The most surprising thing about security baselines is that they’re not primarily about preventing sophisticated attacks; they’re about closing the gaping holes that automated scripts and opportunistic attackers exploit every single day.
Let’s look at a live example. Imagine you’ve got a Linux server, and you want to apply some basic hardening. We’ll use CIS Benchmarks as our guide.
First, you need to grab the relevant CIS Benchmark PDF for your OS (e.g., "CIS Ubuntu Linux 20.04 Benchmark"). These documents are dense, but they’re the authoritative source.
Now, let’s say the benchmark for Ubuntu 20.04 recommends disabling the telnet service. Why? Because telnet transmits credentials and data in plain text, making it trivial for anyone on the network to sniff them.
Here’s how you’d check if it’s running:
systemctl is-active telnet.socket
If it outputs active, it’s running. To disable it and prevent it from starting on boot:
sudo systemctl disable telnet.socket
sudo systemctl stop telnet.socket
This command tells systemd (the init system on modern Linux) to unregister the service from the boot process and then immediately stop it if it’s currently running.
Another common recommendation is to ensure SSH is configured securely. The CIS benchmark might mandate disabling root login over SSH and enforcing protocol version 2.
Check your /etc/ssh/sshd_config file. You’re looking for these lines:
PermitRootLogin no
Protocol 2
If PermitRootLogin is set to yes or commented out, change it to no. If Protocol is set to 1 or 2,1 (or commented out and the default is version 1), change it to 2.
After making these changes, you must restart the SSH service for them to take effect:
sudo systemctl restart sshd
This action reloads the SSH daemon’s configuration, applying the new security settings. Without this, your changes are just sitting in the file, doing nothing.
The goal here is to build a system that’s harder to compromise by default. It’s not about writing custom intrusion detection rules; it’s about removing the low-hanging fruit. Think of it like putting locks on your doors and windows instead of installing a laser grid. Automated scanners are constantly probing for open doors, and baselines are the locks.
Consider file permissions. CIS benchmarks often recommend strict permissions for sensitive configuration files. For example, /etc/passwd and /etc/shadow should ideally only be readable by root.
You can check permissions with ls -l /etc/passwd. You’ll typically see something like -rw-r--r--. The benchmark might require -rw-r----- or even stricter.
If you need to adjust:
sudo chmod 640 /etc/passwd
sudo chmod 600 /etc/shadow
These commands set the read/write bits for the owner (root) and remove read access for others, ensuring only the superuser can directly view or modify these critical authentication files.
The most common mistake people make with SSH hardening is disabling password authentication entirely before ensuring key-based authentication is robust and accessible. If you disable passwords and your SSH keys aren’t set up correctly or are inaccessible, you’ll lock yourself out of your own server. Always test key-based login before disabling password authentication.
Another crucial aspect is ensuring that only necessary network ports are open. Tools like nmap can scan your server to see what’s listening. For example, sudo nmap -sT -p- <your_server_ip> will show you open TCP ports. You’d then compare this to your ufw or firewalld rules to ensure only legitimate services are exposed.
The real power of these benchmarks lies in their systematic approach. They provide a checklist that covers a vast attack surface, from user account management and kernel parameters to logging and network services. Instead of guessing what might be a weakness, you’re following a battle-tested set of recommendations.
One subtle but critical point often overlooked is the importance of regular review and updates. A security baseline applied today might be outdated in six months as new vulnerabilities are discovered or best practices evolve. Many organizations treat hardening as a one-time task, failing to re-evaluate their configurations against updated benchmarks or emerging threats. This static approach leaves systems vulnerable to newly identified attack vectors.
The next logical step after implementing baselines is to automate compliance checks and remediation using tools like Ansible, Chef, Puppet, or dedicated compliance platforms.