Lidiando con los ataques HTTP w00tw00t

82

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.

Saif Bechan
fuente

Respuestas:

34

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.

Imo
fuente
Ahora veo el problema. ¿Recomienda la solución provista en el artículo o cree que es mejor dejarla tal como está? Es un escáner para cualquier puerta trasera del sistema. Si lo dejo solo escaneando, algún día podría ser atacado.
Saif Bechan
1
Hola Saif, creo que siempre y cuando mantengas tu instalación de Apache actualizada con tus parches de seguridad de distribución (o manual) deberías estar bien. Una solicitud HTTP / 1.1 mal estructurada (como ha estado viendo) no debería devolver nada más que un error 400 de Apache. Parece que pudo haber sido algún tipo de análisis de vulnerabilidad enfocado en enrutadores DLink. (Según algunas otras fuentes)
Imo
¿Hay al menos una forma de sacar estos campos de mi registro de errores de apache?
Saif Bechan
Tal vez pueda hacerlo a través de mod_log :: httpd.apache.org/docs/2.2/mod/mod_log_config.html#customlog
Imo
Mi sugerencia adicional sería: configure su host virtual predeterminado junto a los que están realmente en uso. Los intentos mencionados anteriormente terminarán en los registros del host virtual predeterminado .
Koos van den Hout
16

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
Des
fuente
spamcleaner.org/en/misc/w00tw00t.html solución similar, pero un poco más detallada.
Isaac
Un problema con el filtrado de cadenas en el firewall es que es "bastante lento".
Alexis Wilke
@AlexisWilke, ¿tiene evidencia que sugiera que el filtrado de cadenas de iptables es más lento que el filtrado a nivel de apache?
jrwren
@jrwren En realidad, puede ser bastante lento si y solo si no pasa el desplazamiento del paquete para dejar de buscar, es decir, "- a 60" aquí. Por defecto, buscará en todo el paquete, el límite máximo se establece en 65.535 bytes, la longitud máxima del paquete IP: blog.nintechnet.com/… El manual dice claramente "Si no se pasa, el tamaño predeterminado es el paquete".
gouessej
ese es un máximo teórico una longitud máxima más realista en internet es ~ 1500.
jrwren
11

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 =
Jackie Craig Sparks
fuente
2
Es cierto que puede bloquearlos, pero no es necesario porque son solo malas solicitudes. Es mejor ignorarlos, le ahorró trabajo y liberará algunos recursos.
Saif Bechan
Correcto @Saif Bechan, si alguien se preocupa de que los "ataques de prueba" tengan éxito, debería corregir la propia aplicación en lugar de perder el tiempo para encontrar una manera de bloquear eso.
Thomas Berger
Te di +1, gracias por la respuesta.
Saif Bechan
44
@SaifBechan, no estoy de acuerdo. w00tw00t es un escáner de vulnerabilidades, y no se puede confiar en que una máquina que emite tales solicitudes intente otro tipo de solicitudes, por lo que si soy administrador del sistema y me lleva 2 minutos prohibir dichos clientes durante días, Lo haría. Sin embargo, no basaría toda mi implementación de seguridad en tal enfoque.
Isaac
3

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.

PRW
fuente
Estos escaneos de vulnerabilidad no usan direcciones IP falsificadas. Si lo hicieran, el protocolo de enlace de 3 vías TCP no se completaría y Apache no registraría la solicitud. Para advertencias (ISP no autorizado, operadores de enrutadores, etc.), consulte security.stackexchange.com/q/37481/53422
Anthony G - justicia para Monica
2

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)
Xorlev
fuente
¿Es esto para evitar el ataque w00tw00t?
Saif Bechan
Sí, tengo que escanear los registros de errores de Apache para cualquier IP "w00tw00t" y agregarlos si no existen, aunque por simplicidad no agregué la verificación de duplicados.
Xorlev
Este script probablemente debería usar una tabla, agregar toneladas de reglas adicionales a las cadenas de iptables va a ralentizar bastante el procesamiento.
Eric
Utiliza una mesa. Sin embargo, simplifiqué mucho ya que estaba adaptado a mi sistema.
Xorlev
¿Crees que esta es una mejor solución que usar mod_security?
Saif Bechan
2

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.

hellomynameisjoel
fuente
Buena respuesta, me gustan los diferentes enfoques. Pensando en ello, tener un registro personalizado creará un mayor uso de recursos, porque todo tiene que verificarse primero, creo que esta opción también se cae. Ahora tengo logwatch habilitado. Esto me envía un informe 2 veces al día con resúmenes de todos los sistemas. Los registros de apache también se verifican y solo dice que w00tw00t intenta 300 veces. Creo que dejaré la configuración tal como está por el momento.
Saif Bechan
1

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.

Imo
fuente
No creo que Apache los rechace, solo arroja el error pero la búsqueda aún pasa. Tengo el mismo w00tw00t.at.ISC.SANS.DFind en el registro de acceso. Hace un GET. Entonces la búsqueda se realiza y si tiene el archivo en su máquina, se ejecutará. Puedo publicar las entradas del registro de acceso pero se ven igual que el registro de errores solo con un GET delante de ellas. Apache arroja el error pero la solicitud pasa. Por eso pregunté si sería una buena idea bloquear estas solicitudes sin nombres de host. Pero no quiero bloquear a los usuarios normales.
Saif Bechan
1
Claro, obtienes la misma entrada en el registro de acceso pero mira el código de error ... 400. No se procesa. HTTP / 1.1 (nombre de host) se usa para decirle a Apache a qué host virtual enviar la solicitud ... sin la parte de nombre de host de la solicitud HTTP / 1.1 Apache no sabe a dónde enviar la solicitud y devuelve un error "400 solicitud incorrecta" De vuelta al cliente.
Imo
Pruébelo usted mismo ... cree una página html en su servidor web e intente acceder a ella manualmente usando "telnet hostname 80" ... los otros pasos están en mi primera respuesta. Pondría una gran recompensa sobre él que no puede obtener el archivo html para mostrar usando HTTP / 1.1 sin el nombre de host.
Imo
Ah sí sí eso por señalarme eso. Siempre pensé que access_log eran entradas que se pasaron a través del registro de errores y que realmente ingresaron a su máquina. Gracias por señalarme esto y editaré mi publicación. Realmente aprecio tu ayuda.
Saif Bechan
Hola Saif, no hay problema, me alegro de haber ayudado. Saludos, Imo
Imo
1

¿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'"
Kreker
fuente
1

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.

Milán
fuente
1

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

Urbach-Webhosting
fuente
recomendé el conjunto de reglas OWASP_CRS / 2.2.5 o grater para mod_security
Urbach-Webhosting
Esto realmente no es una buena idea. Terminarás con muchas conexiones colgantes. Además, si su sitio tiene alguna discusión sobre esas solicitudes, puede terminar con falsos positivos.
kasperd
0

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.

Stuart Cardall
fuente