Cos'è un attacco DDoS?
Un attacco Distributed Denial-of-Service è esattamente ciò che dice il nome: uno sforzo coordinato di molti endpoint per sopraffare un singolo bersaglio con traffico, esaurendo qualche risorsa (larghezza di banda di rete, stato delle connessioni del kernel, thread dell'applicazione, connessioni al database) e rendendo il servizio non disponibile. Gli attacchi DDoS moderni rientrano in tre classi che differiscono nel modo in cui sfruttano il bersaglio.
Gli attacchi volumetrici esauriscono la larghezza di banda grezza della rete. La variante classica è la riflessione-amplificazione — l'attaccante invia pacchetti UDP spoofati a server pubblici (DNS, NTP, Memcached, CLDAP) che rispondono con risposte molto più grandi, moltiplicando la larghezza di banda dell'attaccante da 50x a 50.000x a seconda del protocollo. Gli attacchi volumetrici sono misurati in bit al secondo e i più grandi eventi divulgati pubblicamente hanno superato i 3 Tbps. La mitigazione avviene al perimetro di rete, prima che il traffico raggiunga il tuo server.
Gli attacchi di protocollo esauriscono lo stato delle connessioni a livello di kernel. Gli SYN flood (connessioni TCP half-open), gli ACK flood e vari attacchi con pacchetti malformati rientrano in questa categoria. Sono misurati in pacchetti al secondo. La mitigazione avviene sia al perimetro (con filtri stateless) sia sul server (con ottimizzazione del kernel, SYN cookie, blocco automatico stile fail2ban).
Gli attacchi a livello di applicazione (L7) esauriscono le risorse a livello applicativo. HTTP flood che mirano a endpoint costosi, attacchi slow-loris che tengono aperte le connessioni, query GraphQL che esplodono in pattern N+1. Misurati in richieste al secondo; la mitigazione richiede la comprensione della superficie applicativa e raramente è realizzabile puramente al perimetro di rete — di solito richiede limitazione della velocità a livello applicativo, budget per le query, caching CDN o un WAF.
Ogni classe richiede una mitigazione diversa; gli stack di protezione moderni sovrappongono tutti e tre i livelli. Le cifre in Gbps nei testi di marketing dell'hosting offshore si riferiscono alla capacità volumetrica, ma gli attacchi volumetrici sono solo una delle tre minacce — le altre due richiedono lavoro ingegneristico dal tuo lato.
Come funziona lo scrubbing DDoS moderno
L'infrastruttura che assorbe gli attacchi volumetrici è chiamata "centro di scrubbing" e l'architettura è coerente tra tutti i principali provider (Cloudflare, Akamai, Imperva, NTT) e tra la maggior parte degli host offshore che gestiscono il proprio edge.
Il traffico destinato al tuo IP viene annunciato tramite anycast da più punti geografici. L'anycast consente allo stesso IP di essere raggiungibile da molte località; i protocolli di routing consegnano ogni pacchetto all'edge più vicino automaticamente. Quando è in corso un attacco, il traffico dell'attacco viene distribuito su molti punti edge (perché gli attaccanti sono anch'essi geograficamente distribuiti), e ogni punto edge vede solo una frazione del volume totale.
In ogni punto edge, i filtri di scrubbing classificano il traffico in tempo reale. Il traffico legittimo viene inoltrato alla tua origine; il traffico di attacco viene eliminato all'edge. La classificazione usa una combinazione di regole stateless (elimina IP sorgente spoofati, elimina strutture di pacchetti insolite), euristiche stateful (traccia lo stato delle connessioni e elimina handshake incompleti) e analisi comportamentale (elimina sorgenti che corrispondono a pattern noti di botnet).
L'intera architettura è preventiva — nessun tempo di reazione con intervento umano, nessuna necessità di "attivare" la mitigazione. Una volta che il tuo IP è sull'annuncio anycast protetto, la protezione è sempre attiva. I piani MurmurHost la includono per impostazione predefinita; la pagina delle funzionalità DDoS protection documenta la capacità per ogni livello.
Quale capacità è sufficiente?
Questa è la domanda che la maggior parte dei clienti fa, e la risposta è più sfumata di quanto suggerisca il testo di marketing.
Per la maggior parte dei progetti personali (un blog, un piccolo forum, un'istanza Mastodon per hobby), 10 Gbps di scrubbing sono sufficienti. Gli attacchi che colpiscono i progetti personali sono tipicamente opportunistici — livello script-kiddie, sotto i 10 Gbps, della durata di minuti o ore. I nostri piani di livello base VPS-1 e VPS-2 includono 10 Gbps di scrubbing e questo ha coperto ogni attacco che abbiamo visto contro i clienti con progetti personali nell'ultimo anno.
Per operazioni commerciali modeste (un negozio e-commerce di nicchia, una piccola SaaS, un forum frequentato), 50–100 Gbps è il livello giusto. Gli attacchi a questo livello sono tipicamente motivati — molestie da concorrenti, tentativi di riscatto, attacchi ideologicamente motivati contro commenti specifici — e a volte si protraggono per ore o giorni. I piani di livello medio VPS-4 e VPS-8 includono 100 Gbps di scrubbing.
Per carichi di lavoro ad alta larghezza di banda o ad alto profilo (streaming, adult, server di gioco, nodi di uscita VPN), 200–400 Gbps sono appropriati. Gli attacchi contro questi carichi di lavoro tendono a essere sia più grandi (i mercati commerciali di DDoS-for-hire prendono di mira esplicitamente streaming e adult) sia più lunghi (sostenuti per giorni, a volte settimane). Il nostro livello dedicato — DS-Mid, DS-Pro — include 400 Gbps di scrubbing.
Per carichi di lavoro enterprise con attenzione avversaria sostenuta (attacchi osservati di 1+ Tbps), la pratica standard è di mettere Cloudflare o BunnyCDN davanti all'origine offshore e fare affidamento sulla capacità di assorbimento molto più grande del CDN (multi-Tbps a livello globale) per la protezione L3/L4. Il livello gratuito di Cloudflare include una protezione utile; i livelli a pagamento aggiungono capacità WAF e di gestione dei bot. Supportiamo esplicitamente questo pattern — vedi la nostra pagina delle funzionalità DDoS protection.
La tabella seguente riassume i livelli di protezione MurmurHost:
| Livello del piano | Scrubbing volumetrico | Applicazione |
|---|---|---|
| Condiviso, VPS-1, VPS-2 | 10 Gbps | Personale, hobby |
| VPS-4, VPS-8, RDP-Pro | 100 Gbps | Commerciale, traffico medio |
| VPS-16, DS-Lite | 200 Gbps | Alto traffico |
| DS-Mid, DS-Pro, DS-Beast, piani GPU | 400 Gbps | Streaming, adult, sostenuto |
| Enterprise personalizzato | 1+ Tbps | Livello sovrano, cross-CDN |
Tattiche edge — regole a livello di applicazione, limitazione della velocità
Il livello di scrubbing volumetrico gestisce gli attacchi L3/L4. Gli attacchi a livello di applicazione richiedono lavoro ingegneristico al tuo edge applicativo. Tre pattern contano di più:
Limitazione della velocità. Limita le richieste per IP, per sessione o per endpoint. L'implementazione più semplice è tramite Nginx (limit_req_zone), HAProxy o il middleware della tua applicazione. Approcci più sofisticati — token-bucket per identità, sliding-window per endpoint — richiedono più configurazione ma assorbono gli attacchi a raffica in modo più elegante. Il rapporto giusto dipende dai tuoi normali pattern di traffico: se il tuo utente legittimo più attivo fa 50 richieste al minuto, imposta il limite a 200/minuto, non a 30.
Regole WAF. Un Web Application Firewall ispeziona i payload delle richieste e blocca i pattern che corrispondono a firme di attacco note (SQL injection, XSS, impronte comuni di bot). Il WAF di Cloudflare, modsecurity (con l'OWASP Core Rule Set) e il WAF di BunnyCDN funzionano tutti per host offshore. Il WAF vive al tuo edge CDN se ne hai uno, o davanti al tuo server applicativo se non lo hai.
Cloudflare o BunnyCDN davanti. Oltre al WAF, un CDN assorbe l'attacco a un livello che scala molto oltre qualsiasi singola origine. Cloudflare in particolare è stata la pratica standard nell'hosting offshore per un decennio — funziona bene davanti a un'origine nei Paesi Bassi o in Islanda, e il livello gratuito fornisce una protezione significativa da solo. Documentiamo la configurazione canonica Cloudflare-più-origine-offshore sulla nostra pagina delle funzionalità.
Tarpitting e meccanismi di sfida
Per attacchi L7 sostenuti a basso volume (bot sofisticati, scraper, takeover di account scriptati), i meccanismi di sfida espliciti diventano utili.
Sfida JS. La modalità "I'm Under Attack" di Cloudflare e funzionalità simili iniettano una piccola sfida JavaScript che i browser legittimi superano automaticamente; i bot che non eseguono JS vengono filtrati. Economico, efficace, trasparente per gli utenti legittimi.
Gate CAPTCHA. Quando la sfida JS è insufficiente, un vero CAPTCHA sugli endpoint sospetti filtra gli umani dai bot avanzati. Il costo di attrito è reale — i tassi di abbandono aumentano — quindi usalo con parsimonia e solo su endpoint sotto attacco sostenuto.
Sfide proof-of-work. mCaptcha, Anubis e strumenti simili richiedono al client di calcolare una piccola prova di lavoro prima che la richiesta venga elaborata. Il costo economico per l'attaccante scala linearmente con il tasso di attacco; il costo per un utente legittimo è invisibile (qualche centinaio di millisecondi al massimo). Questo pattern ha guadagnato trazione nel 2025–2026 specificamente contro lo scraping AI e le campagne di credential-stuffing.
Tarpitting. Rallentare le risposte al traffico sospetto senza rifiutarlo esplicitamente. Efficace contro bot semplici che tengono aperte le connessioni finché non ricevono una risposta; meno efficace contro strumenti di attacco moderni che vanno in timeout e passano oltre.
Economia del DDoS: chi paga cosa
L'economia della protezione DDoS è di solito opaca per i clienti. In sintesi:
- La capacità di scrubbing volumetrico è il livello più costoso per l'host. Un livello di scrubbing da 10 Gbps su larga scala costa al provider circa $0,01–0,10 per GB protetto di traffico di attacco, che si somma a un overhead non banale per carichi di lavoro ad alto profilo. La maggior parte dei provider include un livello base nel prezzo del piano e addebita la capacità "premium" oltre quello.
- Il peering anycast è moderatamente costoso — hai bisogno di presenza fisica in più internet exchange point. Per lo più un costo fisso.
- Le regole WAF e la protezione L7 sono economiche rispetto allo scrubbing — la maggior parte del costo è nel mantenere il set di regole, non nella CPU.
MurmurHost include il livello base completo su ogni piano. Lo scrubbing premium (sopra la capacità del livello del piano, per attacchi sostenuti di 1+ Tbps) è una conversazione di upgrade a livello enterprise, non un addebito per attacco. Non fatturiamo in base al volume di attacco; gli attacchi sostenuti sopra la capacità del piano innescano una conversazione con il cliente sull'upgrade del livello del piano, non una fattura a sorpresa.
Cosa puoi fare a livello applicativo
La protezione DDoS più efficace è non essere un bersaglio, e la seconda più efficace è mantenere la tua applicazione economica da servire. Leve specifiche:
Cache in modo aggressivo. I contenuti statici serviti da un CDN (o anche da Nginx locale con una direttiva di cache) non costano nulla all'origine. I contenuti dinamici memorizzati nella cache per brevi finestre (5–60 secondi per la maggior parte delle pagine) assorbono i picchi di traffico senza richiedere l'elaborazione completa dell'origine.
Rendi economici gli endpoint dinamici. Una richiesta che colpisce il database a ogni caricamento di pagina è molto più vulnerabile di una che colpisce Redis. Spingi i calcoli costosi a worker in background, restituisci dati cached o eventualmente consistenti sul percorso della richiesta.
Imposta budget per le query. Le API GraphQL sono particolarmente vulnerabili agli attacchi di amplificazione — una singola richiesta dell'attaccante può innescare migliaia di query al database. Imposta limiti di profondità delle query, limiti di complessità delle query e budget per query per IP.
Separa i percorsi di lettura e scrittura. Il traffico pesante in lettura non dovrebbe mai competere con il traffico pesante in scrittura per lo stesso pool di connessioni al database. Le repliche di lettura gestiscono gli attacchi in lettura con eleganza; gli attacchi in scrittura sono di volume inferiore e più facili da limitare.
Monitora e allerta. Un attacco di 10 minuti che non noti è per lo più un non-evento. Un attacco di 10 minuti che noti ti dà il tempo di attivare le protezioni (attiva la modalità I'm-Under-Attack di Cloudflare, implementa regole WAF di emergenza, contatta il supporto). Anche il monitoraggio di base (carico del server, tasso di richieste, tasso di errori 5xx) è sufficiente per la prima risposta.
Piani con protezione DDoS integrata
Piani MurmurHost selezionati, ordinati per caso d'uso tipico:
- Progetti personali, hobby: VPS-1 ($8/mese, 10 Gbps), Shared Pro ($7,99/mese, 10 Gbps).
- Piccole imprese commerciali: VPS-2 ($16/mese, 10 Gbps), VPS-4 ($32/mese, 100 Gbps).
- Streaming, adult, seedbox: VPS-8 ($64/mese, 100 Gbps), Stream-1 (livello ad alta larghezza di banda).
- Server di gioco: Game-M (filtri UDP di grado gaming), Game-L.
- Dedicati sostenuti ad alto profilo: DS-Mid ($149/mese, 400 Gbps), DS-Pro, DS-Beast.
- Inferenza GPU e ML: GPU-Pro, GPU-Beast — protetti da 400 Gbps di scrubbing come i dedicati.
Il menu completo è su /pricing e la ripartizione per funzionalità su /features/ddos-protection.
Conclusione
La protezione DDoS è un problema risolto a livello volumetrico — ogni host offshore credibile nel 2026 include una capacità di scrubbing sostanziale per impostazione predefinita. Il lavoro rimanente avviene a livello applicativo, dove caching economico, limitazione della velocità, budget per le query e monitoraggio di base chiudono la maggior parte della superficie residua. Il livello di piano giusto è determinato dal tuo caso d'uso più che dalle previsioni sulla dimensione dell'attacco: i progetti personali hanno bisogno di 10 Gbps, il commerciale a traffico medio di 100 Gbps, e i carichi di lavoro ad alto profilo di 400 Gbps con Cloudflare davanti. Scegli il livello che corrisponde al tuo carico di lavoro dalla pagina dei prezzi e abbinalo a un'ingegneria sensata a livello applicativo. Per i modelli di minaccia che lo giustificano, la pagina delle funzionalità DDoS protection copre la capacità per livello in dettaglio.