Perché iptables non blocca un indirizzo IP?

9

Ho configurato fail2ban per monitorare un determinato modello di traffico dannoso che sto ricevendo e vietare gli indirizzi IP associati.

Sembra che tutto funzioni alla grande: regex si adatta in modo appropriato al modello e l'indirizzo IP del problema viene aggiunto a iptables.

Tuttavia, quando controllo i registri di Apache ricevo ancora hit dall'indirizzo IP che viene bandito. È come se iptables non funzionasse affatto.

Vorrei quindi condividere alcuni dettagli solo per confermare che tutto è configurato correttamente.

Innanzitutto, deselezionerò e ricaricherò le regole di iptables:

$ 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

Ora, ecco come appare la configurazione fail2ban:

$ 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.

Come puoi vedere, ho un failregex impostato in un filtro e il filtro è abilitato. Utilizzando fail2ban-regex, il filtro trova una corrispondenza nel file di registro che sto monitorando. (In questo momento sono attivamente colpito da un indirizzo IP problematico che sta rendendo i test abbastanza facili.)

Quindi ora riavvio fail2ban e osservo le regole che entrano in vigore:

$ 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

Come mostra il registro fail2ban, la serie di regole sembra essere configurata correttamente. Puoi già vedere che l'indirizzo IP problematico viene subito catturato e bandito. L'output di iptables mostra che è stato effettivamente eliminato.

Tuttavia, sto già osservando che non ci sono pacchetti rilasciati per quell'indirizzo IP che corrisponde alla catena fail2ban-apache-xmlrpc. Abbastanza sicuro, controllo i log di Apache:

$ 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 "-" "-"

No, non viene bloccato! Posso anche confermare questo nel registro fail2ban:

$ 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

Continua a riapparire nel registro di Apache e quindi fail2ban sta cercando di continuare a vietarlo!

Onestamente non riesco a capire per la mia vita perché iptables non stia abbandonando il traffico da questo indirizzo IP. L'ordine delle regole mi sembra corretto, con il DROP che viene prima di ogni altra cosa.

Ho un sacco di risultati su Google in cui le persone hanno un problema simile, ma sembra sempre tornare a un problema che vieta il traffico SSH in cui si trovano su una porta non standard. Nel mio caso sto solo cercando di vietare un indirizzo IP sulla porta http 80 standard.

Spero di trascurare qualcosa di follemente semplice. Questo è un VPS che esegue Ubuntu 12.04 su Linode. Se qualcuno ha delle idee, per favore me lo faccia sapere. Grazie molto...

EDIT : ecco l'output diiptables -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
fonte
L'output di iptables -spotrebbe essere più utile per noi rispetto al formato diiptables -L
— Daniel Widrick del
@ lVlint67 - Ho modificato la mia domanda per mostrare l'output di iptables -Sper te. Fammi sapere se questo ti dà ulteriori spunti.
— jsdalton,
L'ultima voce del registro Apache è alle 02:44:02 e il primo messaggio fail2ban che l'IP è stato bannato è alle 02:52:30, quindi non vedo alcuna prova del suo funzionamento. Fornisci il file fail2ban.log completo per il periodo.
— mgorven
Il primo ban che vedo dal registro fail2ban era alle 2:43 ma ho anche notato delle discrepanze temporali. NOTA: il divieto si verifica nel So now I restart fail2ban and observe the rules taking effect:blocco
— Daniel Widrick,

Risposte:

10

L' iptables -soutput sembra corretto e non so come 80.82.70.239/32accedervi any:80sul server attraverso il firewall. La mia prima ipotesi è che tu abbia un proxy / bilanciamento del carico di fronte al server e Apache sta registrando l' HTTP_X_FORWARDED_FORintestazione o come mai viene chiamato. In tal caso, dovrai spostare la logica del firewall sul proxy / bilanciamento del carico o verso il basso al livello dell'applicazione (Apache calcola l' FORWARDED_FORintestazione e nega l'accesso.

In entrambi i casi:

Il prossimo corso di azione che vorrei intraprendere è quello di catturare l'output di iptables -ste pubblicato sopra. Disabilitare fail2ban e caricare la configurazione con la catena fail2ban e l'indirizzo IP bloccati in iptables.

Ma fallo come segue come prima -Aregola:

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

Se ti sentiresti meglio intrappolando 80 e 443 provaci. L'idea è che i registri di FIREWALL possano mostrare qualcosa che ci manca se prestiamo attenzione ai pacchetti da fonti sospette.

— Daniel Widrick
fonte
3
L'hai inchiodato. Non so perché non ci abbia pensato prima. Apache è in esecuzione dietro Cloudflare e io ne hanno Apache configurato per registrare l'indirizzo IP HTTP_FORWARDED_FOR. Il traffico effettivo arriva tramite il server Cloudflare, quindi il tentativo di bloccarlo utilizzando fail2ban / iptables non funzionerà. Grazie!
— jsdalton,
Usiamo i bilanciatori di carico haproxy nel campus per gestire LB e HA, quindi ho acquisito familiarità con le piccole "stranezze" che l'installazione comporta. Non so cosa sia Cloudflare, ma se si ha un accesso adeguato, è possibile spostare il divieto sul bilanciamento del carico. ... Se ciò non è possibile, Apache potrebbe essere in grado di gestire il blocco con un metodo, ma non ho familiarità con esso dalla parte superiore della mia testa.
— Daniel Widrick,
@jsdalton Qual è stata la soluzione con cui sei finito. In una barca simile io stesso in questo momento.
— Jay,
@jay Dato che devi esaminare le intestazioni http stai guardando qualcosa chiamato filtro "Layer 7" o firewall. Altrimenti puoi provare a bloccare i tentativi di bilanciamento del carico / proxy se è sotto il tuo controllo.
— Daniel Widrick,
1

L'output di iptables in realtà mostra che mentre esiste una regola per l'indirizzo IP fail2ban ritiene che debba essere filtrata e rilasciata, nessun pacchetto è passato attraverso la catena xmlrpc fail2ban e in realtà è stato eliminato da quella regola. Invece, sono stati accettati tutti i 224 pacchetti che hanno attraversato quella catena.

Detto questo, le regole sono davvero corrette. Tuttavia, sembra che sia stato accettato più traffico dalla regola accetta la porta TCP 80 di quanto non sia stato attraverso la catena di filtri fail2ban. Il motivo più probabile è che il traffico che volevi bloccato è arrivato mentre la catena fail2ban non era ancora inserita nell'input (noto che non lo hai nelle tue regole predefinite, il che è probabilmente OK, ma significa che se ricarichi iptables la catena fail2ban non entrerà in vigore immediatamente).

Prova a correre iptables -zper azzerare il conteggio dei pacchetti e osserva di iptables -nvLnuovo l'output di . L'output non dovrebbe essere lo stesso. Inoltre, considera di salvare le regole per le catene fail2ban nelle regole iniziali per iptables ( /etc/iptables.firewall.rules). Salva le regole di delega come questa:

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

Salvare anche l'esistenza delle catene (come fail2ban-apache-xmlrpc), ma non salvare gli IP attualmente vietati.

— Falcon Momot
fonte
Grazie Falcon. Questo è probabilmente perché ho scaricato le regole di iptables e poi sono passati alcuni istanti prima di riavviare fail2ban e sono state aggiunte le regole fail2ban-apache-xmlrpc. Tuttavia, ho provato a azzerare il conteggio dei pacchetti e ricontrollare. Il risultato è stato praticamente lo stesso. Tutti i pacchetti che entrano nelle regole fail2ban-apache-xmlrpc vengono RESTITUITI e nessuno viene ELIMINATO. Ho confermato che i miei registri di Apache mostrano che il traffico arriva ancora su quell'indirizzo IP che dovrebbe cadere.
— jsdalton,
1

Ho avuto esattamente lo stesso problema del tuo sul mio sito web. Configurazione molto simile, stack LAMP, un paio di jail fail2ban funzionali, eppure ho ancora visto quegli indirizzi IP presumibilmente vietati mostrati nel file di registro di accesso. Non ho alcun proxy / bilanciamento del carico di fronte ad Apache.

La soluzione al mio problema era sorprendentemente semplice: sposta le istruzioni di divieto proprio sopra il file di configurazione di iptables!

— Haidong
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.