Administrativno območje SaaS za VPN: kateremu naslovu zaupati?

Izvor vidi izhodni naslov vaše prehode VPN, ne naslova tunela prenosnika. Zaupajte le konfigurirani glavi proxyja, nato zaprite vsako administrativno operacijo.

Javne strani SaaS lahko ostanejo odprte za vse, medtem ko administrativne operacije za njimi zavrnejo vsakogar zunaj VPN. Mehanizem, ki to omogoča, ni skrit meni ali ločena prijavna stran; to je preverjanje omrežne poti, ki je dostavila zahtevo. Če je dokaz o naslovu napačen, preverjanje bodisi zaklene prave administratorje bodisi spusti vsakogar, ki zna vtipkati glavo. Začnite s tem, kar izvor dejansko prejme.

Kaj izvor po tunelu dejansko prejme

Ko brskalnik doseže javno stran prek VPN, ki prenaša tudi internetni promet, prehod prevede povezavo, preden ta odide. SaaS vidi javni izhodni naslov prehoda, običajno en naslov ali majhen razpon, in nikoli ne vidi naslova tunela prenosnika. Zato dodajanje 10.90.0.42 na seznam dovoljenih ne uspe, in zato dodajanje celotnega RFC 1918 ne uspe še glasneje: drugo spusti vsako zasebno omrežje, ki lahko doseže vas. Edini naslov, vreden pogoja, je tisti, ki ga vaša organizacija dejansko ima na izhodu.

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

Razdeljeno tuneliranje to predpostavko tiho zlomi. Če VPN prenaša le zasebne pisarniške poti, zahteva na javno administrativno ime gostitelja odide prek lokalnega ponudnika in izvor vidi stanovanjski naslov. Povezana ikona VPN o tej konkretni destinaciji ne dokazuje ničesar, zato preizkusite destinacijo, ne tunela.

Ustavite se in popravite usmerjanje, preden napišete katero koli politiko, če se izhodni naslov razlikuje po uporabniku. Pogoj, ki ustreza le nekaterim administratorjem, je slabši od nobenega pogoja, ker skrije težavo do incidenta.

Zaupajte le proxyju, ki prepiše naslov

Večina javnih strani stoji za CDN ali obratnim proxyjem, zato naslov vtičnice izvora pripada tej sprednji strani in ne obiskovalcu. Sprednja stran običajno posreduje izvirni naslov v glavi, in to glavo nadzoruje napadalec, razen če izvor sprejema le od znanih proxyjev. Izrecno konfigurirajte seznam zaupanja vrednih virov in naredite izvor nedosegljiv od kjerkoli drugje. Brez te druge polovice napadalec obide proxy in pošlje glavo neposredno.

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

Enako razmišljanje velja za protokol PROXY: zanesljiv je le, ko je poslušalec vezan na vmesnik, ki ga proxy lahko doseže in noben drug ne more. Manjkajoči kontekst naslova mora povzročiti neuspeh zaščitenega preverjanja, ne pa pasti v privzeto dovoljenje. Manjkajoča glava ni dokaz zaupanja vredne poti.

Pripnite pogoj k vsaki zaščiteni operaciji

Preverjanje postavite na mejo avtorizacije, skozi katero gre vsaka zaščitena operacija, ne na stran, ki izrisuje meni. Skupine poti, middleware ali plast pravil delujejo vse; kopija na vsak upravljalnik ne, ker je upravljalnik, ki ga nekdo doda v naslednjem četrtletju, ne bo imel.

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

Ista meja mora pokriti JSON API, izvoze, podpisane URL-je za prenos in rokovanje WebSocket, saj noben od njih ne potrebuje, da bi bila najprej zahtevana stran HTML. Povezava za prenos, ustvarjena, medtem ko je bil VPN aktiven, ostane veljavna tudi pozneje, razen če končna točka prenosa znova preveri. Dolgotrajne seje potrebujejo tudi pravilo ponovne ocene, sicer ena preverjena zahteva postane trajna izjema. Privzeta zavrnitev je edina nastavitev, ki preživi menjavo osebja.

Skupni predpomnilniki so druga pot okoli preverjanja. Predpomnilnik, ki že vsebuje zaščiten odgovor, ga lahko postreže brez stika z izvorom, zato označite administrativne odgovore kot zasebne in jih hranite zunaj skupnega shrambe. Če jih mora predpomnilnik postreči, se mora preverjanje dostopa izvesti pred postrežbo, kar običajno pomeni, da sploh ne more biti skupni predpomnilnik.

Preizkusite obhode, ki ste jih pravkar zaprli

Vadite matriko, ne srečne poti: administrator skozi VPN, isti administrator brez nje, neadministrator skozi njo in ponarejena glava naslova. Dodajte zahtevo neposredno na izvor in zahtevo z odgovorom iz predpomnilnika, ker prav ta dva v celoti obideta sprednjo stran.

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'

Vsaka zahteva mora vrniti stanje, ki ga obljublja politika, dnevnik pa mora zabeležiti, kateri dokaz o naslovu je bil uporabljen. IPv6 pokrijte ločeno, ker lahko dvoslojni izvor vidi drugo družino virov kot testirano. Običajne odjemalčeve operacije naj delujejo zunaj VPN, sicer bo sprememba razveljavljena ob prvi pritožbi stranke. Zapišite pričakovani rezultat za vsako vrstico pred izvajanjem, da bo presenetljiv prehod viden.

Izhodni naslov dokazuje dovoljeno omrežno pot, ne osebe in ne upravljane naprave. Hranite ga kot en pogoj poleg preverjanja pristnosti in dovoljenja, in administrativno območje ostane ozko, ne da bi celoten izdelek spremenili v storitev samo za VPN. Ta ločitev je zasnova, ne njena omejitev.

Sorodni članki