Che cos'è un attacco DDoS e come proteggere un sito web
Scopri cos'è un attacco DDoS, perché danneggia i siti web e quali metodi di protezione come CDN, WAF, limitazione della velocità e monitoraggio funzionano meglio.
Cos'è un attacco DDoS e perché è pericoloso per un sito web
Un attacco DDoS è un'enorme inondazione di richieste che sovraccarica un sito web, un server o una connessione di rete. Un visitatore non causerà alcun problema. 10.000 richieste al secondo è una storia molto diversa.
L'idea è semplice: l'attaccante non “hackerizza” il sito direttamente, ma lo sovraccarica fino a quando non riesce a farcela, e a volte l'obiettivo è la homepage, a volte l'API, a volte il modulo di accesso. Può anche succedere che un servizio ristretto venga attaccato e l'intero sito vada giù perché condivide un database o un singolo server senza separazione del carico.
Le conseguenze si manifestano rapidamente. Le pagine si caricano lentamente, il carrello della spesa smette di funzionare, la dashboard dell'account utente restituisce errori, il bot di ricerca riceve risposte 5xx e gli utenti si rivolgono a un concorrente. Il danno reputazionale spesso dura più a lungo dell'attacco stesso, specialmente se il sito è stato non disponibile per 20-30 minuti durante l'orario lavorativo.
Un attacco DDoS è pericoloso non solo a causa del downtime, ma aumenta anche i costi dell'infrastruttura, attiva falsi allerta analitici e fa sì che il supporto perda richieste reali dei clienti. Se il sito vende servizi, ogni ora di inattività danneggia i lead e le richieste, e se si tratta di media o SaaS, il consumo regolare di contenuti e la fiducia nel prodotto ne risentono.
Protezione DDoS per un sito web: quali metodi funzionano davvero
Non esiste un pulsante unico per la protezione DDoS. Una configurazione funzionante combina quasi sempre diversi strati: CDN, WAF, limitazione della velocità, filtraggio del traffico, Anycast e restrizioni lato hosting. Se sei interessato a una protezione pratica del sito web dagli attacchi DDoS, vale anche la pena dare un'occhiata al materiale su sicurezza del sito web, perché il DDoS è quasi sempre accompagnato da altri attacchi.
Un CDN aiuta a distribuire le richieste tra i nodi e a ridurre parte del carico sull'origine. Questo è particolarmente evidente per le pagine statiche e i media: invece di un solo server, il traffico incontra una rete di punti di presenza, e l'Anycast funziona in modo simile, ma si concentra sul routing: la richiesta va al nodo più vicino. Per un grande progetto, questo non è un lusso, ma un modo per evitare di andare giù a causa di un picco locale.
Un WAF filtra schemi di richiesta sospetti. Non protegge da tutto, ma fa un buon lavoro nel tagliare parte del traffico spazzatura e dei bot. La limitazione della velocità restringe la frequenza con cui le richieste possono provenire da un singolo IP, subnet o sessione. Quando un attacco arriva come migliaia di richieste identiche a un modulo, i limiti iniziano rapidamente a essere utili.
Il filtraggio del traffico lato fornitore o host è importante quando la linea di connessione è saturata prima che la richiesta raggiunga il tuo server. Qui vale la pena chiedere in anticipo quali meccanismi ha la piattaforma: un centro di pulizia, routing blackhole, reindirizzamento temporaneo e supporto senza un piano di incidente pronto spesso risponde troppo lentamente durante un attacco.
La protezione a livello di hosting e fornitore è necessaria non come opzione di backup, ma come primo strato di risposta, e un server può essere rinforzato, ma se il fornitore stesso non può tagliare il traffico spazzatura, la risorsa andrà comunque giù. In un progetto reale, la configurazione abituale è una combinazione: CDN davanti, WAF all'ingresso, limiti di richiesta e hosting che mantiene l'infrastruttura operativa.
Come proteggere un sito web da DDoS prima che inizi un attacco
La preparazione inizia con l'architettura. Se il sito vive su un solo server, senza caching e senza separazione dei ruoli, è più facile farlo crollare. È meglio separare subito il livello web, il database e i pesanti compiti in background, e bloccare l'area admin per IP o VPN. Per progetti con rischio maggiore, è utile guardare agli approcci dal caso studio S4M — infrastruttura di rete privata: VPN e proxy.
Il primo passo è rimuovere i punti di accesso non necessari, e un pannello di amministrazione aperto, SSH non protetto, sottodomini di test extra e vecchi metodi API ampliano solo la superficie di attacco. Se il modulo di ricerca e il modulo di accesso sono disponibili senza restrizioni, queste sono le prime cose su cui gli attaccanti si concentreranno.
Il secondo passo è pianificare uno scenario di fallback. Hai bisogno di un piano per quando il server principale diventa non disponibile: un segnaposto statico, DNS di backup, il contatto del fornitore e la persona responsabile per il passaggio. Un piano del genere non occupa molto spazio nella documentazione, ma risparmia ore una volta che il traffico inizia ad arrivare a ondate.
Il terzo passo è il monitoraggio. Hai bisogno di metriche per RPS, CPU, RAM, tempo di risposta, numero di errori 5xx e anomalie per paese o IP, e se il sito riceve improvvisamente 5.000 richieste alla pagina di accesso in 3 minuti, questo è immediatamente visibile. Senza monitoraggio, un attacco spesso sembra solo che 'qualcosa è lento.'
Il quarto passo è rafforzare il server. Ulteriore CPU e memoria non fermeranno un DDoS, ma compreranno tempo per attivare la protezione e evitare di perdere dati. È una buona idea controllare in anticipo i limiti di PHP-FPM, le dimensioni delle code, le impostazioni del proxy inverso e i timeout di connessione. Un timeout errato può trasformare un picco breve in un lungo blackout.
Il quinto passo è la memorizzazione nella cache. Le pagine che possono essere servite senza colpire il database dovrebbero essere memorizzate nella cache, e questo riduce il numero di operazioni costose e aiuta a resistere a carichi simili a quelli degli attacchi bot. La cache non risolve il problema, ma attenua il colpo.
Segnali di un attacco DDoS e come individuarlo in tempo
Il primo segnale è un picco di traffico improvviso senza una chiara ragione. Se, alle 2 del mattino, il traffico salta da 30 paesi contemporaneamente e non c'è alcuna campagna pubblicitaria sul sito, questo è un segnale di avvertimento. È particolarmente sospetto se il picco è concentrato su una pagina o un metodo API.
Il secondo segnale è un caricamento lento. Il sito potrebbe comunque aprirsi, ma con un ritardo di 8–15 secondi, e a volte anche di più. Gli utenti non aspetteranno. Chiuderanno la scheda.
Il terzo segnale sono gli errori 5xx. Questi possono essere 500, 502, 503 e 504. Il server è sovraccarico, il proxy non risponde, l'applicazione non riesce a tenere il passo con le richieste, e se tali errori aumentano insieme al traffico, piuttosto che dopo un rilascio, vale la pena indagare su un attacco DDoS.
Il quarto segnale sono i problemi con l'autenticazione e il pannello di amministrazione. Il sito potrebbe essere ancora visibile dall'esterno, ma accedere all'account utente, all'area admin o al modulo di pagamento inizia a fallire. Per le aziende, questo è particolarmente sgradevole: il cliente vede “il sito è attivo”, ma non può completare l'azione.
Il quinto segnale sono schemi insoliti nei log, e user-agent ripetuti, URL identici, molte richieste senza un referrer, intervalli IP strani. Se un log di 10 minuti sembra un copia-incolla, è tempo di controllare la protezione invece di aspettare che “passi da solo”.
Cosa fare durante un attacco DDoS su un sito web
La prima azione è attivare tutti i meccanismi di protezione preparati. Abilita il profilo WAF, i limiti di richiesta, la modalità di sfida se disponibile, e la memorizzazione nella cache al massimo livello senza rischiare la logica aziendale. Se del sito web dagli attacchi DDoS è stato impostato in anticipo, è una questione di minuti. Se no, la situazione è molto peggiore.
La seconda azione è contattare immediatamente il fornitore di hosting o il fornitore di infrastruttura. Non inviare solo un messaggio in chat — fornisci dettagli specifici: l'orario di inizio dell'attacco, gli URL interessati, il modello di traffico, screenshot dei grafici e indirizzi IP dai log. Più precisa è la descrizione, più velocemente il supporto può abilitare il filtro giusto.
La terza azione è limitare temporaneamente i punti di accesso vulnerabili. Puoi bloccare l'area admin per IP, disabilitare moduli pesanti, passare parte del sito in modalità di sola lettura, ridurre la funzionalità API, o rimuovere temporaneamente integrazioni non necessarie. Sì, è scomodo. Ma una funzionalità ridotta è meglio di un sito completamente inattivo.
La quarta azione è analizzare le fonti di traffico, e hai bisogno di log, geografia, modelli di richiesta, intestazioni identiche e frequenza delle richieste — non supposizioni. Se l'attacco proviene da un endpoint, puoi isolarlo, e se l'attacco è distribuito, l'attenzione si sposta sul fornitore e sul filtraggio a livello di rete.
La quinta azione è mantenere una cronologia breve. Chi ha abilitato la protezione, quando è stato contattato il supporto, cosa è stato cambiato e quale effetto è stato visto dopo 5, 15 e 30 minuti. Dopo l'attacco, questo record ti aiuta a capire cosa ha funzionato e cosa ha fatto rompere ulteriormente il sito rispetto all'attacco stesso.
Come scegliere un servizio o un hosting per la protezione DDoS
La scelta inizia con il filtraggio del traffico. Chiedi quali livelli di protezione sono disponibili: al livello di collegamento, al livello di rete e al livello di applicazione, e se il fornitore può solo 'bloccare per IP', non è sufficiente per attacchi complessi. Hai bisogno di meccanismi che vedano non solo l'indirizzo, ma anche il comportamento delle richieste.
Controlla il SLA. Il contratto dovrebbe specificare i tempi di risposta, la disponibilità del servizio e le procedure di escalation. Senza quelle righe, scoprirai solo del 'supporto 24/7' dopo il primo attacco, quando la risposta arriva 40 minuti dopo.
Anche la geografia dei nodi è importante. Se la tua base utenti è in 3 regioni, ma il filtraggio è disponibile solo in un centro dati, la latenza e la perdita di pacchetti aumenteranno. Per un sito internazionale, è meglio scegliere un'infrastruttura distribuita su più punti di presenza.
La compatibilità con il CMS e lo stack del progetto dovrebbe essere verificata in anticipo. WordPress, Laravel, Bitrix, Node.js, architettura headless — ogni opzione ha le proprie limitazioni riguardo a caching, proxy e intestazioni, e un buon servizio di protezione può comunque non essere adatto per un sito specifico se interrompe l'autenticazione o il carrello.
Il supporto dovrebbe essere in grado non solo di rispondere, ma di agire. Durante un attacco, è importante che un ingegnere possa applicare rapidamente una regola invece di passare il ticket tra i reparti. Per un sito web aziendale, è anche utile leggere di struttura del sito web aziendale, perché la protezione dipende anche da come sono organizzate le pagine di accesso, i moduli di richiesta e gli account utente.
Errori che indeboliscono la protezione DDoS di un sito web
Il primo errore è la mancanza di monitoraggio. Se i grafici non sono impostati, l'attacco viene notato troppo tardi. Il sito è già in fase di caduta e il team sta solo iniziando a cercare la causa nel codice, nella cache o nell'aggiornamento del plugin.
Il secondo errore sono le password deboli e i pannelli di amministrazione aperti, e il dDoS spesso va di pari passo con tentativi di indovinare l'accesso o distrarre il team. Un pannello di controllo senza restrizioni IP è una cattiva idea anche per un piccolo progetto.
Il terzo errore sono le impostazioni della cache errate, e a volte dopo aver abilitato la cache, il sito diventa veloce, ma il carrello, l'autenticazione o l'account utente si rompono. Questo crea un falso senso di sicurezza e sotto attacco il problema ritorna, in un momento più scomodo.
Il quarto errore è fare affidamento su un solo strumento. Un CDN senza un WAF, un WAF senza limiti, un host senza supporto — tutti questi sono più deboli di una combinazione di più strati. Un attacco DDoS raramente appare lo stesso due volte.
Il quinto errore è ignorare i test di carico. Se il sito non è mai stato controllato sotto un picco, nessuno sa dove fallirà per primo, e un test con 1.000 richieste non è lo stesso di un attacco, ma fornisce un utile punto di riferimento e rivela punti deboli.
Il sesto errore è mantenere tutti i servizi critici in un unico posto. Quando il sito, il database, la posta e le analisi si trovano tutti su un nodo, un problema trascina giù anche gli altri. Qui vale la pena guardare in anticipo il materiale su supporto al sito web dopo il lancio, perché la protezione e il supporto post-lancio sono strettamente collegati.
In sintesi: un piano di base per la protezione del sito web dagli attacchi DDoS
Inizia con 3 passaggi: attiva il monitoraggio, chiudi i punti di accesso non necessari e accordati con il tuo fornitore di hosting sul processo di risposta in caso di attacco, e se il sito è già sotto carico, aggiungi un CDN, un WAF e limiti alle richieste. Se il progetto è critico per le vendite, tieni a portata di mano uno scenario di fallback e i dettagli di contatto del tuo fornitore.
Poi controlla i log, i timeout, la cache e le aree di amministrazione, e la protezione impostata una volta non ti salva per sempre, ma ti dà tempo quando un attacco è già iniziato. E quel tempo spesso conta più dell'intera infrastruttura che lo circonda.
Se il progetto sta crescendo, la protezione del sito web dovrebbe essere rivista dopo ogni rilascio importante e dopo ogni cambiamento nel traffico, e un nuovo modulo, un modulo, un metodo API possono aprire un carico extra, e un attacco DDoS troverà rapidamente quel punto debole.
