OVH Community, your new community space.

Rastros /w00tw00t.at.ISC.SANS.DFind:) en los logs de Apache HTTP


suicidal
17/10/2012, 07:08
En el dominio principal ya no aparece, pero en un dominio que contraté hace poco, sigue apareciendo mi querido amigo w00t... xD

suicidal
24/09/2012, 08:26
Cita Publicado inicialmente por Diablo48
El fail2ban es un sistema que lee logs, y en base a las reglas que tienes activas va baneando cuando alguna ip, excede el numero de intentos fallidos, etc para cada una de las reglas, por ejemplo intentos de log in fallidos por ssh, ftp, pop, imap, http, etc

Un saludo
Gracias Diablo48.

Respecto a w00tw00t en los logs, ha desaparecido totalmente, asi que está haciendo su función IPTABLES

Diablo48
21/09/2012, 16:51
El fail2ban es un sistema que lee logs, y en base a las reglas que tienes activas va baneando cuando alguna ip, excede el numero de intentos fallidos, etc para cada una de las reglas, por ejemplo intentos de log in fallidos por ssh, ftp, pop, imap, http, etc

Un saludo

suicidal
21/09/2012, 10:35
hago un /bump del tema

mirando en los registros he encontrado el famoso w00tw00t. he aplicado:

iptables -I INPUT -d mi_ip_del_servidor -p tcp --dport 80 -m string --to 50 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.' -j DROP

y estoy a la espera de ver si hace resultado o no.

pregunta, que hace exactamente fail2ban?

lonas
13/07/2010, 00:11
pues me acabo de dar cuenta de que en mis logs me aparecen tambien, voy a probar con:

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

y ya os cuento

Giner OVH
04/02/2010, 15:05
Pero es que lo de esta cadena en los logs es muy sangrante...
ideas?

rockeye
04/02/2010, 14:49
Hola Giner y otros tipos de scan http no necesariamente con la firma w00tw00t? Y los ftp y ssh?

Saludos.

Giner OVH
04/02/2010, 12:59
Todo aquel que esté recibiendo ataques w00tw00t desde IP's de OVH nos lo puede notificar para que saquemos el hacha.

Podéis por favor reportarlo a soporte@ovh.es
y poner como asunto: [w00tw00t]
adjuntando el log.

Gracias.

Roberman
28/01/2010, 09:25
Cita Publicado inicialmente por barbaro
Eso es totalmente falso,comprate un coche y pasa las revisiones,asi no te lo robaran.

Saludos
No del todo. Hay actualizaciones que son correctivos de fallos de seguridad.

Sería algo así como "comprate un coche y pasa las revisiones de la alarma, el cerrojo antirrobo, así será más difícil que te roben".

djbill
28/01/2010, 08:47
Pues yo ya estoy empezando a bloquear ataques, de momento he recibido los siguientes, y desde direcciones de OVH:

2010-01-27 14:43:14,894 fail2ban.actions: WARNING [apache-w00tw00t] Ban 217.195.204.194
2010-01-27 16:50:52,149 fail2ban.actions: WARNING [apache-w00tw00t] Ban 94.23.57.73
2010-01-27 20:28:38,287 fail2ban.actions: WARNING [apache-w00tw00t] Ban 91.121.82.140
2010-01-27 20:29:09,335 fail2ban.actions: WARNING [apache-w00tw00t] Ban 188.165.192.59
2010-01-28 01:24:45,455 fail2ban.actions: WARNING [apache-w00tw00t] Ban 94.23.237.133
2010-01-28 05:44:23,626 fail2ban.actions: WARNING [apache-w00tw00t] Ban 91.121.178.10
Saludos.

chencho
27/01/2010, 07:25
Otro sufridor de escaneos con una maquina que prácticamente no hace nada, manda webs.

Gracias por los filtros.

rockeye
26/01/2010, 14:28
Cita Publicado inicialmente por dcampoy
Otra forma de bloquear DFind sería desde htaccess, con:

RewriteCond %{REQUEST_URI} ^(/w00tw00t) [NC]
RewriteRule ^(.*)$ /malware/403.php

¿Sería correcto?
Pero para aplicarlo junto con mod_evasive. Esto así solo seguiran consumiento recursos de apache.

Saludos.

djbill
26/01/2010, 13:51
Cita Publicado inicialmente por Nebur
Darle un vistazo a esto, quizás pueda servidor de utilidad:

http://howflow.com/tricks/block_w00t..._with_fail2ban
Muchas gracias, me ha dado por mirar el log y tenia restos de scaneo cada 5 minutos.

Un saludo.

dcampoy
26/01/2010, 10:36
Otra forma de bloquear DFind sería desde htaccess, con:

RewriteCond %{REQUEST_URI} ^(/w00tw00t) [NC]
RewriteRule ^(.*)$ /malware/403.php

¿Sería correcto?

Power
25/09/2009, 15:17
Hola,
Cita Publicado inicialmente por pedrito
Se pueden añadir reglas de iptables en unos ficheros de configuración del CSF para que cuando inicie los ejecute. Su creador lo explica en su foro:

Código:
 Default
You can add custom rules to be defined before or after csf configures iptables by creating the files /etc/csf/csfpre.sh and /etc/csf/csfpost.sh and adding the iptables commands into one or the other.
Reply With Quote
¡¡¡ Perfecto !!!
Gracias pedrito

Saludos

pedrito
24/09/2009, 22:15
Cita Publicado inicialmente por Power
Hola,

Hace unos días lancé:
iptables -I INPUT -p tcp --dport 80 -m string --to 50 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.' -j DROP

Y en /etc/httpd/logs/access_log dejé de tener mensajes del tipo:
x.x.x.x - - [15/Sep/2009:19:52:17 +0200] "GET /w00tw00t.at.ISC.SANS.DFind HTTP/1.1" 400 226

Pero hoy, sin haber reiniciado el servidor, vuelven a aparecerme.
Lo único relacionado con cortafuegos que he hecho ha sido reiniciar el CSF.
¿Es posible que esa haya sido la causa?
Si es así ¿cómo podría evitar que el reinicio de CSF afecte a ese comando?

(Perdonad. Ya sé que son cosas triviales de Linux, pero aún me falta mucho recorrido).

Saludos
Se pueden añadir reglas de iptables en unos ficheros de configuración del CSF para que cuando inicie los ejecute. Su creador lo explica en su foro:

Código:
 Default
You can add custom rules to be defined before or after csf configures iptables by creating the files /etc/csf/csfpre.sh and /etc/csf/csfpost.sh and adding the iptables commands into one or the other.
Reply With Quote

Power
24/09/2009, 08:22
Hola,
Cita Publicado inicialmente por Ferny
Al menos yo vi que cuando reiniciabas el servidor las reglas que había metidas en iptables se perdían... imagino que pasará lo mismo si reinicias sólo el servicio (pero no estoy seguro)

Lo que hice para evitar que se pierdan las reglas es salvarlas antes de reiniciar:

/sbin/iptables-save > /var/lib/iptables/rules-save

Y luego restaurarlas:

/sbin/iptables-restore < /var/lib/iptables/rules-save

(Estas líneas las dejé puestas en los archivos local.start y local.stop para automatizarlo, no creas que las meto a mano XD)

Espero que te sirva :-)
Gracias Ferny
Saludos

Ferny
23/09/2009, 20:36
Al menos yo vi que cuando reiniciabas el servidor las reglas que había metidas en iptables se perdían... imagino que pasará lo mismo si reinicias sólo el servicio (pero no estoy seguro)

Lo que hice para evitar que se pierdan las reglas es salvarlas antes de reiniciar:

/sbin/iptables-save > /var/lib/iptables/rules-save

Y luego restaurarlas:

/sbin/iptables-restore < /var/lib/iptables/rules-save

(Estas líneas las dejé puestas en los archivos local.start y local.stop para automatizarlo, no creas que las meto a mano XD)

Espero que te sirva :-)

Power
23/09/2009, 19:03
Hola,

Hace unos días lancé:
iptables -I INPUT -p tcp --dport 80 -m string --to 50 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.' -j DROP

Y en /etc/httpd/logs/access_log dejé de tener mensajes del tipo:
x.x.x.x - - [15/Sep/2009:19:52:17 +0200] "GET /w00tw00t.at.ISC.SANS.DFind HTTP/1.1" 400 226

Pero hoy, sin haber reiniciado el servidor, vuelven a aparecerme.
Lo único relacionado con cortafuegos que he hecho ha sido reiniciar el CSF.
¿Es posible que esa haya sido la causa?
Si es así ¿cómo podría evitar que el reinicio de CSF afecte a ese comando?

(Perdonad. Ya sé que son cosas triviales de Linux, pero aún me falta mucho recorrido).

Saludos

carlose
18/09/2009, 12:28
Cita Publicado inicialmente por luis_sanz
hola carlos

es normal que entre diferentes distribuciones cambie un poco la cosa, y mas cuando usas una distro del 2006, ciertamente yo lo estoy usando en ubuntu y debian identicamente, en centos5 tambien es igual pero creo que eso mejor pueden decirlo los 'CPANELSSS' jejejej

si te lias te recomiendo que uses fail2ban, muy sencillo de usar, con una regla muy sencillita puedes bloquear igualmente esto, aunq claro iptables es el primer filtro.
También es una opción probar fail2ban. Veré qué hago...

Cita Publicado inicialmente por rockeye
Hace tiempo esas extensiones se habilitaban parcheando iptables y compilando. Puede que en las últimas versiones vengan algunas ya integradas o como modulos.

Va a ser lo que dice luis.
Según la página de iptables es eso, que falta parchearlo con esto (todavía no lo hecho ni se si lo voy a hacer):
http://www.netfilter.org/documentati...O-2.html#ss2.1

Gracias a los 2 por contestar

rockeye
18/09/2009, 12:10
Hace tiempo esas extensiones se habilitaban parcheando iptables y compilando. Puede que en las últimas versiones vengan algunas ya integradas o como modulos.

Va a ser lo que dice luis.

luis_sanz
18/09/2009, 11:50
Cita Publicado inicialmente por carlose
Lo estoy probando y en Debian sin problemas, pero en la Release 2 parece ser que falta un módulo o algo que hace que funcione lo de "-m string":
Código:
iptables v1.3.4: Couldn't load match 'string':/lib/iptables/libipt_string.so: cannot open shared object file: No such file or directory
Alguien lo ha conseguido usar en la Release 2? Yo de momento no encuentro nada en Google...
hola carlos

es normal que entre diferentes distribuciones cambie un poco la cosa, y mas cuando usas una distro del 2006, ciertamente yo lo estoy usando en ubuntu y debian identicamente, en centos5 tambien es igual pero creo que eso mejor pueden decirlo los 'CPANELSSS' jejejej

si te lias te recomiendo que uses fail2ban, muy sencillo de usar, con una regla muy sencillita puedes bloquear igualmente esto, aunq claro iptables es el primer filtro.

carlose
18/09/2009, 09:18
Cita Publicado inicialmente por luis_sanz
se que llego tarde!!
iptables -I INPUT -p tcp --dport 80 -m string --to 60 --algo bm --string 'GET /w00tw00t' -j DROP
Lo estoy probando y en Debian sin problemas, pero en la Release 2 parece ser que falta un módulo o algo que hace que funcione lo de "-m string":
Código:
iptables v1.3.4: Couldn't load match 'string':/lib/iptables/libipt_string.so: cannot open shared object file: No such file or directory
Alguien lo ha conseguido usar en la Release 2? Yo de momento no encuentro nada en Google...

kennysamuerto
18/09/2009, 00:59
Cita Publicado inicialmente por luis_sanz
se que llego tarde!!

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

por lo que se deduce que la ip se puede eliminar y que el --to no parece ser algo importante, seguramente sera lo que comentais para la busqueda del string
Personalmente esta me parece la mejor solucion. Directamente cortas de raiz.

luis_sanz
18/09/2009, 00:45
se que llego tarde!!

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

por lo que se deduce que la ip se puede eliminar y que el --to no parece ser algo importante, seguramente sera lo que comentais para la busqueda del string

Power
17/09/2009, 21:30
Hola,

Ya he ejecutado ese comando de iptables.
¡¡¡ Y he dejado de tener en /etc/httpd/logs/access_log los mensajes de intentos de acceso al documento /w00tw00t.at.ISC.SANS.DFind !!!

Gracias MAESTRO rockeye.

Ahora ya sólo me queda estudiar cómo poner el comando para que se ejecute cuando se reinicie la máquina.

Muchas gracias, de nuevo, rockeye.

Saludos

rockeye
17/09/2009, 20:07
jeje ... si es que en el manual de iptables no viene porque es una extensión de iptables. Ese tipo de cosas se activan parcheando, etc. Y la docu la tienes en el web de netfilter. Verás que hay varias extensiones interesantes que salen de lo típico de filtrar IP's, puertos, etc.

http://netfilter.org/documentation/H...ons-HOWTO.html

Pues si, si la quitas hará match con cualquiera, pero igual te interesa poner una regla por cada IP. Así luego cuando hagas un "iptables -L -v", puedes ver las estadísticas por cada una de las IP's.

Saludos.

Power
17/09/2009, 17:50
Hola,
Cita Publicado inicialmente por rockeye
Código:
iptables -m string --help
.
.
.
string match options:
--from                       Offset to start searching from
--to                         Offset to stop searching
--algo                       Algorithm
--icase                      Ignore case (default: 0)
[!] --string string          Match a string in a packet
[!] --hex-string string      Match a hex string in a packet
Las opciones to y from, tienen pinta de ser los limites donde tiene que buscar la cadena dentro del paquete.
Ahora sí lo tengo claro.
(Había intentado entenderlo en www.linuxmanpages.com/man8/iptables.8.php y no había manera.)

Da gusto aprender con buenos profesores.
Muchas gracias rockeye.

Sólo me queda saber si quitando -d dirección_ip_del servidor serviría para cualquier IP del servidor (principal o failover)

Saludos

rockeye
17/09/2009, 15:32
Código:
iptables -m string --help
.
.
.
string match options:
--from                       Offset to start searching from
--to                         Offset to stop searching
--algo                       Algorithm
--icase                      Ignore case (default: 0)
[!] --string string          Match a string in a packet
[!] --hex-string string      Match a hex string in a packet
Las opciones to y from, tienen pinta de ser los limites donde tiene que buscar la cadena dentro del paquete.

Saludos.

crises
17/09/2009, 12:57
No soy ningún entendido del tema pero creo que:
Cita Publicado inicialmente por Power
¿Qué hace el --to 50?
El --to sirve para redireccionar todo lo que filtra a 50, lo que no tengo claro es si es al puerto 50 o a la "ip" 50. En cualquier caso se trataría de... mandarlos a tierra de nadie supongo.
Cita Publicado inicialmente por Power
¿Qué hace el --algo bm?
--algo servía si no recuerdo mal para indicar el tipo de algoritmo que se debe usar para detectar la cadena w00tw00t

Power
17/09/2009, 09:15
Hola,

Soy un pardillo total en el tema de iptables
(Hasta ahora sólo he utilizado el interfaz web del cortafuegos CSF+LFD)

Tengo algunas dudas que no he conseguido aclarar con los tutoriales sobre iptables que he consultado:
Código:
iptables -I INPUT -d dirección_ip_del servidor -p tcp --dport 80 -m string --to 50 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.' -j DROP
¿Qué hace el --to 50?
¿Qué hace el --algo bm?
Si quiero que sirva para accesos por cualquier IP (principal o failovers) ¿bastaría con quitar -d dirección_ip_del servidor?

Perdonad mi ignorancia.
Gracias anticipadas.

Saludos

barbaro
24/07/2009, 11:28
Cita Publicado inicialmente por dave
¿Por qué molestarse en añadir reglas de filtrado?

Si mantienes el software al día no va a pasar nada.

Otra cosa es el servicio SSH, si se puede hacer login desde cualquier IP y no se ha desctivado el login por contraseña, pues igual si es recomendable.

Eso es totalmente falso,comprate un coche y pasa las revisiones,asi no te lo robaran.

Saludos

dave
24/07/2009, 11:11
¿Por qué molestarse en añadir reglas de filtrado?

Si mantienes el software al día no va a pasar nada.

Otra cosa es el servicio SSH, si se puede hacer login desde cualquier IP y no se ha desctivado el login por contraseña, pues igual si es recomendable.

crises
22/07/2009, 19:42
Uhm pues tienes razón, me parece que me hice la picha un lio con lo de que no podía usar la opción --algo la última vez que lo probé, porque ahora sí que me deja crear esa regla... y no he actualizado nada desde entonces. En fín gracias, estaré pendiente de los logs a ver si desaparecen de una vez esos scans ^^

barbaro
22/07/2009, 18:48
Tambien puedes hacerlo con :

iptables -I INPUT -d TON_IP_ICI -p tcp --dport 80 -m string --to 50 --algo bm --string 'GET /w00tw00t.at.ISC.SANS.' -j DROP

Tambien gracias a power utilizo el csf y lo he tenido puesto con fail2ban pero con unas buenas reglas en iptables y deflate me ha dado buen resultado.

Los datos que llegan por Apache, que escucha en el puerto 80 se trasladarán a mod_security y no al revés. De la forma anterior rechaza la solicitud de apache sin el paso a mod_security.

saludos

crises
22/07/2009, 18:41
Cita Publicado inicialmente por barbaro
iptables -I INPUT -d ip de vuestro servidor -p tcp --dport 80 -m string --to 70 \
--algo bm --string 'GET /w00tw00t.at.ISC.SANS.' -j DROP
Lo malo de eso es la opción --algo, que en mi versión de iptables por lo menos no puedo usar. Yo de momento no tengo nada que bloquee los scans estos y ando bloqueando las IPs "a mano" mirando logs y con ayuda del CSF+LFD que tanto le gusta a Power =D

De momento no es que no me preocupe... pero tampoco me ocupa xD Sólo son scans. Creo que hay una manera de bloquearles con el apache mod_security pero no me hagas mucho caso, e incluso con un .htaccess para cada dominio. Otra opción es la que comentan del fail2ban, pero como yo ya tenía el CSF pasé de historias.

Mira mi lista de IPs que me han scaneado, y solo llevo como un mesecito haciéndolo. Hay varias de OVH sí xD

Código:
#w00tw00t
212.78.225.56
79.165.93.226
88.80.216.101
94.23.206.155
87.229.108.30
94.23.211.174
92.51.142.23
208.53.151.10
85.114.141.209
94.102.3.54
195.153.113.140
91.121.25.110
85.14.217.16
216.245.214.93
85.114.135.67
84.164.209.22
88.255.202.82
87.106.208.74
91.121.65.73
74.208.96.223
74.52.89.114
89.163.145.16
85.114.136.194
62.141.54.105
94.23.8.165
87.118.124.57
212.227.97.187
80.146.190.22
62.75.144.64
64.186.129.179
88.255.202.165
78.111.75.142
80.68.240.114
213.180.78.233
94.23.9.143
217.65.100.89
68.178.205.217
88.255.202.246
85.214.63.44
88.80.214.156
89.171.233.10
64.68.48.194
74.208.9.186
64.68.48.194
91.121.174.132
69.44.225.6
93.187.200.66
84.40.5.129
82.98.145.137
74.208.132.247
77.245.145.18
88.80.216.124
87.106.80.167
85.214.153.253
91.121.77.210
213.115.160.62
95.211.64.203
209.47.33.187
75.127.66.117
85.214.153.253
82.152.231.210
62.193.225.236
89.19.2.58
173.1.83.254
81.169.131.42
88.149.202.146
85.214.82.40
213.232.95.7
#end w00tw00t

barbaro
22/07/2009, 16:41
Buscando por hay encontre una regla que quizas sirva,la voy a probar ahora y ya os dire o si quereis hacerlo vosotros y comentais tendremos mas opiniones,aqui os la dejo.

iptables -I INPUT -d ip de vuestro servidor -p tcp --dport 80 -m string --to 70 \
--algo bm --string 'GET /w00tw00t.at.ISC.SANS.' -j DROP

dodger
22/07/2009, 15:54
En mi blog trato el tema:
http://www.ciberterminal.net/blog/?p=62
No únicamente trato el w00t, sino otras cosas que suelen ser relevantes

Nebur
03/04/2009, 13:27
Darle un vistazo a esto, quizás pueda servidor de utilidad:

http://howflow.com/tricks/block_w00t..._with_fail2ban

mikelsanz
18/02/2009, 08:49
Buenos días. En efecto, es un servidor intendo atacar o buscar vulnerabilidades. A mi me afectó a los 10 minutos de instalar el servidor, por lo que es probable que, de momento, solo estén rastreando aleatoriamente.

Sería ideal si los administradores tomaran medidas para que no pudieran ni rastrearnos. Un saludo.

Riemann
18/02/2009, 08:37
Los logs error_log y access_log están llenos de peticiones como la siguiente:

[client 82.196.209.37] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind

Las IPs que han realizado estas peticiones hasta el momento son:

Código:
62.141.37.21
64.135.20.150
65.111.169.204
81.169.143.200
82.196.209.37
85.42.37.227
85.88.25.175
87.106.105.93
94.23.13.104
94.23.19.121
94.23.32.139
94.23.120.99
118.168.138.240
125.208.21.21
212.40.101.18
217.160.253.81

y ya están todas bloqueadas por iptables. Lo que no se, es si esto es un intento de ataque o que están escaneando en busca de alguna vulnerabilidad. He buscado esta cadena en la web y algunos dicen que es un scan que busca fallos en el servidor web... pero no parece concluyente.

¿A alguien más le llegan estas peticiones?

Además, al menos cuatro de las IPs que he listado son de OVH (94.23.*.*). Probablemente pertenecen a servidores crackeados. ¿Alguien sabe si existe alguna manera de avisar a los administradores de estas máquinas?

Un saludo a todos