Ataque masivo 404 con URL inexistentes. ¿Cómo prevenir esto?

El problema es una gran cantidad de errores 404, según lo informado por Google Webmaster Tools, con páginas y consultas que nunca han estado allí. Uno de ellos es viewtopic.php, y también he notado un número aterrador de intentos para verificar si el sitio es un sitio de WordPress ( wp_admin) y para el inicio de sesión de cPanel. Ya bloqueo TRACE, y el servidor está equipado con algo de defensa contra escaneo / piratería. Sin embargo, esto no parece detenerse. La referencia es, según Google Webmaster, totally.me.

He buscado una solución para detener esto, porque ciertamente no es bueno para los usuarios reales y pobres, y mucho menos para las preocupaciones de SEO.

Estoy usando la mini lista negra de Perishable Press (que se encuentra aquí ), un bloqueador de referencias estándar (para sitios pornográficos, herbales, de casino) e incluso algún software para proteger el sitio (bloqueo XSS, inyección SQL, etc.). El servidor también está utilizando otras medidas, por lo que uno supondría que el sitio es seguro (con suerte), pero no está terminando.

¿Alguien más tiene el mismo problema, o soy el único que ve esto? ¿Es lo que pienso, es decir, algún tipo de ataque? ¿Hay alguna forma de solucionarlo o, mejor, evitar este desperdicio inútil de recursos?

EDITAR Nunca he usado la pregunta para agradecer las respuestas, y espero que esto se pueda hacer. Gracias a todos por sus perspicaces respuestas, que me ayudaron a encontrar la manera de salir de esto. He seguido las sugerencias de todos y he implementado lo siguiente:

• un honeypot
• un script que escucha las URL sospechosas en la página 404 y me envía un correo electrónico con el agente de usuario / ip, mientras devuelve un encabezado 404 estándar
• un script que recompensa a los usuarios legítimos, en la misma página personalizada 404, en caso de que terminen haciendo clic en una de esas URL. En menos de 24 horas pude aislar algunas IP sospechosas, todas listadas en Spamhaus. Todas las IP registradas hasta ahora pertenecen a empresas de alojamiento de VPS de spam.

Gracias a todos nuevamente, habría aceptado todas las respuestas si pudiera.

A menudo veo otro sitio que enlaza con toneladas de páginas en mi sitio que no existen. Incluso si hace clic en esa página y no ve el enlace:

• El sitio podría haber tenido previamente esos enlaces
• El sitio puede estar ocultando y sirviendo esos enlaces solo a Googlebot y no a visitantes

Es un desperdicio de recursos, pero no confundirá a Google y no dañará su clasificación. Esto es lo que John Mueller de Google (que trabaja en Herramientas para webmasters y Sitemaps) tiene que decir sobre los errores 404 que aparecen en las herramientas para webmasters :

¡AYUDA! ¡MI SITIO TIENE 939 ERRORES DE CANGREJO! 1

Veo este tipo de preguntas varias veces a la semana; no estás solo: muchos sitios web tienen errores de rastreo.

1. Los errores 404 en URL inválidas no dañan la indexación o clasificación de su sitio de ninguna manera. No importa si hay 100 o 10 millones, no dañarán el ranking de su sitio. http://googlewebmastercentral.blogspot.ch/2011/05/do-404s-hurt-my-site.html
2. En algunos casos, los errores de rastreo pueden provenir de un problema estructural legítimo dentro de su sitio web o CMS. Como lo dices Vuelva a verificar el origen del error de rastreo. Si hay un enlace roto en su sitio, en el HTML estático de su página, siempre vale la pena arreglarlo. (gracias + Martino Mosna )
3. ¿Qué pasa con las URL funky que están "claramente rotas"? Cuando a nuestros algoritmos les gusta su sitio, pueden intentar encontrar más contenido excelente en él, por ejemplo, tratando de descubrir nuevas URL en JavaScript. Si probamos esas "URL" y encontramos un 404, eso es genial y esperado. Simplemente no queremos perdernos nada importante (inserte un meme de Googlebot demasiado adjunto aquí). http://support.google.com/webmasters/bin/answer.py?answer=1154698
4. No es necesario corregir los errores de rastreo en las Herramientas para webmasters de Google. La función "marcar como fijo" es solo para ayudarlo, si desea realizar un seguimiento de su progreso allí; no cambia nada en nuestro canal de búsqueda web, así que siéntete libre de ignorarlo si no lo necesitas. http://support.google.com/webmasters/bin/answer.py?answer=2467403
5. Enumeramos los errores de rastreo en las Herramientas para webmasters de Google por prioridad, que se basa en varios factores. Si la primera página de errores de rastreo es claramente irrelevante, probablemente no encontrará errores importantes de rastreo en otras páginas. http://googlewebmastercentral.blogspot.ch/2012/03/crawl-errors-next-generation.html
6. No es necesario "arreglar" los errores de rastreo en su sitio web. Encontrar 404 es normal y se espera de un sitio web saludable y bien configurado. Si tiene una nueva URL equivalente, entonces es una buena práctica redirigirla. De lo contrario, no debe crear contenido falso, no debe redirigir a su página de inicio, no debe robots.txt rechazar esas URL; todas estas cosas nos dificultan reconocer la estructura de su sitio y procesarla correctamente. Llamamos a estos errores "soft 404". http://support.google.com/webmasters/bin/answer.py?answer=181708
7. Obviamente, si estos errores de rastreo se muestran para las URL que le interesan, tal vez las URL en su archivo de Sitemap, entonces es algo que debe tomar medidas de inmediato. Si Googlebot no puede rastrear sus URL importantes, es posible que se eliminen de nuestros resultados de búsqueda y que los usuarios tampoco puedan acceder a ellas.

Hay toneladas de secuencias de comandos que escanean de manera optimista direcciones IP aleatorias en Internet para encontrar vulnerabilidades conocidas en varios tipos de software. El 99,99% de las veces, no encuentran nada (como en su sitio), y ese 0,01% de las veces, el script activará la máquina y hará lo que el controlador de script desee. Típicamente, estos scripts son ejecutados por botnets anónimos desde máquinas que previamente han sido pwnd, no desde la máquina real del script kiddie original.

Que deberias hacer

1. Asegúrese de que su sitio no sea vulnerable. Esto requiere vigilancia constante.
2. Si esto genera tanta carga que el rendimiento normal del sitio se ve afectado, agregue una regla de bloqueo basada en IP para evitar aceptar conexiones del sitio en particular.
3. Aprenda a filtrar escaneos para CMD.EXE o cPanel o phpMyAdmin o toneladas de otras vulnerabilidades al mirar a través de los registros de su servidor.

Parece creer que cualquier 404 devuelto desde su servidor a alguien afectará lo que Google piensa sobre su sitio. Esto no es verdad. Solo los 404 devueltos por los rastreadores de Google, y quizás los usuarios de Chrome, afectarán su sitio. Mientras todos los enlaces en su sitio sean enlaces apropiados, y no invalide los enlaces que ha expuesto anteriormente al mundo, no verá ningún impacto. Los robots de script no hablan con Google de ninguna manera.

Si está siendo atacado de una manera real, deberá inscribirse en algún tipo de servicio de proveedor de mitigación de DoS. Verisign, Neustar, CloudFlare y Prolexic son proveedores que tienen varios tipos de planes para varios tipos de ataques, desde el simple proxy web (que incluso puede estar libre de algunos proveedores) hasta el filtrado basado en DNS a pedido, hasta BGP completo cambios de punto de presencia basados ​​que envían todo su tráfico a través de centros de datos de "depuración" con reglas que mitigan los ataques.

Pero, por lo que dices, parece que solo estás viendo los scripts de vulnerabilidad normales que cualquier IP en Internet verá si está escuchando en el puerto 80. Literalmente puedes instalar una nueva máquina, iniciar un Apache vacío, y dentro de unas horas, comenzará a ver esas líneas en el registro de acceso.

Esto probablemente no sea en realidad un ataque, sino un escaneo o una sonda.

Dependiendo del escáner / buscador, puede ser benigno, lo que significa que solo está buscando problemas en algún tipo de capacidad de investigación o podría tener una función para atacar automáticamente si encuentra una abertura.

Los navegadores web ponen información de referencia válida, pero otros programas pueden inventar cualquier referencia que deseen.

El referente es simplemente una información que los programas que acceden a su sitio web proporcionan de manera opcional. Puede ser cualquier cosa que elijan configurar como totally.meo random.yu. Incluso puede ser un sitio web real que acaban de seleccionar.

Realmente no puedes arreglar esto o prevenirlo. Si trató de bloquear cada solicitud de este tipo, terminará teniendo que mantener una lista muy grande y no vale la pena.

Mientras su host se mantenga al día con los parches y evite vulnerabilidades, esto no debería causarle ningún problema real.

De hecho, suena como frenesí bot. También hemos sido golpeados por miles de IP en muchos hosts, probablemente sin el conocimiento del sitio OP. Antes de ofrecer algunas soluciones útiles, una pregunta que tengo es:

P: ¿Cómo ve los 404 de su sitio en su conjunto en las herramientas para webmasters de Google? GWT es el resultado de los hallazgos de Googlebots, no el resultado de otros bots. Además, esos otros bots no ejecutan JS para análisis ... ¿tiene algo de API que va a GWT donde puede ver las estadísticas de su servidor? De lo contrario, puede ser motivo de alarma, ya que este es el robot de Google que encuentra errores.

• Si esto es SOLO errores de googlebot, esto podría indicar que alguien ha colocado enlaces a su sitio en foros y cosas para los objetivos de robots maliciosos de PC reales que lo golpean. Piense en harverstor + planter que se ejecuta en un servidor explotado, estableciendo una tonelada de objetivos para futuros "contratos de spam" a través del portal.

• Si realmente sabe que está informando las estadísticas completas de su servidor, entonces necesita algunas herramientas. Algunas aplicaciones y servicios pueden ayudarlo a recortarlo. Suponiendo que está ejecutando un servidor Linux:

1) Comience a agregar IP ofensivas a una lista negra de htaccess. Parece "negar desde 192.168.1.1" y 403 los prohibirá. No te dejes llevar, simplemente bloquea los biggens. Compárelos con los sitios en el paso 4) para asegurarse de que no sean ISP de personas reales. Puede copiar este archivo y pegarlo en cualquier cuenta / aplicación más allá del firewall incluso.

2) Instalar APF. Es muy fácil administrar el firewall a través de SSH en Linux. A medida que construye el ht, agréguelos en APF como "apf -d 192.168.1.1". Parece redundante debido a APF, pero es portátil.

3) Instale cPanel Hulk y asegúrese de incluir su IP en la lista blanca para que nunca lo bloquee si olvida un pase. Esta también será una buena fuente de IP para agregar a ht + apf. Tiene algo de inteligencia para que pueda mitigar de manera inteligente los intentos de inicio de sesión de fuerza bruta.

4) Conéctese con stopforumspam.com y projecthoneypot.org y ejecute sus módulos. Ambos ayudan mucho a negar solicitudes conocidas e identificar + informar nuevos brutos / redes / chinaspam. También puedes usar filtros de correo electrónico, pero gmail lo posee en lo que respecta al filtro de correo no deseado.

5) Dado que los bots nunca se detienen, proteja sus rutas de administrador. Si ejecuta wordpress, cambie la ruta del administrador, agregue captcha, etc. Si usa SSH, cambie el puerto de inicio de sesión a algo no utilizado, luego desactive el inicio de sesión raíz SSH. Cree un "radmin" en el que primero debe iniciar sesión, luego su para root.

• Una nota sobre captcha, si ejecuta su propio captcha en un sitio de gran volumen y no niega el frenesí de los bots a nivel de firewall / ht, pueden estar afectando sus ciclos de CPU debido a la generación de imágenes en todos esos widgets "antispam".

• Una nota sobre la carga, si ejecuta CentOS en su servidor y tiene capacidades de VPS, CloudLinux es fantástico para el control de carga y endurecimiento. Digamos que un bot pasa, CageFS está ahí para limitarlo a una cuenta. Digamos que deciden DDoS ... LVE está ahí para mantener la carga de la cuenta (sitio) limitada para no bloquear su servidor. Es un buen complemento para acentuar todo el sistema de "gestión de entidades involuntarias" :)

Solo algunos pensamientos, espero que te ayuden

Explicación del problema.

En primer lugar, usted no es el único que tiene este problema, todos lo son. Lo que ha visto es el resultado de robots automatizados que rastrean cada IP y buscan vulnerabilidades comunes. Básicamente, intentan encontrar qué cosas estás usando y, si usas phpmyadmin, intentarán luego con un montón de combinaciones de contraseña de nombre de usuario estándar.

Me sorprende que haya encontrado este tipo de cosas en este momento (es posible que haya comenzado su servidor). El problema es que no puede bloquear su dirección IP para siempre (lo más probable es que se trate de una computadora infectada y su usuario real no se dé cuenta de lo que está haciendo, también hay muchas IP de este tipo).

Efecto SEO

No tiene ningún efecto en absoluto. Simplemente significa que alguien intentó acceder a algo en su computadora y no estaba allí

¿Realmente importa?

Claro, estas personas intentan sondearlo por algunos problemas. Además, están desperdiciando sus recursos (su servidor necesita reaccionar de alguna manera) y contaminando su archivo de registro

¿Cómo debo arreglarlo?

Tuve el mismo problema que intenté solucionar y la mejor herramienta (simplicidad de uso frente a lo que puedo hacer con él) que pude encontrar es fail2ban

También es lo suficientemente afortunado porque ya encontré una forma de solucionar el mismo problema e incluso lo documenté aquí (por lo que no necesita encontrar cómo instalarlo y cómo hacerlo funcionar). Verifique mi pregunta en ServerFault . Pero por favor lea un poco sobre fail2ban para saber cómo está funcionando.

Como muchos ya han dicho, este no es un ataque sino un intento de probar o escanear la aplicación de su sitio y / o las capacidades de su servidor. La mejor manera de filtrar todo este tráfico inútil y escaneos potencialmente peligrosos es implementar un WAF (Firewall de aplicaciones web). Esto detectará todos los diferentes intentos y los marcará y solo entonces enviará tráfico limpio legítimo real a sus servidores y aplicación web.

Puede usar DNS WAF basado en la nube o dispositivos dedicados. Personalmente uso Incapsula y F5 ASM para diferentes sitios de clientes. Los costos son tan bajos como $ 500 al mes y ayuda enormemente. También brinda una mejor protección a sus clientes y reduce los recursos en los propios servidores web, lo que le ahorrará dinero y aumentará la velocidad, además de que estos dispositivos ofrecen conformidad con PCI 6.6 y revisiones con informes.

Espero que esto ayude.