Come Proteggere un Sito Durante un Attacco DDoS con Cloudflare "Under Attack Mode"

Quando un sito web è sotto attacco DDoS, la modalità "Under Attack" di Cloudflare offre una difesa immediata: mostra ai visitatori una breve verifica di sicurezza, filtrando il traffico malevolo e rallentando le richieste sospette a livello HTTP/HTTPS. Attivando questa funzione dal pannello Cloudflare (sezione Security), puoi garantire che solo utenti reali accedano al sito e alleggerire il carico del server in pochi minuti. Tuttavia, questa modalità non è una soluzione definitiva: va affiancata a una corretta configurazione DNS proxy, regole WAF, rate limiting, cache ottimizzata e un origin server protetto.

In questa guida vedremo come attivare Cloudflare Under Attack, quando usarlo, quali impostazioni lo rafforzano e come tornare alla normalità in modo sicuro dopo la fine dell’attacco. L’obiettivo è fornire una checklist rapida da seguire nei momenti critici, per ripristinare l'accessibilità del sito nel minor tempo possibile.

Cosa è la Modalità "Under Attack" di Cloudflare?

La modalità Under Attack di Cloudflare è un livello di sicurezza d'emergenza pensato per mitigare attacchi DDoS mirati al livello applicativo (Layer 7). Quando attivata, Cloudflare sottopone ogni visitatore a una verifica automatica (solitamente dura pochi secondi), bloccando bot, tool di HTTP flood e client non-browser che tentano di sovraccaricare il sito.

L’obiettivo principale è filtrare richieste massicce come migliaia di GET sulla homepage, POST ripetuti sulle pagine di login WordPress, query costose su pagine di ricerca o traffico fasullo su carrelli e checkout. In questi casi, Under Attack offre una risposta immediata.

Attenzione: questa modalità filtra il traffico web, ma se l’IP del server origin viene attaccato direttamente (Layer 3/4), o servizi non proxyati da Cloudflare sono esposti, serve una protezione aggiuntiva. È fondamentale che i record DNS siano proxyati da Cloudflare, che l’IP del server sia nascosto e che il provider hosting abbia misure di sicurezza adeguate. Per la scelta dell’infrastruttura, consulta Servizi di web hosting sicuri e installazione del certificato SSL.

Segnali di Attacco DDoS: Cosa Controllare Prima di Attivare Under Attack

Non tutti i rallentamenti sono causati da DDoS: plugin difettosi, database bloccato, cron job pesanti o cache mal configurata possono provocare sintomi simili. Prima di attivare Under Attack, diagnostica rapidamente la situazione. Se il server fatica a rispondere, utenti ricevono errori 502, 503, 504 e i log mostrano esplosioni di richieste, non aspettare: attiva la modalità di emergenza.

Indicatori tipici di DDoS

Improvviso aumento del traffico: 5, 10, 50 volte superiore al normale.
Centinaia di richieste al secondo su una sola pagina o endpoint.
Traffico con user-agent simili da paesi diversi.
URL critici (admin, login, search, cart) di WordPress, WooCommerce, OpenCart o software custom bersagliati.
Saturazione di CPU, RAM, PHP-FPM worker o limiti di connessione MySQL sul server.
Impennata di errori 4xx e 5xx su Cloudflare Analytics.
Utenti reali accedono a intermittenza, mentre i bot generano richieste continue.

Esempio: un e-commerce che passa da 2.000 richieste al minuto a 80.000 in dieci minuti, con il 70% delle richieste su carrello o ricerca, è chiaramente sotto attacco Layer 7. In questo scenario, attiva Under Attack entro 5 minuti e aggiungi regole WAF e rate limiting sugli URL bersagliati.

Quando Attivare Cloudflare Under Attack?

La modalità Under Attack non va tenuta sempre attiva: mostra una schermata di verifica anche agli utenti reali, impattando esperienza e conversioni, soprattutto su pagine di pagamento o API. Va usata come difesa temporanea durante un attacco, ripristinando il livello di sicurezza normale quando il traffico si stabilizza.

Situazioni in cui è consigliato

Ricezione di un volume anomalo di richieste HTTP/HTTPS.
Esaurimento rapido delle risorse server e aumento di errori 502/503.
Cloudflare WAF non ancora configurato: serve un filtro rapido.
Bot traffic nettamente superiore a quello umano.
Bersaglio dell'attacco: pagine web, form, login, endpoint di ricerca.

Usare con cautela in caso di:

Traffico intenso su app mobile, provider di pagamento, webhook o API.
Periodo critico per il crawl dei bot dei motori di ricerca.
Utenti aziendali che accedono da browser vecchi o reti restrittive.
Sottodomini non proxyati da Cloudflare.

Se il sito usa API, attivare Under Attack sull’intero dominio può bloccare integrazioni. Valuta regole WAF, allowlist o livelli di sicurezza specifici per i sottodomini API. Per approfondire, vedi Guida alla sicurezza API e limitazione della velocità.

Come Attivare Cloudflare Under Attack: Procedura Step by Step

Ecco una checklist pratica per agire rapidamente durante un attacco. L’interfaccia Cloudflare può cambiare, ma il processo resta: selezionare il dominio, alzare il livello di sicurezza, filtrare il traffico.

1. Accedi al tuo account Cloudflare

Entra nel tuo account Cloudflare e seleziona il dominio sotto attacco. Se gestisci più zone, verifica di operare sulla corretta: attivare Under Attack sul dominio sbagliato spreca tempo prezioso.

2. Verifica che i record DNS siano proxyati

Affinché Under Attack sia efficace, il traffico web deve passare da Cloudflare. Nel pannello DNS, assicurati che i record A, AAAA e CNAME mostrino la nuvola arancione (proxy). I record "DNS only" (nuvola grigia) bypassano la protezione Cloudflare. Controlla www, dominio root e tutti i sottodomini usati.

Se l’IP origin è visibile online, gli attaccanti possono aggirare Cloudflare e puntare direttamente al server. Consenti traffico HTTP/HTTPS solo dagli IP Cloudflare tramite firewall: chiedi supporto al tuo hosting o consulta Come configurare le impostazioni DNS di Cloudflare.

3. Attiva Under Attack Mode dalla sezione Security

Nel pannello Cloudflare, apri il dominio e cerca la voce Under Attack Mode (Security o Overview). Attivando questa opzione, Cloudflare presenterà una schermata di verifica ai visitatori. In alcuni pannelli, la funzione è sotto Security Level come "I am Under Attack".

Il cambiamento è immediato: monitora Analytics, Security Events e risorse server nei primi minuti. Se CPU e connessioni calano, la modalità funziona; se gli errori persistono, aggiungi regole mirate.

4. Verifica l’esperienza utente reale

Dopo aver attivato Under Attack, testa il sito da diverse reti (mobile, ufficio, sedi remote), provando homepage, pagine prodotto, login e checkout. Se gli utenti accedono dopo la verifica, tutto ok. In caso di loop infinito nella verifica, controlla impostazioni cookie, compatibilità browser o conflitti con le regole Cloudflare.

5. Identifica gli URL bersagliati dall’attacco

Under Attack offre una protezione generale, ma la massima efficacia si raggiunge con regole dedicate. Usa Cloudflare Security Events, Web Analytics, log di accesso hosting e log applicativi per scoprire le pagine più colpite: /wp-login.php, /xmlrpc.php, /search, /cart, /api/login, /checkout sono tipici bersagli.

Quando individui gli URL critici, crea regole WAF custom in base a paese, user-agent, metodo, path o score bot. Ad esempio, per il login puoi applicare una challenge agli IP che superano una certa soglia di richieste. Per WordPress, vedi Misure di Sicurezza WordPress.

Confronto tra Under Attack e Altre Soluzioni di Sicurezza Cloudflare

Cloudflare offre vari strumenti di sicurezza. Under Attack è un filtro d’emergenza, mentre WAF e Rate Limiting sono soluzioni più mirate e sostenibili.

Confronto tra Under Attack e Altre Soluzioni di Sicurezza Cloudflare
Funzione	Cosa fa?	Quando usarla?	Impatto sull’utente
Under Attack Mode	Applica verifica a tutti i visitatori, riduce bot e flood.	Durante attacchi DDoS o HTTP flood intensi.	Utente vede una breve schermata di attesa.
WAF Custom Rules	Blocca/filtra su URL, paese, IP, metodo, user-agent.	Se conosci il pattern dell’attacco e serve una difesa mirata.	Basso impatto se ben configurato.
Rate Limiting	Limita il numero di richieste per cliente in un intervallo.	Su login, ricerca, API, carrelli.	Impatto sull’utente se la soglia è troppo bassa.
Bot Fight Mode	Mitiga bot semplici e comportamenti sospetti.	Traffico bot basso-medio persistente.	Di solito impatto minimo.
Cache Rules	Serve contenuti statici/dinamici dal CDN edge.	Per ridurre il carico server in modo permanente.	Impatto positivo se configurato correttamente.

In pratica: usa Under Attack per la pressione immediata, analizza il traffico, aggiungi regole WAF e rate limiting, poi rafforza cache e firewall origin per una protezione durevole.

Impostazioni Cloudflare Consigliate Durante un Attacco

Under Attack si attiva con un click, ma la difesa DDoS efficace richiede settaggi extra. Ecco le best practice più utili.

Crea protezione mirata con WAF

Il WAF di Cloudflare consente azioni precise: ad esempio, sfida solo POST da certi paesi su /wp-login.php, isolando l'attacco senza penalizzare tutto il sito.

Limita l’accesso a admin/login solo per IP o paesi autorizzati.
Blocca endpoint inutilizzati come XML-RPC.
Applica challenge a user-agent sospetti.
Usa rate limiting su URI con molte richieste.

Imposta la cache in modo intelligente

Se il server deve rispondere a ogni richiesta, le risorse si esauriscono. File statici, immagini, CSS, JS e pagine cachabili devono essere serviti da Cloudflare edge. Su WordPress, usa plugin di cache, regole Cloudflare e intestazioni cache-control.

Per siti news/blog, le pagine per visitatori anonimi possono essere cacheate 5-30 minuti, migliorando TTFB e alleggerendo il server. Per l’ottimizzazione, consulta Guida alla velocizzazione del sito web.

Imposta rate limiting con soglie realistiche

Il rate limiting è essenziale sugli endpoint costosi, ma se la soglia è troppo bassa rischi di bloccare utenti veri. Su una ricerca prodotti, normalmente un utente fa 5-15 query/minuto: 100/minuto è sospetto. Sul login, 10 tentativi falliti in 5 minuti sono già anomali.

Esempio: per /wp-login.php, applica challenge a IP che fanno più di 10 richieste/minuto, blocca chi supera 50 in 5 minuti. Sugli endpoint API, usa limiti più precisi basati su sessione, token o metodo.

Nascondi l’IP origin e filtra via firewall

L’errore più grave è lasciare l’IP origin esposto. Record DNS vecchi, sottodomini diretti, servizi web mischiati con record mail o configurazioni trapelate permettono agli attaccanti di aggirare Cloudflare.

Apri le porte 80/443 solo agli IP Cloudflare. Non lasciare SSH, pannelli, database, admin accessibili pubblicamente: usa restrizioni IP, password forti, 2FA, magari VPN. Per la sicurezza hosting consulta impostazioni di sicurezza cPanel e configurazione del firewall VPS.

Focus su WordPress, WooCommerce e Siti Aziendali

Ogni sito ha una struttura di traffico diversa: blog, negozi WooCommerce, SaaS hanno esigenze specifiche. Identifica le aree critiche in base al tipo di sito.

Siti WordPress

I target più comuni sono /wp-login.php e /xmlrpc.php. Se non usi XML-RPC, bloccalo. Limita admin solo a IP o paesi fidati. Attenzione a conflitti tra plugin di sicurezza e regole Cloudflare: troppe challenge possono creare loop di verifica per gli utenti.

Shop WooCommerce

Pagine carrello, pagamento e account richiedono attenzione: sono dinamiche, quindi cache aggressiva non va applicata. In modalità Under Attack, verifica che le callback dei provider di pagamento funzionino; se necessario, inserisci IP del provider in allowlist o crea regole dedicate.

Siti aziendali/API

Portali aziendali, CRM e API mobile potrebbero non gestire la challenge JavaScript di Cloudflare. Meglio proteggere www.example.com con Under Attack e gestire api.example.com con token, rate limit e allowlist.

Monitoraggio dei Parametri Dopo Attivazione Under Attack

La sola apertura del sito non basta: monitora numeri e comportamenti.

Cloudflare Security Events: quanti challenge/block sono stati applicati?
Codici HTTP: variazione di errori 403, 429, 502, 503, 504.
CPU/RAM server: dovrebbero calare dopo Under Attack.
Connessioni PHP-FPM/MySQL: indicano se l’applicazione è più "leggera".
Larghezza banda/numero richieste: confronta il traffico totale con quello filtrato.
Conversioni reali: verifica invio form, ordini, login, pagamenti.

Se il totale delle richieste resta invariato, ma quelle che arrivano all’origin diminuiscono del 60%, Cloudflare sta assorbendo il carico. Se il server resta sotto stress, verifica se l’attacco colpisce query dinamiche specifiche e analizza i log applicativi.

Come Disattivare Under Attack Mode Dopo la Fine dell’Attacco

Quando il traffico torna normale, non lasciare Under Attack attivo troppo a lungo: la verifica penalizza conversioni, crawling e user experience. Procedi in modo graduale e controllato.

Passaggi per tornare alla normalità

Attendi 30-60 minuti di traffico stabile.
Controlla che i challenge/block su Cloudflare Security Events siano calati.
Prima di disattivare Under Attack, assicurati che regole WAF e rate limiting siano attive.
Imposta il livello di sicurezza su High o Medium.
Testa il sito da vari dispositivi e monitora errori 5xx.
Monitora i log per 24 ore per intercettare eventuali nuovi attacchi.

Redigi un report post-attacco: ora di inizio, URL bersagliati, picco di richieste, azioni intraprese, regole efficaci e miglioramenti apportati. Questo documento accelera i futuri interventi.

Errori Comuni da Evitare

La rapidità è essenziale, ma un errore sotto stress può bloccare utenti reali. Ecco gli sbagli più frequenti:

Credere che Under Attack protegga anche record DNS non proxyati.
Lasciare l’IP origin esposto e non filtrare via firewall per IP Cloudflare.
Applicare challenge a tutto il dominio senza testare API/webhook/payment callback.
Scrivere regole WAF troppo ampie, bloccando clienti reali.
Cacheare pagine dinamiche come carrello, pagamento o pannelli utente.
Lasciare Under Attack attivo per settimane dopo l’attacco.
Decidere solo dai dati Cloudflare senza analizzare i log server.

Bloccare callback di pagamento su e-commerce può causare gravi perdite. Sperimenta con log o managed challenge prima di bloccare, poi agisci in modo più deciso dopo aver verificato l’efficacia.

Pianificare una Difesa Resiliente su Infrastruttura Hostragons

Cloudflare è uno scudo potente, ma la difesa DDoS non si esaurisce sul CDN. Hosting, ottimizzazione software, SSL, DNS e backup vanno pensati insieme. Su Hostragons, la strategia ideale è: Cloudflare filtra il traffico, il server hosting gestisce solo traffico pulito, l’applicazione è ottimizzata per evitare carico inutile.

Prima di pubblicare un nuovo sito: configura DNS corretti, installa SSL senza errori, scegli risorse server adatte. Consulta Verifica del dominio e registrazione del nome a dominio, Pacchetti di web hosting, soluzioni di hosting aziendale e Certificato SSL gratuito.

Per progetti ad alto rischio/traffico, scegli VPS o server gestiti invece del hosting condiviso: così firewall, web server, PHP-FPM, Redis, object cache e database sono configurabili in modo flessibile. Qualunque infrastruttura tu scelga, Under Attack va usato solo come strumento d’emergenza, affiancato da WAF, log analysis e aggiornamenti regolari.

Checklist Rapida: Cosa Fare nei Primi 15 Minuti di Attacco DDoS

In caso di attacco, il tempo è cruciale. Ecco una lista da seguire nella prima fase:

Accedi al pannello Cloudflare e seleziona il dominio corretto.
Verifica che i record DNS siano proxyati (nuvola arancione).
Attiva Under Attack Mode.
Testa homepage, login, carrello, pagamento e endpoint API.
Identifica gli URL bersagliati tramite Security Events.
Aggiungi regole WAF o rate limiting sugli URL più colpiti.
Monitora CPU, RAM, PHP-FPM e MySQL sul server.
Controlla se l’IP origin è raggiungibile direttamente.
Verifica se serve allowlist per payment provider, webhook, integrazioni critiche.
Annota tutte le azioni con orario.

Se questa lista viene provata periodicamente, l’intervento durante un attacco sarà più efficace e meno stressante. Su siti grandi, documenta il processo come piano di risposta agli incidenti.

Domande Frequenti

La modalità Under Attack protegge completamente il sito?

No. Under Attack è efficace contro bot e flood HTTP/HTTPS, ma da sola non basta. Va usata insieme a DNS proxyati, IP origin nascosto, regole WAF, rate limiting, cache e firewall server.

Under Attack danneggia la SEO?

Un uso breve non impatta significativamente la SEO. Se rimane attiva troppo a lungo, può ridurre efficienza crawling e user experience. Dopo l’attacco, disattivala e mantieni regole di sicurezza mirate.

Quanto tempo va tenuta attiva Under Attack?

Finché l’attacco dura. In pratica, monitora 30-60 minuti di traffico normale prima di disattivare, assicurando che WAF e rate limiting siano pronti.

Under Attack può bloccare API o sistemi di pagamento?

Sì, può succedere: API, webhook e payment callback potrebbero non superare la challenge browser-based. Testa gli endpoint critici e usa allowlist/regole dedicate dove serve.

Serve protezione extra sul server hosting anche con Cloudflare?

Sì. Cloudflare protegge il front-end, ma l’IP origin va nascosto, il firewall server va configurato, il software aggiornato e la cache va impostata correttamente. Un hosting sicuro è fondamentale per resilienza DDoS.

Conclusione

La modalità Under Attack di Cloudflare è uno strumento rapido ed efficace per mitigare DDoS e HTTP flood. Se attivata con DNS proxyati, riduce il traffico bot, alleggerisce il server e mantiene accessibile il sito agli utenti reali. Per la massima efficacia, va integrata con regole WAF, rate limiting, cache ottimizzata e firewall origin.

Se vuoi un sito più resistente agli attacchi, controlla regolarmente infrastruttura, DNS e SSL. Esplora le soluzioni hosting, dominio e SSL di Hostragons per creare una base sicura e sostenibile per il tuo progetto online.