Hur man verifierar att en omvänd proxy skickar rätt klient-IP

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

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

Verifiera klient-IP-vidarebefordran genom att jämföra en känd extern källa med varje proxyheader och backendens slutgiltigt tolkade adress.

En reverse proxy avslutar klientanslutningen, så backend ser normalt proxyns socketadress om inte proxyn vidarebefordrar betrodd metadata om förfrågan. Testet måste skilja den direkta peer-adressen från Forwarded, X-Forwarded-For och X-Real-IP, dokumentera varje betrodd hopp och bevisa att en internetklient inte kan förfalska värdet som används för loggar, hastighetsbegränsningar eller åtkomstkontroll.

Skapa ett test för känd klient-IP utanför hemmet

Använd en enhet på mobildata eller ett annat externt nätverk och registrera dess offentliga IPv4- eller IPv6-adress omedelbart före förfrågan. Skicka en unik sökväg, frågevärde eller tidsstämpel genom den offentliga reverse proxyn.

MDN beskriver X-Forwarded-For som en de facto-header för att bevara ursprunglig klientadress över proxyanslutningar.

Samla in loggen från edge-proxyn, eventuella mellanliggande proxyloggar och backendapplikationens logg för just den förfrågan. Utan en känd källa och korrelerad tidsstämpel kan flera samtidiga användare göra headerkedjan oklar.

Registrera socket-peer och varje vidarebefordrad header

På backend, logga den direkta TCP-peeradressen separat från Forwarded, X-Forwarded-For, X-Real-IP och eventuella CDN-specifika klientheaders. Skriv inte över de råa värdena under det första testet.

En praktisk analys av hantering av ”riktig” klient-IP varnar för att noggrannheten beror på hur proxyn sätter eller lägger till headers och om tidigare värden kan förfalskas. Hela proxy-tillitsmodellen måste stämma överens med den faktiska nätverksarkitekturen.

Backendens socket-peer bör vara lika med den omedelbara betrodda proxyn, medan den valda klientadressen bör vara lika med den externa test-enheten. Om backend endast loggar proxyadressen saknas header-skapande eller tolkning.

Verifiera hur varje proxy lägger till eller ersätter headern

Inspektera varje hopp från CDN eller tunnel till edge-proxy, intern proxy och applikation. Registrera om varje hopp lägger till en befintlig lista, ersätter obetrodda indata eller vidarebefordrar headern oförändrad.

Sling Academy förklarar att NGINX kan sätta X-Real-IP från den omedelbara anslutningen och lägga till en kedja med proxy_add_x_forwarded_for.

Konfigurera den första betrodda edge-proxyn att ta bort eller ersätta klientlevererade vidarebefordringsheaders, och lägg sedan till adresser vid kontrollerade interna hopp. Undvik att blint acceptera det vänster- eller högerställda värdet utan att definiera hur många proxys som är betrodda.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Konfigurera backend att endast lita på kända proxyadresser

Sätt applikationens eller webbserverns lista över betrodda proxys till de exakta reverse-proxy-adresserna eller kontrollerade subnäten. Bekräfta att direkta anslutningar från vanliga LAN- eller internetklienter inte behandlas som betrodda headerkällor.

Ip2Geos förklaring noterar att applikationsanslutningen kommer från lastbalanseraren eller reverse proxyn och att tolkning av den ursprungliga IP:n säkert kräver en betrodd-hopp-regel istället för att acceptera godtycklig indata.

Om proxyadressen ändras på grund av containrar, overlay-nätverk eller en CDN, dokumentera det stödda intervallet och uppdatera det medvetet. Lita inte på alla privata adresser bara för att proxyn för närvarande använder en sådan.

Kör ett test med förfalskad header

Från den externa test-enheten, skicka ett förfalskat X-Forwarded-For eller Forwarded-värde medan du ansluter via den riktiga proxyn. Jämför den råa inkommande headern, den normaliserade proxyheadern och backendens valda klientadress.

Det korrekta resultatet är att den betrodda edge-proxyn ersätter eller säkert lägger till obetrodda indata och att backend väljer adressen baserat på den dokumenterade betrodda hopp-räkningen. En förfalskad adress får inte bli det värde som används för autentisering eller vitlistning.

Upprepa ett direkt-till-backend-test från ett LAN-segment om den porten är nåbar. Backend bör ignorera vidarebefordrade headers från en obetrodd direktklient och registrera den faktiska socket-peern.

Verifiera IPv4, IPv6 och multi-proxy-vägar

Upprepa testet via IPv4 och IPv6, via det normala offentliga värdnamnet och via eventuella CDN, tunnlar eller sekundära proxys som används i produktion. Bekräfta att loggar bevarar giltiga adressformat och inte trunkerar kedjan.

ZimaSpace-guiden för reverse-proxy-förfrågningsidentitet ger den omgivande kontexten för varför korrekta vidarebefordrade värden är viktiga bortom loggning.

Proxyn verifieras endast när den kända källan matchar den tolkade klient-IP:n, betrodda proxys förblir synliga i den råa kedjan, förfalskningsförsök misslyckas och säkerhetskontroller konsekvent använder det normaliserade värdet. Kontrollera igen efter att ha lagt till en CDN, tunnel eller ytterligare proxyhopp.