1,701 25/03/2026 07/04/2026 9 min

Quando un sito finisce sotto attacco, ogni minuto conta. La modalità Under Attack di Cloudflare compra tempo, ma attivarla a mano non basta sempre.

Se il traffico malevolo arriva di notte, durante un lancio o in pieno picco e-commerce, serve una risposta automatica. Qui vediamo come farlo in modo pratico, con pannello, API e un piccolo flusso operativo che puoi davvero mantenere.

Il punto non è solo “accenderla”. Il punto è decidere quando attivarla, chi può farlo, come spegnerla e come evitare falsi positivi. L’obiettivo è ridurre il tempo tra rilevazione e mitigazione.

Prerequisiti

Prima di automatizzare, verifica questi elementi.

  • Un account Cloudflare con il dominio già attivo.
  • Permessi amministrativi o almeno permessi per modificare Security e Firewall.
  • Accesso alla Cloudflare API.
  • Un token API con scope limitati, non la Global API Key.
  • Un sistema di monitoraggio o un trigger, come uptime check, SIEM, WAF log, Prometheus, Grafana o script custom.
  • Una procedura di rollback, perché la modalità Under Attack non va lasciata attiva più del necessario.

Note: se gestisci il dominio da un pannello tipo Cloudflare dashboard, puoi fare tutto anche senza terminale. Il terminale serve solo per l’automazione vera.

Warning: non usare token troppo ampi. Un token con privilegi eccessivi aumenta il rischio operativo quanto l’attacco stesso.

Step numerati

1. Definisci il trigger che deve far scattare la protezione

Serve un criterio oggettivo. Senza soglia, l’automazione diventa rumorosa e poco affidabile. Il trigger può essere un aumento anomalo di richieste, un picco di challenge fallite, un alert del WAF o un controllo esterno che fallisce ripetutamente.

Dal pannello Cloudflare, vai in Security → Events e osserva pattern ripetuti. Se usi un tool esterno, definisci una soglia semplice: per esempio, 5 alert critici in 2 minuti oppure 3 controlli negativi consecutivi da 2 regioni diverse.

trigger:
  name: http-attack-spike
  condition:
    failed_health_checks: 3
    window_seconds: 120
    source: synthetic_monitoring
  action: enable_under_attack

# Output: una regola chiara, attivabile e misurabile

Se il tuo team usa un pannello di monitoraggio, questa logica può stare in una policy o in una regola di alerting. Se invece hai un SIEM, usa il tag del dominio come filtro e collega l’azione a un webhook.

2. Crea un token API con permessi minimi

Qui si fa il lavoro pulito. La modalità Under Attack si attiva tramite API, ma il token deve autorizzare solo ciò che serve. Il principio è semplice: leggere lo stato del firewall e modificarlo per quel sito, senza accessi inutili.

Dal pannello Cloudflare, vai in My Profile → API Tokens → Create Token. Parti da un template vuoto o dal modello più vicino. Assegna questi permessi:

  • Zone → Firewall Services → Edit
  • Zone → Zone → Read

Limita il token a una sola zona, cioè al dominio corretto. Questo riduce il blast radius se il token viene esposto.

Se preferisci terminale, puoi conservarlo in una variabile ambiente sul server di automazione.

export CF_API_TOKEN='your_token_here'
export CF_ZONE_ID='your_zone_id_here'

# Output: token e zone ID pronti per gli script

Note: la Global API Key funziona ancora in alcuni contesti, ma qui è una scelta peggiore. Il token granulare è più sicuro e più facile da revocare.

3. Verifica lo stato corrente della zona prima di cambiare modalità

Prima di attivare la protezione, leggi lo stato attuale. Questo evita toggle inutili e ti permette di registrare l’evento. È utile anche per non sovrascrivere un’impostazione già gestita da un operatore.

Con la dashboard, vai in Security e controlla se la protezione è già attiva. Con API, puoi leggere la configurazione della zona.

curl -sS "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/settings/security_level" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json"

# Output: JSON con il livello di sicurezza attuale

Nel JSON cerca il valore under_attack o uno stato equivalente. Se non c’è, la tua automazione può decidere se attivare o lasciare invariato.

4. Attiva la modalità Under Attack via API

Questo è il cuore dell’automazione. Cloudflare espone l’impostazione di sicurezza della zona. Quando il trigger scatta, lo script imposta il livello su Under Attack.

Usa un comando come questo. È il modo più diretto per automatizzare da un server, un runner CI o un job schedulato.

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/settings/security_level" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"value":"under_attack"}'

# Output: risposta JSON con success true e valore under_attack

Se vuoi farlo da interfaccia, il percorso è questo: vai in Security → Settings → Security Level e seleziona Under Attack. È utile per test manuali e per capire il comportamento prima di automatizzare.

Warning: non attivarla su tutte le zone “per sicurezza”. Su molti siti, il challenge aggiuntivo degrada l’esperienza utente e può impattare conversioni e login.

5. Collega l’attivazione a un webhook o a un job schedulato

Ora devi decidere chi chiama l’API. Le opzioni pratiche sono tre: un webhook del monitoraggio, un job su cron, oppure una pipeline CI che reagisce a un segnale esterno.

Se vuoi semplicità, un cron che controlla un endpoint è spesso sufficiente. Se vuoi reattività, un webhook è migliore. Se lavori già con GitLab CI, GitHub Actions o un runner interno, puoi aggiungere un job di mitigazione.

#!/usr/bin/env bash
set -euo pipefail

ALERT_URL="https://monitor.example.com/attack-alert"
STATUS=$(curl -fsS "$ALERT_URL")

if [ "$STATUS" = "attack" ]; then
  curl -fsS -X PATCH "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/settings/security_level" \
    -H "Authorization: Bearer $CF_API_TOKEN" \
    -H "Content-Type: application/json" \
    --data '{"value":"under_attack"}'
fi

# Output: attivazione automatica quando il monitor segnala attack

Note: se usi un pannello di hosting con cron, il percorso tipico è Cron Jobs → aggiungi comando. Se il server è gestito da Plesk o cPanel, il job si imposta da lì e non serve per forza SSH.

6. Aggiungi una durata massima e il ritorno automatico allo stato normale

La protezione non deve restare attiva all’infinito. Il passaggio più importante, spesso ignorato, è lo spegnimento automatico. Se il sistema non rientra da solo, rischi un problema operativo più grande dell’attacco.

Una strategia semplice usa due fasi: attiva Under Attack, poi dopo 15 o 30 minuti verifica se l’allarme è rientrato. Se sì, torna a un livello meno aggressivo, come medium o high, oppure al valore precedente salvato nel log.

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/settings/security_level" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"value":"medium"}'

# Output: ritorno a un livello meno invasivo

Se il tuo flusso è più maturo, salva lo stato iniziale in un file o in un secret manager. Così puoi ripristinare il valore esatto prima dell’incidente.

7. Logga ogni attivazione e avvisa il team

La mitigazione senza audit è fragile. Ogni attivazione va registrata con data, motivo, durata e responsabile. Questo ti aiuta a capire se la soglia è giusta o troppo sensibile.

Puoi scrivere il log su syslog, su un file locale o su un sistema centralizzato come Loki o ELK. In parallelo invia una notifica al team via email, Slack, Teams o webhook.

logger -t cloudflare-ua "Under Attack enabled for $CF_ZONE_ID due to attack-alert"

curl -X POST https://hooks.example.com/security-alert \
  -H 'Content-Type: application/json' \
  -d '{"zone":"example.com","action":"under_attack","reason":"attack-alert"}'

# Output: evento registrato e notifica inviata

Un log ben fatto ti evita discussioni dopo l’incidente. Sai chi ha attivato cosa, quando e con quale motivo.

8. Testa tutto in una finestra controllata

Non aspettare un attacco vero per scoprire che il token non ha permessi. Fai un test in una finestra concordata con il team, magari su una sotto-zona o in orario a basso traffico.

Dal pannello Cloudflare, attiva manualmente la modalità e verifica che il sito mostri la challenge. Poi prova il ritorno automatico. Se usi script, esegui il job in modalità dry-run se lo hai previsto.

echo "dry-run: would enable under_attack for example.com"

# Output: simulazione del comportamento senza modifiche reali

Warning: se il sito ha login, checkout o API per app mobile, testa anche quei flussi. La challenge può interferire con utenti autenticati, bot legittimi e integrazioni server-to-server.

Verifica finale

Una volta completata l’automazione, controlla questi punti in ordine.

  • Il token API è limitato alla zona corretta.
  • Il trigger è misurabile e non troppo sensibile.
  • L’attivazione genera un log.
  • Esiste un timeout o un rientro automatico.
  • Il team riceve una notifica chiara.
  • Il sito torna normale senza interventi manuali, quando il problema rientra.

Puoi fare un test finale simulando un alert. Se tutto funziona, l’API risponde con successo, il pannello mostra il livello Under Attack e il rollback riporta la zona allo stato previsto.

Un controllo utile è confrontare il timestamp dell’alert con quello della modifica Cloudflare. Se il delta è alto, il tuo flusso è lento e va semplificato.

Troubleshooting

Errore 1: "code": 9109, "message": "Invalid request headers"

La causa più comune è un header Authorization errato o un token copiato male. Spesso manca anche il formato Bearer.

Fix:

export CF_API_TOKEN='token_corretto'
curl -sS -X PATCH "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/settings/security_level" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"value":"under_attack"}'

# Output: richiesta autenticata correttamente

Errore 2: "code": 10000, "message": "Authentication error"

Il token non ha i permessi giusti, oppure è stato creato per un’altra zona. La causa tipica è un scope incompleto.

Fix:

# ricrea il token con:
# Zone -> Zone -> Read
# Zone -> Firewall Services -> Edit
# limita il token a example.com

# Output: token valido per leggere e modificare la zona

Errore 3: "success": false, "errors": [{"message":"Invalid value for setting"}]

La causa è quasi sempre un valore non supportato nel payload o un endpoint sbagliato. Succede quando si usa un nome di stato errato.

Fix:

curl -X PATCH "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/settings/security_level" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"value":"under_attack"}'

# Output: valore accettato dall’API

Conclusione

Automatizzare la Modalità Under Attack di Cloudflare non significa solo reagire più in fretta. Significa anche governare meglio il rischio, ridurre i tempi morti e lasciare traccia delle decisioni.

Il prossimo passo concreto è trasformare questo flusso in una regola operativa: trigger, attivazione, timeout, notifica e rollback. Se vuoi fare un salto di qualità, integra lo stesso meccanismo con il tuo monitoraggio e con un canale di incident response.

Così la protezione non resta un gesto manuale. Diventa una procedura affidabile, ripetibile e sostenibile anche sotto pressione.