Linux Hardening

Minder Trust, Minder Schade

Aanvalspaden worden klein zodra rechten, segmenten en beheerkanalen consequent zijn ingericht.

Voor Linux Hardening blijft de basis hetzelfde: minder impliciet vertrouwen en meer zicht op afwijkend gedrag.

Zo beperk je niet alleen de kans op incidenten, maar vooral ook de omvang en duur als er iets misgaat.

Directe maatregelen (15 minuten)

• Start met MFA, least privilege en tiering voor beheeraccounts.
• Voer segmentatie en expliciete firewallregels door op kritieke paden.
• Borg logging, detectie en hersteltests als structurele operatie.

Waarom dit telt

De kern van Linux Hardening is risicoreductie in de praktijk. Technische context ondersteunt de maatregelkeuze, maar implementatie en borging staan centraal.

Verdediging

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

Agent forwarding uitzetten is de meest impactvolle maatregel. Het elimineert agent hijacking volledig. Ja, het betekent dat beheerders hun keys op elke server moeten zetten, of een jump host moeten gebruiken met ProxyJump in plaats van agent forwarding. Dat is een kleine ongemak vergeleken met het risico.

Auditd

Linux heeft een ingebouwd audit framework dat alles kan loggen: bestandstoegang, processtarts, systeemaanroepen, netwerk-activiteit.

# 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

Het instellen van auditd kost een uur. Het doorlezen van de logs kost een eternity. Maar het verschil tussen een organisatie die auditd draait en eentje die dat niet doet, is het verschil tussen “we weten dat we gehackt zijn” en “we hebben geen idee wat er is gebeurd.”

File Integrity Monitoring

Tools als AIDE (Advanced Intrusion Detection Environment) of OSSEC controleren of systeembestanden zijn gewijzigd:

# AIDE initialiseren
aide --init

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

Als iemand /etc/passwd wijzigt, een SUID-bit zet op een binary, of een cronjob toevoegt, genereert AIDE een alert. Het is niet sexy. Het genereert veel false positives. Maar het werkt.

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

De gouden regel: geef gebruikers nooit sudo-toegang tot interactieve programma’s (editors, pagers, scripting-talen) met NOPASSWD. Als een programma een shell kan openen, is sudo-toegang tot dat programma gelijk aan root-toegang.

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)

Gebruik altijd root_squash (de standaard). Beperk NFS-exports tot specifieke IP-ranges. En vraag je af of je NFS uberhaupt nodig hebt – in veel gevallen is een modernere oplossing als SSHFS of een object store een beter alternatief.

De cynicus sluit af

Er is een prachtige ironie in de wereld van Linux-beveiliging. De community die het hardst schreeuwt over de onveiligheid van Windows, is dezelfde community die Docker-containers draait als root, SSH agent forwarding standaard aan laat staan, en chmod 777 beschouwt als een valide troubleshooting-stap.

“Maar Linux heeft geen virussen!”

Nee. Linux heeft geen virussen in de traditionele zin, omdat niemand de moeite neemt om virussen te schrijven voor een platform dat drie procent van de desktopmarkt heeft. Maar Linux heeft wel misconfiguraties. Heeft wel writable cronjobs. Heeft wel SUID-binaries op plekken waar ze niet horen. Heeft wel beheerders die LD_PRELOAD in de sudoers zetten en dat vervolgens vergeten.

Het verschil tussen een gehackt Windows-systeem en een gehackt Linux-systeem is niet dat het ene moeilijker te hacken is. Het verschil is dat de Windows-beheerder het meestal binnen een dag merkt (omdat er een alert afgaat, of omdat iemand klaagt dat zijn desktop raar doet), terwijl de Linux-beheerder het drie maanden later ontdekt wanneer hij toevallig eens inlogt op die server die “gewoon draait” en merkt dat er een onbekende gebruiker is aangemaakt.

Of helemaal niet ontdekt.

Want het ergste aan Linux-post-incident herstel is niet hoe makkelijk het is. Het ergste is hoe onzichtbaar het is. Een root-compromittatie op een Linux-server die niet wordt gemonitord – en de meeste worden niet gemonitord – kan maanden of jaren onopgemerkt blijven. Geen SIEM. Geen EDR. Geen auditd. Gewoon een server die draait, en een aanvaller die meekijkt.

“Linux is veiliger.”

Nee. Linux kan veiliger zijn. Als je het configureert. Als je het monitort. Als je het bijhoudt. Als je niet alles op 777 zet zodra het even niet werkt.

Maar dat geldt voor elk besturingssysteem. Beveiliging is geen eigenschap van software. Het is een eigenschap van de mensen die de software beheren. En de mensen? Die zijn op elk platform even incompetent.

Referentietabel

Samenvatting

Linux post-incident herstel is een spel van geduld en observatie. Waar Windows-omgevingen je overladen met Active Directory-objecten en Kerberos-tickets, biedt Linux een stiller maar niet minder rijk landschap van escalatie-mogelijkheden.

De rode draad door al deze technieken is hetzelfde: convenience vs. security. SSH agent forwarding is handig. LD_PRELOAD in env_keep is handig. NOPASSWD sudo op vim is handig. En elke keer dat iemand kiest voor handig boven veilig, opent er een deur.

De verdediging is niet ingewikkeld. Schakel agent forwarding uit. Audit je sudoers file. Monitor je cronjobs. Draai auditd. Het zijn geen revolutionaire maatregelen. Het zijn de basics. Maar de basics zijn precies wat de meeste organisaties overslaan, omdat ze te druk zijn met het evalueren van de nieuwste AI-powered security-oplossing die 250.000 euro per jaar kost en precies hetzelfde doet als een goed geconfigureerd auditd – alleen met een mooier dashboard.

In het volgende hoofdstuk kijken we naar wat er gebeurt als je al deze technieken combineert: de volledige incidentketen, van initial access tot domain admin. Van de eerste phishing-mail tot de Golden Ticket. Het grote plaatje.