Hoje eu quero inverter a lógica.
Em vez de falar sobre como mitigar um ataque que chega até a sua rede, vamos falar sobre um cenário que está ficando cada vez mais comum — e bem mais perigoso do que parece: quando a rede do provedor vira a origem do ataque contra terceiros.
Isso não é só “problema dos outros”. É reputação, é relação com upstream, é estabilidade da sua operação e, no fim, é a internet ficando mais hostil para todo mundo.
Um caso real que acendeu o alerta
Há algumas semanas, passou pela rede da OpenX um volume que chamou atenção: mais de 550 GB de tráfego originado por clientes, indo para um único ASN — de uma empresa de mitigação ligada a servidores de Minecraft.
E isso é o tipo de coisa que muda a percepção do problema.
Porque se a gente viu 550 GB passando pelo nosso lado, a pergunta é inevitável: quanto tráfego foi gerado antes disso, dentro da rede do provedor? Quanto disso saturou PON? Quanto estrangulou uplinks regionais? Quanto impacto já tinha acontecido antes de “aparecer” no gráfico que você costuma olhar?
Ataque originado dentro da rede é especialmente cruel porque o estrago vem antes do trânsito sair do seu AS.
O primeiro dever de casa: anti-spoofing (sem desculpa)
Se você não tem certeza se sua rede bloqueia spoofing, esse é o ponto mais urgente.
Boa parte dos ataques devastadores ainda depende de amplificação: o atacante forja pacotes com o IP de origem da vítima, dispara consultas para serviços amplificadores (DNS, NTP, SNMP e outros) e a resposta amplificada vai direto para quem ele quer derrubar.
Se pacotes forjados conseguem sair do seu AS, você vira uma peça importante na cadeia.
O básico aqui é simples: não pode sair da sua rede pacote com IP de origem que não pertence ao seu ASN.
URPF: aplique no cliente, mas não só no cliente
Uma medida muito efetiva é ativar uRPF (Unicast Reverse Path Forwarding) no concentrador (PPPoE/IPoE), garantindo que o assinante só consiga enviar tráfego com o IP que realmente está alocado para ele naquela interface.
Mas não pare aí.
Se um servidor seu for comprometido (DMZ, DNS, RADIUS, etc.), ele também pode gerar tráfego forjado “de dentro”. Então uRPF e controles de origem também precisam existir nas bordas internas, nos pontos onde isso pode nascer.
Não ignore sinal de fumaça: upload alto em provedor de acesso é alerta vermelho
Em rede de acesso, o padrão é claro: consumo mais alto no sentido do download, upload bem menor.
Se de repente você vê pico de upload, isso não é “curiosidade estatística”. É incidente até provar o contrário.
A forma prática de investigar é seguir o caminho:
- apareceu em direção à operadora? ao IX?
- em qual interface exatamente?
- qual cidade/concentrador?
- quais clientes estão gerando?
Hoje tem provedor entregando 1 Gb para assinante. Um único cliente, com um equipamento comprometido, consegue gerar um volume devastador de pacotes por segundo. Quando você identifica a origem, muitas vezes não tem alternativa: é investigação de campo e troca de equipamento o quanto antes.
O vilão comum: CPE exposta e mal protegida
Um padrão que vem se repetindo é CPE/roteador de assinante vulnerável ou simplesmente exposto à internet.
Às vezes a CPE nem precisa “ter um zero-day”: basta estar acessível e mal protegida. Invadir e instalar algo que entra numa botnet pode ser trivial.
O mínimo aqui é garantir que a gerência da CPE só seja acessível a partir da sua rede de gestão. ACL bem feita, sem “liberar para o mundo porque eu preciso acessar viajando”.
Se o argumento é acesso remoto: existe forma segura de fazer isso (ex.: um ponto único confiável com IP fixo e controlado), sem deixar o equipamento do assinante aberto.
Um indício clássico de CPE comprometida: você entra e percebe que o DNS foi trocado para algo que não é o padrão da sua operação. Se isso aconteceu, trate como comprometimento.
Amplificadores na sua rede: descubra antes que virem arma
Outra disciplina importante é ter visibilidade sobre potenciais amplificadores dentro do seu AS.
Às vezes é algo bobo: alguém subiu um MikroTik com DNS habilitado, esqueceu ACL, e pronto — você virou um amplificador de DNS na internet.
Uma boa prática é usar ferramentas como o Radar da Criteo (Creator Radar) para mapear serviços com potencial de amplificação associados ao seu ASN e receber alertas. Se aparece algo ali, não é “opcional” corrigir: ASN vem com responsabilidade.
Segurança não é só lógica: porta ociosa tem que estar em shutdown
Tem um detalhe que muita gente ignora: segurança física.
Um hábito simples e poderoso é: porta que não está em uso, fica desabilitada. Se alguém plugar algo num POP, não acontece nada. Para funcionar, a pessoa teria que violar também a camada lógica (acessar, tirar shutdown, etc.). Segurança em camadas.
Atualização de firmware e sistema: rotina, não evento
Parte desses surtos de ataques acontece porque um equipamento está rodando versão antiga com vulnerabilidade conhecida — e que volta a ser explorada.
O jogo é acompanhar release notes, avaliar risco e atualizar com disciplina. Se é risco iminente, janela de emergência. Se é risco moderado, programa, mas não ignora.
TV Box e botnets: reduzir dano cortando “a nave-mãe”
Um ponto que tem aparecido muito como origem de infecção são as TV Boxes piratas — e aqui vale um cuidado: selo/homologação ajuda, mas não é garantia absoluta de segurança.
O que dá para fazer, do lado da rede, é reduzir o impacto bloqueando a comunicação com infraestrutura de comando e controle (C2) de botnets conhecidas. Mesmo que o dispositivo esteja vulnerável, se ele não consegue falar com a “nave-mãe”, ele perde a capacidade de receber ordens e participar dos ataques com a mesma eficiência.
Isso não é bala de prata, mas é uma camada a mais — e, hoje, camadas importam.
Por que isso é urgente?
Dois motivos bem diretos:
- Ser um bom cidadão de internet. Se ataque derruba negócio, por que permitir que saia da sua rede e derrube o do outro? Internet é colaborativa: ou todo mundo faz sua parte, ou ninguém aguenta.
- Retaliação existe. Quando um ataque sai do seu provedor, é comum vir um de volta. Tem gente que enxerga um AS “relaxado” e decide ensinar “na dor”. Provedor que não tomava ataque há tempos, de repente volta a tomar — e frequentemente depois de ter tráfego malicioso saindo de dentro.
Um checklist rápido para você aplicar hoje
- Anti-spoofing implementado e validado
- uRPF no concentrador e nos pontos certos da rede (não só no cliente)
- Visibilidade de protocolos amplificadores (flow ajuda muito)
- Processo de investigação para picos de upload (sem normalizar o anormal)
- Gerência de CPE restrita por ACL (nada exposto para a internet)
- Portas ociosas em shutdown
- Rotina de atualização baseada em release notes
- Bloqueio de C2/botnets conhecidas como camada adicional
Quer se aprofundar ainda mais nesse tema? Assista ao vídeo que publiquei no YouTube, onde explico em detalhes como identificar e agir diante de tráfego malicioso saindo da sua rede:
👉 Assista aqui e não deixe de se inscrever no nosso canal no YouTube!
Até a próxima edição!