Hva kan en kompromittert nettport fortsatt nå?
En nettport begrenser hva en besøkende åpner, ikke hva en kompromittert vert kan kontakte. To gjennomganger, en beføyelsestabell og kommandoer for å måle rekkevidden.
Anta at gateway-verten er kompromittert mens sertifikatet fortsatt er gyldig. Hver regel som styrte hvilke sider en besøkende kan be om, blir stående, og ingen av disse reglene begrenser forbindelsen angriperen nå åpner fra den verten mot databasesubnettet. Nettopp dette gapet er grunnen til at et rent web-inngangspunkt ikke er samme påstand som et segmentert nettverk. De to påstandene krever separate gjennomganger, fra ulike utgangspunkter, før noen av dem kan fremsettes ærlig.
To påstander, og bare én av dem starter hos den besøkende
Den første påstanden handler om en person: en besøkende med nettleser og gyldig økt kan åpne én applikasjon og ingenting annet. Et rent web-inngangspunkt svarer godt på den påstanden, fordi den besøkende får en side og ikke en rute. Det svaret er verdt å ha, og det er også den eneste påstanden de fleste diagrammer registrerer.
Den andre påstanden handler om en komponent: det antas at gatewayen, eller applikasjonsprosessen bak den, er under noen andres kontroll. Fra den antakelsen endres spørsmålet fra hvilke URL-er som er tillatt til hvilke destinasjoner og identiteter prosessen fortsatt kan nå.
De to påstandene har ulike eiere, gir ulike bevis og feiler uavhengig. Et identitetsteam kan vise den første med en økttest; den andre trenger nettverkspolitikk, gjennomgang av tjenestekontoen og vertskontroller. Et design som bare registrerer besøkende-halvdelen, ser komplett ut på en gjennomgangslysbilde og tynt ut under en hendelse, fordi kontrollene som betyr noe etter en kompromittering, aldri var i omfanget. Navngi hvilken påstand hver kontroll støtter, ellers blir én gateway-regel godskrevet for begge.
En gjennomarbeidet utgiftstjeneste, og de to måtene den taper på
Ta en utgiftstjeneste: en offentlig gateway på 10.60.4.10 autentiserer ansatte og videresender godkjente forespørsler til en applikasjonslytter på port 8443, og den applikasjonen når én PostgreSQL-lytter på 10.60.4.20:5432 som rollen expenses_app. Ansatte skal ikke få generell intern tilgang. Under normal drift leverer designet faktisk et applikasjonsspesifikt inngangspunkt uten å publisere databaselytteren noe sted. Adressene betyr noe, fordi hver senere kontroll i denne artikkelen navngir dem.
Fjern nå gatewayen fra det betrodde settet. Hvilke destinasjoner kan 10.60.4.10 nå når prosessen tilhører en angriper? URL-filteret som begrenset besøkende, sier ingenting om en forbindelse gateway-verten åpner mot databasesubnettet.
Fjern i stedet applikasjonsprosessen, og beføyelsene skifter form: rollen expenses_app, tjenestene den serveren kan nå, og filene den kontoen kan lese. I begge tilfeller kan hoveddøren forbli rent web mens backend-grensen mangler. Etiketten på hoveddøren er derfor ikke et svar på noen av de to spørsmålene.
Kartlegg beføyelsene hver part faktisk har
En kontrakt skrevet som tiltenkte tillatelser har en tendens til å gjenta designet tilbake til deg. Skriv den som beføyelse man har, kontrollen som motbeviser overskuddet, og eieren av den kontrollen, så blir hver rad testbar. Denne tabellen er et forslag til eksempelet over, 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 |
Eierskap følger beføyelsen. Identitetsteamet eier påstandene, nettverksplattformteamet eier rutene, applikasjonsteamet eier databaserollen, databaseadministratoren eier lytteren og dens vertsbaserte regler, og plattformeieren eier styringsplanet. En avvisning uten eier er en setning i et dokument, ikke en kontroll.
Delingen forhindrer også dobbelttelling. En portbegrensning kan ikke uttrykke et tabellprivilegium, og en databaserolle kan ikke hindre en vert i å åpne en socket mot et urelatert subnett.
Tell opp hva gatewayen kan nå i stedet for å hevde det
En grensepåstand er bare så god som opptellingen bak den. På gateway-verten dekker tre kommandoer rutevalg, en levende test og utgangspolitikken:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputLes utdataene i den rekkefølgen. Ruten sier om 10.60.4.20 i det hele tatt velges fra den verten; testen sier om lytteren svarer; regellisten viser om politikken stopper pakken eller om det aldri var noe i banen dens.
Gjenta opptellingen fra applikasjonsverten. Derfra er databasesiden én spørring kjørt som applikasjonsrollen:
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 som ikke kan lese et annet skjema, er et annet resultat enn en vellykket forbindelse under en eierrolle. Bare den andre er et funn.
Registrer avvisningene, og dater deretter gjennomgangen
Aksept skrives som utfall og ikke intensjoner: en ansatts økt kan ikke nå lytteren, gateway-verten kan ikke nå et urelatert subnett, og applikasjonsrollen kan ikke opprette en database. Hver er en separat kontroll med navngitt eier og dato.
Hold overvåking, patching og gjenoppretting tilgjengelig gjennom styringsveien som er laget for dem. En grense som også blokkerer sin eier, blir et avbrudd, og det vanlige første svaret på det avbruddet er å utvide regelen igjen. CISA sine perimeterretningslinjer krever at innkommende og utgående tilgang begrenses til begrunnede porter og protokoller, inkludert trafikk mellom interne nettverk, som er retningen backend initierer og som de fleste diagrammer utelater.
Dater gjennomgangen og navngi eieren. Kjør opptellingen og privilegiespørringen på nytt etter enhver endring i gateway-avbildningen, rutetabellen eller applikasjonsrollen.