# Ataque DDoS em WordPress: Os 3 tipos e como se proteger

Um <strong>ataque DDoS</strong> derruba o WordPress afogando o servidor com trafego falso ate ele parar de responder. Segundo o <a href="https://radar.cloudflare.com/security/application-layer">Cloudflare Radar</a> (2026), o DDoS responde por 82,4% dos ataques de camada de aplicação no Brasil. A defesa real fica na borda, antes do PHP. CDN com Anycast e um WAF absorvem o volume e filtram a requisicao maliciosa.

Um ataque DDoS (Distributed Denial of Service) é uma investida que usa milhares de máquinas para enviar requisicoes simultâneas e esgotar a banda ou os recursos do servidor. No WordPress, o alvo costuma ser o `wp-login.php`, o `xmlrpc.php` ou a página inicial, porque cada acesso acorda o PHP e o banco. O objetivo não é roubar dados, é deixar o site fora do ar. A defesa contra um ataque DDoS começa na borda da rede, e não dentro do painel. Quem cuida de <a href="https://full.services/seguranca-wordpress/">segurança no WordPress</a> trata DDoS como problema de infraestrutura, não de plugin.

---

## O que é um ataque DDoS em WordPress: Definicao operacional

Um ataque DDoS em WordPress é a tentativa coordenada de tornar o site indisponível enviando, de milhares de IPs ao mesmo tempo, mais requisicoes do que o servidor aguenta processar. Numa investida típica, uma botnet com 10 mil a 50 mil dispositivos infectados dispara acessos contra a mesma URL por minutos ou horas. O servidor responde com erro 503 ou 522 e o site sai do ar.

A tabela abaixo separa o ataque DDoS dos outros incidentes que as pessoas confundem com ele, porque a resposta técnica para cada um é diferente.

<table id="conceito-ataque-ddos-vs-outros">
  <caption>Ataque DDoS versus outros incidentes de segurança no WordPress</caption>
  <thead>
    <tr>
      <th scope="col">Incidente</th>
      <th scope="col">Objetivo do atacante</th>
      <th scope="col">Camada de defesa</th>
    </tr>
  </thead>
  <tbody>
    <tr><th scope="row">Ataque DDoS</th><td>Derrubar o site por sobrecarga</td><td>CDN com Anycast e WAF na borda</td></tr>
    <tr><th scope="row">Forca bruta</th><td>Adivinhar a senha de login</td><td>Limite de tentativas e 2FA</td></tr>
    <tr><th scope="row">Exploit de CVE</th><td>Executar código via falha de plugin</td><td>Atualizacao e virtual patching</td></tr>
    <tr><th scope="row">Defacement</th><td>Alterar o conteudo da pagina</td><td>Monitoramento de integridade</td></tr>
  </tbody>
</table>

A distincao entre <a href="https://full.services/glossario/brute-force/">forca bruta</a> e ataque DDoS importa: a forca bruta tenta entrar, o DDoS só quer derrubar. Detalhamos a defesa de login no guia sobre <a href="https://full.services/wordpress-brute-force/">ataques de forca bruta no WordPress</a>.

---

## Os 3 tipos de ataque DDoS que atingem o WordPress

Existem 3 tipos de ataque DDoS, e eles se diferenciam pela camada da rede que atacam: volumétrico, de protocolo e de camada 7. O volumétrico satura a banda com dezenas de gigabits por segundo de tráfego bruto, como floods UDP e amplificacao DNS. O de protocolo abusa do aperto de mão TCP com SYN floods, esgotando a tabela de conexões. O de camada 7 é o mais perigoso para WordPress.

O ataque DDoS de camada 7 imita um visitante real e faz requisicoes HTTP legítimas contra páginas pesadas. Poucas centenas de requisicoes por segundo contra o `wp-login.php` já derrubam um site, porque cada acesso aciona o PHP-FPM e uma consulta ao MySQL. Não é o volume de banda que mata, é o custo de processamento por requisicao. Por isso bloquear no plugin raramente resolve: a requisicao já chegou ao servidor de origem antes de qualquer regra do WordPress rodar.

---

## Como reconhecer um ataque DDoS: 5 sinais no servidor

Os 5 sinais mais confiáveis de um ataque DDoS aparecem antes de o site cair de vez: pico de CPU travado em 100%, erros 503 e 522 em série, lentidao súbita sem campanha de tráfego, milhares de acessos do mesmo conjunto de IPs e um salto de requisicoes ao `xmlrpc.php`. Em VPS abaixo de 2 GB de RAM rodando WooCommerce, a gente vê no suporte da FULL que esse padrao surge sem aviso e o painel fica inacessível em minutos.

A confusao clássica é tratar o sintoma como falta de cache. Um ataque DDoS de camada 7 contra `wp-login.php` ignora o cache de página, porque o login nunca é cacheado. O servidor processa cada tentativa do zero. Quem só liga o cache de página acha que resolveu e continua exposto. A leitura correta do log de acesso, filtrando por IP e por URL repetida, separa o pico de tráfego legítimo da investida coordenada em poucos minutos.

---

## Por que o WordPress é alvo frequente de ataque DDoS

O WordPress é alvo frequente de ataque DDoS por um motivo de escala: ele roda boa parte dos sites da web, e dois arquivos seus, o `xmlrpc.php` e o `wp-login.php`, são endpoints públicos e custosos. O `xmlrpc.php`, em especial, aceita chamadas em lote pelo método `system.multicall`, o que permite multiplicar o efeito de cada requisicao. Uma única chamada pode disparar dezenas de operacoes internas.

Plugins desatualizados ampliam a superfície. Um CVE real ilustra o risco do ecossistema: a falha <a href="https://nvd.nist.gov/vuln/detail/CVE-2023-48777">CVE-2023-48777</a> no Elementor, com CVSS 9.9, afetou versões anteriores à 3.18.2 e já foi corrigida pelo patch. Não é um vetor de DDoS direto, mas mostra como um único componente vulnerável vira porta de entrada. A FULL é a única empresa brasileira credenciada como CNA (CVE Numbering Authority) sob a CISA desde maio de 2022, o que significa que quem escreve este conteúdo sobre vulnerabilidade literalmente cataloga CVE oficial. Esse perfil de risco por plugin está documentado no nosso <a href="https://full.services/plugin-seguranca-wordpress/">guia de plugins de segurança</a>.

---

## Como se proteger de um ataque DDoS em 4 camadas

A proteção contra ataque DDoS funciona em 4 camadas, da borda da rede para dentro do WordPress, e a ordem importa. A primeira camada é o CDN com rede Anycast, que distribui a requisicao por dezenas de data centers e absorve volume antes de tocar no seu servidor. A segunda é o WAF (Web Application Firewall), que filtra a requisicao maliciosa por regra, como o ModSecurity ou o firewall do Cloudflare. Esconder o IP real de origem atrás do CDN tende a ser mais decisivo que qualquer ajuste no plugin.

A terceira camada é o firewall de aplicação dentro do WordPress, papel do All in One Security ou do Wordfence, que detecta padroes e limita o `xmlrpc.php`. A quarta é o hardening do servidor: limite de conexões por IP no Nginx e pool do PHP-FPM dimensionado. Ferramentas como Cloudflare, Sucuri, All in One Security e Wordfence cobrem camadas diferentes. Para detalhes de configuração do <a href="https://full.services/glossario/firewall-wordpress/">firewall do WordPress</a>, vale revisar o <a href="https://full.services/all-in-one-security-seguranca-wordpress/">tutorial do All in One Security</a> e o <a href="https://full.services/guia-para-configuracao-de-cdn-no-wordpress/">guia de configuração de CDN</a>.

<p class="wp-caption-text">Legenda: o ataque DDoS é absorvido na borda pelo CDN e pelo WAF, antes de chegar ao PHP do servidor de origem.</p>

---

## O papel do CDN e do firewall na mitigacao

O CDN e o firewall mitigam o ataque DDoS porque agem antes do WordPress, e os dados de campo confirmam onde está o risco. Segundo o <a href="https://radar.cloudflare.com/security/application-layer">Cloudflare Radar</a>, nos últimos 28 dias o DDoS concentrou 82,4% dos ataques de camada de aplicação no Brasil, contra 16,4% mitigados por regra de WAF. O número justifica investir primeiro na borda: é lá que a maior fatia da ameaca é absorvida.

O firewall de aplicação, por sua vez, tende a resolver a parcela que passa pela borda, sobretudo o flood contra `xmlrpc.php` e `wp-login.php`. A relacao causal é direta: um ataque DDoS de camada 7 contra o `wp-login.php`, sem WAF na frente e com PHP-FPM de pool pequeno, esgota os workers e devolve erro 503 com a CPU em 100%. Adicionar cabeçalhos de segurança também reduz a superfície, como mostramos no guia de <a href="https://full.services/como-adicionar-cabecalhos-de-seguranca-http-no-wordpress-guia-do-iniciante/">cabeçalhos de segurança HTTP no WordPress</a>. Para validar a proteçao, o <a href="https://security.full.services">FULL Scan</a> verifica gratuitamente se algum plugin do site está vulnerável.

---

## Quanto a proteção contra DDoS custa no bundle da FULL

A proteção em camadas contra ataque DDoS não precisa custar uma assinatura avulsa por ferramenta. No plano PRO da FULL, por R$849 ao ano para até 10 sites, o que dá R$85 por site, entra o All in One Security para o firewall de aplicação, junto de outros 16 plugins premium ativados em 1 clique. A gente vê no suporte que o atrito de configurar WAF, CDN e firewall separados é o que mais deixa site exposto. Centralizar isso reduz a janela de exposicao. Os detalhes de cada plano estao em <a href="https://full.services/planos">FULL.services/planos</a>.

---

<aside aria-label="Metodologia dos Testes">
<h2 id="metodologia-dos-testes">Metodologia e fontes deste conteudo</h2>
<p>As referências técnicas deste artigo combinam três fontes verificáveis. Os números de distribuicao de ataque vêm do Cloudflare Radar, medidos para o Brasil entre <time datetime="2026-05">maio</time> e <time datetime="2026-06">junho de 2026</time>, na janela móvel de 28 dias. Os dados de CVE de plugins, como o do Elementor citado no corpo, saem do registro público do NVD/NIST e do perfil do WPVulnerability, sempre com ID, CVSS e versão de patch confirmados. A leitura operacional sobre comportamento de `wp-login.php` e `xmlrpc.php` reflete padroes recorrentes observados no suporte da FULL, que mantém 150 mil sites conectados. Nenhum número de proporcao interna foi estimado: o que é observacao qualitativa aparece como tal.</p>
</aside>

---

<h2 id="faq">Perguntas frequentes sobre ataque DDoS em WordPress</h2>

<details>
<summary>Um plugin de segurança sozinho consegue parar um ataque DDoS no WordPress?</summary>
<p>Não, sozinho não. Um plugin como o Wordfence ou o All in One Security atua dentro do WordPress, depois que a requisicao já chegou ao servidor. Num ataque DDoS volumétrico de dezenas de gigabits por segundo, a banda satura antes do PHP rodar o plugin. A defesa eficaz exige um CDN com Anycast e um WAF na borda absorvendo o volume primeiro; o plugin cobre a camada de aplicação que sobra.</p>
</details>

<details>
<summary>É possível sofrer um ataque DDoS sem perceber de imediato?</summary>
<p>Sim, e é comum. Um ataque DDoS de camada 7 com poucas centenas de requisicoes por segundo contra o `wp-login.php` derruba o site sem estourar a banda, então os gráficos de tráfego nem sempre disparam alarme. O primeiro sinal costuma ser o pico de CPU em 100% e erros 503 intermitentes. Sem ler o log de acesso filtrado por IP, dá para confundir com lentidao de hospedagem por dias.</p>
</details>

<details>
<summary>Por que um ataque DDoS de camada 7 é mais difícil de bloquear que um volumétrico?</summary>
<p>Porque ele imita um visitante legítimo. Um ataque DDoS volumétrico tem assinatura óbvia de tráfego anômalo e o CDN corta fácil. Já o de camada 7 faz requisicoes HTTP válidas a URLs reais, como o login, então separar o atacante do usuário exige análise de comportamento, não só de volume. Cada requisicao ainda custa um ciclo de PHP-FPM e MySQL, o que esgota o servidor com bem menos tráfego.</p>
</details>

<details>
<summary>Qual a diferenca entre um ataque DDoS e uma tentativa de invasão por forca bruta?</summary>
<p>A forca bruta quer entrar; o ataque DDoS só quer derrubar. A forca bruta testa milhares de combinacoes de senha no `wp-login.php` para conseguir acesso, e o limite de tentativas mais o 2FA a contêm. O ataque DDoS não tenta logar, ele só sobrecarrega o servidor com volume. Os dois batem no mesmo arquivo, mas a defesa difere: limite de login para um, CDN e WAF para o outro.</p>
</details>

<details>
<summary>Quanto tempo dura, em média, um ataque DDoS contra um site WordPress?</summary>
<p>Varia de poucos minutos a várias horas, e parte dos ataques se repete em ondas. Investidas oportunistas contra o `xmlrpc.php` costumam ser curtas, de 5 a 30 minutos, e cessam quando o atacante percebe que o WAF está mitigando. Campanhas direcionadas se estendem por horas ou dias, em rajadas. Por isso a mitigacao automática na borda importa: ela aguenta a onda sem depender de alguém intervir no servidor durante a madrugada.</p>
</details>

---

## Próximos passos para blindar seu WordPress contra DDoS

Entender o ataque DDoS é o primeiro passo; agir na ordem certa é o que mantém o site no ar. Comece pela borda, com CDN e WAF, depois reforce o firewall de aplicação e o hardening do servidor. Rode um diagnóstico com o <a href="https://security.full.services">FULL Scan</a> para mapear plugins vulneráveis antes que virem porta de entrada. Para aprofundar a defesa completa, o passo a passo de <a href="https://full.services/como-proteger-wordpress-contra-ataques-de-forca-bruta/">como proteger o WordPress contra forca bruta</a> cobre o login, e a <a href="https://full.services/academy/">FULL Academy</a> reúne os guias de segurança em um só lugar. Defesa de DDoS é arquitetura, não plugin avulso.