Warum blockiert iptables keine IP-Adresse?

9

Ich habe fail2ban so konfiguriert, dass es ein bestimmtes Muster des böswilligen Datenverkehrs überwacht und die damit verbundenen IP-Adressen sperrt.

Alles scheint gut zu funktionieren - der reguläre Ausdruck stimmt angemessen mit dem Muster überein und die IP-Adresse des Problems wird zu iptables hinzugefügt.

Allerdings, wenn ich die Apache überprüfen anmeldet ich noch Hits aus der IP - Adresse erhalten , die verboten werden immer. Es ist, als ob iptables überhaupt nicht läuft.

Lassen Sie mich einige Details mitteilen, um zu bestätigen, dass alles richtig konfiguriert ist.

Zuerst werde ich die iptables-Regeln löschen und neu laden:

$ sudo iptables -F
$ cat /etc/iptables.firewall.rules 
*filter

#  Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT

#  Accept all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#  Allow all outbound traffic - you can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

#  Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL).
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

#  Allow SSH connections
#
#  The -dport number should be the same port number you set in sshd_config
#
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

#  Allow ping
-A INPUT -p icmp -j ACCEPT

#  Log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

#  Drop all other inbound - default deny unless explicitly allowed policy
-A INPUT -j DROP
-A FORWARD -j DROP

COMMIT
$ sudo iptables-restore < /etc/iptables.firewall.rules
$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  *      *       0.0.0.0/0            127.0.0.0/8          reject-with icmp-port-unreachable
   14  1432 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    1    60 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 5/min burst 5 LOG flags 0 level 7 prefix "iptables denied: "
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   11  1638 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

So sieht die fail2ban-Konfiguration aus:

$ cat /etc/fail2ban/filter.d/apache-xmlrpc.conf 
[Definition]
failregex = .*:80 <HOST> .*POST .*xmlrpc\.php.*
ignoreregex =
$ cat /etc/fail2ban/jail.local 
[apache-xmlrpc]

enabled  = true
port     = http,https
filter   = apache-xmlrpc
logpath  = /var/log/apache2/other_vhosts_access.log
maxretry = 6
$ fail2ban-regex /var/log/apache2/other_vhosts_access.log /etc/fail2ban/filter.d/apache-xmlrpc.conf 

Running tests
=============

Use regex file : /etc/fail2ban/filter.d/apache-xmlrpc.conf
Use log file   : /var/log/apache2/other_vhosts_access.log


Results
=======

Failregex
|- Regular expressions:
|  [1] .*:80 <HOST> .*POST .*xmlrpc\.php.*
|
`- Number of matches:
   [1] 29 match(es)

Ignoreregex
|- Regular expressions:
|
`- Number of matches:

Summary
=======

Addresses found:
[1]
    80.82.70.239 (Sat Jul 13 02:41:52 2013)
    80.82.70.239 (Sat Jul 13 02:41:53 2013)
    80.82.70.239 (Sat Jul 13 02:41:55 2013)
    80.82.70.239 (Sat Jul 13 02:41:56 2013)
    80.82.70.239 (Sat Jul 13 02:41:57 2013)
    80.82.70.239 (Sat Jul 13 02:41:58 2013)
    80.82.70.239 (Sat Jul 13 02:41:59 2013)
    80.82.70.239 (Sat Jul 13 02:42:00 2013)
    80.82.70.239 (Sat Jul 13 02:42:02 2013)
    80.82.70.239 (Sat Jul 13 02:42:03 2013)
    80.82.70.239 (Sat Jul 13 02:42:04 2013)
    80.82.70.239 (Sat Jul 13 02:42:05 2013)
    80.82.70.239 (Sat Jul 13 02:42:06 2013)
    80.82.70.239 (Sat Jul 13 02:42:07 2013)
    80.82.70.239 (Sat Jul 13 02:42:09 2013)
    80.82.70.239 (Sat Jul 13 02:42:10 2013)
    80.82.70.239 (Sat Jul 13 02:42:11 2013)
    80.82.70.239 (Sat Jul 13 02:42:12 2013)
    80.82.70.239 (Sat Jul 13 02:42:13 2013)
    80.82.70.239 (Sat Jul 13 02:42:15 2013)
    80.82.70.239 (Sat Jul 13 02:42:16 2013)
    80.82.70.239 (Sat Jul 13 02:42:17 2013)
    80.82.70.239 (Sat Jul 13 02:42:18 2013)
    80.82.70.239 (Sat Jul 13 02:42:19 2013)
    80.82.70.239 (Sat Jul 13 02:42:20 2013)
    80.82.70.239 (Sat Jul 13 02:42:22 2013)
    80.82.70.239 (Sat Jul 13 02:42:23 2013)
    80.82.70.239 (Sat Jul 13 02:42:24 2013)
    80.82.70.239 (Sat Jul 13 02:42:25 2013)

Date template hits:
0 hit(s): MONTH Day Hour:Minute:Second
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second
0 hit(s): Year/Month/Day Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
0 hit(s): Day/Month/Year Hour:Minute:Second
70 hit(s): Day/MONTH/Year:Hour:Minute:Second
0 hit(s): Month/Day/Year:Hour:Minute:Second
0 hit(s): Year-Month-Day Hour:Minute:Second
0 hit(s): Year.Month.Day Hour:Minute:Second
0 hit(s): Day-MONTH-Year Hour:Minute:Second[.Millisecond]
0 hit(s): Day-Month-Year Hour:Minute:Second
0 hit(s): TAI64N
0 hit(s): Epoch
0 hit(s): ISO 8601
0 hit(s): Hour:Minute:Second
0 hit(s): <Month/Day/Year@Hour:Minute:Second>

Success, the total number of match is 29

However, look at the above section 'Running tests' which could contain important
information.

Wie Sie sehen können, habe ich einen Failregex in einem Filter eingerichtet und der Filter ist aktiviert. Bei Verwendung von fail2ban-regex findet der Filter eine Übereinstimmung in der von mir überwachten Protokolldatei. (Ich bin gerade aktiv von einer problematischen IP-Adresse betroffen, was das Testen ziemlich einfach macht.)

Jetzt starte ich fail2ban neu und beobachte, wie die Regeln in Kraft treten:

$ sudo service fail2ban restart
 * Restarting authentication failure monitor fail2ban                                                                                                                         [ OK ] 
$ tail /var/log/fail2ban.log -n 50
2013-07-13 02:42:58,014 fail2ban.server : INFO   Stopping all jails
2013-07-13 02:42:58,745 fail2ban.jail   : INFO   Jail 'apache-xmlrpc' stopped
2013-07-13 02:42:59,439 fail2ban.jail   : INFO   Jail 'ssh' stopped
2013-07-13 02:42:59,440 fail2ban.server : INFO   Exiting Fail2ban
2013-07-13 02:43:08,055 fail2ban.server : INFO   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.6
2013-07-13 02:43:08,057 fail2ban.jail   : INFO   Creating new jail 'ssh'
2013-07-13 02:43:08,111 fail2ban.jail   : INFO   Jail 'ssh' uses Gamin
2013-07-13 02:43:08,397 fail2ban.filter : INFO   Added logfile = /var/log/auth.log
2013-07-13 02:43:08,404 fail2ban.filter : INFO   Set maxRetry = 6
2013-07-13 02:43:08,414 fail2ban.filter : INFO   Set findtime = 600
2013-07-13 02:43:08,435 fail2ban.actions: INFO   Set banTime = 600
2013-07-13 02:43:09,277 fail2ban.jail   : INFO   Creating new jail 'apache-xmlrpc'
2013-07-13 02:43:09,277 fail2ban.jail   : INFO   Jail 'apache-xmlrpc' uses Gamin
2013-07-13 02:43:09,283 fail2ban.filter : INFO   Added logfile = /var/log/apache2/other_vhosts_access.log
2013-07-13 02:43:09,286 fail2ban.filter : INFO   Set maxRetry = 6
2013-07-13 02:43:09,289 fail2ban.filter : INFO   Set findtime = 600
2013-07-13 02:43:09,292 fail2ban.actions: INFO   Set banTime = 600
2013-07-13 02:43:09,458 fail2ban.jail   : INFO   Jail 'ssh' started
2013-07-13 02:43:09,792 fail2ban.jail   : INFO   Jail 'apache-xmlrpc' started
2013-07-13 02:43:11,361 fail2ban.actions: WARNING [apache-xmlrpc] Ban 80.82.70.239
$ sudo iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  244 39277 fail2ban-apache-xmlrpc  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443
  101  7716 fail2ban-ssh  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 22
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  *      *       0.0.0.0/0            127.0.0.0/8          reject-with icmp-port-unreachable
 3404  582K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
  349 20900 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
   12   720 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            state NEW tcp dpt:22
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
    2    80 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 5/min burst 5 LOG flags 0 level 7 prefix "iptables denied: "
    2    80 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 3331 4393K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-apache-xmlrpc (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       80.82.70.239         0.0.0.0/0           
  244 39277 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain fail2ban-ssh (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  *      *       223.4.147.8          0.0.0.0/0           
  101  7716 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Wie das Fail2Ban-Protokoll zeigt, scheint der Regelsatz korrekt konfiguriert zu sein. Sie sehen bereits, dass die problematische IP-Adresse sofort abgefangen und gesperrt wird. Die Ausgabe von iptables zeigt, dass es tatsächlich gelöscht wird.

Ich beobachte jedoch bereits, dass für diese IP-Adresse keine verworfenen Pakete vorhanden sind, die mit der Kette fail2ban-apache-xmlrpc übereinstimmen. Sicher genug, ich überprüfe die Apache-Protokolle:

$ tail /var/log/apache2/other_vhosts_access.log
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:53 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:54 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:56 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:57 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:58 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:43:59 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:44:00 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"
www.--SNIP--.com:80 80.82.70.239 - - [13/Jul/2013:02:44:02 +0000] "POST /xmlrpc.php HTTP/1.1" 403 474 "-" "-"

Nein, es wird nicht blockiert! Ich kann dies auch im fail2ban-Protokoll bestätigen:

$ tail /var/log/fail2ban.log
2013-07-13 02:52:30,757 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:52:37,767 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:52:44,783 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:52:51,814 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:52:58,830 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:53:05,842 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:53:11,858 fail2ban.actions: WARNING [apache-xmlrpc] Unban 80.82.70.239
2013-07-13 02:53:12,910 fail2ban.actions: WARNING [apache-xmlrpc] Ban 80.82.70.239
2013-07-13 02:53:20,118 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned
2013-07-13 02:53:27,129 fail2ban.actions: WARNING [apache-xmlrpc] 80.82.70.239 already banned

Es wird immer wieder im Apache-Protokoll angezeigt und daher versucht fail2ban, es weiterhin zu verbieten!

Ich kann ehrlich gesagt für mein ganzes Leben nicht herausfinden, warum iptables den Datenverkehr von dieser IP-Adresse nicht löscht. Die Regelreihenfolge scheint mir korrekt zu sein, wobei der DROP vor allem anderen steht.

Ich habe eine Reihe von Ergebnissen bei Google, bei denen Leute ein ähnliches Problem haben, aber es scheint immer wieder auf ein Problem zurückzuführen zu sein, das den SSH-Verkehr verbietet, wenn sie sich an einem nicht standardmäßigen Port befinden. In meinem Fall versuche ich nur, eine IP-Adresse auf dem Standard-http-Port 80 zu sperren.

Ich hoffe, ich übersehen nur etwas wahnsinnig Einfaches. Dies ist ein VPS, auf dem Ubuntu 12.04 unter Linode ausgeführt wird. Wenn jemand irgendwelche Ideen hat, lass es mich wissen. Danke vielmals...

EDIT : Hier ist die Ausgabe voniptables -S

$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N fail2ban-apache-xmlrpc
-N fail2ban-ssh
-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-xmlrpc
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
-A INPUT -j DROP
-A FORWARD -j DROP
-A OUTPUT -j ACCEPT
-A fail2ban-apache-xmlrpc -s 80.82.70.239/32 -j DROP
-A fail2ban-apache-xmlrpc -j RETURN
-A fail2ban-ssh -s 223.4.147.8/32 -j DROP
-A fail2ban-ssh -j RETURN
ubuntu  iptables  fail2ban 
— jsdalton
quelle
Die Ausgabe von iptables -skann für uns hilfreicher sein als das Format voniptables -L
— Daniel Widrick
@ lVlint67 - Ich habe meine Frage bearbeitet, um die Ausgabe von iptables -Sfür Sie anzuzeigen . Lassen Sie mich wissen, ob Sie dadurch weitere Einblicke erhalten.
— jsdalton
Der letzte Apache-Protokolleintrag ist um 02:44:02 Uhr und die erste fail2ban-Nachricht, dass die IP gesperrt wurde, ist um 02:52:30 Uhr. Ich sehe also keine Beweise dafür, dass sie nicht funktioniert. Bitte geben Sie das vollständige fail2ban.log für den Zeitraum an.
— mgorven
Das erste Verbot, das ich aus dem fail2ban-Protokoll sehe, war um 2:43 Uhr, aber ich bemerkte auch die Zeitunterschiede. HINWEIS: Das Verbot tritt im So now I restart fail2ban and observe the rules taking effect:Block auf
— Daniel Widrick

Antworten:

10

Die iptables -sAusgabe sieht richtig , und ich weiß nicht , wie 80.82.70.239/32wird immer any:80durch die Firewall auf dem Server. Meine erste Vermutung ist, dass Sie einen Proxy / Load Balancer vor dem Server haben und Apache den HTTP_X_FORWARDED_FORHeader oder was auch immer aufgerufen wird, protokolliert . Wenn sich herausstellt, dass dies der Fall ist, müssen Sie Ihre Firewall-Logik auf den Proxy / Load Balancer oder auf die Anwendungsebene verschieben (Apache berechnet den FORWARDED_FORHeader und verweigert den Zugriff.

So oder so:

Die nächste Maßnahme, die ich ergreifen würde, besteht darin, die Ausgabe von iptables -sIhnen zu erfassen, die oben veröffentlicht wurde. Deaktivieren Sie fail2ban und laden Sie die Konfiguration, wobei die fail2ban-Kette und die IP-Adresse in iptables blockiert sind.

Tun Sie dies jedoch mit der folgenden ersten -ARegel:

-A INPUT -p tcp --dport 80 -j LOG --log-prefix "HTTP: "

Wenn Sie sich besser fühlen würden, wenn Sie 80 und 443 fangen, dann machen Sie es. Der Gedanke ist, dass die Protokolle von der FEUERWAND möglicherweise etwas zeigen, was uns fehlt, wenn wir auf die Pakete aus verdächtigen Quellen achten.

— Daniel Widrick
quelle
3
Du hast den Nagel auf den Kopf getroffen. Ich weiß nicht, warum ich vorher nicht daran gedacht habe. Apache hinter Cloudflare läuft und ich tun haben Apache die HTTP_FORWARDED_FOR IP - Adresse anmelden konfiguriert. Der tatsächliche Datenverkehr kommt über den Cloudflare-Server herein. Der Versuch, ihn mit fail2ban / iptables zu blockieren, funktioniert also nicht. Vielen Dank!
— Jsdalton
Wir verwenden Haproxy Load Balancer auf dem Campus, um LB und HA zu handhaben, sodass ich mich mit den kleinen Macken vertraut gemacht habe, die das Setup mit sich bringt. Ich weiß nicht, was Cloudflare ist, aber wenn Sie über einen ordnungsgemäßen Zugriff verfügen, kann das Verbot möglicherweise auf den Load Balancer verschoben werden. ... Wenn dies nicht möglich ist, kann Apache die Blockierung möglicherweise mit einer bestimmten Methode behandeln, aber ich kenne sie auf Anhieb nicht.
— Daniel Widrick
@jsdalton Was war die Lösung, mit der Sie gelandet sind? Ich bin gerade in einem ähnlichen Boot.
— Jay
@jay Da Sie http-Header untersuchen müssen, sehen Sie sich etwas an, das als "Layer 7" -Filterung oder Firewall bezeichnet wird. Andernfalls können Sie versuchen, die Versuche am Load Balancer / Proxy zu blockieren, wenn dies unter Ihrer Kontrolle steht.
— Daniel Widrick
1

Die Ausgabe von iptables zeigt tatsächlich, dass, obwohl es eine Regel für die IP-Adresse gibt, die fail2ban gefiltert und verworfen werden sollte, keine Pakete die fail2ban xmlrpc-Kette durchlaufen haben und tatsächlich von dieser Regel verworfen wurden. Stattdessen wurden alle 224 Pakete akzeptiert, die diese Kette durchlaufen haben.

Das heißt, die Regeln sind in der Tat korrekt. Es scheint jedoch, dass mehr Verkehr von Ihrer Regel zum Akzeptieren von TCP-Port 80 akzeptiert wurde als durch die Fail2Ban-Filterkette. Der wahrscheinlichste Grund ist, dass der von Ihnen gesperrte Datenverkehr eingegangen ist, während die fail2ban-Kette noch nicht in die Eingabe eingefügt wurde (ich stelle fest, dass Sie ihn nicht in Ihren Standardregeln haben, was wahrscheinlich in Ordnung ist, aber dies bedeutet, dass Sie iptables neu laden Die fail2ban-Kette wird nicht sofort wirksam.

Versuchen Sie, die Paketanzahl iptables -zauf Null zu setzen, und beobachten Sie die Ausgabe von iptables -nvLerneut. Die Ausgabe sollte nicht gleich sein. Erwägen Sie außerdem, die Regeln für die fail2ban-Ketten in den Anfangsregeln für iptables ( /etc/iptables.firewall.rules) zu speichern . Speichern Sie die Delegierungsregeln wie folgt:

fail2ban-apache-xmlrpc  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 80,443

Speichern Sie auch die Existenz der Ketten (wie fail2ban-apache-xmlrpc), aber speichern Sie nicht die tatsächlich gesperrten IPs.

— Falcon Momot
quelle
Danke Falcon. Das liegt wahrscheinlich daran, dass ich die iptables-Regeln gelöscht habe und es dann einige Momente gedauert hat, bis ich fail2ban neu gestartet und die fail2ban-apache-xmlrpc-Regeln hinzugefügt wurden. Trotzdem habe ich versucht, die Paketanzahl auf Null zu setzen und erneut zu überprüfen. Das Ergebnis war ziemlich gleich. Alle Pakete, die in die fail2ban-apache-xmlrpc-Regeln eingehen, werden zurückgegeben und keines wird fallen gelassen. Ich habe bestätigt, dass in meinen Apache-Protokollen immer noch Datenverkehr auf der IP-Adresse angezeigt wird, die gelöscht werden soll.
— jsdalton
1

Ich hatte genau das gleiche Problem wie Sie auf meiner eigenen Website. Sehr ähnliches Setup, LAMP-Stack, ein paar funktionierende Fail2Ban-Jails, aber ich sah immer noch, dass diese angeblich gesperrten IP-Adressen in der Zugriffsprotokolldatei angezeigt wurden. Ich habe keinen Proxy / Load Balancer vor Apache.

Die Lösung für mein Problem war überraschend einfach: Verschieben Sie die Banning-Anweisungen direkt über die iptables-Konfigurationsdatei!

— Haidong
quelle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.