Ich nutze Debian Buster und war mit dessen fail2ban nicht vollkommen glücklich. Ziemlich viele Loginversuche wurden nicht erkannt, Ich habe dann an den Rules herumgeschraubt, das hat dann einigermaßen gepasst. Ich finde die fail2ban-Lösung aber recht aufwendig. Der Openssh-Server hat keine wirklichen Performance-Probleme bei den "üblichen" Loginversuchen. Nur wenn das einer übertreibt sollte man ihn auf die Finger hauen.
Ich habe also die fail2ban-Lösung durch ein RateLimit der Firewall ersetzt, hier ein Auszug meiner nftables Regeln:
- chain input {
- ct state invalid drop
- ct state { established, related } accept
- iif "lo" accept
- tcp dport { http, https } accept
- ip version 4 tcp dport ssh meter ssh4blocked size 1024 { ip saddr & 255.255.255.0 timeout 1h limit rate 1/minute burst 10 packets} counter name "ssh_connections" accept
- ip6 version 6 tcp dport ssh meter ssh6blocked size 1024 { ip6 saddr & ffff:ffff:ffff:ff00:: timeout 1h limit rate 1/minute burst 10 packets} counter name "ssh_connections" accept
- tcp dport ssh counter name "ssh_rate_limit" reject
Die Syntax ist angepasst an die etwas angestaubte Version von nftables in Debian Buster, für aktuelle Versionen siehe https://wiki.nftables.org/wiki-nftables/index.php/Meters.
Damit darf jedes /24 IPv4-Netz bzw. /56 IPv6-Netz einen ssh-Verbindungsaufbau pro Minute machen, der Burst von 10 erlaubt ein Überschreiten dieses Limits um bis zu 10 Verbindungsaufbauten. Alles was drüber liegt, wird von der Firewall abgeschmettert.
Mit einem kurzen Script hole ich mir alle 3 Strunden eine Statistik:
- conn=$(/usr/sbin/nft reset counter inet filter ssh_connections | awk '$1 == "packets" { print $2 }')
- [ -z "$conn" ] && exit 1
- rl=$(/usr/sbin/nft reset counter inet filter ssh_rate_limit | awk '$1 == "packets" { print $2 }')
- [ -z "$rl" ] && exit 1
- logger -p auth.info -t nftables "SSH connections: $conn, rate limit exceeded: $rl"
Hier mal ein Auszug aus dem Log:
- Nov 17 15:00:01 netcup nftables: SSH connections: 43, rate limit exceeded: 0
- Nov 17 18:00:01 netcup nftables: SSH connections: 68, rate limit exceeded: 0
- Nov 17 21:00:01 netcup nftables: SSH connections: 35, rate limit exceeded: 4
- Nov 18 00:00:01 netcup nftables: SSH connections: 72, rate limit exceeded: 4
- Nov 18 03:00:01 netcup nftables: SSH connections: 40, rate limit exceeded: 0
- Nov 18 06:00:01 netcup nftables: SSH connections: 105, rate limit exceeded: 98
- Nov 18 09:00:01 netcup nftables: SSH connections: 80, rate limit exceeded: 0
Ich bekomme also so etwa 80 Requests/3 Stunden, die vom ssh-Server bearbeitet werden müssen, heftigere Scans blockt die Firewall ab. Das ganze auf dem Standardport 22. Diese recht simple Konfiguration hat sich bislang bestens bewährt. Die "normalen" Scans kann der ssh-Server locker ab, heftigere Scans filtert die Firewall weg.
