Week 3: Linux & OS Hardening Basics

1. Users, Groups & the Principle of Least Privilege

Least privilege means every user, process and service gets exactly the access it needs to do its job, and nothing more. On a fresh Linux box, this starts with never operating as root for day-to-day work — root can do anything, which means anything that compromises a root session compromises the entire machine.

# Create a non-root user for real work, add to sudo group for elevated commands only
$ adduser deploy
$ usermod -aG sudo deploy

# Check who's in a sensitive group before trusting the system's current state
$ getent group sudo
sudo:x:27:deploy,alice

# List all users with a valid login shell -- a service account with /bin/bash
# it never needs is itself a red flag
$ awk -F: '$7 ~ /sh$/ {print $1, $7}' /etc/passwd

Groups let you grant a capability to a set of users without editing permissions individually, and they're worth auditing specifically because group membership tends to only grow over time — someone gets added to docker or sudo for a one-off task and is never removed.

2. sudo, SUID/SGID & Privilege Escalation Vectors

sudo lets a scoped user run specific commands as root — the mechanism that makes least privilege practical instead of purely theoretical. But a misconfigured sudo rule is one of the most common privilege-escalation paths on a real box:

# /etc/sudoers -- BAD: this user can run vim as root, with no restriction
deploy ALL=(ALL) NOPASSWD: /usr/bin/vim

# vim can shell out from inside itself:
#   :!bash
# ...which just became a root shell, no password required.

# GOOD: scope the command tightly, and never grant NOPASSWD on anything
# that can spawn a shell, edit arbitrary files, or read arbitrary files as root
deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx

A related, separate mechanism is the SUID bit — a file permission that makes a program run as its owner (often root) regardless of who executes it. It's how passwd lets a regular user update /etc/shadow (which they can't write directly) safely. An unexpected SUID binary is a red flag:

# Find every SUID binary on the system
$ find / -perm -4000 -type f 2>/dev/null

# A short, known list of legitimate SUID binaries is normal (passwd, sudo, su, ping).
# An unfamiliar SUID binary -- especially one in a writable directory, or one that
# lets you read/write arbitrary files -- is exactly what a privilege-escalation
# checklist (like the one Week 14's pentest lab walks through) looks for first.

3. Minimizing the Attack Surface: Services, Ports & Packages

Every running service is something an attacker can potentially reach and exploit. Hardening a fresh server starts with an honest inventory of what's actually listening, and turning off everything that isn't earning its place.

# List every listening TCP/UDP port and the process behind it
$ ss -tulpn

Netid State   Local Address:Port   Process
tcp   LISTEN  0.0.0.0:22           sshd
tcp   LISTEN  0.0.0.0:80           nginx
tcp   LISTEN  127.0.0.1:5432       postgres    # bound to localhost only -- good

# Disable and stop anything you don't recognize or don't need
$ systemctl disable --now cups          # printing service on a headless server? unlikely needed
$ systemctl list-unit-files --state=enabled  # audit everything set to start at boot

The same discipline applies to installed packages, not just running services — a package installed "just in case" is still part of your attack surface even while dormant, because a future local vulnerability in it becomes exploitable the moment anything else on the box is compromised.

# Prefer installing exactly what a service needs, not a general-purpose toolbox image
$ apt list --installed | wc -l          # know your baseline; watch it creep upward over time
$ apt remove --purge    # remove, don't just disable, what you'll never use

# Bind services to localhost/internal interfaces unless they genuinely need
# to be reachable from outside -- 127.0.0.1 instead of 0.0.0.0 where possible

4. File Integrity Monitoring & auditd

Hardening reduces how a system can be attacked; monitoring tells you when something changed anyway. File integrity monitoring (FIM) takes a cryptographic snapshot of important files and alerts when they change unexpectedly — exactly the integrity leg of Week 1's CIA triad, applied to the filesystem itself.

$ apt install aide
$ aideinit                          # builds the initial database of file hashes

# Later, run a check -- any modified, added or removed file under watched
# paths (/etc, /bin, /sbin by default) gets reported
$ aide --check

# A modified /etc/passwd or /etc/sudoers you didn't change yourself is
# exactly the kind of finding this is designed to surface

auditd is a different, complementary tool: instead of periodic snapshots, it logs specific system calls and file access as they happen, in real time — who read or wrote a file, who ran a command, when.

# Watch for any write to /etc/passwd or /etc/shadow, and tag the log entries
$ auditctl -w /etc/passwd -p wa -k identity-changes
$ auditctl -w /etc/shadow -p wa -k identity-changes

# Later, search the audit log for anything tagged with that key
$ ausearch -k identity-changes

# This is exactly the "who did what, when" evidence Week 13's incident
# response process needs -- and it only exists if you turned it on beforehand

5. Building a Security Baseline Checklist

Hardening isn't a one-time task you do and forget — it's a baseline you define once and check every server against, every time. A short, concrete checklist beats a vague policy document that nobody actually applies:

[ ] No login as root; root login disabled in sshd_config (PermitRootLogin no)
[ ] SSH key-based auth only; password auth disabled (PasswordAuthentication no)
[ ] Every user account traced to a real person or documented service purpose
[ ] sudo rules scoped to specific commands, no blanket NOPASSWD ALL
[ ] `ss -tulpn` output reviewed; nothing listening that isn't required
[ ] Firewall default-deny inbound, explicit allow list only (Week 2)
[ ] Unattended security updates enabled for critical packages
[ ] FIM baseline established (AIDE or equivalent) and checked on a schedule
[ ] auditd watching /etc/passwd, /etc/shadow, /etc/sudoers at minimum
[ ] System time synced (NTP) -- accurate timestamps matter for every later log

Frameworks like the CIS Benchmarks formalize this into hundreds of specific, scored checks per operating system — worth knowing exists, even if this week's checklist is a deliberately smaller, practical starting point. Automating a checklist like this against every new server (via configuration management, or a tool like lynis) is what turns hardening from a one-time task into a repeatable guarantee.

6. Hands-on Exercise

7. Knowledge Check

Four quick questions. Expand each to check your answer.