¿Por qué iptables no bloquea una dirección IP?

9

He configurado fail2ban para monitorear un cierto patrón de tráfico malicioso que obtengo y prohibir las direcciones IP asociadas.

Todo parece estar funcionando bien: la expresión regular coincide con el patrón de manera adecuada y la dirección IP problemática se agrega a iptables.

Sin embargo, cuando reviso los registros de Apache todavía recibo visitas de la dirección IP que está siendo prohibida. Es como si iptables no se estuviera ejecutando en absoluto.

Permítanme compartir algunos detalles solo para confirmar que todo está configurado correctamente.

Primero, borraré y volveré a cargar las reglas de 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

Ahora, así es como se ve la configuración de 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.

Como puede ver, tengo un failregex configurado en un filtro y el filtro está habilitado. Usando fail2ban-regex, el filtro encuentra una coincidencia en el archivo de registro que estoy monitoreando. (En este momento, estoy recibiendo una dirección IP problemática que hace que las pruebas sean bastante fáciles).

Así que ahora reinicio fail2ban y observo que las reglas surten efecto:

$ 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

Como muestra el registro de fail2ban, el conjunto de reglas parece estar configurado correctamente. Ya puede ver que la dirección IP problemática está siendo detectada de inmediato y prohibida. El resultado de iptables muestra que, de hecho, se está descartando.

Sin embargo, ya estoy observando que no hay paquetes descartados para esa dirección IP que coincida con la cadena fail2ban-apache-xmlrpc. Efectivamente, reviso los registros de 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, no se está bloqueando! También puedo confirmar esto en el 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

Sigue apareciendo en el registro de Apache y, por lo tanto, fail2ban intenta seguir prohibiéndolo.

Honestamente, no puedo entender de por vida por qué iptables no está eliminando el tráfico de esta dirección IP. El orden de las reglas me parece correcto, con el DROP antes que nada.

Tengo un montón de resultados en Google donde las personas tienen un problema similar, pero siempre parece volver a un problema que prohíbe el tráfico SSH donde se encuentran en un puerto no estándar. En mi caso, solo estoy tratando de prohibir una dirección IP en el puerto http 80 estándar.

Espero estar pasando por alto algo increíblemente simple. Este es un VPS que ejecuta Ubuntu 12.04 en Linode. Si alguien tiene alguna idea, hágamelo saber. Muchas gracias...

EDITAR : Aquí está la salida deiptables -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
fuente
El resultado de iptables -spuede ser más útil para nosotros que el formato deiptables -L
Daniel Widrick
@ lVlint67 - Edité mi pregunta para mostrarle el resultado iptables -S. Avísame si eso te da más información.
jsdalton
La última entrada del registro de Apache es a las 02:44:02 y el primer mensaje de fail2ban de que la IP ha sido prohibida es a las 02:52:30, por lo que no veo ninguna evidencia de que no funcione. Proporcione el fail2ban.log completo para el período.
mgorven
La primera prohibición que veo del registro fail2ban fue a las 2:43 pero también noté las discrepancias de tiempo. NOTA: la prohibición ocurre en el So now I restart fail2ban and observe the rules taking effect:bloque
Daniel Widrick

Respuestas:

10

El iptables -sresultado parece correcto y no sé cómo 80.82.70.239/32está llegando a any:80su servidor a través del firewall. Mi primera suposición es que tiene un proxy / equilibrador de carga frente al servidor y Apache está registrando el HTTP_X_FORWARDED_FORencabezado o como se llame. Si ese es el caso, tendrá que mover la lógica de su firewall al proxy / equilibrador de carga o al nivel de la aplicación (Apache mathing el FORWARDED_FORencabezado y denegar el acceso.

De cualquier manera:

El siguiente curso de acción que tomaría, es capturar el resultado iptables -spublicado anteriormente. Deshabilite fail2ban y cargue la configuración con la cadena fail2ban y la dirección IP bloqueada en iptables.

Pero hazlo con lo siguiente como primera -Aregla:

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

Si te sentirías mejor atrapando 80 y 443, adelante. La idea es que los registros de FIREWALL pueden mostrar algo que nos falta si prestamos atención a los paquetes de fuentes sospechosas.

Daniel Widrick
fuente
3
Lo lograste. No sé por qué no pensé en esto antes. Apache se está ejecutando detrás Cloudflare y yo no tiene Apache configurado para registrar la dirección IP HTTP_FORWARDED_FOR. El tráfico real ingresa a través del servidor Cloudflare, por lo que tratar de bloquearlo con fail2ban / iptables no funcionará. ¡Gracias!
jsdalton
Usamos equilibradores de carga haproxy en el campus para manejar LB y HA, así que me he familiarizado con las pequeñas 'peculiaridades' que trae la configuración. No sé qué es Cloudflare, pero si tienes el acceso adecuado, es posible mover la prohibición al equilibrador de carga. ... Si eso no es posible, Apache puede manejar el bloqueo con algún método, pero no estoy familiarizado con eso.
Daniel Widrick
@jsdalton ¿Cuál fue la solución con la que terminaste? En un barco similar ahora mismo.
Jay
@jay Dado que tiene que examinar los encabezados http, está viendo algo llamado filtrado de "Capa 7" o firewall. De lo contrario, puede intentar bloquear los intentos en el equilibrador de carga / proxy si eso está bajo su control.
Daniel Widrick
1

El resultado de iptables en realidad muestra que, si bien existe una regla para la dirección IP, fail2ban siente que debe filtrarse y descartarse, ningún paquete ha pasado por la cadena fail2ban xmlrpc y, de hecho, esa regla lo ha descartado. En cambio, todos los 224 paquetes que han pasado por esa cadena han sido aceptados.

Dicho esto, las reglas son realmente correctas. Sin embargo, su regla de aceptación del puerto TCP 80 parece haber aceptado más tráfico del que ha recibido a través de la cadena de filtro fail2ban. La razón más probable es que el tráfico que deseaba bloqueado entró mientras la cadena fail2ban aún no se había insertado en la entrada (me doy cuenta de que no lo tiene en sus reglas predeterminadas, lo que probablemente esté bien, pero significa que si recarga iptables la cadena fail2ban no entrará en vigencia de inmediato).

Intente ejecutar iptables -za cero el recuento de paquetes y observe la salida de iptables -nvLnuevo. La salida no debería ser la misma. Además, considere guardar las reglas para las cadenas fail2ban en las reglas iniciales para iptables ( /etc/iptables.firewall.rules). Guarde las reglas de delegación como esta:

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

También guarde la existencia de las cadenas (como fail2ban-apache-xmlrpc), pero no guarde las IP prohibidas reales.

Falcon Momot
fuente
Gracias halcón. Eso es probable porque eliminé las reglas de iptables y luego pasaron unos momentos antes de reiniciar fail2ban y se agregaron las reglas fail2ban-apache-xmlrpc. Sin embargo, intenté poner a cero los recuentos de paquetes y volver a verificar. El resultado fue más o menos el mismo. Todos los paquetes que van a las reglas fail2ban-apache-xmlrpc se ESTÁN DEVOLVIENDO y ninguno se ESTÁ CAIENDO. Confirmé que mis registros de Apache muestran el tráfico entrante todavía en esa dirección IP que debería estar cayendo.
jsdalton
1

Tuve exactamente el mismo problema que el tuyo en mi propio sitio web. Configuración muy similar, pila LAMP, un par de cárceles funcionales de fail2ban, pero aún vi esas direcciones IP supuestamente prohibidas que aparecen en el archivo de registro de acceso. No tengo ningún proxy / equilibrador de carga frente a Apache.

La solución a mi problema fue sorprendentemente simple: mover las declaraciones de prohibición directamente sobre el archivo de configuración de iptables.

Haidong
fuente