--- title: "Identificar ataque DDoS: sintomas e diagnóstico no Linux" description: "Como identificar um ataque DDoS pelos sintomas e por comando no Linux, separar ataque de pico legítimo e reunir a evidência certa para o suporte." url: "https://streethosting.com.br/guias/infraestrutura/identificar-ataque-ddos-servidor" category: "infraestrutura" slug: "identificar-ataque-ddos-servidor" datePublished: "2026-09-28" dateModified: "2026-09-28" author: "Equipe StreetHosting" difficulty: "intermediario" language: "pt-BR" keywords: - "identificar ataque ddos servidor" - "como saber se estou sofrendo ddos" - "sintomas ataque ddos" - "tcpdump amostra ddos" - "ddos ou pico de trafego" --- # Como saber se o seu servidor está sob ataque DDoS Lag geral, jogadores caindo e SSH lento podem ser DDoS ou só um servidor sobrecarregado. Veja os sintomas, os comandos que confirmam o ataque e o que levar ao suporte sem perder tempo. > **Resposta rápida** > > Para **identificar um ataque DDoS no servidor**, cruze três sinais: perda de pacote e latência alta para todos ao mesmo tempo, banda ou pacotes por segundo muito acima do normal e CPU presa em softirq com a aplicação ociosa. Confirme com iftop, ss e uma amostra curta de tcpdump e compare com o jeito de um pico legítimo. Se for ataque, não reinicie em loop: guarde a evidência e abra chamado com horário, IP, porta e a amostra. ## Sintomas que levantam a suspeita Um DDoS quase nunca se anuncia. O primeiro aviso é a reclamação no Discord: todo mundo com lag, gente caindo, painel demorando para abrir. O problema é que servidor sobrecarregado, rota ruim e plugin travado geram queixas parecidas. O que aponta para ataque é a combinação de sintomas, e não um sinal isolado. - **Perda de pacote para todos ao mesmo tempo:** usuários de operadoras e estados diferentes reclamam no mesmo minuto. Problema de rota costuma atingir um grupo, como os clientes de uma única operadora. - **Latência alta até no SSH:** o terminal demora para mostrar o que você digita. Isso indica fila de rede cheia, não aplicação lenta. - **Link saturado:** a entrada encosta no limite da porta, perto de 1 Gbps numa VPS com uplink de 1 Gbps, ou os pacotes por segundo disparam com pouca gente conectada. - **CPU em softirq:** o top mostra a coluna si alta e processos `ksoftirqd` no topo, enquanto o jogo ou a aplicação usam pouco. É o kernel gastando processador só para receber e descartar pacotes. - **Avisos do kernel:** mensagens de SYN flooding ou de tabela de conntrack cheia no dmesg. Um detalhe muda toda a leitura: o que você vê dentro da VPS é só o que sobrou depois da rede do provedor. Com a proteção de borda filtrando, a máquina pode parecer tranquila enquanto os jogadores sentem uma oscilação curta no início da mitigação. E se o volume for maior que o próprio link, os pacotes se perdem antes de chegar: o servidor fica fora do ar e o iftop aparece quase vazio. Os tipos de ataque por trás de cada quadro estão em [o que é DDoS em servidor de jogos](https://streethosting.com.br/guias/infraestrutura/o-que-e-ddos-ataque-servidor-jogos). | Sintoma | O que sugere | Como confirmar | | --- | --- | --- | | Perda de pacote geral e simultânea | Saturação de rede ou ataque volumétrico | nload na VPS e MTR a partir de duas operadoras | | Perda só para uma operadora ou região | Problema de rota, não DDoS | MTR com perda que começa num salto e segue até o destino | | CPU alta em si com a aplicação ociosa | Flood de pacotes pequenos | top, mpstat e sar com pacotes por segundo | | Milhares de conexões em SYN RECV | SYN flood | ss e mensagens do dmesg | | Site lento com banda normal | HTTP flood na camada 7 | Requisições por minuto no log do Nginx | | Um único serviço lento e rede normal | Gargalo interno de CPU, disco ou memória | htop, iostat e free | Para separar ataque de rota ruim, rode um MTR a partir de redes diferentes, como mostra o guia de [como usar MTR para diagnosticar a rede](https://streethosting.com.br/guias/infraestrutura/usar-mtr-diagnosticar-rede). Perda que aparece em um salto intermediário e some no destino raramente é problema real. ## Os primeiros minutos no terminal Instale as ferramentas antes de precisar delas. Durante um ataque o apt pode demorar, e o vnstat só mostra histórico se o serviço já estava coletando dados antes do problema. ``` sudo apt update sudo apt install iftop nload vnstat tcpdump sysstat whois ip -br a ``` O último comando lista as interfaces de rede. Numa VPS o nome costuma ser `eth0` ou `ens3`. Troque `eth0` nos exemplos pelo nome que aparecer para você. ### Banda e pacotes por segundo ``` nload eth0 # gráfico de entrada e saída em tempo real sudo iftop -i eth0 -nNP # quem está falando com quem, sem resolver nomes vnstat -l -i eth0 # taxa e pacotes por segundo ao vivo vnstat -5 -i eth0 # médias de 5 em 5 minutos, para comparar com ontem sar -n DEV 1 5 # coluna rxpck/s mostra pacotes recebidos por segundo ``` No iftop, a opção `-n` é importante: sem ela a ferramenta tenta resolver o nome de cada IP e gera ainda mais tráfego num momento ruim. Olhe também para os pacotes, e não só para a banda. Um flood de pacotes pequenos derruba o servidor com a banda longe do limite, porque o custo está em processar cada pacote, e não no volume em megabits. ### CPU, conexões e mensagens do kernel ``` top # aperte 1 para ver cada núcleo; observe a coluna si mpstat -P ALL 1 5 # coluna %soft por núcleo ss -s # resumo de sockets por estado ss -Htan state syn-recv | wc -l sudo dmesg -T | grep -Ei 'syn flooding|conntrack|dropping' | tail cat /proc/sys/net/netfilter/nf_conntrack_count /proc/sys/net/netfilter/nf_conntrack_max ``` Em operação normal, conexões em `SYN-RECV` ficam perto de zero ou em poucas dezenas. Milhares delas, somadas a uma linha como `Possible SYN flooding on port 25565. Sending cookies.` no dmesg, indicam SYN flood e mostram que o kernel ativou os SYN cookies. Se o contador do conntrack encosta no máximo, a tabela encheu e o sistema passa a descartar conexões novas, inclusive as de jogadores de verdade. Para ver quais IPs concentram conexões estabelecidas numa porta, troque 443 pela porta do seu serviço: ``` ss -Htn state established '( sport = :443 )' \ | awk '{print $4}' | sed -E 's/:[0-9]+$//' \ | sort | uniq -c | sort -rn | head ``` ## Amostra curta com tcpdump O tcpdump mostra o que está chegando de fato. A regra é capturar pouco: alguns milhares de pacotes, só os cabeçalhos, sem o tráfego do seu próprio SSH. Captura longa durante um ataque enche o disco em minutos e não acrescenta informação. ``` sudo tcpdump -ni eth0 -s 96 -c 5000 \ -w /root/amostra-$(date +%Y%m%d-%H%M).pcap 'not port 22' ``` A opção `-s 96` guarda só os primeiros 96 bytes de cada pacote, o suficiente para ver protocolo, portas e flags sem gravar o conteúdo. `-c 5000` encerra a captura sozinha depois de 5 mil pacotes, o que num flood leva frações de segundo. Com o arquivo salvo, a análise é feita com calma: ``` A=/root/amostra-AAAAMMDD-HHMM.pcap # primeiras linhas, para enxergar o padrão sudo tcpdump -nr $A | head -30 # origens que mais aparecem sudo tcpdump -nr $A 2>/dev/null | awk '{print $3}' | cut -d. -f1-4 \ | sort | uniq -c | sort -rn | head # quantos pacotes são SYN puro e quantos são UDP sudo tcpdump -nr $A 'tcp[tcpflags] == tcp-syn' 2>/dev/null | wc -l sudo tcpdump -nr $A udp 2>/dev/null | wc -l # portas de origem do UDP recebido (53, 123 e 11211 indicam reflexão) sudo tcpdump -nr $A udp 2>/dev/null | awk '{print $3}' | awk -F. '{print $NF}' \ | sort | uniq -c | sort -rn | head ``` > **Dica** > > Guarde o arquivo .pcap. É a evidência mais útil para o suporte, e poucos segundos de captura bastam. Não publique em grupo aberto: mesmo sem conteúdo, ele traz IPs de jogadores reais, e isso é dado pessoal. ## Padrões comuns e como aparecem Você não precisa classificar o ataque com precisão para pedir ajuda, mas reconhecer o padrão acelera a conversa com o suporte e mostra se vale mexer em algo do seu lado. A explicação de cada tipo por camada de rede está em [DDoS de camada 3, 4 e 7](https://streethosting.com.br/guias/infraestrutura/ddos-layer-3-4-7-diferenca). | Padrão | O que aparece na amostra | Sinal no sistema | | --- | --- | --- | | SYN flood | Muitos pacotes só com a flag S para a mesma porta, origens variadas, quase nenhum ACK de volta | Milhares de conexões em SYN RECV e aviso de SYN flooding no dmesg | | UDP flood | Rajada de UDP para a porta do jogo ou para portas aleatórias, pacotes quase do mesmo tamanho | Pacotes por segundo muito acima do normal e softirq alto | | Amplificação por DNS | UDP chegando com porta de origem 53, respostas grandes que você nunca pediu, muitos fragmentos | Entrada muito maior que a saída, banda perto do limite | | Amplificação por NTP | UDP com porta de origem 123 vindo de milhares de servidores diferentes | Banda de entrada saturada em poucos segundos | | Amplificação por memcached | UDP com porta de origem 11211 e pacotes grandes | Picos de banda muito altos e curtos | | HTTP flood | Tráfego TCP na porta 443 com cara de normal | Requisições por minuto fora do padrão no Nginx e CPU da aplicação no teto | Na amplificação, os IPs que aparecem na amostra não são dos atacantes. São servidores mal configurados pela internet respondendo a consultas forjadas com o seu endereço como remetente. Por isso bloquear IP por IP não resolve: a filtragem por porta de origem e por volume precisa acontecer na borda do provedor, antes do seu link. ### HTTP flood no log do Nginx No HTTP flood a banda pode estar normal. O sinal está no log de acesso, que no formato padrão fica em `/var/log/nginx/access.log`. ``` L=/var/log/nginx/access.log # requisições por minuto nos últimos minutos sudo awk '{print substr($4, 2, 17)}' $L | uniq -c | tail -20 # IPs, URLs, user agents e códigos de status mais frequentes sudo awk '{print $1}' $L | sort | uniq -c | sort -rn | head -20 sudo awk '{print $7}' $L | sort | uniq -c | sort -rn | head -20 sudo awk -F'"' '{print $6}' $L | sort | uniq -c | sort -rn | head sudo awk '{print $9}' $L | sort | uniq -c | sort -rn ``` Desconfie quando uma única URL cara, como busca, login ou carrinho, concentra a maior parte das requisições, quando o mesmo user agent aparece milhares de vezes ou quando os códigos 499, 502 e 504 disparam. Se o site está atrás de um proxy ou CDN, o primeiro campo mostra o IP do proxy, e é preciso configurar o módulo real_ip do Nginx para enxergar a origem. As defesas dessa camada estão em [DDoS de camada 7](https://streethosting.com.br/guias/infraestrutura/ddos-camada-7-l7-aplicacao). ## Ataque ou pico legítimo Antes de acionar o alarme, olhe o calendário. Atualização de modpack, sorteio, vídeo de um criador de conteúdo, raid de streamer e início de temporada enchem o servidor de gente real, e bloquear essa gente por engano é pior do que o ataque. A tabela resume as diferenças que mais ajudam. | Critério | Pico legítimo | Ataque | | --- | --- | --- | | Origem | Operadoras residenciais e móveis do Brasil, na proporção do seu público | Datacenters, países sem jogadores seus ou milhares de IPs do mesmo tipo | | Início | Sobe em rampa e acompanha o anúncio | Salta do zero ao máximo em segundos, para do mesmo jeito e volta em ondas | | Comportamento | Conexão completa, login, navegação por várias páginas | SYN sem resposta, a mesma URL repetida, user agent idêntico, pacotes do mesmo tamanho | | Horário | Coincide com live, evento, atualização ou post | Coincide com ban, briga entre comunidades, ameaça ou madrugada sem movimento | | Banda e jogadores | Banda cresce junto com o número de conectados | Banda enorme com jogadores estáveis ou caindo | | Correlação com divulgação | Os picos batem com cada ação de divulgação | Nenhum evento seu explica o volume | Para checar a origem de um IP que aparece muito na amostra, o whois mostra o dono do bloco e o país: ``` whois 198.51.100.7 | grep -Ei 'owner|orgname|org-name|netname|country' ``` Um bloco de datacenter estrangeiro batendo num servidor com público 100% brasileiro é sinal forte. Centenas de IPs de operadoras brasileiras, com conexão completa e uso normal, é gente de verdade chegando. Nesse caso o problema é capacidade, e a resposta é dimensionar melhor, não bloquear. ## O que fazer durante o ataque 1. **Não reinicie a VPS em loop.** O reboot não para o tráfego que vem de fora, apaga as mensagens do kernel e os contadores e, quando o servidor volta, todos os jogadores reconectam juntos, o que parece um novo pico. Reiniciar uma vez um processo travado é outra coisa. 2. **Anote o essencial:** horário de início com fuso, IP e porta afetados, e o que os usuários estão sentindo. 3. **Colete a evidência:** amostra curta de tcpdump, saída de ss e do dmesg, prints do nload ou do vnstat e, se for site, um trecho do log do Nginx. 4. **Abra o chamado** com tudo isso num único texto, como no modelo abaixo. 5. **Avise a comunidade** com uma mensagem curta e honesta. O roteiro de papéis e mensagens prontas está em [plano de resposta a incidentes](https://streethosting.com.br/guias/infraestrutura/plano-resposta-incidentes-comunidade-gamer). 6. **Depois que normalizar,** revise as portas expostas e procure por onde o IP pode ter vazado. ``` Assunto: Suspeita de DDoS no IP 203.0.113.10 Serviço: VPS, ID do serviço no painel IP e porta: 203.0.113.10, TCP 25565 Início: 28/09/2026 às 21h14 (horário de Brasília), ainda em andamento Sintomas: perda de pacote para todos os jogadores, SSH lento Medições: entrada de 850 Mbps e 400 mil pacotes/s no vnstat, 12 mil conexões em SYN-RECV no ss Anexos: amostra-20260928-2114.pcap (5000 pacotes, só cabeçalhos), print do nload, saída do dmesg ``` > **Atenção** > > Não tente revidar nem descobrir o atacante por conta própria. Atacar de volta é crime, mesmo contra quem começou, e ainda coloca o seu IP no meio do problema. - [ ] Ferramentas instaladas e vnstat coletando antes de qualquer incidente - [ ] Nome da interface de rede anotado no runbook - [ ] Comando de captura curta pronto para copiar e colar - [ ] Modelo de chamado salvo fora do servidor - [ ] Mensagem para a comunidade escrita com antecedência ## Onde a proteção precisa estar Nenhum comando desta página segura um ataque volumétrico. Quando o link lota, a única defesa está antes da sua máquina, na rede do provedor. Por isso o AntiDDoS precisa vir junto com o servidor, e não como item à parte. Na StreetHosting a proteção está inclusa em todas as [VPS](https://streethosting.com.br/vps) e nos [servidores dedicados](https://streethosting.com.br/dedicated), com datacenter em São Paulo. - **VPS Xeon:** AntiDDoS Enterprise, de R$ 23,00 por mês com 2 vCPU, 2 GB de RAM e 20 GB NVMe até R$ 550,00 com 24 vCPU e 64 GB. Mais vCPU por real, boa para sites, APIs e bots. - **VPS Ryzen 9 9950X:** DDR5 e clock de até 5,7 GHz, de R$ 39,00 com 1 vCPU e 2 GB até R$ 814,00 com 14 vCPU, 64 GB e 640 GB NVMe. É a linha indicada para servidor de jogo. As duas linhas de VPS têm uplink de 1 Gbps. - **Dedicados AMD:** AntiDDoS Gamer, porta de 10 Gbps dedicada e NVMe de 2 TB, a partir de R$ 1.489,00 por mês no Budget SM, com Ryzen 9 5900XT e 64 GB DDR4. Com a filtragem na borda, o trabalho desta página muda de natureza: em vez de tentar segurar o ataque, você confirma o que está acontecendo e entrega ao suporte uma evidência boa. Detalhes da rede e do datacenter estão na página de [infraestrutura da StreetHosting](https://streethosting.com.br/infraestructure). ## Perguntas frequentes ### Como saber se meu servidor está sofrendo um ataque DDoS? Procure a combinação de sinais: perda de pacote e latência alta para todos os usuários ao mesmo tempo, banda ou pacotes por segundo muito acima do normal e CPU ocupada em softirq enquanto a aplicação está ociosa. Confirme com iftop, ss e uma amostra curta de tcpdump antes de concluir. ### Reiniciar a VPS resolve um ataque DDoS? Não. O tráfego vem de fora e continua chegando ao IP depois do reboot. Reiniciar em loop apaga mensagens do kernel e contadores que serviriam de evidência, e ainda provoca uma reconexão em massa quando o servidor volta, o que confunde o diagnóstico. ### Como diferenciar DDoS de um pico de jogadores? Pico legítimo sobe em rampa, acompanha uma divulgação ou evento e vem de operadoras residenciais e móveis compatíveis com o seu público, com conexões completas. Ataque costuma saltar do zero ao máximo em segundos, vir de datacenters ou de origens sem relação com a comunidade e mostrar padrões repetitivos, como SYN sem resposta ou a mesma URL sem parar. ### O que devo mandar para o suporte durante um ataque? Horário de início com fuso, IP e porta afetados, sintomas observados, números de banda e pacotes por segundo, a saída de ss e do dmesg e uma amostra curta de tcpdump com poucos milhares de pacotes. Com isso o suporte consegue localizar o evento sem precisar perguntar tudo de novo. ### Por que o servidor está fora do ar e o iftop mostra pouco tráfego? Porque o que a VPS enxerga é só o que sobrou depois da rede do provedor. Se a proteção de borda está filtrando, pouca coisa chega. Se o volume passou do próprio link, os pacotes se perdem antes de entrar na máquina. Nos dois casos o diagnóstico precisa da visão do provedor, então abra chamado. ## Guias relacionados - [O que é DDoS: ataque a servidor de jogos explicado](https://streethosting.com.br/guias/infraestrutura/o-que-e-ddos-ataque-servidor-jogos.md) - [DDoS layer 3, 4 e 7: qual a diferença entre as camadas](https://streethosting.com.br/guias/infraestrutura/ddos-layer-3-4-7-diferenca.md) - [AntiDDoS para servidor de jogos no Brasil: como proteção na borda funciona](https://streethosting.com.br/guias/infraestrutura/antiddos-servidor-jogos-brasil.md) - [Como montar um plano de resposta a incidentes para comunidade gamer](https://streethosting.com.br/guias/infraestrutura/plano-resposta-incidentes-comunidade-gamer.md) - [Como verificar CPU, RAM, disco e rede no Linux por comando](https://streethosting.com.br/guias/vps/verificar-cpu-ram-disco-rede-linux.md) ## Produtos citados - https://streethosting.com.br/vps - https://streethosting.com.br/dedicated - https://streethosting.com.br/infraestructure ## Dados estruturados ```json [ { "@context": "https://schema.org", "@type": [ "Article", "TechArticle" ], "headline": "Como saber se o seu servidor está sob ataque DDoS", "name": "Identificar ataque DDoS: sintomas e diagnóstico no Linux", "abstract": "Lag geral, jogadores caindo e SSH lento podem ser DDoS ou só um servidor sobrecarregado. Veja os sintomas, os comandos que confirmam o ataque e o que levar ao suporte sem perder tempo.", "description": "Como identificar um ataque DDoS pelos sintomas e por comando no Linux, separar ataque de pico legítimo e reunir a evidência certa para o suporte.", "datePublished": "2026-09-28", "dateModified": "2026-09-28", "author": { "@type": "Organization", "name": "Equipe StreetHosting" }, "publisher": { "@type": "Organization", "name": "StreetHosting", "url": "https://streethosting.com.br" }, "inLanguage": "pt-BR", "mainEntityOfPage": { "@type": "WebPage", "@id": "https://streethosting.com.br/guias/infraestrutura/identificar-ataque-ddos-servidor" } }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Como saber se meu servidor está sofrendo um ataque DDoS?", "acceptedAnswer": { "@type": "Answer", "text": "Procure a combinação de sinais: perda de pacote e latência alta para todos os usuários ao mesmo tempo, banda ou pacotes por segundo muito acima do normal e CPU ocupada em softirq enquanto a aplicação está ociosa. Confirme com iftop, ss e uma amostra curta de tcpdump antes de concluir." } }, { "@type": "Question", "name": "Reiniciar a VPS resolve um ataque DDoS?", "acceptedAnswer": { "@type": "Answer", "text": "Não. O tráfego vem de fora e continua chegando ao IP depois do reboot. Reiniciar em loop apaga mensagens do kernel e contadores que serviriam de evidência, e ainda provoca uma reconexão em massa quando o servidor volta, o que confunde o diagnóstico." } }, { "@type": "Question", "name": "Como diferenciar DDoS de um pico de jogadores?", "acceptedAnswer": { "@type": "Answer", "text": "Pico legítimo sobe em rampa, acompanha uma divulgação ou evento e vem de operadoras residenciais e móveis compatíveis com o seu público, com conexões completas. Ataque costuma saltar do zero ao máximo em segundos, vir de datacenters ou de origens sem relação com a comunidade e mostrar padrões repetitivos, como SYN sem resposta ou a mesma URL sem parar." } }, { "@type": "Question", "name": "O que devo mandar para o suporte durante um ataque?", "acceptedAnswer": { "@type": "Answer", "text": "Horário de início com fuso, IP e porta afetados, sintomas observados, números de banda e pacotes por segundo, a saída de ss e do dmesg e uma amostra curta de tcpdump com poucos milhares de pacotes. Com isso o suporte consegue localizar o evento sem precisar perguntar tudo de novo." } }, { "@type": "Question", "name": "Por que o servidor está fora do ar e o iftop mostra pouco tráfego?", "acceptedAnswer": { "@type": "Answer", "text": "Porque o que a VPS enxerga é só o que sobrou depois da rede do provedor. Se a proteção de borda está filtrando, pouca coisa chega. Se o volume passou do próprio link, os pacotes se perdem antes de entrar na máquina. Nos dois casos o diagnóstico precisa da visão do provedor, então abra chamado." } } ] } ] ```