WAF blocca i clienti mobili a causa del CGNAT: 6 controlli e come risolvere i blocchi

Se la conversione dal traffico mobile è improvvisamente diminuita e il modulo di registrazione o pagamento restituisce un errore 403 ai clienti reali, probabilmente non è colpa di un hacker, ma del tuo stesso WAF. Il firewall vede migliaia di richieste da un unico indirizzo IP di un operatore mobile e lo interpreta come un attacco DDoS o un brute force. In realtà, dietro a questo IP ci sono centinaia o migliaia di persone comuni: è la tecnologia CGNAT. Vediamo come scoprirlo e risolverlo, senza aprire una falla per attacchi reali.

Che cos'è il CGNAT e perché crea problemi

CGNAT (Carrier-Grade NAT) è una tecnologia utilizzata dagli operatori di telefonia mobile a causa della scarsità di indirizzi IPv4. Invece di assegnare a ciascun abbonato un IP pubblico unico, l'operatore "nasconde" migliaia di utenti dietro uno o più indirizzi condivisi. Per il sito, questo si traduce in traffico proveniente da un unico IP da centinaia di persone diverse contemporaneamente: dispositivi diversi, browser diversi, comportamenti diversi, ma lo stesso indirizzo esterno.

Per un normale server web, questo non è un problema: elabora semplicemente le richieste. Ma per i sistemi di protezione che conteggiano le richieste in un'unità di tempo da un IP, questo appare come un'anomalia. Immagina: in un minuto, da un indirizzo arrivano 200 richieste alla pagina di accesso. Per il WAF, questo è un classico schema di brute force o scraping. In realtà, potrebbero essere 150 clienti reali di un operatore mobile nella tua regione che hanno semplicemente aperto il sito contemporaneamente dopo una campagna pubblicitaria o una pubblicazione sui social media.

Il problema è particolarmente acuto nei paesi con un'alta densità di internet mobile: gli operatori raggruppano un enorme numero di abbonati dietro un numero minimo di IP esterni. Ecco perché è necessario testare il comportamento del sito non da un normale IP di data center, ma proprio da proxy mobili, che passano realmente attraverso l'infrastruttura CGNAT dell'operatore: solo in questo modo è possibile riprodurre la stessa situazione che vede il WAF con gli utenti reali.

Perché il WAF vede una minaccia nel CGNAT

La maggior parte delle soluzioni WAF - Cloudflare, AWS WAF, Imperva, moduli integrati Nginx/ModSecurity - utilizza il rate-limiting per indirizzo IP come meccanismo di base per la protezione da bot e DDoS. La logica è semplice: se da un IP arrivano più di N richieste in T secondi, blocchiamo o mostriamo un captcha. Questa regola funziona bene per attacchi classici da un dispositivo, ma si rompe completamente sul traffico CGNAT.

Ci sono diversi scenari tipici in cui questo si verifica:

• Rate-limiting per IP. Il limite di "100 richieste al minuto da un IP" è normale per il traffico di data center, ma catastrofico per una regione mobile con un milione di abbonati dietro un unico indirizzo.
• Punteggio comportamentale. Se il sistema accumula "reputazione" per un IP basata sulla cronologia delle richieste, un singolo utente "cattivo" dietro CGNAT può rovinare la reputazione dell'indirizzo per migliaia di clienti onesti successivi.
• Heuristica geografica. A volte il WAF contrassegna un IP come sospetto se rileva bruschi picchi di attività, non tipici di un "normale" utente: il comportamento di un indirizzo CGNAT è proprio questo: carichi di picco durante le ore di attività del pubblico.
• Blocco per ASN dell'operatore. Alcune regole WAF bloccano interi intervalli ASN degli operatori mobili se in precedenza ci sono stati attacchi da questi intervalli: tutti i clienti dell'operatore nel paese vengono colpiti.

Risultato: più rigido è il WAF "out of the box", maggiore è la possibilità che blocchi non i bot, ma il tuo reale pubblico mobile, specialmente se il business è orientato verso paesi con un internet mobile sviluppato e un'alta percentuale di traffico CGNAT.

Quali sono i rischi per il business: clienti e denaro persi

Il problema dei blocchi CGNAT è raramente visibile nell'analisi standard. Google Analytics e Yandex.Metrica non registrano semplicemente chi ha ricevuto un errore 403 a livello di WAF: tali visite spesso non arrivano nemmeno al contatore. Di conseguenza, il marketer vede un calo della conversione, ma non comprende la causa e inizia a ottimizzare creatività e landing page, anche se il problema è nell'infrastruttura.

Le conseguenze reali per diversi segmenti di business:

• E-commerce. Un acquirente da internet mobile non riesce a completare l'ordine: il modulo di pagamento restituisce un errore, il carrello si perde. Perdite dirette di fatturato, particolarmente evidenti dopo il lancio di pubblicità su TikTok Ads o Facebook Ads, dove il traffico principale è mobile.
• SaaS e registrazioni. L'utente cerca di registrarsi o accedere al proprio account, riceve un captcha a ogni passo o viene bloccato - si rivolge a un concorrente.
• Contenuti e pubblicità. Il traffico pubblicitario da dispositivi mobili si "disconnette" massicciamente sulla landing page, il budget pubblicitario viene speso, ma non ci sono conversioni: gli algoritmi delle piattaforme pubblicitarie interpretano questo come una bassa qualità del pubblico e aumentano il costo per clic.
• Servizio clienti. Aumenta il numero di segnalazioni "il tuo sito non si apre", "non riesco a registrarmi" - e il supporto tecnico non vede il problema, perché accede da desktop tramite Wi-Fi dell'ufficio senza CGNAT.

La cosa più sgradevole è che tali blocchi sono difficili da diagnosticare a posteriori, perché il log del WAF mostra un unico IP "sospetto" con un numero enorme di richieste, e l'amministratore vede in questo una conferma della correttezza del blocco, e non un falso allarme.

6 controlli con IP mobili per identificare il problema

Per capire se il tuo WAF sta bloccando clienti mobili onesti, è necessario riprodurre le reali condizioni del CGNAT - cioè testare il sito con veri IP mobili di diversi operatori e regioni. Ecco una checklist pratica di 6 controlli.

Controllo 1: Accesso massivo da un unico IP mobile

Configura diverse sessioni parallele attraverso lo stesso IP mobile (questo è naturale per i proxy con CGNAT dell'operatore) ed esegui 50-100 azioni normali - apertura di pagine, aggiunta al carrello, navigazione tra le sezioni. Se dopo una certa soglia inizia a comparire un captcha o un 403 - questo è il primo segnale di un problema.

Controllo 2: Cambio User-Agent con un unico IP

Un indirizzo CGNAT gestisce diversi dispositivi - iPhone, Android, diversi browser. Esegui richieste con diverse stringhe User-Agent attraverso un unico IP e verifica se si attiva la regola WAF "variabilità sospetta dei dispositivi da un unico indirizzo".

Controllo 3: Test su moduli critici

Segui il percorso completo del cliente - registrazione, accesso, completamento dell'ordine, pagamento - proprio attraverso l'IP mobile dell'operatore. Spesso il WAF è impostato in modo più aggressivo proprio sui moduli di inserimento dati (login, pagamento), dove il rischio di brute force è maggiore, e questo è il primo luogo dove si perdono clienti reali.

Controllo 4: Verifica con diversi operatori e regioni

Il comportamento del CGNAT varia tra diversi operatori e paesi: in alcuni casi, dietro un unico IP si nascondono 50 abbonati, in altri 5000. Testa il sito con IP mobili di diversi operatori nelle geo chiave per il business, per capire se ci sono specifiche regionali nei blocchi.

Controllo 5: Analisi della risposta del server per codici e intestazioni

Registra non solo il fatto del blocco, ma il codice HTTP esatto e le intestazioni di risposta (ad esempio, cf-mitigated: challenge di Cloudflare). Questo aiuterà a capire quale meccanismo di protezione è scattato - rate-limit, rilevamento bot o regola geografica.

Controllo 6: Monitoraggio a lungo termine della reputazione IP

Ripeti il test dallo stesso IP mobile per diversi giorni. Se l'accesso peggiora nel tempo senza motivi apparenti da parte tua, significa che il sistema di punteggio cumulativo "rovina" la reputazione dell'indirizzo a causa dell'attività di altri abbonati dietro lo stesso CGNAT, e questo è un problema sistemico, non occasionale.

Come configurare il WAF per non bloccare i clienti onesti

Dopo la diagnosi, è necessario correggere le regole di protezione in modo da non perdere il livello di sicurezza, ma smettere di bloccare gli utenti mobili reali. Ecco i principali approcci.

Problema	Soluzione nel WAF
Rate-limit rigido per IP	Aumentare il limite per gli ASN noti degli operatori mobili o passare a un limite per sessione/cookie invece che per IP puro
Punteggio di reputazione IP cumulativo	Ridurre il tempo di "memoria" della reputazione per gli intervalli CGNAT, aggiungere una whitelist per gli ASN noti degli operatori
Blocco per geo/ASN intero	Sostituire il blocco totale con una sfida morbida (verifica JS) invece di un 403
Captcha rigido sui moduli di accesso	Attivare il captcha in modo adattivo - solo in presenza di reali segni di brute force (numerosi tentativi falliti da un unico account), e non solo per il fatto di un IP CGNAT

Una buona pratica è mantenere un elenco personale degli intervalli noti degli operatori mobili per le tue geo chiave e fornire loro regole separate, più morbide rispetto al traffico internet normale. Questo richiede tempo per la configurazione, ma riduce drasticamente il numero di falsi blocchi.

Strumenti per il test con proxy mobili

Per un audit regolare della protezione del sito, è comodo utilizzare una combinazione di browser anti-detect e proxy mobili. I browser anti-detect (Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) consentono di creare profili isolati con diverse impronte di dispositivo, mentre i proxy mobili forniscono traffico CGNAT reale dagli operatori.

Un approccio passo dopo passo per il test:

1. Crea diversi profili nel browser anti-detect con diverse impostazioni del dispositivo (diverso User-Agent, risoluzione dello schermo, fuso orario).
2. Collega a ciascun profilo proxy mobili della regione e dell'operatore desiderati - questo fornirà un comportamento CGNAT reale.
3. Segui gli scenari utente chiave: registrazione, accesso, aggiunta al carrello, pagamento.
4. Registra tutti i casi di captcha, 403 e altri blocchi, confrontali con le impostazioni del WAF.
5. Ripeti il test tramite proxy residenziali per il confronto - questo aiuterà a capire se il problema è specifico per il traffico mobile.

Per testare parallelamente in diverse geo, sono utili anche proxy residenziali - aiutano a valutare quanto il WAF sia aggressivo per il traffico domestico normale e per il CGNAT mobile. Se prevedi test di carico con infrastruttura server senza legami con l'operatore, per controlli senza l'effetto CGNAT puoi collegare proxy di data center - forniranno una linea di base pulita senza distorsioni tipiche delle reti mobili.

Questo approccio complessivo - IP mobili, residenziali e di data center in un unico test - fornisce un quadro completo: vedi esattamente dove scatta la protezione e per quale tipo di traffico, e non indovini in base a segni indiretti nei log.

Domande frequenti

È possibile escludere completamente gli intervalli CGNAT dalle regole WAF?
Non è consigliato - questo ridurrebbe la protezione da attacchi reali, che possono anche provenire attraverso reti mobili. È più corretto allentare le soglie e passare a una sfida morbida invece di un blocco rigido.

Con quale frequenza è necessario eseguire tali controlli?
Almeno una volta al mese e sicuramente dopo qualsiasi modifica delle regole WAF o il lancio di una nuova campagna pubblicitaria per il pubblico mobile.

Influisce su SEO?
Sì - se i bot dei motori di ricerca o gli utenti reali da dispositivi mobili ricevono un 403, questo aumenta il tasso di rimbalzo e può influire negativamente sulle metriche comportamentali di ranking.

Conclusione

Il CGNAT non è una minaccia, ma una caratteristica dell'internet mobile, con cui si confronta praticamente qualsiasi business con un pubblico mobile. Il problema non è nella tecnologia stessa, ma nel fatto che le impostazioni standard del WAF non considerano inizialmente la sua specificità e puniscono gli utenti onesti per comportamenti tipici delle normali reti mobili. I sei controlli di questo articolo aiuteranno a diagnosticare rapidamente se stai perdendo clienti a causa di falsi blocchi, e una regolazione mirata delle regole WAF può ripristinare la conversione senza ridurre il livello di protezione.

Se prevedi di testare regolarmente il comportamento del sito e dei funnel pubblicitari come li vedono i veri clienti mobili, ti consigliamo di utilizzare proxy mobili - forniscono traffico CGNAT reale dagli operatori e consentono di identificare i falsi blocchi prima che li trovino i tuoi clienti.