Boas praticas para cenarios de DDoS

########### EM CONSTRUÇÃO ###########

Introdução

O objetivo deste artigo é explicar algumas boas práticas que você deve adotar para amenizar o impacto de eventuais ataques de negação de serviço em sua rede.

Estas boas práticas não irão resolver os problemas de ataque em sua rede, mas sem elas, quaisquer outras medidas mais definitivas, como a contratação de um serviço de mitigação em nuvem, ou um serviço de detecção local, não surtirão todo o efeito esperado ou simplesmente serão ineficazes.

Também vale relembrar que não existe uma solução fácil, rápida e barata para ataques (D)DoS. Qualquer solução que penses em adotar exigirá também esforço e dedicação de toda a equipe da empresa envolvida nos problemas causados pelos ataques.

Antes de seguir na leitura deste artigo, recomendamos a leitura de outro, também aqui no BPF: o O Minimo que voce precisa saber sobre DDoS.

Boas práticas propostas

Previna loops de roteamento

Uma das principais causas de amplificação de ataques é o loop de roteamento. Estes loops geralmente acontecem da seguinte forma:

Exemplo 1:

• Roteador A tem rota para uma rede completa, como um /22 em IPv4, tendo como next-hop/gateway o roteador B;
• Roteador B não possui toda a rede /22 em uso, mas possui uma rota default para o roteador A;
• Ataques, inclusive de pouca volumetria, chegam com destino à IPs que não estão em uso. Estes pacotes são encaminhados pelo roteador A ao roteador B. Roteador B segue a rota default e devolve o pacote ao roteador A;
• Este ciclo se repete com cada um dos pacotes até que o TTL seja expirado, amplificando o ataque internamente.

Este exemplo pode acontecer internamente entre um roteador de borda (BGP) e um roteador adjacente na própria topologia, como no exemplo descrito acima, ou até mesmo entre o roteador de borda da empresa e o roteador do upstream, como do diagrama exibido abaixo:

Exemplo 2

No exemplo do diagrama acima, um ataque à algum IP que não está em uso, como 192.0.2.0 ou 192.0.2.100, teriam um grande potencial devastador.

Uma forma comum de resolver estes problemas é adicionar uma rota estática para a blackhole/null0/discard do bloco inteiro no(s) roteador(es) que recebe(m) rotas específicas dos IPs que estão realmente em uso.

No exemplo 1, os roteadores A e B deveriam ter um IGP (OSPF, IS-IS, EIGRP, IBGP etc), o roteador B deveria anunciar os prefixos em uso dinamicamente para o roteador A e o roteador A deveria ter uma rota estática do bloco inteiro tendo como next-hop uma interface de discard/blackhole.

No exemplo 2, bastaria adicionar uma rota estática do bloco 192.0.2.0/24 para a blackhole.

No caso de roteadores Mikrotik basta adicionar uma rota estática sem o parâmetro gateway, e mudando seu tipo para "Blackhole".

Um sintoma típico de loops de roteamento durante DDoS é o aumento do upload junto com o aumento do download durante o DDoS.

Recomendamos também o uso do Radar QRATOR para monitoramento de loops de roteamento.

Evite o uso de IPs públicos nas interfaces WAN

Um dos ataques que geralmente não terão uma contra medida específica a se adotar são os ataques nos IPs de WAN/P2P usados para entrega dos links ou estabelecimento de peerings. Quando se trata de um ataque nos seus próprios IPs, você pode simplesmente utilizar a técnica de RTBH (ou simplesmente blackhole) para descartar o tráfego externamente ou deixar de anunciar aquele bloco atacado temporariamente. Entretanto um ataque em um IP de WAN de um fornecedor não poderá ser resolvido rapidamente por você mesmo e exigirá o desligamento daquele link ou uma ação do próprio detentor daquele ASN.

Sendo assim, para evitar ataques nos IPs de WAN recomendamos que sempre peçam IPs privados, que não sejam publicamente acessíveis ou que sejam protegidos pelo fornecedor. Quando isto não for possível, sempre monitore em seus sistemas de flow e detecção de ataques também estes IPs.

Infelizmente o IX.BR não possui uma solução para este assunto, e ataques pelo próprio IX não podem ser contidos, restando apenas a opção de deixar todo o tráfego entrar ou desligar a conexão com o IX. Este inclusive é um dos motivos para que você não conte apenas com a sua capacidade de tráfego no IX para suportar a operação.

Anunciar os prefixos /24 com community de no-export;

Adotar massivamente o uso de IPv6, inclusive no DNS;

Não use endereços IPv4 públicos em seus sistemas de detecção

Os sistemas de detecção de ataque são os responsáveis por orquestrar o da proteção da rede, e por isso devem ser mantidos sob a maior segurança possível. Um ataque diretamente à um destes sistemas poderia causar uma falha nas suas funções de detecção, deixando toda a rede vulnerável, saturando os demais recursos e até possibilitando outros ataques ainda mais severos.

Sendo assim, tente acessar estes sistemas apenas por VPNs, endereços privados internamente ou com endereços IPv6 apenas.

Evite o uso de endereços IPv4 públicos diretamente nos roteadores

A maioria dos roteadores foi projetado para otimizar a função de forward (encaminhamento de pacotes) e não o input (processamento de pacotes destinados ao próprio roteador).

Desta forma, ataques à IPs dos próprios roteadores facilmente causarão travamentos ou falhas severas nos equipamentos, principalmente em softrouters como Mikrotik. Por este motivo, evite sempre possuir IPs públicos em interfaces dos roteadores. Caso isto seja realmente necessário, certifique-se de proteger estes IPs devidamente.

Comumente vemos roteadores Mikrotik que fazem CGNAT possuírem todos os IPs públicos em uma interface, como loopback. Isto multiplica o problema descrito anteriormente, e por isto é importante notar que não é necessária a existência do IP em uma interface deste roteador para que ele consiga fazer o NAT. Você pode substituir esta prática por rotas estáticas à este roteador ou criar rotas locais para a blackhole, configurando o seu IGP para distribuir as rotas deste tipo dinamicamente para o resto da rede.

Possuir fastpath ou fasttrack sempre que possível em roteadores Mikrotik;

Faça testes de detecção e mitigação constantemente;

Teste a blackhole;

Aumente o número de prefixos aceitos, pra blackhole e em geral.

Não criar regras de firewall para tentar mitigar ataques DDoS localmente.