Wat kan een gecompromitteerde webgateway nog bereiken?
Een webgateway beperkt wat een bezoeker opent, niet wat een gecompromitteerde host kan bereiken. Twee beoordelingen, een bevoegdhedentabel en opdrachten om het bereik te meten.
Stel dat de gatewayhost wordt gecompromitteerd terwijl het certificaat nog geldig is. Elke regel die bepaalde welke pagina's een bezoeker mag opvragen blijft van kracht, en geen van die regels beperkt de verbinding die de aanvaller nu vanaf die host richting het databasesubnet opent. Juist deze kloof is de reden dat een puur web-ingangspunt niet dezelfde bewering is als een gesegmenteerd netwerk. De twee beweringen vragen afzonderlijke beoordelingen, vanuit verschillende beginpunten, voordat een van beide eerlijk kan worden gedaan.
Twee beweringen, en slechts één ervan begint bij de bezoeker
De eerste bewering gaat over een persoon: een bezoeker met een browser en een geldige sessie kan één applicatie openen en niets anders. Een puur web-ingangspunt beantwoordt die bewering goed, omdat de bezoeker een pagina krijgt in plaats van een route. Dat antwoord is de moeite waard, en het is ook de enige bewering die de meeste diagrammen vastleggen.
De tweede bewering gaat over een component: er wordt aangenomen dat de gateway, of het applicatieproces erachter, onder de controle van iemand anders staat. Vanuit die aanname verandert de vraag van welke URL's zijn toegestaan naar welke bestemmingen en identiteiten het proces nog kan bereiken.
De twee beweringen hebben verschillende eigenaren, leveren verschillend bewijs en falen onafhankelijk. Een identiteitsteam kan de eerste aantonen met een sessietest; de tweede vereist netwerkbeleid, een beoordeling van het serviceaccount en hostcontroles. Een ontwerp dat alleen de bezoekershelft vastlegt, ziet er compleet uit op een beoordelingsdia en dun tijdens een incident, omdat de controles die na een compromis tellen nooit in scope waren. Benoem welke bewering elke controle ondersteunt, anders wordt één gatewayregel aan beide toegeschreven.
Een uitgewerkte onkostendienst, en de twee manieren waarop die verliest
Neem een onkostendienst: een openbare gateway op 10.60.4.10 authenticeert medewerkers en stuurt goedgekeurde verzoeken door naar een applicatielistener op poort 8443, en die applicatie bereikt één PostgreSQL-listener op 10.60.4.20:5432 als de rol expenses_app. Medewerkers horen geen algemene interne toegang te krijgen. In normaal bedrijf levert het ontwerp inderdaad een applicatiespecifieke ingang zonder de databaselistener ergens te publiceren. De adressen doen ertoe, omdat elke latere controle in dit artikel ze noemt.
Haal nu de gateway uit de vertrouwde set. Welke bestemmingen kan 10.60.4.10 bereiken zodra het proces van een aanvaller is? Het URL-filter dat bezoekers beperkte zegt niets over een verbinding die de gatewayhost richting het databasesubnet opent.
Verwijder in plaats daarvan het applicatieproces, en de bevoegdheden veranderen van vorm: de rol expenses_app, de diensten die die server kan bereiken en de bestanden die dat account kan lezen. In beide gevallen kan de voordeur puur web blijven terwijl de backendgrens ontbreekt. Het label op de voordeur is dus geen antwoord op een van beide vragen.
Breng in kaart welke bevoegdheden elke partij werkelijk heeft
Een contract geschreven als bedoelde rechten herhaalt vaak het ontwerp aan je. Schrijf het als gehouden bevoegdheid, de controle die het overschot weerlegt, en de eigenaar van die controle, en elke rij wordt testbaar. Deze tabel is een voorstel voor het voorbeeld hierboven, geen productclaim:
| 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 |
Eigendom volgt de bevoegdheid. Het identiteitsteam bezit de beweringen, het netwerkplatformteam bezit de routes, het applicatieteam bezit de databaserol, de databasebeheerder bezit de listener en zijn op de host gebaseerde regels, en de platformeigenaar bezit het beheervlak. Een weigering zonder eigenaar is een zin in een document, geen controle.
De splitsing voorkomt ook dubbeltelling. Een poortbeperking kan geen tabelprivilege uitdrukken, en een databaserol kan niet verhinderen dat een host een socket opent naar een niet-verwant subnet.
Tel op wat de gateway kan bereiken in plaats van het te beweren
Een grensbewering is slechts zo goed als de opsomming erachter. Op de gatewayhost dekken drie opdrachten routekeuze, een live test en het uitgaande beleid:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputLees de uitvoer in die volgorde. De route zegt of 10.60.4.20 überhaupt vanaf die host wordt gekozen; de test zegt of de listener antwoordt; de regellijst toont of het beleid het pakket tegenhoudt of dat er nooit iets in zijn pad was.
Herhaal de opsomming vanaf de applicatiehost. Vanaf daar is de databasekant één query uitgevoerd als de applicatierol:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'Een geslaagde verbinding onder een rol die geen ander schema kan lezen is een ander resultaat dan een geslaagde verbinding onder een eigenaarsrol. Alleen de tweede is een bevinding.
Leg de weigeringen vast en dateer daarna de beoordeling
Acceptatie wordt als uitkomsten geschreven, niet als intenties: een medewerkerssessie kan de listener niet bereiken, de gatewayhost kan geen niet-verwant subnet bereiken, en de applicatierol kan geen database aanmaken. Elk is een afzonderlijke controle met een genoemde eigenaar en een datum.
Houd monitoring, patchen en herstel bereikbaar via het beheerpad dat daarvoor is ontworpen. Een grens die ook zijn eigenaar blokkeert, wordt een storing, en de gebruikelijke eerste reactie op die storing is de regel weer te verruimen. De CISA-perimeterrichtlijn vraagt inkomende en uitgaande toegang te beperken tot gerechtvaardigde poorten en protocollen, inclusief verkeer tussen interne netwerken, dat is de door de backend geïnitieerde richting die de meeste diagrammen weglaten.
Dateer de beoordeling en benoem de eigenaar. Voer de opsomming en de privilegequery opnieuw uit na elke wijziging aan de gateway-image, de routetabel of de applicatierol.