Skip to content
BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

5 Commits
README.md
README.md
 
 
born2beroot.pdf
born2beroot.pdf
 
 

Repository files navigation

This project has been created as part of the 42 curriculum by hbani-at.

Born2beroot

Build your first secure Linux server from scratch.

Born2beroot is one of the foundational system administration projects in the 42 Common Core. Unlike programming projects, this project focuses on understanding how a Linux operating system works internally, how to securely configure a server, and how to administer it following industry best practices.

Instead of writing code, you will install, configure, harden, and maintain a complete Linux server running inside a virtual machine. Along the way, you'll learn concepts used daily by Linux administrators, DevOps engineers, cloud engineers, cybersecurity professionals, and backend engineers.

Project Information

Item Value
Project Born2beroot
Curriculum 42 Common Core
Category System Administration
Language Bash / Linux
Operating System Debian (Stable)
Virtualization VirtualBox
Security AppArmor, UFW, SSH, sudo
Services OpenSSH
Monitoring Bash + cron
Subject Version 4

Table of Contents

Project Overview

Born2beroot introduces the fundamental concepts of Linux system administration by requiring the creation of a secure virtual server from scratch.

The project emphasizes security, system configuration, user management, networking, and automation, rather than software development.

The virtual machine must comply with a strict set of security requirements defined in the project subject, including:

  • Installing a minimal Debian or Rocky Linux system
  • Creating encrypted partitions using Logical Volume Manager (LVM)
  • Configuring SSH to listen on port 4242
  • Preventing direct root login through SSH
  • Configuring a firewall (UFW for Debian)
  • Enforcing a strong password policy
  • Configuring sudo according to strict security rules
  • Creating users and groups
  • Writing a monitoring script that periodically displays system information

Although the project appears simple, it introduces many of the technologies used in production Linux servers around the world.

Learning Objectives

After completing this project, you should understand:

  • Linux installation
  • Virtualization and virtual machines
  • Hypervisors (Type 1 vs Type 2)
  • Disk partitioning
  • Logical Volume Manager (LVM)
  • LUKS disk encryption
  • Symmetric vs asymmetric encryption
  • Linux filesystem hierarchy
  • User and group management
  • Password management and PAM
  • SSH protocol and configuration
  • Firewalls and network ports
  • Secure remote administration
  • sudo and privilege escalation
  • System services and systemd
  • Bash scripting
  • Cron and task scheduling
  • System monitoring with wall
  • Basic Linux security hardening

More importantly, this project teaches how Linux systems are administered in real-world environments rather than simply how to use Linux.

Why Does This Project Exist?

Most developers know how to write software.

Far fewer understand where that software actually runs.

Every web application, database, API, Docker container, Kubernetes cluster, or cloud deployment ultimately runs on an operating system.

Understanding how Linux works is therefore essential for:

  • Software Engineers
  • Backend Developers
  • DevOps Engineers
  • Cloud Engineers
  • Site Reliability Engineers (SRE)
  • Security Engineers
  • System Administrators

Born2beroot provides the foundation upon which many later 42 projects—and many professional careers—are built.

Instead of treating Linux as a black box, this project encourages understanding what happens beneath the surface.

Project Requirements

According to the official subject, the virtual machine must satisfy several mandatory requirements.

Operating System

Choose one:

  • Debian Stable (recommended)
  • Rocky Linux

No graphical interface may be installed.

Storage

The server must use:

  • encrypted partitions
  • Logical Volume Manager (LVM)

SSH

The SSH server must:

  • run on port 4242
  • refuse direct root login

Firewall

Configure:

  • UFW (Debian) or firewalld (Rocky)

Only SSH on port 4242 should be accessible.

Security

Implement:

  • strong password policy
  • sudo restrictions
  • command logging
  • password expiration
  • password complexity rules

Users

The system must contain:

  • root
  • your login user

Your user must belong to:

  • sudo
  • user42

Monitoring

Create a Bash script named monitoring.sh that periodically displays important system information using wall.

Bonus

Optional bonus tasks:

  • Set up a specific partition structure (see below)
  • Set up a WordPress site with lighttpd, MariaDB, PHP
  • Set up an additional useful service (NGINX and Apache2 excluded)

Bonus partition structure

The subject bonus requires a structure similar to this:

sda
├── sda1    /boot          (unencrypted, ~500 MB)
└── sda5    LUKS encrypted
    └── LVM group
        ├── root      → /           (mandatory)
        ├── home      → /home       (mandatory)
        ├── var       → /var        (mandatory)
        ├── srv       → /srv        ← bonus
        ├── tmp       → /tmp        ← bonus
        ├── var--log  → /var/log    ← bonus
        └── swap      → [SWAP]      (mandatory)

The bonus adds /srv, /tmp, and /var/log as separate logical volumes. Sizes are arbitrary — allocate what makes sense for your disk (e.g., 10.5 GB disk: 4 GB root, 2 GB home, 2 GB var, 1 GB srv, 500 MB tmp, 500 MB var-log, 500 MB swap).

README

The repository must also contain:

  • README.md
  • signature.txt

Virtualization

This section draws from IBM: What is Virtualization?

What is Virtualization?

Imagine you own a very powerful computer.

Normally, that computer can run only one operating system at a time. If Windows is installed, then Windows controls all the hardware. If Debian is installed, then Debian controls all the hardware.

Virtualization changes this.

It allows a single physical computer to behave as if it were many independent computers, each running its own operating system.

Instead of buying multiple physical machines, we create Virtual Machines (VMs) that share the hardware of one computer.

Each virtual machine behaves like a completely separate computer, with its own:

  • CPU
  • RAM
  • Hard disk
  • Network card
  • Operating System
  • Users
  • Files
  • Services

Even though these components are virtual, the guest operating system cannot tell the difference.

A Real-World Analogy

Imagine an apartment building.

                   Apartment Building
        ┌─────────────────────────────────┐
        │ Apartment 1 │ Apartment 2 │ Apartment 3 │
        └─────────────────────────────────┘
                  ▲          ▲          ▲
                  │          │          │
            Separate families living independently

Everyone shares the same building. However, each apartment has its own furniture, its own electricity usage, its own rules, its own residents. No apartment can directly access another.

Virtualization works the same way.

            Physical Computer
      CPU
      RAM
      SSD
      Network
            │
            ▼
     Hypervisor (VirtualBox)
            │
 ┌──────────┼──────────┐
 │          │          │
 ▼          ▼          ▼
Debian    Ubuntu    Windows
 VM         VM         VM

One physical computer. Multiple isolated computers.

Why Was Virtualization Invented?

Before virtualization became popular, companies had to purchase one physical server for each application.

For example:

Database Server ─── Physical Machine #1
Web Server     ─── Physical Machine #2
Mail Server    ─── Physical Machine #3

Most of these machines were idle most of the time. CPU usage: 5%. RAM usage: 20%. Yet each required electricity, cooling, maintenance, hardware upgrades, and rack space.

This was extremely expensive.

Virtualization solved this problem by allowing many servers to share the same physical hardware. Today, almost every data center, cloud provider, and enterprise infrastructure relies on virtualization.

Advantages of Virtualization

Better Hardware Utilization

Instead of running one operating system per computer, multiple virtual machines share the available hardware. This significantly improves CPU, memory, and storage utilization.

Cost Reduction

Organizations save money by reducing the number of physical servers they need to purchase, power, cool, and maintain.

Isolation

Every virtual machine is isolated. If one VM crashes, the others continue running. If malware infects one VM, the others remain unaffected.

Snapshots

A snapshot records the complete state of a virtual machine. If something goes wrong, you can restore the VM to an earlier state within seconds.

Note: The Born2beroot subject forbids having snapshots at the beginning of the evaluation, but they are extremely useful during development. Remove or delete them before your defense.

Easy Testing

Need to experiment with a firewall? Try a risky kernel configuration? Install a new package? You can safely do so inside a virtual machine without affecting your main operating system.

Portability

A virtual machine is essentially a collection of files. You can move it to another computer and continue using it exactly where you left off.

Virtual Machine Components

A virtual machine emulates the essential hardware of a real computer.

Component Description
Virtual CPU (vCPU) Executes instructions using the host CPU
Virtual RAM Memory allocated from the host
Virtual Disk A file that behaves like a hard drive
Virtual Network Card Provides network connectivity
BIOS/UEFI Starts the virtual machine during boot
Virtual Display Used for graphical output (if installed)

Host OS vs Guest OS

Host Operating System

The operating system installed directly on the physical computer. Examples: Arch Linux, Debian, Windows, macOS. The host owns the actual hardware.

Guest Operating System

The operating system installed inside the virtual machine. For this project, the guest OS is Debian Stable. The guest believes it owns the hardware, but all hardware access is managed by the hypervisor.

How a VM Boots

Power On VM
      │
      ▼
Virtual BIOS / UEFI
      │
      ▼
Bootloader (GRUB)
      │
      ▼
Linux Kernel
      │
      ▼
Systemd
      │
      ▼
Services Start: SSH, UFW, cron, AppArmor ...
      │
      ▼
Login Prompt

The boot process is almost identical to that of a real server.

Virtual Disks

Unlike a physical computer, which uses an actual SSD or HDD, a virtual machine stores its disk inside a file.

For VirtualBox, this file usually has the extension .vdi.

Extension Hypervisor
.vdi VirtualBox
.vmdk VMware
.qcow2 QEMU / UTM
.vhdx Hyper-V

To the guest operating system, this file appears to be a normal hard drive.

Why Does 42 Use Virtualization?

The Born2beroot project focuses on learning Linux system administration, not on installing Linux directly on your personal computer.

Virtualization offers several advantages in this context:

  • Protects your host operating system from accidental damage
  • Allows you to reinstall the server quickly if something goes wrong
  • Provides an environment similar to real production servers
  • Enables experimentation without risking your personal files
  • Makes evaluation consistent across all students

Key Takeaways

  • Virtualization allows multiple OSes to run on a single physical computer
  • Each VM behaves like an independent computer
  • A hypervisor manages access to the physical hardware
  • VMs provide isolation, portability, and efficient resource utilization

Hypervisors

This section draws from IBM: What is a Hypervisor? and VMware: Bare Metal Hypervisor

What is a Hypervisor?

A hypervisor, also known as a Virtual Machine Monitor (VMM), is the software layer responsible for creating, running, and managing virtual machines.

Think of it as the manager between the physical hardware and the virtual machines. Without a hypervisor, virtualization would not be possible.

               Virtual Machine
          (Debian, Ubuntu, Windows)
                    │
                    ▼
              Hypervisor (VMM)
                    │
      ┌─────────────┼─────────────┐
      │             │             │
     CPU           RAM          Storage
                    │
                    ▼
             Physical Hardware

The hypervisor is responsible for:

  • Creating virtual machines
  • Allocating CPU cores
  • Allocating RAM
  • Managing virtual disks
  • Managing networking
  • Isolating VMs from one another
  • Scheduling access to hardware resources

Why Do We Need a Hypervisor?

Imagine installing Debian, Ubuntu, and Windows directly on the same hardware at the same time. Each OS would try to control the CPU, manage memory, access the disk, and configure network devices. Chaos would result.

A hypervisor solves this by acting as an intermediary. Instead of accessing hardware directly, each guest OS communicates with the hypervisor, which safely coordinates access to physical resources.

Type 1 (Bare-Metal)

A Type 1 Hypervisor runs directly on the physical hardware. There is no traditional OS between the hardware and the hypervisor.

Applications
Virtual Machines
──────────────
Type 1 Hypervisor
──────────────
CPU • RAM • Disk • Network
──────────────
Physical Hardware

Since the hypervisor has direct access to the hardware, it provides better performance, lower latency, better scalability, and improved security.

Advantages

  • Near-native performance
  • Efficient resource management
  • Excellent isolation
  • Designed for production environments

Disadvantages

  • More complex to configure
  • Usually intended for servers
  • Requires dedicated hardware

Examples

  • VMware ESXi
  • Microsoft Hyper-V Server
  • Xen
  • Citrix Hypervisor

Type 2 (Hosted)

A Type 2 Hypervisor runs on top of an existing operating system.

Virtual Machine
──────────────
VirtualBox
──────────────
Host OS (Windows / Linux / macOS)
──────────────
Physical Hardware

Instead of communicating directly with the hardware, the hypervisor asks the host OS to perform hardware operations. Every request passes through the host OS, creating a small performance overhead.

Advantages

  • Easy to install
  • Beginner friendly
  • Great for development and testing
  • Convenient snapshots

Disadvantages

  • Slightly lower performance
  • Higher resource usage
  • Depends on host OS stability

This is exactly why 42 uses VirtualBox for Born2beroot.

Type 1 vs Type 2

Feature Type 1 Type 2
Runs directly on hardware Yes No
Requires host OS No Yes
Performance Excellent Very Good
Complexity Higher Lower
Common Usage Data Centers Personal Computers
Best For Production Development & Learning

KVM

KVM (Kernel-based Virtual Machine) is an interesting case. Technically, KVM is built directly into the Linux kernel. When enabled, the Linux kernel itself becomes a hypervisor.

Virtual Machines
│
▼
KVM
│
▼
Linux Kernel
│
▼
Hardware

Although KVM runs within Linux, it operates at the kernel level and has direct access to hardware virtualization features (Intel VT-x or AMD-V). Because of this architecture, KVM delivers performance very close to traditional Type 1 hypervisors.

Many professionals describe KVM as "Type 1-like" because of its efficiency. Large cloud providers like OpenStack commonly rely on KVM.

Source: Red Hat: What is KVM?

Hypervisor Type Common Usage
VirtualBox Type 2 Learning, Development
VMware Workstation Type 2 Development
VMware ESXi Type 1 Enterprise Data Centers
Hyper-V Type 1 Windows Server Environments
Xen Type 1 Cloud Infrastructure
KVM Kernel-Based Linux Servers & Cloud Platforms

Hardware Virtualization (Intel VT-x & AMD-V)

Modern CPUs include hardware features specifically designed for virtualization. Intel calls this Intel VT-x; AMD calls it AMD-V. Without these technologies, virtualization would be much slower because the hypervisor would need to emulate privileged CPU instructions in software. Hardware-assisted virtualization allows guest OSes to execute most instructions directly on the processor while still remaining isolated.

Virtualization Software

To complete Born2beroot, we need software capable of creating and managing virtual machines. The 42 subject recommends:

  • VirtualBox (most platforms)
  • UTM (Apple Silicon Macs)

VirtualBox

VirtualBox is a free and open-source virtualization software developed by Oracle. It is a Type 2 (Hosted) Hypervisor.

+----------------------------------+
|           Debian VM              |
+----------------------------------+
|          VirtualBox              |
+----------------------------------+
|   Windows / Linux / macOS Host   |
+----------------------------------+
|         Physical Hardware        |
+----------------------------------+

Features

  • Multiple OS support: Run several OSes simultaneously
  • Virtual hardware: CPU, RAM, disk, network, USB, audio
  • Snapshots: Save and restore VM state instantly
  • Shared clipboard: Copy/paste between host and guest
  • Shared folders: Expose host directories inside the guest
  • Networking modes: NAT, Bridged, Host-Only, Internal Network

UTM

UTM is a virtualization application designed primarily for macOS. It is especially popular on Apple Silicon (M1, M2, M3) because it provides excellent support for ARM-based systems.

Unlike VirtualBox, UTM is built on top of QEMU, one of the most powerful open-source virtualization projects.

Debian VM
│
▼
UTM
│
▼
QEMU
│
▼
Apple macOS
│
▼
Apple Silicon Hardware

Virtualization vs Emulation

Feature Virtualization Emulation
CPU Architecture Same as host Different from host
Performance Near-native Significantly slower
Translation Minimal (hardware-assisted) Full instruction translation

VirtualBox vs UTM

Feature VirtualBox UTM
Platform Windows, Linux, macOS macOS
Hypervisor Type Type 2 QEMU-based
Apple Silicon Support Limited Excellent
x86 Virtualization Excellent Excellent
Ease of Use Excellent Excellent

Both applications are capable of completing Born2beroot successfully. The choice depends mainly on the host operating system.

Operating Systems

What is an Operating System?

An Operating System (OS) is the software that manages a computer's hardware and provides services for applications. It acts as the bridge between the user (or applications) and the physical hardware.

An OS is responsible for: managing processes, memory, storage, users and permissions, networking, filesystems, security, CPU scheduling, and hardware drivers.

             User
              │
      Applications (SSH, Bash, etc.)
              │
        Operating System
              │
   CPU • RAM • Disk • Network • GPU

What is Linux?

Linux is not an operating system by itself. Linux is a kernel. The kernel is the core component that communicates with hardware, manages memory, schedules processes, handles filesystems, and provides system calls.

A complete Linux operating system consists of:

Applications
│
▼
System Utilities
│
▼
GNU Tools
│
▼
Linux Kernel
│
▼
Hardware

Because the Linux kernel is open source, anyone can build an OS around it. These are called Linux distributions.

What is a Linux Distribution?

A Linux distribution (or distro) is a complete OS built around the Linux kernel. It usually includes:

  • Linux kernel
  • Package manager
  • Installer
  • GNU utilities
  • Shell
  • Security tools
  • Repositories
Distribution Primary Use
Debian Stability
Ubuntu Desktop & Server
Fedora Latest Features
Rocky Linux Enterprise
Arch Linux Rolling Release

Why Does the Subject Allow Debian or Rocky Linux?

The Born2beroot subject allows Debian and Rocky Linux because they represent two of the most influential Linux families:

                  Linux
          ┌────────┴────────┐
      Debian Family     Red Hat Family
          │                  │
      Debian              RHEL
          │                  │
       Ubuntu          Rocky Linux
                       AlmaLinux
                       Fedora

Learning either one provides a strong foundation for Linux system administration.

Debian

Debian is one of the oldest and most respected Linux distributions. Created in 1993 by Ian Murdock, it is developed by a worldwide community of volunteers.

Its primary goals are: stability, reliability, security, and free software. Debian values stability over having the newest software versions. Many servers run Debian for years without major issues.

Why Choose Debian?

  • Extensive documentation
  • Huge community support
  • Stable package repositories
  • Predictable behavior
  • Excellent VirtualBox compatibility
  • Beginner-friendly package management
  • Large number of tutorials

Rocky Linux

Rocky Linux is an enterprise Linux distribution released in 2021, created after Red Hat changed the direction of CentOS. It aims to be 100% compatible with Red Hat Enterprise Linux (RHEL).

Why Companies Use Rocky Linux

  • Enterprise stability
  • Long-term support
  • RHEL compatibility
  • Excellent security
  • Professional server ecosystem

Debian vs Rocky Linux

Feature Debian Rocky Linux
Family Debian Red Hat
Package Manager APT DNF
Package Format .deb .rpm
Primary Goal Stability Enterprise Stability
Community Large Growing
Enterprise Adoption High Very High
Beginner Friendly Excellent Good

Package Managers

A package manager installs, updates, removes, and manages software. Instead of downloading programs manually, Linux distributions install software from trusted repositories.

Distribution Package Manager
Debian / Ubuntu apt
Rocky Linux / Fedora dnf
Arch Linux pacman

apt vs aptitude

The Born2beroot evaluation frequently includes questions about the difference between apt and aptitude.

apt

apt is the modern command-line package manager used by Debian.

sudo apt update
sudo apt upgrade
sudo apt install nginx

Advantages: Fast, simple, officially recommended, installed by default, used in most documentation.

aptitude

aptitude is an alternative package manager with more advanced dependency resolution than apt. It also includes an interactive text-based interface.

sudo aptitude install nginx

Advantages: Better dependency conflict resolution, interactive interface, advanced package searching.

Disadvantages: Not installed by default, less commonly used today.

Which Should You Use?

For Born2beroot, apt is preferred because it is installed by default and is the standard tool in Debian documentation. aptitude remains a powerful tool, but apt has improved significantly over the years.

Why Does the Subject Ask About This?

The project tests whether you understand that Linux provides multiple tools for the same task, each with its own design goals. Being able to explain why you chose apt demonstrates deeper understanding than simply knowing the command syntax.

Source: Packagecloud: apt vs aptitude

Disk Partitioning

What is a Disk?

A disk is a storage device used to permanently store data. In a physical computer, this could be an HDD, SSD, or NVMe SSD. Inside a virtual machine, the "disk" is actually a file created by the hypervisor (.vdi for VirtualBox).

Host Computer → VirtualBox → Debian.vdi → Inside VM: /dev/sda

Linux has no idea that the disk is virtual.

Why Partition a Disk?

Imagine buying a huge warehouse. You could throw everything into one giant room, but finding anything would quickly become a nightmare. Instead, warehouses create separate sections.

A disk partition works the same way. Instead of one huge storage area, the disk is divided into multiple independent sections. Each partition can have its own filesystem, purpose, permissions, and mount point.

This organization improves security, reliability, maintenance, and recovery.

Partition Tables: MBR vs GPT

Before partitions can exist, the disk needs a partition table that describes where each partition begins and ends, its size, and its type.

MBR (Master Boot Record)

The older partitioning scheme.

Pros Cons
Widely supported Max disk size ~2 TB
Simple Max 4 primary partitions
Compatible with BIOS Older design

GPT (GUID Partition Table)

The modern partition table.

Pros
Supports disks >2 TB
Supports many more partitions
Better reliability
Redundant partition tables

Primary vs Logical Partitions

This topic frequently appears during the Born2beroot evaluation.

Primary Partition

A primary partition exists directly in the partition table. MBR allows only four primary partitions.

Extended Partition

An extended partition is a special partition that acts as a container for logical partitions.

Logical Partition

A logical partition exists inside an extended partition. Functionally, it behaves almost the same as a primary partition.

Feature Primary Logical
Exists directly in partition table Yes No
Can boot an OS Yes Usually Yes
MBR Limit Max 4 Many
Location Directly on disk Inside extended partition

With GPT, this distinction is largely obsolete because GPT allows many partitions without needing logical partitions.

Source: EaseUS: Logical vs Primary Partition

Filesystems

A partition by itself is just empty space. Before Linux can store files on it, the partition must be formatted with a filesystem.

ext4

The default filesystem for most Linux distributions. Stable, reliable, fast, with journaling support. Born2beroot commonly uses ext4.

swap

Swap is not a traditional filesystem. It is disk space used as virtual memory. When RAM becomes full, the OS moves inactive pages to swap.

Mount Points

Linux does not assign drive letters like Windows. Instead, every partition is attached to a directory called a mount point.

Partition → Format → Filesystem → Mount → Directory

Example:

/dev/sda1 → ext4 → mounted at /
/dev/sda2 → ext4 → mounted at /home
/dev/sda3 → ext4 → mounted at /var
/dev/sda4 → swap

Why Does Born2beroot Use Multiple Partitions?

Partition Purpose
/ Root filesystem (OS)
/boot Bootloader and kernel files
/home User home directories
swap Virtual memory
/var Logs, caches, variable data

By isolating these directories, a problem affecting one partition is less likely to impact the rest of the system.

Logical Volume Manager (LVM)

This section draws from Wikipedia: LVM and Linux Handbook: LVM Guide

What is LVM?

Logical Volume Manager (LVM) is a storage management layer that sits between the physical disk partitions and the filesystem.

Instead of creating fixed partitions directly on the disk, LVM introduces an abstraction layer that allows storage to be managed much more flexibly.

Think of LVM as a storage manager. Instead of saying "this partition is permanently 10 GB," you say "create a storage pool, then allocate space from that pool whenever it's needed."

Why Was LVM Created?

Traditional partitioning has one major problem: partitions have fixed sizes.

Imagine you create:

/        10 GB
/home     5 GB
/var      5 GB

Months later, /home is 100% full but /var is only 10% used. Although plenty of free space exists on the disk, /home cannot use it because its partition size was fixed during installation.

LVM was designed to solve exactly this problem.

The Three Main Components

LVM is built around three concepts:

Step 1 — Physical Volume (PV)

The lowest layer. Represents a physical storage device (entire disk, partition, or block device) that LVM can use.

/dev/sda2
   │
   ▼
Physical Volume (PV)

Step 2 — Volume Group (VG)

A storage pool created by combining one or more Physical Volumes.

PV1 = 20 GB
PV2 = 30 GB
PV3 = 50 GB
   │
   ▼
VG = 100 GB

Step 3 — Logical Volume (LV)

Created from the free space inside a Volume Group.

Volume Group (100 GB)
   │
   ├── Root LV (30 GB)  → ext4 → /
   ├── Home LV (20 GB)  → ext4 → /home
   ├── Var LV  (15 GB)  → ext4 → /var
   └── Swap LV (8 GB)   → swap

To Linux, a Logical Volume looks exactly like a normal partition:

/dev/mapper/debian--vg-root
/dev/mapper/debian--vg-home

Complete LVM Workflow

Physical Disk
   │
   ▼
Partition
   │
   ▼
Physical Volume
   │
   ▼
Volume Group
   │
   ▼
Logical Volume
   │
   ▼
Filesystem (ext4)
   │
   ▼
Mount Point (/home, /var, /)

LVM in Born2beroot

A typical Debian installation for Born2beroot:

Virtual Disk
   │
   ▼
Physical Volume
   │
   ▼
Volume Group: debian-vg
   │
   ├── root  → /
   ├── home  → /home
   ├── var   → /var
   └── swap  → swap

Traditional Partitions vs LVM

Feature Traditional LVM
Fixed Sizes Yes No
Easy Resizing Difficult Easy
Multiple Disks Limited Supported
Storage Pool No Yes
Snapshots No Yes

Common LVM Commands

sudo pvs           # View Physical Volumes
sudo vgs           # View Volume Groups
sudo lvs           # View Logical Volumes
sudo lvdisplay     # Detailed LV info
sudo vgdisplay     # Detailed VG info
sudo pvdisplay     # Detailed PV info

Disk Encryption (LUKS)

What is Encryption?

Encryption is the process of converting data into a coded form that can only be read by someone who has the correct decryption key. If an attacker gains physical access to the disk, encrypted data remains unreadable without the passphrase.

Symmetric vs Asymmetric Encryption

Feature Symmetric Asymmetric
Keys One shared key Public + Private key pair
Speed Fast Slow
Usage Encrypting data at rest Key exchange, SSH, SSL/TLS
Example AES, ChaCha20 RSA, ECDSA

In LUKS disk encryption, symmetric encryption is used. The passphrase you enter at boot is used to derive the symmetric key that decrypts the data.

Source: Medium: Symmetric and Asymmetric Encryption

What is LUKS?

LUKS (Linux Unified Key Setup) is the standard for Linux disk encryption. It provides a platform-independent way to manage encryption keys and protect data at rest.

LUKS is not the encryption algorithm itself. It is a key management standard that sits on top of encryption algorithms like AES. It handles:

  • Storing encrypted keys on disk
  • Allowing multiple passphrases (up to 8)
  • Providing a header with encryption metadata
  • Making encrypted disks portable between systems

How LUKS Works

Disk Partition
   │
   ▼
LUKS Header (encryption metadata, key slots)
   │
   ▼
Encrypted Data (AES encrypted)
   │
   ▼
Upon boot: Enter passphrase → LUKS decrypts key → Filesystem accessible

When the system boots, you are prompted for a passphrase. LUKS uses this passphrase to decrypt the master key, which then decrypts the data. Without the correct passphrase, the data appears as random noise.

LUKS Header Structure

+---------------------------+
| LUKS phdr (header)        |
| - Magic: "LUKS"           |
| - Cipher: aes-xts-plain64 |
| - Hash: sha256            |
| - Key size: 512 bits      |
+---------------------------+
| Key Slot 0 (active)       |
| Key Slot 1 (free)         |
| Key Slot 2-7 (free)       |
+---------------------------+
| Encrypted Data            |
| (ext4 filesystem)         |
+---------------------------+

LUKS Key Slots

LUKS supports up to 8 key slots. Each slot can hold a copy of the master encryption key, encrypted with a different passphrase. This allows:

  • Multiple users to have different passphrases
  • Adding backup passphrases
  • Revoking a passphrase by removing its key slot

Why Does 42 Require Encryption?

The subject requires at least 2 encrypted partitions using LVM. This is a fundamental security practice:

  • Physical theft protection: If someone steals the VM disk file, they cannot read the data without the passphrase
  • Data confidentiality: Even if the disk is moved to another system, data remains protected
  • Compliance requirement: Encrypted storage is a standard requirement in enterprise and regulated environments
  • Real-world practice: Production servers almost always use disk encryption

Verifying Encryption

sudo dmsetup ls                # List device mapper targets (includes LUKS)
sudo cryptsetup status <name>  # Check LUKS device status
lsblk                           # Check partition layout
sudo blkid                      # Check filesystem types and UUIDs

Example output of lsblk with LUKS:

NAME                   MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                      8:0    0   32G  0 disk
├─sda1                   8:1    0  487M  0 part  /boot
├─sda2                   8:2    0    1K  0 part
└─sda5                   8:5    0 31.5G  0 part
  └─sda5_crypt          254:0    0 31.5G  0 crypt
    ├─debian--vg-root   254:1    0   10G  0 lvm   /
    ├─debian--vg-home   254:2    0    5G  0 lvm   /home
    ├─debian--vg-var    254:3    0    5G  0 lvm   /var
    └─debian--vg-swap   254:4    0    2G  0 lvm   [SWAP]

SSH

This section draws from DigitalOcean: Understanding SSH Encryption, SSH.com: sshd, and the user's SSH notes.

What is SSH?

SSH (Secure Shell) is a cryptographic network protocol for operating network services securely over an unsecured network. It provides encrypted communication between a client and a server.

SSH ensures:

  • Confidentiality: Encrypts data between client and server
  • Integrity: Verifies data hasn't been tampered with
  • Authentication: Confirms identities of clients and servers

In Born2beroot, SSH is the only way to access the server remotely. The subject requires SSH to be running on port 4242 and must refuse direct root login.

How SSH Works

SSH uses a combination of symmetric encryption (for the session), asymmetric encryption (for key exchange), and hashing (for integrity).

Connection Overview

Client                          Server
   │                               │
   ├── TCP Connection (port 22) ──►│
   │◄── Server Host Key ───────────┤
   │── Key Exchange Init ────────►│
   │◄── Diffie-Hellman Reply ─────┤
   │                               │
   │   [Symmetric Session Key      │
   │    Established Securely]      │
   │                               │
   │── SSH User Auth Request ────►│
   │◄── Auth Challenge ────────────┤
   │── Auth Response ────────────►│
   │◄── Auth Success ──────────────┤
   │                               │
   │   [Encrypted Session Begins]  │
   │                               │

Step-by-step SSH Connection

  1. TCP Handshake: Client connects to server on port 22 (or 4242 in our case)

  2. Server Identification: Server sends its host key. Client checks against ~/.ssh/known_hosts to verify it's the expected server (prevents man-in-the-middle attacks)

  3. Key Exchange (Diffie-Hellman): Client and server generate a shared symmetric session key using asymmetric encryption. This key will encrypt all further communication

  4. User Authentication: The client authenticates using either:

    • Password authentication: Password is sent through the encrypted tunnel
    • Public key authentication: Client signs a challenge with its private key

  5. Session Established: An encrypted shell session begins

SSH Host Keys

Each SSH server has a unique host key pair (typically RSA, ECDSA, or Ed25519). When a client connects, the server presents its public key. The client checks this against its known_hosts file.

If keys do not match, a warning is issued, preventing man-in-the-middle attacks.

~/.ssh/known_hosts
/etc/ssh/ssh_known_hosts

Encryption Types in SSH

SSH uses three types of encryption:

Type Role Algorithm Example
Symmetric Encrypts the session data AES, ChaCha20
Asymmetric Key exchange, host authentication RSA, ECDSA, Ed25519
Hashing Integrity checking HMAC-SHA256

Source: DigitalOcean: Understanding the SSH Encryption and Connection Process

SSH Configuration

The OpenSSH server configuration file is:

/etc/ssh/sshd_config
File/Purpose
/etc/ssh/sshd_config — SSH server configuration
/etc/ssh/ssh_config — SSH client configuration
/etc/ssh/ssh_host_* — Host key pairs
~/.ssh/authorized_keys — Public keys for key-based auth
~/.ssh/known_hosts — Known host keys
~/.ssh/id_rsa — User's private key
~/.ssh/id_rsa.pub — User's public key

Port 4242

The subject requires SSH to run on port 4242 instead of the default port 22.

# Edit /etc/ssh/sshd_config
# Change this line:
# Port 22
# To:
Port 4242

After making changes, restart the service:

sudo systemctl restart ssh

Why change the port? While security by obscurity is not true security, changing the default port reduces automated brute-force attacks that scan only port 22. Combined with a strong password policy and key-based authentication, this improves security.

How to connect:

ssh your_login@localhost -p 4242

Disabling Root Login

The subject requires that direct root login via SSH is disabled.

# Edit /etc/ssh/sshd_config
PermitRootLogin no

Why disable root login?

  • The root username exists on every Linux system. An attacker only needs to guess the password, not the username
  • Root has unrestricted privileges. Compromise leads to maximum damage
  • Auditing is harder when multiple admins share the root account
  • Forces users to log in as a regular user and escalate via sudo, providing accountability

On modern systems, the default may be prohibit-password, which allows key-based root login but not password-based.

sudo systemctl restart ssh

SSH Key-Based Authentication

SSH supports authentication using public/private key pairs instead of passwords.

Generating a Key Pair

ssh-keygen -t ed25519
# or
ssh-keygen -t rsa -b 4096

Copying the Public Key

ssh-copy-id -i ~/.ssh/id_ed25519.pub your_login@localhost -p 4242

How Key Authentication Works

Client                          Server
   │                               │
   │── Request auth (public key) ►│
   │◄── Challenge encrypted with  │
   │    user's public key         │
   │                               │
   │── Decrypt challenge using    │
   │    private key               │
   │── Send proof back ──────────►│
   │◄── Access granted ───────────┤

Verifying SSH

# Check SSH service status
sudo systemctl status ssh

# Verify listening port
ss -tlnp | grep 4242

# Check SSH config for root login
sudo grep PermitRootLogin /etc/ssh/sshd_config

# Test connection
ssh your_login@localhost -p 4242

Expected results:

  • SSH service is active (running)
  • Listening on port 4242
  • Root login is denied
  • Connection works as a regular user

Firewall (UFW)

What is a Firewall?

A firewall is a network security system that monitors and controls incoming and outgoing network traffic based on predetermined security rules. It establishes a barrier between a trusted internal network and untrusted external networks.

What is UFW?

UFW (Uncomplicated Firewall) is a user-friendly frontend for managing iptables firewall rules on Linux. It is the default firewall tool for Debian and Ubuntu systems.

UFW simplifies iptables commands into easy-to-understand syntax:

ufw allow 4242

instead of the equivalent iptables command:

iptables -A INPUT -p tcp --dport 4242 -j ACCEPT

Why Use a Firewall?

  • Reduces attack surface: Only explicitly allowed ports are accessible
  • Blocks unwanted traffic: Prevents unauthorized access attempts
  • Industry standard: Every production server has a firewall
  • Subject requirement: The firewall must block all ports except 4242

Without a firewall, every running service is exposed to the network. A misconfigured or vulnerable service could be exploited.

UFW Configuration

Step 0: Set default policies

Before adding rules, set the default policy:

sudo ufw default deny incoming
sudo ufw default allow outgoing

This ensures all incoming traffic is blocked by default unless explicitly allowed.

Step 1: Allow SSH on port 4242

sudo ufw allow 4242

Step 2: Enable UFW

sudo ufw enable

Step 3: Check status

sudo ufw status numbered

Expected output:

Status: active

To                         Action      From
--                         ------      ----
4242                       ALLOW       Anywhere
4242 (v6)                  ALLOW       Anywhere (v6)

Additional UFW Commands

sudo ufw status          # Show current rules
sudo ufw status numbered # Show rules with numbers
sudo ufw delete NUM      # Delete rule by number
sudo ufw disable         # Disable firewall
sudo ufw reload          # Reload firewall

Verifying UFW

# Check if UFW is active
sudo ufw status

# Verify only port 4242 is open
ss -tlnp

# Check UFW rules are persistent
sudo ufw show added

Source: DigitalOcean: UFW Essentials

AppArmor

What is AppArmor?

AppArmor (Application Armor) is a Linux security module that provides Mandatory Access Control (MAC). It allows the system administrator to restrict programs' capabilities on a per-program basis.

AppArmor confines programs to a limited set of resources (files, network, capabilities) rather than allowing full system access.

How AppArmor Works

AppArmor uses security profiles loaded into the kernel to restrict what a program can do. Profiles can run in two modes:

Mode Description
Enforce Policy is enforced. Violations are logged and blocked
Complain Policy is not enforced. Violations are logged but allowed

Profile Location

AppArmor profiles are stored in:

/etc/apparmor.d/

Example profile for a program:

/etc/apparmor.d/usr.sbin.sshd

Checking AppArmor Status

sudo aa-status

Example output:

apparmor module is loaded.
14 profiles are loaded.
14 profiles are in enforce mode.
   /usr/bin/man
   /usr/sbin/sshd
   ...
0 profiles are in complain mode.

Common AppArmor Commands

sudo aa-status           # Show AppArmor status
sudo aa-enforce <path>   # Set profile to enforce mode
sudo aa-complain <path>  # Set profile to complain mode
sudo apparmor_parser -r <profile>  # Reload a profile

AppArmor vs SELinux

For Debian, the subject requires AppArmor. For Rocky Linux, the subject requires SELinux.

Feature AppArmor SELinux
Type MAC (Mandatory Access Control) MAC
Default on Debian, Ubuntu RHEL, Rocky, Fedora
Configuration Path-based profiles Label-based policies
Ease of Use Simpler, more beginner-friendly More complex
Granularity Moderate Very high
Profile Language Easier to write More complex rules

Why AppArmor for Debian?

AppArmor is simpler to configure than SELinux while still providing strong security. It is the default MAC system for Debian and is sufficient for the project requirements.

Why Does 42 Require AppArmor?

The subject requires AppArmor to be running at startup. This ensures:

  • Programs are confined to their required resources
  • Even if a service is compromised, damage is limited
  • Students learn about Mandatory Access Control concepts
  • Security best practices are reinforced

Verifying AppArmor

# Check if AppArmor is loaded and running
sudo aa-status

# Alternatively
sudo cat /sys/module/apparmor/parameters/enabled
# Output: Y

# Check AppArmor service
sudo systemctl status apparmor

Password Policy

What is a Password Policy?

A password policy is a set of rules designed to enhance computer security by requiring users to create strong passwords and manage them properly. It typically covers password length, complexity, expiration, and history.

Subject Requirements

According to the Born2beroot subject:

Requirement Value
Password expiration Every 30 days
Min days before password change 2 days
Warning before expiration 7 days
Minimum password length 10 characters
Must contain Uppercase, lowercase, number
Max consecutive identical chars 3
Must not contain username Yes
Root password follows policy Yes

Password Aging (login.defs)

Password aging settings are configured in /etc/login.defs.

sudo nano /etc/login.defs

Set the following values (these apply to new users):

PASS_MAX_DAYS   30
PASS_MIN_DAYS   2
PASS_WARN_AGE   7
Setting Purpose Subject Value
PASS_MAX_DAYS Max days a password is valid 30
PASS_MIN_DAYS Min days before password can be changed 2
PASS_WARN_AGE Days before expiration to warn user 7

Apply to Existing Users with chage

The settings in /etc/login.defs only apply to newly created users. For existing users, use chage:

sudo chage -M 30 -m 2 -W 7 your_login
sudo chage -M 30 -m 2 -W 7 root

Verify with:

sudo chage -l your_login
sudo chage -l root

Example output:

Last password change                    : May 01, 2024
Password expires                        : May 31, 2024
Password inactive                       : never
Account expires                         : never
Minimum number of days between password change     : 2
Maximum number of days between password change     : 30
Number of days of warning before password expires  : 7

Password Complexity (PAM)

Password complexity is managed by PAM (Pluggable Authentication Modules). PAM is a flexible framework for authentication on Linux systems.

Installing libpam-pwquality

For Debian, the pam_pwquality module enforces password quality rules:

sudo apt update
sudo apt install libpam-pwquality

Configuring Password Quality

Edit /etc/pam.d/common-password:

sudo nano /etc/pam.d/common-password

Find the line containing pam_pwquality.so and modify it:

password requisite pam_pwquality.so retry=3 minlen=10 ucredit=-1 lcredit=-1 dcredit=-1 maxrepeat=3 reject_username difok=7

⚠️ difok=7 and root: The subject says "The following rule does not apply to the root password: The password must have at least 7 characters that are not part of the former password. Of course, your root password has to comply with this policy." This means difok=7 explicitly does NOT apply to root. PAM's pam_pwquality exempts root by default — so we omit enforce_for_root. This means no PAM complexity rules apply to root. To still enforce aging rules on root, use chage (covered above). If you prefer simplicity, add enforce_for_root (most evaluators accept it), but know the subject carves out difok for root.

Parameter Breakdown

Parameter Meaning Subject Value
retry=3 Allow 3 attempts before failure 3
minlen=10 Minimum password length 10
ucredit=-1 At least 1 uppercase letter 1
lcredit=-1 At least 1 lowercase letter 1
dcredit=-1 At least 1 digit 1
maxrepeat=3 Max 3 consecutive identical chars 3
reject_username Password must not contain username Yes
difok=7 At least 7 chars different from old password 7
(no enforce_for_root) difok=7 does not apply to root per subject Not set

What is PAM?

PAM (Pluggable Authentication Modules) is a framework that allows system administrators to configure authentication methods independently of applications. Instead of each application implementing its own authentication, PAM provides a unified API.

PAM Architecture

Application (login, sshd, passwd)
       │
       ▼
┌──────────────────────────┐
│      PAM Library         │
│  (libpam.so)             │
│                          │
│  Reads /etc/pam.d/<app>  │
└──────┬───────────────────┘
       │
       ▼
┌──────────────────────────┐
│      PAM Modules         │
│                          │
│  pam_unix      (auth)    │
│  pam_pwquality (quality) │
│  pam_limits    (limits)  │
│  pam_env       (env)     │
└──────────────────────────┘

PAM modules are stacked. The order matters:

  • required — must pass for auth to succeed; other modules still run
  • requisite — fails immediately if this module fails
  • sufficient — skips remaining modules on success

PAM configuration files

Located in /etc/pam.d/:

/etc/pam.d/
├── common-password    # Password rules
├── common-auth        # Authentication rules
├── common-account     # Account management
├── common-session     # Session management
├── login              # Login authentication
└── sshd               # SSH authentication

Verifying Password Policy

# Check password aging for a user
sudo chage -l your_login

# Check global password defaults
grep PASS_MAX /etc/login.defs
grep PASS_MIN /etc/login.defs
grep PASS_WARN /etc/login.defs

# Check PAM password configuration
grep pam_pwquality /etc/pam.d/common-password

Source: OSTechNix: Set Password Policies in Linux

sudo Configuration

What is sudo?

sudo (Superuser DO) allows a permitted user to execute a command as the superuser or another user, while being logged for accountability.

sudo vs su

Feature su sudo
Requires root password Yes No (uses user's password)
Logs commands No Yes
Granular permissions No Yes
Keeps user environment No Yes

Subject Requirements for sudo

The subject requires:

Requirement Value
Max authentication attempts 3
Custom error message Yes
Log all actions (input + output) Yes, in /var/log/sudo/
TTY mode enabled Yes
Restricted PATH Yes

Configuring sudo

Create a custom sudo configuration file:

sudo visudo -f /etc/sudoers.d/sudoconfig

Add the following rules:

Defaults  passwd_tries=3
Defaults  badpass_message="Incorrect password. Please try again."
Defaults  log_input, log_output
Defaults  iolog_dir=/var/log/sudo
Defaults  requiretty
Defaults  secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

Parameter Breakdown

Directive Purpose
passwd_tries=3 Max 3 wrong password attempts before sudo fails
badpass_message="..." Custom message shown on wrong password
log_input Log all input typed during sudo sessions
log_output Log all output displayed during sudo sessions
iolog_dir=/var/log/sudo Directory for sudo I/O logs
requiretty sudo can only be run from a terminal (TTY)
secure_path=... Restricted PATH for sudo commands

Verifying sudo Configuration

# Check sudo configuration
sudo -l

# Check that the config file is valid
visudo -c -f /etc/sudoers.d/sudoconfig

sudo Logs

All sudo actions are logged. Input logs capture what the user typed; output logs capture what was displayed.

# View sudo log directory
sudo ls -la /var/log/sudo/

# Read sudo logs (use sudoreplay for I/O logs)
sudo sudoreplay -l

Why Logging Matters

  • Accountability: Every privileged action is traced to a specific user
  • Auditing: Security teams can review who did what and when
  • Forensics: In case of a breach, logs help determine the attack vector
  • Subject requirement: All sudo input and output must be archived

Users and Groups

What is a User?

A user account provides security boundaries, a unique identifier (UID), and ownership of processes and files.

Types of Users

Type Description
Superuser (root) UID 0, full system access
System users Used by services/daemons
Regular users Used for daily activities

The /etc/passwd File

Stores user account metadata:

username:x:UID:GID:comment:home_directory:shell
Field Description
username Login name
x Password placeholder (hash in /etc/shadow)
UID User ID
GID Primary Group ID
comment Full name / description
home_directory User's home directory
shell Default login shell

The /etc/shadow File

Stores encrypted password hashes and aging information:

username:$algorithm$salt$hash:last_change:min:max:warn:inactive:expire
Field Description
$algorithm$ Hash algorithm ($y$ = yescrypt, $6$ = SHA-512)
salt Random salt value
hash Cryptographic hash of password
last_change Days since epoch of last password change
min Minimum days before password change
max Maximum days before password change
warn Warning days before expiration

What is a Group?

A group is a collection of users to share access to files or resources. Identified by GID, stored in /etc/group.

group_name:x:GID:user1,user2,user3

Primary vs Supplementary Groups

Type Description
Primary group Defined in /etc/passwd, owns user's files
Supplementary group Listed in /etc/group, for extra access

Subject Requirements

The Born2beroot subject requires:

  • A user with your login as the username
  • The user must belong to sudo and user42 groups
  • During evaluation, you must create a new user and assign it to a group

User Management Commands

Creating a User

sudo useradd -m username
sudo passwd username

Modifying a User

sudo usermod -aG groupname username   # Add to supplementary group
sudo usermod -s /bin/bash username    # Change shell

Deleting a User

sudo userdel username           # Delete user
sudo userdel -r username        # Delete user + home directory

Group Management Commands

Creating a Group

sudo groupadd groupname

Adding a User to a Group

sudo usermod -aG groupname username

Removing a User from a Group

sudo gpasswd -d username groupname

Viewing Group Information

id username              # Show UID, GID, groups
groups username          # Show groups for a user
getent group groupname   # Show group members

Important Files and Their Purposes

File Purpose
/etc/passwd User account information
/etc/shadow Encrypted password hashes
/etc/group Group database
/etc/sudoers sudo configuration
/etc/login.defs Password aging and user creation defaults
/etc/hostname Machine hostname
/etc/hosts Local hostname resolution
/etc/ssh/sshd_config SSH server configuration
/etc/pam.d/common-password PAM password rules

Monitoring Script

What is monitoring.sh?

The monitoring script is a Bash script that displays system information on all terminals every 10 minutes. It is executed at server startup and runs periodically via cron.

Subject Requirements

The script must display the following information:

  1. Architecture — OS and kernel version
  2. Physical processors — Number of physical CPUs
  3. Virtual processors — Number of virtual CPUs (vCPUs)
  4. RAM usage — Current available RAM and utilization percentage
  5. Disk usage — Current available storage and utilization percentage
  6. CPU load — Current utilization rate of processors
  7. Last boot — Date and time of the last reboot
  8. LVM status — Whether LVM is active
  9. Active connections — Number of active TCP connections
  10. User log — Number of users on the server
  11. Network — IPv4 address and MAC address
  12. Sudo count — Number of commands executed with sudo

Script Breakdown

1. Architecture

arch=$(uname -a)

uname -a prints all system information: kernel name, hostname, kernel release, kernel version, machine hardware, and OS.

2. Physical Processors

pcpu=$(grep "physical id" /proc/cpuinfo | sort -u | wc -l)

Each physical CPU has a unique physical id in /proc/cpuinfo. Sorting unique IDs and counting them gives the number of physical processors.

3. Virtual Processors

vcpu=$(grep "^processor" /proc/cpuinfo | wc -l)

Each logical processor (including hyperthreading) is listed as processor in /proc/cpuinfo.

4. RAM Usage

ram_total=$(free --mega | awk '$1 == "Mem:" {print $2}')
ram_used=$(free --mega | awk '$1 == "Mem:" {print $3}')
ram_percent=$(free --mega | awk '$1 == "Mem:" {printf "%.2f", $3/$2*100}')

free --mega displays memory in megabytes. awk extracts total and used values.

5. Disk Usage

disk_total=$(df -BG --total | grep "total" | awk '{print $2}')
disk_used=$(df -BG --total | grep "total" | awk '{print $3}')
disk_percent=$(df -B1 --total | grep "total" | awk '{printf "%.2f", $3/$2*100}')

df displays filesystem disk usage. -BG shows values in gigabytes. The --total line sums all filesystems.

6. CPU Load

cpu_load=$(top -bn1 | grep "^%Cpu" | awk '{print $2}')

top -bn1 runs one iteration of top in batch mode. The %Cpu line shows CPU utilization. Field 2 is the user-space CPU percentage.

7. Last Boot

last_boot=$(who -b | awk '{print $3 " " $4}')

who -b shows the last system boot time.

8. LVM Status

lvm_active=$(lsblk | grep "lvm" | wc -l)
lvm_status=$(if [ $lvm_active -eq 0 ]; then echo "no"; else echo "yes"; fi)

lsblk lists block devices. If any device uses LVM, the output will contain "lvm".

9. Active TCP Connections

tcp_connections=$(ss -tln | wc -l)

ss -tln shows listening TCP sockets. The count gives active connections.

10. User Log

user_log=$(who | wc -l)

who lists currently logged-in users.

11. Network Information

ipv4=$(hostname -I)
mac=$(ip link show | grep "ether" | awk '{print $2}')

hostname -I shows the IPv4 address. ip link show shows network interfaces; the ether line contains the MAC address.

12. Sudo Count

sudo_count=$(grep -c "sudo" /var/log/sudo/seq)

Counts entries in the sudo log sequence file. Alternatively:

sudo_count=$(journalctl | grep -c "sudo.*COMMAND")

Full Script

#!/bin/bash

# Cron runs with a minimal PATH — commands like free, ss, who, ip may not
# resolve without this explicit path.
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

arch=$(uname -a)
pcpu=$(grep "physical id" /proc/cpuinfo | sort -u | wc -l)
vcpu=$(grep "^processor" /proc/cpuinfo | wc -l)
ram_total=$(free --mega | awk '$1 == "Mem:" {print $2}')
ram_used=$(free --mega | awk '$1 == "Mem:" {print $3}')
ram_percent=$(free --mega | awk '$1 == "Mem:" {printf "%.2f", $3/$2*100}')
disk_total=$(df -BG --total | grep "total" | awk '{print $2}')
disk_used=$(df -BG --total | grep "total" | awk '{print $3}')
disk_percent=$(df -B1 --total | grep "total" | awk '{printf "%.2f", $3/$2*100}')
cpu_load=$(top -bn1 | grep "^%Cpu" | awk '{print $2}')
last_boot=$(who -b | awk '{print $3 " " $4}')
lvm_active=$(lsblk | grep -c "lvm")
lvm_status=$(if [ "$lvm_active" -eq 0 ]; then echo "no"; else echo "yes"; fi)
tcp_connections=$(ss -tln | wc -l)
user_log=$(who | wc -l)
ipv4=$(hostname -I)
mac=$(ip link show | grep "ether" | awk '{print $2}')
sudo_count=$(journalctl | grep -c "sudo.*COMMAND")

wall "
#Architecture: $arch
#CPU physical: $pcpu
#vCPU: $vcpu
#Memory Usage: $ram_used/${ram_total}MB ($ram_percent%)
#Disk Usage: $disk_used/${disk_total} ($disk_percent%)
#CPU load: $cpu_load%
#Last boot: $last_boot
#LVM use: $lvm_status
#Connections TCP: $tcp_connections ESTABLISHED
#User log: $user_log
#Network: IP $ipv4 ($mac)
#Sudo: $sudo_count cmd
"

How wall Works

The wall (write all) command sends a message to all currently logged-in users' terminals. It is used in the monitoring script to display system information on all TTYs simultaneously.

wall "message"

Alternatively, using a here-doc:

wall << EOF
message
EOF

Cron

What is Cron?

Cron is a time-based job scheduler in Unix-like operating systems. It allows users to run scripts or commands at specified times and intervals.

How Cron Works

The cron daemon (cron on Debian) reads configuration files called crontabs and executes commands according to their schedule.

System Time → Cron Daemon → Check Crontabs → Execute Commands

Crontab Syntax

* * * * * command_to_run
┬ ┬ ┬ ┬ ┬
│ │ │ │ │
│ │ │ │ └── Day of week (0-7, 0=Sunday)
│ │ │ └──── Month (1-12)
│ │ └────── Day of month (1-31)
│ └──────── Hour (0-23)
└────────── Minute (0-59)

Special Scheduling

Expression Meaning
*/10 * * * * Every 10 minutes
0 * * * * Every hour
0 0 * * * Every day at midnight
@reboot At system startup

Setting Up the Monitoring Script

Step 1: Place the script

sudo cp monitoring.sh /usr/local/bin/monitoring.sh
sudo chmod +x /usr/local/bin/monitoring.sh

Step 2: Add to root's crontab

sudo crontab -e

Add these lines:

*/10 * * * * /usr/local/bin/monitoring.sh
@reboot /usr/local/bin/monitoring.sh

⚠️ Cron gotcha: Cron runs with a stripped PATH (/usr/bin:/bin). Commands like free, ss, who, hostname, ip may not resolve. Fix by either: (a) adding PATH=... at the top of monitoring.sh (already done in the full script above), or (b) setting PATH in the crontab:

*/10 * * * * PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /usr/local/bin/monitoring.sh
@reboot PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /usr/local/bin/monitoring.sh

Step 3: Verify cron

sudo systemctl status cron
sudo crontab -l

Stopping Cron Without Modifying the Script

During the defense, you will be asked to stop the monitoring script from displaying without modifying the script itself.

Two methods:

Method 1: Stop the cron daemon

sudo systemctl stop cron
sudo systemctl status cron

This stops cron entirely, preventing any scheduled job from running.

Method 2: Edit root's crontab

sudo crontab -e

Comment out the lines with #:

#*/10 * * * * /usr/local/bin/monitoring.sh
#@reboot /usr/local/bin/monitoring.sh

Installation Guide

Prerequisites

  • VirtualBox (or UTM on Apple Silicon)
  • Debian Stable ISO (netinst or DVD image)
  • At least 1 GB RAM allocated to VM
  • At least 10 GB virtual disk

Step 1: Create the Virtual Machine

  1. Open VirtualBox
  2. Click New
  3. Name: Born2beroot (or your login)
  4. Type: Linux
  5. Version: Debian (64-bit)
  6. Memory: 1024 MB
  7. Hard disk: Create a virtual hard disk now
  8. Size: 8+ GB (recommend 12.8+ GB for bonus)
  9. File type: VDI
  10. Storage: Dynamically allocated

Step 2: Install Debian

  1. Attach the Debian ISO to the VM
  2. Start the VM
  3. Select Install (not graphical install)
  4. Language: English
  5. Location: United States
  6. Keymap: American English
  7. Configure the network:
    • Hostname: your_login42 (e.g., wil42)
    • Domain: (leave blank)
  8. Root password: Set a strong password
  9. User account:
    • Full name: (your name)
    • Username: your_login
    • Password: strong password
  10. Partition disks: Select Manual or Guided - use entire disk with LVM and encryption

Step 3: Partitioning with LVM and Encryption

If using guided partitioning with LVM and encryption:

  1. Select Guided - use entire disk with LVM and encryption
  2. Select the virtual disk
  3. Choose the partitioning scheme:
    • Separate /home, /var, and /swap partitions recommended
  4. Review partition layout
  5. Enter encryption passphrase
  6. Confirm partitioning

Expected layout:

sda1    /boot      (unencrypted, ~500 MB)
sda5    LUKS encrypted
  └─── debian-vg
         ├── root   → /
         ├── home   → /home
         ├── var    → /var
         └── swap   → swap

Note: The subject requires at least 2 encrypted partitions. With this scheme, all partitions except /boot are encrypted under LUKS.

Step 4: Post-Installation Setup

After installation completes, reboot and log in as root.

Update the system

apt update
apt upgrade -y

Install necessary packages

apt install sudo ufw openssh-server -y

Create the user42 group

The subject requires your user to be in the user42 group, which does not exist by default on Debian:

groupadd user42

Add your user to required groups

usermod -aG sudo your_login
usermod -aG user42 your_login

Step 5: Configure sudo

visudo -f /etc/sudoers.d/sudoconfig

Add:

Defaults  passwd_tries=3
Defaults  badpass_message="Incorrect password. Please try again."
Defaults  log_input, log_output
Defaults  iolog_dir=/var/log/sudo
Defaults  requiretty
Defaults  secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

Step 6: Configure SSH

nano /etc/ssh/sshd_config

Change:

Port 4242
PermitRootLogin no

Restart SSH:

systemctl restart ssh

Step 7: Configure UFW

ufw allow 4242
ufw enable
ufw status

Step 8: Configure Password Policy

Set password aging

Edit /etc/login.defs:

PASS_MAX_DAYS   30
PASS_MIN_DAYS   2
PASS_WARN_AGE   7

Apply to existing users:

chage -M 30 -m 2 -W 7 your_login
chage -M 30 -m 2 -W 7 root

Set password complexity

apt install libpam-pwquality -y

Edit /etc/pam.d/common-password:

password requisite pam_pwquality.so retry=3 minlen=10 ucredit=-1 lcredit=-1 dcredit=-1 maxrepeat=3 reject_username difok=7

See the Password Policy section for the difok/enforce_for_root discussion.

Step 9: Create User and Assign Groups

Your login user should already exist from installation. Verify:

id your_login

Expected:

uid=1000(your_login) gid=1000(your_login) groups=1000(your_login),27(sudo),1001(user42)

Step 10: Set Hostname

hostnamectl set-hostname your_login42

Edit /etc/hosts:

127.0.0.1   localhost
127.0.1.1   your_login42

Step 11: Set Up monitoring.sh

nano /usr/local/bin/monitoring.sh

Paste the script content, then:

chmod +x /usr/local/bin/monitoring.sh

Test it:

/usr/local/bin/monitoring.sh

Step 12: Configure Cron

crontab -e

Add:

*/10 * * * * /usr/local/bin/monitoring.sh
@reboot /usr/local/bin/monitoring.sh

Step 13: Generate signature.txt

On your host machine (not inside the VM), navigate to the VirtualBox VM folder:

# Linux
sha1sum ~/VirtualBox\ VMs/Born2beroot/Born2beroot.vdi

# macOS
shasum ~/VirtualBox\ VMs/Born2beroot/Born2beroot.vdi

# Windows
certUtil -hashfile "C:\Users\YourName\VirtualBox VMs\Born2beroot\Born2beroot.vdi" sha1

Copy the hash into signature.txt at the root of your repository.

◆ Preserving the signature across evaluations

Every boot and shutdown changes the .vdi file — logs, timestamps, journal files all get written. If the hash in signature.txt doesn't match the VM disk at evaluation, your grade is 0. Two strategies:

Strategy A — Duplicate (recommended):

  1. Fully configure the VM, power it off cleanly
  2. Copy the entire VM folder: 
    cp -r ~/VirtualBox\ VMs/Born2beroot ~/VirtualBox\ VMs/Born2beroot-eval
  3. Generate sha1sum from the copy, paste the hash into signature.txt
  4. Never boot the copy. Use the original as your working VM
  5. At evaluation, register the copy in VirtualBox: Machine → Add, select the copy's .vbox file
  6. The copy's disk is untouched → hash matches → safe

Strategy B — Save state:

  1. Generate signature from the powered-off VM
  2. Before evaluation, use Save State (not power off) — this preserves the disk
  3. At evaluation, resume from saved state
  4. The disk hash still matches

Why this matters: one evaluation session can permanently invalidate your signature for the next. Duplication or save-state avoids this entirely.

Rocky Linux installation walkthrough

If you chose Rocky Linux instead of Debian, the steps differ. Here is the equivalent installation.

Step R1: Install Rocky

  1. Boot from the Rocky ISO
  2. Select Install Rocky Linux 9
  3. Language: English → Continue
  4. Installation Destination: select the virtual disk, enable encryption, configure LVM with separate /home, /var, and swap
  5. Network & Hostname: set hostname to your_login42, enable the network adapter
  6. Root Password: set a strong password
  7. User Creation: create your login user, check Make this user administrator (adds to wheel group)
  8. Begin installation

Step R2: Post-installation

# Update the system
dnf update -y

# Install required packages
dnf install sudo openssh-server firewalld -y

# Create the user42 group
groupadd user42
usermod -aG user42 your_login

Step R3: Verify SELinux

Rocky uses SELinux instead of AppArmor. The subject requires SELinux to be running at startup:

# Check SELinux status
getenforce          # must return "Enforcing"
sestatus            # detailed status

# If not enforcing, enable it:
sudo nano /etc/selinux/config
# Set: SELINUX=enforcing
sudo reboot

Note: KDump is explicitly not required for Rocky by the subject.

Step R4: Configure firewalld (instead of UFW)

Rocky uses firewalld as its firewall:

# Start and enable firewalld
sudo systemctl start firewalld
sudo systemctl enable firewalld

# Add SSH on port 4242
sudo firewall-cmd --permanent --add-port=4242/tcp
sudo firewall-cmd --reload

# Verify
sudo firewall-cmd --list-ports
sudo firewall-cmd --list-all

Step R5: SSH, sudo, password policy (same as Debian)

Setting Debian Rocky
SSH config /etc/ssh/sshd_config Same
sudo config visudo -f /etc/sudoers.d/sudoconfig Same
Password aging /etc/login.defs Same
Password complexity /etc/pam.d/common-password /etc/pam.d/system-auth and /etc/pam.d/password-auth
PAM quality module libpam-pwquality (apt) libpwquality (dnf) 
# Install password quality module
dnf install libpwquality -y

# Rocky uses /etc/security/pwquality.conf instead of pam args
nano /etc/security/pwquality.conf
# Add or uncomment:
# minlen = 10
# dcredit = -1
# ucredit = -1
# lcredit = -1
# maxrepeat = 3
# difok = 7

# Password aging in /etc/login.defs works identically
PASS_MAX_DAYS   30
PASS_MIN_DAYS   2
PASS_WARN_AGE   7

# Apply to existing users
chage -M 30 -m 2 -W 7 your_login
chage -M 30 -m 2 -W 7 root

Step R6: Generate signature.txt (same process)

# Linux host
sha1sum ~/VirtualBox\ VMs/Rocky_Born2beroot/Rocky_Born2beroot.vdi

Apply the same duplication/save-state strategy described in Step 13.

Verification Checklist

Use this checklist before evaluation to ensure everything is configured correctly.

System

  • VM boots without errors
  • No graphical interface is installed
  • Hostname is your_login42
  • No snapshots exist

Users

  • Root user exists
  • Your login user exists
  • Your user is in sudo group
  • Your user is in user42 group
  • Can create a new user during evaluation

SSH

  • SSH service is running
  • SSH listens on port 4242
  • Root login via SSH is denied
  • Can connect via ssh your_login@localhost -p 4242

UFW

  • UFW is active
  • Only port 4242 is open
  • Rules persist after reboot

AppArmor

  • AppArmor is running
  • Profiles are in enforce mode

Password Policy

  • PASS_MAX_DAYS is 30
  • PASS_MIN_DAYS is 2
  • PASS_WARN_AGE is 7
  • Password requires 10+ chars
  • Password requires uppercase, lowercase, digit
  • Max 3 consecutive identical chars
  • Password cannot contain username
  • Root password follows the same rules

sudo

  • passwd_tries is 3
  • Custom badpass message is set
  • I/O logging is enabled
  • Logs go to /var/log/sudo/
  • requiretty is enabled
  • secure_path is restricted
  • visudo config is valid

Partitioning

  • At least 2 encrypted partitions using LVM
  • LUKS encryption is active
  • LVM is displayed by lsblk

Monitoring

  • monitoring.sh exists and is executable
  • Script runs via cron every 10 minutes
  • Script runs at server startup
  • Script uses wall to display information
  • Can stop it without modifying the script

Repository

  • README.md exists
  • signature.txt exists with correct hash

Evaluation Questions

During the defense, you will be asked questions about your choices and understanding. Here are common questions with concise, interview-ready answers.

What is virtualization?

Virtualization is a technology that allows multiple virtual machines to run on a single physical computer. A hypervisor manages access to the physical hardware and isolates each VM. This improves hardware utilization, reduces costs, and provides isolation between systems.

What is a hypervisor?

A hypervisor (or Virtual Machine Monitor) is the software layer that creates, runs, and manages virtual machines. It sits between the physical hardware and the VMs, allocating resources and ensuring isolation.

What is the difference between Type 1 and Type 2 hypervisors?

Type 1 hypervisors run directly on the physical hardware without an underlying OS (e.g., VMware ESXi). Type 2 hypervisors run as an application on top of an existing OS (e.g., VirtualBox). Type 1 offers better performance and is used in data centers; Type 2 is easier to use and ideal for learning.

What is KVM?

KVM (Kernel-based Virtual Machine) is a virtualization module built into the Linux kernel. It turns Linux into a Type 1-like hypervisor by using hardware virtualization extensions (Intel VT-x/AMD-V). It powers many enterprise and cloud platforms.

What is the difference between apt and aptitude?

Both are package managers for Debian. apt is the modern, command-line-focused tool that is installed by default and used in most documentation. aptitude is a higher-level tool with better dependency resolution and an interactive text interface. For Born2beroot, apt is the preferred choice.

What is LVM?

LVM (Logical Volume Manager) is a storage management layer that provides flexible disk management. It consists of Physical Volumes (PVs), Volume Groups (VGs), and Logical Volumes (LVs). LVM allows resizing, snapshots, and pooling of multiple disks.

What is a Physical Volume? What is a Volume Group?

A Physical Volume is a storage device (disk or partition) initialized for use by LVM. A Volume Group is a pool of storage created by combining one or more Physical Volumes. Logical Volumes are then allocated from this pool.

What is LUKS?

LUKS (Linux Unified Key Setup) is the standard for Linux disk encryption. It manages encryption keys and protects data at rest. LUKS uses symmetric encryption (typically AES) and supports multiple passphrases through key slots.

What is the difference between symmetric and asymmetric encryption?

Symmetric encryption uses the same key to encrypt and decrypt (e.g., AES). It is fast and used for encrypting data at rest. Asymmetric encryption uses a public/private key pair (e.g., RSA). It is slower and used for key exchange, SSH, and digital signatures. LUKS uses symmetric encryption; SSH uses both types.

What happens during an SSH connection?

  1. Client connects to server on port 22 (or 4242)
  2. Server identifies itself with its host key
  3. Client and server establish a shared symmetric session key using Diffie-Hellman key exchange
  4. Client authenticates (password or public key)
  5. Encrypted session begins

Why disable root login via SSH?

The root username is known, so attackers only need the password. Root has unrestricted privileges, so compromise causes maximum damage. Logging in as a regular user and using sudo provides accountability through logs.

What is AppArmor?

AppArmor is a Mandatory Access Control (MAC) system that confines programs to a limited set of resources. It uses profiles to define what files, network, and capabilities a program can access. Profiles run in enforce or complain mode.

What is the difference between AppArmor and SELinux?

Both are MAC systems. AppArmor is path-based (simpler) and default on Debian/Ubuntu. SELinux is label-based (more granular but complex) and default on RHEL/Rocky/Fedora.

What is PAM?

PAM (Pluggable Authentication Modules) is a framework for authentication on Linux. It allows administrators to configure authentication methods independently of applications. PAM modules control password complexity, account expiration, session management, and more.

Why use sudo instead of logging in as root?

sudo provides granular control over who can run which commands, logs all privileged actions for accountability, uses the user's password (not root's), and keeps the user's environment. This follows the principle of least privilege.

Why use a firewall?

A firewall controls incoming/outgoing network traffic based on security rules. It reduces the attack surface by only allowing necessary ports (e.g., 4242 for SSH) and blocks all unauthorized access attempts.

Why does the monitoring script use wall?

The wall (write all) command displays a message on all terminals of all logged-in users. This ensures that system information is visible regardless of which TTY the evaluator is viewing.

How does cron work?

Cron is a time-based scheduler. The cron daemon checks crontab files for scheduled commands and executes them at the specified times. The syntax is: minute hour day month weekday command.

How can you stop the monitoring script without modifying it?

Stop the cron daemon with sudo systemctl stop cron. This prevents all scheduled jobs from running. Alternatively, comment out the lines in root's crontab with sudo crontab -e.

Practical evaluation scenarios

Changing the hostname

Evaluators will ask you to change the hostname to verify you understand how it works:

# 1. Check current hostname
hostnamectl

# 2. Set new hostname (your login + 42)
sudo hostnamectl set-hostname yourlogin42

# 3. Update /etc/hosts to match
sudo nano /etc/hosts
# Change: 127.0.1.1  oldname → 127.0.1.1  yourlogin42

# 4. Verify
hostnamectl
hostname

# 5. Reboot to confirm persistence
sudo reboot

After reboot, reconnect via SSH and verify the prompt shows the new hostname.

Creating a new user and assigning to a group

The subject states: "During the defense, you will have to create a new user and assign it to a group."

# 1. Create user with home directory and bash shell
sudo useradd -m -s /bin/bash evaluator

# 2. Set a password (must follow your password policy!)
sudo passwd evaluator

# 3. Add to a group
sudo usermod -aG sudo evaluator   # grant sudo access
# or
sudo usermod -aG user42 evaluator # project-specific group

# 4. Verify
id evaluator
groups evaluator

# 5. Test (if added to sudo)
su - evaluator
sudo whoami    # should print "root"

Useful Commands

System Information

uname -a                 # All system info
hostnamectl              # Hostname details
lscpu                    # CPU information
free -h                  # Memory usage
df -h                    # Disk usage
lsblk                    # Block devices
blkid                    # Block device attributes

Service Management

sudo systemctl status <service>   # Check service status
sudo systemctl start <service>    # Start a service
sudo systemctl stop <service>     # Stop a service
sudo systemctl restart <service>  # Restart a service
sudo systemctl reload <service>   # Reload configuration
systemctl list-units             # List all units

User Management

id <username>              # User info
groups <username>          # User's groups
sudo useradd -m <user>    # Create user
sudo passwd <user>         # Set password
sudo usermod -aG <group> <user>  # Add user to group
sudo userdel -r <user>    # Delete user + home

Network

ss -tlnp                   # Listening ports
ip a                       # IP addresses
ip link show               # Network interfaces
hostname -I                # IP address
ping -c 4 localhost        # Test connectivity

Security

sudo ufw status            # Firewall status
sudo aa-status             # AppArmor status
sudo chage -l <user>       # Password aging info
sudo sudoreplay -l         # List sudo logs
journalctl | grep sudo     # View sudo commands

Logs

journalctl -xe             # System logs
sudo tail -f /var/log/syslog  # System log
ls -la /var/log/sudo/      # Sudo I/O logs
dmesg                      # Kernel messages

Troubleshooting

SSH Issues

Cannot connect to SSH

# Check SSH service
sudo systemctl status ssh

# Check port
ss -tlnp | grep 4242

# Check firewall
sudo ufw status

# Check SSH config
sudo grep -E "Port|PermitRootLogin" /etc/ssh/sshd_config

Permission denied (publickey)

# Check authorized_keys permissions
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

# Ensure SSH allows key auth
sudo grep PubkeyAuthentication /etc/ssh/sshd_config

Firewall Issues

Locked out after enabling UFW

If you enabled UFW before allowing SSH:

# From the VM console (not SSH)
sudo ufw allow 4242

UFW won't enable

Check for conflicts with other firewall tools:

sudo ufw disable
sudo ufw reset
sudo ufw enable

sudo Issues

User is not in sudoers file

Boot in recovery mode or use root:

# As root
usermod -aG sudo your_login

visudo reports syntax error

Always use visudo to edit sudoers files. If locked out:

# Boot in single-user mode
# Or use pkexec
pkexec visudo

Password Policy Issues

Password not enforced for new users

Changes to /etc/login.defs apply only to new users. Use chage for existing users.

PAM password rules not working

# Verify pam_pwquality is installed
dpkg -l | grep pam_pwquality

# Check config
grep pam_pwquality /etc/pam.d/common-password

Monitoring Script Issues

Script runs manually but not via cron

Cron has a limited PATH. Use absolute paths in the script:

#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

wall permission denied

Cron jobs run with root privileges if added to root's crontab. Verify:

sudo crontab -l

Disk/Storage Issues

Check LVM status

sudo pvs
sudo vgs
sudo lvs

Check encryption status

sudo dmesg | grep crypt
sudo cryptsetup status sda5_crypt

Evaluation Issues

Snapshot detected

The subject forbids snapshots. Remove them before evaluation:

# In VirtualBox Manager: Right-click VM → Snapshots → Delete all

Signature mismatch

After evaluation, the VM signature may change. To preserve:

  • Use Save State instead of powering off
  • Or duplicate the VM before evaluation
  • Generate a new signature.txt if necessary

Resources

Virtualization

Resource Description
IBM: What is Virtualization? Comprehensive introduction to virtualization concepts
IBM: What is a Hypervisor? Detailed explanation of hypervisors and their types
VMware: Bare Metal Hypervisor Deep dive into Type 1 hypervisors
Red Hat: What is KVM? KVM virtualization explained

Storage

Resource Description
Wikipedia: LVM Comprehensive LVM reference
Linux Handbook: LVM Guide Practical LVM tutorial with examples
EaseUS: Logical vs Primary Partition Clear explanation of partition types

Package Management

Resource Description
Packagecloud: apt vs aptitude In-depth comparison

Security & Encryption

Resource Description
Medium: Symmetric and Asymmetric Encryption Clear explanation of encryption types
DigitalOcean: Understanding SSH Encryption Complete guide to SSH encryption and connection process
SSH.com: sshd SSH server process documentation
OSTechNix: Password Policies in Linux Guide to configuring password policies

Firewall

Resource Description
DigitalOcean: UFW Essentials Common UFW commands and rules
DigitalOcean: iptables Essentials iptables firewall rules reference

About

A system administration project focused on creating and securing a Linux virtual machine using Debian, implementing user management, SSH configuration, firewall rules, sudo policies, LVM partitioning, and automated system monitoring.

Resources

Readme
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors