/the-practical-linux-hardening-guide

:zap: This guide details the planning and the tools involved in creating a secure Linux production systems - work in progress.

GNU General Public License v3.0GPL-3.0

The Practical Linux Hardening Guide


Master


"Did you know all your doors were locked?" - Riddick (The Chronicles of Riddick)


Branch License

Created by trimstray and contributors

All suggestions and pull requests are welcome!


💥 Work in progress, just a moment... First, I update a Table Of Content and chapters.

If you want to support another repository containing hardening rules, please see: linux-hardening-checklist - it's a simple checklist with the most important hardening rules.

Table Of Content

Pre install tasks

Physical system security

ℹ️ Introduction

The primary goal of many possible attacks is to stop them where possible, and failing that slow them down so that hopefully someone will notice the attacker tearing apart a system in someone's office.

✴️ Secure rooms

For secure rooms make sure that the walls go beyond the false ceiling, and below the raised floor, large vents should also be covered with bars if possible.

✴️ Monitoring

Monitoring the room with CCTV or wired cameras. It's great way to provide security for your server room or data center. As well as providing video footage of events which may occur - door open events, motion detection or any other sensor event, they also act as a visual deterrent to would be criminals.

Solution for remotely monitoring the temperature ensue proactively notify you when the temperature goes above or below pre-defined thresholds, potentially allowing you to take corrective measures before encountering costly downtime.

✴️ Air conditioning

Computer equipment generates heat, and is sensitive to heat, humidity, and dust, but also the need for very high resilience and failover requirements. Maintaining a stable temperature and humidity within tight tolerances is critical to IT system reliability.

Air conditioning designs for most computer or server rooms will vary depending on various design considerations, but they are generally one of two types: "up-flow" and "down-flow" configurations.

✴️ Fire protection

The fire protection system's main goal should be to detect and alert of fire in the early stages, then bring fire under control without disrupting the flow of business and without threatening the personnel in the facility. Server room fire suppression technology has been around for as long as there have been server rooms.

There are a series of things you need in a fire suppression system:

  • an emergency power off function
  • gas-based suppression system
  • water detection sensors in/on the floor

✴️ Locked racks

All systems should be securely fastened to something with a cable system, or locked in an equipment cage if possible. Case locks should be used when possible to slow attackers down.

✴️ Console security

With physical access to most machines you can simply reboot the system and ask it nicely to launch into single user mode, or tell it to use /bin/sh for init.

✴️ BIOS protection

In the program itself to edit the BIOS settings:

  • only boot from specific drive
  • disable the unused controllers
  • disable the booting from external media devices (USB/CD/DVD)
  • enable BIOS password

You need to protect the BIOS of the host with a password so the end-user won’t be able to change and override the security settings in the BIOS.

Main reasons for password protecting the BIOS:

  • preventing changes to BIOS settings
  • preventing system booting

Because the methods for setting a BIOS password vary between computer manufacturers, consult the computer's manual for specific instructions.

For this reason, it is good practice to lock the computer case if possible. However, consult the manual for the computer or motherboard before attempting to disconnect the CMOS battery.

☑️ Summary checklist

Item True False
Physically secure machine (also outside of a server room) 🔲 🔲
Monitoring server rooms with CCTV or wired cameras 🔲 🔲
Remotely monitoring the temperature 🔲 🔲
Efficient air conditioning solution 🔲 🔲
Efficient fire protection system 🔲 🔲
Locked cage (server case) 🔲 🔲
Physical access to server console 🔲 🔲
Password on the BIOS 🔲 🔲
Disable external media devices 🔲 🔲
Periodic physical inspections 🔲 🔲

Hard disk encryption

ℹ️ Introduction

Disk encryption is focused on securing physical access, while relying on other parts of the system to provide things like network security and user-based access control.

Most of the Linux distributions will allow you to encrypt your disks before installation.

If you use an alternative installation method (e.g. from debootstrap) you can create an encrypted disk manually.

Before this you should to answer the following questions:

  • What part of filesystem do you want to encrypt?
    • only user data
    • user data and system data
  • How should swap, /tmp and other be taken care of?
    • disable or mount as ramdisk
    • encrypt (separately of as part of full)
  • How should encrypted parts of the disk be unlocked?
    • passphrase
    • key file
  • When should encrypted parts of the disk be unlocked?
    • before boot process
    • during boot process
    • mixed above or manually

✴️ Encrypt root filesystem

Unlocked during boot, using passphrases or USB stick with keyfiles.

✴️ Encrypt /boot partition

  • encrypting the whole disk without /boot partition but keeping it on a flash drive you carry at all times
  • using a checksum value of the boot sector
  • boot partition to detect it and change you passphrase

This may not completely get rid of the attack vector described in this post as there is still part of the bootloader that isn't encrypted, but at least the grub stage2 and the kernel/ramdisk are encrypted and should make it much harder to attack.

In addition, the /boot partition may be a weak point if you use encryption methods for the rest of the disk.

Historically it has been necessary to leave /boot unencrypted because bootloaders didn't support decrypting block devices. However, there are some dangers to leaving the bootloader and ramdisks unencrypted.

Before this you should to answer the following questions:

  • Where your /boot partition is stored?
    • the same place where stored /
    • separately partition
    • external flash drive

The following recipe should be made after installing the system (however, these steps are included in this section to avoid mixing issues).

Create copy of your /boot
mkdir /mnt/boot
mount --bind / /mnt/boot
rsync -aAXv /boot/ /mnt/boot/
umount /mnt/boot
Removed old /boot partition
umount /boot
sed -i -e '/\/boot/d' /etc/fstab
Regenerate grub configuration
# Debian like distributions
grub-mkconfig > /boot/grub/grub.cfg

# RedHat like distributions
grub2-mkconfig > /boot/grub2/grub.cfg
Enable GRUB_ENABLE_CRYPTODISK param
echo GRUB_ENABLE_CRYPTODISK=y >> /etc/default/grub
Reinstall grub
# Debian like distributions
grub-install /dev/sda

# RedHat like distributions
grub2-install /dev/sda

More details can be found here (Bootloader configuration (grub) section):

✴️ Swap partition

  • swap area is not required to survive a reboot, therefore a new random encryption key can be chosen each time the swap area is activated
  • get the key from /dev/urandom because /dev/random maybe stalling your boot sequence

☑️ Summary checklist

Item True False
Encrypting the whole disk 🔲 🔲
Usage passphrase or key file to disk unlocked 🔲 🔲
Choosing a strong passphrase 🔲 🔲
Encrypting the /boot partition 🔲 🔲
Securing swap partition with /dev/urandom 🔲 🔲
swap or tmp using an automatically generated per-session throwaway key 🔲 🔲

Post install tasks

Bootloader configuration (grub)

ℹ️ Introduction

Protection for the boot loader can prevent unauthorized users who have physical access to systems, e.g. attaining root privileges through single user mode.

Basically when you want to prohibit unauthorized reconfiguring of your system, otherwise anybody could load anything on it.

✴️ Protect bootloader with password

You can set password for the bootloader for prevents users from entering single user mode, changing settings at boot time, access to the bootloader console, reset the root password, if there is no password for GRUB-menu or access to non-secure operating systems.

Generate password hash
# Debian like distributions
grub-mkpasswd-pbkdf2

# RedHat like distributions
grub2-mkpasswd-pbkdf2
Updated grub configuration
cat > /etc/grub.d/01_hash << __EOF__
set superusers="user"
password_pbkdf2 user
grub.pbkdf2.sha512.<hash> # rest of your password hash
__EOF__

And regenerate grub configuration:

# Debian like distributions
grub-mkconfig > /boot/grub/grub.cfg

# RedHat like distributions
grub2-mkconfig > /boot/grub2/grub.cfg

✴️ Protect bootloader config files

Set the owner and group of /etc/grub.conf to the root user:

chown root:root /etc/grub.conf

or

chown -R root:root /etc/grub.d

Set permission on the /etc/grub.conf or /etc/grub.d file to read and write for root only:

chmod og-rwx /etc/grub.conf

or

chmod -R og-rwx /etc/grub.d

☑️ Summary checklist

Item True False
Set password for the bootloader 🔲 🔲

Disk partitions

ℹ️ Introduction

Critical file systems should be separated into different partitions in ways that make your system a better and more secure.

✴️ Separate disk partitions

Make sure the following filesystems are mounted on separate partitions:

  • /boot
  • /tmp
  • /var
  • /var/log

Additionally, depending on the purpose of the server, you should consider separating the following partitions:

  • /usr
  • /home
  • /var/www

You should also consider separating these partitions:

  • /var/tmp
  • /var/log/audit

✴️ Mount options: nodev, nosuid and noexec

For more security-focused situations is as follows:

  • nodev - specifies that the filesystem cannot contain special devices: This is a security precaution. You don't want a user world-accessible filesystem like this to have the potential for the creation of character devices or access to random device hardware
  • nosuid - specifies that the filesystem cannot contain set userid files. Preventing setuid binaries on a world-writable filesystem makes sense because there's a risk of root escalation or other awfulness there
  • noexec - this param might be useful for a partition that contains no binaries, like /var, or contains binaries you do not want to execute on your system (from partitions with noexec), or that cannot even be executed on your system

✴️ Secure /boot directory

The boot directory contains important files related to the Linux kernel, so you need to make sure that this directory is locked down to read-only permissions.

Add ro option and nodev, nosuid and noexec to /etc/fstab for /boot entry:

LABEL=/boot  /boot  ext2  defaults,ro,nodev,nosuid,noexec  1 2

When updating the kernel you will have to move the flag to rw:

mount -o remount,defaults,rw /boot

✴️ Secure /tmp and /var/tmp

On Linux systems, the /tmp and /var/tmp locations are world-writable.

Several daemons/applications use the /tmp or /var/tmp directories to temporarily store data, log information, or to share information between their sub-components. However, due to the shared nature of these directories, several attacks are possible, including:

  • Leaks of confidential data via secrets in file names
  • Race-condition attacks (TOCTOU) on the integrity of processes and data
  • Denial-of-Service (DoS) attacks based on race conditions and pre-allocating file/directory names

As a rule of thumb, malicious applications usually write to /tmp and then attempt to run whatever was written. A way to prevent this is to mount /tmp on a separate partition with the options nodev, nosuid and noexec enabled.

This will deny binary execution from /tmp, disable any binary to be suid root, and disable any block devices from being created.

The first possible scenario is create symlink

mv /var/tmp /var/tmp.old
ln -s /tmp /var/tmp
cp -prf /var/tmp.old/* /tmp && rm -fr /var/tmp.old

and set properly mount params:

UUID=<...>  /tmp  ext4  defaults,nodev,nosuid,noexec  1 2

The second scenario is a bind mount

The storage location /var/tmp should be bind mounted to /tmp, as having multiple locations for temporary storage is not required:

/tmp  /var/tmp  none  rw,nodev,nosuid,noexec,bind  0 0

The third scenario is setting up polyinstantiated directories

Create new directories:

mkdir --mode 000 /tmp-inst
mkdir --mode 000 /var/tmp/tmp-inst

Edit /etc/security/namespace.conf:

 /tmp      /tmp-inst/          level  root,adm
 /var/tmp  /var/tmp/tmp-inst/  level  root,adm

Set correct SELinux context:

setsebool polyinstantiation_enabled=1
chcon --reference=/tmp /tmp-inst
chcon --reference=/var/tmp/ /var/tmp/tmp-inst

And set nodev, nosuid and noexec mount options in /etc/fstab.

Alternative for polyinstantiated directories is PrivateTmp feature available from systemd. For more information please see: New Red Hat Enterprise Linux 7 Security Feature: PrivateTmp.

✴️ Secure /dev/shm

/dev/shm is a temporary file storage filesystem, i.e. tmpfs, that uses RAM for the backing store. One of the major security issue with the /dev/shm is anyone can upload and execute files inside the /dev/shm similar to the /tmp partition. Further the size should be limited to avoid an attacker filling up this mountpoint to the point where applications could be affected. (normally it allows 20% or more of RAM to be used). The sticky bit should be set like for any world writeable directory.

For applies to shared memory /dev/shm mount params:

tmpfs  /dev/shm  tmpfs  rw,nodev,nosuid,noexec,size=1024M,mode=1777 0 0

You can also create a group named 'shm' and put application users for SHM-using applications in there. Then the access can be completely be restricted as such:

tmpfs  /dev/shm  tmpfs  rw,nodev,nosuid,noexec,size=1024M,mode=1770,uid=root,gid=shm 0 0

✴️ Secure /proc filesystem

The proc pseudo-filesystem /proc should be mounted with hidepid. When setting hidepid to 2, directories entries in /proc will hidden.

proc  /proc  proc  defaults,hidepid=2  0 0

Some of the services/programs operate incorrectly when the hidepid parameter is set, e.g. Nagios checks.

✴️ Swap partition

✴️ Disk quotas

☑️ Summary checklist

Item True False
Separate base partition scheme: /boot, /tmp, /var, /var/log 🔲 🔲
Separate /usr partition 🔲 🔲
Separate /home partition 🔲 🔲
Separate /var/www partition 🔲 🔲
Separate /var/tmp partition 🔲 🔲
Separate /var/audit partition 🔲 🔲
Secure /boot directory with ro, nodev, nosuid, noexec options 🔲 🔲
Secure /tmp and /var/tmp directory with nodev, nosuid, noexec options 🔲 🔲
Create symlink for /var/tmp in /tmp 🔲 🔲
Setting up bind-mount /var/tmp to /tmp 🔲 🔲
Setting up polyinstantiated directories for /tmp and /var/tmp 🔲 🔲
Secure /dev/shm directory with nodev, nosuid, noexec options 🔲 🔲
Secure /proc filesystem with hidepid=2 option 🔲 🔲