Ein guter Ruf allein schützt nicht vor Angreifern. Wir zeigen, mit welchen Handgriffen Sie Angreifer aufspüren und abwehren.

Haben Sie das Glück, kein vorhandenes Betriebssystem zu übernehmen, sondern eines frisch installieren zu können, sollten Sie von Anfang an die Weichen für ein sicheres System stellen. Üben Sie sich dazu in Minimalismus, und lassen Sie bei der Installation alles weg, was Sie nicht unbedingt benötigen.

Viele Distributoren bieten eigens dafür erzeugte Minimal-Versionen. Damit richten Sie ein Mini-Linux ein, das gerade so läuft und an dem Sie sich anmelden können. Sie spielen dann gezielt noch die Pakete ein, die Sie für die spätere Funktion des Systems zwingend benötigen – was nicht da ist, stellt auch kein Sicherheitsrisiko dar.

Sobald das System dann läuft, halten Sie es aktuell. Insbesondere Sicherheitsaktualisierungen sollten Sie täglich prüfen und umgehend einspielen. Viele Distributionen haben dafür automatisierte Prozesse, die Sie nur aktivieren müssen. Bei Debian und Ubuntu lautet das Stichwort dafür “unattended upgrades” [1].

Root-Login deaktivieren

Das Passwort des Kontos root, des am höchsten privilegierten Benutzers, ist für einen Angreifer ein besonders lohnenswertes Ziel. Lässt sich das System per SSH via Internet erreichen, finden Sie in der Log-Datei /var/log/auth.log (Listing 1, Zeile 1 bis 4) beziehungsweise im Log von Systemd (ab Zeile 5) zahlreiche Login-Versuche automatisierter Bots, bei denen die Angreifer versuchen, durch schlichtes Erraten des Root-Passworts Zugriff auf das System zu bekommen.

$ egrep -i fail /var/log/auth.log
[...]
Jul 16 13:28:47 ubuntu sshd[21717]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=222.186.180.223  user=root
Jul 16 13:28:48 ubuntu sshd[21717]: Failed password for root from 222.186.180.223 port 4141 ssh2
$ journalctl _SYSTEMD_UNIT=sshd.service | egrep -i fail
[...]
Jul 24 13:02:18 ontario sshd[10311]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=222.186.180.223  user=root
Jul 24 13:02:20 ontario sshd[10311]: Failed password for root from from 222.186.180.223 port 48972 ssh2

Hier hat also jemand versucht, sich von einem System mit der IP-Adresse 222.186.180.223 aus als Root anzumelden. Möchten Sie wissen, woher der Login-Versuch kam, geben Sie whois IP-Adresse ein. Die Ausgabe finden Sie etwas gekürzt in Abbildung 1.

Abbildung 1: Mit dem Kommando whois ermitteln Sie, wer hinter einer IP-Adresse steckt.

In diesem Fall hat der Angreifer falsch geraten (Failed password for root). Haben Sie jedoch das Passwort zu schwach gewählt oder ein Angreifer landet einen Glückstreffer, verlieren Sie die Kontrolle über das System. Aus diesem Grund sollten Sie das Einloggen als Root völlig unterbinden. Einen aktiven Root-Account braucht man in der Regel sowieso nicht, da sich entsprechend konfigurierte Nutzer per sudo administrative Rechte holen können.

Legen Sie dazu im ersten Schritt einen Benutzer namens bob an, und vergeben Sie ein Passwort für ihn (Abbildung 2). Damit Bob mit einem vorangestellten sudo Kommandos als Root ausführen darf, müssen Sie ihn mit dem Kommando usermod -a -G sudo bob in die Sudo-Benutzergruppe einfügen.

Abbildung 2: Die meisten Distributionen stellen keine Anforderungen an neue Passwörter.

Um zu testen, ob alles funktioniert, melden Sie sich dann ab und als bob wieder an. Dann führen Sie das Kommando sudo ls /root aus. Erhalten Sie keine Fehlermeldung, hat alles geklappt. Eine Ausgabe gibt es möglicherweise nicht: Auf einem frisch installierten System steht das Verzeichnis /root meist leer.

Nun können Sie darangehen, das Login für Root zu deaktivieren. Dazu editieren Sie die Konfigurationsdatei des SSH-Servers, /etc/sshd/sshd_config. In der Zeile PermitRootLogin yes ändern Sie das yes in ein no und speichern die Datei. Mit dem Kommando sudo usermod -p '!' root deaktivieren Sie anschließend den Root-Benutzer. Zu guter Letzt starten Sie mit systemctl restart ssh den SSH-Dienst einmal neu.

Ab sofort akzeptiert das System Login-Versuche des Benutzers root nicht mehr. Damit haben Sie das Root-Konto erfolgreich aus der Schusslinie genommen und die Angriffsfläche des Systems merklich verringert.

Bessere Passwörter erzwingen

Nach einer Analyse [2] des Sicherheitsunternehmens Splashdata waren die fünf am häufigsten benutzten Passwörter im vergangenen Jahr “12345”, “123456789”, “querty”, “password” und “1234567”. Ähnliche Studien anderer Unternehmen und Institutionen kommen zu nahezu identischen Ergebnissen.

Für Sie als Betreuer eines Linux-Systems bedeutet das: Sie dürfen sich nicht darauf verlassen, dass Ihre Benutzer von selbst auf die Idee kommen, sinnvolle und hinreichend komplexe Passwörter zu wählen. Sie müssen ihnen dabei ein wenig auf die Sprünge helfen. Dazu dient das PAM-Modul Pwquality. Sie installieren es auf einem Debian- oder Ubuntu-System mit dem Kommando aus Listing 2.

$ sudo apt install libpam-pwquality cracklib-runtime

Das dabei ebenfalls eingerichtete Paket cracklib-runtime enthält ein Wörterbuch, mit dem das Modul häufig benutzte und allzu simple Passwörter erkennt und vor deren Nutzung warnt. Probieren Sie es einmal aus: Ändern Sie mit dem Kommando passwd das Passwort des Benutzers bob in 12345678. Sie erhalten zwar die deutliche Warnung BAD PASSWORD, dürfen das Passwort aber dennoch auf 12345678 ändern (Abbildung 3).

Abbildung 3: Das PAM-Modul Pwquality warnt den Nutzer beim Setzen eines zu schwachen Passworts.

Um komplexere Passwörter zu erzwingen, müssen Sie noch eine Anpassung in der Datei /etc/pam.d/common-password vornehmen. Dort findet sich die Zeile password requisite pam_pwquality.so retry=3. Durch Anhängen diverser Parameter verschärfen Sie die Regeln für neue Passwörter (Listing 3). Mit den einzelnen Parametern lassen sich die Anforderungen an das Passwort dabei gut steuern (siehe Tabelle “Pwquality-Parameter”).

[...]
password requisite pam_pwquality.so retry=3 minlen=9 difok=4 lcredit=-2 ucredit=-2 dcredit=-1 ocredit=-1 reject_username enforce_for_root
[...]

Nach einem Reboot greift die neue Passwortregelung aktiv. Versuchen Sie jetzt ein weiteres Mal Bobs Passwort auf 12345678 zu ändern, dann verlangt das System zwingend das Einhalten der Regeln aus der /etc/pam.d/common-password. Es lehnt die Eingabe von 12345678 ab (Abbildung 4).

Versuchen Sie es nun mit einem “richtigen” Passwort, etwa Iwbity1,itcoY. Das sind die Anfangsbuchstaben der ersten Wörter aus “Robinson Crusoe” von Daniel Defoe (“I was born in the year 1632, in the city of York”). Es erfüllt alle Anforderung an Groß- und Kleinbuchstaben, eine Zahl und ein Sonderzeichen enthält es ebenfalls – und wird daher akzeptiert.

Abbildung 4: Mit der richtigen Einstellungen lässt Pwquality schwache Passwörter gar nicht erst zu.

Login nur per Schlüssel

Besser als das stärkste Passwort ist – gar kein Passwort. SSH erlaubt es, dass Sie sich mit einem kryptografischen Schlüssel anstelle des Passworts ausweisen. Dazu erzeugen Sie zunächst auf dem System, von dem aus Sie sich einloggen möchten, ein Schlüsselpaar aus einem geheimen und einem öffentlichen Schlüssel. In unserem Beispiel benutzen wir einen Schlüssel vom Typ RSA und eine Länge von 4096 Bit:

$ ssh-keygen -t rsa -b 4096

Das Kommando möchte nun wissen, wo es die Schlüssel speichern soll. Hier empfiehlt es sich bei den Standardeinstellungen zu bleiben und einfach die Eingabetaste zu drücken. Danach entscheiden Sie, ob Sie den Schlüssel mit einer Passphrase schützen möchten – ein zusätzlicher Schutz, sollte der Schlüssel einmal in falsche Hände geraten. Wenn Sie hier einfach [Eingabe] drücken, ist der Schlüssel ohne Passphrase nutzbar (Abbildung 5).

Abbildung 5: SSH-Schlüssel machen ein komfortables Login auf entfernte Rechner ohne Passwort möglich.

Den öffentlichen Teil des Schlüsselpaars, das Sie erzeugt haben, laden Sie nun auf den Server hoch, auf dem Sie sich künftig mit diesem Schlüssel anstelle eines Passworts anmelden möchten. Für unser Beispiel nehmen wir wieder an, dass Sie sich dort als bob einloggen:

$ ssh-copy-id bob@IP-Adresse

Das war schon alles. Ein Login auf den entfernten Server via ssh bob@IP-Adresse klappt nun ohne Eingabe eines Passworts.

Sofern Sie diesen Prozess für alle Benutzer durchexerzieren, die sich auf dem entfernten System anmelden, können Sie das Login per Passwort auch komplett abschalten. Dazu ändern Sie in der Konfiguration des SSH-Servers /etc/ssh/sshd_config die Zeile PasswordAuthentication in PasswordAuthentication_no. Nach einem Neustart des SSH-Dienstes gelingt kein Login per Passwort mehr – Zutritt nur noch mit Schlüssel.

Fail2ban frustriert Angreifer

Das Erraten von Passwörtern überlässt der Angreifer in aller Regel einem automatisierbaren Angriffsprogramm, das stupide einen Eintrag nach dem anderen aus einem Wörterbuch abarbeitet. Dagegen kann man sich schützen: Tools wie Fail2ban verhindern solche Angriffe zwar nicht völlig, treiben jedoch den Zeitaufwand für den Angreifer so sehr in die Höhe, dass er in der Regel frustriert aufgibt.

Fail2Ban besteht aus einem Server-Daemon und einem Client, der die zentralen Konfigurationsdateien fail2ban.conf und jail.conf interpretiert und Befehle an den Server schickt. Das Programm liest eine oder mehrere Log-Dateien mit und prüft jede Zeile mit regulären Ausdrücken. So kann Fail2Ban etwa beim Überschreiten einer definierten Anzahl von Login-Versuchen die IP-Adresse des Angreifers per Iptables für eine einstellbare Zeit blockieren.

Sie installieren Fail2ban mit dem Kommando apt install fail2ban. Bei vielen Distributionen ist Fail2ban schon so weit vorkonfiguriert, dass es direkt nach der Installation die Arbeit aufnimmt und SSH (und oft auch weitere Dienste) schützt, ohne dass Sie noch etwas tun müssen. Ob das bei Ihrem System der Fall ist, zeigt nach einer gewissen Wartezeit der Blick ins Log, in diesem Fall /var/log/fail2ban.log (Abbildung 6).

Abbildung 6: Fail2ban registriert wiederholte Login-Versuche und sperrt die IP-Adressen der Angreifer.

Wenn Sie den Verdacht haben, dass der Schutz noch nicht aktiviert ist, sehen Sie sich die Konfigurationsdatei /etc/fail2ban/jail.conf an. Dort finden Sie einen Abschnitt, der mit [sshd] beginnt. Falls in diesem Abschnitt enabled=false steht, ändern Sie das false zu true und starten den Dienst mit systemctl restart ssh einmal neu. Daraufhin legt Fail2ban sofort los.

Serienmäßig trifft der Bannstrahl jeden, der innerhalb von zehn Minuten oder weniger drei Login-Fehlversuche produziert. Fail2ban blockiert dann die entsprechende IP-Adresse für ein Stunde. Diese Werte passen Sie an Ihre eigenen Vorstellungen an, indem Sie in der Konfigurationsdatei die Parameter findtime, maxretry und bantime verändern.

Bei Login E-Mail

Einbruchserkennungssysteme (Intrusion Detection Systems oder kurz IDS) sind in der Regel recht komplexe Anwendungen, die versuchen, außergewöhnliche Aktivitäten auf dem System zu erkennen und zu melden. Aber es geht auch eine Nummer kleiner: Um Sie stets auf dem Laufenden zu halten, wer sich wann auf dem System einloggt, genügt bereits ein Einzeiler (Listing 4).

$ echo 'Login on' $(hostname) $(date) $(who) | mail -s "Login on $(hostname) $(who) | awk '{print $5}'" meine@email.tld

Sie müssen lediglich meine@email.tld gegen Ihre konkrete E-Mail-Adresse austauschen. Dann öffnen Sie die Datei /etc/bash.bashrc und fügen den Einzeiler am Fuß der Datei ein.

Sie erhalten jetzt jedes Mal eine E-Mail, sobald sich ein Benutzer am System anmeldet. Ihr können Sie den Benutzernamen und die Uhrzeit des Logins entnehmen. Meldet sich etwa unser Test-Benutzer bob auf dem System influx an, erhalten Sie eine Mail wie im Beispiel aus Abbildung 7.

Abbildung 7: Unser einfaches Einbruchserkennungssystem meldet per Mail, sobald sich ein Benutzer anmeldet.

Dienste deaktivieren

Manchmal probiert man auf einem System etwas aus, spielt damit herum und vergisst es dann. Auf exponierten Systemen stellen solche “versunkenen” Dienste ein Sicherheitsrisiko dar. Es ist sinnvoll, ab und an nachzusehen, was genau auf dem System läuft, und insbesondere, welche Dienste man von außen erreichen kann.

Das klappt sehr einfach mit dem Kommando netstat -tlpn, das Sie mit administrativen Rechten aufrufen. Netstat liefert eine tabellarische Aufstellung aller Dienste und der Ports, an die sie gebunden sind.

Abbildung 8: Mit Netstat ermitteln Sie aktive Dienste, die Ports zum Netzwerk öffnen.

Auf dem System aus Abbildung 8 läuft zum Beispiel neben anderen Diensten auch InfluxDB. Netstat zeigt, dass dieser Dienst für beliebige Zugriffe aus dem Netz offensteht und an Port 8086 nach Anfragen lauscht – das zeigen 0.0.0.0:Port für IPv4 und :::Port für IPv6. In einem herkömmlichen Heimnetzwerk müsste man den Port 8086 noch vom WLAN-Router auf den Rechner weiterleiten, damit der Dienst auch aus dem Internet zu erreichen wäre.

Nehmen wir an, für die Arbeit an InfluxDB haben Sie gerade keine Zeit. Sie möchten den Dienst zwar deaktivieren, aber er soll installiert bleiben, damit Sie sich später weiter damit beschäftigen können. Dazu stoppen Sie mit dem Kommando systemctl stop influx zunächst InfluxDB. Das Kommando wird ausgeführt, erzeugt aber keine Ausgabe. Um zu kontrollieren, dass InfluxDB wirklich nicht mehr läuft, genügt ein Blick in /var/log/syslog beziehungsweise das Log von Systemd (Listing 5).

[...]
Jul 18 11:22:37 influx influxd[11322]: ts=2020-07-18T10:22:37.769190Z lvl=info msg="Closed service" log_id=0O4MSfDG000 service=subscriber
Jul 18 11:22:37 influx influxd[11322]: ts=2020-07-18T10:22:37.769493Z lvl=info msg="Server shutdown completed" log_id=0O4MSfDG000
Jul 18 11:22:37 influx systemd[1]: influxdb.service: Succeeded.
[...]

Dass Sie den Dienst jetzt gestoppt haben, bedeutet aber nicht, dass er dauerhaft deaktiviert bleibt. Nach einem Neustart würde er automatisch wieder starten. Das verhindern Sie, indem Sie den Dienst mit systemctl disable influxdb komplett deaktivieren. So bleibt InfluxDB installiert, startet aber nicht mehr automatisch. Mit systemctl enable influxdb machen Sie diesen Schritt bei Bedarf wieder rückgängig. (cla/jlu)