59 30/03/2026 07/04/2026 9 min

Introduzione

La protezione DDoS non è un singolo interruttore, ma una somma di barriere. Se un sito o un servizio viene preso di mira, la differenza la fanno tre cose: filtrare il traffico sospetto prima che arrivi all’applicazione, limitare gli abusi ripetitivi e avere una procedura di mitigazione già pronta.

In questa guida trovi un approccio pratico e realistico per ambienti Linux, hosting, VPS, web server e WordPress/CMS. L’obiettivo non è “bloccare tutto”, ma ridurre l’impatto senza rompere il traffico legittimo.

1. Prima di tutto: capire che tipo di DDoS stai subendo

Non tutti gli attacchi sono uguali. Se confondi il tipo di pressione, rischi di applicare il filtro sbagliato.

  • Volumetrico: saturazione banda o pps, spesso fuori dalla portata del singolo server.
  • Protocollo: abuso di TCP, SYN flood, ACK flood, frammentazione, connessioni incomplete.
  • Applicativo: richieste HTTP/HTTPS ripetute verso pagine pesanti, login, search, XML-RPC, API.

La regola pratica è semplice: se il link è saturo, il server locale non basta. In quel caso serve protezione upstream: CDN, reverse proxy, firewall del provider o servizio anti-DDoS.

Indicatori da osservare

  • CPU alta ma banda normale: spesso attacco applicativo.
  • Banda in ingresso piena e traffico anomalo: volumetrico.
  • Molte connessioni in stato SYN_RECV o CLOSE_WAIT: possibile attacco di protocollo o problemi di tuning.
  • Molti 403/429/5xx nei log: filtro troppo aggressivo o pressione reale.
La prima mitigazione efficace non è “chiudere tutto”, ma capire dove si sta consumando la risorsa: banda, connessioni, CPU, PHP, database o I/O.

2. Architettura difensiva: difesa a strati

Un setup serio non si basa su una sola regola. La struttura più solida è questa:

  1. Upstream protection: CDN, WAF, anti-DDoS del provider, reverse proxy.
  2. Filtro di rete: firewall host, rate limit a livello TCP/UDP se necessario.
  3. Filtro applicativo: web server, WAF, mod_security, regole per URL sensibili.
  4. Protezione dell’app: cache, limiti su login, API, form, XML-RPC, query lente.

Se salti il primo livello, il server si ritrova a combattere da solo. Se curi solo il primo livello, l’attacco applicativo può comunque consumare PHP e MySQL.

3. Filtri di rete: bloccare il rumore prima che arrivi al web server

Il firewall deve fare il minimo indispensabile con regole chiare e reversibili. Su sistemi comuni, le opzioni più pratiche sono nftables, iptables o il firewall del pannello di controllo.

Regole utili in pratica

  • Consenti solo le porte necessarie: 80, 443, SSH, mail e quelle davvero usate.
  • Blocca protocolli o porte inutilizzati.
  • Limita nuove connessioni per IP sulle porte esposte.
  • Proteggi SSH e pannelli con allowlist IP, 2FA e porte non standard solo se davvero utile.

Per un server web, il firewall non deve essere “furbo” in modo eccessivo. Meglio poche regole comprensibili che una catena complessa difficile da mantenere durante un incidente.

Esempio concettuale di difesa

INPUT: consenti established/related, blocca il resto per default, apri solo le porte necessarie, limita i nuovi SYN per IP, logga i drop sospetti con moderazione.

Il logging va dosato: durante un DDoS, loggare ogni pacchetto può peggiorare l’impatto su disco e CPU.

4. Rate limit: la barriera più utile contro gli abusi HTTP

Il rate limit è fondamentale contro il traffico applicativo, i bot aggressivi e gli abusi di endpoint costosi. L’idea è semplice: un client normale può fare un numero ragionevole di richieste, uno aggressivo no.

Dove applicarlo

  • Web server: Nginx, Apache, LiteSpeed.
  • CDN o reverse proxy: limite per IP, paese, ASN, path.
  • Applicazione: login, recupero password, ricerca, checkout, API.

Endpoint da proteggere per primi

  • /wp-login.php
  • /xmlrpc.php
  • /login, /admin, /api
  • ricerca interna, form di contatto, endpoint AJAX

Su WordPress, spesso il problema non è il sito intero ma pochi percorsi molto costosi. Limitare quelli dà più beneficio che alzare potenza del server.

Approccio prudente

  1. Metti un limite moderato.
  2. Osserva i falsi positivi.
  3. Aumenta o abbassa soglia in base ai log.
  4. Escludi IP fidati, webhook e monitor esterni.

Un rate limit fatto male può bloccare clienti reali, crawler legittimi o sistemi di pagamento. La chiave è partire stretti ma non estremi.

5. Mitigazione su Nginx: esempio pratico

Nginx è spesso la prima linea per HTTP/HTTPS. Le direttive più utili sono limit_req e limit_conn.

Prima di modificare i file di configurazione, fai sempre un backup del file interessato.

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%F-%H%M)

Per limitare richieste per IP:

http {
    limit_req_zone $binary_remote_addr zone=perip:10m rate=5r/s;
    limit_conn_zone $binary_remote_addr zone=connperip:10m;

    server {
        location / {
            limit_req zone=perip burst=20 nodelay;
            limit_conn connperip 20;
        }
    }
}

Effetto atteso: un client che supera la soglia viene rallentato o riceve 429 invece di consumare risorse senza limiti.

Controlli dopo la modifica

nginx -t

Esito atteso: configurazione valida.

systemctl reload nginx

Esito atteso: ricarica senza interrompere il servizio.

Se il sito usa CMS con molti asset o chiamate AJAX, non applicare limiti troppo stretti sull’intero sito: spesso conviene proteggere solo i path sensibili.

6. Mitigazione su Apache: mod_evasive, mod_security e limiti di connessione

Apache può essere protetto con moduli dedicati, ma va fatto con criterio. mod_evasive aiuta contro richieste ripetute, mentre mod_security serve più per regole WAF che per puro DDoS.

Buone pratiche

  • Attiva solo i moduli necessari.
  • Evita regole troppo generiche su tutto il traffico.
  • Proteggi login e URL ad alto costo.
  • Verifica gli error log dopo ogni tuning.

Se il traffico è molto alto, Apache puro può diventare il collo di bottiglia: in quel caso il reverse proxy davanti, con Nginx o CDN, è spesso la soluzione più efficace.

7. CDN e reverse proxy: il filtro migliore contro gli attacchi HTTP

Per molte realtà, la protezione più utile è mettere il sito dietro una CDN con WAF e rate limiting. In questo modo il traffico malevolo viene filtrato prima di raggiungere il server origin.

Vantaggi concreti

  • Nascondi l’IP reale del server.
  • Assorbi picchi di traffico e richieste ripetute.
  • Applichi regole per paese, ASN, user-agent e path.
  • Riduci il carico su PHP e database grazie alla cache.

Il punto critico è proteggere l’origin: se l’IP del server resta pubblico, l’attaccante può bypassare la CDN. Per questo bisogna consentire l’accesso all’origin solo dagli IP della CDN o da una rete privata.

Verifica essenziale

  1. Il DNS pubblico punta alla CDN.
  2. L’origin accetta solo traffico autorizzato.
  3. Le intestazioni di risposta mostrano il passaggio dal proxy/CDN.

Se salti il blocco dell’origin, la protezione diventa solo parziale.

8. Protezione applicativa: dove si vince davvero sugli attacchi intelligenti

Molti attacchi DDoS moderni non cercano di saturare la banda, ma di consumare risorse costose. Qui la difesa migliore è ridurre il costo di ogni richiesta.

Interventi ad alto rendimento

  • Cache pagina: riduce PHP e query al database.
  • Object cache: Redis o Memcached per CMS e applicazioni dinamiche.
  • Disabilita endpoint inutili: XML-RPC se non serve, debug in produzione, API non usate.
  • Proteggi login e form: CAPTCHA, 2FA, rate limit, lock temporanei.

Per WordPress, i bersagli classici sono login, XML-RPC, ricerca interna e wp-admin. Non sempre è necessario bloccarli del tutto: spesso basta limitarli e metterli dietro cache e WAF.

9. Rate limit intelligente: non basta il numero, conta il contesto

Un limite statico uguale per tutti è comodo ma rozzo. Dove possibile, conviene distinguere tra traffico buono e sospetto.

  • IP fidati o ufficio: soglie più alte.
  • Bot noti e crawler verificati: eccezioni ragionate.
  • Endpoint sensibili: soglie più basse.
  • Metodi POST su form e login: più severi di GET su contenuti statici.

Se il tuo stack lo consente, usa segnali multipli: frequenza, comportamento, cookie, path, referer, stato di sessione. Più segnali usi, meno falsi positivi avrai.

10. Protezione SSH, pannelli e servizi di amministrazione

Durante un attacco, spesso il bersaglio secondario è l’accesso amministrativo. Se SSH, cPanel, Plesk o altri pannelli restano esposti senza difese, aumenti il rischio di compromissione mentre sei occupato a mitigare il DDoS.

Minimo indispensabile

  • Consenti accesso solo da IP fidati dove possibile.
  • Attiva 2FA sui pannelli.
  • Usa password forti e, se possibile, chiavi SSH.
  • Limita tentativi di login con fail2ban o protezioni equivalenti.

Non confondere protezione DDoS con hardening generale: se un attacco crea distrazione e nel frattempo viene sfruttata una password debole, il problema raddoppia.

11. Come reagire durante un incidente

Quando il sito è sotto pressione, serve una sequenza semplice:

  1. Stabilizza: attiva la protezione upstream più rapida disponibile.
  2. Riduci il costo: cache, blocco temporaneo di endpoint pesanti, rate limit più severo.
  3. Osserva: CPU, RAM, I/O, banda, 4xx/5xx, connessioni attive, slow query.
  4. Raffina: aggiusta le soglie in base ai log reali.

Se il sito è ancora raggiungibile ma lento, spesso conviene mettere una pagina statica temporanea o una modalità maintenance controllata, invece di lasciare l’applicazione pesante esposta a pieno carico.

Cosa controllare subito

  • Web server log: picchi su pochi path.
  • Access log: IP ripetuti, user-agent anomali, pattern regolari.
  • Error log: 429, 403, upstream timeout.
  • Database: query lente o connessioni esaurite.

12. Esempio di strategia concreta per un sito WordPress

Un sito WordPress è spesso bersaglio di richieste ripetute su login, XML-RPC e pagine dinamiche. Una strategia pratica può essere questa:

  1. Metti il sito dietro CDN con WAF.
  2. Blocca l’accesso diretto all’origin se non dalla CDN.
  3. Attiva cache pagina e object cache.
  4. Limita /wp-login.php e /xmlrpc.php.
  5. Proteggi /wp-admin con 2FA e, se possibile, allowlist IP.

Questa combinazione, da sola, spesso riduce drasticamente il carico senza modificare il contenuto del sito.

13. Errori comuni da evitare

  • Bloccare tutto il traffico estero senza analisi: può danneggiare SEO, utenti e servizi legittimi.
  • Applicare rate limit uguali a tutto il sito: rompe risorse statiche e API sane.
  • Loggare troppo durante l’attacco: aumenta I/O e peggiora il problema.
  • Non proteggere l’origin: la CDN perde efficacia.
  • Usare solo un plugin di sicurezza pensando che basti: la difesa deve essere a più livelli.

Il principio giusto è semplice: blocca vicino alla sorgente, limita dove costa di più, osserva sempre gli effetti.

14. Checklist operativa rapida

  1. Identifica il tipo di attacco: banda, connessioni, HTTP o applicativo.
  2. Attiva la protezione upstream più vicina al traffico.
  3. Applica rate limit ai path sensibili, non a caso.
  4. Proteggi origin, pannelli e accessi amministrativi.
  5. Misura dopo ogni cambio: CPU, RAM, I/O, slow query, TTFB e cache hit.

Conclusione

La vera protezione DDoS non è una regola magica, ma un sistema che degrada bene sotto pressione. Filtri, rate limit e mitigazione funzionano davvero quando sono pensati insieme: il filtro riduce il rumore, il rate limit impedisce l’abuso, la mitigazione assorbe il colpo e l’applicazione consuma meno risorse.

Se vuoi che la difesa regga nel tempo, mantienila semplice, reversibile e misurabile. Una protezione che non puoi verificare nei log o tornare indietro in pochi minuti è una protezione fragile.