Socket-Peer oder weidergeleeten Header: wéien Adress trauen?

Eng Ufro, déi bei Ärer Applikatioun ukommt, dréit zwou Aarte vun Adressbeweiser: de Peer, deen d'Netzwierkverbindung opgemaach huet, an en HTTP-Feld, dat d'Adress vun engem fréiere Client behaapt. Si äntwerten op verschidde Froen. De Socket-Peer gëtt observéiert, wärend den Header vun deem behaapt gëtt, deen en geschriwwen huet, an keen dovun sollte deen aneren an engem Log oder enger Zougangsregel stëll ersetzen. De Verglach hei drënner hält si getrennt a weist duerno déi eenzeg Usuerdnung, an där den Header brauchbar gëtt.

Beschreift de Wee, ier Dir eppes vergläicht:

Client -> approved reverse proxy -> application origin

An där Usuerdnung ass de Socket-Peer vum Ursprong normalerweis de Proxy, an en Weiderleeungs-Header kann d'Behaaptung vum Proxy iwwer de Client droen. Säi Wäert kënnt aus der kontrolléierter Bezéiung mat deem Proxy, net aus dem Numm vum Header.

Zwou Aarte vun Adressbeweiser

De Socket-Peer ass eng Tatsaach iwwer eng TCP-Verbindung: eppes huet en Handshake vun där Adress ofgeschloss. Et ass net onbedéngt de Mënsch, den Apparat oder de Kont, deen Iech wichteg ass, well eng VPN oder en Tor-Ausgang legitim déi Quell kënne sinn, déi en Déngscht observéiert. Et ass awer ëmmer nach déi eenzeg Adress, déi den Host selwer verifizéiert huet, an dat ass säi ganzen Wäert.

En Weiderleeungsfeld ass Metadaten iwwer eng Kette. X-Forwarded-For, X-Real-IP an dat standardiséiert Feld Forwarded kann vun all Client geschriwwe ginn, deen en Endpunkt erreecht, deen se widderhëlt, dofir hänkt hir Zouverlässegkeet komplett dovun of, wiem et erlaabt war, se ze setzen.

Halt béid am Ufrokontext ënner ënnerschiddlechen Nimm. Eng Applikatioun, déi de Peer mam Header iwwerschreift, verléiert d'Fäegkeet, méi spéit e Vertrauensfehler ze rekonstruéieren, an dat ass genee de Moment, wou Dir en braucht.

En Header leet d'Verbindung ni ëm

Eng Adress an en Weiderleeungsfeld ze schreiwen ännert net d'Quell vun der TCP-Verbindung, déi um Server ukommt, an et ännert och nirgends um Wee d'Routing. Gewéinlech VPN-Routing oder Quell-NAT liwréiert Traffic ganz ouni HTTP-Header. Genee esou schreift en Transit-Gateway en ordentlech geschützten HTTPS-Austausch net ëm, ouni d'Usuerdnung vum TLS-Endpunkt ze änneren.

De ëmgekéierte Fehler ass grad esou heefeg: HTTPS mécht en Header, dee vum Client komm ass, net wouer. Et schützt den Transport vun enger falscher Behaaptung genee esou gutt wéi vun enger wouerer.

Wann e Kolleg eng Header-Ännerung virschléit, fir e Routingproblem ze léisen, ass d'Diagnos schonn an d'Luucht gaang. Reparéiert de Wee, oder reparéiert d'Proxy-Konfiguratioun, déi den Header schreift.

Nennt de Proxy, deen däerf behaapten

Zwou Reegele maachen en Weiderleeungsfeld brauchbar, an déi zwou sinn Konfiguratioun an net Code. De Rand normaliséiert oder verwäertft alles, wat vun dobausse kënnt, no sengem eegene dokumentéierte Verhalen fir déi Felder. Duerno hëlt den Ursprong eng Ersatzadress aus dem Proxy-Wee, deen Dir genannt hutt, an aus näischt anescht. Déi zweet Regel gëllt just esou laang, wéi d'Cliente den Ursprong net op eng aner Manéier erreeche kënnen, well en Ursprong, deen op direkt wéi och op iwwer Proxy gestallte Ufroe äntwert, net weess, wéien vun deenen zwee en zerwéiert.

NGINX-Modul fir d'richteg IP weist d'Opdeelung kloer. set_real_ip_from nennt d'Absender, deenen hir Behaaptung zielt, an real_ip_header seet, wéi ee Feld se dréit; dat éischt mécht d'Vertrauen, dat zweet seet just, wou ee kucke soll.

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

Eng Direktiv fir d'Header-Auswiel eleng begrënnt nach ëmmer näischt doriwwer, wien de Wäert geschéckt huet.

Transportsecherheet muss de ganze Wee tëscht de Komponente lafen, deenen Dir vertraut. En Rand, deen korrekt normaliséiert, verléiert dee Wäert an deem Ament, wou en ongeschützte Sprong ënnerwee engem aneren erlaabt, d'Behaaptung ze editéieren, während se ënnerwee ass.

Behandelt Ketten mat méi wéi engem Sprong bewosst

Méi Proxye brauchen en ëmplizit Kettemodell. Huelt net de lénksten oder rietsten duerch Komma getrennte Wäert, just well et en Blogbeitrag esou gemaach huet; fannt eraus, wéien Ärer Proxye bäisetzt, wéien ersetzt an wéien dat ankommend Feld erhalet. NGINX zum Beispill kann d'Lëscht no hannen duerch säi vertraute Set goen an déi éischt Adress huelen, déi et net besëtzt, an dat ass d'Regel vun deem Produkt an net e Gesetz, dem all Framework nolauschtert. Liest d'Dokumentatioun vun Ärem eegene Proxy mat deene selwechte Froen: wéie Wäert wielt en, a wéien Absender gleeft en?

Schreift d'Kette op: Spronguerdnung, wéie Sprong d'Feld setzt a wéie Sprong ankommend Kopie läscht. Halt duerno déi Notiz nieft der Proxy-Konfiguratioun, net just am Ticket. Test dann, andeems Dir eng Ufro mat engem gefälschten Header duerch den approuvéierte Validéierungsprozess schéckt a bestätegt, datt den Ursprong se ignoréiert.

Wann Dir e Sprong derbäisetzt, iwwerpréift deen Dokument. En neien Lastverdeeler virum vertraute Proxy kann änneren, wéi eng Adress gewënnt, ouni datt een d'Applikatioun editéiert.

Halt béid Observatiounen am Log

Wou Diagnostik erlaabt ass, loggt de Peer vun der Verbindung an déi normaliséiert Client-Adress als zwee getrennt Felder, a setzt nëmmen déi Weiderleeungs-Metadaten derbäi, déi den Zweck wierklech brauch. Beweist duerno d'Deployment mat zwou Ufroe: eng iwwer de Proxy, déi béid Wäerter vernünfteg registréiere soll, an ee Versuch direkt op den Ursprong, dee muss refuséiert ginn.

Denkt drun, wat de Puer bedeit. Den Header füügt Kontext bäi, deen eng Komponent liwwert, déi Dir gewielt hutt ze vertrauen; de Peer bleift déi eenzeg Adress, déi Ären Host wierklech gesinn huet. Keng vun den zwee ass Beweis fir individuell Identitéit, an en Design, deen eng dovun als Beweis behandelt, wäert sech iwwer een täuschen.