Als ich kürzlich die Logs meines Webservers unter die Lupe genommen hatte ist mir aufgefallen, dass es etwa im Sekundentakt gescheiterte Anmeldeversuche des Nutzers root von IP-Adressen 222.*.*.*/42.*.*.* gegeben hat. Das war zwar schon zu erwarten, denn jeder öffentliche Server wird früher oder später einmal von Bots gefunden und “ausgetestet”, ruhig schlafen lies es mich dann aber doch nicht.
Die Anmeldung des root-Nutzers war schon längst deaktiviert, nun ist es aber an der Zeit weitere Maßnahmen zu ergreifen um meinen Webserver vor Angreifern zu schützen. Schließlich geht es hier nicht nur um meine eigene Webseiten.
Passwörter im Griff
Gerade bei öffentlich zugänglichen Servern ist ein sicheres Passwort äußerst wichtig. Besser ist, ganz auf Passwörter verzichten und Public/Private-Key-Authentifizierung verwenden. Ist das keine Option gilt die Regel: länger = besser. “hT%2” ist ein Passwort mit Sonderzeichen, Groß- und Kleinschreibung und Zahlen. Hat aber keine Chance mit “UiYPHzDfrkDeski3Wv4SEDVPCmRqD59ZZhwVRHMRTrjf” mitzuhalten.
SSH Zugriff schützen
Der SSH-Zugang liefert eine gewaltige Angriffsfläche. Daher die Empfehlung vorne weg: Wenn der Zugang nicht zwingend notwendig ist (wie in meinem Fall) dann sollte der SSH-Server komplett abgeschaltet werden. Ist dies keine Option haben folgende Maßnahmen in der SSH-Konfigurationsdatei
/etc/ssh/sshd_config
gewaltige Auswirkungen:
- Zugang für root mit
PermitRootLogin noabschalten. Die Bots kennen schließlich keine Nutzernamen, da es den Nutzer root in jedem Fall gibt wird natürlich dieser versucht. - Wenn möglich die Passwortauthentifizierung mit
PasswordAuthentication noabschalten. Und stattdessen auf Public/Private-Key-Authentifizierung setzen. - Simpel, aber sehr wirkungsvoll: SSH-Port ändern. Die Angriffe finden meißt auf dem Standardport 22 statt. Nach einer Änderung des Ports auf einen anderen beliebigen, aber nicht konfligierenden Port verstummten die Log-Meldungen sofort.
- Automatisches bannen der Angreifer-IP. Siehe unten.
Firewall einsetzen
Ubuntu und Co. sind nach Design so aufgebaut, das theoretisch keine Firewall nötig ist. Siehe Artikel auf ubuntuusers.de. Um aber auch vor (ggf. selbstverschuldeter) Fehlkonfiguration und Softwarebugs geschützt zu sein, lohnt es sich eine Firewall aufzusetzen. Der Artikel auf digitalocean.com beschreibt das Vorgehen sehr ausführlich.
Die Installation/Konfiguration von ufw kurz und knapp:
# ufw installieren
sudo apt install ufw
# ufw Standardeinstellungen setzen
sudo ufw default deny incoming
sudo ufw default allow outgoing
# ssh erlauben - Sonst sperrt man sich selbst aus!
sudo ufw allow ssh
# Sollte man den Port geändert haben, stattdessen
sudo ufw allow portnummer/tcp
# ufw scharfstellen
sudo ufw enable
# Weitere Ports freigeben. Z. B.
# sudo ufw allow Apache
fail2ban einsetzen
Meiner Meinung ist das kleine Tool fail2ban wesentlich wertvoller als der Einsatz einer Firewall. Es konfiguriert wie auch ufw die iptables – allerdings dynamisch. Dazu überwacht es Logdaten von SSH, Apache und Co und kann damit verdächtige IP-Adressen sperren.
Konfiguriert wird das fail2ban mit einer Konfigurationsdatei unter
/etc/fail2ban/jail.local
in welcher die Standardkonfiguration der jail.conf überschrieben wird. Die sogenannten Filter sind bereits vorkonfiguriert und suchen Logdaten an den Standardpfaden. Sie warten lediglich darauf aktiviert zu werden. Dazu schreibt man den Namen des Moduls in eckige Klammern und darunter ein enabled = true. Eine minimale Konfiguration kann dann zum Beispiel so aussehen:
[sshd]
enabled = true
maxretry = 3
findtime = 3600
bantime = 86400
[pam-generic]
enabled = true
Läuft zudem Apache auf dem Server können die passenden Module folgendermaßen aktiviert werden.
[apache-overflows]
enabled = true
[apache-auth]
enabled = true
[apache-badbots]
enabled = true
[php-url-fopen]
enabled = true
[apache-fakegooglebot]
enabled = true
[apache-modsecurity]
enabled = true
Ihr habt weitere Tipps? Oder einen Fehler in meinen Entdeckt? Dann schreibt mir doch eine Nachricht! 🙂
