CISS.2024.bookworm.installation

Overview

• A) Preliminary remarks
  • 1) Excursion: Benefits of Full Disk Encryption
  • 2) Excursion: Advanced physical boot loader hardening
• B) Prerequisites
  • a) Partitioning scheme: Standard
  • b) Partitioning scheme: Ephemeral Swap
  • 1) Excursion: Generate a strong SSH public/private key pair
  • 2) Excursion: Example Netcup VPS Settings
    • I) Netcup-Server-Control-Panel
    • II) Netcup VPS Preparation
• E) Main Debian Bookworm installation
  • 1) Setup selection
  • 2) Keyboard considerations
  • 3) Installer components
    • I) Excursion: Explanation of common Netinstaller Modules
  • 4) User preparation
  • 5) Partition disks
    • I) Excursion: Boot Partiton considerations
  • 6) Final installation steps
  • 7) Further preparation
• F) Next steps
• G) Changelog

A) Preliminary remarks

For those new to Linux, this tutorial shows how to set up a minimal environment that is ideally prepared to run the CISS.2024.vpn.bookworm.hardening script.

It is important to keep track of the proposed partitioning scheme. Surely it is not most important to follow the exact steps to reproduce the suggested partitioning scheme – with or without Full Disk Encryption (FDE), with or without Logical Volume Manager (LVM), or with or without an underlying RAID setup, either hardware-based or software-based – as long as the suggested partitions are available for the CISS.2024.vpn.bookworm.hardening script.

Obviously, an FDE setup will only protect data at rest. However, in the event that the entire hard drive is stolen or seized by law enforcement, a strong FDE setup will protect your data from further offline attacks. This part should never be underestimated in your threat model, especially if your server setup is on VPS systems, as creating an image could easily be done by the hosting provider.

Also note that this setup preparation allows you to easily decide later by running the CISS.2024.vpn.bookworm.hardening script to also encrypt the /boot partition so that with a possible secure boot setup the whole boot chain UEFI – GRUB2 – ESP – initramfs – kernel could be secured to detect malicious kernels and protect the whole setup from eval-maid attacks with final steps to sign your own backed kernel and in case you are running servers with physical access you should consider – if this is your threat model – to also keep your kernel on a separate USB stick or better on a non-rewritable media like a CD-ROM.

1) Excursion: Benefits of Full Disk Encryption

The implementation of Full Disk Encryption (FDE) and the division of the file system into separate, encrypted partitions is an essential step towards hardening a Debian server.

Background and goals

1. Data protection and integrity:
   • Full Disk Encryption (FDE): Protects the data on the hard drive by fully encrypting it when not in use. This prevents unauthorised access to stored data, even if the hard disk is physically removed.
   • Encrypted SWAP partition: Ensures that temporary data written to SWAP memory is also encrypted, reducing the risk of confidential information being stored in plain text.
2. Fine-grained access and error isolation:
   • Separate partitions for important directories: This enables targeted control and management of access rights and quotas for different file system areas. It also helps to isolate errors so that a problem in one directory does not affect the entire system.

Directory partitioning

• /root: Contains administrative and system configuration files. Separate encryption protects critical system information.
• /home: Contains user files. Separate partitions make it possible to isolate and protect user files.
• /var: Contains variable data such as log files, databases and spool directories. A separate partition prevents log files from overfilling the file system.
• /usr: Contains user-specific binary files and libraries. A separate partition protects system applications and libraries from manipulation.
• /tmp: Temporary files. A separate partition prevents temporary files from cluttering up the file system and enables automatic deletion on restart.
• /var/tmp: Temporary files that should survive system reboots. A separate partition offers similar advantages to /tmp.
• /var/log: System and application logs. A separate partition protects logs from manipulation and data loss.
• /var/log/audit: Specific logs for security audits. A separate partition ensures that audit logs are managed and protected separately.

Possible attacks and their defence

1. Physical theft:
   • FDE and encrypted SWAP partition: Prevent access to data if the hard drive is stolen, as it can only be read with the corresponding decryption key.
2. Man-in-the-middle attacks:
   • Encryption and separate partitions: Reduce the risk of attackers being able to read or write unencrypted data during a MitM attack.
3. Rootkits and malware:
   • Separate and encrypted partitions: Make it more difficult for malware to make persistent changes to critical system directories as each partition is protected separately.
4. Log tampering:
   • Separate partitions for /var/log and /var/log/audit: Ensure that log files are protected from tampering and that logs can be backed up separately to ensure integrity.
5. Denial of Service (DoS):
   • Quotas and separate partitions: Prevent an overfilled directory from rendering the entire file system unusable by limiting the amount of space required by directories.
6. Data leaks due to temporary files:
   • Encrypted SWAP and separate /tmp and /var/tmp partitions: Ensure that temporary files are not accessible to unauthorised users and are cleaned up regularly.

Further considerations for full disk encryption

dm-crypt/LUKS is an integral part of the Linux kernel and is well integrated in all Linux distributions. The encryption is also used by governments and intelligence agencies to protect confidential and secret data. dm-crypt/LUKS is FIPS-2 certified, is regularly evaluated by the BSI and is authorised in Germany and NATO for the storage of data up to VS-GEHEIM (however, from VS-NfD only with hardware tokens as access protection and not with passwords).
dm-crypt/LUKS encrypts block devices (hard drive partitions, USB sticks or image files) and works completely transparently. Up to 8 different passphrases + key data can be defined as credentials for accessing a container. Veracrypt containers can also be opened.

https://privacy-handbuch.de/handbuch_37a.htm

SWAP size considerations

The size of the swap file under Debian (or Linux in general) depends on the size of the physical RAM and the specific requirements of your system. Historically, general guidelines have been developed that make recommendations based on the amount of RAM installed.

General recommendations

1. Systems with little RAM (< 2 GB):
   • Recommended swap size: 2 to 2.5 times the size of the RAM.
   • Example: For a system with 1 GB RAM, a swap file of 2 to 2.5 GB is recommended.
2. Systems with moderate RAM (2 GB to 8 GB):
   • Recommended swap size: 1 to 1.5 times the size of the RAM.
   • Example: For a system with 4 GB RAM, a swap file of 4 to 6 GB is recommended.
3. Systems with a lot of RAM (8 GB to 64 GB):
   • Recommended swap size: equal to or slightly larger than the installed RAM.
   • Example: For a system with 16 GB RAM, a swap file of 16 to 24 GB is recommended.
4. Systems with a lot of RAM (> 64 GB):
   • Recommended swap size: 0.5 to 1 times the size of the RAM.
   • Example: For a system with 128 GB RAM, a swap file of 64 to 128 GB is recommended.

Additional considerations

• Hibernate:
  • If you plan to use hibernate mode, the swap size should be at least as large as the installed RAM, as the contents of the RAM will be written to the swap file.
  • Example: For a system with 16 GB RAM that is to use Hibernate, the swap file should be at least 16 GB in size.
• Workloads and applications:
  • Consider the type of workloads and applications running on your system. Some memory-intensive applications (such as databases or virtual machines) may benefit from a larger swap file.
• Performance:
  • While swap is useful for providing additional memory, accessing swap is slower than accessing RAM. Therefore, do not rely solely on swap for storage requirements. It is better to have sufficient physical RAM.

2) Excursion: Advanced physical boot loader hardening

Using a remote boot stick like a CD-ROM or USB stick with a signed kernel and boot loader and implementing UEFI Secure Boot offers several security advantages and can defend against certain attacks.

Advantages

1. Integrity and authenticity:
   • Signing the kernel and boot loader with a dedicated key ensures that only authentic, non-tampered software is executed.
   • UEFI Secure Boot checks the signatures at system startup and prevents the loading of unsigned or manipulated software.
2. Physical security:
   • The swapped-out boot stick can be kept physically secure and only used when needed, reducing the risk of physical tampering with the boot media.
3. Easy recovery:
   • In the event of a compromised system, the boot stick can be quickly replaced or recreated, simplifying system recovery.

Defenced against attacks

1. Bootkit attacks:
   • Bootkits manipulate the boot loader or operating system during the boot process to load malicious code. Secure Boot prevents such attacks by only allowing signed boot loaders and kernels.
2. Rootkit attacks:
   • Rootkits are malicious software that is deeply embedded in the system and difficult to detect and remove. A signed kernel and secure boot prevent the loading of unsigned kernel modules and drivers, which effectively wards off rootkits.
3. Firmware tampering:
   • Attackers could try to manipulate the firmware to execute malicious code at system boot. UEFI Secure Boot protects against such attacks, as only signed firmware components are loaded.
4. Man-in-the-middle attacks during booting:
   • Signing the boot loader and kernel ensures that no malicious changes have been made to these components, even if an attacker had physical access to the system.
5. Boot media tampering:
   • A swapped out boot stick can be physically removed and stored securely if required, minimising the risk of tampering with the boot media.
6. Malware installation:
   • Attackers attempting to install malware by tampering with the boot process are prevented from doing so as Secure Boot only allows signed software to be loaded.

B) Prerequisites

• VPS amd64 for example from Hetzner, Netcup (both preferred for their web console access). Netcup is used in this tutorial.
• For Netcup: UEFI mode enabled.
• For Netcup: Change hard disk driver to recommended SCSI.
• SSH public key for root user.
• All partitions mentioned in any of the following partitioning schemes are formatted with the ext4 journalling filesystem to be fully compatible with the CISS.2024.vpn.bookworm.hardening script.
• Please select one of the following partitioning schemes: Standard or Ephemeral Swap

a) Partitioning scheme: Standard

NAME                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                        8:0    0   512G  0 disk
├─sda1                     8:1    0   3.7G  0 part
├─sda2                     8:2    0   3.7G  0 part  /boot/efi
├─sda3                     8:3    0   3.7G  0 part  /boot
└─sda4                     8:5    0 485.9G  0 part
  └─sda4_crypt           254:0    0 485.9G  0 crypt
    ├─vg00-home          254:1    0  59.6G  0 lvm   /home
    ├─vg00-root          254:2    0  59.6G  0 lvm   /
    ├─vg00-swap          254:3    0  14.9G  0 lvm   [SWAP]
    ├─vg00-tmp           254:4    0  14.9G  0 lvm   /tmp
    ├─vg00-var           254:5    0 119.2G  0 lvm   /var
    ├─vg00-var_log       254:6    0  14.9G  0 lvm   /var/log
    ├─vg00-var_tmp       254:7    0  14.9G  0 lvm   /var/tmp
    ├─vg00-var_log_audit 254:8    0  14.9G  0 lvm   /var/log/audit
    └─vg00-usr           254:9    0   173G  0 lvm   /usr

b) Partitioning scheme: Ephemeral Swap

NAME                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                        8:0    0   512G  0 disk
├─sda1                     8:1    0   3.7G  0 part
├─sda2                     8:2    0   3.7G  0 part  /boot/efi
├─sda3                     8:3    0   3.7G  0 part  /boot
├─sda4                     8:4    0  14.9G  0 part
│ └─swap                 254:10   0  14.9G  0 crypt [SWAP]
└─sda5                     8:5    0 485.9G  0 part
  └─sda5_crypt           254:0    0 485.9G  0 crypt
    ├─vg00-home          254:1    0  59.6G  0 lvm   /home
    ├─vg00-root          254:2    0  59.6G  0 lvm   /
    ├─vg00-tmp           254:4    0  14.9G  0 lvm   /tmp
    ├─vg00-var           254:5    0 119.2G  0 lvm   /var
    ├─vg00-var_log       254:6    0  14.9G  0 lvm   /var/log
    ├─vg00-var_tmp       254:7    0  14.9G  0 lvm   /var/tmp
    ├─vg00-var_log_audit 254:8    0  14.9G  0 lvm   /var/log/audit
    └─vg00-usr           254:9    0   173G  0 lvm   /usr

In this scheme, just prepare the volume,

but do not mount the swap area,

as this will be done by the CISS.2024.vpn.bookworm.hardening script afterwards.

1) Excursion: Generate a strong SSH public/private key pair

The command

ssh-keygen -o -a 768 -t ed25519 -C "your_comment_here"

is used to generate a new SSH key pair.

• ssh-keygen: The command to generate a new SSH key pair.
• -o: This option enforces the new OpenSSH key file format, which is more secure than the older PEM format. This format uses bcrypt to encrypt private keys, which makes it more resistant to brute force attacks.
• -a 768: This option specifies the number of bcrypt KDF (Key Derivation Function) rounds used to encrypt the private key. A higher number of rounds increases security as it requires more computing power to crack the key. The default value for bcrypt-KDF rounds is 16; 768 is a very high value that further increases security, but also slows down key generation and utilisation.
• -t ed25519: This option specifies the type of key to be generated. ed25519 is a modern, secure and efficient elliptic curve used for SSH keys. It offers a high level of security and better performance compared to RSA keys.

Security considerations

1. Key file format (-o): The modern OpenSSH format is more secure than the old PEM format.
2. bcrypt rounds (-a 768): A high value such as 768 significantly increases security as it increases the time and computing power for brute force attacks.
3. Key type (-t ed25519): Ed25519 is favoured for its security and efficiency and is a good choice for modern SSH keys.

2) Excursion: Example Netcup VPS Settings

i) Preface: Netcup Server Control Panel

For security reasons, please change the access to the Server Control Panel only from the Netcup Customer Control Panel and enable 2FA in the Customer Control Panel. Log in to your Customer Control Panel, go to Stammdaten and enable 2FA:

Next, log into your Server Control Panel, head to Options, Settings and enable Secure Access Mode:

II) Netcup VPS Preparation

While still in the Server Control Panel, select your VPS, go to Media and select the recommended SCSI driver:

On the same tab, select Format Hard-drives and click Format Hard-drives irreparably:

Next, select Settings and do the following

• Select your preferred keyboard layout. Remember your choice in case you choose to enable the GRUB2 boot loader password settings when you run the CISS.2024.vpn.bookworm.hardening script later and/or /boot encryption.
• Enable UEFI boot.

Always click Save to apply the changed settings.

Last step. Go to Network and add any additional Ethernet adapters, for example if you have Netcup VLAN enabled. This tab is also used to set up the rDNS records and IPv6. The following IPv6 convention is used and suggested:

• Consider your IPv4 to be: 123.123.123.123
• Consider your IPv6 prefix to be: 2a10:ABCD:1111:FFFF::1/64
• Then the server IPv6 is as follows 2a10:ABCD:1111:FFFF:123:123:123:123/128

Finally, go to Control and click on Power Cycle. After a few seconds the VPS will be back on and you can log into the web console (KVM) by selecting _Screen, which is always present in the Server Control Panel menu on the left.

E) Main Debian Bookworm installation

1) Setup selection

After booting from CD-ROM or the boot media, please select Advcande options ...

then continue with ... Graphical expert install

2) Keyboard considerations

Be careful to choose the right keyboard layout, and remember that for GRUB2 password selection and/or /boot encryption, the early bootloader only supports the US keyboard layout (without manual override, which is not very well documented).

3) Installer components

Now, select the installer components to be loaded:

It is good practice to select only the necessary components to minimise the attack surface, for example in this case:

• choose-mirror
• crypto-dm-modules
• fdisk-udeb
• network-console
• openssh-client-udeb
• parted-udeb
• rescue-mode

I) Excursion: Explanation of common Netinstaller Modules

choose-mirror

• When Needed: During the installation process when you need to select a Debian mirror from which to download additional packages.
• What It Is Good For: Allows the installer to download the latest packages from a chosen mirror, ensuring that you get the most up-to-date software and security patches.

crypto-dm-modules-6.1.0-18-amd64-di

• When Needed: When you need support for device-mapper cryptographic target modules, typically for setting up encrypted partitions.
• What It Is Good For: Provides support for disk encryption, ensuring that data stored on the disk is protected from unauthorized access.

fdisk-udeb

• When Needed: When manually partitioning disks during installation.
• What It Is Good For: Provides the fdisk utility in the installer environment, allowing for manual partitioning of hard drives.

load-media

• When Needed: When additional installation media needs to be loaded during the installation process.
• What It Is Good For: Allows the installer to load additional packages or drivers from external media, such as USB drives or CDs, which might be necessary if the default packages are insufficient.

lowmem

• When Needed: When installing Debian on systems with very limited RAM.
• What It Is Good For: Provides a set of tools and scripts to help reduce memory usage during installation, enabling Debian to be installed on systems with low memory.

mdr-udeb

• When Needed: When RAID support is required during the installation process.
• What It Is Good For: Provides support for configuring RAID (Redundant Array of Independent Disks) setups during installation, allowing for the creation of RAID arrays.

nbd-modules-6.1.0-18-amd64-di

• When Needed: When Network Block Device (NBD) support is required during installation.
• What It Is Good For: Provides support for using network block devices, enabling the installation process to access remote disk storage over the network.

network-console

• When Needed: When remote installation or recovery via SSH is desired.
• What It Is Good For: Enables an SSH server in the installer environment, allowing the installation process to be controlled remotely via an SSH client.

openssh-client-udeb

• When Needed: When SSH client functionality is required in the installer environment.
• What It Is Good For: Provides an SSH client, enabling secure access to remote systems from within the installer environment.

parted-udeb

• When Needed: When flexible partitioning options are needed during installation.
• What It Is Good For: Provides the GNU Parted utility in the installer environment, offering advanced partitioning capabilities.

rescue-mode

• When Needed: When the system needs to be repaired or recovered.
• What It Is Good For: Provides a rescue mode in the installer, allowing for various system recovery and repair tasks, such as fixing boot issues or recovering lost data.

4) User preparation

As you can see, the selection of installer menu items has changed. Continue with the following steps

• Detect network hardware
• Configure the network
• Remote installation via SSH
• Choose a mirror

Then proceed to Set up users and passwords.

If you use the CISS.2024.vpn.bookworm.hardening setup script afterwards, it may not be necessary to set up a normal user, as this will be done by the script. In this case, a normal root user is sufficient. Choose a strong password of at least 24 alphanumeric characters or an equivalent strong passphrase, for the brief moment during the installation process. The generated public key will be transmitted shortly after the installation process. Please note that the CISS.2024.vpn.bookworm.hardening setup script disables password root login via SSH and only accepts public key authentication plus additional hardening best practices are set up so there is no need to worry about a root login via SSH as it is practiced in this tutorial.

5) Partition disks

Since we have chosen UEFI for this tutorial, the following unencrypted Partitions must be created:

• BIOS (only in case of dual-boot setup)
• EFI system partition or ESP
• /boot partition

I) Excursion: Boot Partiton considerations

In a UEFI environment, all necessary data and firmware information that was previously stored in a BIOS partition is stored in the EFI System Partition. The EFI System Partition is a special partition on the hard drive that serves as a storage location for the UEFI firmware files, boot loader and other system files that are necessary for booting and operating the system.

1. EFI System Partition (ESP):
   • This partition contains the UEFI firmware files and boot loaders.
   • It has a fixed partition ID (0xEF00) and a standardised file system (normally FAT32).
2. No need for additional BIOS partition:
   • No traditional BIOS partitions are used in UEFI systems.
   • All necessary firmware and boot information is stored in the ESP.
3. UEFI and GPT:
   • UEFI systems normally use the GPT (GUID Partition Table) partition scheme.
   • GPT allows for a larger number of partitions and better support for modern storage technologies.

To summarise, in a pure UEFI configuration, the EFI system partition is sufficient and no additional BIOS partition is required.

Dual Boot / Hybrid Mode

An EFI System Partition (ESP) and a BIOS partition would be necessary if a system offers both UEFI and legacy BIOS support, i.e. if it is operated in the so-called CSM mode (Compatibility Support Module).

1. Dual boot configurations with UEFI and Legacy BIOS:
   • If a system is configured to boot in both UEFI and Legacy BIOS modes (dual-boot), both partitions might be required.
   • In such a scenario, a partition table could contain both an EFI system partition (for UEFI) and a BIOS boot partition (for legacy BIOS).
2. Hybrid systems or upgrades:
   • If an older system that was originally installed in legacy BIOS mode is upgraded to UEFI, it may be necessary to have both partitions to ensure compatibility and functionality.
   • Such systems may require a BIOS boot partition (containing boot loader files for the legacy BIOS) and an EFI system partition (containing UEFI firmware files).

Detailed explanations of the partitions:

• EFI System Partition (ESP):
  • Contains the boot loader files and UEFI firmware files.
  • Is used in UEFI systems and requires a FAT32 file system.
  • Has a fixed partition ID of 0xEF00.
• BIOS boot partition:
  • Also referred to as „BIOS Boot Partition“ or „BIOS Boot Area.“
  • Is required on GPT-formatted drives if the system boots in legacy BIOS mode.
  • Contains stage 1.5 of the GRUB boot loader or other boot code stored in the first sectors of the hard drive.
  • Normally has no file systems (unmounted) and a partition ID of 0xEF02.

Example of partition table in a dual boot setup:

1. EFI System Partition (ESP) (e.g. 100-200 MB, FAT32, Partition ID: 0xEF00)
2. BIOS boot partition (e.g. 1-2 MB, without file system, partition ID: 0xEF02)
3. Further partitions for operating systems and data.

Boot partition size considerations

The size of the EFI System Partition (ESP) depends on various factors, including the number and size of kernel images, boot loaders and other system files that are stored on the partition. In general, the ESP should be large enough to hold all necessary files and allow for future growth. Here are some recommendations based on current best practices and various scenarios:

General recommendations:

1. Minimum size:
   • A minimum size of 100 MB is often recommended as an absolute minimum, especially for simple setups without many additional kernel images or boot loaders.
2. Recommended size for typical setups:
   • 500 MB is a commonly recommended size for most standard setups. This size provides enough space for several kernel images and boot loader files.
3. Recommended size for advanced setups:
   • 1 GB or more is recommended if you plan to store many kernel images, boot loaders and other system files. This size provides sufficient buffer for future growth and software updates.

Specific scenarios:

1. Systems with multiple operating systems:
   • If the system supports multiple operating systems (e.g. dual-boot or multi-boot), it may make sense to use a larger ESP of 1-2 GB to have enough space for the boot loaders and kernel images of all installed operating systems.
2. Server environments with many kernel updates:
   • In server environments where kernel updates are performed frequently, a larger ESP of 1-4 GB may be useful to ensure that there is enough space for old and new kernel images.
3. Future-Proofing:
   • For future expansions and to ensure that no memory problems occur, a size of 2-4 GB can be selected. This is particularly important in environments where there is a lot of experimentation or many different boot configurations are tested.

Summary of recommendations:

• 100 MB: Absolute minimum, suitable for simple setups.
• 500 MB: Recommended for most standard setups.
• 1 GB: Useful for advanced setups and systems with multiple operating systems.
• 2-4 GB: Recommended for server environments with many kernel updates and for future expansions.

Please select Partition disks :

And then select Manual:

formatted Hard Drive

If you have formatted the drive in this specific tutorial using the Netcup Server Control Panel, proceed here. Otherwise continue with the setup for existing partitions. Click on the hard disk to set up the partition table:

Select Yes to create the partition table and click Continue:

Select gpt as the partition table and click Continue:

Existing Partitions

If partitions already exist, delete them by clicking on the partition. Select Delete from the next menu.

If all existing partitions have been deleted, create new partitions by clicking on FREE SPACE and selecting Create new partition from the new menu:

Create a EFI System Partition named for example ESP, this partition is automatically flagged as Bootable. Click Done setting up the parttion:

Create a /boot partition named e.g. boot, select your desired filesystem, ext4 journalling filesystem is a good recommendation, especially if you are going to enable the SELinux security extensions later in the CISS.2024.vpn.bookworm.hardening script. Click Done setting up the parttion:

Ephemeral Swap Setup

If you are going to use the CISS.2024.vpn.bookworm.hardening script and opt in to the ephemeral swap setup, create the partition that will hold the encrypted ephemeral swap partition now. Bear this in mind: Do not create an additional swap space inside LVM later. Do not mount this partition yet, just leave it unmounted:

If you are prompted in the final partition setup routine that there is no swap space mounted, just ignore the message:

Create the physical partition for the encrypted setup by creating a new partition and selecting Physical volume for encryptionthen click Done setting up the parttion.

Please note the following established naming scheme:

• Prefix „crypt“: The names of dm-crypt encrypted partitions often begin with the prefix „crypt“.
• Name: The „crypt“ prefix is followed by a descriptive name that describes the content or function of the encrypted partition. This name can contain letters, numbers and hyphens.
• Number: If required, a consecutive number can be added to distinguish several encrypted partitions with the same name.

Example:

• crypt_home
• crypt_data
• crypt_volume1

This naming scheme makes it easier to identify and manage encrypted partitions, especially in complex system environments with multiple encrypted data stores. It is important to remain consistent and use clear naming conventions for encrypted partitions to enable efficient management and troubleshooting.

In the next menu, it is not a good idea to change the default settings unless you know exactly what you are doing, as improperly selected settings will definitely weaken the full disk encryption setup.

Normally it is also not necessary to select Erase data unless you have very specific security requirements, such as deniable encryption.

Back in the main partition menu, continue with Configure encrypted volumes, then select Create encrypted volumes and click Continue:

In the menu that appears, select the physical volume for encryption you created earlier and click Continue:

In the next menu, select Finish and click Continue:

You will be prompted to enter your passphrase. Click Continue to proceed:

You can now Configure the Logical Volume Manager:

First, create a volume group and select the /dev/mapper of your previously created encrypted partition from the menu that appears.

A common naming scheme has been established for the designation of LVM (Logical Volume Manager) groups under Linux. LVM groups are typically named according to the following scheme:

• Prefix „vg“: All LVM group names typically begin with the prefix „vg“ (for volume group).
• Name: The prefix „vg“ is followed by a meaningful name that describes the function or purpose of the volume group. This name can consist of letters, numbers and, if necessary, hyphens.
• Number: If several volume groups could have the same name, a consecutive number is added to distinguish them.

Example

• vg01
• vg_data
• vg_storage01

This naming scheme helps administrators to clearly identify and manage volume groups, especially in environments with multiple LVM-based storage configurations. It is important to remain consistent and use clear naming conventions for managing LVM groups.

Now that you have created the logical volume group, it is time to create the final logical volumes that will be mounted in the next step. The following volumes should be created:

• – home
• – root
• – swap
• – usr
• – tmp
• – var
• – var_log
• – var_tmp
• – var_log_audit

The final step is to prepare all the created volumes for formatting, either for ext4 in our example, or as a swap in our LVM-on-dm-crypt setup.

To do this, select each volume you have created and choose Ext4 journaling file system under Use as. Then mount as follows:

Select the volume to edit:

Specify the file system under Use as in our case always ext4. Select the mount point where the volume should be mounted. The mount options will be set to the hardened defaults later by the CISS.2024.vpn.bookworm.hardening script.

If you are not going to use ephemeral swap encryption and just leave it on the encrypted LVM, you will need to select the swap volume and specify the filesystem to swap in this case. No other settings are required for the swap volume.

For all volumes that do not offer pre-defined mount options, such as /var/log, /var/log/audit and /var/tmp just click Enter manually …

… and enter the mount path and click Continue.

After all the volumes have been set up select Finish partitioning and click Continue:

Confirm the settings with Yes and click Continue:

6) Final installation steps

Continue to install the base system and configure the package manager, skip Select and installing software and proceed to install the GRUB boot loader. It is not necessary to force the installation of GRUB into the EFI removable media path. Select No and click Continue:

Select Yes to ensure that Debian is automatically booted when the computer is turned on, and click Continue:

As there is no other operating system installed on our machine, you can skip the OS check by selecting No and clicking Continue:

Finally, select Finish the installation and click Continue:

You can confirm the clock settings as the default:

7) Further preparation

Done. Now go back to the server control panel, eject the Netinstaller DVD, switch the VPS off and on again to boot into the new Debian environment.

Log in to the web console and enter the password of the encrypted partition:

Log in to your machine. Check that the SSH server is running:

systemctl status ssh

● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Sun 2024-07-07 16:22:25 UTC; 18min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 5571 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
   Main PID: 5572 (sshd)
      Tasks: 9 (limit: 19152)
     Memory: 10.3M
        CPU: 94ms
     CGroup: /system.slice/ssh.service
             ├─5541 "sshd: root@notty"
             ├─5547 /usr/lib/openssh/sftp-server
             ├─5553 "sshd: root@notty"
             ├─5559 /usr/lib/openssh/sftp-server
             ├─5572 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"
             ├─5582 "sshd: root@pts/0"
             ├─5588 -bash
             ├─5592 systemctl status ssh
             └─5593 less

Then edit the /etc/ssh/sshd_config:

nano /etc/ssh/sshd_config

Change

#PermitRootLogin prohibit-password
#PubkeyAuthentication yes

to

PermitRootLogin yes
PubkeyAuthentication yes

Save and exit. Restart the ssh.service:

systemctl restart ssh

Copy the previously generated public key to the server:

ssh-copy-id -i ~/.ssh/new_key.pub -p <your_port> <user>@123.123.123.123

For security reasons, change the settings in /etc/ssh/sshd_config back to:

PermitRootLogin prohibit-password
PubkeyAuthentication yes

Save and exit. Restart the ssh.service:

systemctl restart ssh

Now try to log in to your server using SSH and public key authentication. If all goes well, log out of the web console. Check that no services have failed to start, and that the partitioning scheme looks like the example below in case of the not selected ephemeral swap scheme:

root@test:~# systemctl status --failed
root@test:~# lsblk
NAME                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                        8:0    0   512G  0 disk
├─sda1                     8:1    0   3.7G  0 part
├─sda2                     8:2    0   3.7G  0 part  /boot/efi
├─sda3                     8:3    0   3.7G  0 part  /boot
├─sda4                     8:4    0  14.9G  0 part
└─sda5                     8:5    0 485.9G  0 part
  └─sda5_crypt           254:0    0 485.9G  0 crypt
    ├─vg00-home          254:1    0  59.6G  0 lvm   /home
    ├─vg00-root          254:2    0  59.6G  0 lvm   /
    ├─vg00-swap          254:3    0  14.9G  0 lvm   [SWAP]
    ├─vg00-tmp           254:4    0  14.9G  0 lvm   /tmp
    ├─vg00-var           254:5    0 119.2G  0 lvm   /var
    ├─vg00-var_log       254:6    0  14.9G  0 lvm   /var/log
    ├─vg00-var_tmp       254:7    0  14.9G  0 lvm   /var/tmp
    ├─vg00-var_log_audit 254:8    0  14.9G  0 lvm   /var/log/audit
    └─vg00-usr           254:9    0   173G  0 lvm   /usr
sr0                       11:0    1  1024M  0 rom
root@test:~#

Now’s the perfect time to take a snapshot of your new server. Shut down the server using

shutdown now

In the Server Control Panel, go to the Media section and select the Snapshots tab.

Enter a few meaningful descriptions, as shown in the screenshot, and start the process by selecting Create Snapshot:

F) Next steps

To harden the new server, it is strongly recommended that you run the CISS.2024.vpn.bookworm.hardening script. Please refer to the following tutorial to proceed with hardening.

G) Changelog

Please consider a donation in support of my free services.

• GitHub
• Patreon
• Twitter
• RSS-Feed