Un DDoS (Distributed Denial of Service) è un attacco che cerca di rendere indisponibile un sito, un server o un servizio online sovraccaricandolo con traffico proveniente da molte sorgenti. Il punto non è necessariamente “entrare” nel sito o rubare dati: l’obiettivo principale è consumare abbastanza banda, connessioni o risorse applicative da impedire agli utenti reali di utilizzare il servizio.
La parte più importante da capire è questa: non esiste una singola impostazione anti-DDoS capace di fermare qualsiasi attacco. Una difesa efficace deve intervenire nel punto giusto dell’infrastruttura. Un plugin WordPress può essere utile contro alcune richieste applicative abusive, ma non può risolvere un attacco che ha già saturato la connettività del server.
Per questo vedremo come funziona un DDoS, quali forme può assumere, come distinguere un attacco da un normale problema di hosting e soprattutto dove deve essere applicata la mitigazione.
DDoS: significato e differenza tra DoS e DDoS
DDoS significa Distributed Denial of Service, cioè negazione distribuita del servizio. Anche il CERT-AGID definisce il DDoS come un attacco che provoca deliberatamente la saturazione delle risorse di un sistema fino a impedirgli di erogare correttamente il servizio.
La differenza fra DoS e DDoS riguarda soprattutto la provenienza del traffico.
Un attacco DoS può essere generato da una singola sorgente. In un DDoS, invece, le richieste arrivano contemporaneamente da molti sistemi distribuiti. Questo rende molto meno efficace la semplice strategia del “blocco l’IP che mi sta attaccando”.
Perché un attacco DDoS è distribuito
Dietro molti attacchi DDoS c’è una botnet, cioè una rete di computer, server, dispositivi IoT o altri sistemi compromessi e controllati da remoto.
Il proprietario del dispositivo coinvolto può anche non sapere che la propria macchina sta partecipando all’attacco. Quando i sistemi della botnet iniziano a generare traffico verso lo stesso bersaglio, la vittima vede arrivare richieste da numerosi indirizzi e reti differenti.
È proprio questa distribuzione a complicare la mitigazione: bloccare una sorgente non elimina le altre.
Botnet e sorgenti multiple: perché bloccare un singolo IP non basta
In un attacco semplice, individuare una sorgente anomala e bloccarla può ridurre immediatamente il problema. Con un DDoS questa logica smette rapidamente di funzionare.
Puoi avere migliaia di client che inviano richieste contemporaneamente, indirizzi che cambiano e traffico che, preso singolarmente, non appare necessariamente anomalo. Inoltre una parte delle richieste può assomigliare molto al comportamento di visitatori reali.
La domanda utile quindi non è soltanto “quale IP devo bloccare?”, ma “quale risorsa sta venendo saturata e quanto a monte posso filtrare il traffico?”.
Come funziona un attacco DDoS
Un sito non ha risorse infinite. La connessione di rete ha una capacità, il web server può gestire un certo numero di connessioni, PHP dispone di un numero finito di worker, il database può elaborare una quantità limitata di query e ogni applicazione ha operazioni più o meno costose.
Un attacco DDoS cerca di portare uno o più di questi componenti oltre la capacità disponibile.
In pratica il percorso può essere rappresentato così:
Internet → rete/provider → CDN o reverse proxy → server origin → web server → applicazione → database
Un attacco può tentare di saturare uno dei primi livelli oppure arrivare fino all’applicazione.
Saturare banda, connessioni o risorse applicative
Se il bersaglio è la banda, un volume enorme di traffico può riempire la capacità della connessione prima ancora che WordPress o un’altra applicazione possano fare qualcosa.
Altri attacchi puntano alle connessioni e agli stati mantenuti dall’infrastruttura di rete, costringendo server e apparati a gestire quantità anomale di sessioni o pacchetti.
Un DDoS applicativo lavora invece più in alto: le richieste possono raggiungere realmente il web server e richiedere elaborazioni costose. Su WordPress, per esempio, una richiesta dinamica può coinvolgere PHP, plugin, tema, query database e servizi esterni.
Per questo due attacchi DDoS possono produrre lo stesso risultato — sito irraggiungibile — ma richiedere contromisure differenti.
Un DDoS non significa necessariamente che il sito sia stato violato
È importante separare disponibilità e compromissione.
Un DDoS mira principalmente a impedire l’accesso a un servizio. Questo, da solo, non dimostra che qualcuno abbia ottenuto accesso al server, modificato file o sottratto dati.
Al tempo stesso un incidente di disponibilità non è una ragione per ignorare gli altri segnali di sicurezza. Se durante l’attacco compaiono login anomali, modifiche ai file, account sconosciuti o altre attività sospette, vanno analizzati come eventi distinti.
Tipi di attacchi DDoS: rete, protocollo e livello applicativo
Non esiste una tassonomia unica usata nello stesso modo da tutti i provider, ma una suddivisione operativa molto comune distingue attacchi volumetrici, attacchi che colpiscono protocolli o risorse di rete e attacchi applicativi. Anche la panoramica tecnica di Cloudflare sui DDoS utilizza questa distinzione.
| Tipo di attacco | Bersaglio principale | Effetto tipico | Dove deve iniziare la difesa |
|---|---|---|---|
| Volumetrico | Banda e capacità di rete | Connessione saturata, servizio irraggiungibile | Provider, rete di mitigazione, edge |
| Protocollo / rete | Connessioni, apparati, stack di rete | Esaurimento delle risorse di rete | Provider, firewall e protezione L3/L4 |
| Applicativo / Layer 7 | HTTP, API, applicazione, backend | CPU, worker o database sotto pressione | Edge, rate limiting, WAF, applicazione |
Attacchi volumetrici e amplification
Gli attacchi volumetrici cercano di generare abbastanza traffico da occupare la capacità disponibile fra Internet e il bersaglio.
Una variante è l’amplification, nella quale una piccola quantità di traffico generata dall’attaccante produce risposte molto più grandi indirizzate verso la vittima. Il principio è sfruttare servizi di rete che rispondono con più dati di quanti ne ricevano.
In questo scenario il problema nasce molto prima di WordPress. Se la linea o l’infrastruttura davanti al server sono già sature, installare un plugin nel CMS non può recuperare la capacità di rete perduta.
Attacchi ai protocolli e alle connessioni
Altri attacchi cercano di consumare le risorse utilizzate per gestire connessioni e protocolli.
Il bersaglio può essere il server stesso oppure un componente intermedio: firewall, load balancer, router o altro apparato che deve mantenere informazioni sullo stato delle comunicazioni.
Anche in questo caso la difesa deve essere sufficientemente a monte da impedire al traffico dannoso di consumare prima le risorse che stai cercando di proteggere.
Attacchi Layer 7 e HTTP flood
Gli attacchi Layer 7 prendono di mira il livello applicativo. Una richiesta HTTP può essere perfettamente valida dal punto di vista del protocollo ma diventare problematica quando viene ripetuta su larga scala.
È qui che strumenti come rate limiting, bot management e Web Application Firewall diventano particolarmente interessanti.
Serve però una distinzione: un WAF non equivale automaticamente a una soluzione DDoS completa. Può filtrare traffico HTTP indesiderato, applicare regole o limitare determinate richieste, ma un attacco volumetrico può saturare l’infrastruttura prima che un WAF installato vicino all’applicazione riesca a intervenire.
Come capire se un sito è sotto attacco DDoS
Un sito lento o irraggiungibile non è automaticamente sotto DDoS.
Un aggiornamento difettoso, una query database pesante, la saturazione dei PHP worker, un problema del provider o un picco legittimo di visitatori possono produrre sintomi molto simili.
Per diagnosticare correttamente il problema devi mettere in relazione traffico, errori, risorse e log nello stesso intervallo temporale.
Picchi di traffico, latenza, errori e consumo delle risorse
I segnali che meritano attenzione includono picchi improvvisi di richieste, un forte aumento delle connessioni, latenze anomale, errori 5xx, esaurimento dei worker, CPU molto alta o richieste ripetute verso gli stessi endpoint.
Nessuno di questi elementi, isolatamente, prova un DDoS.
Un 503 Service Unavailable, per esempio, indica che il servizio non riesce temporaneamente a gestire la richiesta, ma non spiega la causa. La nostra guida all’errore 503 mostra perché conviene prima capire quale componente della catena sta fallendo.
DDoS, picco di traffico o problema del server: come distinguerli
Il confronto più utile è tra ciò che accade all’edge e ciò che arriva realmente all’origin.
Se una CDN registra un volume enorme ma il server origin riceve soltanto una parte controllata del traffico, la mitigazione sta probabilmente lavorando prima del backend.
Se invece crescono contemporaneamente richieste all’origin, CPU, connessioni, processi PHP e query database, devi capire quali endpoint stanno generando il carico e se il traffico è legittimo.
Anche la forma del traffico conta. Un improvviso aumento di visitatori distribuiti fra molte pagine può essere molto diverso da milioni di richieste concentrate su pochi endpoint o da schemi ripetitivi incompatibili con l’uso normale del sito.
La diagnosi deve quindi partire dai dati, non dall’idea che “molto traffico = DDoS”.
Come proteggersi da un attacco DDoS
La protezione più efficace è a strati. Ogni controllo deve fermare ciò che può gestire prima che il traffico raggiunga una risorsa più costosa.
Una buona architettura cerca quindi di ridurre progressivamente le richieste:
rete di mitigazione → edge/CDN → WAF e rate limiting → origin → applicazione
Più tardi intervieni, più risorse del tuo server sono già state consumate.
Mitigazione upstream e protezione del provider
Contro gli attacchi che colpiscono banda o protocolli, la prima linea di difesa non può essere WordPress.
Serve un provider o una rete capace di assorbire, filtrare o deviare il traffico prima che raggiunga la capacità limitata del tuo server.
Quando scegli un’infrastruttura, quindi, non guardare soltanto spazio disco, CPU nominale e prezzo. Nella nostra guida alla scelta dell’hosting vale la pena considerare anche quali misure di rete, monitoraggio e mitigazione il provider mette realmente a disposizione e come viene gestito un incidente.
CDN e reverse proxy: bloccare il traffico prima dell’origin
Una CDN o un reverse proxy possono diventare una parte molto importante della difesa perché si posizionano davanti al server origin.
La cache riduce il numero di richieste che devono raggiungere il backend e una piattaforma edge può filtrare traffico anomalo prima che consumi PHP, database e risorse del server. È uno dei motivi per cui servizi come Cloudflare vengono utilizzati anche come livello di sicurezza oltre che come CDN.
Ma avere una CDN non significa automaticamente avere un’architettura resistente ai DDoS.
Se l’indirizzo IP dell’origin è ancora raggiungibile direttamente, un aggressore può tentare di bypassare il proxy e colpire il server senza attraversare i controlli dell’edge.
WAF e rate limiting per gli attacchi Layer 7
Quando il traffico arriva via HTTP, un WAF può analizzare le richieste e applicare regole prima che vengano elaborate dall’applicazione.
Il rate limiting aggiunge un’altra possibilità: limitare la frequenza con cui determinate richieste possono raggiungere endpoint sensibili o costosi.
Può essere utile su login, API, ricerche interne e altre funzioni in cui un volume anomalo di richieste genera un costo applicativo sproporzionato.
Il criterio, però, non deve essere “blocchiamo tutto ciò che supera una soglia arbitraria”. Una configurazione troppo aggressiva può fermare utenti legittimi, crawler, integrazioni e API reali.
Un buon rate limiting nasce dal comportamento normale dell’applicazione.
Proteggere e non esporre l’IP del server origin
Questo passaggio viene spesso trascurato.
Se hai scelto un reverse proxy proprio per evitare che le richieste arrivino direttamente al server, lasciare l’origin liberamente accessibile da Internet crea una strada alternativa.
La documentazione Cloudflare sulla protezione dell’origin raccomanda, quando l’architettura lo permette, di usare record proxied e limitare l’accesso al server alle connessioni provenienti dalla rete autorizzata.
Va controllato anche se altri record DNS o vecchie configurazioni espongono l’indirizzo origin.
Se l’IP è già noto ed è stato bersagliato direttamente, può essere necessario valutarne la sostituzione insieme al provider e impedire che quello nuovo venga nuovamente esposto.
Monitoring, alert e piano di risposta
La protezione DDoS non dovrebbe iniziare quando il sito è già offline.
Devi poter sapere qual è il traffico normale, quanto carico regge il server, quali errori iniziano a comparire e quali endpoint consumano più risorse.
Un sistema di monitoring utile dovrebbe permetterti almeno di correlare traffico, stato HTTP, latenza, CPU, memoria, connessioni, worker e log.
Questa baseline trasforma un generico “il sito è lento” in una diagnosi molto più utile: il traffico è aumentato, ma dove sta effettivamente finendo la capacità?
Cosa fare se un attacco DDoS è già in corso
Durante un incidente l’obiettivo non è modificare a caso WordPress finché il sito riparte. Devi individuare il livello sotto pressione e spostare la mitigazione il più possibile verso monte.
- Verifica che sia realmente un problema di traffico. Controlla stato del provider, CDN, errori e metriche server prima di attribuire automaticamente il downtime a un DDoS.
- Coinvolgi subito hosting o provider di mitigazione. Se la connettività è già satura, il server da solo non può recuperarla.
- Controlla cosa sta passando dall’edge. Se hai già una piattaforma di protezione, verifica eventi DDoS, richieste anomale, endpoint colpiti e regole attive.
- Riduci il traffico applicativo non necessario. Rate limiting, regole WAF e challenge possono essere utili contro specifici pattern Layer 7, purché non blocchino le funzioni necessarie.
- Proteggi l’origin. Se il traffico sta bypassando il proxy, valuta con il provider restrizioni di rete e, quando necessario, la sostituzione di un origin IP già esposto.
- Conserva i dati dell’incidente. Log, orari, metriche, pattern delle richieste e interventi effettuati servono per capire cosa ha funzionato e correggere l’architettura prima del prossimo evento.
Bloccare manualmente centinaia o migliaia di singoli IP raramente è una strategia sostenibile per un vero attacco distribuito. Il traffico va classificato e filtrato al livello più adatto.
DDoS e WordPress: cosa serve davvero e cosa non basta
WordPress aggiunge un livello applicativo importante, ma non cambia la fisica dell’infrastruttura.
Se l’attacco satura la rete prima che la richiesta raggiunga il CMS, WordPress non può difendersi da solo. Se invece l’aggressore sta consumando PHP, database o specifici endpoint HTTP, allora configurazioni applicative e controlli WordPress possono diventare parte della mitigazione.
La distinzione evita anche di confondere la normale sicurezza WordPress con la protezione DDoS. Aggiornare core, plugin e temi resta essenziale per ridurre le vulnerabilità, ma non aumenta magicamente la capacità della rete di assorbire un flood.
Cloudflare e protezione all’edge prima di WordPress
Su un sito WordPress, uno dei modelli più utili consiste nel far terminare il traffico pubblico su una piattaforma edge e lasciare che soltanto quello ammesso prosegua verso il server.
Il percorso diventa:
visitatore → edge/CDN → controlli di sicurezza → origin → WordPress
In questo modo cache, protezione DDoS, WAF e rate limiting possono lavorare prima che ogni richiesta consumi risorse PHP.
Se utilizzi questa architettura, la configurazione deve però essere completa. Nella guida su come configurare Cloudflare con WordPress trovi il passaggio specifico fra DNS, proxy, CDN e CMS.
XML-RPC: quando limitarlo e perché non ferma un DDoS volumetrico
xmlrpc.php è un endpoint storico di WordPress utilizzato da alcune integrazioni e funzionalità remote.
In passato la funzione pingback è stata sfruttata per generare traffico distribuito attraverso installazioni WordPress. Per questo, se non utilizzi funzionalità che dipendono da XML-RPC, limitarne le funzioni non necessarie può ridurre una specifica superficie di abuso.
È però sbagliato trasformare questa misura in una protezione DDoS generale.
Disabilitare XML-RPC non impedisce a una botnet di saturare la tua connessione né blocca automaticamente un HTTP flood indirizzato verso altri endpoint.
La nostra guida dedicata spiega più precisamente cos’è XML-RPC in WordPress e quando ha senso limitarlo.
Perché disabilitare la REST API non è una soluzione DDoS
Qui conviene correggere un consiglio che circola ancora in molte vecchie guide WordPress: disabilitare completamente la REST API non dovrebbe essere la risposta standard a un problema DDoS.
Il REST API Handbook ufficiale di WordPress specifica che la REST API non dovrebbe essere disabilitata perché funzioni dell’amministrazione dipendono dalla sua disponibilità.
Se un endpoint API viene abusato, la soluzione più precisa consiste nel capire chi deve accedervi, applicare autenticazione dove necessaria e usare controlli come WAF o rate limiting quando appropriati.
Spegnere indiscriminatamente l’intera API può rompere funzionalità senza risolvere il vero collo di bottiglia.
Plugin di sicurezza: dove possono aiutare e dove no
Un plugin di sicurezza può bloccare determinate richieste, applicare regole, limitare login abusivi o rilevare comportamenti sospetti.
Il suo limite è dove viene eseguito.
Se per arrivare al plugin la richiesta ha già attraversato la connessione del server, il web server e magari PHP, una parte del costo dell’attacco è già stata sostenuta.
Per questo, contro un DDoS importante, preferirei sempre bloccare ciò che è possibile prima dell’origin, lasciando al plugin il lavoro strettamente applicativo che ha senso svolgere dentro WordPress.
DDoS e SEO: cosa succede se il sito rimane offline
Un DDoS non provoca una “penalizzazione SEO” automatica.
Il problema reale è la disponibilità. Se Googlebot prova a visitare un URL mentre il server restituisce errori, Google può ridurre temporaneamente la frequenza di scansione. Se gli errori server continuano abbastanza a lungo, gli URL possono infine uscire dall’indice.
La documentazione Google sui problemi di disponibilità e scansione distingue chiaramente questi effetti da una penalizzazione algoritmica per violazione delle norme.
Questo significa anche che non conviene nascondere un’indisponibilità restituendo una normale pagina 200 OK con scritto “sito non disponibile”.
Quando il servizio è realmente temporaneamente indisponibile, un vero stato 503 Service Unavailable comunica correttamente la condizione. Nella nostra guida sul 503 Service Unavailable trovi anche la differenza rispetto agli altri errori server e il ruolo dell’header Retry-After.
La priorità resta comunque riportare l’infrastruttura in condizioni normali. I codici HTTP descrivono correttamente il problema; non sostituiscono la mitigazione.
Domande frequenti sugli attacchi DDoS
Quanto può durare un attacco DDoS?
Non esiste una durata standard. Un evento può essere breve e molto intenso oppure ripresentarsi in più ondate. Per questo è più utile preparare procedure di rilevamento e mitigazione che basarsi sull’idea di poter semplicemente aspettare che termini.
Un attacco DDoS può rubare dati?
Il denial of service ha come obiettivo principale l’indisponibilità del servizio, non l’esfiltrazione dei dati. Un DDoS, da solo, non dimostra quindi una violazione dei dati.
Durante un incidente conviene comunque controllare separatamente eventuali segnali di compromissione. Disponibilità e accesso non autorizzato sono problemi differenti e possono verificarsi anche nello stesso intervallo temporale.
Un sito dietro una CDN può comunque subire un DDoS?
Sì. Dipende dal tipo di attacco, dalle capacità del servizio utilizzato e dalla configurazione.
Una CDN può ridurre enormemente il traffico che raggiunge l’origin e una piattaforma edge può integrare mitigazione DDoS, WAF e rate limiting. Ma se il server origin resta direttamente raggiungibile o altri servizi sono esposti al di fuori dell’edge, quella protezione può essere aggirata.
Conclusione
Se devi ricordare un solo principio, è questo: un DDoS va fermato il più possibile prima della risorsa che può essere saturata.
Per un attacco volumetrico significa lavorare con provider e infrastruttura di rete. Per traffico HTTP abusivo diventano importanti edge, WAF e rate limiting. Su WordPress, XML-RPC, plugin di sicurezza e hardening possono completare la difesa, ma non devono essere scambiati per una protezione DDoS universale.
Quindi non partire dalla domanda “quale plugin anti-DDoS installo?”. Parti da rete → edge → origin → applicazione e individua il livello che rischia di esaurire per primo le proprie risorse.
È da lì che deve iniziare la mitigazione.