Linux VPS Hardening Checklist for Agencies

Why a formalised runbook changes everything for an agency

What this runbook brings to your agency

• Reproducibility: every technician follows exactly the same steps, in the same order, on each new client VPS.
• Traceability: auditd records who did what, when, and which command — preservable proof for incidents or client audits.
• Safe delegation: a junior can deliver a hardened server without improvising, because the runbook already contains the decisions.
• Contractual defence: a security clause in your maintenance contract is only enforceable with a dated execution log.
• Reduced attack surface: the checklist eliminates classic omissions — root SSH left open, auditd not activated — the most commonly exploited entry points.
• Cross-client consistency: same secure baseline for all clients, differences only where the client's specification requires them.

Prerequisites and scope of the checklist

Block 1 — Updates and initial inventory

1. 01

   System update and inventory

   The first action after root login is to bring the system to its current patch level.

   apt update && apt upgrade -y
   apt install -y auditd audispd-plugins curl gnupg2 ufw fail2ban

   Record in your runbook: the date, kernel version (uname -r), and the list of installed packages (dpkg -l > /root/inventory-$(date +%F).txt). This inventory file constitutes the server's baseline at delivery — it is the evidence you produce if a client disputes the initial state of their machine.

   CIS Benchmark reference: CIS control 1.1 (Ubuntu Linux 24.04 LTS Benchmark, "Initial Setup" section).

2. 02

   Enable automatic security updates

   apt install -y unattended-upgrades
   dpkg-reconfigure --priority=low unattended-upgrades

   Verify that the Unattended-Upgrade::Allowed-Origins line includes ${distro_id}:${distro_codename}-security. For a client portfolio, enable automatic updates and schedule a monthly review of non-security updates — those require human validation.

   CIS reference: CIS control 1.9 (Ensure updates, patches, and additional security software are installed).

Block 2 — Sudo user and root lockout

1. 03

   Create a dedicated administration account

   Never use root for day-to-day tasks. Create a named account per technician or an agency service account:

   useradd -m -s /bin/bash adminagency
   usermod -aG sudo adminagency
   passwd adminagency

   Agency tip: use an identifiable account name in logs (john.doe or agency-admin), not a generic admin. When auditd traces an action, the executing account is recorded — a generic name makes the audit unusable.

2. 04

   Disable root SSH login

   sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
   grep PermitRootLogin /etc/ssh/sshd_config

   Caution: only reload sshd after verifying that your sudo user can connect and run sudo su. Otherwise you will lock yourself out of the server.

   CIS reference: CIS control 5.2.8 (Ensure SSH root login is disabled).

Block 3 — SSH key authentication

1. 05

   Deploy the agency public key

   mkdir -p /home/adminagency/.ssh
   chmod 700 /home/adminagency/.ssh
   echo "<AGENCY_PUBLIC_KEY>" >> /home/adminagency/.ssh/authorized_keys
   chmod 600 /home/adminagency/.ssh/authorized_keys
   chown -R adminagency:adminagency /home/adminagency/.ssh

   Agency tip: maintain a versioned public key repository (one file per technician, annual rotation). Every key deployed on a client VPS must be referenced in this repository — that is what allows you to revoke access when a team member leaves.

2. 06

   Disable password authentication

   Once the key is verified (test from another terminal before confirming):

   sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
   sed -i 's/^#\?ChallengeResponseAuthentication.*/ChallengeResponseAuthentication no/' /etc/ssh/sshd_config
   systemctl reload sshd

   CIS reference: CIS control 5.2.11 (Ensure only approved MAC algorithms are used) and CIS 5.2.19 (Ensure SSH PasswordAuthentication is disabled).

Block 4 — UFW firewall

1. 07

   Configure UFW with a default-deny policy

   ufw default deny incoming
   ufw default allow outgoing
   ufw allow 22/tcp comment 'Agency SSH'
   ufw allow 80/tcp comment 'HTTP'
   ufw allow 443/tcp comment 'HTTPS'
   ufw --force enable
   ufw status verbose

   Only open ports actually used by the client project. If the client application does not use a direct mail port, do not open it.

   For fail2ban installation and advanced UFW options, see the dedicated guides: Protecting a VPS with fail2ban and UFW firewall on VPS.

   CIS reference: CIS control 3.5.1 (Ensure a firewall package is installed).

Block 5 — fail2ban

1. 08

   Enable fail2ban with the SSH jail

   cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

   Edit /etc/fail2ban/jail.local and adjust the [sshd] section:

   [sshd]
   enabled = true
   maxretry = 5
   findtime = 600
   bantime = 3600

   systemctl enable fail2ban
   systemctl start fail2ban
   fail2ban-client status sshd

   For a client portfolio, consider CrowdSec as a replacement or complement: its community blocklist pools intelligence from thousands of servers.

Block 6 — auditd: the traceability log

1. 09

   Enable auditd and configure minimum rules

   auditd is the component agencies most often forget — yet it is the one that provides defensible proof in the event of an incident.

   systemctl enable auditd
   systemctl start auditd

   Create an agency rules file at /etc/audit/rules.d/agency.rules:

   # Trace all privilege escalations
   -w /etc/sudoers -p wa -k sudoers_changes
   -w /etc/sudoers.d/ -p wa -k sudoers_changes
   
   # Trace SSH connections
   -w /var/log/auth.log -p wa -k auth_log
   
   # Trace changes to system configuration files
   -w /etc/ssh/sshd_config -p wa -k sshd_config
   -w /etc/passwd -p wa -k passwd_changes
   -w /etc/shadow -p wa -k shadow_changes
   
   # Trace commands executed as root
   -a always,exit -F arch=b64 -S execve -F euid=0 -k root_commands

   augenrules --load
   auditctl -l

   CIS reference: CIS control 4.1.1 (Ensure auditing is enabled) and CIS 4.1.3 (Ensure events that modify date and time information are collected).

2. 10

   Export and retain auditd logs

   auditd logs must be retained off the server to be defensible. Configure an export to your centralised system (rsyslog, Loki, or a simple daily rsync to agency storage):

   # Example: rsyslog export to agency collector
   echo ':programname, isequal, "auditd" @<AGENCY_COLLECTOR_IP>:514' \
     >> /etc/rsyslog.d/99-auditd-remote.conf
   systemctl restart rsyslog

   Retain at least 90 days of logs. GDPR does not set a minimum retention period for security logs, but frameworks like CIS Controls v8 (control 8.3) recommend at least 90 days on-site and 1 year in cold archive.

Block 7 — Final verification and delivery record

# Check active services
systemctl is-active ufw fail2ban auditd sshd

# Confirm root cannot connect via SSH
grep PermitRootLogin /etc/ssh/sshd_config

# Check UFW rules
ufw status verbose

# Check loaded auditd rules
auditctl -l

# Check recent logins
last -n 10

Agency runbook vs. ad-hoc configuration: what changes

Scroll the table

Troubleshooting: common errors when applying the runbook

sshd -t && systemctl reload sshd

# In /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Automatic-Reboot "false";

Going further: bastioning and continuous monitoring