Linux Hardening

Less Trust, Less Damage

Attack paths shrink once permissions, segments, and management channels are consistently configured.

For Linux Hardening, the foundation remains the same: less implicit trust and more visibility into anomalous behavior.

This way you limit not only the chance of incidents, but especially the scope and duration when something does go wrong.

Immediate measures (15 minutes)

• Start with MFA, least privilege, and tiering for admin accounts.
• Enforce segmentation and explicit firewall rules on critical paths.
• Embed logging, detection, and recovery tests as structural operations.

Why this matters

The core of Linux Hardening is risk reduction in practice. Technical context supports the choice of measures, but implementation and assurance are central.

Defense

SSH Hardening

# /etc/ssh/sshd_config

# Schakel agent forwarding uit
AllowAgentForwarding no

# Schakel TCP forwarding uit
AllowTcpForwarding no

# Beperk toegang tot specifieke gebruikers
AllowUsers admin deploy

# Schakel root login uit
PermitRootLogin no

# Gebruik alleen key-based authenticatie
PasswordAuthentication no
PubkeyAuthentication yes

# Beperk max sessies
MaxSessions 2

# Log alles
LogLevel VERBOSE

Disabling agent forwarding is the most impactful measure. It completely eliminates agent hijacking. Yes, it means administrators need to put their keys on every server, or use a jump host with ProxyJump instead of agent forwarding. That's a minor inconvenience compared to the risk.

Auditd

Linux has a built-in audit framework that can log everything: file access, process starts, system calls, network activity.

# Monitor SUID/SGID changes
-a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat \
    -F auid>=1000 -k perm_mod

# Monitor sudo gebruik
-w /etc/sudoers -p wa -k sudoers_change
-w /etc/sudoers.d/ -p wa -k sudoers_change

# Monitor cron wijzigingen
-w /etc/crontab -p wa -k cron_mod
-w /etc/cron.d/ -p wa -k cron_mod

# Monitor SSH configuratie
-w /etc/ssh/sshd_config -p wa -k ssh_config

# Monitor passwd/shadow
-w /etc/passwd -p wa -k passwd_change
-w /etc/shadow -p wa -k shadow_change

# Monitor LD_PRELOAD gebruik
-a always,exit -F arch=b64 -S execve \
    -F key=ld_preload_usage

Setting up auditd takes an hour. Reading through the logs takes an eternity. But the difference between an organization that runs auditd and one that doesn't is the difference between "we know we were hacked" and "we have no idea what happened."

File Integrity Monitoring

Tools such as AIDE (Advanced Intrusion Detection Environment) or OSSEC check whether system files have been modified:

# AIDE initialiseren
aide --init

# Regelmatig controleren (via cron, uiteraard)
aide --check

If someone modifies /etc/passwd, sets a SUID bit on a binary, or adds a cronjob, AIDE generates an alert. It's not sexy. It generates many false positives. But it works.

Sudo hardening

# /etc/sudoers (via visudo!)

# Verwijder LD_PRELOAD uit env_keep
Defaults !env_keep += "LD_PRELOAD"

# Beperk sudo-commando's tot specifieke paden
# FOUT:
# operator ALL=(ALL) NOPASSWD: /usr/bin/vim
# BETER:
# operator ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart httpd

# Gebruik NOPASSWD alleen voor specifieke, niet-escapable commando's
# Vermijd: vim, less, more, find, python, perl, ruby, env, awk, sed

# Log alle sudo-activiteit
Defaults logfile="/var/log/sudo.log"
Defaults log_input, log_output

The golden rule: never give users sudo access to interactive programs (editors, pagers, scripting languages) with NOPASSWD. If a program can open a shell, sudo access to that program is equivalent to root access.

Docker hardening

# Verwijder onnodige gebruikers uit de docker-groep
gpasswd -d username docker

# Gebruik rootless Docker
# https://docs.docker.com/engine/security/rootless/

# Beperk container capabilities
docker run --cap-drop ALL --cap-add NET_BIND_SERVICE myapp

# Gebruik read-only file systems
docker run --read-only myapp

# Blokkeer toegang tot de Docker socket
chmod 660 /var/run/docker.sock

NFS hardening

# /etc/exports
# FOUT:
# /data *(rw,no_root_squash)
# GOED:
# /data 10.1.0.0/24(rw,root_squash,no_subtree_check)

Always use root_squash (the default). Restrict NFS exports to specific IP ranges. And ask yourself whether you actually need NFS -- in many cases, a more modern solution like SSHFS or an object store is a better alternative.

The cynic signs off

There is a beautiful irony in the world of Linux security. The community that shouts the loudest about Windows insecurity is the same community that runs Docker containers as root, leaves SSH agent forwarding enabled by default, and considers chmod 777 a valid troubleshooting step.

"But Linux doesn't have viruses!"

No. Linux doesn't have viruses in the traditional sense, because nobody bothers writing viruses for a platform that has three percent of the desktop market. But Linux does have misconfigurations. Does have writable cronjobs. Does have SUID binaries in places where they don't belong. Does have administrators who put LD_PRELOAD in the sudoers and then forget about it.

The difference between a hacked Windows system and a hacked Linux system is not that one is harder to hack. The difference is that the Windows administrator usually notices within a day (because an alert goes off, or because someone complains their desktop is acting weird), while the Linux administrator discovers it three months later when they happen to log into that server that "just runs" and notices an unknown user has been created.

Or doesn't discover it at all.

Because the worst thing about Linux post-incident recovery is not how easy it is. The worst thing is how invisible it is. A root compromise on a Linux server that isn't being monitored -- and most aren't -- can go unnoticed for months or years. No SIEM. No EDR. No auditd. Just a server that runs, and an attacker watching along.

"Linux is more secure."

No. Linux can be more secure. If you configure it. If you monitor it. If you maintain it. If you don't set everything to 777 the moment something doesn't work.

But that applies to every operating system. Security is not a property of software. It is a property of the people who manage the software. And the people? They are equally incompetent on every platform.

Reference table

Summary

Linux post-incident recovery is a game of patience and observation. Where Windows environments overwhelm you with Active Directory objects and Kerberos tickets, Linux offers a quieter but no less rich landscape of escalation possibilities.

The common thread through all these techniques is the same: convenience vs. security. SSH agent forwarding is convenient. LD_PRELOAD in env_keep is convenient. NOPASSWD sudo on vim is convenient. And every time someone chooses convenient over secure, a door opens.

The defense is not complicated. Disable agent forwarding. Audit your sudoers file. Monitor your cronjobs. Run auditd. These are not revolutionary measures. They are the basics. But the basics are exactly what most organizations skip, because they're too busy evaluating the latest AI-powered security solution that costs 250,000 euros per year and does exactly the same thing as a well-configured auditd -- just with a nicer dashboard.

In the next chapter, we'll look at what happens when you combine all these techniques: the full incident chain, from initial access to domain admin. From the first phishing email to the Golden Ticket. The big picture.