Сокетски партнер или проследено заглавие: на која адреса да верувате?

Барањето што пристигнува во вашата апликација носи два вида докази за адресата: партнерот што ја отворил мрежната врска и 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 може да ја помине листата наназад против своето доверливо множество и да застане на првата адреса што не ја поседува, и тоа е правило на тој производ, а не закон што го следи секоја рамка. Читајте ја документацијата на сопственото прокси со истите две прашања: која вредност ја избира и на кои испраќачи им верува?

Запишете го ланецот: редослед на скоковите, кој скок го поставува полето и кој скок ги отстранува дојдовните копии. Потоа држете ја таа белешка до конфигурацијата на проксито, не само во тикетот. Потоа тестирајте го испраќајќи барање со фалсификувано заглавие низ одобрениот процес за валидација и потврдувајќи дека изворот го игнорира.

Кога додавате скок, прегледајте го тој документ. Нов балансер на оптоварување вметнат пред доверливото прокси може да смени која адреса победува без никој да ја уредува апликацијата.

Држете ги двете набљудувања во дневникот

Каде што дијагностиката е дозволена, забележете го партнерот на врската и нормализираната адреса на клиентот како две одделни полиња, и додајте ги само метаподатоците за проследување што на целта навистина ѝ требаат. Потоа докажете го распоредувањето со две барања: едно преку прокси што треба разумно да ги запише двете вредности, и еден обид директно до изворот што мора да биде одбиен.

Запомнете што значи парот. Заглавието додава контекст што го дава компонента што сте избрале да ѝ верувате; партнерот останува единствената адреса што вашиот домаќин навистина ја видел. Ниту едно не е доказ за индивидуален идентитет, и дизајн што било кое од нив го третира како доказ ќе погреши за некого.