- Wann kommt die Flut über mich?
Wann kommt die Flut, die mich berührt?
Wann kommt die Flut, die mich mit fortnimmt
in ein anderes großes Leben - irgendwo.
- -- Joachim Witt & Peter Heppner, "Die Flut"
Achtung! Jetzt wird es mal wieder technisch, und nur für solche interessant, die einen eigenen Server mit ssh Zugang betreiben, so wie wir hier mit unserem h8u.de Server. Oder so etwas in Zukunft mal vorhaben.
Mich nervt ja schon seit langem dieses
Gehämmer am ssh-Server. Besonders jetzt, so ich mir die wichtigsten Sachen per
logcheck zumailen lasse, da nervt es dann doch extremst, wenn der Abschnitt "Security Events" eigentlich nur aus fehlgeschlagenen ssh-Verbindungen besteht, weil ein paar
Script-Kiddies mal wieder meinen bei mir etwas finden zu können.
Lange Rede kurzer Sinn: natürlich kommen sie nicht rein, aber jeder Fehlversuch wird im Log vermerkt, und deswegen gehen mir eventuell die wichtigen Meldungen durch die Lappen. Da ich aber sicher nicht der einzige bin, der sich mit diesem Problem beschäftigen muss, habe ich da doch mal die wunderbare Welt von Google gefragt. Schon nach kurzem Suchen wurde ich auf einer Mailing Liste des Debian Projektes
fündig.
Eigentlich wollte ich nach drei Fehlversuchen die IP-Adresse des Angreifers für eine gewisse Zeit sperren. Das benötigt aber eine gewisse Interaktion von ssh und iptables. Die Idee von "RT" ist um einiges simpler und deshalb so genial: er lässt per iptables einfach nur drei Verbindungen innerhalb von 60 Sekunden zu, egal ob fehlgeschlagenen oder nicht. Soll eine weitere Verbindung aufgebaut werden, werden diese Pakete einfach verworfen.
Seitdem ich das auch bei uns hier drin habe, haben wir so gut wie keine Attacken mehr, denn sobald die ersten Verbindungen ignoriert werden, brechen die Angreifer ab und suchen sich anscheinend ein neues Ziel.
Und um den Lesern, die bis hierhin vorgedrungen sind, das Linkklicken zu ersparen, hier nun die drei iptables Befehle:
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j LOG --log-prefix "SSH conn flooding "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 3 --rttl --name SSH -j DROP
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
Das war's schon. Coole Sache, finde ich.
Kommentare
Wenn man etwas durch ssh tunnelt, macht man eine(!) Verbindung auf, und tunnelt alle Befehle durch diese eine Verbindung, statt für jeden Befehl eine neue Verbindung aufzubauen. Und ich glaube nicht, dass die Programmierer von Subversion einen wirklich so eklatanten Designfehler einbauen.