Rate limiting per indirizzo IP: progettare limiti efficaci negli ambienti con IP condivisi
Il rate limiting per indirizzo IP diventa complesso quando gli IP sono condivisi. In questo articolo vediamo come progettare limiti più solidi in presenza di proxy, VPN e NAT.
Il rate limiting è uno dei meccanismi di difesa fondamentali per proteggere applicazioni web e API da abusi, esaurimento delle risorse e attacchi denial-of-service. L’approccio più semplice e diffuso consiste nel conteggiare le richieste per indirizzo IP. Ma questo metodo mostra rapidamente i suoi limiti di fronte alla realtà delle reti moderne: gli indirizzi IP condivisi.
Gli IP condivisi sono ovunque: NAT aziendali, reti degli operatori mobili, Wi-Fi pubblici, VPN, proxy e nodi di uscita TOR. Affidarsi solo all’IP sorgente per identificare un utente o un’entità univoca porta inevitabilmente a bloccare utenti legittimi, generando falsi positivi, oppure a lasciare spazio ad attaccanti evoluti, che possono aggirare i limiti ruotando tra IP condivisi e producendo falsi negativi.
Questo articolo illustra alcune strategie per progettare limiti di rate limiting più resilienti negli ambienti con IP condivisi, andando oltre il semplice conteggio basato su IP /32 o /128.
Il problema di fondo: indirizzo IP != utente
In passato, un indirizzo IP era spesso fortemente correlato a un singolo utente, o a un piccolo gruppo di utenti dietro un NAT statico. Oggi questa assunzione non regge più:
- Operatori mobili: Migliaia, o persino decine di migliaia, di utenti possono condividere un unico indirizzo IPv4 pubblico tramite Carrier-Grade NAT (CGNAT).
- Reti aziendali: Le grandi organizzazioni spesso convogliano tutto il traffico in uscita attraverso un pool limitato di IP pubblici.
- Wi-Fi pubblici/Hotspot: Molti utenti si connettono contemporaneamente tramite un unico IP di gateway.
- Proxy, VPN, TOR: Questi servizi raggruppano esplicitamente più utenti dietro IP condivisi, per motivi di privacy o per aggirare restrizioni. Gli attaccanti li sfruttano per restare anonimi e distribuire il carico su molti IP.
- Cloud provider/Data center: I workload eseguiti in ambienti cloud o data center provengono spesso da grandi intervalli IP noti, condivisi da numerosi tenant.
Quando un numero elevato di utenti legittimi condivide lo stesso IP, un semplice limite per IP viene raggiunto rapidamente, con il rischio di bloccarli tutti. Al contrario, un attaccante può ruotare tra un pool di IP proxy, ciascuno apparentemente sotto la soglia prevista, e superare nel complesso il limite che si voleva imporre.
Oltre il semplice IP: arricchire i segnali del rate limiting
Per costruire limiti più robusti, è necessario integrare segnali aggiuntivi rispetto al solo IP sorgente immediato.
1. Identificativi centrati sull’utente
Quando sono disponibili e appropriati, è preferibile associare i limiti a un ID utente invece che esclusivamente a un IP. È la soluzione ideale per le azioni autenticate.
- Session ID/Cookie: Tracciare le richieste per sessione. Questo aiuta a individuare azioni ripetute dallo stesso
