Hvad kan en kompromitteret webgateway stadig nå?
En webgateway begrænser, hvad en besøgende åbner, ikke hvad en kompromitteret vært kan kontakte. To gennemgange, en beføjelsestabel og kommandoer til at måle rækkevidden.
Antag, at gateway-værten er kompromitteret, mens dens certifikat stadig er gyldigt. Hver regel, der styrede, hvilke sider en besøgende måtte anmode om, forbliver i kraft, og ingen af disse regler begrænser den forbindelse, som angriberen nu åbner fra den vært mod databasesubnettet. Netop dette hul er grunden til, at et rent web-indgangspunkt ikke er det samme udsagn som et segmenteret netværk. De to udsagn kræver separate gennemgange fra forskellige udgangspunkter, før nogen af dem kan fremsættes ærligt.
To udsagn, og kun det ene begynder hos den besøgende
Det første udsagn handler om en person: en besøgende med en browser og en gyldig session kan åbne én applikation og intet andet. Et rent web-indgangspunkt besvarer det udsagn godt, fordi den besøgende modtager en side i stedet for en rute. Det svar er værd at have, og det er også det eneste udsagn, de fleste diagrammer registrerer.
Det andet udsagn handler om en komponent: gatewayen eller applikationsprocessen bag den antages at være under en andens kontrol. Ud fra den antagelse ændres spørgsmålet fra, hvilke URL'er der er tilladte, til hvilke destinationer og identiteter processen stadig kan nå.
De to udsagn har forskellige ejere, giver forskellige beviser og fejler uafhængigt. Et identitetsteam kan påvise det første med en sessionstest; det andet kræver netværkspolitik, en gennemgang af tjenestekontoen og værtskontroller. Et design, der kun registrerer besøgendes-halvdelen, ser komplet ud på en gennemgangs-slide og tynd ud under en hændelse, fordi de kontroller, der betyder noget efter en kompromittering, aldrig var i omfang. Navngiv, hvilket udsagn hver kontrol understøtter, ellers bliver én gateway-regel krediteret for begge.
En gennemarbejdet udgiftstjeneste og de to måder, den taber på
Tag en udgiftstjeneste: en offentlig gateway på 10.60.4.10 autentificerer medarbejdere og videresender godkendte anmodninger til en applikationslytter på port 8443, og den applikation når én PostgreSQL-lytter på 10.60.4.20:5432 som rollen expenses_app. Medarbejdere skal ikke have generel intern adgang. Under normal drift leverer designet faktisk en applikationsspecifik indgang uden at offentliggøre databaselytteren nogetsteds. Adresserne betyder noget, fordi hver kontrol senere i denne artikel navngiver dem.
Fjern nu gatewayen fra det betroede sæt. Hvilke destinationer kan 10.60.4.10 nå, når dens proces tilhører en angriber? Det URL-filter, der begrænsede besøgende, siger intet om en forbindelse, som gateway-værten åbner mod databasesubnettet.
Fjern i stedet applikationsprocessen, og beføjelserne skifter form: rollen expenses_app, de tjenester, den server kan nå, og de filer, den konto kan læse. I begge tilfælde kan hoveddøren forblive rent web, mens backend-grænsen mangler. Etiketten på hoveddøren er derfor ikke et svar på noget af de to spørgsmål.
Kortlæg den beføjelse, hver part faktisk har
En kontrakt skrevet som tilsigtede tilladelser har en tendens til at gentage designet tilbage til dig. Skriv den som besiddet beføjelse, den kontrol, der modbeviser overskuddet, og ejeren af den kontrol, og hver række bliver testbar. Denne tabel er et forslag til eksemplet ovenfor, ikke en produktpåstand:
| 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 |
Ejerskab følger beføjelsen. Identitetsteamet ejer assertions, netværksplatformsteamet ejer ruter, applikationsteamet ejer databaserollen, databaseadministratoren ejer lytteren og dens værtsbaserede regler, og platformsejeren ejer styringsplanet. En afvisning uden ejer er en sætning i et dokument snarere end en kontrol.
Opdelingen forhindrer også dobbelttælling. En portbegrænsning kan ikke udtrykke en tabelprivilegium, og en databaserolle kan ikke forhindre en vært i at åbne en socket mod et urelateret subnet.
Optæl, hvad gatewayen kan nå, i stedet for at hævde det
Et grænseclaim er kun så godt som optællingen bag det. På gateway-værten dækker tre kommandoer rutevalg, en livetest og udgangspolitikken:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputLæs outputtet i den rækkefølge. Ruten siger, om 10.60.4.20 overhovedet vælges fra den vært; testen siger, om lytteren svarer; regellisten viser, om politik stopper pakken, eller om der aldrig var noget i dens vej.
Gentag optællingen fra applikationsværten. Derfra er databasesiden én forespørgsel kørt som applikationsrollen:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'En vellykket forbindelse under en rolle, der ikke kan læse et andet skema, er et andet resultat end en vellykket forbindelse under en ejerrolle. Kun den anden er et fund.
Registrer afvisningerne, og datér derefter gennemgangen
Accept skrives som udfald snarere end hensigter: en medarbejdersession kan ikke nå lytteren, gateway-værten kan ikke nå et urelateret subnet, og applikationsrollen kan ikke oprette en database. Hver er en separat kontrol med en navngivet ejer og en dato.
Hold overvågning, patchning og gendannelse tilgængelige gennem den styringsvej, der er designet til dem. En grænse, der også blokerer sin ejer, bliver et afbrud, og det sædvanlige første svar på det afbrud er at udvide reglen igen. CISA's perimetervejledning kræver, at indgående og udgående adgang begrænses til begrundede porte og protokoller, herunder trafik mellem interne netværk, hvilket er den backend-initierede retning, som de fleste diagrammer udelader.
Datér gennemgangen, og navngiv dens ejer. Kør optællingen og privilegieforespørgslen igen efter enhver ændring af gateway-imaget, rutetabellen eller applikationsrollen.