Vad kan en komprometterad webbgateway fortfarande nå?
En webbgateway begränsar vad en besökare öppnar, inte vad en komprometterad värd kan nå. Två granskningar, en befogenhetstabell och kommandon för att mäta räckvidden.
Anta att gateway-värden är komprometterad medan dess certifikat fortfarande är giltigt. Varje regel som styrde vilka sidor en besökare får begära gäller fortfarande, och ingen av dessa regler begränsar den anslutning som angriparen nu öppnar från den värden mot databassubnätet. Det är just denna lucka som gör att en ren webb-ingångspunkt inte är samma påstående som ett segmenterat nätverk. De två påståendena kräver separata granskningar, från olika utgångspunkter, innan något av dem kan göras ärligt.
Två påståenden, och bara ett av dem börjar hos besökaren
Det första påståendet handlar om en person: en besökare med webbläsare och giltig session kan öppna en applikation och inget annat. En ren webb-ingångspunkt svarar bra på det påståendet, eftersom besökaren får en sida i stället för en rutt. Det svaret är värt att ha, och det är också det enda påstående som de flesta diagram registrerar.
Det andra påståendet handlar om en komponent: man antar att gatewayen, eller applikationsprocessen bakom den, står under någon annans kontroll. Utifrån det antagandet ändras frågan från vilka URL:er som är tillåtna till vilka destinationer och identiteter processen fortfarande kan nå.
De två påståendena har olika ägare, ger olika bevis och misslyckas oberoende. Ett identitetsteam kan visa det första med ett sessionstest; det andra kräver nätverkspolicy, granskning av tjänstekontot och värdkontroller. En design som bara registrerar besökarens halva ser komplett ut på en granskningsbild och tunn ut under en incident, eftersom de kontroller som spelar roll efter en kompromettering aldrig ingick i omfattningen. Namnge vilket påstående varje kontroll stöder, annars krediteras en gateway-regel för båda.
En genomarbetad utgiftstjänst, och de två sätt den förlorar på
Ta en utgiftstjänst: en offentlig gateway på 10.60.4.10 autentiserar personal och vidarebefordrar godkända förfrågningar till en applikationslyssnare på port 8443, och den applikationen når en PostgreSQL-lyssnare på 10.60.4.20:5432 som rollen expenses_app. Anställda ska inte få allmän intern åtkomst. Under normal drift levererar designen faktiskt en applikationsspecifik ingång utan att publicera databaslyssnaren någonstans. Adresserna spelar roll, eftersom varje senare kontroll i den här artikeln namnger dem.
Ta nu bort gatewayen från den betrodda mängden. Vilka destinationer kan 10.60.4.10 nå när dess process tillhör en angripare? URL-filtret som begränsade besökare säger ingenting om en anslutning som gateway-värden öppnar mot databassubnätet.
Ta i stället bort applikationsprocessen, och befogenheterna byter form: rollen expenses_app, de tjänster som servern kan nå och de filer som kontot kan läsa. I båda fallen kan ytterdörren förbli ren webb medan backend-gränsen saknas. Etiketten på ytterdörren är därför inte ett svar på någon av de två frågorna.
Kartlägg vilka befogenheter varje part faktiskt har
Ett kontrakt skrivet som avsedda behörigheter tenderar att upprepa designen tillbaka till dig. Skriv det som befogenhet man har, kontrollen som motbevisar överskottet och ägaren av den kontrollen, så blir varje rad testbar. Den här tabellen är ett förslag till exemplet ovan, inte ett produktpåstående:
| Component | Authority it actually holds | Check that proves the denial | Owner of the check |
|---|---|---|---|
| Identity provider | Issues assertions and session cookies, and holds no network path of its own | A request to the application URL without a session is redirected to the login page | Identity team |
| Public gateway host | TCP reachability to whatever its routing table and egress rules permit | An egress rule drops 10.60.4.20:5432 and the probe reports the port filtered | Network platform team |
| Application role | SQL privileges granted to expenses_app inside the expenses database | A privilege query shows no ownership or create right on any other schema | Application team |
| Database listener | Accepts connections only from the source ranges named in its host-based rules | A connection from an unlisted address is refused before authentication | Database administrator |
| Management path | Administrative access reserved for patching, monitoring and recovery | A staff workstation cannot reach the administrative port or jump through it | Platform owner |
Ägandet följer befogenheten. Identitetsteamet äger påståendena, nätverksplattformsteamet äger rutterna, applikationsteamet äger databasrollen, databasadministratören äger lyssnaren och dess värdbaserade regler, och plattformsägaren äger hanteringsplanet. En avvisning utan ägare är en mening i ett dokument, inte en kontroll.
Uppdelningen förhindrar också dubbelräkning. En portbegränsning kan inte uttrycka ett tabellprivilegium, och en databasroll kan inte hindra en värd från att öppna en socket mot ett orelaterat subnät.
Räkna upp vad gatewayen kan nå i stället för att påstå det
Ett gränspåstående är bara så bra som uppräkningen bakom det. På gateway-värden täcker tre kommandon ruttval, en livetest och utgresspolicyn:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputLäs utdata i den ordningen. Rutten säger om 10.60.4.20 ens väljs från den värden; testet säger om lyssnaren svarar; regellistan visar om policyn stoppar paketet eller om det aldrig fanns något i dess väg.
Upprepa uppräkningen från applikationsvärden. Därifrån är databassidan en enda fråga som körs som applikationsrollen:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'En lyckad anslutning under en roll som inte kan läsa ett annat schema är ett annat resultat än en lyckad anslutning under en ägarroll. Bara den andra är ett fynd.
Registrera avvisningarna och datera sedan granskningen
Accept skrivs som utfall och inte avsikter: en anställds session kan inte nå lyssnaren, gateway-värden kan inte nå ett orelaterat subnät, och applikationsrollen kan inte skapa en databas. Varje är en separat kontroll med namngiven ägare och datum.
Håll övervakning, patchning och återställning nåbara via den hanteringsväg som är avsedd för dem. En gräns som också blockerar sin ägare blir ett avbrott, och det vanliga första svaret på det avbrottet är att vidga regeln igen. CISA:s perimeterriktlinjer kräver att inkommande och utgående åtkomst begränsas till motiverade portar och protokoll, inklusive trafik mellan interna nätverk, vilket är den riktning som backend initierar och som de flesta diagram utelämnar.
Datera granskningen och namnge dess ägare. Kör uppräkningen och privilegiefrågan igen efter varje ändring av gateway-avbildningen, rutttabellen eller applikationsrollen.