Boas praticas para cenarios de DDoS - Histórico de revisão

Daniel Damito em 21h20min de 30 de agosto de 2022

2022-08-30T21:20:12Z

Daniel Damito: /* Evite o uso de endereços IPv4 públicos diretamente nos roteadores */

2020-10-07T23:49:11Z

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

Daniel Damito: /* Evite o uso de endereços IPv4 públicos diretamente nos roteadores */

2020-10-03T13:58:14Z

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

Daniel Damito: /* Evite o uso de IPs públicos nas interfaces WAN */

2020-10-03T13:53:22Z

Evite o uso de IPs públicos nas interfaces WAN

Daniel Damito em 13h51min de 3 de outubro de 2020

2020-10-03T13:51:42Z

Daniel Damito: /* Anuncie os prefixos mais específicos com community de no-export para todos seus fornecedores */

2020-10-02T00:46:38Z

Anuncie os prefixos mais específicos com community de no-export para todos seus fornecedores

Daniel Damito: /* Utilize Fastpath ou Fasttrack em Mikrotiks sempre que possível */

2020-10-02T00:42:06Z

Utilize Fastpath ou Fasttrack em Mikrotiks sempre que possível

Daniel Damito: /* Não use endereços IPv4 públicos em seus sistemas de detecção */

2020-10-02T00:39:29Z

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

Daniel Damito: /* Previna loops de roteamento */

2020-10-02T00:37:19Z

Previna loops de roteamento

Daniel Damito: /* Previna loops de roteamento */

2020-10-02T00:36:49Z

Previna loops de roteamento

← Edição anterior		Edição das 21h20min de 30 de agosto de 2022
Linha 24:		Linha 24:

	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, teria um grande potencial devastador.		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, teria um grande potencial devastador.
		+
		+	Uma das formas de testar loops de roteamento é através do utilitário fping. Exceto em casos de bloqueios explícitos de bloqueio, um mero teste de ping é capaz de mostrar IPs que estão em loop e portanto respondem com ICMP Time Exceeded. A linha de comando abaixo, que usa a rede 192.0.2.0/24 como exemplo, mostra todos os IPs nesta rede que supostamente estão em loops:
		+
		+	''fping -gae 192.0.2.0/24 2>&1 \| grep -Fi time \| cut -d" " -f 11''

	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.		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.

@@ Linha 52: / Linha 52: @@
 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 e VyOS. 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.
+Desta forma, ataques à IPs dos próprios roteadores facilmente causarão travamentos ou falhas severas nos equipamentos, principalmente em ''softrouters'' como Mikrotik e VyOS. Por este motivo, evite sempre possuir IPs públicos em interfaces (físicas ou lógicas, inclusive em loopbacks) 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.

@@ Linha 52: / Linha 52: @@
 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.
+Desta forma, ataques à IPs dos próprios roteadores facilmente causarão travamentos ou falhas severas nos equipamentos, principalmente em ''softrouters'' como Mikrotik e VyOS. 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.
@@ Linha 62: / Linha 62: @@
 ==== Não crie regras de firewall para tentar mitigar ataques DDoS localmente ====
-Provavelmente você não conseguirá mitigar ataques DDoS com regras de firewall triviais em roteadores, sobretudo softrouters como Mikrotik. Por este motivo, evite usar regras de firewall, principalmente na tabela ''filter'' durante ataques. Estas regras, se mal utilizadas, ao invés de resolver o seu problema, irão aumentá-lo, fazendo com que o roteador tente processar todo o ataque ao invés de apenas encaminhar o tráfego para seu destino, causando seu travamento total.
+Provavelmente você não conseguirá mitigar ataques DDoS com regras de firewall triviais em roteadores, sobretudo softrouters como Mikrotik e VyOS. Por este motivo, evite usar regras de firewall, principalmente na tabela ''filter'' durante ataques. Estas regras, se mal utilizadas, ao invés de resolver o seu problema, irão aumentá-lo, fazendo com que o roteador tente processar todo o ataque ao invés de apenas encaminhar o tráfego para seu destino, causando seu travamento total.
 Uma alternativa barata e eficaz para mitigar alguns ataques localmente é o uso de flowspec automatizado.
@@ Linha 74: / Linha 74: @@
 Aproveitando o ensejo do tópico anterior, recomendamos que seus sistemas de detecção e mitigação sejam testados periodicamente. E estes testes devem considerar os cenários mais distópicos possíveis, como a falta do IPv6, ataques de carpet bombing, ataques de grandes volumetrias e ataques de exaustão de recursos.
-Testes assim podem ser feitos usando stress testers como o [https://www.ipstresser.com/ IP Stresser]ou utilitários como o hping3 executados remotamente. Cuidado ao escolher uma stress tester, pois elas podem ser um golpe.
+Testes assim podem ser feitos com utilitários como o hping3 executados remotamente.
 É importante que se tenha uma check list de itens a se testar, como:

@@ Linha 42: / Linha 42: @@
 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 [http://ix.br/ 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.
+Infelizmente o [http://ix.br/ IX.BR] não possui uma solução para este assunto, e ataques pelo próprio IX nos IPs do ATM 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.
 ==== Não use endereços IPv4 públicos em seus sistemas de detecção ====

@@ Linha 2: / Linha 2: @@
 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.
+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.

@@ Linha 96: / Linha 96: @@
 Durante uma convergência de rotas, seus prefixos podem sofrer loops de roteamento na Internet, causando uma indisponibilidade temporária. Este problema, quando esporádico, não traz grandes transtornos.
-Entretanto durante épocas de ataques constantes exigem uma constante manipulação de prefixos de forma automática para que sejam mitigados.
+Entretanto épocas de ataques constantes exigem uma constante manipulação de prefixos de forma automática para que sejam mitigados.
 Para que não tenhas indisponibilidade à cada desvio ou modificação de anúncio BGP, recomendamos que todos os prefixos mais específicos sejam anunciados com a community de no-export para todos os upstreams.

← Edição anterior		Edição das 00h42min de 2 de outubro de 2020
Linha 60:		Linha 60:

	Caso o fastpath não seja possível, uma alternativa ao fastpath pode ser o [https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack fasttrack]. Apesar de ele ser menos eficaz que o fastpath e um pouco mais complexo, também pode reduzir bastante os danos causados por ataques.		Caso o fastpath não seja possível, uma alternativa ao fastpath pode ser o [https://wiki.mikrotik.com/wiki/Manual:IP/Fasttrack fasttrack]. Apesar de ele ser menos eficaz que o fastpath e um pouco mais complexo, também pode reduzir bastante os danos causados por ataques.
−
−	~~Possuir fastpath ou fasttrack sempre que possível em roteadores Mikrotik;~~

	==== Não crie regras de firewall para tentar mitigar ataques DDoS localmente ====		==== Não crie regras de firewall para tentar mitigar ataques DDoS localmente ====

@@ Linha 45: / Linha 45: @@
 ==== 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.
+Os sistemas de detecção de ataque são os responsáveis por orquestrar toda a 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.

@@ Linha 23: / Linha 23: @@
 [[Arquivo:Ddoslooproteamento.jpg|miniaturadaimagem|centro|'''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.
+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, teria 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.

@@ Linha 19: / Linha 19: @@
 * 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:
+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 no diagrama exibido abaixo:
 [[Arquivo:Ddoslooproteamento.jpg|miniaturadaimagem|centro|'''Exemplo 2''']]