Сусед па сокеце супраць загалоўка перанакіравання: якому адрасу давяраць?

Запыт, які прыходзіць у вашу праграму, нясе два віды доказаў адрасу: суседа, які адкрыў сеткавае злучэнне, і HTTP-поле, якое сцвярджае адрас ранейшага кліента. Яны адказваюць на розныя пытанні. Сусед па сокеце назіраецца, а загаловак сцвярджае той, хто яго напісаў, і ні адзін не павінен маўкліва замяняць іншы ў журнале або ў правіле доступу. Параўнанне ніжэй трымае іх асобна, а затым паказвае адзіную схему, у якой загаловак становіцца прыдатным да ўжывання.

Апішыце шлях, перш чым нешта параўноўваць:

Client -> approved reverse proxy -> application origin

У такой схеме сусед па сокеце на баку крыніцы звычайна з’яўляецца проксі, і загаловак перанакіравання можа перадаваць сцвярджэнне проксі пра кліента. Яго каштоўнасць паходзіць з кантраляваных адносін з гэтым проксі, а не з назвы загалоўка.

Два віды доказаў адрасу

Сусед па сокеце — гэта факт пра адно TCP-злучэнне: нешта завяршыла рукапацісканне з таго адрасу. Гэта не абавязкова чалавек, прылада або ўліковы запіс, якія вас цікавяць, бо VPN або выхадны вузел Tor могуць цалкам законна быць крыніцай, якую назірае сэрвіс. Але гэта па-ранейшаму адзіны адрас, які пацвердзіў сам хост, і ў гэтым уся яго каштоўнасць.

Поле перанакіравання — гэта метаданыя пра ланцуг. X-Forwarded-For, X-Real-IP і стандартызаванае поле Forwarded можа запісаць любы кліент, які дасягае канчатковай кропкі, што іх адлюстроўвае, таму іх надзейнасць цалкам залежыць ад таго, каму дазволена іх усталёўваць.

Трымайце абодва ў кантэксце запыту пад рознымі імёнамі. Праграма, якая перазапісвае суседа загалоўкам, губляе здольнасць пазней аднавіць памылку даверу, а гэта менавіта той момант, калі яна вам патрэбна.

Загаловак ніколі не перанакіроўвае злучэнне

Запіс адрасу ў поле перанакіравання не змяняе крыніцу TCP-злучэння, якое прыходзіць на сервер, і не змяняе маршрутызацыю нідзе на шляху. Звычайная маршрутызацыя VPN або зыходны NAT перадае трафік наогул без якога-небудзь HTTP-загалоўка. Гэтак жа транзітны шлюз не перапісвае належным чынам абаронены абмен HTTPS, не змяніўшы схему канчатковай кропкі TLS.

Адваротная памылка сустракаецца гэтак жа часта: HTTPS не робіць праўдзівым загаловак перанакіравання, які прадставіў кліент. Ён абараняе перадачу ілжывага сцвярджэння гэтак жа добра, як і праўдзівага.

Калі калега прапануе змяніць загаловак, каб выправіць праблему маршрутызацыі, дыягназ ужо пайшоў не туды. Выпраўце шлях або выпраўце канфігурацыю проксі, які запісвае загаловак.

Назавіце проксі, якому дазволена сцвярджаць

Два правілы робяць поле перанакіравання прыдатным, і абодва — гэта канфігурацыя, а не код. Ускраек нармалізуе або адкідвае ўсё, што прыходзіць звонку, у адпаведнасці з уласнымі дакументаванымі паводзінамі для гэтых палёў. Затым крыніца бярэ заменны адрас з шляху проксі, які вы назавалі, і ні адкуль больш. Другое правіла дзейнічае толькі тады, калі кліенты не могуць дасягнуць крыніцы іншым шляхам, бо крыніца, якая адказвае і на прамыя, і на праксіраваныя запыты, не ведае, якому з іх служыць.

Модуль NGINX для рэальнага IP ясна паказвае гэтае размежаванне. set_real_ip_from называе адпраўнікоў, чыё сцвярджэнне мае значэнне, і real_ip_header паказвае, якое поле яго нясе; першы выконвае давер, другі толькі кажа, дзе глядзець.

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

Адна дырэктыва выбару загалоўка сама па сабе ўсё яшчэ нічога не ўсталёўвае наконт таго, хто паслаў значэнне.

Бяспека транспарту павінна дзейнічаць на ўсім шляху паміж кампанентамі, якім вы давяраеце. Ускраек, які правільна нармалізуе, губляе гэтую каштоўнасць у той момант, калі незабаронены прамежак ніжэй дазваляе камусьці іншаму змяніць сцвярджэнне ў дарозе.

Апрацоўвайце шматузроўневыя ланцугі свядома

Некалькі проксі патрабуюць яснай мадэлі ланцуга. Не бярыце самае левае або самае правае значэнне, падзеленае коскамі, толькі таму, што так зрабіў нейкі блог; высветліце, які з вашых проксі дадае, які замяняе, а які захоўвае ўваходнае поле. Напрыклад, NGINX можа ісці па спісе назад супраць свайго набору давераных і спыніцца на першым адрасе, якім ён не валодае, і гэта правіла гэтага прадукту, а не закон, якому падпарадкоўваецца кожны фрэймворк. Чытайце дакументацыю вашага проксі з тымі ж двума пытаннямі: якое значэнне ён выбірае і якім адпраўнікам ён верыць?

Запішыце ланцуг: парадак скокаў, які скок устанаўлівае поле і які скок выдаляе ўваходныя копіі. Затым трымайце гэтую нататку побач з канфігурацыяй проксі, а не толькі ў тыкеце. Затым праверце яе, адправіўшы запыт з падробленым загалоўкам праз зацверджаны працэс праверкі і пацвердзіўшы, што крыніца яго ігнаруе.

Калі вы дадаяце скок, перагледзьце гэты дакумент. Новы балансіроўшчык нагрузкі, усталяваны перад давераным проксі, можа змяніць, які адрас пераможа, без удзелу кагосьці ў рэдагаванні праграмы.

Трымайце абодва назіранні ў журнале

Там, дзе дыягностыка дазволена, запісвайце суседа злучэння і нармалізаваны адрас кліента як два асобныя палі і дадавайце толькі тыя метаданыя перанакіравання, якія сапраўды патрэбныя мэце. Затым дакажыце разгортванне двума запытамі: адзін праз проксі, які павінен разумна запісаць абодва значэнні, і адну спробу наўпрост да крыніцы, якая павінна быць адхіленая.

Помніце, што азначае гэтая пара. Загаловак дадае кантэкст, які падае кампанент, абраны вамі для даверу; сусед застаецца адзіным адрасам, які ваш хост сапраўды бачыў. Ні адзін з іх не з’яўляецца доказам індывідуальнай асобы, і праект, які лічыць любы з іх доказам, памыліцца адносна кагосьці.