TS: Spezial-Raketen-Frage iptables, fail2ban, recidive

Hello,

merkwürdige Dinge laufen auf einem meiner Webhosts:

2022-01-13 08:19:43,601 fail2ban.actions: WARNING [ssh] Ban 185.220.102.241
2022-01-13 09:19:43,699 fail2ban.actions: WARNING [ssh] Unban 185.220.102.241
2022-01-13 09:19:43,727 fail2ban.actions.action: ERROR  iptables -D fail2ban-ssh -s 185.220.102.241 -j DROP returned 100
2022-01-13 10:58:47,146 fail2ban.actions: WARNING [ssh] Ban 185.220.102.241
2022-01-13 11:58:47,821 fail2ban.actions: WARNING [ssh] Unban 185.220.102.241
2022-01-13 13:51:57,177 fail2ban.actions: WARNING [ssh] Ban 185.220.102.241
2022-01-13 13:51:59,784 fail2ban.actions: WARNING [recidive] Ban 185.220.102.241

Was hat die Meldung über den Delete-Versuch der Regel zwischen den RECIDIVE-Meldungen zu sagen?

Der Server war nach einem angeblichen kurzen Stromausfall ca. 20 Stunden ohne Firewall. Das Vautron-Rechenzentrum hüllt sich aber in nichtssagende Antworten.

Mir selber ist es nur aufgefallen, dass iptables nicht mehr lief durch eine Recidive-Meldung. Ich wollte die Sperre persistent machen und "iptables -L" lieferte nur die Standardliste.

185.220.102.241 gehört mWn zur Gruppe der Tor-Server.

Kann ich den Host jetzt vergessen? :-(

Glück Auf
Tom vom Berg

--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
  1. iptables -D fail2ban-ssh -s 185.220.102.241 -j DROP returned 100
    

    iptables wurde bei dem versuch, eine Regel zu löschen, mit etwas wie exit 100 beendet.

    Untersuche mal mit

    sudo iptables -n -L | grep 185.220.102.241
    

    ob überhaupt irgendeine Role für diese IP existiert. Ich würde aus der Übrigen Beschreibung („dass iptables nicht mehr lief“) vermuten, die, ist einer anderen Aktion zum Opfer gefallen.

    So lange das nicht häufiger vorkommt (und so, lange keine Regel fail2ban-ssh -s 185.220.102.241 -j DROP existiert) ist das aus meiner Sicht erst mal kein Grund zur Besorgnis.

    1. Hm. Ich lese gerade, die Listen waren leer... dann wäre das auch das erwartende Ergebnis, wenn versucht wird, eine Regel aus einer Blockchain zu löschen, die nicht existent ist.

      Der Server war nach einem angeblichen kurzen Stromausfall ca. 20 Stunden ohne Firewall. Das Vautron-Rechenzentrum hüllt sich aber in nichtssagende Antworten.

      Hm. Merkwürdig. Wieso wird das Zeug nicht automatisch gestartet?

      Zeige mal die Ausgaben von

      sudo systemctl status fail2ban
      

      und

      sudo systemctl status netfilter-persistent.service
      

      Hint:

      Die IP 185.220.102.241 steht aktuell auch in einer der von mir genutzten Blocklisten. Bei einem Tor-Exit ist das quasi die Regel.

    2. Hello,

      Jau, danke.

      iptables -D fail2ban-ssh -s 185.220.102.241 -j DROP returned 100
      

      iptables wurde bei dem versuch, eine Regel zu löschen, mit etwas wie exit 100 beendet.

      Untersuche mal mit

      sudo iptables -n -L | grep 185.220.102.241
      

      Ich nehme immer

      iptables-save | grep ...  
      

      Damit kann man weniger Fehler machen ;-O

      ob überhaupt irgendeine Role für diese IP existiert. Ich würde aus der Übrigen Beschreibung („dass iptables nicht mehr lief“) vermuten, die, ist einer anderen Aktion zum Opfer gefallen.

      So lange das nicht häufiger vorkommt (und so, lange keine Regel fail2ban-ssh -s 185.220.102.241 -j DROP existiert) ist das aus meiner Sicht erst mal kein Grund zur Besorgnis.

      Vermutlich war es so.

      Ich verstehe nur nicht, was die da im Rechenzentrum veranstaltet haben. Es läuft u. a. ein Still-Alive-Logger für einen anderen Server auf diesem Host. Dadurch konnte ich sehen, dass der Ausfall keine zwei Minuten gedauert haben kann. Per SSH hat sich auch niemand angemeldet. Da hätte ich eine eMail bekommen. Durch die Recidive-Kontrollmeldungen kann ich auch nachvollziehen, dass iptables vorher auch (einwandfrei?) lief.

      iptables-persistent ist im rc3.d-Dir eingetragen und wird normalerweise beim Booten auch gestartet und lädt rules.v4. IPv6 habe ich dort nicht im Einsatz. Die Datei wird regelmäßig aktuell gehalten.

      Die History gibt auch nichts her.
      Das Ganze ist mir ein Rätsel.

      Da muss einer direkt per Konsole an der Maschine gefummelt haben.

      Ich werde nun doch mal über einen Hosterwechsel nachdenken. Das System muss ohnehin erneuert werden.

      Glück Auf
      Tom vom Berg

      --
      Es gibt nichts Gutes, außer man tut es!
      Das Leben selbst ist der Sinn.
      1. Naja. Du darfst nicht vergessen, dass die Maschine ja einen Stromausfall hatte. Da wurde offenbar nichts „heruntergefahren“ sondern „brutals möglich ausgeschaltet“, iptables-safe fand also nicht statt. (Ich wundere mich schon ein wenig darüber, aber ich weiß ja nicht so detailliert, was andere treiben.)

        Allerdings kann selbst ein HyperVi, erst recht VM-Ware auf einem Server mit unterbrechungsfreier Stromversorgung auf das durch diese ausgelöste Herunterfahren des Hosts reagieren und die Gäste „einfrieren“ bzw. „suspendieren“. Was hast Du? Dezidiertes „Blech“?

        Anno 2022 kann man nämlich über die Frage "virtualisiert oder dezidiert" etwas wie „Blech bringt Pech!“ sagen.

        Zurück zum Thema:

        Damit die Regeln persistent sind müssen diese irgendwann in eine Datei geschrieben werden. Bei mir sind das

        /etc/iptables/rules.v4 /etc/iptables/rules.v6

        und, aus Kompatibiltätsgründen, existiert bei mir(sic!) ein harter Link zu

        /etc/iptables/iptables.rules

        Du musst auf Deinem eigenen System nachsehen, welche Dateien Du hast.

        Du kannst jetzt mit einem cronjob und iptables-save Deine Einstellungen regelmäßig sichern - dann hast Du aber das Problem, dass fail2ban eventuell IPs nie mehr herauslöscht ODER eben damit leben, dass nach einem Stromausfall womöglich solche Zeilen im Logfile auftauchen, auf jeden Fall das Blockieren von vorn beginnt, es also (womöglich) erst mal wieder Kontrollmeldungen gibt.

        In einen der Äpfel musst Du beißen. Ich sichere übrigens bei einer anderen Gelegenheit (Abholen von Blocklists...) filtere aber alle von fail2ban gesetzten Regeln dabei aus:

        iptables-save | grep -v -- '^-A f2b.*DROP'  > "${rulesFile}"
        

        Grund:

        Damit, dass fail2ban die Listen neu aufbauen muss, kann ich gut leben... Schlechter wäre es für mich, wenn ich unterwegs bin und mich selbst aussperre bis ich wieder direkt an den Server kann, weil fail2ban die von iptables-restore aus dem $rulesFile gelesenen Sperren nie wieder aufhebt. „Schlecht“ (weil mit Aufwand verbunden) ist auch, dass ich womöglich die Regeln die Fail2ban gesetzten manuell aufheben müsste. Wer - BITTE - persistiert denn die von fail2ban gesetzten Rules?

        Hinweis:

        Ich habe den obigen Code als „schlecht“ markiert, damit das niemand genau so nachmacht und dann lamentiert, weil es bei ihm oder ihr so nicht geht. Das muss jeder für sich noch überprüfen und anpassen.