Protezione DDoS per siti web: cosa aiuta davvero

Una buona protezione DDoS per un sito web non è un singolo prodotto ma un insieme di livelli, ognuno dei quali ferma un tipo diverso di attacco: il filtraggio di rete contro i flood grezzi, un reverse proxy davanti al sito, regole contro gli attacchi a livello applicativo e un server di origine che parla solo con quel proxy. Conta soprattutto il momento, perché una protezione già attiva funziona dalla prima richiesta, mentre una protezione aggiunta nel mezzo di un attacco ti costa ore. Se il tuo sito è sotto attacco proprio ora, vai alla pagina per i siti sotto attacco oppure alla nostra guida su cosa fare quando il sito è sotto attacco DDoS.

Perché la protezione va messa davanti al server

Un server impegnato a rispondere a richieste spazzatura non può anche decidere quali richieste siano spazzatura. Quando una regola del firewall o un plugin di sicurezza sul tuo server esamina una richiesta, la banda è già consumata e spesso PHP è già partito. Una protezione efficace filtra il più lontano possibile dall'origine.

In ottica di prevenzione, la domanda utile è quale livello ferma quale tipo di attacco:

Nessun livello copre tutto da solo: un proxy senza protezione dell'origine può essere aggirato, e un'origine protetta ma senza proxy affronta da sola ogni HTTP flood.

I quattro livelli nel dettaglio

1. Livello di rete: flood volumetrici e di protocollo

Gli attacchi volumetrici riempiono la connessione del tuo server con più traffico di quanto possa trasportarne. Nessuna configurazione sul server aiuta, perché il collegamento è saturo prima ancora che il firewall veda un pacchetto. Questo livello viene gestito a monte dalla rete del tuo hosting o da un servizio di scrubbing dedicato. Il tuo compito è sapere cosa fa il tuo hosting qui e nascondere l'IP di origine dietro un proxy, così gli attaccanti devono inondare la rete del proxy invece della connessione del tuo server.

2. Un reverse proxy davanti all'intero sito

Un reverse proxy per l'intero sito riceve ogni richiesta al tuo dominio, risponde dalla cache a ciò che può e inoltra il resto all'origine. Contano due effetti:

• Le pagine in cache costano poco. Un flood contro la tua homepage è innocuo se la homepage viene servita dall'edge e non raggiunge mai il server.
• Il filtraggio avviene prima dell'origine. Regole, rate limit e challenge girano sull'edge, quindi le richieste bloccate non costano nulla al tuo server.

Assicurati che il proxy copra il tuo HTML. Un CDN per gli asset che serve solo immagini e script da un hostname separato accelera il sito, ma le richieste delle pagine vanno ancora dritte al tuo server, e con loro anche gli attacchi. La guida su cos'è un CDN spiega la differenza.

3. WAF, rate limiting e regole anti-bot per il livello 7

I flood a livello applicativo sono gli attacchi più comuni contro siti piccoli e medi e i più difficili da riconoscere, perché ogni richiesta sembra legittima. Prendono di mira gli URL che fanno lavorare di più il server, quindi pianifica le tue regole attorno a quelli:

Un web application firewall (WAF) con set di regole gestiti blocca anche i tentativi di exploit come SQL injection e cross-site scripting, e le regole anti-bot tengono lontani gli scraper. Le regole per paese aiutano se servi pochi mercati, ma preferisci una challenge a un blocco netto, così i clienti che usano una VPN riescono comunque a passare.

4. Protezione dell'origine

Un proxy ti protegge solo se gli attaccanti non possono aggirarlo. Una volta che il sito è dietro un proxy, blinda l'origine:

• Accetta traffico web solo dal proxy. Configura il firewall del server o dell'hosting in modo che le porte 80 e 443 accettino connessioni solo dagli intervalli di IP pubblicati dal tuo fornitore di proxy.
• Dai per scontato che i vecchi record DNS siano noti. Se il dominio puntava direttamente al server, i servizi che archiviano lo storico DNS rendono quell'IP facile da trovare. Chiedi al tuo hosting se puoi avere un nuovo IP dopo il passaggio.
• Controlla i sottodomini. Record come staging, dev, ftp, cpanel o mail puntano spesso direttamente allo stesso server e ne rivelano l'origine.
• Separa la posta dal server web. Se il tuo record MX punta al server web, o se il server invia da solo le email del modulo di contatto, il suo IP compare nel DNS e negli header Received di ogni email. Controlla anche nel record SPF le voci ip4: che tradiscono il server.

Un controllo veloce mostra quali record puntano al tuo IP di origine:

dig +short example.com A
dig +short mail.example.com A
dig +short example.com MX
dig +short example.com TXT

Ogni risposta che contiene l'IP del tuo server è una scorciatoia per aggirare il proxy.

Cosa copre il tuo hosting e cosa no

Molti hosting filtrano i grandi attacchi volumetrici ai margini della propria rete. Questo protegge la loro infrastruttura e tutti i clienti che ci stanno sopra, ma non equivale a proteggere il tuo sito. Le lacune tipiche:

• I flood di livello 7 passano. Qualche centinaio di richieste HTTP al secondo è poca cosa per la rete di un data center, ma basta a sovraccaricare un tipico CMS o negozio online.
• Il null routing ti manda offline. Se un attacco minaccia la rete, alcuni hosting smettono di instradare il traffico verso l'IP colpito. Gli altri clienti sono al sicuro, il tuo sito è giù.
• I limiti di risorse si fanno sentire. Sui piani condivisi o gestiti, un attacco può spingere il tuo account oltre i limiti di CPU o di processi, e il sito viene rallentato.
• Niente regole per singolo sito. Di solito non puoi impostare rate limit o challenge personalizzati a livello di rete dell'hosting.

Fai queste domande al tuo hosting e conserva le risposte:

1. Quali tipi di attacco filtrate, e il filtraggio degli HTTP flood (livello 7) fa parte del mio piano?
2. Cosa succede al mio sito durante un grande attacco: rallentamento, null routing, sospensione?
3. Posso limitare il mio server in modo che accetti traffico web solo dagli intervalli di IP di un proxy?
4. Come contatto l'assistenza durante un attacco?

Come scegliere un servizio di protezione

Se il tuo hosting copre il livello di rete ma non l'applicazione, un servizio basato su proxy colma la lacuna. Confronta per criteri, non per etichette di marketing:

• Copertura dell'intero sito. Fa da proxy al tuo HTML, non solo agli asset statici.
• Sempre attivo. Un filtraggio permanente non richiede alcun passaggio durante un attacco. Con i servizi on demand, il tempo di attivazione è proprio il problema.
• Strumenti di livello 7 sotto il tuo controllo. Rilevamento automatico più blocchi IP, regole per paese, challenge e rate limit impostati da te.
• Cache sicura e visibilità. Rispetta i tuoi header Cache-Control, non mette mai in cache carrelli o pagine degli utenti loggati e mostra richieste ed errori con avvisi.
• I bot buoni continuano a funzionare. Crawler dei motori di ricerca e callback dei pagamenti passano anche quando le regole si fanno più severe.
• DNS completo. Che tu cambi i nameserver o un singolo record, i record MX, TXT e SRV devono continuare a funzionare. La nostra checklist per cambiare i nameserver senza downtime se ne occupa.
• Fatturazione durante gli attacchi. Chiedi come viene conteggiato il traffico d'attacco rispetto al traffico incluso.
• Assistenza. Come raggiungi una persona durante un attacco.

La guida sui denial of service del National Cyber Security Centre britannico (in inglese) è una buona lettura indipendente dai fornitori per la pianificazione.

Una checklist di preparazione

Completa questa lista una volta, poi rivedila ogni qualche mese:

• Contatti. Assistenza dell'hosting con il tuo numero cliente, la tua agenzia o il tuo sviluppatore, il tuo fornitore di protezione e chi decide se disattivare funzioni o informare i clienti.
• Accessi. Almeno due persone possono accedere a registrar, DNS e dashboard del proxy, ognuna con il proprio account e l'autenticazione a due fattori.
• DNS. Tieni un export aggiornato della zona e sappi quali record devono restare raggiungibili.
• Monitoraggio. Un controllo di uptime esterno, avvisi per picchi di traffico e aumento degli errori 5xx, e una vista sulla CPU dell'origine.
• Runbook. Una pagina con le regole più severe da attivare, le funzioni pesanti che puoi spegnere per un giorno (ricerca live, widget di raccomandazione, chiamate ad API esterne) e un breve messaggio per i clienti.
• Test dell'origine. Verifica che l'origine rifiuti il traffico diretto, usando l'IP del tuo server:

curl -sI --max-time 10 --resolve www.example.com:443:203.0.113.10 https://www.example.com/

Se ottieni una risposta invece di un timeout o di un rifiuto, la tua origine accetta ancora traffico che aggira il proxy.

Come ti aiuta fast.site

fast.site è un reverse proxy per l'intero sito che si mette davanti al tuo hosting attuale. Tieni il tuo hosting e punti i nameserver del dominio a fast.site. Da quel momento ogni richiesta arriva prima alla rete edge e viene filtrata lì, prima che qualcosa venga inoltrato all'origine. fast.site gestisce la tua zona DNS, compresi i record MX, TXT e SRV, come descritto nella documentazione DNS.

Il rilevamento degli attacchi DDoS di livello 7 è automatico su tutti i domini, senza bisogno di configurazione. Puoi inoltre bloccare IP e intervalli CIDR, bloccare paesi o sottoporli a una challenge CAPTCHA, creare regole di challenge personalizzate e impostare rate limit per IP. Set di regole gestiti filtrano SQL injection, XSS e bot malevoli. La documentazione sulla sicurezza elenca tutte le opzioni.

Anche la cache alleggerisce il server: le pagine pubbliche mostrano fs-cache: HIT e vengono servite dall'edge, mentre carrelli, checkout e sessioni degli utenti loggati mostrano BYPASS. Le analytics mostrano richieste, tassi di errore e banda dell'origine, e gli avvisi di anomalia segnalano i picchi di traffico. La protezione a livello di rete per la connessione del tuo server di origine resta compito del tuo hosting, quindi limita l'accesso all'origine al solo proxy.

Configuralo con calma e misura il risultato sul tuo sito. Puoi testarlo con una prova gratuita di 7 giorni, senza carta di credito. Trovi i piani nella pagina dei prezzi.

Domande frequenti

Anche i siti piccoli hanno bisogno di protezione DDoS?

Le dimensioni non ti proteggono. I siti piccoli cadono anche sotto un HTTP flood modesto, e su un hosting condiviso un attacco a un sito vicino può colpire anche il tuo. Se un'interruzione ti costa ordini, contatti o reputazione, vale la pena mettere una protezione davanti al sito.

La protezione DDoS è inclusa nel mio hosting?

Spesso in parte. Molti hosting filtrano i grandi flood di rete per proteggere la propria infrastruttura, ma i flood a livello applicativo contro il tuo sito di solito passano, e alcuni hosting mettono in null routing l'IP attaccato. Chiedi con precisione quali tipi di attacco sono coperti.

Un CDN protegge dagli attacchi DDoS?

Solo se fa da proxy all'intero sito e filtra il traffico prima che raggiunga il tuo server. Un CDN per gli asset su un hostname separato non protegge le tue pagine, perché le richieste HTML vanno ancora direttamente all'origine.

La protezione DDoS rallenta il sito?

Un proxy aggiunge una tappa tra visitatore e server, ma le pagine in cache servite da un edge vicino spesso arrivano più velocemente. Dipende dal tuo sito e dai tuoi visitatori, quindi fai un confronto prima e dopo come descritto nella nostra guida su come misurare la velocità di un sito.