Härtungsmaßnahmen für Linuxserver – Teil 2

Ergänzend zu einem vorherigen Beitrag, der einige grobe Maßnahmen zur Härtung von Linuxservern behandelt hat, wird der folgende eine kleine Ergänzung dazu darstellen.
Wie sooft durfte abermals ein Ubuntu-Server für sämtliche Arbeitsschritte herhalten.

Kernelparameter mit sysctl editieren

Die sysctl.conf ist eine Konfig-Datei zur Steuerung diverser Kernel-Parameter. In ihr lassen sich Kernel-Features ein und ausschalten. Einige davon dienen der weiteren Sicherheit, weswegen wir einen genaueren Blick auf sie werfen. Öffnet also die Datei sysctl.conf …

sudo nano /etc/sysctl.conf

… und stellt sicher, dass folgende vier Einträge einkommentiert gesetzt sind:

net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
### Gegebenenfalls auch noch folgendes deaktivieren, falls vorhanden
net.ipv4.conf.default.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

Durch die Deaktivierung dieser Option werden ICMP Redirect-Meldungen ignoriert. Hintergrund ist, dass Router ICMP-Redirect-Meldungen benutzen um Hosts zu benachrichtigen, dass für Ziele eine direktere Weiterleitung vorhanden ist. Und diese Meldung kann gefälscht sein und zu einer Man-in-the-Middle Attacke führen. Also schalten wir die Redirection einfach ab. Es sei an dieser Stelle angemerkt, dass dies zu Problemen im Netzwerk führen oder die Geschwindigkeit beeinträchtigen kann und einige Dienste, die zuvor auf Traffic-Redirection angewiesen waren, nicht mehr ordnungsgemäß funktionieren.
Außerdem sollte (falls der Server kein Router ist) die beiden Optionen …

net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

… einkommentiert und ebenfalls auf 0 gesetzt sein. Eingehende IP-Pakete mit Route-Informationen im Header werden verworfen. Das soll für uns bitte ein der dazwischenliegenden Gateways übernehmen.
Die Spoof-Protection ist eine Methode, um z.B. manipulierte IP-Pakete abzulehnen, die nicht zurückgeroutet werden können. Dies kann z.B. Dos Angriffe abwehren. Dem Linux Kernel steht hierfür die Funktion „reverse path filtering“ zur Verfügung.

net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter =1

Um mögliche verworfene Pakete zu loggen, aktivieren wir noch das Logging für Martian-Pakete (die landen dann im syslog).

net.ipv4.conf.all.log_martians = 1

Sind sämtliche Optionen gesetzt, verlassen wir die Datei und aktivieren sie folgendermaßen:

sudo sysctl -p

Fail2ban

Fail2ban ist ein „Intrusion prevention System“. Es bewahrt uns (im Idealfall) vor bösartige Zugriffsversuche, die in einem vordefinierten Zeitrahmen mit falschen Passwörtern stattfinden. Ermittelt werden diese aus Log-Dateien, z.B. die /var/log/auth.log. Kommt es zu einem blockierten Zugriff, ist das unkonfigurierte Tool so eingestellt, dass dieser nach wenigen Minuten wieder freigegeben wird. Dies stellt immerhin bereits ein Abwehr-Mechanismus gegen Brute-Force-/ oder einfache DoS-Attacken dar.
Doch zunächst muss das Tool installiert werden:

sudo apt-get install fail2ban

Laut Manpage ist es ratsam, Benutzerspezifische Änderungen an der fail2ban Konfiguration nicht in der bereits vorhandenen „/etc/fail2ban/jail.conf“ durchzuführen, sondern in einer neuen Datei namens „local.conf“. Da letztere noch nicht vorhanden ist, erzeugen wir sie uns einfach aus der bereits existierenden und werfen anschließend einen Blick hinein:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano /etc/fail2ban/jail.local

Interessant für uns sind hier die Einträge „bantime“ (Dauer in Sekunden, die ein Host geblockt bleibt) und „maxretry“ (Anzahl der Login-Versuche, bis der Host blockiert wird). Diese Einstellungen lassen sich auch auf einzelne Dienste anwenden, beispielsweise [ssh], [apache-auth], [postfix] etc. Hierzu stehen weiter unten in der Datei bereits vorgefertigte Kategorien zur Verfügung. Werden dort Änderungen eingetragen, überschreibt es die globale Kategorie [DEFAULT].
Nachdem Änderungen durchgeführt wurden, muss der Dienst abschließend einmal neugestartet werden:

sudo systemctl restart fail2ban.service

Damit wäre unser Server nochmals ein Stück weit abgesicherter.

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Nach oben scrollen