Mudanças entre as edições de "O Minimo que voce precisa saber sobre DDoS"
(A palavra "apenas" repetida.) |
|||
(9 revisões intermediárias por 3 usuários não estão sendo mostradas) | |||
Linha 1: | Linha 1: | ||
=== Introdução === | === Introdução === | ||
− | <u>[https://wiki.brasilpeeringforum.org/w/O_Minimo_que_voce_precisa_saber_sobre_DDoS | + | <u>[https://wiki.brasilpeeringforum.org/w/O_Minimo_que_voce_precisa_saber_sobre_DDoS#Coisas_que_voc.C3.AA_N.C3.83O_deve_fazer_para_mitigar_ataques_DoS Disclaimer: se você não estiver disposto a ler este artigo inteiro, ao menos clique aqui e leia este capítulo, que diz o que você '''NÃO''' deve fazer!]</u> |
Os ataques de negação de serviço consistem no envio massivo de pacotes não solicitados em alta volumetria contra algum dispositivo ou uma rede conectada à internet. Quando isto ocorre, a vítima do ataque tem seus recursos computacionais ou links de Internet total ou parcialmente saturados, não conseguindo processar os pacotes legítimos. Como consequência, o serviço torna-se indisponível ou degradado. | Os ataques de negação de serviço consistem no envio massivo de pacotes não solicitados em alta volumetria contra algum dispositivo ou uma rede conectada à internet. Quando isto ocorre, a vítima do ataque tem seus recursos computacionais ou links de Internet total ou parcialmente saturados, não conseguindo processar os pacotes legítimos. Como consequência, o serviço torna-se indisponível ou degradado. | ||
Linha 32: | Linha 32: | ||
=== Motivações de um ataque DoS === | === Motivações de um ataque DoS === | ||
Nem sempre é possível determinar o motivo de ser vítima de um ataque, mas algumas causas costumam ser comuns e bastante recorrentes, como: | Nem sempre é possível determinar o motivo de ser vítima de um ataque, mas algumas causas costumam ser comuns e bastante recorrentes, como: | ||
− | * '''Ação | + | * '''Ação anticompetitiva:''' muitas vezes o motivo do ataque é uma ação anticompetitiva de um concorrente de mercado, que busca indisponibilizar o serviço visando a perda de receitas da vítima ou perda de sua reputação. Durante a edição 32 do GTS foi ministrada [https://www.youtube.com/watch?v=-5fs3IOZdYA esta palestra], que explica mais sobre o assunto. |
* '''Retaliação:''' há casos onde uma vítima de DoS causado por uma amplificação dentro da tua rede entende que você o está atacando propositalmente. Nestes casos, a vítima do ataque contrata serviços de ataque contra você para se vingar do mal causado. | * '''Retaliação:''' há casos onde uma vítima de DoS causado por uma amplificação dentro da tua rede entende que você o está atacando propositalmente. Nestes casos, a vítima do ataque contrata serviços de ataque contra você para se vingar do mal causado. | ||
* '''Extorsão:''' é bastante comum empresas receberem ataques DoS e em seguida serem chantageadas a pagarem um valor, geralmente em bitcoin, para que os ataques sejam cessados. | * '''Extorsão:''' é bastante comum empresas receberem ataques DoS e em seguida serem chantageadas a pagarem um valor, geralmente em bitcoin, para que os ataques sejam cessados. | ||
Linha 44: | Linha 44: | ||
* '''Contratar serviços paralelos que não sejam de mitigação de ataques:''' existem diversos serviços de segurança de rede para sistemas autônomos. Mas a grande maioria destes serviços não tem qualquer relação com ataques. Alguns destes serviços oferecem sistemas de blacklists, onde você aprende centenas ou milhares de IPs maliciosos da Internet via BGP e deixa de enviar pacotes para estes endereços. Entenda que ataques de negação de serviço não dependem de (a) você responder ou não aos pacotes maliciosos ou (b) ter o IP em uso em sua rede. Ou seja, estes serviços de blacklists evitam que a comunicação dos IPs maliciosos em sua rede não seja bidirecional, evitando spams, bruteforces ou invasões à devices, <u>mas não evitam ataques de negação de serviço.</u> | * '''Contratar serviços paralelos que não sejam de mitigação de ataques:''' existem diversos serviços de segurança de rede para sistemas autônomos. Mas a grande maioria destes serviços não tem qualquer relação com ataques. Alguns destes serviços oferecem sistemas de blacklists, onde você aprende centenas ou milhares de IPs maliciosos da Internet via BGP e deixa de enviar pacotes para estes endereços. Entenda que ataques de negação de serviço não dependem de (a) você responder ou não aos pacotes maliciosos ou (b) ter o IP em uso em sua rede. Ou seja, estes serviços de blacklists evitam que a comunicação dos IPs maliciosos em sua rede não seja bidirecional, evitando spams, bruteforces ou invasões à devices, <u>mas não evitam ataques de negação de serviço.</u> | ||
* '''Se vingar do suposto atacante:''' por mais que você desconfie ou tenha fortes evidências de quem está te atacando, tome nenhuma atitude contra esta empresa ou pessoa sem que tenha certeza absoluta de que ela é a culpada. Existem casos onde é montado um grande teatro para te fazer crer que o culpado de seus ataques é uma pessoa inocente, e nestes casos você irá iniciar uma guerra cibernética desnecessariamente. | * '''Se vingar do suposto atacante:''' por mais que você desconfie ou tenha fortes evidências de quem está te atacando, tome nenhuma atitude contra esta empresa ou pessoa sem que tenha certeza absoluta de que ela é a culpada. Existem casos onde é montado um grande teatro para te fazer crer que o culpado de seus ataques é uma pessoa inocente, e nestes casos você irá iniciar uma guerra cibernética desnecessariamente. | ||
+ | * '''Pagar ao atacante para parar de receber ataques:''' quando você paga para o ofensor cessar seus ataques, está sinalizando à ele que você é uma fonte de renda fácil. Por ser uma prática criminosa, obviamente não existem garantias de que você não voltará a receber novos ataques após realizar este pagamento. Além disso, você também ajudará o mercado dos crimes cibernéticos a crescer, o que também te afetará. | ||
=== O que fazer para se prevenir e/ou mitigar ataques DoS === | === O que fazer para se prevenir e/ou mitigar ataques DoS === | ||
Linha 53: | Linha 54: | ||
* '''Apenas contrate upstreams que possuam suporte à blackhole:''' jamais contrate um fornecedor de link IP que não tenha suporte funcional à communities de blackhole. Caso seus upstreams atuais não tenham, sinto-lhe em dizer que você está fadado à sucumbir no primeiro ataque que receber. | * '''Apenas contrate upstreams que possuam suporte à blackhole:''' jamais contrate um fornecedor de link IP que não tenha suporte funcional à communities de blackhole. Caso seus upstreams atuais não tenham, sinto-lhe em dizer que você está fadado à sucumbir no primeiro ataque que receber. | ||
− | * '''Mantenha o IPv6 em dia:''' durante um ataque severo em IPv4, a única alternativa para continuar operando pode ser deixar de anunciar | + | * '''Mantenha o IPv6 em dia:''' durante um ataque severo em IPv4, a única alternativa para continuar operando pode ser deixar de anunciar alguns de seus blocos IPv4 para a Internet e mantê-lo apenas para Peerings privados e CDNs. O impacto na navegação de centenas de usuários será grande, obviamente, mas tendo IPv6 trabalhando em paralelo com o IPv4 diminuirá bastante as queixas de problemas. |
* '''Tenha um sistema de blackhole automatizado:''' tenha um sistema de blackhole automatizado, como Wanguard ou Fastnetmon, que analisa o tráfego de sua rede constantemente e anuncia os IPs sob ataque para a blackhole de seus upstreams. Caso você não possua isso de forma automatizada, o seu tempo de reação pode ser demasiadamente alto, fazendo até com que você não consiga acessar o equipamento para realizar esta ação manualmente. | * '''Tenha um sistema de blackhole automatizado:''' tenha um sistema de blackhole automatizado, como Wanguard ou Fastnetmon, que analisa o tráfego de sua rede constantemente e anuncia os IPs sob ataque para a blackhole de seus upstreams. Caso você não possua isso de forma automatizada, o seu tempo de reação pode ser demasiadamente alto, fazendo até com que você não consiga acessar o equipamento para realizar esta ação manualmente. | ||
* '''Mantenha uma boa relação com seus concorrentes:''' seus concorrentes não devem ser seus inimigos. Você deve se esforçar para manter uma boa relação com eles, inclusive parcerias se possível. Tendo uma boa relação e deixando claro que sua intenção não é prejudicá-los, você certamente diminuirá as chances de receber um ataque por ações anticompetitivas. | * '''Mantenha uma boa relação com seus concorrentes:''' seus concorrentes não devem ser seus inimigos. Você deve se esforçar para manter uma boa relação com eles, inclusive parcerias se possível. Tendo uma boa relação e deixando claro que sua intenção não é prejudicá-los, você certamente diminuirá as chances de receber um ataque por ações anticompetitivas. | ||
Linha 59: | Linha 60: | ||
# O que fazer quando o IP de um assinante for atacado e estiver em blackhole? Trocar seu IP ou deixá-lo indisponível por um tempo? Se a resposta for trocar seu IP, quais IPs serão usados para este fim? | # O que fazer quando o IP de um assinante for atacado e estiver em blackhole? Trocar seu IP ou deixá-lo indisponível por um tempo? Se a resposta for trocar seu IP, quais IPs serão usados para este fim? | ||
# O que fazer se o IP de todos os seus DNS's ficarem indisponíveis? Existe outro DNS não divulgado, mas pronto e configurado, reservado para esta finalidade? | # O que fazer se o IP de todos os seus DNS's ficarem indisponíveis? Existe outro DNS não divulgado, mas pronto e configurado, reservado para esta finalidade? | ||
− | # Caso | + | # Caso um bloco inteiro seja atacado e você anuncie eles para a blackhole, terminará de concretizar o ataque. Você possui outros IPs fora do alvo do ataque para contingência? Utilizará um NAT com estes outros blocos para navegação na Internet? E os serviços que precisam ser acessados externamente: eles possuem IPv6? |
− | # Se você possuir um | + | # Se você possuir um serviço de mitigação em nuvem, quais são os limites de ataque e banda limpa contratados? Se este limite exceder, você pode operar no regime de 95 percentile? Estas perguntas são apenas alguns exemplos, mas devem ser adaptadas à sua organização, levando em conta sua capacidade e peculiaridades. Recomendamos que isto seja devidamente documentado internamente e que todos os responsáveis pelo NOC saibam como operar durante uma situação de crise. |
* '''Teste periodicamente suas medidas de contingência:''' por mais que você tenha feito um plano de contingência, testado e validado seu funcionamento, você precisa testá-lo recorrentemente e corrigir eventuais falhas se necessário. Um upstream pode mudar sua community de blackhole, deixar de prover este recurso ou algum software de detecção automática pode deixar de funcionar sem que você saiba. Portanto, não é necessário apenas construir o plano, mas também testá-lo periodicamente. | * '''Teste periodicamente suas medidas de contingência:''' por mais que você tenha feito um plano de contingência, testado e validado seu funcionamento, você precisa testá-lo recorrentemente e corrigir eventuais falhas se necessário. Um upstream pode mudar sua community de blackhole, deixar de prover este recurso ou algum software de detecção automática pode deixar de funcionar sem que você saiba. Portanto, não é necessário apenas construir o plano, mas também testá-lo periodicamente. | ||
− | * '''Entenda que ataques causam efeitos colaterais, mesmo se mitigados:''' todo ataque de negação de serviço, ainda que mitigado, causará efeitos colaterais em sua rede. Estes efeitos colaterais podem variar em tipo ou intensidade, mas quase sempre acontecerão. Quanto melhor for o teu plano de contingência, mais você saberá lidar com estes efeitos colaterais ou contorná-los. | + | * '''Acionar a justiça e autoridades policiais:''' a grande maioria das empresas não toma nenhuma atitude no âmbito jurídico, trazendo uma grande sensação de impunidade para os atacantes. Recomendamos que sempre que for alvo de um ataque, contate um advogado e façam uma notícia crime. Baseado nisto, existe a possibilidade de que casos correlatos sejam associados e um criminoso seja encontrado ou ao menos investigado. Como podemos ver [https://www.youtube.com/watch?v=0z9bCEzi-JE&feature=youtu.be&t=28565 neste vídeo], a polícia federal sequer fica sabendo dos ataques que acontecem. |
+ | * '''Entenda que ataques causam efeitos colaterais, mesmo se mitigados:''' todo ataque de negação de serviço, ainda que mitigado, causará efeitos colaterais em sua rede. Estes efeitos colaterais podem variar em tipo ou intensidade, mas quase sempre acontecerão. Um dos mais comuns é o aumento de latência ou perda de pacotes. Quanto melhor for o teu plano de contingência, mais você saberá lidar com estes efeitos colaterais ou contorná-los. | ||
=== Não seja você a origem de um ataque === | === Não seja você a origem de um ataque === | ||
− | A grande maioria dos ataques são causados por amplificação, reflexão, spoofing ou as três coisas juntas. Estes ataques apenas acontecem | + | A grande maioria dos ataques são causados por amplificação, reflexão, spoofing ou as três coisas juntas. Estes ataques apenas acontecem porque outras entidades na Internet não fizeram o seu dever de casa e permitiram que isto acontecesse. |
Para que você não seja a '''origem''' de um ataque, é necessário que você: | Para que você não seja a '''origem''' de um ataque, é necessário que você: | ||
Linha 81: | Linha 83: | ||
Artigo originalmente escrito por [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito]. | Artigo originalmente escrito por [https://wiki.brasilpeeringforum.org/w/Usu%C3%A1rio:Daniel_Damito Daniel Damito]. | ||
− | + | [[Categoria:Roteamento]] | |
− | [[Categoria: |
Edição atual tal como às 10h36min de 5 de junho de 2024
Introdução
Os ataques de negação de serviço consistem no envio massivo de pacotes não solicitados em alta volumetria contra algum dispositivo ou uma rede conectada à internet. Quando isto ocorre, a vítima do ataque tem seus recursos computacionais ou links de Internet total ou parcialmente saturados, não conseguindo processar os pacotes legítimos. Como consequência, o serviço torna-se indisponível ou degradado.
Como analogia, imaginemos uma festa cujo local do evento comporta apenas algumas dezenas de pessoas, sendo invadida por centenas de impostores. Naturalmente, caso nenhuma ação seja tomada, o salão em pouco tempo estará totalmente lotado por pessoas não autorizadas e não haverá mais espaço para que pessoas autorizadas possam adentrar. Uma possível solução para este problema poderia ser a contratação de seguranças devidamente capacitados para discernir pessoas autorizadas de impostores. Com esta contramedida, hipoteticamente poderíamos ter alguns resultados:
- Sucesso: Os seguranças conseguem filtrar rapidamente o ingresso das pessoas ao recinto, permitindo que o espaço fique livre para receber apenas as pessoas autorizadas;
- Sucesso com pequena degradação no serviço: O número de impostores é muito maior do que o número de convidados para a festa. Desta forma, devido ao número limitado ou pequeno de seguranças, as pessoas autorizadas precisam aguardar um tempo anormal para adentrar à festa, enquanto os seguranças checam cada um dos candidatos à ingressar ao evento;
- Falha devido ao exaurimento da capacidade da equipe de segurança: Sendo o número de seguranças insuficiente para a checagem de todos as pessoas aguardando para entrar à festa, é possível que hajam falhas no processo de identificação e impostores tomem os espaços que deviam ser reservados para convidados;
- Falha por congestionamento nas entradas: Considerando que as entradas do evento suportem apenas dez pessoas transitando simultaneamente ao total, se dez ou mais impostores tentarem invadir a festa ao mesmo tempo, o número ou a capacidade dos seguranças não fará diferença. Por mais numerosos e por mais ágeis que sejam, os seguranças não poderão evitar que os impostores congestionem totalmente as entradas do evento, impedindo que os convidados consigam entrar no salão de festas.
Essa analogia representa justamente alguns cenários possíveis de ataques de negação de serviço e algumas contramedidas e seus resultados.
Para facilitar a compreensão:
- A festa em em si representa a vítima do ataque de negação de serviço;
- Os seguranças representam sistemas de mitigação de ataques ou firewalls;
- A entrada da festa representa a capacidade de link que a empresa vítima do ataque possui.
Esta foi uma forma simples de exemplificar que nem todos os ataques DoS podem ser mitigados localmente sem que haja uma grande infraestrutura preparada para receber estes tipos de ataques.
Diferenças entre DoS e DDoS
Ataques de negação de serviço podem ser efetuados através de uma única origem (DoS) ou através de múltiplas origens (DDoS). Na maioria dos cenários, a contramedida e as defesas contra estes ataques são as mesmas, independente se é um DoS ou um DDoS.
Para facilitar a leitura deste artigo, aqui trataremos todos os ataques, sejam distribuítos (DDoS) ou de origens únicas (DoS) como apenas DoS.
Efeitos de um ataque de negação de serviço
Os ataques de negação de serviço podem basicamente surtir dois efeitos:
- Exaurimento de recursos computacionais: quando o ataque é tão grande que os equipamentos da rede, como roteadores e switchs, não são capazes de processá-los, apresentando gargalos ou mau funcionamento.
- Exaurimento da capacidade dos links de Internet: quando o ataque, somado à quantidade banda limpa, é maior do que a quantidade de link contratado pela empresa.
Motivações de um ataque DoS
Nem sempre é possível determinar o motivo de ser vítima de um ataque, mas algumas causas costumam ser comuns e bastante recorrentes, como:
- Ação anticompetitiva: muitas vezes o motivo do ataque é uma ação anticompetitiva de um concorrente de mercado, que busca indisponibilizar o serviço visando a perda de receitas da vítima ou perda de sua reputação. Durante a edição 32 do GTS foi ministrada esta palestra, que explica mais sobre o assunto.
- Retaliação: há casos onde uma vítima de DoS causado por uma amplificação dentro da tua rede entende que você o está atacando propositalmente. Nestes casos, a vítima do ataque contrata serviços de ataque contra você para se vingar do mal causado.
- Extorsão: é bastante comum empresas receberem ataques DoS e em seguida serem chantageadas a pagarem um valor, geralmente em bitcoin, para que os ataques sejam cessados.
- Rivalidade entre gamers: um outro motivo recorrente de ataques é contra servidores de jogos hospedados na empresa. Estes ataques geralmente não têm como destino necessariamente a empresa hospedeira, mas seu objetivo final é indisponibilizar o servidor de jogos. As vezes a empresa toda pode ser atacada quando não há sucesso no ataque direto ao servidor do jogo. Também não é raro encontrarmos casos onde toda a infraestrutura de um ISP é lesada por um ataque apenas com o objetivo de deixar um único jogador fora da Internet.
- Vingança pessoal: alguns ataques têm como alvo uma pessoa da organização, não a empresa em si. Estes ataques podem ter motivos diversos, como separação de sociedades, pleitos jurídicos e discussões em redes sociais.
- Testes contra sua infraestrutura: uma pessoa ou entidade interessada em saber a resiliência de sua rede pode usar ferramentas de ataque contra sua infraestrutura apenas para testar sua capacidade de reação contra estes ataques.
- Testes de ferramentas de ataque: há casos onde a vítima do ataque foi escolhida aleatoriamente apenas para validar o funcionamento de uma ferramenta de ataques.
Coisas que você NÃO deve fazer para mitigar ataques DoS
- Pedir cotação de diversas empresas de mitigação em nuvem: antes de buscar uma empresa que faça mitigação em núvem, pesquise quem são seus upstreams, seus peerings, downstreams, pontos de conexão, e o principal: sua reputação. Para saber sobre a reputação e confiabilidade de uma empresa, faça buscas ou questione em listas de emails como GTER e BPF, grupos de comunidades técnicas no Whatsapp e Telegram e contate clientes e ex clientes desta empresa pedindo referências. De preferência, faça este processo de forma anônima para evitar eventuais retaliações. Ao menor sinal de dúvida sobre a reputação da empresa candidata a ser contratada, não peça sequer uma cotação.
- Contratar serviços paralelos que não sejam de mitigação de ataques: existem diversos serviços de segurança de rede para sistemas autônomos. Mas a grande maioria destes serviços não tem qualquer relação com ataques. Alguns destes serviços oferecem sistemas de blacklists, onde você aprende centenas ou milhares de IPs maliciosos da Internet via BGP e deixa de enviar pacotes para estes endereços. Entenda que ataques de negação de serviço não dependem de (a) você responder ou não aos pacotes maliciosos ou (b) ter o IP em uso em sua rede. Ou seja, estes serviços de blacklists evitam que a comunicação dos IPs maliciosos em sua rede não seja bidirecional, evitando spams, bruteforces ou invasões à devices, mas não evitam ataques de negação de serviço.
- Se vingar do suposto atacante: por mais que você desconfie ou tenha fortes evidências de quem está te atacando, tome nenhuma atitude contra esta empresa ou pessoa sem que tenha certeza absoluta de que ela é a culpada. Existem casos onde é montado um grande teatro para te fazer crer que o culpado de seus ataques é uma pessoa inocente, e nestes casos você irá iniciar uma guerra cibernética desnecessariamente.
- Pagar ao atacante para parar de receber ataques: quando você paga para o ofensor cessar seus ataques, está sinalizando à ele que você é uma fonte de renda fácil. Por ser uma prática criminosa, obviamente não existem garantias de que você não voltará a receber novos ataques após realizar este pagamento. Além disso, você também ajudará o mercado dos crimes cibernéticos a crescer, o que também te afetará.
O que fazer para se prevenir e/ou mitigar ataques DoS
Primeiramente eu gostaria de deixar claro o significado da palavra mitigação:
mitigação substantivo feminino
ação, processo de mitigar; aliviamento.
efeito de mitigar; alívio, lenitivo.
Origem
⊙ ETIM lat. mitigatĭo,ōnis 'ação de aliviar'
Com isto quero dizer que a mitigação de um ataque pode não significar necessariamente cessá-lo ou zerar seus efeitos colaterais, mas sim reduzir os impactos causados.
- Apenas contrate upstreams que possuam suporte à blackhole: jamais contrate um fornecedor de link IP que não tenha suporte funcional à communities de blackhole. Caso seus upstreams atuais não tenham, sinto-lhe em dizer que você está fadado à sucumbir no primeiro ataque que receber.
- Mantenha o IPv6 em dia: durante um ataque severo em IPv4, a única alternativa para continuar operando pode ser deixar de anunciar alguns de seus blocos IPv4 para a Internet e mantê-lo apenas para Peerings privados e CDNs. O impacto na navegação de centenas de usuários será grande, obviamente, mas tendo IPv6 trabalhando em paralelo com o IPv4 diminuirá bastante as queixas de problemas.
- Tenha um sistema de blackhole automatizado: tenha um sistema de blackhole automatizado, como Wanguard ou Fastnetmon, que analisa o tráfego de sua rede constantemente e anuncia os IPs sob ataque para a blackhole de seus upstreams. Caso você não possua isso de forma automatizada, o seu tempo de reação pode ser demasiadamente alto, fazendo até com que você não consiga acessar o equipamento para realizar esta ação manualmente.
- Mantenha uma boa relação com seus concorrentes: seus concorrentes não devem ser seus inimigos. Você deve se esforçar para manter uma boa relação com eles, inclusive parcerias se possível. Tendo uma boa relação e deixando claro que sua intenção não é prejudicá-los, você certamente diminuirá as chances de receber um ataque por ações anticompetitivas.
- Possua um plano de contingência: para não ser pego totalmente de surpresa, você precisa ter um plano de contingência contra ataques. E para isso, algumas perguntas precisam ser respondidas e estar bem documentadas, como:
- O que fazer quando o IP de um assinante for atacado e estiver em blackhole? Trocar seu IP ou deixá-lo indisponível por um tempo? Se a resposta for trocar seu IP, quais IPs serão usados para este fim?
- O que fazer se o IP de todos os seus DNS's ficarem indisponíveis? Existe outro DNS não divulgado, mas pronto e configurado, reservado para esta finalidade?
- Caso um bloco inteiro seja atacado e você anuncie eles para a blackhole, terminará de concretizar o ataque. Você possui outros IPs fora do alvo do ataque para contingência? Utilizará um NAT com estes outros blocos para navegação na Internet? E os serviços que precisam ser acessados externamente: eles possuem IPv6?
- Se você possuir um serviço de mitigação em nuvem, quais são os limites de ataque e banda limpa contratados? Se este limite exceder, você pode operar no regime de 95 percentile? Estas perguntas são apenas alguns exemplos, mas devem ser adaptadas à sua organização, levando em conta sua capacidade e peculiaridades. Recomendamos que isto seja devidamente documentado internamente e que todos os responsáveis pelo NOC saibam como operar durante uma situação de crise.
- Teste periodicamente suas medidas de contingência: por mais que você tenha feito um plano de contingência, testado e validado seu funcionamento, você precisa testá-lo recorrentemente e corrigir eventuais falhas se necessário. Um upstream pode mudar sua community de blackhole, deixar de prover este recurso ou algum software de detecção automática pode deixar de funcionar sem que você saiba. Portanto, não é necessário apenas construir o plano, mas também testá-lo periodicamente.
- Acionar a justiça e autoridades policiais: a grande maioria das empresas não toma nenhuma atitude no âmbito jurídico, trazendo uma grande sensação de impunidade para os atacantes. Recomendamos que sempre que for alvo de um ataque, contate um advogado e façam uma notícia crime. Baseado nisto, existe a possibilidade de que casos correlatos sejam associados e um criminoso seja encontrado ou ao menos investigado. Como podemos ver neste vídeo, a polícia federal sequer fica sabendo dos ataques que acontecem.
- Entenda que ataques causam efeitos colaterais, mesmo se mitigados: todo ataque de negação de serviço, ainda que mitigado, causará efeitos colaterais em sua rede. Estes efeitos colaterais podem variar em tipo ou intensidade, mas quase sempre acontecerão. Um dos mais comuns é o aumento de latência ou perda de pacotes. Quanto melhor for o teu plano de contingência, mais você saberá lidar com estes efeitos colaterais ou contorná-los.
Não seja você a origem de um ataque
A grande maioria dos ataques são causados por amplificação, reflexão, spoofing ou as três coisas juntas. Estes ataques apenas acontecem porque outras entidades na Internet não fizeram o seu dever de casa e permitiram que isto acontecesse.
Para que você não seja a origem de um ataque, é necessário que você:
- Possua filtros antispoofing em sua rede;
- Mantenha seus serviços, como DNS, NTP, SNMP e outros, devidamente configurados e respondendo apenas à sua rede;
- Adira ao MANRS, seguindo esta documentação, para que a segurança de sua rede seja validada externamente por outras pessoas;
- Siga as boas práticas de segurança padrão recomendadas pela comunidade da Internet. Este artigo e também este podem te ajudar com isto.
Lembre-se que se você não seguir as instruções acima, além de estar sujando a reputação de sua empresa publicamente e prejudicando outras organizações, também se prejudicará com a alta taxa de upload e pacotes por segundo em sua própria rede.
Resumo de alguns pontos importantes
- Se o ataque recebido for maior que seus links, não adianta tentar limpar o tráfego internamente;
- Rotas recebidas e inseridas em uma blacklist ou blackhole de sua rede não farão com que um ataque DoS deixe de entrar em sua rede;
- Não contrate soluções de mitigação desesperadamente. Pesquise sobre a empresa antes de solicitar cotações;
- Siga as boas práticas para não originar ataques em sua rede.
Artigo originalmente escrito por Daniel Damito.