Административна зона SaaS иза VPN-а: којој адреси веровати?

Извор види излазну адресу вашег VPN гејтвеја, а не тунелску адресу лаптопа. Верујте само конфигурисаном заглављу проксија, а затим затворите сваку административну операцију.

Јавне SaaS странице могу остати отворене за све, док административне операције иза њих одбијају свакога ван VPN-а. Механизам који то омогућава није скривени мени ни посебна страница за пријаву; то је провера мрежног пута који је доставио захтев. Погрешите ли доказ о адреси, провера или закључава праве администраторе или прима свакога ко уме да откуца заглавље. Почните од онога што извор заиста прима.

Шта извор заиста прима после тунела

Када прегледач стигне до јавног сајта преко VPN-а који преноси и интернет саобраћај, гејтвеј преводи везу пре него што она изађе. SaaS види јавну излазну адресу гејтвеја, обично једну адресу или мали опсег, и никада не види тунелску адресу лаптопа. Зато стављање 10.90.0.42 на листу дозвољених не успева, и зато стављање целог RFC 1918 не успева још гласније: друго прима сваку приватну мрежу која може да вас достигне. Једина адреса вредна услова је она коју ваша организација заиста поседује на излазу.

curl -s https://ifconfig.me
dig +short admin.example.com

Подељено тунелирање тихо крши ту претпоставку. Ако VPN преноси само приватне канцеларијске руте, захтев ка јавном административном имену домаћина излази преко локалног провајдера и извор види стамбену адресу. Повезана VPN икона не доказује ништа о овој конкретној дестинацији, зато тестирајте дестинацију, а не тунел.

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

Верујте само проксију који преписује адресу

Већина јавних сајтова стоји иза CDN-а или обрнутог проксија, тако да адреса сокета извора припада том предњем слоју, а не посетиоцу. Предњи слој обично прослеђује оригиналну адресу у заглављу, и то заглавље контролише нападач осим ако извор прихвата само од познатих проксија. Конфигуришите листу поузданих извора експлицитно и учините извор недоступним са било ког другог места. Без те друге половине нападач прескаче прокси и шаље заглавље директно.

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

Исто размишљање важи и за PROXY протокол: поуздан је само када је слушалац везан за интерфејс до којег прокси може да стигне и ништа друго не може. Недостајући контекст адресе мора да обори заштићену проверу уместо да падне у подразумевано дозвољавање. Заглавље које недостаје није доказ поузданог пута.

Причврстите услов на сваку заштићену операцију

Ставите проверу на границу ауторизације кроз коју пролази свака заштићена операција, а не на страницу која приказује мени. Групе рута, middleware или слој политике сви раде; копија по руковаоцу не, јер руковалац који неко дода следећег квартала неће је имати.

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

Иста граница мора да покрије JSON API, извозе, потписане URL-ове за преузимање и WebSocket руковање, јер ниједном од њих не треба претходни захтев за HTML страницом. Веза за преузимање створена док је VPN био активан остаје важећа и после, осим ако крајња тачка за преузимање поново не провери. Дуготрајне сесије такође захтевају правило поновне процене, иначе један аутентификовани захтев постаје трајни изузетак. Подразумевано одбијање једина је поставка која преживи смену особља.

Дељени кешеви су други пут око провере. Кеш који већ држи заштићени одговор може да га послужи без контактирања извора, зато означите административне одговоре као приватне и држите их изван дељеног складишта. Ако кеш мора да их послужи, провера приступа мора да се изврши пре послуживања, што обично значи да уопште не може бити дељени кеш.

Тестирајте заобилажења која сте управо затворили

Вежбајте матрицу, а не срећан пут: администратор кроз VPN, исти администратор без њега, неадминистратор кроз њега и фалсификовано заглавље адресе. Додајте захтев директно ка извору и захтев са кешираним одговором, јер та два потпуно прескачу предњи слој.

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

Сваки захтев треба да врати статус који политика обећава, а дневник треба да забележи који је доказ о адреси коришћен. Покријте IPv6 одвојено, јер извор са двоструким стеком може да види другу породицу извора од оне коју сте тестирали. Одржавајте уобичајене клијентске операције активним изван VPN-а, иначе ће промена бити враћена при првој жалби клијента. Запишите очекивани резултат за сваки ред пре покретања, да изненађујући пролаз буде видљив.

Излазна адреса доказује дозвољен мрежни пут, а не особу и не управљани уређај. Држите је као један услов поред аутентификације и дозволе, и административна зона остаје уска без претварања целог производа у услугу само за VPN. То раздвајање је дизајн, а не његово ограничење.

Повезани чланци