Ubuntu User Sever @ Home (Vorschau)

Admin
SSH‐Guard
zuspielten. Dank
der Verbesserungen
in der neuen
Version müssen
Sie nur noch herausfinden,
in
welcher Datei sich
die Logdaten für
einen unterstützten
Dienst befinden.
Unter Ubuntu landen
beispielsweise
alle relevanten
Meldungen über
4 Tragen Sie die Iptables‐Befehle in die Datei „/ etc/ rc.local“ ein, lädt fehlgeschlagene
Ubuntu sie bei jedem Start automatisch. Vor dem „exit 0“ fügen Sie bei SSH-Loginversuche
Bedarf noch einen Aufruf für den SSH‐Guard selbst ein.
in der Datei /var/
log/ auth.log. Den
gesamten Pfad zur Logdatei übergeben Sie SSH-
Guard einfach mit Hilfe des an den Befehl angehängten
Parameters ‐l:
Glossar
CIDR-Notation: Effiziente Notation,
welche die Beziehung von IP‐
Adressen zu Subnetzmasken über
einen angehängten Suffix eindeutig
ausdrückt.
Eingriff
Ähnlich wie bei der Verkehrssünderkartei in
Flensburg belegt auch SSH‐Guard jeden Angriffsversuch
mit einem bestimmten Punktewert,
der „Dangerousness“. Welche Aktion wie viele
Punkte auslöst, verrät die SSH‐Guard‐Homepage
[4]. Dort erfahren Sie zugleich, welche
Logeinträge SSH‐Guard als konkreten Angriffsversuch
wertet. Die meisten Angriffe bringen 10
Punkte, ab 40 Punkten greift SSH‐Guard ein.
Soll diese Schmerzgrenze höher liegen, teilen
Sie dies dem Werkzeug über den Parameter -a
mit. Der Befehl
sshguard ‐l /var/log/auth.log ‐a 60 U
1> /dev/null &
schraubt die Gefährlichkeit auf 60 Punkte hoch.
Der Parameterkollege -p bestimmt, wie viele Sekunden
der Angreifer nach der ersten Blockade
$ sudo sshguard ‐l /var/log/auth.log 1> U
/dev/null &
Dieser Befehl (den Sie auch in die Datei /etc/
rc.local eintragen können, damit Ubuntu ihn beim
Systemstart automatisch ausführt) wirft jetzt permanent
ein Auge auf die Datei /var/log/auth.log.
Die beim Start produzierte Textausgabe schicken
Sie über 1> /dev/ null ins Nirwana. Der Befehl entdeckt
zwangsläufig auch fehlgeschlagene Loginversuche
via SSH. Nehmen diese überhand, setzt
SSH-Guard eine entsprechende Firewall-Regel ab.
Legen die anderen Dienste ihre Logdaten ebenfalls
in auth.log ab, berücksichtigt SSH-Guard sie auch.
Eine explizite Konfiguration für FTP und Co. benötigen
Sie somit nicht. Soll SSH-Guard mehrere
Logdateien im Auge behalten, übergeben Sie die
Pfade einfach über weitere Parameter, die Sie an ‐l
hängen, also ‐l /pfad/ 1 ‐l /pfad/ 2 usw.
mindestens warten muss, bis er wieder Zugriff
auf den SSH‐Server erhält. So würde
sshguard ‐l /var/log/auth.log ‐p 15 U
1> /dev/null &
den Angreifer für mindestens 15 Sekunden aussperren.
Abschließend regelt die Option -s, nach
wie vielen Sekunden SSH‐Guard die IP‐Adresse
des Angreifers wieder vergisst. Geben Sie hier
zum Beispiel
sshguard ‐l /var/log/auth.log ‐s 20 U
1> /dev/null &
ein, muss der Angreifer nach jedem Versuch
lediglich 20 Sekunden warten, damit SSH‐Guard
ihn niemals blockiert. Das zieht aber einen
Brute‐Force‐Angriff gehörig in die Länge. Alle
genannten Parameter kombinieren Sie übrigens
nach eigenem Bedarf beliebig miteinander.
Drum prüfe, wer sich bindet
Nun prüfen Sie am besten, ob die Blockade reibungslos
funktioniert. Im Folgenden geschieht
dies am Beispiel von SSH. Die anderen, von SSH-
Guard beobachteten, Dienste prüfen Sie nach dem
gleichen Prinzip. Falls auf Ihrem Ubuntu-Rechner
noch kein SSH-Server läuft (und das ist der Standard),
installieren Sie noch das Paket opensshserver.
Andere Nutzer dürfen sich nun per SSH auf
Ihrem Rechner anmelden.
Um SSH-Guard auf die Probe zu stellen, starten
Sie den SSH-Guard wie oben beschrieben und
loggen sich dann von einem anderen Rechner im
Netzwerk aus per SSH mehrfach mit einem falsch
gewählten Passwort ein. Nach fünf Loginversuchen
blockt SSH-Guard den Client für ein paar Sekunden
und protokolliert das in der Logdatei /var/
log/ auth.log (Abbildung 5). Darüber hinaus zeigt
sudo iptables ‐L eine neue Firewall-Regel an, die
den anfragenden Rechner aussperrt (Abbildung
6). Für den Angreifer sieht es so aus, als würde
der Server nicht mehr auf seine Anfragen reagieren
beziehungsweise als sei die Verbindung zum
Server unterbrochen.
Je häufiger der Angreifer sich erfolglos einloggt,
desto länger wird die Zwangspause. Irgendwann
ist sie so lang, dass er sich faktisch ausgesperrt
hat. Ein Blacklisting, also eine schwarze Liste
mit gesperrten IP-Adressen, ist daher nicht mehr
notwendig. Wollen Sie dennoch ein wenig an den
Wartezeiten schrauben, werfen Sie einen Blick in
den Kasten Eingriff.
Bei einem erkannten Angriffsversuch erstellt SSH-
Guard eine neue Firewall-Regel, welche die IP-
Adresse des Angreifers nur für den unter Beschuss
stehenden Dienst blockiert. Wird also ein Angreifer
gesperrt, weil er mehrmals erfolglos versucht,
sich per SSH anzumelden, darf er sich nach der
Sperrung weiterhin per FTP einloggen. Im Extremfall
sperrt SSH-Guard einen Angreifer also nach
und nach von allen Diensten und Zugriffen aus.
Weiße Weste
Einem befugten Nutzer gestattet SSH-Guard mit
seiner Arbeitsweise genügend Versuche, sich an
sein Passwort zu erinnern. Möchten Sie jedoch
in einem sicheren LAN gezielt einen bestimmten
Rechner von sämtlichen Strafmaßnahmen aus-
Listing 1
01 # Die Rechner von Edith und Dieter:
02 192.168.0.101
03 192.168.0.102
04 # Das LAN der Entwicklungsabteilung:
05 192.168.0/24
06 # Unsere Zweigstellen:
07 zweigstelle1.example.com
08 zweigstelle2.example.com
82 UBUNTU
02/2011
www.ubuntu-user.de
user