Peer ng socket o forwarded na header: aling address ang pagkakatiwalaan?

Ang kahilingang dumarating sa iyong aplikasyon ay may dalawang uri ng ebidensya ng address: ang peer na nagbukas ng koneksyon sa network, at isang field ng HTTP na nagsasabing address ng naunang kliyente. Iba ang sinasagot ng mga ito. Ang peer ng socket ay napagmamasdan, samantalang ang header ay pinapahayag ng sinumang sumulat nito, at wala sa dalawa ang dapat tahimik na pumalit sa isa sa isang log o patakaran ng pag-access. Pinaghihiwalay sila ng paghahambing sa ibaba, at pagkatapos ay ipinapakita ang nag-iisang kaayusan kung saan nagiging gamitin ang header.

Ilarawan ang landas bago ihambing ang anuman:

Client -> approved reverse proxy -> application origin

Sa kaayusang iyon, ang peer ng socket ng pinagmulan ay karaniwang ang proxy, at ang forwarded na header ay maaaring magdala ng pahayag ng proxy tungkol sa kliyente. Nagmumula ang halaga nito sa kontroladong ugnayan sa proxy na iyon, hindi sa pangalan ng header.

Dalawang uri ng ebidensya ng address

Ang peer ng socket ay isang katotohanan tungkol sa isang koneksyon ng TCP: may isang bagay na nagtapos ng pakikipagkamay mula sa address na iyon. Hindi ito kinakailangang ang tao, aparato o account na mahalaga sa iyo, dahil ang isang VPN o labasan ng Tor ay maaaring maging pinagmulan na namamasdan ng isang serbisyo nang ayon sa batas. Gayunpaman ito pa rin ang nag-iisang address na mismong beripikado ng host, at doon nakasalalay ang buong halaga nito.

Ang field ng forwarding ay metadata tungkol sa isang chain. X-Forwarded-For, X-Real-IP at ang standardized na field Forwarded ay maaaring isulat ng kahit anong kliyente na umaabot sa isang endpoint na nagbabalik sa kanila, kaya ang pagiging mapagkakatiwalaan nila ay lubos na nakadepende sa kung sino ang pinayagang magtakda sa kanila.

Panatilihin ang dalawa sa konteksto ng kahilingan sa ilalim ng magkaibang pangalan. Ang aplikasyong nag-o-overwrite sa peer gamit ang header ay nawawalan ng kakayahang muling buuin ang isang error sa pagtitiwala sa hinaharap, at iyon mismo ang sandaling kailangan mo ito.

Hindi kailanman inililipat ng header ang koneksyon

Ang pagsulat ng address sa isang field ng forwarding ay hindi nagbabago sa pinagmulan ng koneksyon ng TCP na dumarating sa server, at hindi nagbabago sa routing kahit saan sa landas. Ang karaniwang routing ng VPN o source NAT ay naghahatid ng trapiko na walang anumang header ng HTTP. Gayundin, hindi muling isinusulat ng isang transit gateway ang isang maayos na protektadong palitan ng HTTPS nang hindi binabago ang kaayusan ng endpoint ng TLS.

Ang kabaligtarang pagkakamali ay kasingkaraniwan: hindi ginagawang totoo ng HTTPS ang isang forwarded na header na ibinigay ng kliyente. Pinoprotektahan nito ang transportasyon ng isang maling pahayag nang kasinghusay ng isang totoo.

Kung may katrabaho na nagmungkahi ng pagbabago sa header upang ayusin ang isang problema sa routing, mali na ang diyagnosis. Ayusin ang landas, o ayusin ang konfigurasyon ng proxy na sumusulat ng header.

Pangalanan ang proxy na pinapayagang magpahayag

Dalawang patakaran ang nagpapaging-gamitin sa isang field ng forwarding, at pareho itong konfigurasyon at hindi code. Ang gilid ay nag-normalize o nagtatapon ng lahat ng dumarating mula sa labas, ayon sa sarili nitong nakadokumentong pag-uugali para sa mga field na iyon. Pagkatapos ay kumukuha ang pinagmulan ng kapalit na address mula sa landas ng proxy na pinangalanan mo at wala nang iba. Ang ikalawang patakaran ay may bisa lamang habang hindi kayang maabot ng mga kliyente ang pinagmulan sa ibang paraan, dahil ang pinagmulang sumasagot sa parehong direktang kahilingan at kahilingang dumaan sa proxy ay hindi alam kung alin sa dalawa ang pinaglilingkuran nito.

Ang module ng tunay na IP ng NGINX ay malinaw na nagpapakita ng paghahati. set_real_ip_from pinangalanan ang mga nagpadala na ang pahayag ay binibilang, at real_ip_header sinasabi kung aling field ang nagdadala nito; ang una ang gumagawa ng pagtitiwala, ang pangalawa ay nagsasabi lamang kung saan titingin.

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

Ang direktiba ng pagpili ng header lamang ay wala pang itinatatag tungkol sa kung sino ang nagpadala ng halaga.

Ang seguridad ng transportasyon ay dapat tumakbo sa buong landas sa pagitan ng mga bahaging pinagkakatiwalaan mo. Ang gilid na nag-normalize nang tama ay nawawalan ng halagang iyon sa sandaling ang isang hindi protektadong pagtalon sa ibaba ay nagpapahintulot sa ibang tao na i-edit ang pahayag habang naglalakbay ito.

Sadyang pangasiwaan ang mga chain na may maraming pagtalon

Maraming proxy ang nangangailangan ng malinaw na modelo ng chain. Huwag kunin ang pinakakaliwa o pinakakanang halagang hinihiwalay ng kuwit dahil ginawa ito ng isang post sa blog; alamin kung alin sa iyong mga proxy ang nagdadagdag, alin ang pumapalit at alin ang nagpapanatili ng papasok na field. Halimbawa, ang NGINX ay maaaring maglakad sa listahan pabalik laban sa pinagkakatiwalaan nitong set at huminto sa unang address na hindi nito pag-aari, at iyon ay patakaran ng produktong iyon, hindi batas na sinusunod ng bawat framework. Basahin ang dokumentasyon ng sarili mong proxy gamit ang parehong dalawang tanong: aling halaga ang pinipili nito, at aling mga nagpadala ang pinaniniwalaan nito?

Isulat ang chain: pagkakasunod-sunod ng pagtalon, aling pagtalon ang nagtatakda ng field at aling pagtalon ang nag-aalis ng papasok na kopya. Pagkatapos ay itago ang tala na iyon sa tabi ng konfigurasyon ng proxy, hindi lamang sa ticket. Pagkatapos ay subukan ito sa pamamagitan ng pagpapadala ng kahilingang may pekeng header sa pamamagitan ng inaprubahang proseso ng beripikasyon at pagtitiyak na binabalewala ito ng pinagmulan.

Kapag nagdagdag ka ng pagtalon, suriin muli ang dokumentong iyon. Ang isang bagong load balancer na ipinasok sa harap ng pinagkakatiwalaang proxy ay maaaring magbago kung aling address ang mananalo nang walang nag-edit ng aplikasyon.

Panatilihin ang dalawang obserbasyon sa log

Kung saan pinapayagan ang diyagnostika, i-log ang peer ng koneksyon at ang na-normalize na address ng kliyente bilang dalawang magkaibang field, at idagdag lamang ang metadata ng forwarding na talagang kailangan ng layunin. Pagkatapos ay patunayan ang deployment gamit ang dalawang kahilingan: isa sa pamamagitan ng proxy na dapat na makatwirang itala ang parehong halaga, at isang direktang pagtatangkang patungo sa pinagmulan na dapat tanggihan.

Tandaan kung ano ang ibig sabihin ng pares. Ang header ay nagdadagdag ng kontekstong ibinibigay ng isang bahaging pinili mong pagkatiwalaan; ang peer ay nananatiling nag-iisang address na talagang nakita ng iyong host. Wala sa dalawa ang patunay ng indibidwal na pagkakakilanlan, at ang isang disenyong itinuturing ang alinman sa mga ito bilang patunay ay magkakamali tungkol sa isang tao.