Socket-társ vagy továbbított fejléc: melyik címben bízzunk?

Az alkalmazáshoz érkező kérés kétféle címbizonyítékot hordoz: a hálózati kapcsolatot megnyitó társat, és egy HTTP-mezőt, amely egy korábbi ügyfél címét állítja. Különböző kérdésekre válaszolnak. A socket-társ megfigyelt, a fejlécet pedig az állítja, aki írta, és egyiknek sem szabadna csendben helyettesítenie a másikat egy naplóban vagy egy hozzáférési szabályban. Az alábbi összehasonlítás külön tartja őket, majd megmutatja az egyetlen elrendezést, amelyben a fejléc használhatóvá válik.

Írja le az útvonalat, mielőtt bármit összehasonlít:

Client -> approved reverse proxy -> application origin

Ebben az elrendezésben a forrás socket-társa általában a proxy, és egy továbbítási fejléc hordozhatja a proxy ügyfélről szóló állítását. Értéke a proxyhoz fűződő ellenőrzött viszonyból ered, nem a fejléc nevéből.

Kétféle címbizonyíték

A socket-társ egy TCP-kapcsolat ténye: valami kézfogást fejezett be arról a címről. Nem feltétlenül az a személy, eszköz vagy fiók, amely Önnek fontos, mert egy VPN vagy egy Tor-kijárat jogszerűen lehet az a forrás, amelyet egy szolgáltatás megfigyel. Mégis ez az egyetlen cím, amelyet maga a gazdagép ellenőrzött, és ebben rejlik a teljes értéke.

A továbbítási mező egy láncról szóló metaadat. X-Forwarded-For, X-Real-IP és a szabványosított mező Forwarded bármely ügyfél írhatja, amely elér egy olyan végpontot, amely visszhangozza őket, így megbízhatóságuk teljesen attól függ, kinek volt engedélye beállítani őket.

Tartsa mindkettőt a kérés kontextusában külön neveken. Az az alkalmazás, amely felülírja a társat a fejléccel, elveszíti a bizalmi hiba későbbi rekonstruálásának képességét, és pontosan akkor van erre szüksége.

A fejléc soha nem irányítja át a kapcsolatot

A cím beírása egy továbbítási mezőbe nem változtatja meg a kiszolgálóhoz érkező TCP-kapcsolat forrását, és az útvonal egyetlen pontján sem változtatja meg az útválasztást. A szokásos VPN-útválasztás vagy a forrás-NAT HTTP-fejléc nélkül szállítja a forgalmat. Hasonlóképpen, egy tranzitátjáró nem írja át a megfelelően védett HTTPS-cserét anélkül, hogy megváltoztatná a TLS-végpont elrendezését.

A fordított hiba ugyanilyen gyakori: a HTTPS nem teszi igazzá az ügyfél által szolgáltatott továbbítási fejlécet. Ugyanolyan jól védi egy hamis állítás szállítását, mint egy igazét.

Ha egy kolléga fejlécmódosítást javasol egy útválasztási probléma megoldására, a diagnózis már rossz irányba ment. Javítsa az útvonalat, vagy javítsa a fejlécet író proxy konfigurációját.

Nevezze meg az állításra jogosult proxyt

Két szabály tesz egy továbbítási mezőt használhatóvá, és mindkettő konfiguráció, nem kód. A perem normalizálja vagy eldobja mindazt, ami kívülről érkezik, saját dokumentált viselkedése szerint ezekre a mezőkre. Ezután a forrás a megnevezett proxy-útvonalból vesz helyettesítő címet, és máshonnan nem. A második szabály csak addig érvényes, amíg az ügyfelek más módon nem érhetik el a forrást, mert a közvetlen és a proxyn keresztüli kérésekre egyaránt válaszoló forrás nem tudja, melyiket szolgálja ki.

NGINX valódi IP-modulja világosan mutatja a szétválasztást. set_real_ip_from megnevezi azokat a küldőket, akiknek az állítása számít, és real_ip_header megmondja, melyik mező hordozza; az első végzi a bizalmat, a második csak azt mondja, hova nézzen.

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

Egy fejlécválasztó direktíva önmagában még mindig semmit nem állít arról, ki küldte az értéket.

A szállítási biztonságnak végig kell futnia a megbízható összetevők közötti teljes úton. A helyesen normalizáló perem elveszíti ezt az értéket abban a pillanatban, amikor egy védtelen ugrás lejjebb engedi, hogy valaki más szerkessze az állítást, miközben az úton van.

Tudatosan kezelje a többugrásos láncokat

Több proxy kifejezett láncmodellt igényel. Ne a legbal- vagy legjobbszélső, vesszővel elválasztott értéket vegye, csak mert egy blogbejegyzés így tett; derítse ki, melyik proxyja fűz hozzá, melyik helyettesít és melyik őrzi meg a bejövő mezőt. A NGINX például végigmehet a listán hátrafelé a megbízható halmaza ellen, és megállhat az első olyan címnél, amely nem a sajátja, és ez annak a terméknek a szabálya, nem pedig törvény, amelyet minden keretrendszer követ. Olvassa a saját proxyja dokumentációját ugyanazzal a két kérdéssel: melyik értéket választja, és mely küldőkben hisz?

Írja le a láncot: ugrássorrend, melyik ugrás állítja be a mezőt és melyik ugrás távolítja el a bejövő másolatokat. Utána tartsa ezt a feljegyzést a proxy konfigurációja mellett, ne csak a jegyben. Utána tesztelje úgy, hogy egy hamisított fejlécű kérést küld a jóváhagyott ellenőrzési folyamaton keresztül, és megerősíti, hogy a forrás figyelmen kívül hagyja.

Amikor ugrást ad hozzá, nézze át újra azt a dokumentumot. A megbízható proxy elé beszúrt új terheléselosztó megváltoztathatja, melyik cím nyer, anélkül hogy bárki szerkesztené az alkalmazást.

Tartsa mindkét megfigyelést a naplóban

Ahol a diagnosztika engedélyezett, naplózza a kapcsolat társát és a normalizált ügyfélcímet két külön mezőként, és csak azokat a továbbítási metaadatokat adja hozzá, amelyekre a célnak valóban szüksége van. Utána bizonyítsa a telepítést két kéréssel: egy proxyn keresztülivel, amelynek mindkét értéket értelmesen rögzítenie kell, és egy közvetlen, a forrás felé tett kísérlettel, amelyet el kell utasítani.

Emlékezzen, mit jelent a pár. A fejléc olyan kontextust ad hozzá, amelyet egy Ön által megbízni választott összetevő szolgáltat; a társ marad az egyetlen cím, amelyet a gazdagépe valóban látott. Egyik sem bizonyíték egyéni identitásra, és az a tervezés, amely bármelyiket bizonyítékként kezeli, tévedni fog valakivel kapcsolatban.