Artikel
uli mauk 
Club vs Köln 2012 
Warsinsky 
Peter K. 
Aber...
Chris 
Ben Attacke auf SSH!
Wiederholte Login-Versuche auf Serverdienste wie SSH sind Ärgernis und Sicherheitsrisiko zugleich. Trotz eines starken Passworts bleibt oft ein flaues Gefühl im Magen, wenn man in Logfiles auf eine (meist skriptgesteuerte) Attacke stößt. Solche Login-Versuche zu unterbinden ist die Aufgabe von Fail2ban.
(Bildlizenz: Creative Commons Attribution-Share Alike 3.0 Unported)
Wie Fail2ban funktioniert
Fail2ban analysiert Logfiles auf unerwünschte Zugriffsversuche. Bei SSH wird die Datei /var/log/auth.log auf fehlgeschlagene Logins untersucht. Bei Apache z.B. kann Fail2ban die Error-Logdateien darauf abklopfen, ob es Zugriffsversuche auf Adminbereiche oder passwortgeschützte Verzeichnisse gibt.
Ergibt die Analyse, dass eine bestimmte IP-Adresse für eine (konfigurierbare) Anzahl von Zugriffsversuchen verantwortlich zeichnet, wird diese IP-Adresse vorübergehend blockiert. Dazu erstellt Fail2ban eine neue Firewallregel und fügt sie -zeitlich begrenzt- in das bestehende Regelwerk ein. Weitere Login-Versuche laufen dann ins Leere.
Fail2ban kann so konfiguriert werden, dass jede Blockade (inklusive einer whois-Abfrage) per Email an den Administrator gemeldet wird:
Liebesgrüße aus China!
Installation und Konfiguration
Bei Ubuntu, Debian und vielen anderen Distributionen ist Fail2ban über die Paketquellen installierbar. Die Hauptkonfigurationsdatei lautet /etc/fail2ban.conf. Diese Datei kann allerdings bei einem Upgrade überschrieben werden. Besser ist es daher, eine Kopie der Datei nach /etc/fail2ban/jail.local zu kopieren und diese zu editieren. Hier ein Auszug aus /etc/fail2ban/jail.local:
[DEFAULT]
ignoreip = 127.0.0.1
bantime = 300
maxretry = 3
Hier werden Standardwerte für alle Dienste festgelegt. Wenn für einen einzelnen Dienst nichts weiter konfiguriert ist, soll die Blockade nach 3 Fehlversuchen eintreten und 300 Sekunden dauern.
Gerade im Zuge der Einrichtung von Fail2ban und der Testphase ist eine kurze Blockadedauer empfehlenswert, um sich nicht selbst allzulang auszusperren, wenn man die Funktionalität testet.
[ssh]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 4
In diesem Fall wird für SSH festgelegt, dass Fail2ban für SSH aktiviert ist und SSH auf Port 22 läuft. Gefiltert wird die Datei /var/log/auth.log nach der Filterdefinition “sshd” (Filterdefinitionen für einzelne Dienste sind im Verzeichnis /etc/fail2ban/filter.d/ festgelegt). Nach 4 Fehlversuchen wird die IP-Adresse für 300 Sekunden blockiert.
In der Realität wird die Blockade aber oft weitere Fehlversuche zulassen (wenn dies innerhalb kürzester Zeit geschieht). Dies liegt daran, dass Fail2ban die Logfiles aus Gründen der Performance nicht in Echtzeit, sondern periodisch durchforstet.
Neben SSH hält die Konfigurationsdatei auch Standards für Dienste wie Apache, Postfix oder Proftpd bereit.
Eigene Filterregeln erstellen
Während die Standardkonfigurationen für gängige Dienste schon viel abdeckt, kann man auch individuelle Filterregeln erstellen. Dazu muss man die entsprechende Filterregel z.B. als /etc/fail2ban/filter.d/mein_dienst.conf anlegen und dann in /etc/fail2ban/jail.local mit “filter = mein_dienst” darauf verweisen. Ein Beispiel für diese Prozedur findet Ihr im Artikel fail2ban und der Kampf gegen Trackback Spam.
Fail2ban (neu) starten
Nach einer Änderung an der Konfiguration muss Fail2ban neu gestartet werden:
/etc/init.d/fail2ban restart
Weitere Infos
Auf der Suche nach eventuellen Fehlern bei der Konfiguration kann ein Blick in das Logfile /var/log/fail2ban.log helfen. Nicht unerwähnt soll bleiben, dass man das Login für SSH mit einem Passwort natürlich auch komplett unterbinden kann und den Zugriff nur mit Zertifikat erlauben kann. Eine ausführliche Sammlung über Sicherheit und SSH findet Ihr in dem Artikel Top 20 OpenSSH Server Best Security Practices.
Fail2ban FAQ (deutsch)
IT Blögg: Fail2ban Debian Howto
Ähnliche Artikel:
wie wäre es, wenn man mit zertifikaten arbeiten würde?
da ist sowas dann hinfällig.
Auf diese Möglichkeit habe ich ja am Ende des Artikels hingewiesen
Zitat: “Nicht unerwähnt soll bleiben, dass man das Login für SSH mit einem Passwort natürlich auch komplett unterbinden kann und den Zugriff nur mit Zertifikat erlauben kann.”
[edit] Die Lösung mit dem Zertifikat ist aber nicht für alle Situationen eine Option, z.B. wenn man von wechselnden Maschinen auf SSHD zugreifen muss. Beispiel wäre ein kleiner Heimserver, von dem man auch von unterwegs zugreifen will. Da kann man sich, wenn man bei Mutti ist, mal schnell Putty runterladen und trotzdem auf den Server zugreifen. Sicherer ist das Zertifikat, flexibler die Passwortmethode. Außerdem kann man ja Root-Login verbieten und SSH auf einen anderen Port legen…
Aber auch mit Zertifikat kann es sinnvoll sein zu wissen, wer da versucht, zuzugreifen und die IP zu blockieren. [/edit]
Dann nimm deinen Key auf einem USB-Stick einfach mit.
Du kannst dir sogar mehrere Keys erstellen: einen ohne Passwort, der auf deinem System zuhause bleibt und dazu einen weiteren mit Passwort, den du auf dem USB-Stick hinterlegst. Sollte dir der USB-Stick mal abhanden kommen entfernst du den Key aus der ~/.ssh/authorized_keys oder setzt ihn gleich in die ~/.ssh/revoked_keys
~jug
Es kann doch kein Zweifel daran bestehen, dass das Zertifikat im allgemeinen (und gerade im professionellen Umfeld) die beste Lösung ist.
Es gibt aber auch (gerade private) Szenarien, wo die Passwortmethode praktikabler ist, z.B. wenn man “Rudis kleine Modellfliegerseite” verwaltet. Wenn Du am Wochenende unterwegs bist und kriegst einen Anruf, dass da was nicht läuft, dann ist Passwort praktikabler.
Da hat man doch keine Lust, ständig einen USB-Stick mit sich herumzuschleppen (den man mit Sicherheit genau dann nicht dabei hat, wenn was nicht funktioniert)
SSH-Keys würde ich auch empfehlen. Dieses Fail2Ban ist doch nur wieder weitere Software, die eine Sicherheitslücke enthalten kann. Und die wird installiert um eine Sicherheitslücke zu schließen, die gar nicht existiert, wenn man den SSH-Daemon richtig konfiguriert. Also dass man den Login über Passwörter deaktiviert, sonst bleiben die Brute-Force-Angriffe natürlich möglich.
Eine weitere Möglichkeit den SSHd etwas abzusichern wäre übrigens Port-Knocking, was auch im verlinkten Artikel auf Platz 18 enthalten ist.
~jug
Da die Diskussion sich nun stark auf SSH beschränkt, will ich nur nochmal klarmachen, dass Fail2ban auch etliche andere Dienste abdeckt (xinetd, apache, postfix, vsftpd usw.) und mit der möglichen Konfiguration IP-Blockaden für alle möglichen weiteren Szenarien ermöglicht. Die richtige Konfiguration von SSH ist natürlich Voraussetzung; Fail2ban kann kein Ersatz dafür sein.
1) Zertifikat ist eine gute Idee
2) die SSH auf einen HighPort legen, dann muss jemand erstmal suchen
3) du willst IP´s aussperren? Dann such dir doch die Deutschen IP Bereiche und sperr es via iptables
4) einfacher um den ganzen Scheiss zu umgehen: Portknocking
Ein ähnliches Tool ist DenyHosts http://denyhosts.sourceforge.net/
Wenn Du jetzt noch das Wiki mit Deinem Wissen fütterst, sind alle glücklich
–> http://ubuntuusers.de/search/?query=fail2ban&area=wiki
Liebe Grüße, Flo
[Antwort wurde als private Nachricht gesendet]
Erstmals, danke für die Verlinkung.
Zertifikate sind absolut Nr1 Schutz. Wer nicht immer den USB Stick dabei hat, kann den Key in ein truecrypt Container legen und auf Dropbox oder anderen Diensten hinterlegen.
SSH Port in ein hohen Bereich zu verlegen ist nicht wirklich ein Schutz. Der Port ist mit ein paar Sekunden Mehraufwand gefunden.
Vor Allem gegen Angriffe auf die Webdienste, Bruteforce bei FTP und Mail ist dies eine ergänzende Möglichkeit die jeder SSH Ntuzer installiert haben sollte.
Wenn man Fail2Ban einsetzt, kann man die Angreifer automtisiert über mein Projekt http://www.blocklist.de/de/ melden, damit die zuständigen Provider den PC/Server säubern oder deaktivieren können.
Bei Interesse einfach vorbei schauen.
Dazu kann man dann noch Statistiken einsehen und zusammengefasst erhalten (Tagesreport)
Mfg Martin
[...] fail2ban (Artikel) wurde ich darauf aufmerksam, dass von einer chinesischen IP-Adresse ein Zeitgenosse versucht, sich [...]
[...] Deutsche FAQ: http://www.fail2ban.org/wiki/index.php/FAQ_german Blogeintrag bei Netz 10: http://netz10.de/2011/02/16/fail2ban/ [...]
[...] Links Fail2ban: http://www.fail2ban.org Deutsche FAQ: http://www.fail2ban.org/wiki/index.php/FAQ_german Blogeintrag bei Netz 10: http://netz10.de/2011/02/16/fail2ban/ [...]
Hallo,
danke für den Artikel.
Gibt es unter fail2ban die Möglichkeit mir die Passwörter anzuzeigen, die verwendet wurden?
Gute Frage, aber ich glaube nicht. Passwörter werden ja meist gehasht abgelegt und nur die jeweiligen Hashes verglichen. Wüsste nicht mal, wo ich LOKAL ein falsches Passwort aufspüren sollte. Und fail2ban sucht in der Standardeinstellung (ssh) nicht direkt nach Passwörtern, sondern stützt sich auf eventuelle Einträge in /var/log/auth.log, z.B.
Gerade was Apache angeht (phpmyadmin-Attacken usw.) geben die Logfiles manchmal einen recht guten Aufschluss darüber, was der Angreifer probiert hat.