Sonntag, 23. September 2007

Auto-Blacklisting für die NSLU2

Im Normalfall greife ich per ssh auf meine NSLU2 zu. ssh läuft bei mir auf dem Standard-Port und ist auch von außen (also aus dem Internet) her erreichbar. Das merken natürlich auch viele gelangweilte Personen, die automatisiert IP-Adressen nach Zugängen absuchen und dann versuchen sich per Brute-Force bzw. Trial&Error auf meinem System einzuloggen.

Passwortauthentifizierung ist bei mir allerdings ausgeschaltet, man muss sich mit asymmetrischen Schlüsseln anmelden - das gibt einen gewissen Grad an Sicherheit, bedeutet aber auch, dass man sich nur von einem System einloggen kann, auf dem der Schlüssel existiert. Theoretisch müsste man ihn also ständig mit sich 'rumschleppen. Das stört aber die ganzen skriptgesteuerten Login-Versuch dieser "Hacker" natürlich nicht, so dass /var/log/auth.log bei mir so aussieht:

Sep 23 08:25:20 NSLU2 sshd[21135]: Invalid user staff from 202.106.62.52
Sep 23 08:25:25 NSLU2 sshd[21139]: Invalid user sales from 202.106.62.52
Sep 23 08:25:29 NSLU2 sshd[21143]: Invalid user recruit from 202.106.62.52
Sep 23 08:25:33 NSLU2 sshd[21147]: Invalid user alias from 202.106.62.52
Sep 23 08:25:38 NSLU2 sshd[21151]: Invalid user office from 202.106.62.52
Sep 23 08:25:42 NSLU2 sshd[21155]: Invalid user samba from 202.106.62.52
Sep 23 08:25:47 NSLU2 sshd[21159]: Invalid user tomcat from 202.106.62.52
Sep 23 08:25:51 NSLU2 sshd[21163]: Invalid user webadmin from 202.106.62.52

... und so weiter und so fort ...

Wenn man nun aber doch mal die normale Passwortauthentifikation benötigt, dann steht und fällt die Sicherheit allein mit der "Stärke" des Passworts. Es gibt aber Methoden und Möglichkeiten, diese Brute-Force-Angriffe etwas zu entschärfen. Auf die Idee hat mich ein iX-Artikel gebracht, bei dem das Auto-Blacklisting-PAM erwähnt wird: pam_abl. Leider konnte ich es nicht als Paket für Debian finden, so dass man wohl selber kompilieren muss. GCC, make usw. sollten also schon mal auf dem System vorhanden sein.

Okay, dann mal los:

//NSLU2~# mkdir pam_abl
//NSLU2~# cd pam_abl/
//NSLU2~/pam_abl# wget http://garr.dl.sourceforge.net/sourceforge/pam-abl/pam_abl-0.2.3.tar.gz

Okay, dann mal schick auspacken:

//NSLU2~/pam_abl# tar xvf pam_abl-0.2.3.tar.gz
//NSLU2~/pam_abl# cd pam_abl

Um erfolgreich zu kompilieren, benötigt man noch ein paar Bibliotheken, die aber bequem per aptitude oder apt-get nachinstallierbar sind:

//NSLU2~/pam_abl/pam_abl# aptitude install libdb4.4-dev libpam0g-dev

Dann mal los zum kompilieren:

//NSLU2~/pam_abl/pam_abl# make
//NSLU2~/pam_abl/pam_abl# make install

Wenn Fehler kommen, dann fehlt wahrscheinlich noch eine Abhängigkeit, bei mir hat's jedenfalls geklappt. Im Unterverzeichnis conf ist eine Beispiel-Konfiguration vorhanden, die man noch ins System kopieren sollte:

//NSLU2~/pam_abl/pam_abl# cp conf/pam_abl.conf /etc/security/

Dann mal gleich die Konfig noch anpassen. Die Dokumentation gibt Auskunft über die Syntax, ich habe mich für folgende Variante entschieden, die jeden Host (IP-Adresse) für zwei Tage sperrt, von dem drei fehlgeschlagene Login-Vorgänge in einer Stunde ausgegangen sind. Das User-Handling habe ich auskommentiert, sonst könnte nämlich jemand ankommen, sich dreimal als root anmelden wollen und dann komme ich selbst nicht mehr rein. Neenee, dann schon lieber nur der Host-basierte Ansatz ;)

# /etc/security/pam_abl.conf
# debug
host_db=/var/lib/abl/hosts.db
host_purge=2d
host_rule=*:3/1h

#host_rule=*:10/1h,30/1d
#user_db=/var/lib/abl/users.db
#user_purge=2d
#user_rule=!root:10/1h,30/1d

Damit jetzt das neue Auto-Blacklisting auch eingesetzt wird, muss man noch die PAM-Konfig für ssh anpassen, die findet sich hier:

//NSLU2~/pam_abl/pam_abl# vi /etc/pam.d/ssh

Basierend auf der Doku habe ich folgende Zeilen hinzugefügt:

# PAM Auto-Blacklisting
auth required /lib/security/pam_abl.so config=/etc/security/pam_abl.conf

Jetzt kann man das Ganze testen, indem man die Passwortauthentifikation in der /etc/ssh/sshd_config mal testweise wieder anschaltet und sich Fehl-Logins von einem Client aus erzeugt. Für Debug-Zwecke ist es auch hilfreich, die entsprechende Zeile Debug-Zeile in der pam_abl-Konfig zu setzen.

Wenn man nun (wie ich) eine Weile 'rum experimentiert, merkt man, dass die fehlerhaften Logins leider NICHT zur Sperrung des betreffenden Hosts führen, da die host_db nicht angelegt wird. Argh.

Mein Freund Google hat mir aber mitgeteilt, dass es sich vermutlich um einen Bug in openSSH handelt. Da ich ja eh' mit Schlüsseln arbeite, spielt das für mich erstmal keine Rolle. Ich lasse die pam_abl-Konfig aktiv und werde nach dem nächsten openSSH-Update mal schauen, ob es denn funzt. Wenn es denn geht, sieht das Ergebnis so aus, dass nach dem dritten Fehl-Login der Host gesperrt wird, d.h. man kann eine ssh-Verbindung zwar öffnen aber selbst mit dem richtigen Passwort wird kein Zugriff mehr gewährt (zwei Tage lang). So geht man Wörterbuchattacken effizient aus dem Weg oder erschwert sie zumindest, da sie auf 3 Versuche pro IP-Adresse limitiert sind. Natürlich gibt's mit iptables etc. noch andere Möglichkeiten zum Blockieren ungewünschter Gäste, aber die mittels PAM hier ist klein und effektiv.

Ich behalte das mal auf dem Schirm.

UPDATE: Ich habe die bessere Lösung gefunden, lest einfach hier weiter.

blog comments powered by Disqus

Design von Dicas Blogger, angepasst durch Mario Ruprecht