Mitigar ataque DDoS com HAProxy [duplicado]

Question

Fomos alvo hoje cedo de um ataque DDoS. Havia 20x tantas conexões quanto o normal em nosso balanceador de carga (HAProxy) e todos os nós de back-end continuaram a descer durante esse ataque.

System structure: HAProxy > Squid > Apache (for ModSecurity) > IIS app layer.

Durante o ataque, notei que havia um erro MaxClients Reached no Apache, então alterei a configuração de 150 para 250 e pareceu ajudar em alguma medida. No entanto, parecia que eu tinha que continuar reiniciando o Apache manualmente para que os backends se recuperassem. O ataque durou cerca de 50 minutos.

Depois que o ataque começou a diminuir, um reinício final do Apache em cada nó nos trouxe para o green, mas agora estou investigando por que isso ocorreu em primeiro lugar. Nos logs de erro do Apache, vejo muitos deles:

[Wed Jun 22 11:46:12 2011] [error] [client 10.x.x.x] proxy: Error reading from remote server returned by /favicon.ico
[Wed Jun 22 11:46:13 2011] [error] [client 10.x.x.x] (70007)The timeout specified has expired: proxy: error reading status line from remote server www.example.com

O Apache está usando as configurações padrão de keep-alive (os keep-alives estão habilitados e o tempo limite está definido para 15 segundos). Depois de fazer algumas leituras adicionais em HAProxy + keep-alives, é uma conclusão razoável acreditar que o DDoS foi agravado pelo keep-alives sendo ativado?

Embora as conexões HAProxy max estejam bem abaixo dos máximos definidos no Apache, talvez com as conexões 20x muitas conexões estivessem sendo abertas na moda do DOS, mas o Apache as mantinha abertas.

    

Answer 1

Depois de o problema surgir mais algumas vezes nas semanas seguintes ao "ataque" inicial, tive que ir mais fundo, pois achava que poderia estar usando o DDoS como desculpa.

Embora os registros de acesso e os instantâneos netstat (obtenham os IPs superiores ordenados pelo número de conexões anexadas a um arquivo de log) mostrassem definitivamente uma quantidade muito distribuída de endereços IP, consegui identificar uma página específica nos logs de acesso que Parecia suspeito.

Aparentemente, a equipe de desenvolvimento criou uma página de "proxy" para exibir solicitações de API de terceiros por meio do AJAX. O problema parece ser que essa página de proxy estava usando slots de conexão valiosos no HAProxy e, quando o serviço de terceiros tinha problemas na entrega de solicitações de API, demorava muito tempo para expirar. Eventualmente, as solicitações de proxy demoradas levaram nosso back-end HAProxy ao limite máximo (para que todas as novas solicitações fossem enfileiradas). A partir desse ponto, as contagens de conexões começaram a aumentar em nossa rede, e nosso site voltado para o público iniciou o tempo limite de solicitações normais não AJAX.

A solução, no nosso caso, foi criar um backend adicional no HAProxy especificamente para essas chamadas AJAX. Na próxima vez que o serviço terceirizado tiver problemas, ele só atingirá o tempo limite das chamadas da página proxy do AJAX, e o restante do site continuará a se movimentar.

Obrigado pelas respostas. Acho que a maioria de vocês estava no local para mitigar um ataque DDoS "real", mas acho que é útil para outros leitores saberem que vale a pena olhar internamente para ter certeza de que você não está atirando no próprio pé.

    

Answer 2

Acho que você está indo atrás da solução errada para esse cenário. Se você está sendo DDoSed, então a única rota real de mitigação que você tem é conversar com seus provedores de upstream e levá-los a nulo-rota / blackhole o tráfego antes que ele chegue à sua rede. Caso contrário, não importa o que você faça, ele ainda estará alcançando a borda da sua rede e potencialmente (provavelmente) saturando a conexão no final.

A única coisa a fazer é bloqueá-lo antes que ele alcance a borda da sua rede. É improvável que qualquer tipo de cenário de mitigação de DDoS seja tão útil, pois o tráfego precisa entrar em sua rede antes que possa ser ignorado / bloqueado / interrompido. Como resultado, ele ainda consumirá sua largura de banda.

    

Answer 3

Além disso, simplesmente aumentar o número de trabalhadores disponíveis pode piorar o problema se você não tiver memória suficiente disponível para todos os processos filhos. Você vai começar a trocar para o disco e sua máquina vai parar. Surpreso que ninguém mencionou mod_evasive ou mod_security também; ter algumas heurísticas automatizadas para bloquear o acesso a recursos dispendiosos em termos computacionais ajuda bastante no caso de você upstream não conseguir ou não fazer o roteamento nulo.

EDIT: este foi um comentário, mas eu o transformei em uma resposta por sugestão do @Tom O'Connor.

    

Answer 4

@ Tom O'Connor este não é um tipo de DDoS de largura de banda / pps. Parece-me uma simples negação de serviço.

Mantenha-se vivo para piorar, seu problema aqui é que o Apache não pode processar solicitações tão rápido quanto deveria e gera muitos trabalhadores que não conseguem acompanhar as solicitações. À medida que isso aumenta, as chances de recuperação são praticamente nulas se o ataque continuar.

Você pode, obviamente, aumentar a diretiva MaxClients, mas a partir do que você descreveu, você apenas fará um minuto ou dois mais tarde.

Não tenho certeza de qual pilha você está executando, mas o objetivo para você é simplesmente melhorar a resposta do Apaches a uma única solicitação (você está executando o PHP? Está conectando ao MySQL? Você não está armazenando em cache?) 0,010 segundos responderão 100 vezes melhor a uma página .vs de negação de serviço que procura toneladas de material no MySQL e termina em 2 segundos por solicitação.

Se alguém fizer 100 solicitações, seu servidor terá que trabalhar por 200 segundos, mas como faz tudo de uma só vez, 2 segundos / solicitação agora é 40 segundos / solicitação * 100. Mais solicitações, mais carga.

Outra maneira de resolver isso é identificar as principais conexões xyz e simplesmente bloqueá-las, mas isso será um pouco mais complicado e requer um pouco mais de conhecimento para uma tentativa adequada.