webserver - Protégete contra los ataques Dos

protection denial-of-service (4)

Esto podría ser algo más adecuado para Serverfault, pero muchos desarrolladores de sitios web que solo vengan aquí se beneficiarán de las posibles respuestas a esta pregunta.

La pregunta es: ¿Cómo se protege efectivamente contra los ataques de Denegación de Servicio contra su servidor web?

Me pregunté esto después de leer este article

Para aquellos que no están familiarizados, esto es lo que recuerdo al respecto: un ataque DoS intentará ocupar todas tus conexiones enviando repetidamente encabezados falsos a tus servidores.

Al hacerlo, su servidor alcanzará el límite de posibles conexiones simultáneas y, como resultado, los usuarios normales ya no podrán acceder a su sitio.

Wikipedia proporciona más información: http://en.wikipedia.org/wiki/Denial_of_service

Los servidores asíncronos, por ejemplo, son más o menos inmunes a esta forma particular de ataque. Por ejemplo, sirvo a mis aplicaciones Django utilizando un proxy inverso Nginx, y el ataque no parece afectar su funcionamiento en absoluto. Otro servidor asíncrono popular es lighttpd.

Tenga en cuenta que este ataque es peligroso porque puede ser realizado incluso por una sola máquina con una conexión lenta. Sin embargo, los ataques DDoS comunes enfrentan a su servidor contra un ejército de máquinas, y hay poco que pueda hacer para protegerse de ellas.

No hay panacea, pero puede hacer que los ataques de DoS sean más difíciles haciendo lo siguiente:

No (o limite su voluntad de) hacer operaciones costosas en nombre de clientes no autenticados
Intentos de autenticación del acelerador
Acelera las operaciones realizadas en nombre de cada cliente autenticado y coloca su cuenta en un bloqueo temporal si hacen demasiadas cosas en un tiempo demasiado breve
Tenga un acelerador global similar para todos los clientes no autenticados y prepárese para reducir esta configuración si detecta un ataque en curso
Tenga una marca que pueda usar durante un ataque para deshabilitar todos los accesos no autenticados
No almacene cosas en nombre de clientes no autenticados, y use una cuota para limitar el almacenamiento para cada cliente autenticado
En general, rechace todas las solicitudes mal formadas, irrazonablemente complicadas o excesivamente grandes lo más rápido posible (y regístrelas para ayudar en la detección de un ataque)
No use un caché LRU puro si las solicitudes de clientes no autenticados pueden resultar en el desalojo de ese caché, ya que estará sujeto a ataques de envenenamiento de caché (donde un cliente malintencionado solicita un montón de cosas que se usan con poca frecuencia, lo que hace que desaloje todo). las cosas útiles de su caché y necesita hacer mucho más trabajo para servir a sus clientes legítimos)

Recuerde, es importante rechazar directamente las solicitudes limitadas (por ejemplo, con un HTTP 503: respuesta de Servicio no disponible o una respuesta similar apropiada para cualquier protocolo que esté usando) en lugar de poner en cola las solicitudes limitadas. Si los colocas en la cola, la cola acabará con toda tu memoria y el ataque DoS será al menos tan efectivo como lo hubiera sido sin la limitación.

Algunos consejos más específicos para los servidores HTTP:

Asegúrese de que su servidor web esté configurado para rechazar los mensajes POST sin el encabezado Content-Length acompaña, y para rechazar las solicitudes (y estrangular al cliente infractor) que exceda la Content-Length indicada, y para rechazar las solicitudes con una Content-Length que sea irrazonable el servicio al que se dirige el POST (o PUT )

Para este ataque específico (siempre que la solicitud sea GET), se basará en un equilibrador de carga o un WAF que solo base las solicitudes completas al servidor web.

Los problemas comienzan cuando se usa GET POST en lugar de GET (lo cual es fácil) porque no se puede saber si se trata de un POST malicioso o solo de una carga realmente lenta de un usuario.

Desde DoS per se no puede realmente proteger su aplicación web debido a un hecho simple. Sus recursos son limitados, mientras que el atacante potencialmente tiene tiempo y recursos ilimitados para realizar el DoS. Y la mayoría de las veces es barato para el atacante realizar los pasos necesarios. por ejemplo, este ataque mencionado anteriormente unas pocas 100 conexiones de ejecución lenta -> no hay problema

Respuesta corta:

No puedes protegerte contra un DoS.

Y no estoy de acuerdo en que pertenezca a Serverfault ya que DoS está categorizado como un problema de seguridad y está definitivamente relacionado con la programación