Boas praticas para cenarios de DDoS
########### EM CONSTRUÇÃO ###########
Índice
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:
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 possuir IPv4 público no Wanguard;
Não possuir IPv4 público diretamente em interfaces de roteadores Mikrotik;
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.
