Linux Server Audit: Diese Punkte sollten Unternehmen regelmäßig prüfen

Der Server lief seit vier Jahren stabil. Dann kam ein unerwarteter Neustart nach einem Stromausfall, und plötzlich startete ein wichtiger Dienst nicht mehr. Die Fehlersuche dauerte Stunden, weil niemand genau wusste, welche Konfigurationen über die Jahre von Hand vorgenommen wurden, welche Abhängigkeiten bestanden und welcher Patchstand eigentlich aktuell war. Solche Situationen sind keine Seltenheit in KMU, wo Server oft organisch wachsen und von verschiedenen Händen gepflegt werden.

Genau hier setzt ein regelmäßiger Linux Server Audit an. Er ist keine einmalige Sicherheitsprüfung, sondern eine Bestandsaufnahme, die auf die Reproduzierbarkeit und Stabilität Ihrer Infrastruktur abzielt. Meine Leitfrage bei jedem Server, den ich betreue oder analysiere, ist immer dieselbe: "Kann jemand anderes diesen Server neu aufsetzen – aus Code, in definierter Zeit?" Wenn die Antwort nicht klar "Ja" lautet, gibt es Handlungsbedarf.

Ein Audit hilft Ihnen, genau diese Lücken zu identifizieren, bevor sie zu einem echten Problem werden. Es geht darum, das Wissen, das heute in Köpfen und auf gewachsenen Maschinen steckt, in eine überprüfbare, dokumentierte und idealerweise versionierte Form zu bringen. Was gehört also zu einer solchen Prüfung?

Patchstand und Systemaktualität prüfen

Ein veralteter Patchstand ist ein offenes Einfallstor für Angreifer und die Ursache für unzählige Kompatibilitätsprobleme. Ich sehe immer wieder Server, die seit Monaten oder sogar Jahren keine Updates mehr erhalten haben. Das Argument ist oft "Never change a running system", doch die Realität zeigt: Ein nicht gepatchtes System ist ein tickende Zeitbombe.

Beim Audit prüfe ich zuerst den aktuellen Patchstand des Betriebssystems und aller installierten Pakete. Ein einfaches Kommando wie apt update && apt list --upgradable auf Debian/Ubuntu-Systemen oder dnf check-update auf RHEL/CentOS-Derivaten gibt einen schnellen Überblick. Wichtiger als die reine Liste ist die Frage: Gibt es eine Strategie für Updates? Werden sie regelmäßig eingespielt? Und noch wichtiger: Gibt es eine Testumgebung, in der größere Updates vorab geprüft werden?

Die Herausforderung liegt oft nicht im Update selbst, sondern in den potenziellen Abhängigkeitskonflikten oder Breaking Changes, die es mit sich bringen kann. Ein Audit deckt auf, ob diese Risiken bekannt sind und wie damit umgegangen wird.

Benutzer, Gruppen und Zugriffsrechte

Wer hat Zugriff auf den Server? Diese Frage ist fundamental. Beim Audit überprüfe ich alle aktiven Benutzerkonten, deren Gruppenmitgliedschaften und vor allem die Sudo-Berechtigungen. Oft finden sich hier noch alte Konten von ehemaligen Mitarbeitern oder Testbenutzer, die nie gelöscht wurden.

Ich nutze Befehle wie getent passwd und getent group, um einen Überblick zu bekommen. Für Sudo-Berechtigungen ist sudo -l als jeder Benutzer hilfreich, um zu sehen, welche Befehle er ohne Passwort oder als Root ausführen darf. Das Prinzip der geringsten Rechte (Principle of Least Privilege) sollte hier konsequent angewendet werden. Jeder Benutzer sollte nur die Berechtigungen haben, die er für seine Aufgaben unbedingt benötigt.

Ein häufiges Problem sind auch zu weitreichende Dateiberechtigungen, die es einem Angreifer nach dem Einbruch in ein weniger privilegiertes Konto ermöglichen, auf sensible Daten zuzugreifen oder Konfigurationen zu manipulieren. Hier hilft ein Blick auf kritische Verzeichnisse wie /etc, /var/www oder Datenverzeichnisse mit ls -la.

SSH-Konfiguration und Fernzugriff

SSH ist das Tor zu Ihrem Server. Eine unsichere Konfiguration ist eine Einladung für Angreifer. Ich prüfe die /etc/ssh/sshd_config auf folgende Punkte:

• Ist der Root-Login deaktiviert (PermitRootLogin no)?
• Ist die Passwort-Authentifizierung deaktiviert (PasswordAuthentication no)?
• Wird nur die schlüsselbasierte Authentifizierung verwendet?
• Gibt es eine Whitelist für erlaubte Benutzer (AllowUsers) oder Gruppen (AllowGroups)?
• Wird ein nicht-Standard-Port verwendet (optional, aber eine zusätzliche Hürde)?

Ein Blick in die ~/.ssh/authorized_keys-Dateien der Benutzer zeigt, welche Schlüssel Zugriff haben. Es ist wichtig, dass diese Schlüssel sicher verwaltet werden und bei Bedarf widerrufen werden können. Eine detailliertere Betrachtung der SSH-Sicherheit finden Sie in meinem Artikel SSH-Sicherheit auf Linux-Servern: Von Basics bis zur Härtung.

Firewall-Regeln und Netzwerkdienste

Welche Dienste sind von außen erreichbar? Eine restriktive Firewall ist essenziell. Ich überprüfe, ob eine Firewall (z.B. UFW, firewalld, iptables) aktiv ist und welche Regeln konfiguriert sind. Nur die absolut notwendigen Ports sollten geöffnet sein.

Befehle wie ufw status oder firewall-cmd --list-all geben Aufschluss. Zusätzlich prüfe ich mit netstat -tulpen oder ss -tulpen, welche Dienste auf welchen Ports lauschen und ob diese tatsächlich benötigt werden. Ein Webserver sollte beispielsweise nur auf Port 80 und 443 lauschen, nicht aber auf einen internen Datenbankport, der nur für lokale Verbindungen gedacht ist.

Oft finde ich hier noch alte Regeln für Dienste, die längst nicht mehr existieren, oder offene Ports, die aus Bequemlichkeit während der Einrichtung geöffnet und nie wieder geschlossen wurden. Jede unnötig offene Tür ist ein Risiko.

Backup-Strategie und Restore-Fähigkeit

Ein Backup ist nur so gut wie seine Wiederherstellbarkeit. Es reicht nicht, einfach nur Daten zu sichern. Beim Audit frage ich nicht nur: "Gibt es ein Backup?", sondern vor allem: "Wurde der Restore jemals erfolgreich getestet?"

Ich prüfe die Konfiguration der Backup-Lösung: Was wird gesichert? Wie oft? Wie lange werden die Backups aufbewahrt? Wo werden sie gespeichert (On-Site, Off-Site)? Und ganz wichtig: Gibt es eine Dokumentation des Restore-Prozesses? Ohne einen getesteten Restore-Plan ist ein Backup im Ernstfall wertlos.

Ein weiterer Aspekt ist die Unterscheidung zwischen Datenbackup und Systemreproduzierbarkeit. Ein Datenbackup stellt Ihre Dateien wieder her. Es stellt aber nicht automatisch die Konfigurationen, Abhängigkeiten und das Betriebssystem selbst wieder her, die für den Betrieb der Anwendung notwendig sind. Hier trennt sich die Spreu vom Weizen, wenn es um die Frage der schnellen Wiederherstellung nach einem Totalausfall geht.

Monitoring und Log-Management

Sehen Sie, wenn etwas schiefläuft, bevor es Ihre Kunden merken? Ein funktionierendes Monitoring ist die Frühwarnsystem Ihrer Infrastruktur. Ich prüfe, ob überhaupt ein Monitoring-System (z.B. Prometheus, Zabbix, Nagios) im Einsatz ist und welche Metriken erfasst werden.

Wichtige Punkte sind die Überwachung von CPU-Auslastung, Arbeitsspeicher, Festplattenspeicher, Netzwerktraffic und vor allem der Status kritischer Dienste. Werden bei Schwellenwertüberschreitungen oder Dienstausfällen Benachrichtigungen versendet? Und wer erhält diese?

Eng damit verbunden ist das Log-Management. System- und Anwendungslogs sind entscheidend für die Fehlersuche und die Erkennung von Sicherheitsvorfällen. Ich prüfe, ob Logs rotiert werden, um die Festplatte nicht zu überfüllen, und ob sie zentral gesammelt und analysiert werden (z.B. mit einem ELK-Stack oder Grafana Loki). Ein Blick in journalctl oder die Logdateien unter /var/log kann schnell Aufschluss über den Zustand des Systems geben.

Speicherplatz und Dateisystemintegrität

Volle Festplatten sind ein häufiger Grund für unerklärliche Dienstausfälle. Ich prüfe mit df -h den belegten Speicherplatz der Dateisysteme. Aber nicht nur der belegte Platz ist relevant, sondern auch die Anzahl der Inodes (Dateiknoten) mit df -i. Viele kleine Dateien können die Inodes erschöpfen, selbst wenn noch viel freier Speicherplatz vorhanden ist.

Zusätzlich werfe ich einen Blick auf die Dateisystemintegrität. Obwohl moderne Dateisysteme wie ext4 oder XFS sehr robust sind, können Stromausfälle oder Hardwarefehler zu Korruption führen. Ein Audit kann hier keine tiefgehende Hardwareprüfung ersetzen, aber es kann auf Auffälligkeiten in den Logs hinweisen, die auf Probleme mit dem Speicher hindeuten.

SSL/TLS-Zertifikate und Dienste

Abgelaufene SSL/TLS-Zertifikate sind ein Klassiker, der immer wieder zu Ausfällen führt und das Vertrauen der Nutzer untergräbt. Ich prüfe die Gültigkeit aller auf dem Server verwendeten Zertifikate, insbesondere für Webserver (nginx, Apache) und andere Dienste, die TLS nutzen.

Ein Befehl wie openssl x509 -in /path/to/your/cert.pem -text -noout | grep "Not After" gibt schnell Auskunft über das Ablaufdatum. Wichtiger ist aber die Frage: Gibt es einen Prozess für die Erneuerung der Zertifikate? Wird Let's Encrypt verwendet und funktioniert die automatische Erneuerung? Oder müssen Zertifikate manuell ausgetauscht werden, was oft vergessen wird?

Parallel dazu prüfe ich die Liste der laufenden Dienste mit systemctl list-units --type=service. Sind alle diese Dienste notwendig? Gibt es alte, nicht mehr benötigte Dienste, die noch laufen und Ressourcen verbrauchen oder potenzielle Angriffsflächen bieten?

Dokumentation und Abhängigkeiten

Der wohl kritischste Punkt für die Reproduzierbarkeit: Ist der Server dokumentiert? Und zwar nicht nur in einem Wiki, das seit Jahren nicht aktualisiert wurde, sondern idealerweise in Codeform. Ein "Snowflake-Server" ist ein Server, der durch manuelle Änderungen über die Zeit einzigartig geworden ist und sich nicht einfach nachbauen lässt.

Ich suche nach Anzeichen für Infrastructure as Code: Gibt es Ansible-Playbooks, Terraform-Module oder Dockerfiles, die den Zustand des Servers oder seiner Anwendungen beschreiben? Wenn nicht, ist die Dokumentation oft lückenhaft oder veraltet. Ich frage nach den Abhängigkeiten: Welche externen Dienste oder Systeme benötigt dieser Server, um zu funktionieren? Welche anderen Server sind von ihm abhängig?

Ein Audit deckt auf, wie hoch der "Bus-Faktor" ist – wie viele Personen das gesamte Wissen über den Server besitzen. Mein Ziel ist es, dieses Wissen zu objektivieren und in eine Form zu bringen, die es jedem ermöglicht, den Server neu aufzusetzen. Das ist auch der Kern von Linux Server Hardening, da eine gut dokumentierte und reproduzierbare Infrastruktur auch sicherer ist.

Was ein Audit nicht leistet und wo seine Grenzen liegen

Ein Linux Server Audit ist eine Momentaufnahme und eine Bestandsaufnahme. Er identifiziert Schwachstellen, Konfigurationsfehler und Lücken in Prozessen. Er ist aber keine automatische Lösung für diese Probleme. Die Umsetzung der Empfehlungen erfordert Zeit und Fachwissen.

Ein Audit ist auch kein umfassender Penetrationstest. Er konzentriert sich auf die interne Konfiguration und die Prozesse, nicht auf aktive Angriffe oder die Ausnutzung von Schwachstellen. Er gibt Ihnen eine Checkliste und eine Roadmap, aber er behebt die Probleme nicht von selbst. Ein Audit gibt auch keine Verfügbarkeits- oder Reaktionszusagen. Und ob die Wiederherstellung wirklich funktioniert, zeigt erst ein Restore-Test – der gehört in den laufenden Betrieb, nicht in die Momentaufnahme.

Was Sie als Nächstes tun können

Wenn Sie sich in einigen der genannten Punkte wiedererkennen, ist das ein guter Startpunkt. Beginnen Sie mit den einfachsten Prüfungen, wie dem Patchstand oder der Firewall-Konfiguration. Für eine umfassende und professionelle Bewertung Ihrer gesamten Infrastruktur empfehle ich eine Infrastruktur-Analyse. Dabei verbringe ich einen Tag vor Ort, um Ihre Systeme zu verstehen, die genannten Punkte zu prüfen und Ihnen einen detaillierten Risikobericht mit einer klaren Roadmap für die Reproduzierbarkeit und Härtung Ihrer Server zu liefern. Vorab bekommen Sie ein verbindliches Angebot; das Ergebnis zeigt Ihnen konkrete Schritte aufzeigt, wie Sie Ihre Server-Infrastruktur zukunftssicher und ohne mich nachbaubar machen können. Wer danach niemanden im Haus hat, der die Server laufend pflegt: Wie die laufende Linux-Server-Betreuung aussieht, steht auf einer eigenen Seite.