Bösartige IPs blockieren: fail2ban, nftables und Edge-Firewalls

Wiederholte Fehlanmeldungen, Portscans und Exploit-Versuche im Serverlog lösen den Reflex aus, die Adresse zu sperren. Ob das etwas bringt, hängt aber davon ab, wo, wie lange und wie breit gesperrt wird.

Auf welcher Ebene sperren?

• Edge/CDN — hält den Verkehr fern, bevor er den Server erreicht; bei volumenstarken Angriffen die einzige realistische Option.
• Server-Firewall (nftables/iptables) — schnell und günstig für maschinenspezifische Entscheidungen; das Paket fällt, bevor die Anwendung es sieht.
• Anwendungsebene — am teuersten, weil die Anfrage bereits verarbeitet wurde, dafür die einzige Ebene mit Konto-, Sitzungs- und Verhaltenskontext.

Faustregel: Brute-Force und Scans in der Firewall stoppen, geschäftslogischen Missbrauch (Fake-Registrierungen, Gutschein-Missbrauch) in der Anwendung.

fail2ban: automatische Sperren nach Verhalten

fail2ban liest Logs und trägt eine Adresse in die Firewall ein, sobald ein Muster oft genug in einem Zeitfenster auftaucht. Eine typische SSH-Konfiguration:

Das recidive-Jail hält Adressen, die immer wieder kurze Sperren kassieren, wochenlang draußen. Tragen Sie eigene Büro- und Monitoring-Adressen in ignoreip ein — sonst sperren Sie sich eines Tages selbst aus.

Große Listen: ipset / nftables-Sets

Für Tausende Adressen einzelne Regeln zu schreiben bremst die Firewall aus. Richtig ist ein einziges Set, das mit einer Regel geprüft wird:

Diese Struktur bleibt auch bei Hunderttausenden Einträgen konstant schnell; das Set wird einfach per Cron aus aktuellen Feed-Daten neu befüllt.

Wie breit, wie lange?

• Befristete Sperren als Standard. Permanente Listen verkommen mit der Zeit: Adressen wechseln den Besitzer, der Angreifer von gestern ist der Kunde von morgen.
• Vorsicht bei /24 und größer. Wegen eines einzigen bösen Servers einen ganzen Block zu sperren trifft auch legitime Nutzer darin.
• Bei CGNAT- und Mobilfunkbereichen besonders zurückhaltend sein. Hinter einer Adresse können Tausende Anschlüsse stehen.
• Eigene Infrastruktur auf die Whitelist — Monitoring, Backup und Callback-Adressen von Zahlungsdienstleistern inklusive.

Suchmaschinen nicht versehentlich aussperren

Nicht jeder aggressiv crawlende Bot ist bösartig. Bevor Sie eine Adresse sperren, die sich als Suchmaschinen-Bot ausgibt, lösen Sie den Reverse-DNS-Eintrag auf und fragen den zurückgegebenen Namen vorwärts erneut ab; passen Name und IP nicht zusammen, ist der Bot gefälscht. Der User-Agent-Header allein beweist gar nichts.

Die Liste mit IP-DB speisen

Adressen aus den eigenen Logs vor dem Sperren zu prüfen reduziert unnötige Bans erheblich. Die API von IP-DB.com liefert Blacklist-Einträge, ASN und Community-Meldungen zu einer Adresse; vorgeschaltet vor Ihre Firewall-Automatisierung landen nur wirklich schlecht beleumundete Adressen im Set. Für Stichproben nutzen Sie die Sammelabfrage, für den Dauerbetrieb die API.