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

Offentlige SaaS-sider kan forbli åpne for alle mens de administrative operasjonene bak dem avviser alle utenfor VPN-en. Mekanismen som gjør det mulig, er ikke en skjult meny eller en egen innloggingsside; det er en kontroll av nettverksbanen som leverte forespørselen. Tar du adressebeviset feil, låser kontrollen enten ute ekte administratorer eller slipper inn alle som kan skrive en header. Start med det opprinnelsen faktisk mottar.

Hva opprinnelsen faktisk mottar etter tunnelen

Når en nettleser når det offentlige nettstedet gjennom en VPN som også bærer internettrafikk, oversetter gatewayen forbindelsen før den går ut. SaaS-en ser gatewayens offentlige utgående adresse, vanligvis én adresse eller et lite område, og ser aldri tunneladressen til laptopen. Derfor mislykkes det å legge 10.90.0.42 i tillatelseslisten, og derfor mislykkes det å legge hele RFC 1918 inn enda høyere: det andre slipper inn hvert private nettverk som kan nå deg. Den eneste adressen som er verdt en betingelse, er den organisasjonen din faktisk eier ved utgangen.

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

Delt tunnellering bryter denne antakelsen stille. Hvis VPN-en bare bærer private kontorruter, går forespørselen til det offentlige admin-vertsnavnet ut gjennom den lokale leverandøren, og opprinnelsen ser en boligadresse. Et tilkoblet VPN-ikon beviser ingenting om denne konkrete destinasjonen, så test destinasjonen og ikke tunnelen.

Stopp og rett opp rutingen før du skriver noen policy hvis den utgående adressen varierer per bruker. En betingelse som bare passer for noen administratorer, er verre enn ingen betingelse, fordi den skjuler problemet til en hendelse.

Stol bare på proxyen som skriver om adressen

De fleste offentlige nettsteder ligger bak en CDN eller omvendt proxy, så socket-adressen til opprinnelsen tilhører den frontenden og ikke besøkende. Frontenden videresender vanligvis den opprinnelige adressen i en header, og den headeren kontrolleres av en angriper med mindre opprinnelsen bare godtar den fra kjente proxyer. Konfigurer listen over klarerte kilder eksplisitt og gjør opprinnelsen utilgjengelig fra alle andre steder. Uten den andre halvdelen hopper en angriper 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

Samme resonnement gjelder for PROXY-protokollen: den er bare pålitelig når lytteren er bundet til et grensesnitt som proxyen kan nå og ingen andre kan. Manglende adressekontekst må få den beskyttede kontrollen til å feile i stedet for å falle tilbake til en standardtillatelse. En header som mangler, er ikke bevis på en klarert bane.

Fest betingelsen til hver beskyttet operasjon

Sett kontrollen ved autorisasjonsgrensen som hver beskyttet operasjon passerer, ikke i siden som tegner menyen. Rutegrupper, middleware eller et policy-lag fungerer alle; en kopi per handler gjør det ikke, fordi handleren noen legger til neste kvartal ikke vil ha den.

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

Den samme grensen må dekke JSON-API-et, eksporter, signerte nedlastings-URL-er og WebSocket-håndtrykket, siden ingen av dem krever at HTML-siden blir forespurt først. En nedlastingslenke som er laget mens VPN-en var oppe, forblir gyldig etterpå med mindre nedlastingsendepunktet sjekker på nytt. Langvarige økter trenger også en revurderingsregel, ellers blir én autentisert forespørsel en permanent unntakelse. Standardavvisning er den eneste innstillingen som overlever utskifting av ansatte.

Delte hurtigbufre er den andre veien rundt kontrollen. En hurtigbuffer som allerede holder et beskyttet svar, kan levere det uten å kontakte opprinnelsen, så merk admin-svar som private og hold dem utenfor delt lagring. Hvis en hurtigbuffer må levere dem, må tilgangskontrollen kjøre før leveringen, noe som vanligvis betyr at den ikke kan være en delt hurtigbuffer i det hele tatt.

Test omveiene du nettopp lukket

Gå gjennom matrisen i stedet for den lykkelige veien: en administrator gjennom VPN-en, den samme administratoren uten den, en ikke-administrator gjennom den, og en forfalsket adresse-header. Legg til en forespørsel direkte til opprinnelsen og en forespørsel med bufret svar, fordi det er de to som hopper helt 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'

Hver forespørsel bør returnere statusen policyen lover, og loggen bør registrere hvilket adressebevis som ble brukt. Dekk IPv6 separat, fordi en dual-stack-opprinnelse kan se en annen kildefamilie enn den du testet. Hold vanlige kundeoperasjoner i gang utenfor VPN-en, ellers blir endringen rullet tilbake første gang en kunde klager. Skriv det forventede resultatet for hver rad før du kjører den, slik at en overraskende bestått er synlig.

Den utgående adressen beviser en tillatt nettverksbane, ikke en person og ikke en administrert enhet. Hold den som én betingelse ved siden av autentisering og tillatelse, og admin-området forblir smalt uten å gjøre hele produktet til en VPN-only-tjeneste. Den separasjonen er designet, ikke en begrensning ved det.