Hoe controleer je of een reverse proxy het juiste client-IP verzendt?

Verifieer client-IP-forwarding door een bekende externe bron te vergelijken met elke proxy-header en het uiteindelijk geparseerde adres van de backend.

Een reverse proxy beëindigt de clientverbinding, dus ziet de backend normaal gesproken het socketadres van de proxy, tenzij de proxy vertrouwde request-metadata doorgeeft. De test moet het directe peer-adres onderscheiden van Forwarded, X-Forwarded-For en X-Real-IP, elke vertrouwde hop documenteren en bewijzen dat een internetclient de waarde die wordt gebruikt voor logs, rate limits of toegangscontrole niet kan vervalsen.

Maak een Bekende Client-IP Test Van Buiten het Thuisnetwerk

Gebruik een apparaat op mobiel dataverkeer of een ander extern netwerk en noteer het publieke IPv4- of IPv6-adres direct vóór het verzoek. Verstuur een uniek pad, querywaarde of tijdstempel via de publieke reverse proxy.

MDN beschrijft X-Forwarded-For als een de facto header voor het behouden van het oorspronkelijke clientadres over proxyverbindingen heen.

Verzamel de edge proxy-log, elke tussenliggende proxy-log en de backend applicatielog voor dat ene verzoek. Zonder een bekende bron en gecorreleerde tijdstempel kan de headerketen ambigu zijn door meerdere gelijktijdige gebruikers.

Registreer de Socket Peer en Elke Forwarded Header

Log aan de backend het directe TCP-peeradres apart van Forwarded, X-Forwarded-For, X-Real-IP en elke CDN-specifieke clientheader. Overschrijf de ruwe waarden niet tijdens de eerste test.

Een praktische analyse van het omgaan met “echte” client-IP’s waarschuwt dat de nauwkeurigheid afhangt van hoe de proxy headers instelt of toevoegt en of eerdere waarden vervalst kunnen worden. Het volledige proxy-trustmodel moet overeenkomen met de daadwerkelijke netwerkarchitectuur.

De backend socket peer moet gelijk zijn aan de directe vertrouwde proxy, terwijl het geselecteerde clientadres gelijk moet zijn aan het externe testapparaat. Als de backend alleen het proxyadres logt, ontbreekt headercreatie of -parsing.

Verifieer Hoe Elke Proxy de Header Toevoegt of Vervangt

Inspecteer elke hop van CDN of tunnel tot edge proxy, interne proxy en applicatie. Registreer of elke hop toevoegt aan een bestaande lijst, onbetrouwbare input vervangt of de header ongewijzigd doorgeeft.

Sling Academy legt uit dat NGINX X-Real-IP kan instellen vanuit de directe verbinding en een keten kan toevoegen met proxy_add_x_forwarded_for.

Configureer de eerste vertrouwde edge om door de client aangeleverde forwarding headers te verwijderen of te vervangen, en voeg vervolgens adressen toe bij gecontroleerde interne hops. Vermijd het blindelings accepteren van de meest linkse of rechtse waarde zonder te definiëren hoeveel proxies vertrouwd zijn.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Configureer de Backend om Alleen Bekende Proxyadressen te Vertrouwen

Stel de trusted-proxy lijst van de applicatie of webserver in op de exacte reverse-proxy adressen of gecontroleerde subnetten. Bevestig dat directe verbindingen van gewone LAN- of internetclients niet als vertrouwde headerbronnen worden behandeld.

De uitleg van Ip2Geo merkt op dat de applicatieverbinding afkomstig is van de load balancer of reverse proxy en dat het veilig parsen van het originele IP een trusted-hop regel vereist in plaats van het accepteren van willekeurige input.

Als het proxyadres verandert door containers, overlay-netwerken of een CDN, documenteer dan het ondersteunde bereik en werk dit bewust bij. Vertrouw niet zomaar op alle private adressen alleen omdat de proxy er momenteel een gebruikt.

Voer een Spoofed-Header Test Uit

Verstuur vanaf het externe testapparaat een vervalste X-Forwarded-For of Forwarded waarde terwijl je via de echte proxy verbindt. Vergelijk de ruwe binnenkomende header, genormaliseerde proxyheader en het door de backend geselecteerde clientadres.

Het correcte resultaat is dat de vertrouwde edge onbetrouwbare input vervangt of veilig toevoegt en dat de backend het adres selecteert op basis van het gedocumenteerde aantal vertrouwde hops. Een vervalst adres mag niet de waarde worden die wordt gebruikt voor authenticatie of allowlisting.

Herhaal een directe backend-test vanaf een LAN-segment als die poort bereikbaar is. De backend moet doorgestuurde headers van een onbetrouwbare directe client negeren en het daadwerkelijke socket peer-adres registreren.

Valideer IPv4-, IPv6- en Multi-Proxy Paden

Herhaal de test via IPv4 en IPv6, via de normale publieke hostnaam en via elke CDN, tunnel of secundaire proxy die in productie wordt gebruikt. Bevestig dat logs geldige adresformaten behouden en de keten niet afkappen.

De ZimaSpace gids over reverse-proxy request identity biedt de context waarom correcte forwarded waarden belangrijk zijn buiten alleen logging.

De proxy is alleen geverifieerd wanneer de bekende bron overeenkomt met het geparseerde client-IP, vertrouwde proxies zichtbaar blijven in de ruwe keten, spoofpogingen mislukken en beveiligingscontroles consequent de genormaliseerde waarde gebruiken. Controleer opnieuw na het toevoegen van een CDN, tunnel of een andere proxyhop.