Linux-Server härten? Erst mit Lynis auditieren

Lynis ist ein Kommandozeilen-Tool, das eine Linux-, macOS- oder BSD-Maschine scannt und dir danach eine Liste aushändigt: Dutzende konkreter Schwachstellen, jede nach Wichtigkeit eingestuft. Behoben wird davon keine einzige. Genau diese Lücke, zwischen dem Finden eines Problems und der Entscheidung, was damit passiert, überspringen die meisten Anleitungen zum Linux-Server-Härten stillschweigend. Generische Checklisten wandern von Server zu Server und werden von oben nach unten abgearbeitet, egal ob sie zur jeweiligen Maschine passen. Lynis geht den umgekehrten Weg: erst auditieren, bewerten, was gefunden wurde, und die Entscheidung der Person überlassen, die die Maschine tatsächlich betreibt.

Diese Anleitung setzt Sudo-Zugriff auf eine Debian-, Ubuntu-, RHEL-Familie- oder macOS/BSD-Maschine voraus. Probiere sie zuerst auf einer Testmaschine oder einer Wegwerf-VM aus. Ein paar der folgenden Fixes betreffen SSH, das Protokoll, über das die meisten Server administriert werden, und eine falsche Einstellung dort kann dich aussperren.

Lynis installieren

Lynis ist in den meisten Distributions-Repos verpackt, meist eine Version hinter dem aktuellen Release. Unter Debian und Ubuntu:

sudo apt update
sudo apt install lynis

Unter Fedora, RHEL und anderen Red-Hat-Systemen:

sudo dnf install lynis

Für die aktuelle Version klonst du stattdessen direkt aus der Quelle:

cd /usr/local
sudo git clone https://github.com/CISOfy/lynis

Michael Boelen hat Lynis 2007 gestartet und entwickelt es bis heute über CISOfy weiter, das niederländische Unternehmen, das er 2013 gegründet hat. Das Kern-Tool ist kostenlos, Open Source und unter der GPLv3 lizenziert. Ein separates, kostenpflichtiges Add-on gibt es für die Verwaltung von Audits über viele Server hinweg von einem Dashboard aus, aber alles in dieser Anleitung funktioniert allein mit der kostenlosen Kommandozeilen-Version.

Deinen ersten Audit ausführen

Einmal installiert, ist der komplette Audit ein einziger Befehl:

sudo lynis audit system

Er arbeitet die Maschine Abschnitt für Abschnitt durch: Bootloader, Art der Anmeldeauthentifizierung, Datei- und Verzeichnisberechtigungen, installierte Pakete, Netzwerkeinstellungen, Firewall, SSH-Konfiguration und Logging, unter anderem. Ein kompletter Durchlauf dauert ein bis zwei Minuten auf einem typischen Server. Alles, was Lynis findet, wird während des Laufs im Terminal ausgegeben, markiert als Beobachtung, Warnung oder Vorschlag. Dasselbe Detail landet zusätzlich in zwei Dateien zum späteren Nachschlagen: /var/log/lynis.log für das Test-für-Test-Protokoll und /var/log/lynis-report.dat für die strukturierten Ergebnisse, die ein Skript oder ein späterer Vergleich einlesen kann.

Root-Zugriff ist nicht zwingend nötig. Ein --pentest-Flag startet einen nicht-privilegierten Scan, der jeden Test überspringt, der Root-Rechte braucht:

lynis audit system --pentest

Dieser Modus ersetzt nicht den vollständigen Audit. Ganze Kategorien bleiben ungeprüft, der resultierende Score fällt entsprechend niedriger aus und sagt weniger aus. Wofür er sich eignet: ein schneller erster Blick auf eine Maschine, bevor du erhöhten Zugriff darauf hast, oder eine schnelle externe Prüfung durch jemanden, der auf dieser Maschine ohnehin kein Sudo haben sollte.

Den Hardening-Index lesen, ohne der Zahl hinterherzulaufen

Der Audit endet mit einem Hardening-Index, einer Punktzahl von 0 bis 100, die zusammenfassen soll, wie viele empfohlene Maßnahmen umgesetzt sind. In der Praxis landet eine frische, unkonfigurierte Installation üblicherweise in den 50ern oder 60ern, ein Server, der einen bewussten Härtungsdurchlauf hinter sich hat, kann in die 80er oder höher vorstoßen.

Boelen, der auf seiner eigenen Seite bis heute über das Tool schreibt, ist unmissverständlich darüber, was die Zahl nicht ist: Der Hardening-Index ist nur ein Indikator für getroffene Maßnahmen, kein Prozentwert dafür, wie sicher das System tatsächlich ist. Er warnt außerdem vor der naheliegenden Abkürzung, Tests, die ein System immer wieder durchfallen lässt, einfach zu deaktivieren oder zu überspringen, nur damit die Zahl steigt. Das hebt den Wert, ohne am tatsächlichen Risiko etwas zu ändern, und macht den Vergleich mit einer anderen Maschine bedeutungslos.

Die sinnvolle Lesart des Scores ist relativ, nicht absolut. Ist dieser Server besser gehärtet als noch letzten Monat, und ergibt der Abstand zu einem vergleichbaren Server in derselben Flotte Sinn.

Zuerst die zwei Änderungen fixen, die am meisten zählen

Ein erster Lynis-Lauf auf einem durchschnittlichen Server kann über fünfzig Vorschläge zurückliefern. Der Versuch, alle in einer Sitzung abzuarbeiten, ist der Grund, warum die meisten Audits so enden: Jemand öffnet die Liste, fixt drei Punkte und kommt nie wieder zurück. Zwei Änderungen, beide auf fast jeder Standardinstallation markiert, lohnen sich vor allem anderen auf der Liste.

Die erste betrifft die SSH-Passwortauthentifizierung. Falls die Anmeldung per Schlüssel bereits funktioniert, bestätige das in einer zweiten Terminal-Sitzung, bevor du die erste schließt, und deaktiviere dann die Passwortanmeldung komplett:

sudo sed -i 's/#\?PasswordAuthentication .*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart sshd

Das entfernt eine ganze Kategorie von Passwort-Rate-Angriffen gegen SSH, meist der am häufigsten angetestete Dienst auf jedem öffentlich erreichbaren Server. Es ist auch derselbe Reflex, der hinter Zero-Trust-Architektur steckt: nicht mehr standardmäßig Zugriff gewähren, sondern einen Nachweis verlangen.

Die zweite betrifft Fail2Ban, einen Daemon, der Logdateien wie /var/log/auth.log beobachtet und jede IP-Adresse vorübergehend blockiert, die zu viele fehlgeschlagene Anmeldeversuche anhäuft:

sudo apt install fail2ban
sudo systemctl enable --now fail2ban

Fail2Bans eigene Dokumentation ist ehrlich darüber, was das bringt: Es senkt die Rate der Einbruchsversuche, kann aber schwache Authentifizierung nicht von sich aus reparieren, weshalb es genau neben die SSH-Änderung oben gehört, nicht an ihre Stelle.

Den erneuten Audit automatisieren und den Trend verfolgen

Ein einmaliger Audit ist nur eine Momentaufnahme. Lynis ist für wiederholte Läufe gebaut und hat dafür ein eigenes Flag:

sudo lynis audit system --cronjob

Das --cronjob-Flag lässt den Scan ohne interaktive Nachfragen laufen, was ihn sicher für einen geplanten Job macht:

# /etc/cron.weekly/lynis-audit
#!/bin/sh
lynis audit system --cronjob

Jeder Lauf überschreibt dieselbe /var/log/lynis-report.dat, also heb nach jedem Scan eine datierte Kopie auf, wenn das Ziel eine echte Trendlinie ist und nicht nur die jeweils letzte Momentaufnahme. Zwei Berichte nebeneinander zu vergleichen zeigt, welche Vorschläge erledigt wurden und welche neuen seit dem letzten Durchlauf aufgetaucht sind, ein konkreteres Signal als die Indexzahl allein.

Um einen einzelnen Fix zu bestätigen, braucht es keinen kompletten erneuten Lauf. Das Flag --tests-from-category grenzt einen Scan auf einen Bereich ein:

sudo lynis show categories
sudo lynis audit system --tests-from-category <kategorie-name>

Die Kategorienliste einmal aufzurufen zeigt die exakten Namen, die Lynis auf dieser Installation kennt. Ein enger Re-Scan direkt nach der SSH-Änderung oben ist in Sekunden statt der über eine Minute für den vollen Scan durch, was es realistisch macht, einen Fix sofort zu prüfen, statt auf den nächsten geplanten Audit zu warten.

Vor Produktion erst testen

Jede oben vorgeschlagene Änderung, SSH-Passwörter deaktivieren, einen Daemon neu starten, eine Firewall-Regel verschärfen, kann auch etwas kaputt machen, das von der aktuellen, lockereren Konfiguration abhängt: ein Monitoring-Agent, der sich noch per Passwort authentifiziert, ein Cron-Job, der voraussetzt, dass ein Port offen bleibt. Wende Lynis-Vorschläge zuerst auf einer Staging-Kopie des Servers an, oder halte mindestens eine zweite, funktionierende Sitzung offen, während SSH neu startet, damit ein Fehler dich nicht vom einzigen Zugangsweg aussperrt.

Häufig gestellte Fragen

Ist es sicher, Lynis auf einem Produktionsserver auszuführen?

Ja. Ein normaler lynis audit system-Lauf liest nur Konfigurations- und Logdateien. Er ändert standardmäßig nichts an der Maschine, daher birgt das Ausführen auf einem laufenden Server kein größeres Risiko als jedes andere read-only Inspektionstool.

Behebt Lynis die gefundenen Probleme?

Nein, und das ist Absicht. Lynis liefert eine bewertete Liste mit Vorschlägen samt Links zur Dokumentation und, bei vielen Punkten, dem exakten Befehl zur Behebung, aber die Anwendung bleibt eine manuelle Entscheidung. Das kostenpflichtige Produkt Lynis Enterprise ergänzt zentrales Reporting über mehrere Server hinweg, keine automatische Behebung.

Was gilt als guter Hardening-Index-Wert?

Es gibt keine universelle Bestehensgrenze. Die Zahl ist nützlich, um den Fortschritt eines einzelnen Servers über die Zeit zu verfolgen, oder um einen Server in einer Flotte zu erkennen, der spürbar hinter den anderen zurückbleibt. Jede feste Zahl als Bestehens- oder Durchfallgrenze zu behandeln, verfehlt laut dem eigenen Entwickler den Sinn des Tools.

Ist Lynis dasselbe wie CIS-CAT oder OpenSCAP?

Nein. CIS-CAT ist der eigene Scanner des Center for Internet Security für dessen veröffentlichte Benchmarks, OpenSCAP ist ein separater offener Standard samt Toolset, getragen von Red Hat. Lynis ist ein unabhängiges Projekt, das sich auf CIS-Benchmarks, NIST und diverse Hersteller-Guides als Hintergrundmaterial bezieht, aber von keiner dieser Organisationen gebaut oder zertifiziert wird.

Das Fazit für alle, die einen Linux-Server betreiben

Lynis wird einen Server nicht von selbst härten, und genau das ist der Punkt. Ein Tool, das jede empfohlene Einstellung stillschweigend automatisch anwenden würde, würde irgendwann etwas Wichtiges kaputt machen, auf einer Maschine, die niemand aufmerksam genug im Blick hatte, um es zu bemerken. Was es tatsächlich tut: “den Server härten” von einer vagen Anweisung in eine kurze, priorisierte, konkrete Liste verwandeln und sich dann zurückziehen. Fang mit SSH und Fail2Ban an, führe den Audit regelmäßig erneut aus, und lass den Score den Fortschritt verfolgen, statt ihn zu definieren. Das ist ein ehrlicherer Weg, einen Linux-Server zu härten, als fremde Checklisten von oben nach unten abzuarbeiten.