fail2ban/iptables Probleme

  • Moin Moin,


    aktuell kämpfe ich mit einem Problem bei fail2ban und iptables.


    Zusammenfassung:

    • Debian 10, fail2ban 0.10.2
    • Der Regex-Check filtert das gewünschte fehlerfrei raus
    • Die IP wird unter fail2ban auch fehlerfrei als geblockt angezeigt (ebenfalls im log)


    Problem:

    Die IP wird allerdings nicht zu den iptables hinzugefügt. Mittlerweile habe ich glaube ich nahezu alle Settings durch welche ich im Netz finden konnte. Aber leider alles ohne Erfolg.



  • Heißt das im Umkehrschluss, dass man fail2ban unter Debian 10 nicht mit iptables arbeiten lassen kann?

    Nein (oder je nach Lesart/Klassifikation: "Jein") – Es gibt eine Kompatibilitätsschicht, siehe "You can switch back and forth between iptables-nft and iptables-legacy by means of update-alternatives". (Sowohl der Artikel, auf welchen der obige Link zu nftables verweist als auch der hier genannte sind miteinander verknüpft.)

    Aber man muss zunächst explizit auf "iptables-legacy" wechseln, was der Grund für obiges Problem gewesen zu sein scheint.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Mit "banaction = nftables-multiport" hatte ich es auch versucht.


    Zudem hatte ich das Paket nftables auch noch installiert und zusätzlich mit UFW hatte ich es auch versucht.


    Es kann doch nicht sein, dass es default nicht klappt. Es ist ein default Debian und fail2ban ist aus den offiziellen Repos.

  • Mit "banaction = nftables-multiport" hatte ich es auch versucht. Zudem hatte ich das Paket nftables auch noch installiert […]

    Wenn das wirklich alles war (eine einzelne Zeile ändern und das Paket installieren), dann reicht das für sich nicht aus. Es gibt mehrere ausführlichere Anleitungen, wenn man wirklich eine saubere Umstellung auf nftables vornehmen will unter Debian Buster (anstatt die Kompatibilitätsschicht zu verwenden), siehe beispielsweise "Fail2Ban auf nftables umstellen". Ganz ohne ein Einlesen in das nftables-Thema wird das aber ggf. nicht (zufriedenstellend) gelingen. Informationen zu nftables sind im Upstream-GitHub-Repository von fail2ban leider sehr verteilt/versteckt.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Ich bin jetzt auf die legacy gewechselt. nftables hat mich heute viele Haare gekostet.


    Code
    update-alternatives --set iptables /usr/sbin/iptables-legacy
    update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy


    Zumindest taucht die IP jetzt auf. Allerdings kann das Endgerät - in diesem Fall mein Handy - trotzdem noch auf die Webseite zugreifen.

    Ich bin definitiv kein kein iptables Profi aber das schaut eigentlich gut für mich aus. Sprich, eigentlich müsste ich nicht mehr auf die Seite kommen.

  • Sorry für die späte Rückmeldung.


    Nachdem ich jetzt auf iptables-legacy/ip6tables-legacy umgestellt hatte klappt es nun.

    Von der IP war da wirklich v4 und v6 "irgendwie zusammen" am start. Aber krass, dass bei nem REJECT die Provider es mit ner anderen IP versuchen.

    Nachdem die IPv6 geblockt wurde, versuchte es die IPv4.


    Dann hatte ich mich noch kurz gewundert warum f2b bei ner IPv4 das "ganze" /32 blockt..... Naja, Layer 8 sag ich da nur :D;(

  • Vielleicht noch eine kleiner Tipp:

    Ich hatte ursprünglich Probleme mit Fail2ban in Verbindung mit eigenen iptables Regeln. Irgendwie hat es mir da vor einigen Jahren immer alle Regeln rausgehauen.


    Dann habe ich nach einer Variante gesucht Fail2ban ohne iptables zu verwenden und auf folgende Lösung gestossen:

    https://www.faqforge.com/linux…les-to-block-connections/


    Hier wird einfach die Route der zu blockiernden IP angepasst. Funktioniert für mich jedenfalls ohne Probleme.

  • Auch ein interessanter Ansatz. Ich hatte mal nach ein paar Vergleichen dazu gesucht. Einige meinten, dass diese Art aber "Systemlastiger" sei. Kannst du dazu was sagen?