apache-2.2 – Lidiando con ataques HTTP w00tw00t

Pregunta:

Tengo un servidor con apache y recientemente instalé mod_security2 porque me atacan mucho por 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:)

Estos son 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 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 pasa en mod_security2 es que SecFilterSelective no se puede usar, me da errores. En su lugar, 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 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 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 tener que escupir a través de un registro largo.

  2. Creo que la segunda opción es mejor, y es bloquear los 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 revisar 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á ver el registro completo sin que falte nada.

  2. Es mejor simplemente ignorar los resultados y concentrarse en una mejor manera de analizar sus registros de errores. Usar 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 tanto los registros de errores como los registros de acceso se vuelven extremadamente grandes.

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

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

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

Respuesta:

Desde su registro de errores, están enviando una solicitud HTTP / 1.1 sin la parte Host: de la solicitud. Por lo que leí, Apache responde con un error 400 (solicitud incorrecta) a esta solicitud, antes de pasarla a mod_security. Por lo tanto, no parece que se procesen sus reglas. (Apache se ocupa de ello antes de que sea necesario entregarlo a mod_security)

Pruébelo usted mismo:

telnet hostname 80
GET /blahblahblah.html HTTP/1.1  (enter)
(enter)

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

La solicitud adecuada debería verse así:

GET /blahblahblah.html HTTP/1.1
Host: blah.com

Una solución para este problema podría ser parchear mod_uniqueid, para generar un ID único incluso para una solicitud fallida, para que apache pase la solicitud a sus controladores 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 requiere una solución.

Leave a Comment

Your email address will not be published.

Scroll to Top

istanbul avukat

-

web tasarım