Cosa fare in caso di un attacco DDoS a un sito web?

Manuel Schulz · 31.10.2025 · Sicurezza informatica · 7 minuti

Di recente è stato Zerlo.net con un attacco DDoS confrontato. Ci interessava: come procediamo, come riconosciamo qualcosa del genere – e come siamo riusciti a dimostrarlo in modo inequivocabile? In questo articolo mostro i nostri passi, cosa c'è dietro al DDoS e come Cloudflare come strato di protezione aiuta. Se avete problemi simili, trovate strumenti pratici sul nostro Zerlo-Toolseite e altri contributi nel Zerlo-Blog .

Banner in evidenza: attacco DDoS – immagine simbolo

Fonte: Rappresentazione propria

Spiegazione: Che cos'è un DDoS?

Un Distributed-Denial-of-Service-Angriff (DDoS) è il tentativo di rendere indisponibile un servizio online mediante richieste massivamente distribuite. «Distributed» significa: l'attacco proviene contemporaneamente da molte fonti, spesso automatizzate ( CISA-Leitfaden). ) HTTP-Floods. Una buona introduzione pratica la fornisce anche OWASP ( (Denial of Service)).

Come si rileva?

Una singola misurazione raramente basta. Modelli tipici sono: carico di origine in forte aumento, ma sessioni/conversioni reali invariati; improvvisi molte richieste su endpoint “costosi” (Login, Ricerca, /api, Moduli); user-agent sospetti o vuoti; picchi insoliti da nuovi ASN; alto utilizzo CPU/IO senza modifiche al codice. Log puliti sono utili, che voi ad es. su Cloudflare Logpush/Log Explorer o valutate sul lato server. Zerlo-Blog Una checklist compatta la trovate nel

Rilevare tramite Cloudflare

In Cloudflare è possibile scomporre questi schemi in modo chiaro:

Sicurezza → Eventi/Analisi:Picchi per percorso, paese, ASN, metodo, User-Agent segmentare ( Security Analytics)).
Traffico/Analisi:Molte richieste Edge con contemporanea alta quota origine → Indicazione di L7-Floods ( Traffic Analytics)).
WAF/Firewall: «Challenged/Blocked» conta le mitigazioni; regole da ottimizzare ( Cloudflare WAF)).
HTTP-DDoS/Rate Limiting: Identificare hotspot IP/Percorso ( Rate Limiting Rules, HTTP DDoS Managed Rules)).

Conclusione: Per i siti Web con molti utenti è utile avere uno strato di protezione in linea come Cloudflare Application Services praticamente obbligatorio: telemetria e strumenti aiutano a distinguere tra carico legittimo e attacco e a reagire rapidamente. Internamente rimandiamo per articoli di base a Zerlo-Blog e agli strumenti su quelli. Zerlo-Tools.

Personale

Noi di Zerlo abbiamo dovuto rilevare un carico insolito molto alto il 31.10.2025 – a volte il sito è stato offline diverse volte. Inizialmente pensavo fosse un problema tecnico. Poi ho controllato le visite: quasi identiche al giorno precedente, cosa strana, dato che il nostro conteggio misura solo interazioni umane (JavaScript). Under-Attack-Mode (UAM) Il classico contro-test: avviare tutto localmente (localhost). Risultato: localmente 0% di carico – quindi il carico esterno doveva essere artificiale. Su Cloudflare l'aumento era chiaramente visibile. Attivai temporaneamente il

Statistica Cloudflare: forte aumento delle richieste in ingresso

Fonte: Rappresentazione propria

In breve: siamo stati colpiti da un DDoS. Ulteriori approfondimenti li condividiamo costantemente nel Zerlo-Blog.

Cloudflare

Se l'hosting ha già una buona protezione a livello di rete, spesso ciò basta per attacchi volumetrici, soprattutto se il provider mitiga. Noi gestiamo presso Zerlo Tuttavia gestiamo una rete più ampia con diversi servizi e abbiamo bisogno di interfacce centralizzate, posizionate in avanti, che terminino e filtrino il traffico in modo intelligente prima che raggiunga le nostre origini. Proprio qui una rete edge globale come Cloudflare aiuta: Anycast, caching, WAF, Bot Fight Mode, Rate-Limiting e telemetria dettagliata.

Cloudflare è disponibile gratuitamente nella versione base e può essere aumentato temporaneamente durante gli attacchi. Non riconosce automaticamente ogni scenario in modo perfetto – bisogna osservare i modelli –, ma dopo, con le regole giuste, è molto efficace. Per configurazioni e benchmark documentiamo le Best Practices anche su zerlo.net/de/tools.

Meccanismo di protezione Cloudflare spiegato

Così semplice quanto geniale: prima del caricamento effettivo della pagina, Cloudflare può eseguire un controllo basato su JavaScript ( Challenge) ) da anteporre e valutare segnali dal browser. Per gli utenti reali ciò avviene una sola volta e quasi inudibile; bot e script falliscono o devono utilizzare molte più risorse. Risultato: il carico sul backend diminuisce immediatamente e voi avete tempo per l'affinamento ( WAF, Rate-Limits, Caching)).

❝ Non si evita il DDoS – si gestisce. L'arte è rendere gli attacchi invisibili per le persone, ma costosi per i bot. ❞

Manuel Schulz

Zerlo.net

Fonte: Breve panoramica su botnet e DDoS.

Cosa si può fare contro?

Niente. Non si può impedire un DDoS – chiunque in rete può inviarti pacchetti. Ma puoi rendere l'effetto così piccolo da mantenere la pagina disponibile per gli utenti reali. Questo è l'obiettivo: attenuare in modo intelligente invece di aspettare che passi.

A breve termine: Under-Attack-Mode (UAM) Attivare per attenuare immediatamente il carico Layer-7.

A lungo termine: WAF-Regeln per POST/API/GET costosi, Managed-Challenges per user-agent sospetti, Rate-Limiting per IP. Per le pagine pubbliche « Cache Everything“, », per accessi/login admin «Bypass su Cookie». Moduli con Turnstile proteggere.

Operatività: Security Analytics osservare, impostare avvisi, Logs proteggere. Un piccolo script può attivare UAM automaticamente quando i ping falliscono – e avvisarvi. Esempi e snippet li documentiamo su zerlo.net/de/blog.

Cloudflare: regole utili di WAF/Rate Limit

(len(http.user_agent) = 0
 or lower(http.user_agent) contains "python"
 or lower(http.user_agent) contains "curl"
 or lower(http.user_agent) contains "bot"
 or lower(http.user_agent) contains "crawler")
=> Action: Managed Challenge

(http.request.method eq "POST"
 or starts_with(http.request.uri.path, "/api/")
 or http.request.uri.path contains "/sendMail.php")
=> Action: Managed Challenge

# Rate Limiting (Beispiel)
(http.request.method eq "POST" and starts_with(http.request.uri.path, "/api/"))
Threshold: 10 requests in 10 seconds per IP
Action: Challenge

# Doku:
# UAM: https://developers.cloudflare.com/fundamentals/reference/under-attack-mode/
# WAF: https://developers.cloudflare.com/waf/
# Rate Limiting: https://developers.cloudflare.com/waf/rate-limiting-rules/
# Challenges: https://developers.cloudflare.com/cloudflare-challenges/

cloudflare_uam_toggle.sh

#!/usr/bin/env bash
# Under-Attack-Mode per API setzen (Beispiel)
# Voraussetzung: CF_API_TOKEN mit Berechtigung 'Zone Settings Edit'
ZONE_ID="<ZONE_ID>"

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

# UAM AUS (z.B. wieder auf 'high' oder 'medium')
curl -sX PATCH "https://api.cloudflare.com/client/v4/zones//settings/security_level" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"value":"high"}'

# Mehr: https://developers.cloudflare.com/api/operations/zone-settings-change-security-level

nginx_rate_limit_example.conf

# Nginx: simples per-IP-Limit (Beispiel)
limit_req_zone $binary_remote_addr zone=perip:10m rate=30r/s;

server {
  location /api/ {
limit_req zone=perip burst=60 nodelay;
proxy_pass http://backend;
  }
}

# OWASP-DoS-Cheatsheet: https://cheatsheetseries.owasp.org/cheatsheets/Denial_of_Service_Cheat_Sheet.html

Altre risorse

Nozioni di base e approfondimenti: NIST-DoS, NIST-DDoS, CISA-DDoS, OWASP-DoS, Cloudflare Learning Center. Altri articoli pratici e strumenti li trovate su zerlo.net e in particolare su zerlo.net/de/tools.

Conclusione

Il DDoS non è una situazione di emergenza, ma un caso operativo. Chi riconosce rapidamente anomalie, le attenua temporaneamente e poi rafforza miratamente, resta online. Per i siti in crescita è Cloudflare come strato di protezione in linea fortemente consigliato: visibilità, misure immediate e mattoncini per un'operatività robusta. Per configurazioni individuali, checklist e snippet facciamo riferimento a quello Zerlo-Blog e ai Zerlo-Tools.