¿El bloqueo de una IP con tablas de IP lo protege de un ataque de DOS (no DDOS)?

  

Mi pregunta es, si todo lo que está haciendo es rechazar sus solicitudes,   entonces todavía tienen acceso para intentar enviar información sobre ese puerto.   ¿Todavía no pueden sobrecargar su servidor con solicitudes?

Sí, un subconjunto de atacantes puede. Si su ancho de banda es mayor que el tuyo, o si encuentran una manera de usar tu ancho de banda más rápido que el de ellos para compensar la diferencia, estás privado de ancho de banda y el tráfico legítimo no puede pasar.

Esto es realmente cierto en cualquier momento, attacker_effective_bandwidth + legitime_bandwidth > server_bandwidth, por lo que no depende únicamente de los recursos del atacante, sino también del grado en el que se aprovisiona en exceso.

Tenga en cuenta también que fail2ban se centra en los intentos de acceso y las vulnerabilidades que usted registra o supervisa. Algunos ataques de denegación de servicio se basan en comunicaciones que pueden no estar registradas (por ejemplo, las solicitudes de eco de ICMP) y es posible que no activen fail2ban.

  

si bloquea su IP y no realiza ningún procesamiento en el   información entonces realmente están lanzando piedras en una pared de ladrillo   ahí. ¿Esto es correcto?

Solo es correcto si el recurso que está preservando es la CPU, y si fail2ban observará / activará en función de todo el tráfico que cause el uso de la CPU. Dejar caer paquetes requiere una cantidad considerable de CPU, pero es mucho más pequeño que intentar hacer cualquier otra cosa con ellos.

  

¿Con qué otras razones estaría protegido contra DOS con esto?   método?

No entiendo esta pregunta, pero creo que fail2ban es una herramienta que podría usar, y una razonable. Sin embargo, debe considerar agregar otras herramientas si el costo de la caída de su sitio es mayor que el costo de adquisición y mantenimiento de las herramientas necesarias para evitarlo.

Para responder a su pregunta, sí, bloquear la IP de un atacante Hacer su servidor es una mitigación efectiva. Esto es por dos razones básicas:

Razón # 1: Hipotéticamente, si el atacante va con un ataque básico basado en la inundación con la intención de abrumar al servidor con ancho de banda (¿por ejemplo, subir archivos?) el bloqueo de su IP reducirá significativamente la IP el ancho de banda de su ataque hasta el punto no debería tener ningún impacto en su servidor (siempre y cuando su servidor no sea un hámster corriendo sobre una rueda que alimenta una Raspberry Pi).

Se debe tener en cuenta que # 1 es una estrategia de ataque rara para un ataque DoS ya que, de manera realista, un solo nodo atacante no tendrá la capacidad de ancho de banda para bloquear un servidor inundándolo de solicitudes. El caso más común es

Razón # 2: Los ataques DoS a nivel de aplicación son mucho más efectivos. Por ejemplo, supongamos que su sitio web tiene una página de inicio de sesión que realiza el cifrado criptográfico del lado del servidor de la contraseña proporcionada. Un atacante inteligente podría intentar bloquear el servidor al enfocar su ataque DoS en esa solicitud de inicio de sesión, haciendo que el servidor calcule cientos o miles de inicios de sesión simultáneos cuando la carga típica es mucho más liviana. En este caso, el marco Fail2Ban que describiste debería funcionar perfectamente, ya que filtraría las solicitudes de inicio de sesión falsas de los atacantes.

Se puede eludir la táctica de mitigación completa mediante la rotación frecuente de una dirección IP falsificada en la nota del atacante, pero eso se convierte en un extraño híbrido DDoS / DoS y usted preguntó específicamente acerca del DoS antiguo. Por lo tanto, la respuesta se mantiene. Simplemente bloquear la IP de ataque debería ser una defensa adecuada.

Lo que probablemente sea más importante aquí es que, en lo que respecta a la mitigación, es casi inútil diferenciar los ataques DoS y DDoS en estos días. Ya no se producen ataques de denegación de servicio en el mundo real desde una única fuente de IP fija.

La única excepción obvia es cuando un atacante genera un paquete especialmente diseñado para explotar una vulnerabilidad con potencial DoS (por ejemplo, un null puntero de referencia en algún lugar en un código de manejo de paquetes; aquí hay un ejemplo de dicha vulnerabilidad ). Pero bloquear una dirección IP de origen que ejecuta un exploit no es realmente una buena manera de mitigar eso; parchear un sistema vulnerable es.

En teoría, sería más fácil manejar un ataque DoS simple que un ataque distribuido. Sin embargo, como son demasiado fáciles de mitigar, en su mayoría están extintos hoy en día, y la herramienta que está preguntando (Fail2Ban) no está ahí para ayudar contra los ataques extintos, está escrita teniendo en cuenta la aplicación del mundo real.

Teniendo esto en cuenta, bloquear una dirección IP (ya sea con Fail2Ban o manualmente) solo tiene sentido si se cumplen dos condiciones al mismo tiempo:

1. El ataque DDoS que está en curso afecta solo el rendimiento del propio servidor (o cualquier cosa detrás de él, como un servidor de base de datos detrás de una aplicación web), pero no el transporte de red que se encuentra delante ;
2. Se puede verificar de alguna manera que no se falsifican todas las direcciones IP de origen involucradas en el ataque. P.ej. un ataque DDoS apunta a un servicio de red basado en handshake (donde puede negociar algún secreto hacia un cliente y verificar que el cliente tenga En realidad recibió el secreto), y pasa el apretón de manos básico con éxito. Puedo dar otro ejemplo, pero la descripción anterior resume bastante bien el escenario más frecuente.

Con respecto a un servidor HTTPS típico, puede usar el bloqueo del rango de IP contra, por ejemplo, la inundación de la conexión TCP , la inundación de protocolo de enlace SSL / TLS, la inundación de POST, Slowloris , etc. (es bastante difícil clasifique los ataques de Capa 7 más allá de las simples inundaciones), que en la mayoría de los casos satisfacen ambos requisitos.

Tenga en cuenta que, por ejemplo, una inundación POST lo suficientemente grande podría afectar el transporte de red frente a su servidor, el bloqueo de IP todavía puede ayudarlo con eso, ya que impide que se establezcan las conexiones TCP subyacentes y un bot malicioso. no podrá enviar posteriormente un cuerpo POST grande hacia su servidor. Esto limita efectivamente el tráfico entrante malicioso restante a una inundación de SYN de baja velocidad que en la mayoría de los casos es fácil de manejar.

Además, el principal efecto que causará una inundación basada en HTTP en su transporte de red se debe al tráfico de salida generado por su servidor en respuesta (que en el HTTP de hoy puede ser aproximadamente de 11 a 12 veces más que el de entrada), y el bloqueo de las fuentes IP de una inundación de HTTP elimina esto también debido a las razones descritas anteriormente.

Al mismo tiempo, el bloqueo de IP es casi inútil contra ataques como ICMP flood, SYN flood, UDP flood , y otros que no cumplen al menos el requisito # 2; y contra los ataques de amplificación que son, en la mayoría de los casos, tan poderosos en términos de tráfico entrante que No cumpla con el requisito # 1.

Tenga en cuenta que el hecho de que una dirección IP de origen en una inundación SYN, por ejemplo, no se pueda verificar, no significa necesariamente que esté falsificada. Sin embargo, el bloqueo de un rango de direcciones IP potencialmente falsificadas puede hacer que su servicio no sea accesible para usuarios legítimos. De hecho, puede ser la intención de un atacante engañarlo para que comience a iniciar automáticamente (por ejemplo, a través de la mencionada herramienta Fail2Ban) bloquear las direcciones IP de origen de una inundación basada en paquetes, mientras que solo hay pocas fuentes presentes en el tráfico, y luego es importante Los rangos de direcciones IP, como los rangos de IP de los ISP más grandes en su país, o incluso el rango global de direcciones IPv4 de ~ 4 mil millones de direcciones que, a una tasa de inundación arbitraria de 100 Mbit por segundo, se podrían enumerar en aproximadamente una hora - De hecho, lo he visto en mi vida varias veces.