Lidiando con los ataques HTTP w00tw00t

Tengo un servidor con apache y recientemente instalé mod_security2 porque esto me atacó mucho:

Mi versión de apache es apache v2.2.3 y uso mod_security2.c

Estas fueron las entradas del registro de errores:

[Wed Mar 24 02:35:41 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:31 2010] [error] 
[client 202.75.211.90] client sent HTTP/1.1 request without hostname 
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:47:49 2010] [error]
[client 95.228.153.177] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Wed Mar 24 02:48:03 2010] [error] 
[client 88.191.109.38] client sent HTTP/1.1 request without hostname
(see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

Aquí están los errores de access_log:

202.75.211.90 - - 
[29/Mar/2010:10:43:15 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:11:40:41 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-"
211.155.228.169 - - 
[29/Mar/2010:12:37:19 +0200] 
"GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 392 "-" "-" 

Intenté configurar mod_security2 así:

SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecFilterSelective REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecFilterSelective REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

Lo que hay en mod_security2 es que SecFilterSelective no se puede usar, me da errores. En cambio, uso una regla como esta:

SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind"
SecRule REQUEST_URI "\w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:"
SecRule REQUEST_URI "w00tw00t\.at\.ISC\.SANS\.DFind:\)"

Incluso esto no funciona. Ya no sé qué hacer. ¿Alguien tiene algún consejo?

Actualización 1

Veo que nadie puede resolver este problema usando mod_security. Hasta ahora, usar ip-tables parece ser la mejor opción para hacer esto, pero creo que el archivo se volverá extremadamente grande porque la ip cambia varias veces al día.

Se me ocurrieron otras 2 soluciones, ¿alguien puede comentar sobre ser bueno o no?

1. La primera solución que se me ocurre es excluir estos ataques de mis registros de errores de apache. Esto hará que sea más fácil para mí detectar otros errores urgentes a medida que ocurren y no tengo que escupir a través de un registro largo.

2. Creo que la segunda opción es mejor, y es bloquear hosts que no se envían de la manera correcta. En este ejemplo, el ataque w00tw00t se envía sin nombre de host, por lo que creo que puedo bloquear los hosts que no están en la forma correcta.

Actualización 2

Después de analizar las respuestas, llegué a las siguientes conclusiones.

1. Tener un registro personalizado para apache consumirá algunos recursos innecesarios, y si realmente hay un problema, es probable que desee ver el registro completo sin que falte nada.

2. Es mejor ignorar los aciertos y concentrarse en una mejor manera de analizar sus registros de errores. El uso de filtros para sus registros es un buen enfoque para esto.

Reflexiones finales sobre el tema.

El ataque mencionado anteriormente no llegará a su máquina si al menos tiene un sistema actualizado, por lo que básicamente no hay preocupaciones.

Puede ser difícil filtrar todos los ataques falsos de los reales después de un tiempo, porque los registros de errores y los registros de acceso se vuelven extremadamente grandes.

Evitar que esto suceda de cualquier manera le costará recursos y es una buena práctica no desperdiciar sus recursos en cosas sin importancia.

La solución que uso ahora es Linux logwatch . Me envía resúmenes de los registros y se filtran y agrupan. De esta manera, puede separar fácilmente lo importante de lo no importante.

Gracias a todos por la ayuda, y espero que esta publicación también pueda ser útil para alguien más.

Desde su registro de errores están enviando una solicitud HTTP / 1.1 sin el Host: parte de la solicitud. Por lo que leí, Apache responde con un error 400 (solicitud incorrecta) a esta solicitud, antes de pasar a mod_security. Por lo tanto, no parece que se procesen sus reglas. (Apache lidiando con eso antes de requerir la entrega a mod_security)

Pruébalo tú mismo:

telnet hostname 80
OBTENER /blahblahblah.html HTTP / 1.1 (ingresar)
(entrar)

Debería obtener el error 400 y ver el mismo error en sus registros. Esta es una mala solicitud y Apache está dando la respuesta correcta.

La solicitud adecuada debería verse así:

OBTENER /blahblahblah.html HTTP / 1.1
Anfitrión: blah.com

Una solución para este problema podría ser parchear mod_uniqueid, para generar una ID única incluso para una solicitud fallida, para que apache pase la solicitud a sus manejadores de solicitudes. La siguiente URL es una discusión sobre esta solución e incluye un parche para mod_uniqueid que puede usar: http://marc.info/?l=mod-security-users&m=123300133603876&w=2

No pude encontrar ninguna otra solución y me pregunto si realmente se necesita una solución.

Filtrar IP no es una buena idea, en mi humilde opinión. ¿Por qué no intentas filtrar la cadena que conoces?

Quiero decir:

iptables -I INPUT -p tcp --dport 80 -m string --to 60 --algo bm --string 'GET /w00tw00t' -j DROP

Iv también comenzó a ver este tipo de mensajes en mis archivos de registro. Una forma de prevenir este tipo de ataques es configurar fail2ban ( http://www.fail2ban.org/ ) y configurar filtros específicos para incluir en la lista negra estas direcciones IP en las reglas de iptables.

Aquí hay un ejemplo de un filtro que bloquearía la dirección IP asociada con la creación de esos mensajes.

[Mar 16 de agosto 02:35:23 2011] [error] [cliente] El archivo no existe: /var/www/skraps/w00tw00t.at.blackhats.romanian.anti-sec :) === apache w00t w00t messages jail - expresiones regulares y filtro === Cárcel

 [apache-wootwoot]
 enabled  = true
 filter   = apache-wootwoot
 action   = iptables[name=HTTP, port="80,443", protocol=tcp]
 logpath  = /var/log/apache2/error.log
 maxretry = 1
 bantime  = 864000
 findtime = 3600

Filtrar

 # Fail2Ban configuration file
 #
 # Author: Jackie Craig Sparks
 #
 # $Revision: 728 $
 #
 [Definition]
 #Woot woot messages
 failregex = ^\[\w{1,3} \w{1,3} \d{1,2} \d{1,2}:\d{1,2}:\d{1,2} \d{1,4}] \[error] \[client 195.140.144.30] File does not exist: \/.{1,20}\/(w00tw00t|wootwoot|WootWoot|WooTWooT).{1,250}
 ignoreregex =

w00tw00t.at.blackhats.romanian.anti-sec es un intento de piratería y utiliza IP falsas, por lo que las búsquedas como VisualRoute informarán sobre China, Polonia, Dinamarca, etc. de acuerdo con la IP secundada en ese momento. Por lo tanto, configurar una IP denegada o un nombre de host resoluble es casi imposible, ya que cambiará en una hora.

Personalmente escribí un script de Python para agregar automáticamente las reglas de IPtables.

Aquí hay una versión ligeramente abreviada sin registro y otra basura:

#!/usr/bin/python
from subprocess import *
import re
import shlex
import sys

def find_dscan():
        p1 = Popen(['tail', '-n', '5000', '/usr/local/apache/logs/error_log'], stdout=PIPE)
        p2 = Popen(['grep', 'w00t'], stdin=p1.stdout, stdout=PIPE)

        output = p2.communicate()[0].split('\n')

        ip_list = []

        for i in output:
                result = re.findall(r"\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b", i)
                if len(result):
                        ip_list.append(result[0])

        return set(ip_list)

for ip in find_dscan():
        input = "iptables -A INPUT -s " + ip + " -j DROP"
        output = "iptables -A OUTPUT -d " + ip + " -j DROP"
        Popen(shlex.split(input))
        Popen(shlex.split(output))

sys.exit(0)

Creo que la razón por la que mod_security no está funcionando para usted es que Apache no ha podido analizar las solicitudes por sí mismas, están fuera de especificaciones. No estoy seguro de que tenga un problema aquí: apache está registrando cosas extrañas que están sucediendo en la red, si no lo hace, no se dará cuenta de que está sucediendo. Los recursos necesarios para registrar las solicitudes son probablemente mínimos. Entiendo que es frustrante que alguien esté llenando sus registros, pero será más frustrante si deshabilita el registro solo para descubrir que realmente lo necesita. Al igual que alguien irrumpió en su servidor web y necesita los registros para mostrar cómo entraron.

Una solución es configurar ErrorLogging a través de syslog, y luego usar rsyslog o syslog-ng puede filtrar y descartar específicamente estas violaciones de RFC con respecto a w00tw00t. O bien, puede filtrarlos en un archivo de registro separado simplemente para que su ErrorLog principal sea fácil de leer. Rsyslog es increíblemente poderoso y flexible a este respecto.

Entonces, en httpd.conf podrías hacer:

ErrorLog syslog:user 

entonces en rsyslog.conf podrías tener:

:msg, contains, "w00tw00t.at.ISC.SANS.DFind" /var/log/httpd/w00tw00t_attacks.log

Tenga en cuenta que este enfoque en realidad utilizará muchas veces más recursos que el registro utilizado directamente en un archivo. Si su servidor web está muy ocupado, esto podría convertirse en un problema.

De todos modos, es una práctica recomendada que todos los registros se envíen a un servidor de registro remoto lo antes posible, y esto lo beneficiará si alguna vez ingresa, ya que es mucho más difícil borrar el rastro de auditoría de lo que se hizo.

El bloqueo de IPTables es una idea, pero puede terminar con una lista de bloqueo de iptables muy grande que puede tener implicaciones de rendimiento en sí misma. ¿Hay un patrón en las direcciones IP o proviene de una gran red de bots distribuida? Deberá haber un X% de duplicados antes de obtener un beneficio de iptables.

Dices en la Actualización 2:

Problema que aún persiste El problema que aún persiste es el siguiente. Estos ataques son de bots que buscan ciertos archivos en su servidor. Este escáner particular busca el archivo /w00tw00t.at.ISC.SANS.DFind :).

Ahora puedes ignorarlo, lo que es más recomendable. El problema sigue siendo que si algún día tienes este archivo en tu servidor de alguna manera, estás en problemas.

De mi respuesta anterior, dedujimos que Apache está devolviendo mensajes de error debido a una consulta HTML 1.1 mal formada. Todos los servidores web que admiten HTTP / 1.1 probablemente deberían devolver un error cuando reciban este mensaje (no he verificado el RFC, tal vez RFC2616 nos dice).

Tener w00tw00t.at.ISC.SANS.DFind: en su servidor en algún lugar que no signifique místicamente "tiene algún problema" ... Si crea el archivo w00tw00t.at.ISC.SANS.DFind: en su DocumentRoot o incluso DefaultDocumentRoot no importa ... el escáner está enviando una solicitud HTTP / 1.1 rota y Apache dice "no, esa es una solicitud incorrecta ... adiós". Los datos en el archivo w00tw00t.at.ISC.SANS.DFind: no se servirán.

No se requiere el uso de mod_security para este caso a menos que realmente lo desee (¿no tiene sentido?) ... en cuyo caso, puede buscar parchearlo manualmente (enlace en otra respuesta).

Otra cosa que podría considerar usar es la función RBL en mod_security. Quizás haya un RBL en línea en algún lugar que proporcione IP w00tw00t (u otras IP maliciosas conocidas). Sin embargo, esto significaría que mod_security realiza una búsqueda de DNS para cada solicitud.

¿Qué tal agregar una regla a la seguridad de mods? Algo como esto:

   SecRule REQUEST_URI "@rx (?i)\/(php-?My-?Admin[^\/]*|mysqlmanager
   |myadmin|pma2005|pma\/scripts|w00tw00t[^\/]+)\/"
   "severity:alert,id:'0000013',deny,log,status:400,
   msg:'Unacceptable folder.',severity:'2'"

Veo que la mayoría de las soluciones ya están cubiertas anteriormente, sin embargo, me gustaría señalar que no todas las solicitudes HTTP / 1.1 enviadas por el cliente sin ataques de nombre de host están dirigidas directamente a su servidor. Hay muchos intentos diferentes de tomar huellas digitales y / o explotar el sistema de red que precede a su servidor, es decir, usando:

client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /tmUnblock.cgi

para apuntar a los enrutadores Linksys, etc. Así que a veces ayuda a ampliar su enfoque y dividir sus esfuerzos de defensa entre todos los sistemas con una participación equitativa, es decir: implementar reglas de enrutador, implementar reglas de firewall (con suerte, su red tiene una), implementar firewall del servidor / tabla de IP reglas y servicios relacionados, es decir, mod_security, fail2ban, etc.

Qué tal esto ?

iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.DFind' -j DROP
iptables -I INPUT -p tcp --dport 80 -m string --to 70 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.DFind' -j LOG --log-level 4 --log-prefix Hacktool.DFind:DROP:

funciona bien para mi

Si usa hiawathaun servidor web como reverse proxyestos, estos escaneos se descartan automáticamente como basura y se clientprohíben. También filtra XSSy CSRFexplota.