I proxy residenziali aggirano il blocco IP: cosa funziona

Circa un quarto dei nodi di uscita dei proxy residenziali venduti dai principali provider gira su dispositivi i cui proprietari non sanno di far parte dell'infrastruttura di qualcuno. Questa stima deriva da anni di lavoro accademico sulla misurazione di queste reti, e spiega parecchie cose, incluso il modo in cui una società di sicurezza ha recentemente individuato uscite di proxy residenziali all'interno di spazio IP assegnato all'Executive Office of the President. Quando i ricercatori hanno notato quel traffico, metà del quale arrivava tra le 17 e mezzanotte ora della costa orientale, internet ha fatto quello che fa sempre: ha scherzato. Ma sotto le battute c'è una lezione reale per tutti gli altri: i proxy residenziali sono il modo più efficace per aggirare le difese basate sugli IP, e se il tuo modello di minaccia considera ancora «IP residenziale» un segnale di fiducia, sei indietro di una generazione.

Ho passato quattro anni a occuparmi di rilevamento frodi per un'azienda SaaS di medie dimensioni, e il cambiamento si vedeva in tempo reale sulle nostre dashboard. Più o meno nel periodo in cui le squadre di credential stuffing sono passate dai proxy di datacenter alle uscite residenziali, le nostre blocklist IP sono passate dal bloccare l'80% del traffico d'attacco a non bloccarne quasi nulla. Stessi attacchi, stessi strumenti, diverso ultimo salto. Questo articolo parla del perché succede e di cosa funziona davvero quando la reputazione IP smette di funzionare.

Come funzionano davvero i proxy residenziali

Un proxy residenziale è semplicemente un nodo di uscita che gira su un dispositivo di consumo: uno smartphone, una smart TV, un decoder, un router di casa. Il cliente della rete proxy paga per il traffico che esce da questi dispositivi, e il compito del provider è avere milioni di nodi disponibili in ogni area geografica. La disponibilità arriva da tre fonti, in ordine decrescente di rispettabilità.

1. SDK con consenso esplicito. App gratuite — VPN, widget meteo, giochi mobile, app del tipo «guadagna condividendo la tua banda» — includono un SDK proxy. Il consenso è sepolto in termini di servizio che nessuno legge, ma tecnicamente esiste. È il modello a cui i grandi provider rimandano quando parlano di etica.
2. Firmware compromesso e malware. Le botnet monetizzano da anni rivendendo proxy. Un lettore multimediale Android economico con firmware dubbio installato in fabbrica è un nodo proxy nel momento in cui si connette. Il proprietario pensa di aver comprato un lettore multimediale.
3. Noleggio puro di botnet. La fascia bassa del mercato non fa finta di niente. Se un provider offre cinquanta milioni di IP rotanti senza una politica dichiarata sulla provenienza, basta fare due conti.

La parte importante è come appare dal lato del difensore. Il traffico arriva da un ASN residenziale di Comcast, BT o Deutsche Telekom. L'IP viene geolocalizzato in una città plausibile. Il reverse DNS restituisce qualcosa come pool-96-225-14-7.nycmny.fios.verizon.net. Ogni euristica che abbiamo costruito negli anni 2010 dice che si tratta di una persona a casa. Non è così. È un relay a 3 dollari al gigabyte, e la persona a casa non sa nemmeno che esiste.

Quest'ultimo punto merita enfasi, perché è la parte della storia che dovrebbe preoccuparti anche se non compri né combatti proxy. Lo stesso SDK che inoltra banda è un software sotto il controllo remoto di qualcun altro, in esecuzione dentro il perimetro della tua rete. Oggi vende banda. Niente nell'architettura impedisce all'operatore — o a chi compromette l'operatore — di usare quei nodi per qualcosa di peggio. Un SDK proxy su un dispositivo dentro una rete sensibile non è un problema di banda. È un punto d'appoggio con un ufficio fatturazione.

Perché le difese basate sugli IP sono morte

La reputazione IP aveva senso quando l'abuso veniva da posti che sembravano abuso: hosting a prova di proiettile, range di datacenter dirottati, proxy aperti su istanze VPS dimenticate. Si potevano elencare i quartieri malfamati. I proxy residenziali hanno chiuso quell'era spostando il traffico malevolo nei quartieri per bene, una stanza di soggiorno compromessa alla volta.

L'economia peggiora le cose. Lo spazio IP dei datacenter è finito e molto monitorato: bruci un /24 e finisce in ogni blocklist entro un giorno. I nodi di uscita residenziali sono praticamente infiniti e si rigenerano da soli. Una singola campagna di credential stuffing può ruotare tra decine di migliaia di IP domestici distinti, ognuno con due o tre richieste, senza mai far scattare i rate limit per IP. Il tuo WAF vede diecimila «utenti» diversi. Bloccare il singolo IP non serve a nulla; bloccare l'intero ASN significa bloccare i tuoi clienti veri.

È anche per questo che «il traffico arrivava dalla Casa Bianca» va preso con cautela, e gli scettici in ogni discussione su questa storia hanno ragione a sollevarlo. Possedere uno spazio IP non significa che ogni annuncio corrisponda a un'unica posizione fisica. Le grandi organizzazioni annunciano range da molti siti, gestiscono reti per ospiti, laboratori e overlay NAT dei carrier. Un IP di uscita nel range di un'organizzazione ti dice a chi è registrato lo spazio, non dalla scrivania di chi sono passati i pacchetti. Quando fai questa analisi sulla tua rete — e dovresti farla — tratta l'attribuzione come un'ipotesi da verificare sui log di flusso interni, non come una conclusione.

I segnali di rilevamento che funzionano ancora

La reputazione IP è morta, ma il traffico non è invisibile. Le uscite dei proxy lasciano impronte. Nessuno di questi segnali è sufficiente da solo — ognuno ha spiegazioni legittime — ma combinati sono sorprendentemente efficaci. È la mossa standard nell'ingegneria del rilevamento moderna: smettere di cercare la pistola fumante e iniziare a costruire un punteggio a partire da segnali deboli. La stessa filosofia compare nel fingerprinting comportamentale di script offuscati — non serve leggere il codice se puoi caratterizzare come si comporta.

Analisi di ASN e forma delle connessioni

Parti dall'ASN, ma non fermarti a «è residenziale?». La domanda utile è se l'ASN è coerente con il client dichiarato. Una richiesta che presenta un user agent di Chrome desktop e arriva dal range 5G consumer di un operatore mobile è sospetta. Lo è anche il traffico da un ASN di ISP domestico che colpisce la tua API con una concorrenza tipica di un datacenter. I singoli nodi proxy sono case vere, e le case vere hanno vincoli reali: banda di upload domestica, tabelle NAT, condivisione di indirizzi con carrier-grade NAT. Un IP di uscita che serve quaranta clienti proxy diversi in un'ora produce pattern di connessione che nessuna famiglia genererebbe.

Fingerprint TLS e TCP

Qui si beccano gli operatori sciatti. La maggior parte dei clienti proxy fa passare il traffico attraverso il software client del provider o tramite librerie HTTP standard — Python requests, net/http di Go, Node. Ognuna ha un ClientHello TLS distinto: ordine delle cipher suite, liste delle estensioni, gruppi supportati. Gli hash JA3 e JA4 ti permettono di confrontare ciò che l'handshake TLS dice sul client con ciò che lo user agent dichiara. Un «Chrome 126 su Windows» che invia un fingerprint TLS di Go è un bot travestito. Alcune reti proxy sofisticate fanno il passthrough TLS completo dalla macchina del cliente, il che preserva la bugia, ma molte no, e anche quelle buone perdono informazioni a livello TCP. Un client dichiarato Windows dietro un TTL e una dimensione della finestra che indicano Linux è un altro punto nel punteggio.

Latenza e pattern temporali

Ogni proxy residenziale aggiunge un salto attraverso hardware domestico su uplink domestici. Quel salto ha un costo. Se il tuo servizio vede anche la latenza reale del client tramite WebRTC, una misurazione dall'edge di una CDN o persino la distribuzione temporale delle richieste all'interno di una sessione, puoi confrontare l'RTT di rete con la geografia dichiarata. Un «utente a Denver» con un RTT di 4 ms verso il tuo datacenter in Virginia non si trova a Denver. Anche la temporizzazione all'interno delle sessioni conta: la navigazione umana ha pause di lettura, movimenti del mouse, cadenza irregolare. Il traffico che passa da un proxy e nasce da uno script di automazione ha una qualità da metronomo: intervalli tra richieste costanti, nessuna deriva da inattività, invio di moduli istantaneo. Anche quando gli attaccanti aggiungono jitter, è un jitter estratto da una distribuzione che un essere umano non produrrebbe mai.

Euristiche comportamentali

Il segnale più forte è cosa fa il client, non cosa è. Gli utenti reali vagano. I bot eseguono piani. Una sessione che fa il login, va direttamente alla pagina delle impostazioni tramite un URL che nessun percorso dell'interfaccia raggiunge, cambia l'email e invia una richiesta di pagamento in novanta secondi non è una persona, qualunque cosa dica il suo IP. Monitora l'entropia delle sequenze: le sessioni attraversano la tua app come il tuo frontend le guida davvero, oppure colpiscono endpoint in un ordine che solo chi legge la tua documentazione API sceglierebbe? L'aggregazione tra sessioni è la funzione killer qui. Un IP residenziale che fa tre richieste sembra innocente. Trecento IP residenziali che fanno ciascuno tre richieste con fingerprint TLS identici, risoluzioni di schermo identiche e la stessa sequenza di endpoint sono un'unica operazione con trecento travestimenti.

Caccia alle minacce: SDK proxy sulla tua rete

Il problema in ingresso attira l'attenzione, ma la storia che ha dato il via a tutto è in realtà una storia in uscita: un dispositivo su una rete che dovrebbe saperne di più stava inoltrando il traffico di altre persone. È lo scenario su cui puoi davvero agire, perché controlli il perimetro. Dai per scontato che prima o poi qualche utente collegherà un decoder compromesso o installerà una «VPN gratuita» su un telefono di lavoro. Il tuo compito è far sì che quell'evento faccia rumore.

La logica di rilevamento è semplice perché gli SDK proxy hanno una postura caratteristica. Un nodo esiste per ricevere istruzioni e inoltrare traffico, il che significa:

• Connessioni persistenti di controllo. Sessioni TLS di lunga durata verso domini o IP sconosciuti, spesso con piccoli payload periodici. Stabilisci una baseline delle destinazioni in uscita; un dispositivo client con una connessione di sei ore verso un host in un paese dove nessuno dei tuoi fornitori di software opera merita un controllo.
• Alto fan-out di connessioni da un dispositivo client. Una workstation che apre connessioni in uscita verso centinaia di IP esterni distinti all'ora si comporta come un'infrastruttura, non come una persona. I portatili navigano; i relay inoltrano.
• Flussi avviati dall'esterno verso le sottoreti client. Molti framework proxy aprono tunnel in ingresso o usano il NAT traversal in stile STUN. Se un dispositivo sulla tua VLAN ospiti o IoT riceve connessioni da internet, qualcosa nella tua segmentazione non va — trovalo.
• Pattern di upload asimmetrici. Un telefono o un decoder il cui volume di upload si avvicina a quello di download sta servendo contenuti o inoltrando traffico. Nessuno dei due è normale per dispositivi di consumo.
• Baseline per orario. I ricercatori che hanno individuato le uscite nella rete governativa si sono basati esattamente su questo: un'attività concentrata in orario serale suggeriva un dispositivo su una rete personale, non per ospiti. La tua versione è più semplice — genera un alert quando il pattern di traffico di un dispositivo cambia natura, non solo volume.

Nulla di tutto questo richiede la deep packet inspection, il che conta se ci tieni a gestire una rete di cui le persone possano fidarsi. I metadati di flusso — NetFlow, log di conn di Zeek, VPC flow log — contengono ogni segnale descritto sopra. Se non stai già conservando e facendo baseline dei dati di flusso in uscita, è questa la lacuna da colmare prima di comprare qualsiasi cosa. I punti ciechi qui assomigliano a quelli del logging dell'autenticazione cloud: i dati esistono, ma nessuno li guarda finché non c'è un incidente.

# Quick-and-dirty hunt: client devices acting like relays
# Feed this Zeek-style conn logs; flag RFC1918 sources with
# high distinct-destination fan-out and heavy upload ratios.
awk -F'\t' '
$3 ~ /^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01]))/ {
src=$3; dst=$5
up[src]+=$10; down[src]+=$12
seen[src SUBSEP dst]=1
}
END {
for (k in seen) { split(k,a,SUBSEP); fanout[a[1]]++ }
for (s in fanout)
if (fanout[s] > 200 && up[s] > down[s] * 0.5)
printf "%s dsts=%d up=%d down=%d\n", s, fanout[s], up[s], down[s]
}' conn.log | sort -t= -k2 -nr | head -20

È un primo passo, non un prodotto finito: calibra la soglia di fan-out sulle tue baseline e aspettati falsi positivi dai media server e dagli agent di backup finché non li metti in whitelist. Il punto è che la caccia costa poco. Un pomeriggio di analisi dei log trova ciò che un'appliance da sei cifre troverebbe.

La segmentazione è la vera soluzione

Ecco la mia forte opinione, maturata a fatica: non vincerai mai la corsa agli armamenti del rilevamento contro i dispositivi di consumo compromessi. L'offerta è troppo grande e i produttori che spediscono firmware insicuro non subiscono alcuna conseguenza. Quello che puoi fare è rendere un dispositivo compromesso noioso. Un decoder infetto su una VLAN IoT ben segmentata può vendere la sua banda a una rete proxy — fastidioso, potenzialmente imbarazzante se il tuo range IP è sensibile — ma non può raggiungere le tue condivisioni file, le API interne o qualsiasi cosa trasformi un imbarazzo in una violazione.

Negli incident review lo schema è sempre lo stesso. L'organizzazione aveva una rete piatta, oppure una rete «ospiti» che poteva raggiungere il DNS interno e le interfacce di gestione, oppure una policy BYOD applicata solo con un accordo da accettare con un clic. Poi un Android economico o un telefono con un SDK incluso si è connesso alla rete, e l'IP di uscita dell'organizzazione ha cominciato a comparire negli inventari dei provider proxy. La correzione a posteriori è ciò che avrebbe dovuto essere prima: isolamento dei client sulle reti ospiti, dispositivi IoT su una VLAN con accesso solo in uscita e destinazioni RFC1918 negate, dispositivi personali lontani dalle zone di fiducia della produzione. La difesa in profondità non è affascinante, ma come abbiamo sostenuto parlando di difese a strati contro singoli controlli forti, sono gli strati a salvarti quando un controllo cede — e uno cede sempre.

C'è anche una discussione di policy che vale la pena fare internamente. Le app «gratuite» sono il modo in cui questi SDK arrivano. Se il tuo personale può installare software arbitrario su dispositivi che toccano la rete, hai delegato il perimetro ad aziende di ad-tech mobile. Alcune organizzazioni rispondono con MDM e allowlist di app; per la maggior parte, la segmentazione di rete ottiene lo stesso contenimento con meno costi politici.

Cosa ci dice davvero questa storia

Tolte le speculazioni politiche, la storia è una dimostrazione lineare di due fatti. Primo, il rilevamento dei proxy residenziali è diventato una categoria di prodotto: i ricercatori ora possono elencare le uscite su larga scala e mapparle sullo spazio IP, il che è telemetria davvero utile. Secondo, e più scomodo, ogni rete è a un solo acquisto distratto di un dispositivo dall'essere infrastruttura di qualcun altro. Le reti più protette del mondo hanno ancora persone al loro interno, e le persone collegano le cose.

Se ti porti via una sola cosa: verifica se gli IP di uscita della tua organizzazione compaiono negli inventari dei proxy residenziali. Diversi servizi te lo diranno, e il tuo feed di threat intelligence potrebbe già includerlo. Trovare il tuo range elencato non è la prova di una compromissione — il carrier-grade NAT e lo spazio di indirizzi condiviso confondono il quadro — ma è un punto di partenza economico e ad alto segnale per una caccia. Poi vai a controllare il fan-out in uscita, le connessioni di lunga durata e il design delle tue VLAN.

Gli attaccanti sono entrati nei quartieri per bene anni fa. I difensori che se ne sono accorti sono quelli che hanno smesso di controllare gli indirizzi e hanno iniziato a osservare i comportamenti.