Configurazione Cloudflare per siti web aziendali: velocità e sicurezza, passo dopo passo

Cloudflare si trova tra i tuoi visitatori e il tuo server. I visitatori si connettono al vicino data center di Cloudflare, che serve direttamente i file memorizzati nella cache, filtra il traffico ostile e inoltra il resto al tuo server. Per un'azienda, ciò significa pagine più veloci per i clienti lontani dalla posizione di hosting, protezione da semplici inondazioni di negazione del servizio e un luogo in cui applicare le regole di sicurezza senza modificare il codice dell'applicazione. Molti piani iniziano gratuitamente e i piani a pagamento aggiungono funzionalità, quindi controlla il confronto dei piani attuali prima di decidere.

Non sostituisce il software con patch e il codice protetto. La nostra lista di controllo sulla sicurezza PHP è ancora valida. Pensa a Cloudflare come a una solida porta d'ingresso, non a un sostituto per chiudere a chiave le stanze all'interno.

Prima di iniziare

• Fai l'inventario dei tuoi DNS. Esporta o fai uno screenshot di ogni record presso il tuo attuale provider DNS, inclusi i record di posta (MX, SPF, DKIM, DMARC) e di verifica. Un record mancato è il classico modo per interrompere la posta elettronica durante una migrazione.
• Scopri chi possiede l'account del registrar del dominio e assicurati che si tratti di un account aziendale con autenticazione a più fattori. Cambierai i nameserver lì.
• Se possibile, abbassa il TTL dei record chiave un giorno prima, in modo che le modifiche si diffondano più rapidamente.
• Scegli un momento tranquillo e dillo alla squadra. Pianifica un rollback: i vecchi nameserver, scritti.

Passaggio 1: aggiungi il sito e controlla i DNS

Aggiungi il tuo dominio nella dashboard Cloudflare. Esegue la scansione dei record esistenti. Confrontali con il tuo inventario e correggi le lacune. Per ogni record scegli tra due modalità:

• Proxied (nuvola arancione): il traffico passa attraverso Cloudflare. Utilizzalo per i nomi host del tuo sito web e delle tue applicazioni web.
• Solo DNS (nuvola grigia): Cloudflare risponde semplicemente alla query DNS. Utilizzare per server di posta, nomi host SSH o FTP e tutto ciò che non è traffico HTTP o HTTPS.

Quindi aggiorna i nameserver presso il tuo registrar. Una volta che il sito risulta attivo, controlla il tuo sito e invia un'e-mail di prova.

Passaggio 2: imposta correttamente la crittografia

Questa è l'impostazione che danneggia la maggior parte dei siti. Cloudflare dispone di diverse modalità SSL/TLS:

• Flessibile: crittografa il visitatore su Cloudflare ma invia il traffico al tuo server non crittografato. Sembra che funzioni, ma la seconda tratta è aperta e spesso causa cicli di reindirizzamento. Evitatelo.
• Completo: crittografa entrambe le gambe ma non verifica il certificato del server.
• Completo (rigoroso): crittografa entrambe le gambe e verifica il certificato sul tuo server. Questo è quello da usare.

Installa prima un certificato valido sul tuo server. Funzionano entrambi un certificato CA Cloudflare Origin o un certificato Let's Encrypt gratuito. Quindi passa a Completo (ristretto), attiva Usa sempre HTTPS, imposta una versione TLS minima di 1.2 e abilita HSTS solo dopo che tutto funziona su HTTPS, perché HSTS dice ai browser di rifiutare il semplice HTTP per un lungo periodo.

Passaggio 3: rendi Cloudflare impossibile da aggirare

Se gli aggressori conoscono il vero indirizzo IP del tuo server, possono inviare traffico direttamente ad esso e ignorare ogni protezione configurata. Risolvilo in due modi:

• Consenti il traffico web al tuo server solo dagli intervalli IP pubblicati di Cloudflare.
• Ripristina l'IP reale del visitatore nel tuo server web, perché altrimenti ogni richiesta nei tuoi registri, limiti di velocità e analisi sembrerebbe provenire da Cloudflare.

#!/usr/bin/env bash
# /opt/cf/update_cloudflare_ips.sh - run weekly from cron
set -euo pipefail
IPS="$(curl -fsS https://www.cloudflare.com/ips-v4) $(curl -fsS https://www.cloudflare.com/ips-v6)"

# 1) real visitor IP for Nginx
OUT=/etc/nginx/conf.d/cloudflare_real_ip.conf
{
  for r in $IPS; do echo "set_real_ip_from $r;"; done
  echo "real_ip_header CF-Connecting-IP;"
} > "$OUT.tmp" && mv "$OUT.tmp" "$OUT"
nginx -t && nginx -s reload

# 2) firewall: allow HTTPS only from Cloudflare (remove any generic "allow 443" rule first)
for r in $IPS; do ufw allow proto tcp from "$r" to any port 443 comment 'cloudflare'; done

Un dettaglio importante per gli utenti Docker: le porte pubblicate da Docker ignorano le regole ufw. Associa i contenitori all'host locale dietro un proxy inverso o limita l'accesso nella catena firewall DOCKER-USER di Docker. Per un isolamento più forte, Cloudflare Tunnel consente al tuo server di effettuare solo una connessione in uscita, quindi non ha bisogno di porte web in entrata aperte. Per i webhook di pagamento e altre integrazioni server-server, assicurati che le regole IP consentano comunque il passaggio di tali richieste se non passano tramite Cloudflare.

Passaggio 4: regole di memorizzazione nella cache

Per impostazione predefinita, Cloudflare memorizza nella cache file statici come immagini, CSS e JavaScript, ma non HTML. Una politica sensata per un tipico sito PHP:

• Asset statici: cache per un lungo periodo (un mese o più). Utilizza nomi di file con versione o una stringa di query come app.css?v=123 in modo che una nuova distribuzione venga rilevata immediatamente.
• Pagine HTML pubbliche (pagine di marketing, blog): possono essere memorizzate nella cache per minuti o ore con una regola di cache. Prova attentamente.
• Non memorizzare mai nella cache: amministratore, account, carrello, checkout, endpoint API e qualsiasi pagina che dipenda da un cookie di accesso. Crea una regola di bypass per questi percorsi e per le richieste che trasportano il cookie di sessione.

Elimina automaticamente dopo ogni distribuzione in modo che i clienti non vedano mai file obsoleti. Crea un token API con solo l'autorizzazione "Cache Purge" per questa zona e chiamalo dal tuo script di distribuzione:

# purge selected files after a deployment
curl -sS -X POST "https://api.cloudflare.com/client/v4/zones/$CF_ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/css/app.css","https://example.com/js/app.js"]}'

Le pagine più veloci aiutano anche la ricerca e le conversioni. Consulta la nostra guida Core Web Vitals per i siti PHP per sapere cosa correggere sul lato server una volta installato il CDN.

Passaggio 5: firewall, bot e limitazione della velocità

• Attiva le regole WAF gestite disponibili nel tuo piano. Bloccano i modelli di attacco comuni prima che raggiungano il tuo codice.
• Abilita la protezione bot adatta al tuo piano e osserva le analisi prima di stringere qualsiasi cosa.
• Endpoint sensibili ai limiti di velocità: accesso, reimpostazione della password, registrazione e pagamento. Gli attacchi di forza bruta e di test delle carte prendono di mira esattamente questi.
• Esente il traffico delle macchine attendibili: i webhook dei fornitori di pagamenti, i servizi di monitoraggio e le tue integrazioni non devono essere colpiti dalle sfide del browser, poiché una pagina di sfida restituita a un webhook sembra un errore.

# Custom rule 1: block probes for secrets and repositories (action: Block)
(http.request.uri.path contains "/.env" or http.request.uri.path contains "/.git" or http.request.uri.path contains "wp-config")

# Custom rule 2: let payment webhooks through (action: Skip, security features)
(http.request.uri.path in {"/webhooks/stripe" "/webhooks/paypal"})

# Rate limiting rule: at most 10 login attempts per minute per IP
(http.request.uri.path eq "/login" and http.request.method eq "POST")  =>  10 requests / 1 minute / IP

La sintassi delle regole e i campi disponibili variano in base al piano, quindi considerali come modelli ed esegui prima il test in modalità "log". Mantieni anche le protezioni a livello di applicazione: i controlli della firma dei webhook, come nella nostra guida ai webhook Stripe, non dipendono mai solo dalle regole di rete.

Passaggio 6: verificare la configurazione

# is traffic going through Cloudflare?
curl -sI https://example.com | grep -iE "^(server|cf-cache-status|cf-ray)"

# does the origin refuse direct access? (replace with your server IP; expect a timeout or refusal)
curl -sI --max-time 8 https://203.0.113.10 -H "Host: example.com" -k

# are the nameservers and mail records right?
dig NS example.com +short
dig MX example.com +short
dig TXT example.com +short

Controlla due volte un file statico: la seconda risposta dovrebbe mostrare cf-cache-status: HIT. Controlla i flussi di accesso, pagamento e amministrazione con un browser reale e invia e ricevi un'e-mail di prova.

Errori comuni

• SSL flessibile e cicli di reindirizzamento che seguono.
• Proxy del nome host di posta (deve essere solo DNS) o dimenticanza di un record di posta durante lo spostamento.
• Memorizzazione nella cache delle pagine private, in modo che un cliente veda la pagina dell'account di un altro. Ignora sempre la cache per il traffico connesso.
• Lasciando l'origine esposta: l'IP reale è visibile nei vecchi record DNS, nelle intestazioni delle e-mail o nei registri dei certificati. Limita il firewall e valuta la possibilità di modificare l'IP in caso di perdita.
• Non ripristinare l'IP reale, il che viola i limiti di velocità, i registri e i controlli antifrode.
• Webhook e API impegnativi, che causano errori silenziosi nei pagamenti e nelle integrazioni.
• Limiti dimensione richiesta: le richieste proxy hanno una dimensione massima del corpo a seconda del piano. Controlla il limite attuale se la tua applicazione accetta caricamenti di grandi dimensioni.
• Dimenticando il monitoraggio. Aggiungi avvisi per la scadenza di certificati e domini e mantieni i controlli di uptime, come descritto nella nostra guida al backup e al monitoraggio.

Una lista di controllo di una pagina

1. Inventario DNS esportato, account registrar protetto.
2. Sito aggiunto, record revisionati, proxy solo per nomi host web.
3. Certificato di origine installato, modalità SSL completa (rigorosa), utilizza sempre HTTPS attivato.
4. Firewall limitato agli intervalli Cloudflare, IP dei visitatori reali ripristinato.
5. Regole di cache per risorse statiche, bypass per percorsi privati, eliminazione nello script di distribuzione.
6. WAF gestito attivato, limiti di velocità per accesso e pagamento, webhook esentati.
7. Vengono eseguiti comandi di verifica, avvisi configurati, rollback documentato.

Come possiamo aiutare

Configuriamo Cloudflare, pipeline di hosting e distribuzione per applicazioni PHP e le colleghiamo a sistemi di pagamento, CRM e messaggistica. Leggi informazioni sul nostro servizio di integrazione o prenota una breve chiamata ed esamineremo la tua configurazione DNS, SSL e di memorizzazione nella cache rispetto a questo elenco di controllo.