SaaS-administrasjonsområde bak VPN-en: kva adresse kan du stole på?

Offentlege SaaS-sider kan halda fram med å vera opne for alle medan dei administrative operasjonane bak dei avviser alle utanfor VPN-en. Mekanismen som gjer det mogleg, er ikkje ei skjult meny eller ei eiga innloggingsside; det er ein kontroll av nettverksvegen som leverte førespurnaden. Tek du adresseprovet feil, låser kontrollen anten ute ekte administratorar eller slepp inn alle som kan skriva ein header. Start med det opphavet faktisk mottek.

Kva opphavet faktisk mottek etter tunnelen

Når ein nettlesar når den offentlege sida gjennom ein VPN som òg ber internettrafikk, omset gatewayen sambandet før det går ut. SaaS-en ser den offentlege utgåande adressa til gatewayen, vanlegvis éi adresse eller eit lite område, og ser aldri tunneladressa til laptopen. Difor mislukkast det å leggja 10.90.0.42 i tillatingslista, og difor mislukkast det å leggja heile RFC 1918 inn endå høgare: det andre slepp inn kvart private nettverk som kan nå deg. Den einaste adressa som er verd ein føresetnad, er den organisasjonen din faktisk eig ved utgangen.

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

Delt tunnellering bryt denne føresetnaden stille. Viss VPN-en berre ber private kontorruter, går førespurnaden til det offentlege admin-vertsnamnet ut gjennom den lokale leverandøren, og opphavet ser ei bustadadresse. Eit tilkopla VPN-ikon beviser ingenting om denne konkrete destinasjonen, så test destinasjonen og ikkje tunnelen.

Stopp og rett opp rutingsarbeidet før du skriv nokon policy viss den utgåande adressa varierer per brukar. Eit vilkår som berre passar nokre administratorar, er verre enn ingen vilkår, fordi det skjuler problemet til ei hending.

Stol berre på proxyen som skriv om adressa

Dei fleste offentlege nettstadene ligg bak ein CDN eller ein omvend proxy, så socket-adressa til opphavet høyrer til den frontenden og ikkje til den besøkjande. Frontenden sender vanlegvis den opphavlege adressa vidare i ein header, og den headeren vert styrt av ein åtakar med mindre opphavet berre godtek han frå kjende proxyar. Konfigurer lista over klarerte kjelder eksplisitt og gjer opphavet utilgjengeleg frå alle andre stader. Utan den andre halvdelen hoppar ein åtakar over proxyen og sender headeren direkte.

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

Same resonnementet gjeld for PROXY-protokollen: han er berre påliteleg når lyttaren er bunden til eit grensesnitt som proxyen kan nå og ingen andre kan. Manglande adressekontekst må få den verna kontrollen til å mislukkast i staden for å falla tilbake til ei standardtillating. Ein header som manglar, er ikkje prov på ein klarert veg.

Fest vilkåret til kvar verna operasjon

Set kontrollen ved autorisasjonsgrensa som kvar verna operasjon passerer, ikkje i sida som teiknar menyen. Rutegrupper, middleware eller eit policy-lag fungerer alle; ein kopi per handterar gjer det ikkje, fordi handteraren nokon legg til neste kvartal ikkje vil ha han.

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

Den same grensa må dekkja JSON-API-et, eksportar, signerte nedlastings-URL-ar og WebSocket-handtrykket, sidan ingen av dei krev at HTML-sida vert førespurd først. Ei nedlastingslenkje som er laga medan VPN-en var oppe, held fram med å vera gyldig etterpå med mindre nedlastingsendepunktet sjekkar på nytt. Langvarige økter treng òg ein revurderingsregel, elles vert éin autentisert førespurnad eit permanent unntak. Standardavvising er den einaste innstillinga som overlever utskifting av tilsette.

Delte hurtigbufferar er den andre vegen rundt kontrollen. Ein hurtigbuffer som allereie held eit verna svar, kan levera det utan å kontakta opphavet, så merk admin-svar som private og hald dei utanfor delt lagring. Viss ein hurtigbuffer må levera dei, må tilgangskontrollen køyra før leveringa, noko som vanlegvis tyder at han ikkje kan vera ein delt hurtigbuffer i det heile.

Test omvegane du nettopp lukka

Gå gjennom matrisa i staden for den lukkelege vegen: ein administrator gjennom VPN-en, den same administratoren utan han, ein ikkje-administrator gjennom han, og ein forfalska adresse-header. Legg til ein førespurnad direkte til opphavet og ein førespurnad med buffra svar, fordi det er dei to som hoppar heilt over frontenden.

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'

Kvar førespurnad bør returnera statusen policyen lovar, og loggen bør registrera kva adresseprov som vart brukt. Dekk IPv6 separat, fordi eit dual-stack-opphav kan sjå ein annan kjeldefamilie enn den du testa. Hald vanlege kundeoperasjonar i gang utanfor VPN-en, elles vert endringa rulla tilbake fyrste gong ein kunde klagar. Skriv det forventa resultatet for kvar rad før du køyrer ho, slik at ein overraskande bestått er synleg.

Den utgåande adressa beviser ein tillaten nettverksveg, ikkje ein person og ikkje eining som vert styrt. Hald ho som eitt vilkår ved sida av autentisering og løyve, og admin-området held fram med å vera smalt utan å gjera heile produktet til ein VPN-only-teneste. Den separasjonen er designet, ikkje ei avgrensing ved det.