Kva kan ein kompromittert nettport framleis nå?
Ein nettport avgrensar kva ein besøkjande opnar, ikkje kva ein kompromittert vert kan kontakte. To gjennomgangar, ein beføyelsestabell og kommandoar for å måle rekkevidda.
Anta at gateway-verten er kompromittert medan sertifikatet framleis er gyldig. Kvar regel som styrte kva sider ein besøkjande kan be om, blir ståande, og ingen av desse reglane avgrensar sambandet som åtakaren no opnar frå den verten mot databasesubnettet. Nettopp dette gapet er grunnen til at eit reint web-inngangspunkt ikkje er same påstand som eit segmentert nettverk. Dei to påstandane krev separate gjennomgangar, frå ulike utgangspunkt, før nokon av dei kan leggjast fram ærleg.
To påstandar, og berre éin av dei startar hos den besøkjande
Den første påstanden handlar om ein person: ein besøkjande med nettlesar og gyldig økt kan opne éin applikasjon og ingenting anna. Eit reint web-inngangspunkt svarar godt på den påstanden, fordi den besøkjande får ei side og ikkje ei rute. Det svaret er verdt å ha, og det er også den einaste påstanden dei fleste diagram registrerer.
Den andre påstanden handlar om ein komponent: det blir antatt at gatewayen, eller applikasjonsprosessen bak han, er under kontrollen åt nokon annan. Frå den antakinga endrar spørsmålet seg frå kva URL-ar som er tillatne til kva mål og identitetar prosessen framleis kan nå.
Dei to påstandane har ulike eigarar, gir ulike bevis og feilar uavhengig. Eit identitetsteam kan vise den første med ein økttest; den andre treng nettverkspolitikk, gjennomgang av tenestekontoen og vertskontrollar. Eit design som berre registrerer besøkjande-halvdelen, ser komplett ut på ein gjennomgangsslayd og tynt ut under ei hending, fordi kontrollane som tel etter ein kompromittering, aldri var i omfanget. Namngi kva påstand kvar kontroll støttar, elles blir éin gateway-regel godskriven for begge.
Ein gjennomarbeida utgiftsteneste, og dei to måtane ho tapar på
Ta ei utgiftsteneste: ein offentleg gateway på 10.60.4.10 autentiserer tilsette og sender godkjende førespurnader vidare til ein applikasjonslyttar på port 8443, og applikasjonen når éin PostgreSQL-lyttar på 10.60.4.20:5432 som rolla expenses_app. Tilsette skal ikkje få generell intern tilgang. Under normal drift leverer designet faktisk eit applikasjonsspesifikt inngangspunkt utan å publisere databaselyttaren nokon stad. Adressene betyr noko, fordi kvar seinare kontroll i denne artikkelen namngir dei.
Fjern no gatewayen frå det betrudde settet. Kva mål kan 10.60.4.10 nå når prosessen tilhøyrer ein åtakar? URL-filteret som avgrensa besøkjande, seier ingenting om eit samband gateway-verten opnar mot databasesubnettet.
Fjern i staden applikasjonsprosessen, og beføyelsane skiftar form: rolla expenses_app, tenestene den tenaren kan nå, og filene den kontoen kan lese. I begge tilfelle kan hovuddøra halde fram som reint web medan backend-grensa manglar. Etiketten på hovuddøra er derfor ikkje eit svar på nokon av dei to spørsmåla.
Kartlegg beføyelsane kvar part faktisk har
Ein kontrakt skriven som tiltenkte løyve har ein tendens til å gjenta designet tilbake til deg. Skriv han som beføyelse ein har, kontrollen som motbeviser overskotet, og eigaren av den kontrollen, så blir kvar rad testbar. Denne tabellen er eit framlegg til dømet over, ikkje ein 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 |
Eigarskap følgjer beføyelsen. Identitetsteamet eig påstandane, nettverksplattformteamet eig rutene, applikasjonsteamet eig databaserolla, databaseadministratoren eig lyttaren og dei vertsbaserte reglane hans, og plattformeigaren eig styringsplanet. Ei avvising utan eigar er ei setning i eit dokument, ikkje ein kontroll.
Delinga hindrar også dobbeltteljing. Ei portavgrensing kan ikkje uttrykke eit tabellprivilegium, og ei databaserolle kan ikkje hindre ein vert i å opne ein socket mot eit urelatert subnett.
Tel opp kva gatewayen kan nå i staden for å hevde det
Ein grensepåstand er berre så god som oppteljinga bak han. På gateway-verten dekkjer tre kommandoar ruteval, ein levande test og utgangspolitikken:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputLes utdata i den rekkjefølgja. Ruta seier om 10.60.4.20 i det heile blir vald frå den verten; testen seier om lyttaren svarar; regellista viser om politikken stoppar pakken eller om det aldri var noko i banen hans.
Gjenta oppteljinga frå applikasjonsverten. Derifrå er databasesida éin spørring køyrd som applikasjonsrolla:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'Eit vellukka samband under ei rolle som ikkje kan lese eit anna skjema, er eit anna resultat enn eit vellukka samband under ei eigarrolla. Berre det andre er eit funn.
Registrer avvisingane, og dater deretter gjennomgangen
Aksept blir skriven som utfall og ikkje intensjonar: ei tilsett-økt kan ikkje nå lyttaren, gateway-verten kan ikkje nå eit urelatert subnett, og applikasjonsrolla kan ikkje opprette ein database. Kvar er ein separat kontroll med namngitt eigar og dato.
Hald overvaking, patching og gjenoppretting tilgjengeleg gjennom styringsvegen som er laga for dei. Ei grense som også blokkerer eigaren sin, blir eit avbrot, og det vanlege første svaret på det avbrotet er å utvide regelen igjen. CISA sine perimeterretningslinjer krev at innkommande og utgåande tilgang blir avgrensa til grunngitte portar og protokollar, inkludert trafikk mellom interne nettverk, som er retninga backend startar og som dei fleste diagram utelèt.
Dater gjennomgangen og namngi eigaren. Køyr oppteljinga og privilegiespørjinga på nytt etter kvar endring i gateway-avbildinga, rutetabellen eller applikasjonsrolla.