CGNAT spiegato: perché un indirizzo IP non equivale a un utente
Il carrier-grade NAT mette migliaia di abbonati dietro un unico indirizzo. Ecco cosa manda in crisi in blocchi basati su IP, rate limiting e analytics — e cosa fare invece.
Molte regole anti-abuso si basano ancora su un presupposto che da anni non regge più: l’idea che un indirizzo IP identifichi un utente. Il motivo principale si chiama carrier-grade NAT, o CGNAT.
Che cos’è il CGNAT
Gli indirizzi IPv4 sono finiti. Invece di acquistare spazio di indirizzamento sempre più raro per ogni abbonato, gli operatori mobili e molti ISP su rete fissa mettono i clienti dietro un pool condiviso di indirizzi pubblici, traducendo le porte in uscita. Un singolo indirizzo pubblico può rappresentare contemporaneamente centinaia o migliaia di abitazioni o smartphone.
Dal punto di vista del tuo server, tutto quel traffico sembra arrivare da un solo client.
Cosa rompe
Blocco. Se bannate un indirizzo dopo un tentativo di brute force, potreste aver tagliato fuori un intero isolato di utenti su rete mobile. L’attaccante si riconnette, ottiene in pochi secondi un nuovo indirizzo dal pool e riparte.
Rate limiting. Un limite di 10 richieste al minuto per IP è generoso per una singola persona, ma assurdamente stretto per 2,000 abbonati che condividono lo stesso punto di uscita. Finirete per rallentare utenti legittimi nelle ore di punta senza accorgervene, perché semplicemente se ne andranno.
Attribuzione. “Due account dallo stesso IP” è un indizio debole di multi-accounting su una rete di operatore. Su una linea in fibra residenziale può voler dire qualcosa. In presenza di CGNAT, quasi nulla.
Analytics. I conteggi dei visitatori unici basati sull’indirizzo risultano compressi sul mobile e gonfiati sulle reti che ruotano spesso gli indirizzi. In entrambi i casi, l’errore resta invisibile nella dashboard.
Come capire che state osservando CGNAT
Segnali che dovrebbero far alzare l’attenzione:
- Tipo di connessione indicato come mobile, oppure un ASN appartenente a un operatore mobile.
- Diversità molto elevata di richieste da un singolo indirizzo: molti user agent, molti account, molte localizzazioni.
- Indirizzi nello spazio di transizione condiviso (100.64.0.0/10) presenti negli header inoltrati.
Una lookup di IP intelligence fornisce direttamente i primi due elementi, abbastanza per modificare la policy al momento della richiesta.
Cosa fare invece
- Scalare i limiti in base alla classe di rete. Le connessioni residenziali possono avere un limite per IP più stretto. Le reti mobile e business richiedono soglie molto più ampie, compensate da controlli più severi per account e per dispositivo.
- Spostare l’identità a un livello più affidabile. Applicate il rate limiting su account ID, sessione o segnale del dispositivo ogni volta che è possibile. Usate l’IP come chiave secondaria, non come identificatore principale.
- Preferire le challenge ai blocchi. Una challenge crea un piccolo attrito su una rete condivisa; un blocco la punisce collettivamente.
- Far scadere tutto in fretta. Se dovete bloccare un indirizzo condiviso, ragionate in minuti, non in giorni. L’attaccante si sarà già spostato molto prima della scadenza del vostro ban.
- Monitorare l’impatto collaterale. Se un singolo ban rischia di colpire più di una manciata di account attivi, è un segnale forte che l’indirizzo è condiviso e che il ban è lo strumento sbagliato.
Il principio di fondo
L’indirizzo IP è una proprietà del percorso, non della persona. È un segnale di rischio potente, ma un pessimo identificatore. I sistemi che rispettano questa distinzione bloccano molto più abuso per ogni falso positivo rispetto a quelli che la ignorano — e l’adozione di IPv6, pur riportando in parte un indirizzamento per abbonato, non eliminerà il problema finché il traffico mobile continuerà a crescere.
