by: Linux/Unix

This guide lists essential considerations to harden (enhance) a Linux server to reduce the attack surface, reduce the impact or protect the system against human error, and manage users and privileges.

Preparation

  • Plan and the logical and physical diagrams that represents the infrastructure and its systems,
  • Create a Software Bill of Material (SBOM) per server and link to the ports,
  • Represent graphically (with illustrations) and document all relationship between applications and services on the network,

Planning

  • Enumerate the layers of communication to apply Defense-in-Depth,
  • Define an Entry Point for the network and deploy the resources in High-Availability to prevent single point of failure,
  • Frequently the network entry point will have:
    • One primarily firewall between the internet and the DMZ,
    • And another firewall between the DMZ and the private network.
  • Make the firewall rules as much restrictive as possible,
  • Use VLANs and ACLs whenever applicable,
  • In case of physical infrastructures use consider using dedicated data links in the Core Network,
  • And Port Security for the Transport and Access Networks when possible,
  • Strategically define where in the network the IDS/IPS shall be located and what will be protected (Network-Bases Protection),
  • End points also must have up to date anti-virus, anti-malware, and firewall rules accordingly (Host-Based Protection),
  • Avoid or eliminate the usage of Legacy services such as Telnet, FTP, RSH, HTTP, etc. They are all non-encrypted services.
    • If it is unenviable tunnel the traffic over encrypted or dedicated sniff-proof means.

Hardening points to target

  • Hardware
    • Restrict physical access and to servers and network devices with locks, alarms, or cameras if necessary,
    • Prefer UEFI (uses GPT) over BIOS (uses MBR),
    • Enable TPM 2.0 when possible.
  • BIOS
    • Create password to access the BIOS/UEFI menus.
  • Operating System
    • Bootloader
      • Limit the access to the bootloader configuration and to the boot volume (desirable read-only for /boot),
      • Use password for groups or users in GRUB to limit the boot options such as kernel versions of multi operating system boot.
    • Kernel
      • Customize the Kernel compilation to only load the drivers for the used pieces of hardware,
      • Hide process from other users (only root should be able of seen all processes),
      • Isolate processes resources with Control Groups and Namespaces,
      • Enable SELinux, AppArmor, and Exec Shield,
    • Always choose LTS version of the desires distribution and update it regularly (consider unattended upgrades),
    • Remove orphan (unused) packets and unused resources such as X11, Firewire, IPv6,
    • Consider disabling Ctrl+Alt+Delete if not needed,
    • Reserve disk space for a SWAP partition,
    • Encrypt volumes that store sensitive data,
    • Disable root login or disable completely the root account,
    • Granularly assign what each user can or cannot execute with sudo and configure notifications,
  • Services
    • Leverage system and application level containerization (LXD and Docker, respectively),
    • Periodically list and audit the listening ports,
    • Apply all best practices to the SSH service:
      • Dot not allow empty passwords (preferably no passwords at all) nor root login,
      • Require SSH-Keys and a secondary factor such as OTP mobile app [Link] or USB/NFC Hardware Key [Link],
      • Only allow certain users or groups or use restrictive rules to allow connections that Match an specific pattern,
      • Ans always use Fail2Ban in combination with most of your publicly facing services [Link].
  • Administration
    • Centralize the logs in a Log Server,
    • Configure LogWatch and LogCheck to monitor the logs and send reports periodically,
    • Disable and remove unused or unnecessary services,
    • Allow/Deny the users that should use cron or not,
    • Define a reasonable timeout for the for the shells,
    • Find and disable SUID and GUID permission files,
    • Use PAM (Pluggable Authentication Modules) to enforce Strong Passwords (length, complexity, reusability, etc) and Password Age parameters,
    • Configure Kerberos when possible,
    • Validate the UIDs periodically and identify users with empty password,
    • Stablish policies to lock inactive users.
  • Users
    • Assign privileges to Groups instead Users, even if the user is the only member of the group,
    • Use a directory service or manage the users with automation tools such as Ansible.

Desired State

  • Encryption in Transit,
  • Encryption in Rest,
  • Restrict read and write with Least Privilege Access Control,
    • Per Files,
    • Per Directory,
    • Per Volumes.