Mudanças entre as edições de "Boas praticas para cenarios de DDoS"
| (10 revisões intermediárias pelo mesmo usuário não estão sendo mostradas) | |||
| 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. | 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. | 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 19: | Linha 19: | ||
* Este ciclo se repete com cada um dos pacotes até que o TTL seja expirado, amplificando o ataque internamente. | * 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 | + | 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''']] | [[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, | + | 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 42: | Linha 46: | ||
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. | 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 ==== | ==== 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 | + | 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. | Sendo assim, tente acessar estes sistemas apenas por VPNs, endereços privados internamente ou com endereços IPv6 apenas. | ||
| Linha 52: | Linha 56: | ||
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). | 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 (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. | 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 60: | Linha 64: | ||
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. | ||
| − | |||
| − | |||
==== Não crie regras de firewall para tentar mitigar ataques DDoS localmente ==== | ==== 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. | Uma alternativa barata e eficaz para mitigar alguns ataques localmente é o uso de flowspec automatizado. | ||
| Linha 76: | Linha 78: | ||
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. | 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 | + | 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: | É importante que se tenha uma check list de itens a se testar, como: | ||
| Linha 98: | Linha 100: | ||
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. | 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 | + | 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. | 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 atual tal como às 18h20min de 30 de agosto de 2022
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 no 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, 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.
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 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
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.
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 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.
Utilize Fastpath ou Fasttrack em Mikrotiks sempre que possível
Roteadores Mikrotik que não precisam fazer funções de firewall, NAT, mangle, PBR ou queues podem utilizar o fastpath, um recurso que otimiza o encaminhamento de pacotes, aumentando grandemente o seu poder de processamento e tornando-os muito mais resilientes à travamentos devido à DDoS.
Caso o fastpath não seja possível, uma alternativa ao fastpath pode ser o 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.
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 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.
Teste as communities de blackhole periodicamente
Como explicado no artigo O Minimo que voce precisa saber sobre DDoS, possuir um trânsito IP que não suporte blackhole não deve ser uma opção. Qualquer trânsito IP que não possua este recurso, sob qualquer pretexto, não deve ser considerado como uma opção. Alguns alegam que possuir uma mitigação elimina a necessidade de se possuir uma comunidade para RTBH, e isto não é uma verdade. Considere a possibilidade de um IP que não está em uso ser atacado e a mitigação falhar, e neste caso você pode resolver o problema simplesmente anunciando o prefixo IPv4 /32 para seu upstream com a comunidade de blackhole.
Tendo dito isto, recomendamos que testem periodicamente a eficácia das blackholes com todos os fornecedores, pois segundo a Lei de Murphy, os ataques acontecerão justamente quando as blackholes de seus fornecedores não estiverem funcionando devidamente.
Faça testes de detecção e mitigação constantemente
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 com utilitários como o hping3 executados remotamente.
É importante que se tenha uma check list de itens a se testar, como:
- Tempo de detecção;
- Eficácia da blackhole;
- Eficácia da mitigação;
- Efeitos colaterais causados (falhas na abertura de página ou carregamento de conteúdos, por ex);
- Precisão da detecção;
- Quantidade de tráfego sujo vazado pela mitigação.
Além disso, após mapear os possíveis problemas num ataque, também documente contra medidas a se tomar em casos de falhas.
Confirme o número de prefixos em blackhole aceitos pelos seus upstreams
Considerando um cenário caótico, onde sua mitigação em nuvem não está operacional e um ataque de carpet bombing está a atingir toda a rede, uma opção pode ser anunciar todos os IPs que não estão em uso para a blackhole em seu fornecedor. Isto fará o ataque ser reduzido ou até cessado em alguns casos. Sendo assim, sempre confirme qual a quantidade máxima de prefixos em blackhole que pode ser aceita por seu upstream sem que tua sessão BGP seja automaticamente desligada.
Um número sugerido é 25% do total de IPs de seu ASN ou de seu cone de clientes.
Confirme o número de prefixos totais aceitos pelos seus upstreams
Em cenários de crise, você poderá ter que desviar às pressas todo seu tráfego para um caminho protegido. Sendo um ISP que não vende trânsito para outros ASNs, este número total de prefixos anunciados pode não ser grande. Sendo um ITP (provedor de trânsito), considere a possibilidade de ter que desviar centenas ou milhares de prefixos simultânea e automaticamente para um único fornecedor. Portanto, procure sempre manter um número elevado na quantidade máxima de prefixos aceitos por seus fornecedores.
Anuncie os prefixos mais específicos com community de no-export para todos seus fornecedores
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 é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.
Adotar massivamente o uso de IPv6, inclusive no DNS
Como já devem ter percebido pelo tom deste artigo, para termos eficácia contra ataques, devemos pensar sempre nos cenários mais caóticos possíveis. E, considerando estes cenários, imagine que um dia você poderá ter que parar de anunciar seus próprios blocos IPv4 e terá que navegar com outros IPs através de um NAT. Ou até mesmo terá alguns problemas de navegação durante a mitigação de seus ataques.
Tanto numa situação de um NAT geral e emergencial, quanto num problema de navegação causado por uma proteção, certamente utilizar IPv6 reduzirá muito os impactos do ataque. Todos os grandes provedores de conteúdo, como Netflix, Google e Facebook já adotam IPv6 massivamente, e estes conteúdos provavelmente estarão livres de problemas se tu também adotares massivamente o uso do IPv6 na rede.
Artigo originalmente escrito por Daniel Damito.