DDoS Protection WordPress: Server e CDN per Agenzie

Anatomia di un attacco DDoS su WordPress

Un attacco DDoS (Distributed Denial of Service) su un sito WordPress può manifestarsi in diverse forme: flood di richieste HTTP, exploit di endpoint AJAX come admin-ajax.php, attacchi XML-RPC amplificati, o brute force distribuiti su wp-login.php. Nel 2025, il 68% degli attacchi DDoS contro CMS ha colpito WordPress, con un picco medio di 250.000 richieste al secondo nei casi più gravi.

La vulnerabilità principale di WordPress in questi scenari è il carico computazionale: ogni richiesta PHP genera query database, parsing di plugin e rendering di temi. Anche con caching, endpoint dinamici come il login o il carrello WooCommerce restano esposti. Una protezione efficace richiede un approccio stratificato: mitigazione a livello infrastruttura prima che il traffico raggiunga il server applicativo.

Strategie a livello server

Rate limiting con Nginx e fail2ban

Il primo livello di difesa va implementato sul web server. Nginx offre moduli nativi per limitare le richieste per IP con precisione millimetrica:

limit_req_zone $binary_remote_addr zone=wplogin:10m rate=5r/m;
limit_req_zone $binary_remote_addr zone=wpajax:10m rate=30r/m;

server {
    location = /wp-login.php {
        limit_req zone=wplogin burst=3 nodelay;
        limit_req_status 429;
    }
    
    location = /wp-admin/admin-ajax.php {
        limit_req zone=wpajax burst=10;
    }
}

Questa configurazione limita il login a 5 richieste al minuto per IP, con burst di 3 richieste. Per admin-ajax.php, più tollerante, 30 richieste al minuto. Il codice 429 (Too Many Requests) comunica chiaramente il rate limiting.

Fail2ban completa la strategia monitorando i log Nginx e bannando IP che violano soglie definite:

[wordpress-ddos]
enabled = true
port = http,https
filter = wordpress-ddos
logpath = /var/log/nginx/access.log
maxretry = 50
findtime = 60
bantime = 3600

Con un filtro personalizzato che intercetta pattern sospetti (es. oltre 50 richieste in 60 secondi), fail2ban aggiunge automaticamente regole iptables temporanee.

Hardening degli endpoint critici

Oltre al rate limiting, la superficie d’attacco va ridotta drasticamente:

• Disabilitare XML-RPC: se non usate app mobile o Jetpack, bloccatelo completamente con add_filter('xmlrpc_enabled', '__return_false'); o a livello Nginx
• Limitare REST API: filtrare endpoint non autenticati con rest_authentication_errors o whitelist a livello server
• Proteggere wp-cron.php: disabilitare il trigger HTTP (define('DISABLE_WP_CRON', true);) e usare cron di sistema con autenticazione
• Bloccare user enumeration: impedire scansioni con redirect su ?author=N o blocco in .htaccess

Un file .htaccess con regole specifiche può bloccare pattern di attacco comuni:

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

RewriteCond %{QUERY_STRING} author=
RewriteRule ^ - [F,L]

Ottimizzazione risorse server

Durante un DDoS, anche richieste legittime soffrono. Ottimizzare la stack è cruciale:

• PHP-FPM tuning: aumentare pm.max_children ma con attenzione alla RAM (ogni processo PHP consuma 30-50MB). Usare pm = ondemand per carichi variabili
• OPCache aggressivo: opcache.memory_consumption=256 e opcache.max_accelerated_files=20000 riducono parsing PHP
• Object caching: Redis o Memcached con persistenza evitano query DB ripetitive. Configurare wp-config.php con WP_CACHE_KEY_SALT univoco per ogni sito
• Database query optimization: indici su wp_options.autoload, limitare post_revisions, partizionare tabelle grandi

Su AgencyPilot monitoriamo in tempo reale questi parametri per oltre 3.200 siti client, con alert automatici quando pm.max_children raggiunge il 90% di saturazione.

CDN con protezione DDoS integrata

Cloudflare: configurazione avanzata per WordPress

Cloudflare rimane la scelta più diffusa tra agenzie, con piano Pro (€20/mese) che include protezione Layer 7 illimitata. La configurazione ottimale per WordPress:

• Page Rules strategiche: cache aggressiva su static assets (*.css, *.js, *.woff2) con Edge Cache TTL di 1 mese; bypass totale su /wp-admin/* e /carrello/*
• Firewall Rules: bloccare paesi non target, creare challenge per user-agent sospetti, rate limiting addizionale (100 req/min su login con Enterprise o Workers)
• Bot Fight Mode: attivarlo con cautela, può bloccare crawler legittimi. Meglio Super Bot Fight Mode (Pro+) con whitelist personalizzate
• DDoS Managed Ruleset: dalla dashboard Security → DDoS, impostare sensibilità su “High” per WordPress (default “Medium” può lasciare passare attacchi sotto soglia)

Per attacchi Layer 4 (SYN flood, UDP amplification), Cloudflare mitiga automaticamente a livello network, ma serve un piano Business+ per analisi dettagliate.

Alternative enterprise: Sucuri e Imperva

Per siti ad alto traffico o e-commerce critici, WAF dedicati offrono vantaggi:

Sucuri Website Firewall (da €200/anno) include:

• Virtual patching per vulnerabilità zero-day WordPress
• DDoS mitigation fino a 30Gbps inclusa
• Scansione malware server-side ogni 4 ore
• CDN Anycast con 11 PoP globali

Imperva (ex Incapsula) scala fino a centinaia di Gbps ma costa da €300/mese. Adatto per WooCommerce con 50k+ transazioni/giorno.

Nel nostro stack per clienti enterprise, combiniamo Cloudflare Workers per rate limiting granulare (paghi per richiesta, circa €5 per 10M request) con Sucuri come secondo layer. Ridondanza che ha bloccato un attacco da 180Gbps nel marzo 2026 senza downtime.

CDN self-hosted: BunnyCDN + Nginx

Soluzione ibrida interessante per agenzie con server dedicati: BunnyCDN (€1/TB) per asset statici + Nginx reverse proxy con rate limiting dedicato per traffico dinamico. Configurazione:

1. BunnyCDN pull zone su static.tuosito.it che cacheaggia /wp-content/uploads/ e asset compilati
2. Nginx upstream verso origin server con proxy_cache per HTML
3. ModSecurity con OWASP Core Rule Set 4.0 sul reverse proxy
4. Rate limiting differenziato: 200 req/s per IP su statico, 10 req/s su dinamico

Costo totale per 5TB/mese: circa €15 BunnyCDN + server VPS (€40/mese Hetzner CCX32). Controllo totale ma richiede competenze DevOps avanzate.

Monitoring e incident response

Metriche da monitorare in real-time

Un sistema di monitoring efficace deve tracciare:

• Request rate per endpoint: picchi anomali su /wp-login.php o /xmlrpc.php sono segnali d’allarme
• Distribuzione geografica: traffico improvviso da paesi mai visti indica botnet
• Status code ratio: aumento di 429, 503 o 500 suggerisce saturazione
• Response time percentile: p95 e p99 degradano prima della media durante DDoS
• Connection states: netstat -an | grep :443 | wc -l monitora connessioni HTTPS aperte

Su AgencyPilot usiamo una dashboard Grafana con datasource Prometheus che aggrega metriche da Nginx exporter, PHP-FPM exporter e CloudWatch (per client su AWS). Alert su Slack quando request rate supera 3x la baseline oraria.

Playbook di risposta a DDoS

Quando scatta un alert, seguite questo protocollo:

1. Minuto 0-5: verificare se è traffico legittimo (lancio prodotto, viral post). Controllare Cloudflare Analytics o dashboard CDN
2. Minuto 5-10: attivare “I’m Under Attack Mode” su Cloudflare o equivalente. Abbassare rate limit Nginx del 50%
3. Minuto 10-20: analizzare log per identificare pattern (user-agent, referrer, subnet IP). Creare firewall rule temporanee
4. Minuto 20+: se l’attacco persiste, valutare blocco geografico temporaneo o whitelist IP clienti critici con bypass CDN

Documentare ogni intervento. Il 40% degli attacchi DDoS contro le nostre agenzie client nel 2025 erano “smoke screen” per coprire tentativi di intrusione paralleli.

Considerazioni di costo e ROI

Budget tipico per protezione DDoS multi-livello:

• Setup base: Cloudflare Pro + hardening server + monitoring → €30/mese per sito
• Setup intermedio: + Sucuri WAF + Redis managed → €50/mese
• Setup enterprise: Cloudflare Business + Imperva + infrastruttura dedicata → €500+/mese

Il costo di downtime per un e-commerce medio è €5.600/ora (dati Gartner 2025). Un attacco DDoS di 4 ore senza protezione: €22.400 di danno diretto + danni reputazionali. ROI della protezione: positivo già al primo attacco bloccato.

Per agenzie che gestiscono 50+ siti, negoziare un Cloudflare for SaaS plan (da €200/mese per 100 zone) riduce drasticamente i costi rispetto a piani individuali.

FAQ

Cloudflare gratuito è sufficiente per proteggere WordPress da DDoS?

Il piano gratuito Cloudflare offre protezione DDoS Layer 3/4 illimitata, ma limitazioni significative su Layer 7: solo 5 firewall rules, niente rate limiting avanzato, e Page Rules limitate a 3. Per un blog personale va bene, ma per siti client con admin-ajax.php sotto carico o login esposti serve almeno il piano Pro. La differenza principale è la granularità del controllo, non la capacità di assorbire traffico grezzo.

Come distinguere un picco di traffico legittimo da un attacco DDoS?

Indicatori chiave: traffico legittimo mostra distribuzione geografica coerente con l’audience, user-agent variati e realistici, session depth elevata (multiple page views), traffico spalmato su diversi endpoint. Un DDoS invece concentra richieste su 1-2 endpoint, proviene da IP geograficamente sparsi o concentrati in datacenter, usa user-agent ripetitivi o mancanti, e session depth è quasi sempre 1. Analizzare referrer e comportamento post-landing: bot DDoS raramente seguono link interni.

È possibile proteggere XML-RPC senza disabilitarlo completamente?

Sì, con whitelist IP per servizi legittimi. Se usate Jetpack, consentite solo IP di Automattic (disponibili pubblicamente). A livello Nginx: location = /xmlrpc.php { allow 192.0.64.0/18; allow 2a04:fa80::/29; deny all; }. In alternativa, plugin come Disable XML-RPC-API permettono di abilitare solo metodi specifici (es. pingback sì, system.multicall no). Per sicurezza massima, autenticazione OAuth2 su XML-RPC con token rotating ogni 24h.

Quale impatto ha il rate limiting sugli utenti legittimi?

Con configurazione corretta, impatto minimo. Un utente normale su wp-login.php fa 1-3 tentativi in pochi minuti (rate limit di 5/minuto è sicuro). Su admin-ajax.php, anche form complessi raramente superano 20 richieste/minuto. Il parametro burst in Nginx è cruciale: permette temporanei spike senza penalizzare UX. Monitorare 429 response in Cloudflare Analytics: se supera 0.5% del traffico totale, i limiti sono troppo stretti. Testing con utenti reali su reti mobili (latenza alta = retry automatici) è essenziale prima del rollout.

Meglio investire in CDN premium o potenziare il server origin?

CDN premium sempre. Un server da €200/mese con 32 core può servire 5.000 req/s di WordPress dinamico, ma un DDoS da 50.000 req/s lo satura comunque. Cloudflare Business (€200/mese) assorbe Tbps di traffico prima che tocchi il vostro server. Il server origin dovrebbe dimensionarsi per traffico legittimo + 20% buffer, mentre la protezione DDoS va demandata al perimetro. Unica eccezione: se avete già infrastruttura multi-region con Anycast proprio, ma parliamo di budget enterprise (€5k+/mese).