SaaS-adminisztrációs terület a VPN mögött: melyik címben bízzunk?

A nyilvános SaaS-oldalak mindenki számára nyitva maradhatnak, miközben a mögöttük lévő adminisztratív műveletek elutasítanak mindenkit, aki a VPN-en kívül van. Az ezt lehetővé tevő mechanizmus nem rejtett menü és nem külön bejelentkezési oldal; ez a kérést szállító hálózati útvonal ellenőrzése. Ha a címbizonyíték rossz, az ellenőrzés vagy kizárja a valódi adminisztrátorokat, vagy beenged bárkit, aki be tud írni egy fejlécet. Kezdd azzal, amit az origin valójában megkap.

Amit az origin az alagút után valójában megkap

Amikor egy böngésző olyan VPN-en keresztül éri el a nyilvános oldalt, amely internetes forgalmat is szállít, az átjáró lefordítja a kapcsolatot, mielőtt az kilép. A SaaS az átjáró nyilvános kimenő címét látja, jellemzően egy címet vagy egy kis tartományt, és soha nem látja a laptop alagútcímét. Ezért hiúsul meg a 10.90.0.42 engedélyezési listára vétele, és ezért hiúsul meg még hangosabban a teljes RFC 1918 felvétele: az utóbbi minden privát hálózatot beenged, amely elérhet téged. Az egyetlen cím, amelyre érdemes feltételt tenni, az, amely a szervezetedé a kijáratnál.

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

Az osztott alagút csendben megbontja ezt a feltevést. Ha a VPN csak privát irodai útvonalakat szállít, a nyilvános adminisztratív gazdagépnévhez intézett kérés a helyi szolgáltatón keresztül lép ki, és az origin lakóhelyi címet lát. Egy csatlakozott VPN-ikon semmit nem bizonyít erről a konkrét célról, ezért a célt teszteld, ne az alagutat.

Állj meg és javítsd a forgalomirányítást, mielőtt bármilyen szabályt írnál, ha a kimenő cím felhasználónként változik. Az a feltétel, amely csak néhány adminisztrátorra illik, rosszabb, mint a feltétel hiánya, mert incidensig elrejti a problémát.

Csak abban a proxyban bízz, amely átírja a címet

A legtöbb nyilvános oldal CDN vagy fordított proxy mögött van, így az origin socket-címe ahhoz a frontendhez tartozik, nem a látogatóhoz. A frontend általában egy fejlécben továbbítja az eredeti címet, és azt a fejlécet a támadó irányítja, hacsak az origin csak ismert proxyktól fogadja el. Konfiguráld kifejezetten a megbízható források listáját, és tedd az origint minden más helyről elérhetetlenné. A második fél nélkül a támadó megkerüli a proxyt, és közvetlenül elküldi a fejlécet.

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

Ugyanez az érvelés érvényes a PROXY protokollra: csak akkor megbízható, ha a figyelő olyan interfészhez van kötve, amelyet a proxy elér, és más semmi. A hiányzó címkontextusnak meg kell buktatnia a védett ellenőrzést, nem szabad alapértelmezett engedélybe esnie. A hiányzó fejléc nem megbízható útvonal bizonyítéka.

Csatold a feltételt minden védett művelethez

Tedd az ellenőrzést arra az engedélyezési határra, amelyen minden védett művelet átmegy, ne a menüt renderelő oldalra. Az útvonalcsoportok, a middleware vagy egy házirend-réteg mind működik; a kezelőnkénti másolat nem, mert a következő negyedévben hozzáadott kezelőnél nem lesz ott.

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

Ugyanennek a határnak kell lefednie a JSON API-t, az exportokat, az aláírt letöltési URL-eket és a WebSocket-kézfogást, mivel egyik sem igényli, hogy előbb a HTML-oldalt kérjék le. Egy letöltési hivatkozás, amely a VPN működése közben készült, utána is érvényes marad, hacsak a letöltési végpont újra nem ellenőriz. A hosszú életű munkameneteknek is kell újraértékelési szabály, különben egy hitelesített kérés állandó kivétellé válik. Az alapértelmezett elutasítás az egyetlen beállítás, amely túléli a személyzetcserét.

A megosztott gyorsítótárak a másik kerülőút. Egy gyorsítótár, amely már tartalmaz védett választ, kiszolgálhatja azt anélkül, hogy elérné az origint, ezért jelöld privátnak az adminisztratív válaszokat, és tartsd őket távol a megosztott tárolótól. Ha egy gyorsítótárnak mégis ki kell szolgálnia őket, a hozzáférés-ellenőrzésnek a kiszolgálás előtt kell futnia, ami általában azt jelenti, hogy egyáltalán nem lehet megosztott gyorsítótár.

Teszteld a most bezárt megkerüléseket

A mátrixot gyakorold, ne a boldog utat: egy adminisztrátor a VPN-en át, ugyanaz az adminisztrátor nélküle, egy nem adminisztrátor rajta át, és egy hamisított címfejléc. Adj hozzá egy közvetlen az originhez menő kérést és egy gyorsítótárazott válaszú kérést, mert ez a kettő hagyja ki teljesen a frontendet.

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'

Minden kérésnek azt az állapotot kell visszaadnia, amelyet a szabályzat ígér, és a naplónak rögzítenie kell, melyik címet bizonyítékot használták. Az IPv6-ot külön fedd le, mert egy kétveremű origin más forráscsaládot láthat, mint amelyet teszteltél. Tartsd működőképesen a szokásos ügyfélműveleteket a VPN-en kívül, különben a változtatást visszavonják, amint egy ügyfél először panaszkodik. Írd le minden sor várható eredményét a futtatás előtt, hogy egy meglepő átmenés látható legyen.

A kimenő cím engedélyezett hálózati útvonalat bizonyít, nem személyt és nem kezelt eszközt. Tartsd meg egy feltételként a hitelesítés és az engedély mellett, és az adminisztratív terület szűk marad anélkül, hogy az egész termék csak VPN-es szolgáltatássá válna. Ez az elkülönítés a tervezés, nem annak korlátja.