Mudanças entre as edições de "Boas praticas para cenarios de DDoS"
(Criou página com '<nowiki>###########</nowiki> EM CONSTRUÇÃO ########### ===Introdução=== O objetivo deste artigo é explicar algumas boas práticas que você deve adotar para amenizar o i...') |
|||
Linha 9: | Linha 9: | ||
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]]. | 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: | ||
+ | |||
+ | [[Arquivo:Artigo DDoS BPF 4.png|centro|miniaturadaimagem|597.983x597.983px]] | ||
+ | |||
+ | 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". | ||
+ | |||
+ | <u>Um sintoma típico de loops de roteamento durante DDoS é o aumento do upload junto com o aumento do download durante o DDoS.</u> | ||
Criar um mecanismo para evitar loop de roteamento e monitorá-lo através do radar.qrator; | Criar um mecanismo para evitar loop de roteamento e monitorá-lo através do radar.qrator; |
Edição das 19h26min de 1 de outubro de 2020
########### 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.
Criar um mecanismo para evitar loop de roteamento e monitorá-lo através do radar.qrator;
Possuir IPs de WAN Privados com os fornecedores;
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;
Não criar regras de firewall para tentar mitigar ataques DDoS localmente.