Una solución paliativa de los intentos de abuso hacia Apache

per Victor Carceler — darrera modificació 2020-03-25T15:31:05+01:00
Un servidor web que recibe peticiones de uso como proxy puede generar mucho tráfico. Aquí se presenta una solución que ignora a las peticiones abusivas.

Conectar a Internet una máquina que funciona como Proxy abierto (atendiendo a todos los clientes) creará muchos problemas. Pronto se detectará el nuevo Proxy y comenzarán a llegar peticiones. Peticiones que a medida que se sirven consumen ancho de banda en el router que conecta al Proxy con Internet. Cuando alguna web de Internet liste la IP de nuestro router como un proxy abierto, el número de peticiones aumentará y se provocará una denegación de servicio en la LAN.


Diagrama_proxy.png

El encaminador de la LAN, además del tráfico habitual, tendrá que trabajar con:

  • Todas las peticiones que envian los clientes del proxy desde Internet
  • Las diferentes conexiones del Proxy con los servidores web demandados por los clientes
  • La respuesta del Proxy hacia el cliente


Así pues, dejando de lado los problemas que para Internet supone un Proxy abierto (el servidor WWW verá que los contenidos los pide la IP del router en Internet, no el cliente real), para la organización que lo mantiene no aporta ninguna ventaja y sí muchos problemas:

  • Un tremendo consumo de ancho de banda que provocará una saturación del router, dejando con un acceso muy lento a Internet a los usuarios de la LAN y consiguiendo que desde Internet sea muy lento acceder a los servidores que se encuentran tras el router.
  • Posibles quejas por las fechorias que los clientes del Proxy han realizado a lo largo y ancho de Internet.


Así pues NO ES UNA BUENA IDEA dejar funcionando un Proxy abierto en una máquina que está conectada a Internet1. Además hay que advertir que los efectos negativos no cesarán por completo cuando el proxy deje de atender a los clientes, pues una vez que nuestra IP está listada en diferentes webs seguirán lloviendo peticiones a nuestro router haya o no un proxy abierto en nuestra LAN.

También hay que recordar que Apache puede actuar como Proxy y si no se tiene especial cuidado durante su configuración es posible que haga de proxy abierto.


Nos llueven las peticiones para que actuemos como Proxy, qué hacemos ???

Si ya se ha llegado a esta situación, porque la dirección IP de nuestro router ha sido listada en alguna web como proxy abierto, se imponen medidas drásticas.

Un centro educativo de la XEiLL sufrió esta situación. En el servidor de la XEiLL se ejecutaba Apache actuando como proxy para el servidor Zope que ejecutaba Plone para mantener la web del centro. Durante la configuración del servidor, y por tremendo error, Apache funcionó un tiempo como proxy abierto. El proxy fué detectado y la IP del router apareció en diferentes webs, y aún sigue aunque hace más de un año que no actúa como proxy abierto.

Si la IP de nuestro router aparece en Internet listada como Proxy habrá quien intente utilizarlo, y a nuestro servidor web le llegarán todas las peticiones.

Fragmento del fichero de registro de Apache (/var/log/httpd/access_log):

217.153.66.130 - - [04/Dec/2006:10:58:34 +0100] "POST http://www.airberlin.com/site/abvakanz_c.php?LANG=deu HTTP/1.0" 404 36707
217.153.66.130 - - [04/Dec/2006:10:58:34 +0100] "POST http://www.airberlin.com/site/abvakanz_c.php?LANG=deu HTTP/1.0" 404 36707 "-" "Snoopy v1.2.3"
70.36.188.134 - - [04/Dec/2006:10:58:35 +0100] "GET http://www.cli3nt.com/aenv/ HTTP/1.1" 404 23559
70.36.188.134 - - [04/Dec/2006:10:58:35 +0100] "GET http://www.cli3nt.com/aenv/ HTTP/1.1" 404 23559 "-" "-"
202.105.101.187 - - [04/Dec/2006:10:58:38 +0100] "GET http://clickingagent.com/proxycheck.php?ip=82.151.210.205&port=80&loc= HTTP/1.0" 404 15578
202.105.101.187 - - [04/Dec/2006:10:58:38 +0100] "GET http://clickingagent.com/proxycheck.php?ip=82.151.210.205&port=80&loc= HTTP/1.0" 404 15578 "-" "Mozilla/4.0 (compatible; MSIE
 6.0; Windows NT 5.1)"
195.2.114.1 - - [04/Dec/2006:10:59:07 +0100] "POST http://cheap0available.info/CheckProxy.php HTTP/1.0" 404 36663
195.2.114.1 - - [04/Dec/2006:10:59:07 +0100] "POST http://cheap0available.info/CheckProxy.php HTTP/1.0" 404 36663 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"
209.160.73.8 - - [04/Dec/2006:10:59:15 +0100] "POST http://www.qtecmx.info/dgen/http_post.php HTTP/1.0" 404 36675
209.160.73.8 - - [04/Dec/2006:10:59:15 +0100] "POST http://www.qtecmx.info/dgen/http_post.php HTTP/1.0" 404 36675 "http://www.qtecmx.info/dgen/http_post.php" "Mozilla/4.0"
69.232.79.10 - - [04/Dec/2006:10:59:20 +0100] "GET http://80.67.86.18/n14.login.scd.yahoo.com/config/isp_verify_user?&l=Kingsnake93&p=superman HTTP/1.0" 404 15578
69.232.79.10 - - [04/Dec/2006:10:59:20 +0100] "GET http://80.67.86.18/n14.login.scd.yahoo.com/config/isp_verify_user?&l=Kingsnake93&p=superman HTTP/1.0" 404 15578 "-" "-"
209.160.73.8 - - [04/Dec/2006:10:59:21 +0100] "POST http://www.qtecmx.info/dgen/http_post.php HTTP/1.0" 404 36675
209.160.73.8 - - [04/Dec/2006:10:59:21 +0100] "POST http://www.qtecmx.info/dgen/http_post.php HTTP/1.0" 404 36675 "http://www.qtecmx.info/dgen/http_post.php" "Mozilla/4.0"
209.160.73.8 - - [04/Dec/2006:10:59:30 +0100] "POST http://www.qtecmx.info/dgen/http_post.php HTTP/1.0" 404 36675
209.160.73.8 - - [04/Dec/2006:10:59:30 +0100] "POST http://www.qtecmx.info/dgen/http_post.php HTTP/1.0" 404 36675 "http://www.qtecmx.info/dgen/http_post.php" "Mozilla/4.0"
209.160.73.8 - - [04/Dec/2006:10:59:42 +0100] "POST http://www.qtecmx.info/dgen/http_post.php HTTP/1.0" 404 36675
209.160.73.8 - - [04/Dec/2006:10:59:42 +0100] "POST http://www.qtecmx.info/dgen/http_post.php HTTP/1.0" 404 36675 "http://www.qtecmx.info/dgen/http_post.php" "Mozilla/4.0"
209.160.73.8 - - [04/Dec/2006:10:59:45 +0100] "POST http://www.qtecmx.info/dgen/http_post.php HTTP/1.0" 404 36675
209.160.73.8 - - [04/Dec/2006:10:59:45 +0100] "POST http://www.qtecmx.info/dgen/http_post.php HTTP/1.0" 404 36675 "http://www.qtecmx.info/dgen/http_post.php" "Mozilla/4.0"
209.160.73.8 - - [04/Dec/2006:10:59:52 +0100] "POST http://www.qtecmx.info/dgen/http_post.php HTTP/1.0" 404 36675
209.160.73.8 - - [04/Dec/2006:10:59:52 +0100] "POST http://www.qtecmx.info/dgen/http_post.php HTTP/1.0" 404 36675 "http://www.qtecmx.info/dgen/http_post.php" "Mozilla/4.0"
209.160.65.31 - - [04/Dec/2006:10:59:54 +0100] "POST http://209.160.65.31/~casino00/shat/tools/info.php HTTP/1.1" 404 36714
209.160.65.31 - - [04/Dec/2006:10:59:54 +0100] "POST http://209.160.65.31/~casino00/shat/tools/info.php HTTP/1.1" 404 36714 "proxy_test_referer" "Mozilla/4.0 (compatible; MSIE 6.0
; Windows NT 5.0)"
66.90.101.144 - - [04/Dec/2006:10:59:54 +0100] "POST http://66.90.101.144/sp/proxy.php HTTP/1.1" 404 36657
66.90.101.144 - - [04/Dec/2006:10:59:54 +0100] "POST http://66.90.101.144/sp/proxy.php HTTP/1.1" 404 36657 "http://66.90.101.144/sp/proxy.php" "User-Agent: Mozilla/4.0 (compatible
; MSIE 6.0; Windows NT 5.1)"
209.160.73.8 - - [04/Dec/2006:10:59:56 +0100] "POST http://www.qtecmx.info/dgen/http_post.php HTTP/1.0" 404 36675
209.160.73.8 - - [04/Dec/2006:10:59:56 +0100] "POST http://www.qtecmx.info/dgen/http_post.php HTTP/1.0" 404 36675 "http://www.qtecmx.info/dgen/http_post.php" "Mozilla/4.0"
81.222.134.64 - - [04/Dec/2006:11:00:14 +0100] "GET http://www.daytonasystem.com/vars.php HTTP/1.0" 404 15578
81.222.134.64 - - [04/Dec/2006:11:00:14 +0100] "GET http://www.daytonasystem.com/vars.php HTTP/1.0" 404 15578 "-" "-"

Se puede comprobar que el servidor web recibe un montón de peticiones que no corresponden a su dominio, y obtienen el código de error 404 (No encontrado). El problema es que para cada una de esas peticiones nuestro servidor web transmite la página web correspondiente a documento no encontrado y esto puede suponer un gran tráfico.

Solución: Ignorar las peticiones inadecuadas

No tenemos ningún control sobre los paquetes que recibimos, pero sí sobre los que enviamos de manera que la única medida que podemos tomar es no contestar a ninguna de esas peticiones con ningún paquete, ni siquiera con la página de documento no encontrado.

Gracias a netfilter/iptables podremos instruir a nuestro máquina para que descarte los paquetes provenientes de IPs que intentan abusar de nuestro servidor, sin ninguna respuesta. El problema es que el conjunto de máquinas que intentan utilizarnos como proxy varía a lo largo del tiempo. De alguna forma deben incluirse en la lista de direcciones a ignorar a las nuevas máquinas que nos intenten utilizar como proxy y deberemos borrar de la lista a las que hace tiempo que no nos envian ningún paquete, porque debemos evitar que el número de IPs baneadas crezca sin fin.


La estrategia a seguir para proteger a nuestro servidor será programar en Cron una tarea periódica de forma que cada minuto:

  1. Se busquen en las últimas 1000 (parámetro ajustable) líneas del fichero de registro de Apache indicios de abuso. Detectaremos las líneas abusivas porque tienen el código de error 404 o porque en la petición se indica un puerto (por ejemplo, GET dominio.com:8081). Sólo aceptaremos líneas que comiencen con una IP y ése dato será el único que nos interese.
    tail -n 1000 /var/log/httpd/access_log | grep -E  ' 404 |^[^"]+"[^"]+:[0-9]' | grep -E "^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3} " | cut -f 1 -d " "
    Lo más destacable de la sentencia anterior es la expresión regular del primer grep, que debe concordar con todas las líneas de registro en las que aparece el código de error 404 o bien con aquellas que intentan realizar peticiones a determinado puerto ("CONNECT 65.54.244.72:25 HTTP/1.0").

  2. Ordenaremos la lista de IPs obtenida en el paso anterior y después contaremos el número de veces que se repite cada una de ellas. Así sabremos el número de peticiones abusivas que se han recibido desde cada IP en las 1000 líneas exploradas. Aquellas IPs desde las que nos hayan llegado más de 4 (otro parámetro ajustable) intentos de abuso las incluiremos en la lista de direcciones a prohibir.
  3. Borraremos las reglas del cortafuegos (correspondientes al minuto anterior) e insertaremos reglas para bloquear las IPs prohibidas que se han obtenido en el punto 2.
    /sbin/iptables -A INPUT -i eth0 -p tcp --dport 80 -j DROP -s <IP a prohibir>


De esta forma tan sencilla obtenemos un sistema que monitoriza las conexiones entrantes en busca de abusos, cuando alguien hace más de 4 peticiones incorrectas pasa a formar parte de la lista de IPs prohibidas, descartándose todos los paquetes que tengan por origen dicha IP. Y se mantendrá en dicha lista hasta que el abuso desaparezca de las últimas 1000 líneas del fichero de registro de Apache.

Después de poner en marcha el sistema se aprecia una gran mejora en el rendimiento de la LAN y en el desempeño del servidor web.

Si examinamos las reglas del cortafuegos:

[root@raca abuso_de_apache]# iptables -L -v -n
Chain INPUT (policy ACCEPT 1846K packets, 916M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       tcp  --  eth0   *       64.105.113.203       0.0.0.0/0           tcp dpt:80
    0     0 DROP       tcp  --  eth0   *       72.232.83.114        0.0.0.0/0           tcp dpt:80
    0     0 DROP       tcp  --  eth0   *       72.232.83.98         0.0.0.0/0           tcp dpt:80
  108  5184 DROP       tcp  --  eth0   *       72.35.83.140         0.0.0.0/0           tcp dpt:80
    0     0 DROP       tcp  --  eth0   *       72.36.139.50         0.0.0.0/0           tcp dpt:80
    0     0 DROP       tcp  --  eth0   *       75.152.3.189         0.0.0.0/0           tcp dpt:80
    0     0 DROP       tcp  --  eth0   *       81.42.122.85         0.0.0.0/0           tcp dpt:80
    0     0 DROP       tcp  --  eth0   *       82.192.32.65         0.0.0.0/0           tcp dpt:80
    0     0 DROP       tcp  --  eth0   *       82.224.54.104        0.0.0.0/0           tcp dpt:80
   14   632 DROP       tcp  --  eth0   *       83.182.172.141       0.0.0.0/0           tcp dpt:80
    0     0 DROP       tcp  --  eth0   *       89.149.208.208       0.0.0.0/0           tcp dpt:80

Chain FORWARD (policy ACCEPT 19946 packets, 1516K bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 1928K packets, 1420M bytes)
 pkts bytes target     prot opt in     out     source               destination
[root@raca abuso_de_apache]#

Observamos la lista de IPs ignoradas y como en lo que llevamos de minuto se han recibido 108 paquetes (que se han descartado) desde 72.35.83.140.



Se puede hacer algo más ?

A nivel técnico lo más importante ya está hecho. Detectar quien abusa y protegerse de manera dinámica. Después es posible interesarse por las direcciones IPs que crean problemas. Por ejemplo, la dirección 72.35.83.140 intenta conectar con nuestro proxy unas 500 veces por minuto.

Si consultamos la base de datos Whois:

vcarceler@meara:~$ whois 72.35.83.140

OrgName:    Bocacom.net LLC
OrgID:      BOCAC
Address:    4950 Communication Ave.
Address:    Suite 110
City:       Boca Raton
StateProv:  FL
PostalCode: 33431
Country:    US

NetRange:   72.35.64.0 - 72.35.95.255
CIDR:       72.35.64.0/19
NetName:    BOCACOM
NetHandle:  NET-72-35-64-0-1
Parent:     NET-72-0-0-0-0
NetType:    Direct Allocation
NameServer: NS5.BOCACOM.NET
NameServer: NS6.BOCACOM.NET
Comment:
RegDate:    2005-05-02
Updated:    2006-06-19

OrgAbuseHandle: ABUSE900-ARIN
OrgAbuseName:   Abuse Contact
OrgAbusePhone:  +1-561-939-3330
OrgAbuseEmail:  abuse@bocacom.net

OrgNOCHandle: NOC1776-ARIN
OrgNOCName:   Network Operations Center
OrgNOCPhone:  +1-561-939-3330
OrgNOCEmail:  noc@bocacom.net

OrgTechHandle: NOC1776-ARIN
OrgTechName:   Network Operations Center
OrgTechPhone:  +1-561-939-3330
OrgTechEmail:  noc@bocacom.net

# ARIN WHOIS database, last updated 2006-12-27 19:10
# Enter ? for additional hints on searching ARIN's WHOIS database.

Encontramos que la IP pertenece a www.bocacom.net, una empresa de hosting. Ya tenemos el teléfono y la dirección de correo en la que nos podemos quejar del abuso.



1 Con la posible excepción de que se esté montando un Honeypot.