Linux-Härtung

1. Einführung

Ein frisch installierter Linux-Server ist kein gehärtetes System. Die Standardinstallation vieler Distributionen ist auf Kompatibilität und Benutzerfreundlichkeit ausgelegt, nicht auf maximale Sicherheit. Dienste lauschen auf Ports, die nicht benötigt werden. Passwortrichtlinien sind zu lax. Kernelparameter sind nicht für eine feindliche Netzwerkumgebung konfiguriert. Wer einen Server in das Internet stellt, ohne ihn vorher zu härten, lädt Angreifer geradezu ein.

Linux-Härtung (englisch: Linux Hardening) bezeichnet die systematische Reduktion der Angriffsfläche eines Systems. Das Ziel ist nicht, einen Angriff mit absoluter Sicherheit zu verhindern – das ist prinzipiell unmöglich –, sondern den Aufwand für einen erfolgreichen Angriff so weit zu erhöhen, dass er sich für den Angreifer nicht lohnt, und im Falle eines Einbruchs den Schaden möglichst gering zu halten.

1.1 Angriffsszenarien

Die häufigsten Angriffsvektoren auf Linux-Server umfassen automatisierte Brute-Force-Angriffe auf SSH, die Ausnutzung ungepatchter Schwachstellen in Diensten wie Nginx, Apache oder MySQL, fehlerhafte Sudo-Konfigurationen, die eine Privilege Escalation ermöglichen, sowie schlecht gesicherte Webanwendungen, die als Einstiegspunkt für laterale Bewegungen im System dienen. Insider-Bedrohungen durch überprivilegierte Benutzerkonten runden das Bild ab.

1.2 Defense in Depth

Das Prinzip Defense in Depth (Tiefenverteidigung) besagt, dass Sicherheitsmaßnahmen auf mehreren unabhängigen Schichten implementiert werden sollen. Fällt eine Schicht weg oder wird kompromittiert, greifen die nachfolgenden. Für einen Linux-Server bedeutet das: Firewall, Benutzerverwaltung, Mandatory Access Control, Auditing und Monitoring sind keine Alternativen zueinander, sondern ergänzen sich gegenseitig.

1.3 CIS Benchmark als Referenz

Das Center for Internet Security (CIS) veröffentlicht für alle gängigen Linux-Distributionen sogenannte CIS Benchmarks – umfangreiche Härtungsrichtlinien, die von einer Community aus Sicherheitsexperten gepflegt werden. Sie sind frei verfügbar unter cisecurity.org und bilden eine hervorragende Checkliste für die Absicherung produktiver Systeme. Viele der in diesem Artikel beschriebenen Maßnahmen orientieren sich an diesen Benchmarks.

2. Benutzerverwaltung

Fehlerhafte Benutzerverwaltung ist eine der häufigsten Ursachen für erfolgreiche Angriffe. Das Prinzip der geringsten Privilegien (Least Privilege) muss konsequent umgesetzt werden: Jeder Benutzer und jeder Prozess erhält nur die Rechte, die er für seine Aufgabe tatsächlich benötigt.

2.1 Direkten Root-Login deaktivieren

Das Root-Konto sollte niemals direkt über SSH erreichbar sein. Stattdessen meldet sich ein Administrator mit einem persönlichen Konto an und wechselt bei Bedarf über sudo zu erhöhten Rechten. Dies schafft eine Audit-Trail und verhindert anonyme Root-Anmeldungen. In der SSH-Konfiguration wird der direkte Root-Login wie folgt deaktiviert:

# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

Nach der Änderung muss der SSH-Dienst neu geladen werden:

sudo systemctl reload sshd

2.2 Sudo-Konfiguration

Die Datei /etc/sudoers steuert, welche Benutzer welche Befehle mit erhöhten Rechten ausführen dürfen. Sie sollte ausschließlich über visudo bearbeitet werden, da dieses Werkzeug die Syntax vor dem Speichern prüft. Ein fehlerhaftes sudoers-File kann das System unzugänglich machen.

# Bearbeiten mit:
sudo visudo

# Beispiel: Benutzer "deploy" darf nur systemctl restart nginx ausführen
deploy ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx

# Administratoren-Gruppe mit vollem Zugriff (mit Passwort)
%sudo ALL=(ALL:ALL) ALL

# WICHTIG: Folgende unsichere Einträge vermeiden
# deploy ALL=(ALL) NOPASSWD: ALL  <-- gefährlich!

2.3 Starke Passwortrichtlinien mit libpam-pwquality

Das PAM-Modul libpam-pwquality erzwingt Qualitätsanforderungen an Passwörter. Es ersetzt das ältere cracklib-Modul und ist auf Debian/Ubuntu über den Paketmanager verfügbar.

sudo apt install libpam-pwquality

Die Konfiguration erfolgt in /etc/security/pwquality.conf:

# /etc/security/pwquality.conf
minlen = 14          # Mindestlänge 14 Zeichen
dcredit = -1         # Mindestens 1 Ziffer
ucredit = -1         # Mindestens 1 Großbuchstabe
lcredit = -1         # Mindestens 1 Kleinbuchstabe
ocredit = -1         # Mindestens 1 Sonderzeichen
maxrepeat = 3        # Nicht mehr als 3 gleiche Zeichen hintereinander
usercheck = 1        # Benutzername darf nicht im Passwort vorkommen
enforcing = 1        # Verstöße werden abgelehnt (nicht nur gewarnt)

2.4 Account Locking mit faillock

Um Brute-Force-Angriffe auf lokale Logins zu erschweren, kann über das PAM-Modul pam_faillock ein automatisches Sperren von Benutzerkonten nach einer definierten Anzahl fehlgeschlagener Anmeldeversuche konfiguriert werden.

# /etc/security/faillock.conf
deny = 5             # Sperre nach 5 Fehlversuchen
unlock_time = 900    # Sperre für 15 Minuten (900 Sekunden)
fail_interval = 900  # Zählfenster: 15 Minuten

# Gesperrte Konten anzeigen:
sudo faillock --user USERNAME

# Konto manuell entsperren:
sudo faillock --user USERNAME --reset

3. Paketverwaltung & Updates

Ungepatchte Software ist einer der häufigsten Einstiegspunkte für Angreifer. Ein konsequentes Patch-Management ist deshalb keine optionale Maßnahme, sondern ein Grundpfeiler der Systemsicherheit.

3.1 Automatische Sicherheitsupdates mit unattended-upgrades

Auf Debian und Ubuntu ermöglicht das Paket unattended-upgrades das automatische Einspielen von Sicherheitsaktualisierungen ohne manuellen Eingriff.

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

Die Konfiguration in /etc/apt/apt.conf.d/50unattended-upgrades erlaubt eine genaue Steuerung, welche Paketquellen automatisch aktualisiert werden:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    // Optional: auch reguläre Updates
    // "${distro_id}:${distro_codename}-updates";
};

Unattended-Upgrade::Mail "admin@example.com";
Unattended-Upgrade::MailReport "on-change";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Automatic-Reboot "false";

Automatic-Reboot sollte auf Produktivsystemen auf false gesetzt und ein Reboot-Fenster manuell geplant werden, da Kernel-Updates erst nach einem Neustart aktiv werden.

3.2 Nur notwendige Pakete installieren

Jedes installierte Paket ist eine potenzielle Angriffsfläche. Server-Systeme sollten im Minimal-Modus installiert werden. Bereits installierte, nicht benötigte Pakete können mit folgendem Befehl aufgelistet und anschließend entfernt werden:

# Alle installierten Pakete auflisten
dpkg -l | grep "^ii" | less

# Pakete entfernen und Konfigurationsdateien löschen
sudo apt purge PAKETNAME

# Verwaiste Abhängigkeiten entfernen
sudo apt autoremove --purge

Typische Kandidaten für die Entfernung auf einem reinen Web-Server sind beispielsweise cups (Druckdienst), avahi-daemon (mDNS/Bonjour), bluetooth oder nicht benötigte Compiler und Entwicklungswerkzeuge.

4. Netzwerk-Härtung

Die Netzwerkschicht ist der primäre Angriffspunkt für externe Bedrohungen. Eine restriktive Firewall-Konfiguration in Kombination mit gehärteten Kernelparametern reduziert die Angriffsfläche erheblich.

4.1 Firewall mit UFW

UFW (Uncomplicated Firewall) ist ein benutzerfreundliches Frontend für iptables bzw. nftables und auf Ubuntu standardmäßig verfügbar. Grundregel: alles sperren, nur explizit benötigte Ports öffnen.

# UFW installieren und aktivieren
sudo apt install ufw

# Standardrichtlinien setzen: alles eingehende ablehnen, ausgehende erlauben
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Explizit benötigte Dienste erlauben
sudo ufw allow ssh          # Port 22
sudo ufw allow 80/tcp       # HTTP
sudo ufw allow 443/tcp      # HTTPS

# UFW aktivieren
sudo ufw enable

# Status prüfen
sudo ufw status verbose

4.2 Kernelparameter mit sysctl härten

Linux-Kernelparameter können über sysctl zur Laufzeit und persistent über /etc/sysctl.d/ gesetzt werden. Die folgenden Einstellungen verbessern die Netzwerksicherheit deutlich:

# /etc/sysctl.d/99-hardening.conf

# IP-Forwarding deaktivieren (kein Router)
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

# Reverse Path Filtering aktivieren (Schutz vor IP-Spoofing)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# SYN-Flood-Schutz durch SYN-Cookies
net.ipv4.tcp_syncookies = 1

# ICMP-Redirects ignorieren
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

# IPv6 Router Advertisements deaktivieren
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.default.accept_ra = 0

# Source Routing deaktivieren
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# Bogus-ICMP-Fehlermeldungen protokollieren
net.ipv4.icmp_ignore_bogus_error_responses = 1

Die Einstellungen werden mit folgendem Befehl sofort angewendet:

sudo sysctl --system

4.3 Lauschende Ports prüfen

Regelmäßig sollte geprüft werden, welche Dienste auf welchen Ports lauschen. Unbekannte oder unerwartete Einträge können auf kompromittierte Software oder Fehlkonfigurationen hinweisen.

# Alle TCP-Ports mit zugehörigem Prozess anzeigen
sudo ss -tlnp

# Alle UDP-Ports anzeigen
sudo ss -ulnp

# Alternativ mit netstat (falls installiert)
sudo netstat -tlnp

5. AppArmor

AppArmor ist ein Mandatory Access Control (MAC) System, das in den Linux-Kernel integriert ist und auf Ubuntu sowie Debian standardmäßig verfügbar ist. Es schränkt Prozesse auf Basis von Profilen ein: Jedes Profil definiert, auf welche Dateien, Netzwerke und Capabilities ein Programm zugreifen darf – unabhängig von den Unix-Dateiberechtigungen.

5.1 Profile-Konzept und Modi

AppArmor kennt zwei Betriebsmodi für Profile:

• enforce: Zugriffe, die nicht im Profil erlaubt sind, werden blockiert und protokolliert.
• complain: Verstöße werden nur protokolliert, aber nicht blockiert. Nützlich beim Erstellen neuer Profile.

5.2 Status prüfen und Profile verwalten

# AppArmor installieren (falls nicht vorhanden)
sudo apt install apparmor apparmor-utils apparmor-profiles apparmor-profiles-extra

# Aktuellen Status anzeigen: geladene Profile und deren Modus
sudo aa-status

# Profil in den enforce-Modus setzen
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

# Profil in den complain-Modus setzen (zum Testen)
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

# Alle Profile neu laden
sudo systemctl reload apparmor

5.3 Vorgefertigte Profile für Nginx und MySQL

Das Paket apparmor-profiles-extra enthält vorgefertigte Profile für viele gängige Dienste. Für Nginx und MySQL sind Profile in der Regel bereits vorhanden und müssen nur aktiviert werden:

# Verfügbare Profile anzeigen
ls /etc/apparmor.d/

# Nginx-Profil aktivieren
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

# MySQL-Profil aktivieren
sudo aa-enforce /etc/apparmor.d/usr.sbin.mysqld

# Verstöße in den Logs verfolgen
sudo journalctl -k | grep apparmor | tail -50

6. auditd

Das Linux Audit-System (auditd) ermöglicht die detaillierte Protokollierung sicherheitsrelevanter Ereignisse auf Kernelebene. Im Gegensatz zu einfachen Systemlogs erfasst auditd auch Ereignisse wie Dateizugriffe, Systemaufrufe, Benutzeranmeldungen und Änderungen an sicherheitskritischen Dateien – und das manipulationsresistent, da die Logs direkt vom Kernel geschrieben werden.

6.1 Installation und Grundkonfiguration

sudo apt install auditd audispd-plugins

# Dienst starten und für Autostart konfigurieren
sudo systemctl enable --now auditd

# Aktuellen Status prüfen
sudo auditctl -s

6.2 Audit-Regeln für kritische Dateien

Audit-Regeln werden in /etc/audit/rules.d/ als .rules-Dateien abgelegt. Die folgende Konfiguration überwacht sicherheitskritische Dateien und Verzeichnisse auf Lese- und Schreibzugriffe:

# /etc/audit/rules.d/hardening.rules

# Änderungen an Benutzer- und Gruppendatenbank überwachen
-w /etc/passwd -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/gshadow -p wa -k identity

# sudo-Konfiguration überwachen
-w /etc/sudoers -p wa -k sudoers
-w /etc/sudoers.d/ -p wa -k sudoers

# SSH-Konfiguration überwachen
-w /etc/ssh/sshd_config -p wa -k sshd_config

# Privilegierte Befehle protokollieren
-a always,exit -F arch=b64 -S execve -F euid=0 -k privileged

# Netzwerkkonfiguration überwachen
-w /etc/hosts -p wa -k network
-w /etc/network/ -p wa -k network

# Regeln unveränderlich machen (bis zum nächsten Reboot)
-e 2

Nach dem Anlegen der Regeldatei werden die Regeln geladen:

sudo augenrules --load

6.3 Auswertung mit aureport und ausearch

# Zusammenfassenden Bericht erzeugen
sudo aureport

# Nur fehlgeschlagene Ereignisse anzeigen
sudo aureport --failed

# Alle Ereignisse zum Schlüssel "identity" anzeigen
sudo ausearch -k identity --interpret | less

# Logins der letzten 24 Stunden
sudo aureport --login --start today

# Änderungen an /etc/sudoers suchen
sudo ausearch -k sudoers -i

7. Weitere Maßnahmen

Die bisher beschriebenen Maßnahmen bilden eine solide Grundlage. Die folgenden ergänzenden Mechanismen runden die Härtung ab und schließen weitere Angriffsvektoren.

7.1 AIDE – File Integrity Monitoring

AIDE (Advanced Intrusion Detection Environment) erstellt eine Datenbank mit Checksummen und Metadaten kritischer Systemdateien. Bei regelmäßigen Vergleichen kann erkannt werden, ob Dateien unerwartet verändert wurden – ein wichtiger Indikator für eine Kompromittierung.

sudo apt install aide

# Initiale Datenbank erstellen (dauert einige Minuten)
sudo aideinit

# Datenbank aktivieren
sudo cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

# Prüfung durchführen (Abweichungen werden ausgegeben)
sudo aide --check

# Cronjob für tägliche Prüfung einrichten
echo "0 3 * * * root /usr/bin/aide --check | mail -s 'AIDE Report' admin@example.com" \
  | sudo tee /etc/cron.d/aide

7.2 logwatch – Log-Zusammenfassungen

logwatch analysiert täglich die Systemlogs und verschickt eine übersichtliche Zusammenfassung per E-Mail. Damit werden ungewöhnliche Ereignisse – wie gehäufte fehlgeschlagene SSH-Logins oder Sudo-Eskalationen – schnell sichtbar, ohne dass Logs manuell durchsucht werden müssen.

sudo apt install logwatch

# Konfigurationsdatei anpassen
sudo cp /usr/share/logwatch/default.conf/logwatch.conf /etc/logwatch/conf/

# Relevante Einstellungen in /etc/logwatch/conf/logwatch.conf:
# Output = mail
# MailTo = admin@example.com
# Detail = Med
# Range = yesterday

# Manuell ausführen (zum Testen)
sudo logwatch --output stdout --detail med

7.3 Kernelparameter: ASLR

Address Space Layout Randomization (ASLR) randomisiert die Speicheradressen von Stack, Heap und Bibliotheken, was die Ausnutzung von Speicherkorrumpierungsfehlern erheblich erschwert. Auf modernen Linux-Systemen ist ASLR standardmäßig aktiv, sollte aber explizit auf den maximalen Wert gesetzt werden:

# ASLR-Status prüfen (0=aus, 1=partiell, 2=voll)
cat /proc/sys/kernel/randomize_va_space

# Vollständiges ASLR aktivieren
echo "kernel.randomize_va_space = 2" | sudo tee /etc/sysctl.d/99-aslr.conf
sudo sysctl -p /etc/sysctl.d/99-aslr.conf

7.4 /tmp und /var/tmp mit noexec mounten

Verzeichnisse wie /tmp und /var/tmp werden häufig von Angreifern genutzt, um schädliche Skripte hochzuladen und auszuführen. Durch das Mount-Flag noexec wird die direkte Ausführung von Dateien aus diesen Verzeichnissen unterbunden. Ergänzend verhindert nosuid die Ausführung von SUID-Binaries aus diesen Pfaden.

# /etc/fstab – Einträge für gehärtete Mounts
# WARNUNG: Erst prüfen, ob Anwendungen diese Verzeichnisse für ausführbare Dateien nutzen

tmpfs   /tmp        tmpfs   defaults,nosuid,nodev,noexec,size=512M  0 0
tmpfs   /var/tmp    tmpfs   defaults,nosuid,nodev,noexec,size=256M  0 0
tmpfs   /dev/shm    tmpfs   defaults,nosuid,nodev,noexec            0 0

# Mounts neu einlesen ohne Reboot
sudo mount -o remount /tmp
sudo mount -o remount /var/tmp

Vor dem produktiven Einsatz sollte geprüft werden, ob installierte Anwendungen – insbesondere PHP-Anwendungen, bestimmte Datenbanken oder Build-Systeme – ausführbare Dateien in /tmp ablegen. In diesem Fall sind Anpassungen der Anwendungskonfiguration erforderlich, bevor das Flag gesetzt wird.

7.5 Kontinuierliche Überprüfung mit lynis

Linux-Härtung ist kein einmaliger Vorgang, sondern ein kontinuierlicher Prozess. Neue Schwachstellen werden täglich entdeckt, Konfigurationen driften im Laufe der Zeit ab, und neue Dienste erweitern die Angriffsfläche. Empfehlenswert ist daher ein regelmäßiger Audit mit lynis, das eine automatisierte Überprüfung anhand von Best Practices durchführt:

sudo apt install lynis

# Vollständigen Audit ausführen
sudo lynis audit system

# Ergebnis-Score und Empfehlungen werden am Ende ausgegeben
# Bericht liegt unter /var/log/lynis.log

Die in diesem Artikel beschriebenen Maßnahmen bilden in ihrer Gesamtheit eine mehrschichtige Verteidigung, die dem CIS Benchmark Level 1 für Ubuntu und Debian entspricht. Für besonders sicherheitskritische Umgebungen empfiehlt sich zusätzlich die Lektüre des CIS Benchmark Level 2 sowie spezialisierter Härteleitfäden für die eingesetzten Anwendungen. Regelmäßige Audits, ein strukturiertes Patch-Management und die konsequente Anwendung des Least-Privilege-Prinzips sind die drei wichtigsten Säulen einer dauerhaft sicheren Linux-Infrastruktur.