Pregunta Tratar con los ataques HTTP w00tw00t


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

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 del 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 de esta manera:

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 está en mod_security2 es que SecFilterSelective no se puede usar, me da errores. En su lugar utilizo 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 será extremadamente grande porque la ip cambia varias veces al día.

Se me ocurrieron otras 2 soluciones, ¿alguien puede comentarlas sobre si son buenas o no?

  1. La primera solución que me viene a la mente 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 tiene que escupir a través de un registro largo.

  2. La segunda opción es mejor, creo, y eso 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, así que creo que puedo bloquear los hosts que no están en la forma correcta.

Actualización 2

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

  1. Tener un registro personalizado para apache consumirá algunos recursos innecesarios, y si realmente hay un problema, probablemente querrá mirar 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, así que básicamente no hay preocupaciones.

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

Evitar que esto ocurra de alguna 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 que no es importante.

Gracias a todos por la ayuda, y espero que esta publicación también pueda ser útil para otra persona.


80
2018-03-24 05:33


origen




Respuestas:


Desde su registro de errores, envían una solicitud HTTP / 1.1 sin el Host: parte de la solicitud. Por lo que leí, Apache responde con un error de 400 (solicitud incorrecta) a esta solicitud, antes de entregar a mod_security. Entonces, no parece que sus reglas serán procesadas. (Apache trata con él antes de requerir entregar a mod_security)

Pruébate tu mismo:

nombre de host telnet 80
GET /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 apropiada debe verse como:

GET /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 controladores de solicitudes. La siguiente URL es una discusión acerca de 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 se pudo encontrar ninguna otra solución y se pregunta si realmente se necesita una solución.


34
2018-03-29 13:17



Ahora veo el problema. ¿Recomienda la solución provista en el artículo, o cree que es mejor dejarlo como está? Es un escáner para cualquier puerta trasera en el sistema. Si lo dejo solo escaneando, algún día podría ser atacado. - Saif Bechan
Hola Saif, creo que mientras mantengas tu instalación de Apache actualizada con los parches de seguridad de tus distribuciones (o manuales) estarás 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 es así mayo Ha habido algún tipo de exploración de vulnerabilidades centrada en los enrutadores DLink. (Según algunas otras fuentes) - Imo
¿Hay al menos una forma de sacar estos campos de mi apache error_log? - Saif Bechan
Tú tal vez capaz de hacerlo a través de mod_log :: httpd.apache.org/docs/2.2/mod/mod_log_config.html#customlog - Imo
Mi consejo adicional sería: configura tu defecto virtualhost junto a los realmente en uso. Los intentos mencionados arriba terminarán en los registros para el defecto anfitrión virtual. - Koos van den Hout


Filtrar direcciones IP no es una buena idea, imho. ¿Por qué no intentas filtrar la cadena que sabes?

Quiero decir:

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

15
2018-05-09 16:21



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 pruebas que sugieran que el filtrado de cadenas de iptables sea más lento que el filtrado a nivel de apache? - jrwren


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 configure filtros específicos para poner en una lista negra estas direcciones IP en sus 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 mensajes jail - regex y filter === 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 =

11
2017-08-19 17:46



Es cierto que puede bloquearlos, pero no es necesario porque son solicitudes incorrectas. Es mejor simplemente ignorarlos, guardar tu trabajo y liberarás 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
@SaifBechan, no estoy de acuerdo. w00tw00t es un escáner de vulnerabilidades, y no se puede confiar en que una máquina que emite este tipo de solicitudes intente realizar otro tipo de solicitudes, por lo que si soy un administrador del sistema y me demoran 2 minutos en prohibir a dichos clientes durante días a la vez, lo haria Sin embargo, no basaría toda mi implementación de seguridad en este enfoque. - Isaac


w00tw00t.at.blackhats.romanian.anti-sec es un intento de piratería y utiliza IP falsos, por lo que las búsquedas como VisualRoute informarán sobre China, Polonia, Dinamarca, etc., según la IP que se está secundando en ese momento. Por lo tanto, configurar una Denegación de IP o un Nombre de host resoluble es prácticamente imposible, ya que cambiará dentro de una hora.


3
2018-06-01 11:20



Estas exploraciones de vulnerabilidad no utilizan direcciones IP falsificadas. Si lo hicieran, el protocolo de enlace de tres vías TCP no se completaría y Apache no registraría la solicitud. Para advertencias (ISP fraudulento, operadores de enrutadores, etc.), consulte security.stackexchange.com/q/37481/53422 - Anthony Geoghegan


Personalmente escribí una secuencia de comandos de Python para agregar automáticamente 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)

2
2018-03-24 07:06



Es esto para evitar el ataque w00tw00t - Saif Bechan
Sí, tengo que escanear los registros de errores de Apache en busca de cualquier IP "w00tw00t" y agregarlas si no existen, aunque por simplicidad no agregué la comprobació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 el procesamiento un poco. - Eric
Utiliza una mesa. Sin embargo, lo simplifiqué mucho ya que se adaptó a mi sistema. - Xorlev
¿Crees que esta es una mejor solución que usar mod_security? - Saif Bechan


Creo que la razón por la que mod_security no está funcionando es porque Apache no ha podido analizar las solicitudes por sí mismas, están fuera de especificaciones. No estoy seguro de que tengas un problema aquí. Apache está registrando una mierda rara que está ocurriendo en la red, si no la inicia, no estarás al tanto de que está sucediendo. Los recursos necesarios para registrar las solicitudes son probablemente mínimos. Entiendo que es frustrante que alguien esté llenando tus registros, pero será más frustrante si deshabilitas el registro solo para encontrar que realmente lo necesitas. Al igual que alguien irrumpió en su servidor web y necesita los registros para mostrar cómo ingresaron.

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 relacionadas con w00tw00t. O, alternativamente, 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 en este sentido.

Así que en httpd.conf puedes hacer:

ErrorLog syslog:user 

entonces en rsyslog.conf usted podría tener:

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

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

Es recomendable que todos los registros se envíen a un servidor de registro remoto tan pronto como sea posible, y esto le beneficiará si alguna vez lo interrumpen, ya que es mucho más difícil borrar el registro 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 botnet distribuida? Deberá haber un X% de duplicados antes de obtener un beneficio de iptables.


2
2018-03-30 11:09



Buena respuesta, me gustan los diferentes enfoques. Pensando en ello, tener un registro personalizado creará un mayor uso de recursos, ya que todo tiene que comprobarse primero, supongo que esta opción también se desactiva. 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 voy a dejar la configuración como es por el momento. - Saif Bechan


Lo dices en la actualización 2:

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

Ahora puedes simplemente ignorarlo, que es lo más recomendado. El problema sigue siendo que si tiene este archivo en su servidor de alguna manera algún día, tiene algún problema.

De mi respuesta anterior, nos dimos cuenta de que Apache está devolviendo un mensaje de error debido a una consulta HTML 1.1 mal formada. Es probable que todos los servidores web que admiten HTTP / 1.1 devuelvan un error cuando reciban este mensaje (no he vuelto a verificar el RFC, tal vez el RFC2616 nos lo diga).

Tener el archivo w00tw00t.at.ISC.SANS.DFind: en su servidor no significa místicamente que significa "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 está diciendo "no, esa es una mala solicitud ... adiós". Los datos en el archivo w00tw00t.at.ISC.SANS.DFind: no se servirán.

El uso de mod_security para este caso no es obligatorio a menos que realmente quiera (¿no tiene sentido?) ... en cuyo caso, puede ver el parcheo manual (enlace en otra respuesta).

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


1
2018-03-31 08:52



No creo que Apache los rechace, simplemente arroja el error pero la búsqueda aún pasa. Tengo el mismo w00tw00t.at.ISC.SANS.DFind en el registro de acceso. Lo hace un GET. Por lo tanto, 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 frente a ellos. Apache lanza el error pero la solicitud pasa. Es por eso que pregunté si sería una buena idea bloquear estas solicitudes sin nombres de host. Pero no quiero bloquear a los usuarios normales. - Saif Bechan
Claro, obtienes la misma entrada en el registro de acceso pero miras el código de error ... 400. No se procesa. HTTP / 1.1 (nombre de host) se utiliza para indicar a apache a qué host virtual enviar la solicitud a ... sin la parte del nombre de host de la solicitud HTTP / 1.1 apache no sabe dónde enviar la solicitud y devuelve un error de "solicitud incorrecta 400" de vuelta al cliente. - Imo
Inténtelo usted mismo ... créese una página html en su servidor web e intente acceder manualmente usando "telnet hostname 80" ... los otros pasos están en mi primera respuesta. Le daría una gran recompensa que no puede obtener el archivo html para mostrar usando HTTP / 1.1 sin el nombre de host. - Imo
Ah, sí, sí, por señalarme eso. Siempre pensé que access_log eran entradas que se pasaban a través del registro de errores y realmente ingresaban a su máquina. Gracias por señalarme esto y editaré mi publicación. Realmente aprecio tu ayuda. - Saif Bechan
Hola Saif, no hay problemas, me alegro de haberte ayudado. Saludos, Imo - Imo