# O que fazer quando seu serviço sofre um ataque DDoS > Como reconhecer um ataque, o que a mitigação da RedHosting já faz sozinha, quais decisões cabem a você e o que evitar — inclusive as reações que costumam piorar a situação. - Guia da base de conhecimento da RedHosting — categoria: Outros - Página HTML: https://redhosting.com.br/base-de-conhecimento/o-que-fazer-quando-seu-servico-sofre-um-ataque-ddos - Publicado em: 2026-09-02 · Idioma: pt-BR 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](/protecao) — 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: SinalAtaqueSobrecarga comum InícioRepentino, em segundosGradual, acompanhando o uso Origem do tráfegoMuitos IPs sem padrão de públicoOs mesmos de sempre Relação com eventoNenhuma, ou logo após uma rixa públicaDivulgação, promoção, horário de pico Conteúdo das conexõesRepetitivas, sem completar nadaRequisições normais, só que muitas CPU e memóriaNormais, mas a rede saturaSobem 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çãoDecisão recomendadaRisco de ignorar Pico de conexões logo após um eventoAumentar o limite temporariamente e observar a origemBloquear jogador ou cliente legítimo Muitas conexões curtas sem completar nadaFiltrar por assinatura e cadência, não por IPEsgotar a tabela de estado do firewall Consultas anormais num serviço auxiliarIsolar a porta e reduzir a exposiçãoQueda parcial de todo o ecossistema Ataque volta sempre no mesmo horárioLevar o padrão ao suporte para regra permanenteRepetir 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](/protecao). ## Durante um incidente WhatsApp **+55 11 98833-3902** é o canal mais rápido, 24 horas por dia. Chamados em [financeiro.redhosting.com.br](https://financeiro.redhosting.com.br). Manutenções e incidentes em andamento aparecem em [redhosting.com.br/status](/status). ## Perguntas frequentes **Preciso contratar proteção contra DDoS?** Não. A mitigação está incluída em todos os serviços, em duas camadas: a rede GC, com capacidade de até 20 Tbps, e um appliance A10 na borda da RedHosting. Os detalhes estão em [redhosting.com.br/protecao](/protecao). **Como sei se é ataque ou só sobrecarga?** O sinal mais revelador é a relação entre CPU e rede. Em sobrecarga real a máquina está trabalhando e os recursos sobem junto com o tráfego; num ataque volumétrico a máquina está ociosa e o que saturou foi o caminho até ela. **Devo bloquear os IPs do ataque?** Não adianta. Numa botnet distribuída as origens mudam o tempo todo e a lista cresce mais rápido do que você consegue mantê-la. O que sustenta é regra por padrão de tráfego. **Reiniciar o servidor interrompe o ataque?** Não. E piora: a máquina passa mais tempo subindo do que servindo. **O que mando no chamado durante um ataque?** IP, horário aproximado de início 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. **O que posso fazer antes do próximo ataque?** Reduzir a superfície: fechar portas que ninguém usa, tirar serviços auxiliares da internet aberta, manter monitoramento externo e não divulgar o IP de origem quando houver uma camada na frente. ## Navegação — Outros (artigo 5 de 8) - Artigo anterior: Por que o ping varia e como medir a latência do seu servidor — https://redhosting.com.br/base-de-conhecimento/por-que-o-ping-varia-e-como-medir-a-latencia - Próximo artigo: Backup na RedHosting: o que é automático e o que é responsabilidade sua — https://redhosting.com.br/base-de-conhecimento/backup-o-que-e-automatico-e-o-que-e-responsabilidade-sua - Voltar à base de conhecimento: https://redhosting.com.br/base-de-conhecimento --- Precisa de ajuda com este passo a passo? Suporte 24/7 da RedHosting: suporte@redhosting.com.br · WhatsApp +55 11 98833-3902 · https://redhosting.com.br/discord Outros guias: https://redhosting.com.br/md/base-de-conhecimento.md