¿Es posible servir páginas específicas basadas en la dirección IP?

8

He sido blanco de un ataque de fuerza bruta en dos sitios de WordPress que tengo. El atacante está usando el viejo y bueno XML-RPC para amplificar el ataque de contraseña de fuerza bruta. Afortunadamente, tenemos contraseñas extremadamente bien generadas, por lo que dudo mucho que llegue a alguna parte.

Acabo de usar iptables para bloquear sus solicitudes cada vez que aparece de nuevo (siempre del mismo proveedor de nube virtual), pero preferiría modificar el servidor para que cada vez que su dirección IP solicite cualquier página, reciba una respuesta diciéndole para conseguir una vida La mayoría de las solicitudes son POST, por lo que idealmente me gustaría modificar el encabezado de respuesta para incluir algo como "¡Mejor suerte la próxima vez!" o algo igualmente satisfactorio.

es posible? Estoy lejos de ser un experto en Apache, así que no estoy seguro de lo difícil que sería implementar esto. Pero incluso si me lleva horas, la satisfacción no tendrá precio.

Como referencia, estoy ejecutando Ubuntu 16.04.2 LTS, con Apache 2.4.18 alojando Wordpress 4.7.3.

apache-2.4 http-headers

— Aurelio
fuente

"siempre del mismo proveedor de nube virtual" OVH? He notado que muchos script kiddies usan sus servicios por alguna razón.

— hd.

No, online.net ... hasta ahora no han respondido a ninguno de mis informes de abuso. Además, la primera vez que envié una solicitud de abuso, descubrí que reenvían automáticamente la queja al cliente. De ahí cómo encontró mi sitio web personal. Buen trabajo, online.net ....

— Aurelius

25

Simplemente instale fail2ban con la cárcel apropiada y termine con ella. No se moleste en dar una respuesta personalizada, ya que es muy probable que nunca se vea.

— EEAA
fuente

1

Sin lugar a duda. Pero esto es definitivamente algo que siempre he querido hacer. Incluso si él nunca lo ve, solo la posibilidad me hace reír tanto que casi lloro.

— Aurelius

14

Bueno: 1) En mi humilde opinión, descubrir cómo mostrar un pequeño insulto a un guión infantil está fuera de tema aquí. 2) Hacerlo aún consumirá sus recursos de apache, mientras que fail2ban / iptables bloquea las solicitudes en sentido ascendente para que su aplicación nunca tenga que lidiar con eso.

— EEAA

1

Oh seguro Pero quiero divertirme un poco antes de la prohibición permanente. Ya sea mezquino o no, solo quiero reír, y esto es a pedido de la persona que utiliza el servidor.

— Aurelius

44

@Aurelius, si conoces la ip, y esta persona no lo enmascara, ¿por qué no haces esto en la propia aplicación? En este caso, php. Solo verifique si es ip xx.xx.xx.xx y si es solo elimine el script con una respuesta,die("blah blah");

— Miguel

Aceptada como respuesta, principalmente porque no sabía sobre fail2ban y eso es realmente útil en general. ¡La respuesta de Miguel anterior, así como la respuesta de BlackWebWolf a continuación, son dos cosas que voy a analizar!

— Aurelius

5

Existe la posibilidad, y lo hicimos bastante, de revertir posibles ataques. Use iptables para redirigir el proveedor de la nube (rango de direcciones) a un puerto diferente, y allí le sirve al atacante una respuesta, incluso en encabezados simples.

En Apache puede modificar encabezados por ejemplo:

Header set GetOut "Better luck next time!"

— BlackWebWolf
fuente

Jejeje !! Ahora de eso estoy hablando. ¡Buena idea! Voy a mirar en esto.

— Aurelius

55

esta estrategia probablemente será contraproducente con la respuesta, ya que le permite al atacante saber qué está funcionando y qué no, es mucho mejor simplemente pasar silenciosamente la solicitud a nada y no disparar ningún indicador de alerta en su software de ataque de bot. Lo ideal sería devolver el html de la página solicitada, por ejemplo. nunca saben que los atrapó, no pasa nada y su sitio es más seguro. Resista el impulso de hacerles saber, eso es un ERROR, siempre. Simplemente les ayuda a depurar el problema. En su caso, simplemente cambie a rangos de IP más dinámicos, etc., haciendo que el problema sea MUCHO más difícil de resolver.

— Lizardx

1

Tienes razón, no se recomienda, incluso es posiblemente peligroso. La estrategia con honeypot siempre es mejor, pero la pregunta era clara: cómo

— trollear

Realmente no me importa si es un error: he instalado fail2ban, y de todos modos será expulsado. Dudo mucho que vaya a llegar a alguna parte; Por lo que sé, ¿las versiones recientes de WordPress realmente corrigieron este error de seguridad? Sin mencionar, las contraseñas de fuerza bruta que tienen más de 20 caracteres ... sí, eso no ocurre en la vida de nuestro universo.

— Aurelius

blackwebwolf, es similar a alguien que pregunta cómo implementar la extensión mysql_ obsoleta de php, mientras que técnicamente uno puede responder esa pregunta, esa respuesta es incorrecta porque la respuesta real significa hacerlo bien, en ese caso, por ejemplo, usando mysqli_ o xpdo. Es solo la noción, que muchos de nosotros también hemos hecho en nuestro pasado, que responder de alguna manera, como trolling, debe ser corregido, ya que es un grave error, y si alguna vez ha sufrido por ese error, uno entendería de inmediato por qué la pregunta estaba equivocada.

— Lizardx

3

Esto es muy fácil con ModSecurity, que es un módulo WAF de terceros para Apache. Aunque implica aprender su sintaxis de lenguaje de reglas.

También puede usar ModSecurity para simplemente desconectar la conexión en lugar de responder.

Dicho esto, la instalación de ModSecurity solo por esto, cuando, como otros han sugerido, es probable que las respuestas sean ignoradas, puede ser exagerado.

— Barry Pollard
fuente

2

Iría con fail2ban y soltaría solicitudes de ubicaciones de abuso conocidas. Y si cree que el proveedor de servicios del atacante no tiene la culpa, informe los ataques a su dirección de correo electrónico de abuso.

Si desea pasar tiempo haciendo algo que disminuya la velocidad del atacante, puede intentar hacer una tarpit . Primero, por supuesto, debes saber de dónde vienen los ataques. Luego, podría usar apache para redirigir la solicitud de la ip (rango?) A un script específico. Esto podría hacer el truco, aunque no lo he intentado yo mismo. Luego, simplemente implemente un script que, por ejemplo, imprima un punto (o algo de / dev / null) cada 15 segundos para mantener la conexión del atacante abierta indefinidamente.

Dado que es muy probable que el atacante use scripts para atacar su sitio, puede tomar tiempo darse cuenta de que los ataques se han estancado, ya que las conexiones están aparentemente activas, no habrá tiempo de espera y la solicitud no se denegará en el acto.

El problema es que le dedica tiempo y recursos a algo que probablemente no será tan útil como la preocupación más importante: asegurar su inicio de sesión. Es difícil atacar cuando no sabes dónde atacar. Considere algunos de los siguientes:

restringir el acceso a la página de inicio de sesión (solo su intranet? rango de ip? vpn? otro?).
agregue reCaptcha u otra pregunta de verificación para iniciar sesión.
utilizar autenticación multifactor .
esconde tu página de inicio de sesión. Si es posible, no lo enlace desde su página principal y no use / login u otra ubicación obvia.

— Comunidad
fuente

Gracias por la info! Entonces, para aclarar las cosas, A) los dos usuarios que pueden iniciar sesión tienen contraseñas largas generadas aleatoriamente. B) Hay una especie de captcha en la página de inicio de sesión. C) Estoy tratando de que .htaccess funcione para evitar el acceso a esa página. Sin embargo, parece que los estándares para .htaccess han cambiado varias veces: sigo viendo diferentes sintaxis en todas partes y hasta ahora htaccess apenas funciona.

— Aurelius

Además, he informado de todos los ataques a online.net sin respuesta alguna.

— Aurelius

Algunos consejos útiles para htaccess: stackoverflow.com/questions/6441578/… (Recomiendo encarecidamente la autenticación de resumen).

Mirando los comentarios en esta página, ¿el resumen no parece una gran idea? httpd.apache.org/docs/2.4/mod/mod_auth_digest.html

— Aurelius

1

Me atrapaste. Sí, recordé eso desde el momento en que usé la autenticación de resumen y luego no teníamos https en todas partes. La razón por la que no usamos las contraseñas de htacces es que no es una solución a largo plazo. Está bien usarlo para ocultar algo una semana antes de publicarlo, pero para el uso diario no desea otro nivel de contraseñas. Ni siquiera es mucho más seguro. Cuando el recurso está en su lugar y no se muestra en Internet en absoluto, entonces estamos en el camino correcto.