Sie möchten wissen, wie gut Ihre Linux-Server heute abgesichert sind? Der Server-Audit prüft Härtung, Updatestand, Zugänge und Backups und liefert eine priorisierte Befundliste.
Ein frisch installierter Linux-Server ist funktionsfähig, aber nicht gehärtet. Distributionen wählen Voreinstellungen, die auf möglichst vielen Systemen funktionieren. Ein aus dem Internet erreichbarer Server ist automatisierten Anmeldeversuchen und Scans ausgesetzt. Härtung reduziert die Angriffsfläche auf das, was der Server tatsächlich braucht.
Diese Checkliste fasst die wichtigsten Maßnahmen für Debian, Ubuntu und die RHEL-Familie zusammen. Jede Maßnahme hat einen Prüfbefehl und eine Referenz auf den BSI IT-Grundschutz. Die CIS Benchmarks behandeln dieselben Themen im Detail und eignen sich als Prüfmaßstab.
Inhalt
- Referenzen: CIS Benchmarks und BSI IT-Grundschutz
- Checkliste: Linux-Server härten
- SSH absichern
- Firewall und Netzwerkdienste
- Konten, Rechte und Kernel-Schutz
- Protokollierung, Zeit und Angriffserkennung
- Härtung prüfen: Lynis, OpenSCAP und Ubuntu Security Guide
- Häufige Fehler
- Unser Vorgehen bei WZ-IT
- Stand und Methodik
Referenzen: CIS Benchmarks und BSI IT-Grundschutz
| CIS Benchmarks | BSI IT-Grundschutz | |
|---|---|---|
| Herausgeber | Center for Internet Security (USA) | Bundesamt für Sicherheit in der Informationstechnik |
| Form | Konfigurationsempfehlungen je Produkt und Version, kostenlos als PDF | Bausteine mit Anforderungen, für Linux SYS.1.3 zusammen mit SYS.1.1 |
| Stufen | Level 1 (Basis, geringe Betriebsauswirkung), Level 2 (Defense in Depth), STIG-Profil in einzelnen Benchmarks | Basis-, Standard- und Anforderungen bei erhöhtem Schutzbedarf |
| Linux-Abdeckung | eigene Benchmarks unter anderem für Ubuntu, Debian, Red Hat Enterprise Linux | distributionsunabhängig |
| Automatisierbar | ja, über SCAP-Profile und Werkzeuge | teilweise, etwa mit dem ComplianceAsCode-Profil „BSI SYS.1.1 and SYS.1.3“ für RHEL 9; überwiegend organisatorische Umsetzung |
Quellen: CIS Benchmarks FAQ, CIS Ubuntu Linux, CIS Debian Linux, CIS Red Hat Enterprise Linux, BSI SYS.1.3, BSI SYS.1.1.
Laut CIS ist Level 1 eine Basisempfehlung, die sich zügig umsetzen lässt und die Leistung kaum beeinflusst. Level 2 gilt als Defense in Depth für Umgebungen, in denen Sicherheit Vorrang hat. Für die meisten Unternehmensserver ist Level 1 der realistische Maßstab, einzelne Level-2-Punkte kommen nach Risiko hinzu.
Checkliste: Linux-Server härten
| Nr. | Maßnahme | Prüfbefehl | BSI-Referenz |
|---|---|---|---|
| 1 | Unterstützte Version, Sicherheitsupdates aktuell | cat /etc/os-release, apt list --upgradable oder dnf updateinfo list --security |
OPS.1.1.3.A15 |
| 2 | Nicht benötigte Dienste und Pakete entfernt | systemctl list-unit-files --state=enabled |
SYS.1.1.A6 |
| 3 | Nur benötigte Ports offen | ss -tulpn |
SYS.1.1.A6, SYS.1.1.A19 |
| 4 | Lokale Firewall mit Freigaben nur für benötigte Verbindungen | nft list ruleset, ufw status verbose oder firewall-cmd --list-all |
SYS.1.1.A19 |
| 5 | SSH nur mit Schlüsseln, kein Root-Login mit Passwort | sshd -T, Werte für permitrootlogin und passwordauthentication |
SYS.1.3.A8 |
| 6 | Eindeutige Login-Namen, UIDs und GIDs | cut -d: -f1 /etc/passwd, cut -d: -f3 /etc/passwd, cut -d: -f3 /etc/group, jeweils mit sort und uniq -d |
SYS.1.3.A2 |
| 7 | Nur root mit UID 0 |
awk -F: '$3 == 0' /etc/passwd |
SYS.1.3.A2 |
| 8 | ASLR und NX aktiv | sysctl kernel.randomize_va_space (Wert 2), NX: dmesg nach „NX (Execute Disable)“ durchsuchen |
SYS.1.3.A4 |
| 9 | AppArmor oder SELinux aktiv mit Standardprofilen | aa-status oder getenforce |
SYS.1.3.A10 |
| 10 | Kein automatisches Einbinden von Wechseldatenträgern | Automount-Dienste und /etc/fstab prüfen |
SYS.1.3.A3 |
| 11 | Sicherheitsrelevante Ereignisse protokolliert | journalctl, Konfiguration von auditd oder rsyslog |
SYS.1.1.A10 |
| 12 | Zeitsynchronisation aktiv | timedatectl |
Voraussetzung für verwertbare Protokolle |
| 13 | Server im Monitoring | Alarm bei Dienstausfall, Speicherplatz, Zertifikaten | SYS.1.1.A23 |
| 14 | Regelmäßige Sicherheitsprüfung | Lynis oder OpenSCAP in festen Abständen | SYS.1.1.A24 |
SSH absichern
SSH ist auf fast jedem Server aus dem Internet erreichbar und damit ein häufiges Ziel automatisierter Anmeldeversuche. Das BSI fordert in SYS.1.3.A8, interaktive Fernzugriffe ausschließlich über SSH abzuwickeln und zur Authentifizierung vorrangig Zertifikate statt Passwörter zu verwenden.
Die relevanten Optionen in /etc/ssh/sshd_config laut OpenSSH-Handbuch:
PasswordAuthentication no: Der Standardwert istyes. Zusammen mitKbdInteractiveAuthentication noist die Anmeldung nur mit Schlüsseln möglich. Vorher den eigenen Schlüsselzugang testen.PermitRootLogin no: Der Standardwert istprohibit-password, Root darf sich dann noch mit Schlüssel anmelden. Mitnoerfolgt die Administration über persönliche Konten undsudo, was Aktionen einer Person zuordenbar macht.KbdInteractiveAuthentication no: verhindert Passwortabfragen über Keyboard-Interactive, Standard istyes.AllowGroups: beschränkt die Anmeldung auf Mitglieder bestimmter Gruppen.
Nach jeder Änderung prüft sshd -t die Syntax und sshd -T die wirksame Konfiguration. Eine zweite offene Sitzung verhindert, dass ein Fehler den Zugang sperrt.
Firewall und Netzwerkdienste
SYS.1.1.A19 verlangt, eingehende und ausgehende Kommunikation über ein Regelwerk auf die erforderlichen Partner, Protokolle und Ports zu beschränken. Unter Debian und Ubuntu stehen nftables oder ufw zur Verfügung, unter der RHEL-Familie firewalld.
Bewährtes Vorgehen:
- Mit
ss -tulpnalle lauschenden Dienste ermitteln. - Dienste, die nur lokal gebraucht werden, an
127.0.0.1binden, etwa Datenbanken und Caches. - Eingehend nur freigeben, was von außen erreichbar sein muss, typischerweise HTTP, HTTPS und SSH, SSH möglichst nur aus bekannten Netzen oder über VPN.
- Standardregel für eingehende Verbindungen auf Verwerfen setzen.
Gegen wiederholte Anmeldeversuche helfen fail2ban oder CrowdSec, die auffällige Quellen anhand von Protokollen sperren. Sie ersetzen weder die Schlüsselanmeldung noch die Firewall. Für die Netzwerk-Firewall vor den Servern gibt es den Firewall-Betrieb mit OPNsense.
Konten, Rechte und Kernel-Schutz
- Konten: Jede Person bekommt ein eigenes Konto, geteilte Konten entfallen. Konten ausgeschiedener Personen und nicht mehr genutzte Dienstkonten werden entfernt. SYS.1.3.A2 verlangt, dass jede UID und GID nur einmal vorkommt.
- sudo: Rechte so eng wie möglich vergeben, Änderungen an
/etc/sudoersnur mitvisudo. SYS.1.3.A6 empfiehlt die Verwaltungswerkzeuge statt direkter Bearbeitung von/etc/passwd,/etc/shadow,/etc/groupund/etc/sudoers. - Kernel-Schutz: SYS.1.3.A4 fordert aktive ASLR und DEP/NX. Der Wert 2 für
kernel.randomize_va_spaceaktiviert laut Kernel-Dokumentation zusätzlich die Heap-Randomisierung und damit die vollständige Randomisierung. - Mandatory Access Control: SYS.1.3.A10 empfiehlt AppArmor oder SELinux mit aktivierten Standardprofilen. Ubuntu und Debian nutzen AppArmor, die RHEL-Familie SELinux. Deaktivieren, um ein Anwendungsproblem zu lösen, ist ein häufiger Befund.
- Dateisysteme: Separate Partitionen für
/tmpoder/var/logmit Optionen wienodev,nosuidundnoexecgehören zu den Empfehlungen der CIS Benchmarks und lassen sich am einfachsten bei der Installation umsetzen.
Protokollierung, Zeit und Angriffserkennung
SYS.1.1.A10 listet die Mindestereignisse: Systemstarts und Reboots, erfolgreiche und erfolglose Anmeldungen, fehlgeschlagene Berechtigungsprüfungen, blockierte Datenströme (Verstöße gegen ACLs oder Firewallregeln), Änderungen an Benutzern, Gruppen und Rechten, sicherheitsrelevante Fehlermeldungen sowie Warnmeldungen von Sicherheitssystemen wie Virenschutz. Protokolle sollten zusätzlich an ein zentrales System gehen, damit ein Angreifer sie nicht auf dem Server selbst löschen kann.
Ohne synchrone Uhrzeit lassen sich Ereignisse über mehrere Systeme nicht zuordnen; timedatectl zeigt den Status von systemd-timesyncd oder chrony. Bei erhöhtem Schutzbedarf nennt SYS.1.1.A27 hostbasierte Angriffserkennung, etwa mit Wazuh für Dateiintegrität und Ereigniskorrelation.
Härtung prüfen: Lynis, OpenSCAP und Ubuntu Security Guide
| Werkzeug | Lizenz | Prüft gegen | Hinweis |
|---|---|---|---|
| Lynis | GPLv3 | eigene Prüfungen mit Härtungshinweisen | lokal ausführbar mit lynis audit system, ohne Agent (CISOfy) |
| OpenSCAP mit ComplianceAsCode | OpenSCAP LGPL-2.1, ComplianceAsCode BSD-3-Clause | SCAP-Profile, unter anderem „CIS Red Hat Enterprise Linux 9 Benchmark for Level 1 - Server“ und CIS-Profile für Ubuntu | erzeugt Berichte, teils mit Korrekturskripten (OpenSCAP, ComplianceAsCode) |
| Ubuntu Security Guide | Teil von Ubuntu Pro (Abonnement) | CIS und DISA-STIG für Ubuntu | ab Ubuntu 20.04, Installation über den Pro-Client (USG, Installation) |
Ein automatischer Bericht zeigt Abweichungen. Er entscheidet nicht, welche davon im konkreten Betrieb sinnvoll ist. Jede Abweichung vom Benchmark wird deshalb entweder umgesetzt oder mit Begründung dokumentiert, denn SYS.1.1.A16 sieht vor, dass Entscheidungen zu sicherheitsrelevanten Einstellungen dokumentiert und begründet werden.
Häufige Fehler
- Härtung ohne Wiederholung: Ein einmal gehärteter Server driftet mit jeder Änderung. SYS.1.1.A24 verlangt regelmäßige Sicherheitsprüfungen.
- Level 2 überall: Strenge Profile ohne Test brechen Anwendungen. Level 1 als Basis, Level 2 gezielt.
- SELinux oder AppArmor abgeschaltet, statt das Profil anzupassen.
- Datenbank lauscht auf allen Schnittstellen und ist aus dem Internet erreichbar.
- Backup liegt auf demselben Server und fällt bei Verschlüsselung oder Datenträgerausfall mit aus.
- Keine Updates mehr: Härtung schützt nicht vor bekannten Lücken einer Version ohne Support, siehe Linux End of Life.
Unser Vorgehen bei WZ-IT
Der Server-Audit ab 290 Euro netto einmalig prüft Sicherheit und Härtung, Backup-Konfiguration und Systemzustand und liefert eine Befundübersicht mit priorisierten Maßnahmen. Der Audit prüft von innen und ist kein Penetrationstest.
Die Umsetzung und laufende Pflege übernimmt die Linux-Server-Betreuung ab 149,90 Euro netto pro Monat für den ersten Server: Updates in Wartungsfenstern, 24/7 Monitoring, Backup-Kontrolle mit bis zu 250 GB Backup-Speicher je Server und Betriebsdokumentation zu Patches, Alarmen und Backup-Status. Wir betreuen Server remote beim bestehenden Provider oder On-Premise.
Weiterführende Ratgeber
- Linux-Patch-Management: Prozess, Fristen und Nachweis
- Server-Monitoring: was überwacht werden muss
- Proxmox-Härtung: Checkliste für Virtualisierungs-Hosts
- Checkliste zur Linux-Server-Übernahme: Zugänge und Bestand vor einem Betreiberwechsel
Stand und Methodik
- Erhebung: 26.10.2026.
- Referenzen: BSI IT-Grundschutz-Kompendium Edition 2023, Bausteine SYS.1.1 und SYS.1.3 sowie OPS.1.1.3; CIS Benchmarks FAQ zu Profilen und Verteilung. Die Inhalte einzelner CIS Benchmarks wurden nicht wiedergegeben, weil der Download eine Registrierung voraussetzt.
- Standardwerte: OpenSSH nach dem offiziellen Handbuch, Kernel nach der Kernel-Dokumentation.
- Lizenzen: Lizenzdateien der Projekt-Repositorys; Ubuntu Security Guide nach Canonical-Dokumentation.
- Nicht enthalten: Härtung von Anwendungen wie Webservern und Datenbanken, Windows Server, Container-Plattformen.
Quellen
- BSI IT-Grundschutz SYS.1.3 Server unter Linux und Unix (Edition 2023)
- BSI IT-Grundschutz SYS.1.1 Allgemeiner Server (Edition 2023)
- BSI IT-Grundschutz OPS.1.1.3 Patch- und Änderungsmanagement (Edition 2023)
- CIS Benchmarks FAQ
- CIS Benchmarks Ubuntu, Debian, Red Hat Enterprise Linux
- OpenSSH: sshd_config
- Linux-Kernel-Dokumentation: sysctl kernel
- Lynis
- OpenSCAP und ComplianceAsCode
- Ubuntu Security Guide
