Hardening Linux Systems

%admin ALL=(ALL) ALL

This gives all members of the admin group full sudo access. For granular control, restrict commands:

username ALL=(ALL) /usr/bin/apt update, /usr/bin/apt upgrade

systemctl stop apache2
systemctl disable apache2
apt remove apache2

Common services to disable on a hardened server: cups (printing), avahi-daemon (mDNS), bluetooth, rpcbind, telnet, ftp. The exam often tests knowledge of systemctl commands to manage services.

After changes, restart SSH: systemctl restart sshd. The exam may ask which configuration setting prevents brute-force attacks—answer: disabling password authentication or using key-based authentication.

chmod 600 /etc/shadow
chown root:root /etc/shadow

Special permissions: SUID (4000), SGID (2000), sticky bit (1000). SUID allows a program to run with the file owner's privileges—a common vulnerability if misapplied. Find all SUID files with:

find / -perm -4000

The exam expects you to know that the sticky bit on /tmp prevents users from deleting each other's files.

Defaults logfile=/var/log/sudo.log
Defaults timestamp_timeout=5

The timestamp_timeout sets how long sudo credentials are cached (default 5 minutes). The exam may ask how to prevent sudo from caching credentials—set timestamp_timeout to 0.

Apply changes with sysctl -p. The exam may test knowledge of ASLR (Address Space Layout Randomization) as a defense against buffer overflow attacks.

getenforce
sestatus

Set enforcing mode: setenforce 1. SELinux contexts can be viewed with ls -Z. Common commands: - chcon -t httpd_sys_content_t /var/www/html/index.html - restorecon -Rv /var/www/html

AppArmor uses profiles in /etc/apparmor.d/. Check status: aa-status. The exam expects you to know that SELinux and AppArmor are kernel modules that enforce security policies, and that SELinux is more common on Red Hat-based distributions, AppArmor on Debian/Ubuntu.

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

The exam may ask about patch management strategies—apply security patches promptly after testing in a non-production environment.

auditctl -w /etc/passwd -p wa -k passwd_changes
aureport -k passwd_changes

The exam expects you to know that auditd logs can be reviewed with ausearch and aureport.

ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw enable

Or with iptables:

iptables -P INPUT DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -j DROP

The exam may test that a stateful firewall tracks connection states.

Scenario 1: SOC Analyst Investigating a Compromised Linux Web Server A SOC analyst receives an alert from an IDS indicating outbound traffic from a Linux web server to a known malicious IP. The analyst checks the server's running services using systemctl list-units --type=service --state=running and finds an unknown service named 'systemd-helper' listening on port 4444. The analyst then reviews /var/log/auth.log and sees multiple failed SSH attempts from a foreign IP, followed by a successful login from an internal IP that should not have SSH access. The analyst uses ausearch -m USER_LOGIN -sv yes to find successful logins. The root cause: SSH was configured with password authentication enabled and root login permitted. The analyst immediately disables root login and password auth, changes all passwords, and removes the backdoor service. A common mistake is to focus only on the backdoor and not address the weak SSH configuration that allowed initial access.

Scenario 2: System Administrator Hardening a New Linux Deployment An organization is deploying 50 Linux servers for a new application. The system administrator follows a hardening checklist. First, they create a baseline image with minimal services. They use ss -tlnp to verify only SSH and the application port are listening. They configure /etc/ssh/sshd_config with key-only authentication and disable root login. They set up ufw with default deny incoming and allow only necessary ports. They enable automatic security updates via unattended-upgrades. They also configure auditd to monitor /etc/passwd and /etc/shadow. They test the configuration by running a vulnerability scanner (e.g., OpenVAS) and address any findings. A common mistake is to forget to apply the same hardening to all servers consistently, leaving some servers vulnerable. Automation tools like Ansible or Puppet can enforce consistency.

Scenario 3: Incident Response to a Privilege Escalation via SUID Binary An attacker gains initial access through a vulnerable web application. They run find / -perm -4000 and discover a custom SUID binary owned by root that allows execution of arbitrary commands. The attacker exploits it to gain a root shell. The incident responder reviews auditd logs to see the SUID binary execution. The responder then removes the SUID bit from the binary: chmod u-s /path/to/binary. They also check for other SUID binaries using the find command and remove unnecessary ones. The root cause: the binary was installed with SUID during development and never hardened. A common mistake is to only patch the web application vulnerability and not check for SUID binaries, leaving the privilege escalation vector open.