Schlagwort: Konfiguration

Hier hatte ich schonmal versucht, mit iptables und dem recent-Modul, die lästigen ssh-Scanner vom tatsächlichen sshd fernzuhalten. Leider hat das nie wirklich toll geklappt (die „Angreifer“ wurden zwar ausgesperrt, es gelang aber nie, die Sperre automatisch aufzuheben).

Nach zwei bis drei erfolgreichen DoS-Attacken auf unser Firmennetz habe ich mir die Liste der iptables-Module nochmal genauer durchgesehen, ob da nicht was passendes dabei ist — und siehe da; das hashlimit-Modul kann eine Regel auf eine Höchstzahl von Treffern pro Zeiteinheit beschränken. Das liest sich dann so:

# 
# keep established connections open
# 
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# 
# enable ssh:
# 
# throttle to 2 (3) connections per minute for outsourcing and internet
iptables -N ssh
iptables -A ssh -m hashlimit --hashlimit 2/minute --hashlimit-burst 3 \
         --hashlimit-mode srcip --hashlimit-name ssh --j ACCEPT
iptables -A ssh -j LOG --log-level info --log-prefix "SSH scan blocked: "
iptables -A ssh -j REJECT
iptables -A INPUT -p tcp --destination-port 22 --syn -j ssh
iptables -A FORWARD -p tcp --destination-port 22 --syn -j ssh

Das syn-Paket (also der Verbindungsaufbau) wird höchstens zweimal pro Minute durchgelassen, bestehende Verbindungen sind erlaubt. So funktioniert es.

Ich benutze logcheck. Das warnt mich bei ungewöhnlichen Aktivitäten in den Logs der Server. Leider kommt es dabei häufig vor, daß man die eigentlichen Fehler garnicht finden kann, weil man sich durch endlose Wüsten von fehlgeschlagenen ssh-Logins blättern muß:

Das nervt. Haben die Scriptkiddies nichts besseres zu tun als Shellaccounts mit schlechten Paßwörtern zu suchen? Nach ein wenig herumsichen bin ich aber hier (wenn auch nicht im Artikel sondern in den Kommentaren) auf eine einfache Lösung gestoßen:

iptables -N ssh
iptables -A ssh -m state --state ESTABLISHED -j ACCEPT
iptables -A ssh -m recent --update --seconds 300 --hitcount 5 -j REJECT
iptables -A ssh -m recent --set -j ACCEPT
iptables -A INPUT -p tcp --destination-port 22 -j ssh
iptables -A FORWARD -p tcp --destination-port 22 -j ssh

Jetzt kann jeder Client pro 5 Minuten nur noch 5 ssh-Verbindungen öffnen, was in der Regel reichen sollte (man kann das ja auch noch etwas tunen…), danach wird die Verbindung verweigert. Test:

dentaku@charon:~$ ssh trenger@svn.advanced-solutions.de uname -a
Linux kampenwand 2.6.15 #1 SMP Thu Jun 8 18:38:40 CEST 2006 i686 GNU/Linux
dentaku@charon:~$ ssh trenger@svn.advanced-solutions.de uname -a
Linux kampenwand 2.6.15 #1 SMP Thu Jun 8 18:38:40 CEST 2006 i686 GNU/Linux
dentaku@charon:~$ ssh trenger@svn.advanced-solutions.de uname -a
Linux kampenwand 2.6.15 #1 SMP Thu Jun 8 18:38:40 CEST 2006 i686 GNU/Linux
dentaku@charon:~$ ssh trenger@svn.advanced-solutions.de uname -a
Linux kampenwand 2.6.15 #1 SMP Thu Jun 8 18:38:40 CEST 2006 i686 GNU/Linux
dentaku@charon:~$ ssh trenger@svn.advanced-solutions.de uname -a
Linux kampenwand 2.6.15 #1 SMP Thu Jun 8 18:38:40 CEST 2006 i686 GNU/Linux
dentaku@charon:~$ ssh trenger@svn.advanced-solutions.de uname -a
ssh: connect to host svn.advanced-solutions.de port 22: Connection refused
dentaku@charon:~$