Uma empresa de jogos quase demitiu sua operadora. O sistema de proteção contra DDoS não foi suficiente.

Um caso real sobre a diferença entre possuir um dispositivo de mitigação e operar um serviço de DDoS.

‍

‍

Uma empresa de jogos móveis comprou trânsito IP com proteção contra DDoS de uma grande operadora na Ásia. A operadora havia implementado um Sistema de Mitigação de Tráfego líder de mercado. O serviço foi vendido como protegido, o equipamento de mitigação estava instalado e todos tinham motivos para acreditar que o risco estava coberto.

‍

Então, mais de 10 Gbps de tráfego de ataque passaram, saturaram o link da empresa de jogos e interromperam seu serviço. O cliente ameaçou cancelar o serviço de trânsito protegido da operadora.

‍

‍A operadora tinha proteção contra DDoS. O que ela não tinha, no momento crucial, era uma proteção que funcionasse.

‍

Nós vendemos proteção contra DDoS, então leia o restante com a devida desconfiança. Esta não é uma história sobre um fornecedor ser incapaz de mitigar e outro ser infalível. É uma história sobre um erro que nosso setor continua cometendo: tratar um dispositivo de DDoS como se fosse um serviço completo de DDoS.

‍

Nenhum engenheiro sério promete que nada dará errado

"100% de disponibilidade" fica bem em um slide. Engenheiros que operam redes reais sabem o quão frágil essa promessa se torna quando encontra mudanças de roteamento, defeitos de software, erros de configuração, padrões de ataque inéditos e decisões humanas comuns tomadas sob pressão.

‍

A proteção contra DDoS tem o mesmo problema. Não pode significar honestamente que todo ataque será sempre bloqueado perfeitamente, que o tráfego legítimo nunca será afetado ou que a primeira política de mitigação será correta para sempre. Os ataques mudam. O tráfego do cliente muda. Às vezes, a própria mitigação cria um problema.

‍

Um padrão mais honesto
Você está preparado para detectar o ataque, gerenciá-lo, recuperar-se quando algo der errado, adaptar os controles e mitigar o próximo evento de forma mais eficaz?

‍

Isso é menos reconfortante do que uma promessa de 100%. Também é mais próximo de como sistemas confiáveis são realmente construídos. Este incidente é um bom exemplo, porque nenhum dos lados parece infalível.

‍

O cliente comprou um resultado, não um dispositivo de mitigação

A operadora era uma das três empresas de telecomunicações incumbentes do país. Seu cliente final operava serviços de jogos móveis, onde a interrupção não é um evento abstrato de SLA. Os jogadores percebem a latência e as desconexões imediatamente, e não se importam com qual logotipo de fornecedor aparece no diagrama de rede da operadora.

‍

O serviço de trânsito protegido existente dependia de uma plataforma de DDoS líder de mercado e bem conhecida. De acordo com o engenheiro de pré-vendas da Nexusguard envolvido na conta, a implementação encontrou três limites práticos.

‍

‍

Estas foram limitações encontradas nesta implementação, não uma afirmação de que toda instalação do fornecedor incumbente não mencionado se comporta da mesma forma. O blackholing pode proteger o restante de uma rede, mas "protege" o alvo tornando-o inacessível. Isso pode ser um controle de emergência válido. Não é o resultado que uma empresa de jogos acredita ter comprado quando paga por trânsito protegido.

‍

Um produto forte ainda pode se tornar um serviço fraco quando ninguém é responsável pelo resultado.

‍

Nós também não acertamos tudo na primeira tentativa

A Nexusguard propôs uma prova de conceito em produção real com duração de duas semanas. Não foi uma demonstração de laboratório com tráfego gerado e uma condição de sucesso cuidadosamente preparada. O tráfego de produção em cinco prefixos foi direcionado para o nosso serviço Clean Pipe com a mitigação ativada.

‍

Durante um teste inicial de mitigação, um loop de roteamento tornou um host inacessível. Em um evento posterior de 15 Gbps, o policiamento de tráfego produziu um resultado inaceitável e exigiu ajustes adicionais. Esses incidentes ocorreram antes que a prova de conceito fosse entregue ao SOC para gerenciamento operacional completo.

‍

Por que incluir nossas próprias dificuldades?
Porque a afirmação defensável não é que nossa primeira política nunca possa estar errada. É que o serviço incluía pessoas responsáveis por reconhecer um resultado ruim, corrigi-lo e observar o que acontecia em seguida.

‍

Após a transferência para o SOC, a equipe manteve a linha de base inicial e a configuração predefinida sob revisão. Ajustou medidas de anti-spoofing, retransmissão, protocolo e controle de acesso contra o tráfego de ataque que estava observando. Onde as políticas corriam o risco de descartar tráfego legítimo, a equipe as ajustou. Onde os padrões de ataque passavam, a equipe adaptou a filtragem. Os limites de taxa permaneceram como um último recurso, em vez de serem a estratégia completa.

‍

‍

É assim que se parece a mitigação em produção. Se a proposta de um fornecedor não deixa espaço para esse ciclo, ele provavelmente está descrevendo uma demonstração, e não um serviço operacional.

‍

O que mudou após a migração do tráfego de produção

A operadora migrou cinco prefixos de produção ativos para a Nexusguard. O caminho de mitigação Clean Pipe permaneceu ativado, de modo que o tráfego já passava pela mitigação em vez de aguardar um desvio no momento do ataque. O SOC monitorou os eventos, ajustou os perfis e manteve contato com a operadora conforme os ataques se desenvolviam.

‍

Em uma semana, um prefixo particularmente ativo foi alvo de ataques de 60 Gbps e 80 Gbps. O serviço da empresa de jogos não foi afetado. Em alguns eventos, a plataforma detectou e mitigou o ataque antes mesmo que o cliente percebesse que ele estava ocorrendo.

‍

O cliente não cancelou o serviço de trânsito IP com proteção DDoS da operadora. Tanto a operadora quanto seu cliente de jogos ficaram satisfeitos com o resultado, embora não haja um depoimento aprovado pelo cliente — e eu não vou inventar um para ter um final mais elegante.

‍

O que transformou um equipamento em um serviço

‍

Visibilidade não é mitigação, e não estou afirmando que a empresa de jogos utilizou todas as telas do portal. Mas, uma vez que a mitigação funciona, a visibilidade é a forma como um provedor de serviços comprova seu valor e reconstrói a confiança.

‍

O ataque de 80 Gbps não foi a verdadeira lição

Oitenta gigabits por segundo rendem uma boa manchete. Isso demonstra que o serviço de produção lidou com um ataque sério, mas a capacidade, por si só, nunca foi o problema central.

‍

O serviço anterior falhou quando mais de 10 Gbps atingiram e saturaram o link do cliente. Um ataque menor que consegue passar pode causar mais danos do que um ataque maior que é removido de forma limpa. Compradores que comparam apenas a capacidade de scrubbing anunciada estão medindo o tamanho do corpo de bombeiros, e não se a água chega ao seu prédio.

‍

Uma caixa de DDoS é um ativo.
A proteção contra DDoS é uma capacidade operacional.

‍

Um serviço completo exige quatro elementos trabalhando em conjunto: um caminho de mitigação que interrompa o tráfego malicioso antes do link protegido, políticas ajustadas ao comportamento real do cliente, operadores que monitorem e façam ajustes, e evidências que expliquem o resultado.

‍

O que perguntar à sua operadora ou provedor de DDoS

Não pergunte apenas qual fornecedor eles utilizam ou quantos terabits a plataforma deles consegue absorver. Faça perguntas que revelem como o serviço se comporta no seu pior dia.

‍

‍

Se as respostas forem vagas, a palavra "protegido" no seu contrato de trânsito pode estar fazendo mais esforço do que a proteção em si.

‍

Proteção é como você responde quando a proteção é imperfeita

A empresa de jogos neste incidente não se importava se a operadora possuía um dispositivo de mitigação famoso. O que importava era que um serviço vendido como protegido ainda permitia que o tráfego de ataque saturasse seu link.

‍

A Nexusguard não restaurou a confiança prometendo que nada daria errado. Tivemos nossas próprias dificuldades iniciais de POC. A confiança retornou porque o serviço de produção foi monitorado, corrigido, ajustado e, em seguida, testado novamente por ataques reais que atingiram picos de 80 Gbps.

‍

Esse é o padrão que os compradores devem exigir. Não proteção contra 100% dos ataques. Não uma promessa fictícia de perfeição permanente. Prontidão para gerenciar, recuperar, adaptar e mitigar de forma eficaz quando o ataque — ou a primeira resposta a ele — faz algo que você não esperava.

‍

Para que conste, esse é o padrão que você deve aplicar à Nexusguard também. Faça-nos as mesmas perguntas. Exija que expliquemos o que nossa proteção faz, o que ela não faz, quem a opera e como respondemos quando a primeira resposta não é boa o suficiente.

‍

O fornecedor em quem você pode confiar não é aquele que promete que nada dará errado. É aquele que está preparado para lhe mostrar o que acontece quando algo dá.

‍

Perguntas frequentes

O que é trânsito IP com proteção contra DDoS?

O trânsito IP com proteção contra DDoS combina conectividade com a internet e recursos de detecção e mitigação destinados a interromper o tráfego malicioso antes que ele sobrecarregue a conexão do cliente. As questões importantes são onde a filtragem ocorre, como o tráfego é desviado ou mantido no caminho e qual tráfego ainda pode chegar ao link a jusante.

‍

Por que um link com proteção contra DDoS ainda pode ser saturado?

Uma quantidade suficiente de tráfego malicioso ainda pode atingir o gargalo devido a limites de detecção, cobertura incompleta de políticas, comportamento de desvio, limites de taxa, decisões de blackholing ou vazamento de ataques. A causa depende do projeto e do incidente; a presença de um dispositivo de mitigação por si só não garante que o link protegido permanecerá utilizável.

‍

A mitigação sempre ativa é melhor do que a mitigação sob demanda?

A mitigação sempre ativa elimina o atraso envolvido no desvio do tráfego após a detecção, mas introduz suas próprias considerações de roteamento, latência, ajuste e custo. Projetos sob demanda podem reduzir o impacto no caminho normal do tráfego, mas dependem de detecção e desvio oportunos. A escolha certa depende da rede, do risco e do modelo operacional do cliente.

‍

O que uma operadora deve fornecer além de um dispositivo de proteção contra DDoS?

Um serviço completo deve incluir estabelecimento de linha de base de tráfego, monitoramento contínuo, responsabilidade pela mitigação em tempo real, otimização de políticas, comunicação durante incidentes, evidências pós-evento e pessoas responsáveis pelo resultado. O dispositivo é importante, mas não pode realizar o trabalho organizacional em torno dele.