Wie man überprüft, ob ein Reverse-Proxy die korrekte Client-IP sendet

Überprüfen Sie die Weiterleitung der Client-IP, indem Sie eine bekannte externe Quelle mit jedem Proxy-Header und der endgültig vom Backend analysierten Adresse vergleichen.

Ein Reverse-Proxy beendet die Client-Verbindung, sodass das Backend normalerweise die Socket-Adresse des Proxys sieht, es sei denn, der Proxy übermittelt vertrauenswürdige Anfragemetadaten. Der Test muss die direkte Peer-Adresse von Forwarded, X-Forwarded-For und X-Real-IP unterscheiden, jeden vertrauenswürdigen Hop dokumentieren und nachweisen, dass ein Internet-Client den für Protokolle, Ratenbegrenzungen oder Zugriffskontrollen verwendeten Wert nicht fälschen kann.

Erstellen Sie einen bekannten Client-IP-Test von außerhalb des Hauses

Verwenden Sie ein Gerät mit mobiler Datenverbindung oder einem anderen externen Netzwerk und notieren Sie dessen öffentliche IPv4- oder IPv6-Adresse unmittelbar vor der Anfrage. Senden Sie einen eindeutigen Pfad, Abfragewert oder Zeitstempel über den öffentlichen Reverse-Proxy.

MDN beschreibt X-Forwarded-For als einen de-facto-Header zur Bewahrung der ursprünglichen Client-Adresse über Proxy-Verbindungen hinweg.

Sammeln Sie das Edge-Proxy-Log, alle Zwischenproxy-Logs und das Backend-Anwendungslog für diese einzelne Anfrage. Ohne bekannte Quelle und korrelierten Zeitstempel kann die Header-Kette bei mehreren gleichzeitigen Nutzern mehrdeutig sein.

Protokollieren Sie den Socket-Peer und jeden weitergeleiteten Header

Protokollieren Sie im Backend die direkte TCP-Peer-Adresse getrennt von Forwarded, X-Forwarded-For, X-Real-IP und jedem CDN-spezifischen Client-Header. Überschreiben Sie die Rohwerte während des ersten Tests nicht.

Eine praktische Analyse der Handhabung der „echten“ Client-IP warnt, dass die Genauigkeit davon abhängt, wie der Proxy Header setzt oder anhängt und ob frühere Werte gefälscht werden können. Das gesamte Proxy-Vertrauensmodell muss der tatsächlichen Netzwerkarchitektur entsprechen.

Der Backend-Socket-Peer sollte dem unmittelbar vertrauenswürdigen Proxy entsprechen, während die ausgewählte Client-Adresse dem externen Testgerät entsprechen sollte. Wenn das Backend nur die Proxy-Adresse protokolliert, fehlt die Header-Erstellung oder -Analyse.

Überprüfen Sie, wie jeder Proxy den Header hinzufügt oder ersetzt

Untersuchen Sie jeden Hop vom CDN oder Tunnel bis zum Edge-Proxy, internen Proxy und zur Anwendung. Protokollieren Sie, ob jeder Hop an eine bestehende Liste anhängt, nicht vertrauenswürdige Eingaben ersetzt oder den Header unverändert weitergibt.

Sling Academy erklärt, dass NGINX X-Real-IP aus der unmittelbaren Verbindung setzen und mit proxy_add_x_forwarded_for eine Kette anhängen kann.

Konfigurieren Sie den ersten vertrauenswürdigen Edge so, dass clientseitig gelieferte Weiterleitungsheader entfernt oder ersetzt werden, und hängen Sie Adressen bei kontrollierten internen Hops an. Vermeiden Sie es, blind den links- oder rechtsseitigsten Wert zu akzeptieren, ohne zu definieren, wie viele Proxies vertrauenswürdig sind.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Konfigurieren Sie das Backend so, dass nur bekannte Proxy-Adressen vertraut wird

Setzen Sie die Liste der vertrauenswürdigen Proxies der Anwendung oder des Webservers auf die genauen Reverse-Proxy-Adressen oder kontrollierten Subnetze. Stellen Sie sicher, dass direkte Verbindungen von gewöhnlichen LAN- oder Internet-Clients nicht als vertrauenswürdige Header-Quellen behandelt werden.

Die Erklärung von Ip2Geo weist darauf hin, dass die Anwendungsverbindung vom Load Balancer oder Reverse Proxy ausgeht und dass das sichere Parsen der ursprünglichen IP eine Vertrauens-Hop-Regel erfordert, anstatt beliebige Eingaben zu akzeptieren.

Wenn sich die Proxy-Adresse aufgrund von Containern, Overlay-Netzwerken oder einem CDN ändert, dokumentieren Sie den unterstützten Bereich und aktualisieren Sie ihn gezielt. Vertrauen Sie nicht allen privaten Adressen nur, weil der Proxy derzeit eine verwendet.

Führen Sie einen Test mit gefälschtem Header durch

Senden Sie vom externen Testgerät einen gefälschten X-Forwarded-For- oder Forwarded-Wert, während Sie sich über den echten Proxy verbinden. Vergleichen Sie den rohen eingehenden Header, den normalisierten Proxy-Header und die vom Backend ausgewählte Client-Adresse.

Das korrekte Ergebnis ist, dass der vertrauenswürdige Edge unzuverlässige Eingaben ersetzt oder sicher anhängt und das Backend die Adresse basierend auf der dokumentierten Anzahl vertrauenswürdiger Hops auswählt. Eine gefälschte Adresse darf nicht der für Authentifizierung oder Allowlisting verwendete Wert werden.

Wiederholen Sie einen Direkt-zum-Backend-Test von einem LAN-Segment, falls dieser Port erreichbar ist. Das Backend sollte weitergeleitete Header von einem nicht vertrauenswürdigen direkten Client ignorieren und den tatsächlichen Socket-Peer protokollieren.

Validieren Sie IPv4-, IPv6- und Multi-Proxy-Pfade

Wiederholen Sie den Test über IPv4 und IPv6, über den normalen öffentlichen Hostnamen und über jedes in der Produktion verwendete CDN, Tunnel oder sekundäre Proxy. Bestätigen Sie, dass Protokolle gültige Adressformate bewahren und die Kette nicht abschneiden.

Der ZimaSpace-Leitfaden zu Reverse-Proxy-Anfrage-Identität liefert den Kontext, warum korrekte weitergeleitete Werte über das Protokollieren hinaus wichtig sind.

Der Proxy ist nur dann verifiziert, wenn die bekannte Quelle mit der analysierten Client-IP übereinstimmt, vertrauenswürdige Proxies in der Rohkette sichtbar bleiben, Fälschungsversuche fehlschlagen und Sicherheitskontrollen den normalisierten Wert konsequent verwenden. Überprüfen Sie erneut nach Hinzufügen eines CDN, Tunnels oder eines weiteren Proxy-Hops.