Come verificare che un reverse proxy invii l'indirizzo IP corretto del client

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How to Verify a Reverse Proxy Is Sending the Correct Client IP

Verifica l'inoltro dell'IP client confrontando una fonte esterna nota con ogni header proxy e l'indirizzo finale analizzato dal backend.

Un reverse proxy termina la connessione client, quindi il backend normalmente vede l'indirizzo socket del proxy a meno che il proxy non trasmetta metadati di richiesta attendibili. Il test deve distinguere l'indirizzo del peer diretto da Forwarded, X-Forwarded-For e X-Real-IP, documentare ogni hop attendibile e dimostrare che un client internet non può falsificare il valore usato per i log, i limiti di velocità o il controllo degli accessi.

Crea un Test di Client-IP Conosciuto da Fuori Casa

Usa un dispositivo con dati mobili o un'altra rete esterna e registra il suo indirizzo IPv4 o IPv6 pubblico immediatamente prima della richiesta. Invia un percorso unico, un valore di query o un timestamp attraverso il reverse proxy pubblico.

MDN descrive X-Forwarded-For come un header de facto per preservare il indirizzo client originario attraverso le connessioni proxy.

Raccogli il log del proxy di frontiera, qualsiasi log di proxy intermedio e il log dell'applicazione backend per quella singola richiesta. Senza una fonte nota e un timestamp correlato, più utenti concorrenti possono rendere ambigua la catena degli header.

Registra il Socket Peer e Ogni Header Inoltrato

Al backend, registra separatamente l'indirizzo TCP peer diretto da Forwarded, X-Forwarded-For, X-Real-IP e qualsiasi header client specifico del CDN. Non sovrascrivere i valori grezzi durante il primo test.

Un'analisi pratica della gestione dell'IP client “reale” avverte che l'accuratezza dipende da come il proxy imposta o aggiunge gli header e se i valori precedenti possono essere falsificati. Il modello di fiducia dell'intera catena proxy deve corrispondere all'architettura di rete effettiva.

Il socket peer del backend dovrebbe corrispondere al proxy attendibile immediato, mentre l'indirizzo client selezionato dovrebbe corrispondere al dispositivo di test esterno. Se il backend registra solo l'indirizzo del proxy, la creazione o l'analisi degli header manca.

Verifica Come Ogni Proxy Aggiunge o Sostituisce l'Header

Ispeziona ogni hop dal CDN o tunnel al proxy di frontiera, proxy interno e applicazione. Registra se ogni hop aggiunge a una lista esistente, sostituisce input non attendibili o passa l'header senza modifiche.

Sling Academy spiega che NGINX può impostare X-Real-IP dalla connessione immediata e aggiungere una catena con proxy_add_x_forwarded_for.

Configura il primo edge attendibile per rimuovere o sostituire gli header di inoltro forniti dal client, quindi aggiungi gli indirizzi negli hop interni controllati. Evita di accettare ciecamente il valore più a sinistra o più a destra senza definire quanti proxy sono attendibili.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Configura il Backend per Fidarsi Solo degli Indirizzi Proxy Conosciuti

Imposta la lista di proxy attendibili dell'applicazione o del server web agli indirizzi esatti del reverse proxy o ai subnet controllati. Conferma che le connessioni dirette da client LAN ordinari o internet non siano trattate come fonti attendibili di header.

La spiegazione di Ip2Geo nota che la connessione dell'applicazione origina dal bilanciatore di carico o reverse proxy e che analizzare l'IP originale in modo sicuro richiede una regola di hop attendibile piuttosto che accettare input arbitrari.

Se l'indirizzo del proxy cambia a causa di container, reti overlay o un CDN, documenta l'intervallo supportato e aggiornalo deliberatamente. Non fidarti di tutti gli indirizzi privati solo perché il proxy ne usa attualmente uno.

Esegui un Test con Header Falsificato

Dal dispositivo di test esterno, invia un valore X-Forwarded-For o Forwarded contraffatto mentre ti connetti attraverso il proxy reale. Confronta l'header grezzo in ingresso, l'header proxy normalizzato e l'indirizzo client selezionato dal backend.

Il risultato corretto è che l'edge attendibile sostituisce o aggiunge in modo sicuro l'input non attendibile e il backend seleziona l'indirizzo basandosi sul conteggio di hop attendibili documentato. Un indirizzo falsificato non deve diventare il valore usato per l'autenticazione o la lista di accesso.

Ripeti un test diretto al backend da un segmento LAN se quella porta è raggiungibile. Il backend dovrebbe ignorare gli header inoltrati da un client diretto non attendibile e registrare il peer socket effettivo.

Valida IPv4, IPv6 e Percorsi Multi-Proxy

Ripeti il test tramite IPv4 e IPv6, tramite il normale hostname pubblico e tramite qualsiasi CDN, tunnel o proxy secondario usato in produzione. Conferma che i log preservino formati di indirizzo validi e non tronchino la catena.

La guida ZimaSpace a identità della richiesta reverse-proxy fornisce il contesto circostante sul perché i valori inoltrati corretti siano importanti oltre il semplice logging.

Il proxy è verificato solo quando la fonte nota corrisponde all'IP client analizzato, i proxy attendibili rimangono visibili nella catena grezza, i tentativi di spoof falliscono e i controlli di sicurezza usano il valore normalizzato in modo coerente. Ricontrolla dopo aver aggiunto un CDN, tunnel o un altro hop proxy.