Por que o NginX e o Lighttpd não são afetados pelo Slowloris?

23

Estou investigando a vulnerabilidade ao Slowloris e acho que entendo como e por que esse tipo de ataque funciona.

O que não entendo é por que o Lighttpd e o NginX não são afetados (de acordo com o mesmo artigo que o link acima). O que eles fazem tão diferente?

— O Shurrican
fonte

25

O Apache tem uma teoria de 'Máximo de Clientes'

Esse é o número de conexões simultâneas com as quais ele pode lidar. IE, se um servidor apache tiver um limite de 'max clients' de 100 e cada solicitação levar 1 segundo para ser concluída, ele poderá lidar com um máximo de 100 solicitações por segundo.

Um aplicativo como o SlowLoris inundará um servidor com conexões; no nosso exemplo, se o SlowLoris enviar 200 conexões por segundo, e o Apache puder lidar apenas com 100 conexões por segundo, a fila de conexões continuará aumentando e usará toda a memória da máquina um assalto. É semelhante à maneira como o LOIC do Anonymous funciona.

NGINX e Lighttpd (entre outros) não têm um número máximo de conexões, eles usam threads de trabalho, portanto, teoricamente, não há limite para o número de conexões que eles podem manipular.
Se você monitorar suas conexões Apache, verá que a maioria das conexões ativas são 'Enviando' ou 'Recebendo' dados do cliente. No NGINX / Lighttpd, eles simplesmente ignoram essas solicitações e as executam em segundo plano, sem consumir os recursos do sistema, e só precisam processar conexões com alguma coisa acontecendo (análise de respostas, leitura de dados de servidores back-end etc.)

Na verdade, eu respondi a uma pergunta semelhante esta tarde, portanto as informações também podem ser interessantes para você Reduzindo o enfileiramento de pedidos do Apache

— mancha
fonte

Resposta boa e muito detalhada. 1

— Oldskool

6

Correção secundária: o nginx não usa threads de trabalho para obter um número alto de conexões. Do nginx.org : "O Nginx não depende de threads para manipular solicitações. Em vez disso, usa uma arquitetura muito mais escalável, orientada a eventos (assíncrona)"

— dia

2

Embora seja um possível efeito colateral, a intenção do Slowloris não é "consumir toda a memória da máquina", mas esgotar a capacidade máxima de conexão, impedindo que as conexões subsequentes sejam bem-sucedidas.

— Wulfgarpro

@Day Nginx usa threads de trabalho para dar suporte à operação assíncrona. Um esquema útil da arquitetura de aplicativos é fornecido aqui: aosabook.org/en/nginx.html#fig.nginx.arch

— Terry Burton

13

Nginx é realmente vulnerável ao ataque slowloris. Recurso escasso é o número máximo de conexões simultâneas de trabalho. Esse número pode ser calculado como conexões_deprocessador * processos_processos e é igual a 512 na configuração padrão do nginx. Portanto, é muito fácil derrubar o nginx desprotegido com ferramentas como o goloris .

— valyala
fonte

golorisse parece com a ferramenta necessária para garantir que minha implementação / configuração funcione conforme o esperado!

— Alexis Wilke

8

O comentário de valyala deve ser aceito como resposta.

A maioria dos servidores nginx usa configurações padrão e, portanto, vulneráveis a ataques do tipo slowloris. Eu usei o slowloris para derrubar alguns dos sites nginx do meu amigo usando apenas meu laptop e geralmente levava menos de 5 minutos (meus amigos me desafiaram a fazê-lo).

Como valyala afirmou, tecnicamente, o nginx não é vulnerável ao slowloris, mas as configurações padrão limitam o número máximo de conexões; portanto, quando as conexões excedem esse número, o nginx descarta a nova solicitação, o que resulta em uma negação de serviço.

As maneiras conhecidas de proteger o nginx do slowloris incluem limitar o número de conexões do mesmo IP e aumentar a configuração do worker_connections. O ataque ainda pode funcionar, mas fica mais difícil (talvez demore mais de 5 minutos?: D)

— Nguyen Phan Tan
fonte