SaaS-administrasiearea agter die VPN: watter adres vertrou jy?

Openbare SaaS-bladsye kan vir almal oop bly terwyl die administrasiebewerkings agter hulle enigiemand buite die VPN weier. Die meganisme wat dit laat werk, is nie ’n verborge kieslys of ’n aparte aanmeldbladsy nie; dit is ’n kontrole op die netwerkpad wat die versoek afgelewer het. Kry die adresbewyse verkeerd en die kontrole sluit óf regte administrateurs uit óf laat enigiemand in wat ’n opskrif kan tik. Begin met wat die oorsprong werklik ontvang.

Wat die oorsprong werklik ná die tonnel ontvang

Wanneer ’n blaaier die openbare webwerf bereik deur ’n VPN wat ook internetverkeer dra, vertaal die poort die verbinding voordat dit vertrek. Die SaaS sien die poort se openbare uitgangsadres, tipies een adres of ’n klein reeks, en sien nooit die skootrekenaar se tonneladres nie. Dit is waarom die toelating van 10.90.0.42 misluk, en waarom die toelating van die hele RFC 1918 harder misluk: die tweede laat elke private netwerk toe wat jou kan bereik. Die enigste adres wat die moeite werd is om op te kondisioneer, is die een wat jou organisasie werklik by die uitgang besit.

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

Split-tonnelering breek die aanname stilweg. As die VPN slegs private kantoorroetes dra, verlaat die versoek na die openbare administrasie-gasheernaam die plaaslike ISP en die oorsprong sien ’n residensiële adres. ’n Gekoppelde VPN-ikoon bewys niks oor hierdie spesifieke bestemming nie, so toets die bestemming eerder as die tonnel.

Stop en regmaak die roetering voordat jy enige beleid skryf as die uitgangsadres per gebruiker verskil. ’n Voorwaarde wat slegs sommige administrateurs pas, is slegter as geen voorwaarde nie, want dit verberg die probleem tot ’n insident.

Vertrou slegs die proxy wat die adres herskryf

Die meeste openbare webwerwe sit agter ’n CDN of omgekeerde proxy, so die oorsprong se sokadres behoort aan daardie frontend en nie aan die besoeker nie. Die frontend stuur gewoonlik die oorspronklike adres in ’n opskrif aan, en daardie opskrif word deur ’n aanvaller beheer tensy die oorsprong dit slegs van bekende proxys aanvaar. Stel die vertroude bronnelys eksplisiet op en maak die oorsprong onbereikbaar van enige ander plek. Sonder daardie tweede helfte slaan ’n aanvaller die proxy oor en stuur die opskrif direk.

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

Dieselfde redenasie geld vir die PROXY-protokol: dit is slegs betroubaar wanneer die luisteraar aan ’n koppelvlak gebind is wat die proxy kan bereik en niks anders nie. Ontbrekende adreskonteks moet die beskermde kontrole laat misluk eerder as om na ’n verstektoelating deur te val. ’n Opskrif wat afwesig is, is nie bewyse van ’n vertroude pad nie.

Heg die voorwaarde aan elke beskermde bewerking

Plaas die kontrole in die magtigingsgrens waardeur elke beskermde bewerking gaan, nie in die bladsy wat die kieslys weergee nie. Roetegroepe, middleware of ’n beleidslaag werk almal; ’n kopie per hanteerder nie, want die hanteerder wat iemand volgende kwartaal byvoeg, sal dit nie hê nie.

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

Dieselfde grens moet die JSON API, uitvoere, getekende aflaai-URL's en die WebSocket-handdruk dek, aangesien nie een van hulle vereis dat die HTML-bladsy eerste aangevra word nie. ’n Aflaaiskakel wat geskep is terwyl die VPN op was, bly daarna geldig tensy die aflaai-eindpunt weer kontroleer. Langdurige sessies het ook ’n herwaarderingsreël nodig, anders word een gemagtigde versoek ’n permanente vrystelling. Verstekweiering is die enigste instelling wat personeelomset oorleef.

Gedeelde kassies is die ander manier om die kontrole. ’n Kas wat reeds ’n beskermde respons hou, kan dit bedien sonder om die oorsprong te kontak, so merk administrasieresponse as privaat en hou hulle uit gedeelde berging. As ’n kas hulle moet bedien, moet die toegangskontrole voor die bediening loop, wat gewoonlik beteken dit kan glad nie ’n gedeelde kas wees nie.

Toets die omleidings wat jy pas gesluit het

Oefen die matriks eerder as die gelukkige pad: ’n administrateur deur die VPN, dieselfde administrateur daarsonder, ’n nie-administrateur daardeur, en ’n vervalste adresopskrif. Voeg ’n direkte-na-oorsprong-versoek en ’n gekassieerde-respons-versoek by, want dit is die twee wat die frontend heeltemal oorslaan.

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'

Elke versoek moet die status terugstuur wat die beleid belowe, en die log moet aanteken watter adresbewyse gebruik is. Dek IPv6 afsonderlik, want ’n dubbele-stapel-oorsprong kan ’n ander bronfamilie sien as die een wat jy getoets het. Hou gewone klantebewerkings buite die VPN werkend, of die verandering sal teruggedraai word die eerste keer dat ’n klant kla. Skryf die verwagte resultaat vir elke ry voordat jy dit hardloop, sodat ’n verrassende slaag sigbaar is.

Die uitgangsadres bewys ’n toegelate netwerkpad, nie ’n persoon nie en nie ’n bestuurde toestel nie. Hou dit as een voorwaarde naas verifikasie en toestemming, en die administrasiearea bly smal sonder om die hele produk in ’n slegs-VPN-diens te verander. Daardie skeiding is die ontwerp, nie ’n beperking daarvan nie.