Fail2Ban: bereits gebannt?

Ich habe Fail2Ban auf meinem Centos Server. (Config unten)

In meinem var / log / messages habe ich etwas wirklich Seltsames bemerkt:

Jun 19 12:09:32 localhost fail2ban.actions: INFO   [postfix] 114.43.245.205 already banned

Ich habe Fail2Ban so konfiguriert, dass die gesperrte IP zu iptables hinzugefügt wird.

Meine jail.conf:

[postfix]

enabled  = true
filter   = postfix
action   = iptables
port     = smtp,ssmtp
filter   = postfix
logpath  = /var/log/maillog
bantime  = 43200
maxretry = 2

Meine postfix.conf:

[INCLUDES]

before = common.conf

[Definition]
failregex = reject: RCPT from (.*)\[<HOST>\]: 550 5.1.1
            reject: RCPT from (.*)\[<HOST>\]: 450 4.7.1
            reject: RCPT from (.*)\[<HOST>\]: 554 5.7.1
            reject: RCPT from (.*)\[<HOST>\]: (.*)@yahoo.com.tw
ignoreregex =

Meine Frage ist, wie kann jemand, der bereits gesperrt wurde, iptablesnoch eine Verbindung zum Server herstellen?

Das in der anderen Antwort empfohlene wiederkehrende Gefängnis hat das Problem für mich nicht behoben. Ich habe dies jedoch irgendwann behoben. Hier ist meine Methode, falls sie anderen hilft.

Fail2ban blockiert standardmäßig nur über TCP. Zumindest bei meiner Einrichtung bemerkte ich, dass die Meldung "Bereits gesperrt" angezeigt wurde, als Bots zurückkamen, um stattdessen den blockierten Port über UDP zu testen.

Um dieses Problem zu beheben, weisen Sie Fail2ban an, den Port nicht nur über TCP, sondern über alle Protokolle zu blockieren. Sie müssen diese Änderung in /etc/fail2ban/jail.conf und im Abschnitt [Init] jeder Aktion vornehmen, die Sie unter /etc/fail2ban/action.d/ verwenden .

Ändere das:

# Default protocol
protocol = tcp

Zu:

# Default protocol
protocol = all

Als Nächstes deaktivierte ich ICMP-Echoanforderungen, damit blockierte IP-Adressen den Server nicht erreichen konnten:

1. nano /etc/sysctl.conf

2. Fügen Sie diese beiden Zeilen hinzu:

   net.ipv4.icmp_echo_ignore_all = 1  
   net.ipv4.icmp_echo_ignore_broadcasts = 1
   

3. Beenden und speichern Sie die Datei.
4. Führen Sie sysctl -p aus, damit die Änderung wirksam wird.

Führen Sie danach ein Fail2Ban-Client-Reload aus. Diese "bereits gesperrten" Nachrichten sollten nicht mehr angezeigt werden, es sei denn, Sie sind von einer IP-Adresse gesperrt, die vor dem Wirksamwerden der Sperre einige Zugriffsversuche unternommen hat.

Es ist auch wichtig, alle Ports für jeden Angreifer zu blockieren, anstatt den Port, auf den sie zugreifen wollten, indem Sie die Aktion iptables-allports in jedem der Jails verwenden. Andernfalls können sie ein anderes Gefängnis auslösen und in den Protokollen als "bereits gesperrt" enden.

Wenn Sie sich die Ausgabe von ansehen iptables-save, werden Sie feststellen, dass die fail2banKetten so eingerichtet sind, dass sie Pakete gemäß den durch die Filter definierten Regeln auswerten. Beispiel:

:fail2ban-ssh - [0:0]
-A INPUT -p tcp -A INPUT -p tcp -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh 
-A fail2ban-ssh -j RETURN

Der Datenverkehr erreicht den Server noch, bevor die anderen Routingregeln angewendet werden und der Datenverkehr abgelehnt wird. fail2bansieht immer noch diesen anfänglichen Verkehr, und deshalb sehen Sie die "bereits gesperrten" Nachrichten. Außerdem gibt es einen speziellen Filter für Rückfällige ( /etc/fail2ban/filter.d/recidive.conf):

# Fail2Ban filter for repeat bans
#
# This filter monitors the fail2ban log file, and enables you to add long
# time bans for ip addresses that get banned by fail2ban multiple times.
#
# Reasons to use this: block very persistent attackers for a longer time,
# stop receiving email notifications about the same attacker over and
# over again.
#
# This jail is only useful if you set the 'findtime' and 'bantime' parameters
# in jail.conf to a higher value than the other jails. Also, this jail has its
# drawbacks, namely in that it works only with iptables, or if you use a
# different blocking mechanism for this jail versus others (e.g. hostsdeny
# for most jails, and shorewall for this one).

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
before = common.conf

[Definition]

_daemon = fail2ban\.server\.actions

# The name of the jail that this filter is used for. In jail.conf, name the
# jail using this filter 'recidive', or change this line!
_jailname = recidive

failregex = ^(%(__prefix_line)s| %(_daemon)s%(__pid_re)s?:\s+)WARNING\s+\[(?!%(_jailname)s\])(?:.*)\]\s+Ban\s+<HOST>\s*$

[Init]

journalmatch = _SYSTEMD_UNIT=fail2ban.service PRIORITY=4

# Author: Tom Hendrikx, modifications by Amir Caspi

Dies geschieht , wenn die IP - Adresse Sie verbietet nicht , ist eigentlich die IP - Adresse des Clients, auf dem Server ist zu verbinden. ZB wenn sich Ihr Server zufällig hinter einem Load Balancer oder Proxy befindet.

Es hat eine ganze Weile gedauert, bis ich das herausgefunden habe. Der rote Faden bestand darin, dass die Protokolle so konfiguriert waren, dass sie die X-Forwarded-ForIP-Adresse anstelle der tatsächlichen Quelladresse, die in meinem Fall der Lastenausgleich war, erfassten.

In diesem Fall ist fail2ban keine große Hilfe, da das Sperren der anstößigen IP den gesamten Datenverkehr blockieren würde .

Ich möchte mein eigenes Problem und meine Lösung mit "bereits gesperrten" Nachrichten beisteuern. Wie Sie geschrieben haben, hatte ich innerhalb von Minuten Hunderte von ihnen, während der Angreifer bereits hätte gebannt werden sollen.

Bevor ich anfange, hier ist mein System:

• Plesk 12
• Centos 7
• Plesk-Module installiert, betreibt und konfiguriert fail2ban für mich

Bei der Installation von OpenVPN auf meinem Rootserver hatte ich firewalld auf iptables umgestellt. Das könnte dieses Problem für mich verursacht haben, aber abgesehen davon war mein System größtenteils unberührt und ziemlich frisch installiert (Strato-Rootserver schlug Installationsimage vor).

Wenn Sie dieses Problem haben, überprüfen Sie bitte /etc/fail2ban/jail.d/00-firewalld.conf auf eine Zeile, die so aussieht:

banaction = firewallcmd-ipset

Von dem Moment an, als ich das auskommentierte, die Datei speicherte und neu startete fail2ban.service, war mit fail2ban alles in Ordnung. Keine weiteren Nachrichten

Ich bin kein Experte, hoffe aber, Ihnen die richtige Antwort zu geben. Wenn das für Sie funktioniert, lassen Sie es mich bitte wissen!

Meine Frage ist, wie kann jemand, der bereits in Iptables blockiert wurde, noch eine Verbindung zum Server herstellen?

Die Verbindung zum Server wurde nur einmal hergestellt, aber in dieser einen Verbindung wurde versucht, mehrere E-Mails an wahrscheinlich nicht vorhandene Postfächer zuzustellen (wie [email protected], [email protected], [email protected] usw.).

Sie haben Ihren Postfix-Filter so konfiguriert, dass diese Versuche gesperrt werden, damit die IP nach X-Versuchen gesperrt wird. Möglicherweise ist der Client bereits von Postfix getrennt, aber da Postfix möglicherweise nicht die gesamte E-Mail-Verarbeitung abgeschlossen hat, kann Fail2Ban einen weiteren Versuch desselben Clients erkennen, wenn Postfix seine E-Mails verarbeitet. Auf diese Weise wird die Nachrichtenadresse bereits gesperrt. Das liegt daran, wie die Postfix-Warteschlange funktioniert.

Meine Frage ist, wie kann jemand, der bereits in Iptables blockiert wurde, noch eine Verbindung zum Server herstellen?

Unglaublich gute Frage. Ich habe mich umgesehen, ob meine Firewallregeln nicht funktionieren, die aber iptables --list-rulesgenau mit einem anderen Produktionsserver mit funktionierendem fail2ban übereinstimmen.

Die überwältigende Lösung bestand darin, den blockierten Ports den Port 8080 hinzuzufügen, da ich immer noch über Entwicklungsports auf die Anmeldeseite zugegriffen habe.

Die Lösung für meine Situation ist also, dass dieses Problem eine recht einfache Anpassung meiner war jail.local:

[JIRA-LOGIN-tcp]
  enabled = true
  port = http,https,8080
  protocol = tcp
  filter = JIRA-LOGIN-ERROR
  logpath = /var/atlassian/application-data/jira/log/atlassian-jira-security.log
  bantime = 600
  maxretry = 1

Siehe /unix//a/525798/22315

Vermutlich fehlt Port 587 in der Zeile "port =", und Sie können die Postfix-Konfigurationsdatei überprüfen oder mit "lsof -i: 587" direkt herausfinden, ob Postfix zum Öffnen dieses Ports konfiguriert wurde.