Debian/Ubuntu 22.04 LTS härten: Auditd, SSH, systemd‑Profile und Checkliste

In diesem Beitrag geht es darum, wie Sie Debian/Ubuntu 22.04 LTS härten, konkret mit auditd für forensische Audit‑Logs, einem robusten SSH‑Setup und systemd‑Sicherheitsprofilen (systemd ist der Linux‑Init‑ und Service‑Manager). Ziel ist ein praxisfähiger Leitfaden: Voraussetzungen, typische Fehlerquellen, Prüfabläufe, konkrete Konfigurationsbeispiele und Rückfallstrategien. Die Anleitung richtet sich an Administratoren, System Engineers und Operatoren, die produktive Server zuverlässig betreiben müssen.

Debian/Ubuntu 22.04 LTS härten: Warum Härtung auf LTS‑Servern wichtig ist

Debian/Ubuntu 22.04 LTS ist eine weit verbreitete Plattform für Server. LTS steht für Long Term Support und bedeutet längere Sicherheitsupdates; dennoch schützt das allein nicht vor Fehlkonfigurationen, Angriffsvektoren oder Compliance‑Anforderungen. Härtung reduziert Angriffsflächen, verbessert Nachvollziehbarkeit (Audit) und erleichtert Incident Response.

Wichtig: Härtung ist kein einmaliger Schritt, sondern ein Betriebsprozess. Änderungen müssen getestet, dokumentiert und rückrollbar sein.

Übersicht: Fokusbereiche dieses Artikels

• Auditd einrichten und Audit‑Policies definieren — für Nachvollziehbarkeit und Compliance.
• SSH absichern — Authentifizierung, Key‑Management, Protokolle und Session‑Kontrolle.
• systemd‑Sicherheitsprofile (Sandboxing) — Dienstgranularität, Privilegienreduktion und Exploit‑Containment.
• Hardware‑Betrieb: LVM‑Snapshots, Disk‑I/O, Boot‑Recovery und Troubleshooting.
• Log‑Zentralisierung, TLS‑Forwarding und Integritätsstrategien für Audit‑Daten.
• Prüf- und Rollback‑Strategien sowie eine praktikable Checkliste für den Betrieb.

Auditd: Grundlagen, Nutzen und typische Einsatzszenarien

Auditd ist der Linux Audit Daemon (auditd). Er sammelt sicherheitsrelevante Ereignisse (z. B. file access, execve, SELinux/Auditing Hooks) und erzeugt Audit‑Logs, die für Forensik, Compliance (z. B. ISO, PCI) und Intrusion‑Detection benötigt werden. Auditd unterscheidet sich von syslog/journald: Audit‑Events sind strukturierter und für Nachweiszwecke weniger verlustanfällig.

Voraussetzungen und Designentscheidungen

Vor Installation prüfen Sie Festplattenplatz, zentralen Logpfad (z. B. remote syslog/audit server) und Ressourcen: auditd kann bei hoher Regelanzahl I/O‑Last erzeugen. Entscheiden Sie, ob Audit‑Logs lokal bleiben, remote an einen Logserver (z. B. rsyslog/ELK/Graylog) oder an ein SIEM weitergeleitet werden sollen.

Installation und Basiskonfiguration

Installieren und aktivieren Sie auditd:

sudo apt update
sudo apt install -y auditd audispd-plugins
sudo systemctl enable --now auditd

Standardmäßig liegt die Konfiguration in /etc/audit/auditd.conf. Wichtige Parameter sind LogFile (Pfad), max_log_file (Rotation in MB) und max_log_file_action (z. B. rotate oder keep_logs). Für produktive Systeme empfiehlt sich ein konservativer Wert für max_log_file und eine Weiterleitung der Logs.

# Beispiel: /etc/audit/auditd.conf (wichtige Zeilen)
log_file = /var/log/audit/audit.log
max_log_file = 200
max_log_file_action = rotate
space_left_action = SYSLOG
action_mail_acct = root

Audit‑Regeln: Was gehört ins Regelwerk?

Gute Audit‑Regeln konzentrieren sich auf:

• Authentifizierungsereignisse (sshd, sudo, su)
• Änderungen an /etc (Konfigurationsdateien)
• Binaries mit SUID/SGID
• kritische Dateien/Verzeichnisse (z. B. Anwendungskonfigs, Secrets‑Stores)
• execve für sensitives Prozessstart‑Monitoring (mit Bedacht, da volumenintensiv)

Beispiel für eine audit.rules Datei:

# /etc/audit/rules.d/50-monitor.rules
# Authentication events (sshd, sudo)
-w /var/log/auth.log -p wa -k auth_changes

# /etc modifications
-w /etc/ -p wa -k etc_changes

# SUID/SGID binaries
-w /usr/bin/sudo -p x -k privileged

# Monitor sensitive config file
-w /etc/ssh/sshd_config -p wa -k sshd_config

# execve for specific users (example)
-a always,exit -F arch=b64 -S execve -F auid>=1000 -F auid!=4294967295 -k user_exec

Warum das funktioniert: Auditd setzt Kernel‑Hooks, die selbst bei Root‑Änderungen Ereignisse erzeugen. Wann es scheitert: Zu breite execve‑Regeln führen schnell zu voluminösen Logs und Performance‑problemen. Testen Sie Regeln sukzessive in einer Testumgebung.

Zentralisierung und Integrität

Forwarden Sie Audit‑Logs an einen zentralen Logserver oder SIEM. Achten Sie auf Transportverschlüsselung (TLS) und Integritätsprüfungen (z. B. signierte Logrotation oder Write‑once‑Storage). Für kurzfristige Forensik sind lokal verbleibende Logs nützlich, dauerhaft gehören sie aber in zentrale, durchsuchbare Stores.

Audit-Forwarding mit rsyslog über TLS

Auditd selbst hat begrenzte native Remote‑Capabilities; ein bewährter Ansatz ist, das Audit‑Log lokal zu behalten und rsyslog die Datei überwachen zu lassen (imfile‑Modul), dann TLS‑gesichert an einen zentralen Rsyslog/SIEM‑Server zu senden. Das trennt Erfassung (auditd) von Transport (rsyslog) und erlaubt Wiederaufnahme bei Netzwerkproblemen.

# /etc/rsyslog.d/10-audit-imfile.conf (Client)
module(load="imfile")
input(type="imfile"
      File="/var/log/audit/audit.log"
      Tag="audit"
      Severity="info"
      PersistStateInterval="200")

# TLS forwarding (Auszug)
*.* action(type="omfwd" Target="logs.example.internal" Port="6514" Protocol="tcp" StreamDriver="gtls" StreamDriverMode="1" StreamDriverAuthMode="x509/name" StreamDriverPermittedPeers="logs.example.internal")

Auf dem zentralen Rsyslog/SIEM folgen Server‑Zertifikate, Client‑Zertifikatverifikation und passende Firewall‑Regeln. Testen Sie, ob bei Netzunterbrechung die Dateiüberwachung bufferet und wiederaufnimmt.

SSH härten: Authentifizierung, Keys, Protokoll und Betriebsregeln

SSH bleibt das Standardzugangsprotokoll für Linux‑Administration. Schwachstellen entstehen durch schwache Keys, Standardkonfigurationen, offene Root‑Logins und fehlende Session‑Kontrolle. Ein gehärtetes SSH schützt vor Credential‑Diebstahl und seitlichem Zugriff.

Präventive Maßnahmen

Grundregeln:

• Deaktivieren Sie Root‑Login über SSH; nutzen Sie sudo mit Audit‑Tracking.
• Erlauben Sie nur moderne Kryptoalgorithmen (z. B. Ed25519, ECDSA), deaktivieren Sie veraltete Ciphers.
• Begrenzen Sie Authentifizierungsversuche und setzen Sie Fail2ban oder ähnliche Schutzmechanismen ein.
• Nutzen Sie Bastion/Jump‑Host‑Architektur statt direktem SSH‑Zugang aus dem Internet.

Konkrete sshd_config‑Optimierungen

Bearbeiten Sie /etc/ssh/sshd_config. Hier ein empfohlenes Minimalset:

# /etc/ssh/sshd_config (Auszug)
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
AllowUsers adminuser
ClientAliveInterval 300
ClientAliveCountMax 2
PermitEmptyPasswords no
KexAlgorithms curve25519-sha256@libssh.org
HostKey /etc/ssh/ssh_host_ed25519_key
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com
LogLevel VERBOSE

Erläuterung: PasswordAuthentication no zwingt Key‑Based Login; PermitRootLogin no verhindert direkte Rootzugriffe; LogLevel VERBOSE erzeugt verwertbare Audit‑Events (und sollte mit Auditd korreliert werden). Wann es scheitert: Wenn alle Admins plötzlich keinen Key haben – planen Sie Übergänge und Testaccounts.

Key‑Management und Rotation

Organisieren Sie Keys zentral (z. B. über SSH CA oder ein Identity Management). SSH Certificate Authority (SSH CA) ermöglicht kurzlebige Zertifikate statt dauerhafter authorized_keys. Rotation ist wichtig: bestehende Keys regelmäßig prüfen und zurückziehen, wenn Mitarbeiter wechseln.

# Beispiel: ssh-keygen für Ed25519
ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""

# Signieren eines Nutzerkeys mit einer SSH-CA (Kurzbeispiel)
ssh-keygen -s /etc/ssl/ssh/ca_key -I user-cert -n username -V +52w user_key.pub

systemd‑Sicherheitsprofile: Dienst‑Sandboxing und sichere Unit‑Konfiguration

systemd bietet zahlreiche Sicherheitsoptionen direkt auf Unit‑Ebene: ProtectSystem, ProtectHome, PrivateTmp, NoNewPrivileges, CapabilityBoundingSet usw. Diese Einstellungen reduzieren Rechte eines Dienstes und begrenzen Auswirkungen bei Kompromittierung.

Grundprinzip: Least‑Privilege für Dienste

Jeder Dienst bekommt nur die Rechte, die er tatsächlich benötigt. systemd‑Drop‑ins (Directory: /etc/systemd/system/.d/*.conf) sind ein sicheres Mittel, um Änderungen zu pflegen ohne die Paketdatei zu ändern.

Beispiel: systemd Drop‑In zur Härtung einer Web‑Service‑Unit

# /etc/systemd/system/myweb.service.d/hardening.conf
[Service]
PrivateTmp=true
ProtectSystem=full
ProtectHome=yes
NoNewPrivileges=true
RestrictAddrFamilies=AF_INET AF_INET6 AF_UNIX
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
ReadOnlyPaths=/etc/myweb
# Optional: Limit CPU/Memory
MemoryMax=500M
CPUQuota=70%

Warum das funktioniert: ProtectSystem=full macht /usr und /boot read‑only für den Dienst; PrivateTmp isoliert temporäre Dateien; NoNewPrivileges verhindert SetUID/execve nach Privilege‑Erhöhung. Wann es scheitert: Einige Anwendungen brauchen Schreibzugriff auf /usr oder globale tmp‑Verzeichnisse; testen Sie Drop‑ins schrittweise.

Testing und Canary‑Deployment

Nutzen Sie Canary‑Hosts oder Rollouts mit niedrigerer Last. Für systemd‑Änderungen empfiehlt sich:

1. Erstellen des Drop‑ins
2. systemctl daemon-reload
3. Restart im Wartungsfenster
4. Monitoring der Startzeit, OOM‑Events und Anwendungsspezifischer Errors

sudo systemctl daemon-reload
sudo systemctl restart myweb.service
journalctl -u myweb.service -f

Hardware: LVM‑Snapshots, Disk‑I/O und Boot‑Recovery

Die Hardware‑Ebene beeinflusst Härtung und Betrieb stark: Vollgelaufene Partitionen, hohe I/O‑Latenzen oder ein fehlerhaftes Boot‑Device können Härtungsmaßnahmen wirkungslos machen oder kritische Rollbacks verhindern. Hier einige bewährte Handlungsfelder und Troubleshooting‑Schritte.

Platzplanung und Monitoring

Audit‑Logs wachsen. Planen Sie dedizierte Partitionen oder LVM‑Volumes für /var/log und /var/log/audit. Überwachen Sie freien Speicher, inode‑Nutzung und I/O mit einfachen Tools:

# freien Speicher prüfen
df -h /var/log
# I/O Belastung beobachten
iostat -xz 1 10
# Top Prozesse nach I/O
iotop -oPa

Typische Stolperfalle: logrotate deaktiviert oder fehlerhaft → Volle Log‑Partition → Dienste hängen.

LVM Snapshot als Rollback‑Option

Vor umfangreichen Änderungen (systemd‑Drop‑ins, SSH‑Massivrollout, Audit‑Regelupdate) erstellen Sie einen LVM‑Snapshot des betroffenen Volumes. Snapshots erlauben schnellen Restore ohne Backup‑Restore‑Zeit.

# Beispiel: Snapshot anlegen (root-Volume lv_root im vg0)
sudo lvcreate --size 2G --snapshot --name root_snap /dev/vg0/root

# Änderungen durchführen ...

# Snapshot zurückspielenvia lvconvert (oder Mount snapshot und rsync zurück)
sudo lvconvert --merge /dev/vg0/root_snap
# Danach Neustart erforderlich
sudo reboot

Vorsicht: Snapshots verbrauchen Speicher; bei intensiver Schreiblast wachsen sie schnell und können das Volume füllen. Invalid snapshots belasten die Performance.

Boot‑Recovery und Out‑of‑Band

Stellen Sie sicher, dass IPMI/iLO/DRAC oder Provider‑Konsole funktioniert. Ohne Out‑of‑Band‑Zugang können Sie bei Sperrungen (z. B. SSH) nur schwer eingreifen. Dokumentieren Sie Rescue‑Accounts und halten Sie Rescue‑Keys getrennt von der zentralen Automatisierung.

NTP/Krony und Zeitstempel‑Integrität

Konsistente Zeit ist für Audit und Forensik kritisch. Verwenden Sie chrony oder systemd‑timesyncd, validieren Sie NTP‑Peers und Alarmierung bei Drift. Timestamps mit Abweichungen erschweren Log‑Korrelierung.

# Chrony Status prüfen
chronyc tracking
chronyc sources -v

# systemd-timesyncd Status
timedatectl status

Prüfungen, Monitoring und typische Stolperfallen

Vor Änderungen prüfen Sie Basiszustand: Kernel‑Version, installierte Pakete, aktive Dienste und aktuelle Audit‑Regeln. Typische Stolperfallen sind:

• Übermäßig breite auditd‑Regeln → Log‑Explosion
• sshd_config zu restriktiv → Admins ausgesperrt
• systemd‑Restriktionen, die legitime Dateien/Socket‑Zugriffe blockieren
• Mangelnde Log‑Zentralisierung → Verlust forensischer Daten
• Fehlende Out‑of‑Band‑Konsole → schwierige Wiederherstellung

Wesentliche Prüfbefehle

# auditd Status und Regeln
sudo systemctl status auditd
sudo auditctl -l

# SSH Überprüfen
sshd -t
sudo systemctl reload sshd

# systemd-Unit check
systemd-analyze blame
systemctl status myweb.service
journalctl -u myweb.service -n 200

# Disk und Snapshotchecks
lvs -a
df -h /var/log
iostat -xz 1 5

Rollback‑Strategien und Notfallzugang

Planen Sie für jede Änderung eine Rückrolloption. Für SSH‑Änderungen empfiehlt sich ein paralleler Admin‑Account mit Key‑Access, der nicht an die neuen Regeln gebunden ist, oder Out‑of‑Band Konsole (iLO, DRAC, IPMI). Für systemd‑Änderungen bewahren Sie das Drop‑in als Datei mit Versionskennzeichnung und erstellen Sie Snapshots (LVM/LUKS) oder System‑Backups vor kritischen Änderungen.

# Beispiel Rollback systemd: Drop-in entfernen und daemon neu laden
sudo rm /etc/systemd/system/myweb.service.d/hardening.conf
sudo systemctl daemon-reload
sudo systemctl restart myweb.service

Erweiterte Praxis-Checkliste: Schritt für Schritt

Diese Checkliste ist für den produktiven Rollout gedacht. Testen Sie jeden Schritt in einer Staging‑Umgebung.

1. Sichern: aktuelle System‑ und Konfigurationsbackups erstellen, Snapshot falls möglich.
2. Platz & I/O prüfen: /var/log auf separatem Volume, Monitoring setzen.
3. Auditd: installieren, Basisregeln anlegen, lokale Tests durchführen.
4. Logs: imfile‑Monitoring und TLS‑Forwarding zu zentralem Logsystem konfigurieren und TLS prüfen.
5. SSH: Key‑Based Auth aktivieren, RootLogin deaktivieren, Testaccounts setzen und Notfall‑Key hinterlegen.
6. systemd: Drop‑ins erstellen, Canary‑Rollout auf Testhosts durchführen.
7. Rollback: LVM Snapshot erstellen, Restore‑Prozedur dokumentieren.
8. Monitoring: Alerts für Audit‑Lücken, SSH‑Fehlversuche, Disk‑Füllstände und Dienstabbrüche konfigurieren.
9. Review & Rotation: Key‑Rotation, Audit‑Regelreview, systemd‑Policy‑Review regelmäßig planen.
10. Dokumentation: alle Änderungen, Tests und Rückfallpfade in einem zentralen Runbook dokumentieren.

Sicherheits‑Betriebswissen und Wartung

Wartung heißt: periodische Regelreviews, Log‑Retention‑Prüfung und Incident‑Übungen. Audit‑Regeln altern mit dem Dienst‑Verhalten; führen Sie nach Releases und großen Updates Prüfungen durch. Setzen Sie automatisierte Tests für sshd_config (sshd -t checks) und systemd‑Unit‑Start in CI/CD für Infrastruktur‑Änderungen ein. Planen Sie auch Kapazitätsreviews für Log‑Volumes und Snapshot‑Ressourcen.

Konkrete Troubleshooting‑Szenarien

Auditd erzeugt hohe I/O‑Last

Ursache: zu generische execve‑Regeln oder Monitoring von sehr aktiven Verzeichnissen. Sofortmaßnahme: Regeln schrittweise abschalten, write‑back zu zentralem Logserver prüfen, Auditd pausieren nur im Notfall. Langfristig: Sampling‑Regeln, gezieltes Prozessmonitoring und Filterung.

Admins ausgesperrt nach sshd_config Änderung

Rollback: Zugang über Out‑of‑Band oder Console, oder Audit‑Schritt zur Reproduktion: restore of /etc/ssh/sshd_config aus Backup und systemctl restart sshd. Zur Vorbeugung: Immer einen fallback key auf einem dedizierten Rescue‑User halten, der nicht von Automation verwaltet wird.

Service startet nicht nach systemd Drop‑in

Prüfen Sie journalctl -u für Fehler zu den gesetzten Restriktionen (z. B. Permission denied auf Pfade). Entfernen Sie temporär das Drop‑in, reload und restart, um den Dienst wiederherzustellen. Nutzen Sie strace oder fehlerspezifische Logs, falls nötig.

Fazit

Debian/Ubuntu 22.04 LTS härten bedeutet mehr als einzelne Konfigurationsänderungen: Es ist ein abgestuftes Betriebskonzept. auditd liefert Nachvollziehbarkeit, gehärtetes SSH sichert Zugänge, systemd‑Sicherheitsprofile begrenzen Risiken auf Dienstebene und Hardware/Betriebsmaßnahmen sichern Verfügbarkeit. Testen Sie jede Änderung kontrolliert, planen Sie Rollbacks und integrieren Sie Härtung in Ihren Lifecycle‑Prozess (Release, Monitoring, Review). So minimieren Sie Ausfallrisiken und schaffen eine wartbare Sicherheitsbasis.

Empfohlene nächste Schritte

• Einrichten eines Test‑Clusters und Automatisierung der Prüfschritte.
• Integration von Audit‑Logs in SIEM und Alerting mit TLS‑gesichertem Forwarding.
• Dokumentation der systemd‑Drop‑ins, LVM‑Snapshot‑Prozeduren und Key‑Management‑Policies.

Eine strukturierte Implementierung reduziert Betriebsrisiken und erleichtert die Einhaltung von Compliance‑Anforderungen.

Für dieses Thema sind auch Auditd Konfigurieren und Systemd Sicherheitsprofile wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.