Numa época como essa, em que webmasters e “blogueiros” em todo mundo estão com os “nervos à flor da pele” por causa do script Gumblar, surge uma nova forma de ameaça aos servidores web, em especial o Apache, e até o Squid.

.

O guru da segurança, Robert “RSnake” Hansen, presidente da empresa SecTheory, lançou uma nova ferramenta (na verdade um script) de ataque DoS (Denial-of-Service), que aponta uma significativa falha no servidor Apache, e alguns outros.

Hansen chama sua criação de “Slowloris”, ou, em suas palavras, “cliente HTTP com banda baixa, porém ambicioso e venenoso”. Ao contrário de tudo o que se sabe sobre ataques DoS, no qual serviços web são colocados de joelhos através do bombardeio de maciços volumes de dados, o Slowloris alcança o mesmo resultado com um punhadinho de pacotes.

Um ataque DoS típico, com pacotes TCP, tipo “request-flooder”, demanda, pelo menos, mil computadores só para derrubar um único servidor web. Como os grandes servidores contam com grandes larguras de banda (links de dados), e roteadores capazes de lidar com grandes fluxos de tráfego, ultimamente tem se tornado difícil conseguir máquinas zumbis suficientes para tal façanha. Com o Slowloris, contudo, só é preciso pouco mais de mil pacotes de dados para começar, e depois (agora você vai ficar arrepiado!) cai para uma taxa regular de 200 a 300 pacotes por minuto — em um só computador!

É uma perspectiva apavorante, você há de concordar…

E como funciona?

De modo geral um ataque DoS típico consiste em esgotar os recursos de um servidor ou roteador, até que ele pare de responder. No caso de servidores web considere-se que eles conseguem lidar com grandes volumes de requisições, e são hospedados em computadores com grande capacidade de processamento, e, portanto, esgotar os recursos de um serviço assim não é fácil. O que o Slowloris faz é enviar pedidos parciais de conexões HTTP. Com isso ele consegue “segurar” o servidor. “Como assim?”, você deve estar se perguntando… No caso, o Slowloris faz um pedido que nunca se completa. O Apache tem a característica de manter conexões HTTP abertas por longos períodos, e assim, se forem enviadas várias requisições parciais de HTTP, ele esperará por um longo tempo até que essas requisições se completem – o que, no caso do Slowloris, não acontecerá. Essa é a “mágica” (posso chamar assim?) desse ataque: ele consiste em manter uma conexão HTTP aberta indefinidamente (ou pelo máximo de tempo possível), repetindo a abertura de novas conexões algumas centenas de vezes, as quais nunca se concluem, até que o servidor pare de responder.

E por que o Apache — justo o Apache; o nosso querido Apache?! — “cai nessa”?

Porque a diretiva “TimeOut”, do arquivo apache.conf (ou apache2.conf, dependendo da versão) vem, por padrão, com parâmetro 300 — isto é, 300 segundos, ou 5 minutos. Essa é a chave principal (mas não a única) para o sucesso do Slowloris: o Apache, por padrão, permite manter conexões abertas por até 5 minutos! A diretiva “KeepAlive”, vem “ligada” (“on”), e a “KeepAliveTimeOut” vem definida como 15 — 15 segundos para esperar a próxima requisição do mesmo cliente, na mesma conexão. Outras diretivas também podem influir no resultado (veja mais, abaixo).

O código do Slowloris permite definir tempo de time out para conexão TCP, time out para nova tentativa de conexão, e, ainda, permite definir tempos, em minutos, para a duração do ataque – além de outros parâmetros.

O Slowloris teve “ótimos resultados” (se é que posso chamar assim…) nos seguintes servidores:

.

• Apache 1.X;
• Apache 2.X;
• dhttpd;
• GoAhead Webserver;
• Squid.

.

Segundo Hansen, e outros especialistas consultados, os servidores que se mostraram resistentes ao ataque foram:

.

• Microsoft IIS 6.0;
• Microsoft IIS 7.0;
• lighttpd;
• nginx;
• Cherokee.

.

No caso do IIS (Internet Information Services) da Microsoft, a resistência ao ataque se deveu ao fato desse servidor usar um “worker pool” que tem a característica de permitir tantas conexões abertas quantas os seus recursos permitam. Esgotado esse limite, as conexões são fechadas para preservação.

A Apache emitiu uma “dica de segurança”, na qual ensina como mitigar a ameaça do Slowloris. Basicamente consiste em se diminuir os respectivos parâmetros das diretivas “TimeOut” e “KeepAliveTimeOut”; em alguns casos, pode-se desligar a diretiva “KeepAlive”; redefinir o limite de consumo de recursos nas diretivas “LimitRequestBody”, “LimitRequestFields”, “LimitRequestFieldSize”, “LimitRequestLine” e “LimitXMLRequestBody”. Outra opção é ativar a diretiva “MaxClients”, para definir o número máximo de conexões simultâneas.

Se você é administrador de um servidor Apache, primeiro, calma! Reveja suas configurações, no que tange especificamente às diretivas mencionadas acima, e mantenha-se atento a possíveis atualizações de segurança do Apache (estou supondo que você as faz regularmente. Se não faz, comece agora!). O Slowloris apenas expôs uma vulnerabilidade do Apache, mas ele permanece tão viável quanto sempre foi!!

Texto original cique aqui .