He detectado algunos intentos de probar la seguridad de mi sitio. ¿Debo poner en lista negra su dirección IP? ¿Cuáles son las consideraciones o las compensaciones que se deben utilizar para decidir cuándo bloquear su dirección IP y cuándo no?
Como regla general, los rendimientos de este tipo de defensa son casi cero. Hay excepciones, pero incluso entonces esta técnica puede ofrecer solo una pequeña cantidad de seguridad.
Los análisis de vulnerabilidad exhaustiva de los hosts elegidos al azar ofrecen retornos extremadamente bajos en los recursos de análisis. En su lugar, los atacantes exitosos generalmente eligen una de las siguientes dos opciones para aumentar sus probabilidades:
Compruebe si hay un número muy pequeño de vulnerabilidades en un gran número de hosts
Esto incluye contraseñas incorrectas para servicios comunes como SSH, POP3, cPanel, Wordpress, Joomla y similares. Si su contraseña de root es "root" o si la contraseña de administrador de su sitio es "admin", puede esperar ser atrapado en una de estas redes de deriva sorprendentemente rápido.
Comenzando con una única vulnerabilidad conocida, use una técnica de búsqueda para limitar su lista de objetivos solo a las víctimas más probables.
Por lo general, esto comienza en una de las bases de datos comunes de vulnerabilidad. Encuentra un candidato reciente e identifica una cadena que sería común en los hosts vulnerables. Esto suele ser una línea "Desarrollado por" o un enlace de inicio de sesión o un patrón de URL específico. Luego, utilizando su motor de búsqueda favorito, recupera una lista de sitios que siguen ese patrón.
El punto importante es que en ninguno de estos casos el atacante hace más de unos pocos intentos en un sitio determinado. O tienen éxito de inmediato, o siguen adelante.
Eso no quiere decir que no verás a un atacante persistente ocasional. Siempre hay un individuo optimista y mal dirigido que ejecuta Nessus contra a / 16, pero tales ataques son, por su propia naturaleza, autolimitados y muy raramente exitosos, ya que la mayoría de los ataques apuntan al software que un servidor determinado no realiza. ni siquiera correr.
¿Podría tal ataque tener éxito? Sí. ¿Alguna vez sucede? En promedio, trato con varios servidores comprometidos por día, y hasta ahora todavía no he visto ninguno de los análisis de espectro completo de estilo nessus . Pero la probabilidad no es exactamente cero. Y en el mundo de los ataques aleatorios, las estadísticas y las probabilidades son muy importantes.
La excepción es cuando el ataque es no aleatorio. Si ejecuta un sitio de alto valor o alta visibilidad, atraerá muchos ataques directos contra usted en particular Sitios como Facebook, Twitter, Hotmail, etc., ven una cantidad extraordinaria de tráfico de ataques. Si opera en este tipo de sitio, probablemente ya se tome muy en serio la seguridad y no esté buscando consejos.
Una nota sobre la inyección de SQL: este tipo de ataque tiene algún refinamiento; después de detectar un mensaje de error de SQL en un análisis rápido, un atacante puede enviar varias docenas de consultas a un servidor determinado para que los bits se centren correctamente. Por lo tanto, teóricamente, una respuesta de restricción puede evitar un ataque de este tipo ... pero probablemente no, ya que probablemente solo regresará con una IP diferente. Dado que ya está alertado en su servidor, no será disuadido por una lista negra. Un mejor consejo es no ejecutar software de mierda. No hay excusa para utilizar consultas no parametrizadas hoy.
Argumentos a favor de la inclusión en la lista negra: También podría dificultar la vida del atacante. Si bien esta no es una defensa fuerte, puede dar un poco más de tiempo para investigar el ataque y establecer defensas más fuertes.
Argumentos contra listas negras: en el caso de direcciones IP dinámicas, las listas negras pueden terminar bloqueando a otros usuarios benignos. Es posible que nunca sepa que está bloqueando a otros usuarios benignos, o que podría dar lugar a errores difíciles de diagnosticar en el futuro. Además, existe cierta complejidad de configuración potencial para administrar una lista negra.
Si el atacante intenta interrumpir el sitio sobrecargando (para montar un ataque de denegación de servicio), bloquear la dirección IP puede ser la respuesta correcta. Un bloqueo temporal podría ser suficiente.
Si el atacante está explorando o explorando, me inclinaría menos a poner en una lista negra su dirección IP, pero puede tener en cuenta las ventajas y desventajas en cada situación y tomar una decisión informada sobre lo que tiene más sentido.
Obviamente, depende de lo que haga su sitio, la desventaja de bloquear las IP (podría bloquear inadvertidamente a clientes reales que no atacan) y el riesgo de que algo se vea comprometido (es probable que algunos usuarios tengan contraseñas débiles para el usuario). sitio?)
Los bloques a corto plazo parecen perfectamente razonables y varían desde 5 minutos hasta un día. Esto puede permitir que un atacante intente ~ 1000 intentos por día, en comparación con ~ 1000 por segundo en un ataque en línea. Por supuesto, debe asegurarse de no bloquear a los usuarios legítimos que olvidaron su contraseña.
Personalmente, por ejemplo, bloqueo grandes rangos de direcciones IP de China / Rusia en un sitio web que administro para un negocio local. Observé que el servidor ssh para el sitio web tenía un par de miles de intentos de inicio de sesión con nombres de usuario inexistentes. Si bien no estaban cerca de adivinar mi nombre de usuario, y mucho menos mi frase de contraseña aleatoria de alta entropía, no me sentí cómodo con los intentos y no hay razón para dejarlos continuar. Así que instalé fail2ban con configuraciones sueltas (cinco inicios de sesión fallidos = 30 minutos de prohibición; lista blanca para mis direcciones IP estáticas; por lo tanto, todavía puedo iniciar sesión si es necesario. raro). También cambié el puerto ssh de 22, sí, esto es solo seguridad por oscuridad que se puede vencer fácilmente mediante un escaneo de puertos (aunque podría configurar un honeypot para eso, pero no lo hizo), pero está bien si es parte de la defensa. profundidad. La implementación de estos cambios hizo que la cantidad de ataques se redujera a cero en el último mes (tan atrás como los registros).
Editar: esta respuesta no considera el inicio de sesión de fuerza bruta, solo ataques que intentan explotar las vulnerabilidades del sistema. Por supuesto, me parece legítimo prohibir temporalmente una IP que intente 30 inicios de sesión en 5 minutos. / editar.
Si no tiene un sistema automático para revisar y bloquear solicitudes, no prohíba las direcciones IP que intentan hackear su servicio. Si los bloquea, no podrán realizar más solicitudes y no sabrá si hay una fuga . Los ataques ocurren día y noche, y la mayoría de las veces, no estarás viendo el registro mientras intentas un ataque. Bloquee un ataque ahora, y algún día alguien más encontrará la fuga.
Por supuesto, el bloqueo de direcciones IP de ataque es una medida de precaución que ayudará a su seguridad. No es seguridad real, pero podría simplemente protegerse de un ataque mientras le avisa con anticipación.
Hacer esto de manera automatizada puede tener una ventaja cuando devuelve una respuesta predeterminada (como una respuesta HTTP-200) para que las herramientas automatizadas no detecten el bloqueo. Si sigue registrando las solicitudes , puedes verificar más tarde si alguno de los intentos hubiera tenido éxito.
Aunque hay algunos problemas con esto:
En general, no bloquearía ningún intento de ataque. Puede haber situaciones en las que sea una buena idea (quizás en entornos de alta seguridad, como para un banco o un sitio web con millones de visitantes). pero en general no creo que realmente ayude, o incluso puede darte una falsa sensación de seguridad.
La única excepción es un ataque DoS. Aquí no hay riesgo de seguridad, lo único que se explota es el tiempo de procesamiento o el ancho de banda, por lo que no hay razón para no bloquear esto. Aunque incluso en ese momento, solo se puede restringir o prohibir temporalmente: estos ataques probablemente se realizan desde una red de bots, lo que hace que bloquees las IP de los usuarios.
Monitorearía la situación un poco más antes de pasar a la lista negra de IP, incluso temporalmente. Además de los inconvenientes mencionados por D.W., no creo que un intento serio de atacar su sitio emplee la misma IP más de un par de veces; no es muy difícil de falsearlo después de todo. Sin embargo, si después de un breve tiempo dedicado a la supervisión, observara varias sondas de esa IP específica, definitivamente consideraría bloquearla.
Otra cosa que podría estar buscando es la naturaleza de las sondas. Si el rango de direcciones IP ofensivas comparte características comunes en un período de tiempo determinado, es muy probable que el mismo atacante las haya creado.
Finalmente, si los ataques persistieran y / o tuviera algo de tiempo libre, intentaría hacerme una idea de lo que ve el atacante repitiendo las sondas. Como mínimo, obtendría más información sobre la seguridad de mi sitio.
Esta es una compensación "depende".
1: ¿cuál es la prioridad de la accesibilidad frente a la obstrucción de los atacantes?
Para cualquier bloque, desea determinar si está bloqueando el uso legítimo así como los atacantes. Por ejemplo, si la IP proviene de su cliente y una de sus máquinas ha sido pirateada para escanearlo, es posible que desee alertar al cliente y trabajar con su equipo de seguridad en lugar de disparar con su propio pie.
2: ¿cuál es el impacto?
¿Tiene desactivados los protocolos útiles que exponen su red? ¿Qué puede ver el atacante cuando te escanean en el puerto? Escanearse de forma regular es una buena práctica, para que pueda saber de qué es vulnerable. Si ha bloqueado las cosas bastante bien, su riesgo aquí es menor.
También, ¿qué daño está haciendo la exploración? ¿Está desacelerando el uso legítimo?
3 - ¿Cuál es la naturaleza del riesgo? ¿Cuál es su capacidad para gestionarlo?
Los clásicos típicos: disponibilidad, compromiso de activos o información, reputación de la organización. ¿Qué puede perder del análisis de puertos, qué puede perder si encuentran algo y con qué frecuencia ocurre?
¿Y cuál es su personal y su capacidad para abordarlo? En algunas redes, poner un bloque es rápido y fácil, en otras se necesita un grado significativo de diligencia debida. Si lo pones incorrectamente, ¿cuál es el daño?
Lo más razonable ahora es seguir ese análisis y asegurarse de que el atacante no haya encontrado nada vulnerable en su aplicación. En segundo lugar deberías comprobar esa IP. Bloquear la dirección IP de alguien no siempre es la mejor solución. El atacante podría estar escondido detrás del NAT. Así que si comparte su IP con muchos usuarios diferentes, perderá visitantes (también estarán bloqueados). El escaneo también se puede iniciar desde la víctima inocente (su PC podría ser parte de la botnet). Sin embargo, debe asegurarse de que:
Sugiero un enfoque diferente al problema en lugar de prohibir las direcciones IP o fail2ban, que pueden ser frágiles e ineficaces. En su lugar, recomiendo cambiar la configuración de su servidor web para que todas las solicitudes a nombres o ubicaciones de servidores desconocidos devuelvan 404. Escribí sobre esta técnica para nginx aquí:
Si tiene visitantes molestos, raspadores de sitios o spammers, puede que le resulte útil bloquear a estos usuarios para que no accedan al contenido de su sitio web. Puede bloquear los visitantes incorrectos por dirección IP o bloques de direcciones IP utilizando un archivo .htaccess.
Lea más algunos ejemplos útiles: enlace
Lea otras preguntas en las etiquetas network threat-mitigation