A mitigação já está ligada em todos os serviços e trabalha sem você pedir: a proteção da RedHosting é feita em duas camadas — a rede GC, que absorve ataque volumétrico com capacidade de até 20 Tbps antes de o tráfego chegar na nossa infraestrutura, e um appliance A10 na borda, que filtra o que não é volumétrico e passaria por uma inspeção feita só por volume.
Este guia é sobre a outra metade: a parte que é sua. Reconhecer que é ataque, decidir o que fazer, e não piorar por reflexo.
1. É ataque mesmo?
Nem toda queda é ataque, e tratar sobrecarga comum como ataque leva o diagnóstico para o lado errado. Os sinais que separam um do outro:
| Sinal | Ataque | Sobrecarga comum |
|---|
| Início | Repentino, em segundos | Gradual, acompanhando o uso |
| Origem do tráfego | Muitos IPs sem padrão de público | Os mesmos de sempre |
| Relação com evento | Nenhuma, ou logo após uma rixa pública | Divulgação, promoção, horário de pico |
| Conteúdo das conexões | Repetitivas, sem completar nada | Requisições normais, só que muitas |
| CPU e memória | Normais, mas a rede satura | Sobem junto com o tráfego |
O último ponto é o mais revelador: numa sobrecarga real a máquina está trabalhando; num ataque volumétrico ela está ociosa e o que saturou foi o caminho até ela.
2. O que fazer, na ordem
- Registre o horário. Anote quando começou, com minuto aproximado. Sem isso, achar o evento no log depois vira garimpo.
- Não reinicie repetidamente. Reiniciar não interrompe um ataque, e a máquina passa mais tempo subindo do que servindo.
- Abra o chamado cedo, com IP, horário e o que você observou. Quanto antes a equipe olhar o tráfego ao vivo, mais fácil ajustar o filtro para o padrão daquele ataque específico.
- Guarde o que puder do log da aplicação e da saída de
ss -tn state established ou equivalente. É esse material que permite ajustar a regra depois.
- Avise a sua comunidade se for servidor de jogo. Silêncio durante uma queda faz mais estrago à reputação que a queda em si.
⚠️O que não funciona: Bloquear IP na mão. Numa botnet distribuída as origens mudam o tempo todo, e a lista cresce mais rápido do que você consegue mantê-la. Regra por padrão de tráfego é o que sustenta; IP a IP é enxugar gelo.
3. Decisões que costumam aparecer
| Situação | Decisão recomendada | Risco de ignorar |
|---|
| Pico de conexões logo após um evento | Aumentar o limite temporariamente e observar a origem | Bloquear jogador ou cliente legítimo |
| Muitas conexões curtas sem completar nada | Filtrar por assinatura e cadência, não por IP | Esgotar a tabela de estado do firewall |
| Consultas anormais num serviço auxiliar | Isolar a porta e reduzir a exposição | Queda parcial de todo o ecossistema |
| Ataque volta sempre no mesmo horário | Levar o padrão ao suporte para regra permanente | Repetir a mitigação manual toda semana |
💡Dica: Em incidente real, peça no chamado um relatório com horário, pico de tráfego e tipo de filtro aplicado. Esse histórico é o que permite ajustar a regra antes do próximo evento, em vez de reagir de novo do zero.
4. Reduzir a superfície, antes do próximo
Metade do trabalho é feito quando não há ataque nenhum.
Revisão que vale fazer trimestralmente
✓Inventário das portas expostas. Toda porta aberta que ninguém usa é superfície de graça para o outro lado.
✓Serviços auxiliares fechados ao público — banco de dados, painel administrativo, API interna. Eles não precisam de internet aberta.
✓Monitoramento externo, fora da nossa rede, para confirmar disponibilidade de um ponto de vista independente.
✓Um runbook de incidente com mensagens prontas para a comunidade. Escrever comunicado durante a queda sai mal.
✓Revisão de plugins e módulos: cada um que você não usa é código exposto sem motivo.
✓IP do servidor fora de divulgação pública quando houver uma camada na frente — divulgar o IP de origem contorna a proteção.
5. O que já é nosso, e você não precisa configurar
- Mitigação em duas camadas, em todos os produtos — Minecraft, Hytale, VPS, dedicados, sites e bots —, incluída no preço.
- Absorção de ataque volumétrico na rede, antes de consumir a banda do seu servidor.
- Monitoramento proativo 24/7.
- Firewall personalizável e restrição de acesso por jogador autorizado, nos servidores de jogo.
Os números e o funcionamento das duas camadas estão em redhosting.com.br/protecao.
Durante um incidente
WhatsApp +55 11 98833-3902 é o canal mais rápido, 24 horas por dia. Chamados em financeiro.redhosting.com.br. Manutenções e incidentes em andamento aparecem em redhosting.com.br/status.