Mit érhet még el egy kompromittált webátjáró?
A webátjáró azt korlátozza, mit nyit meg a látogató, nem azt, mit érhet el egy kompromittált gazdagép. Két vizsgálat, felhatalmazási táblázat és hatótávolság-mérő parancsok.
Tegyük fel, hogy az átjáró gazdagépe kompromittálódik, miközben a tanúsítványa még érvényes. Minden szabály, amely meghatározta, mely oldalakat kérhet a látogató, érvényben marad, és e szabályok egyike sem korlátozza azt a kapcsolatot, amelyet a támadó most nyit a gazdagépről az adatbázis alhálózata felé. Ez a hézag az oka annak, hogy egy csak webes belépési pont nem ugyanaz az állítás, mint egy szegmentált hálózat. A két állítás külön vizsgálatot igényel, különböző kiindulópontokból, mielőtt bármelyik becsületesen megtehető.
Két állítás, és csak az egyik kezdődik a látogatónál
Az első állítás egy személyről szól: a böngészővel és érvényes munkamenettel rendelkező látogató egy alkalmazást nyithat meg, és semmi mást. A csak webes belépési pont jól válaszol erre az állításra, mert a látogató oldalt kap, nem útvonalat. Ez a válasz megérdemli a helyét, és egyben ez az egyetlen állítás, amelyet a legtöbb diagram rögzít.
A második állítás egy összetevőről szól: feltételezzük, hogy az átjáró vagy a mögötte lévő alkalmazásfolyamat valaki más ellenőrzése alatt áll. Ebből a feltevésből a kérdés arról, mely URL-ek engedélyezettek, átvált arra, hogy a folyamat még mely célokat és identitásokat érhet el.
A két állításnak különböző tulajdonosai vannak, különböző bizonyítékokat termelnek, és egymástól függetlenül hibáznak. Az identitáscsapat egy munkamenet-teszttel igazolhatja az elsőt; a másodikhoz hálózati szabályzat, a szolgáltatásifjók átvizsgálása és gazdagép-vezérlők kellenek. Az a terv, amely csak a látogató felét rögzíti, teljesnek látszik egy felülvizsgálati dián, és vékonynak egy incidens alatt, mert a kompromittálás után fontos vezérlők soha nem voltak a hatókörben. Nevezze meg, melyik állítást támogatja az egyes vezérlők, különben egy átjárószabályt mindkettőnek jóváírnak.
Egy kidolgozott költségnyilvántartó szolgáltatás, és a kétféle veszteség
Vegyünk egy költségnyilvántartó szolgáltatást: a 10.60.4.10 címen működő nyilvános átjáró hitelesíti a munkatársakat, és a jóváhagyott kéréseket továbbítja a 8443-as porton futó alkalmazásfigyelőnek, az alkalmazás pedig egy PostgreSQL-figyelőt ér el a 10.60.4.20:5432 címen expenses_app szerepkörben. A munkatársak nem kaphatnak általános belső hozzáférést. Normál üzemelésben a terv valóban alkalmazásspecifikus belépést biztosít anélkül, hogy az adatbázis-figyelőt bárhol közzétenné. A címek számítanak, mert a cikk későbbi ellenőrzései mind megnevezik őket.
Most vegyük ki az átjárót a megbízható halmazból. Mely célokat érheti el a 10.60.4.10, ha a folyamata egy támadóhoz tartozik? Az URL-szűrő, amely a látogatókat korlátozta, semmit sem mond arról a kapcsolatról, amelyet az átjáró gazdagépe az adatbázis alhálózata felé nyit.
Vegyük ki helyette az alkalmazásfolyamatot, és a felhatalmazás formát vált: az expenses_app szerepkör, a szolgáltatások, amelyeket az a kiszolgáló elérhet, és a fájlok, amelyeket az a fiók olvashat. Mindkét esetben az előajtó csak webes maradhat, miközben a háttérrendszer határa hiányzik. Az előajtó címkéje ezért egyik kérdésre sem válasz.
Térképezze fel, milyen felhatalmazással rendelkezik az egyes felek ténylegesen
A szándékolt engedélyekként megírt szerződés hajlamos visszamondani a tervet. Írja meg meglévő felhatalmazásként, a többletet cáfoló ellenőrzésként és ezen ellenőrzés tulajdonosaként, és minden sor vizsgálhatóvá válik. Ez a táblázat a fenti példa javaslata, nem termékállítás:
| 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 |
A tulajdon követi a felhatalmazást. Az identitáscsapat az állítások, a hálózati platformcsapat az útvonalak, az alkalmazáscsapat az adatbázis-szerepkör tulajdonosa, az adatbázis-adminisztrátor a figyelő és annak gazdagépalapú szabályaié, a platformtulajdonos pedig a felügyeleti sík tulajdonosa. Tulajdonos nélküli elutasítás egy mondat egy dokumentumban, nem vezérlő.
A felosztás a kettős elszámolást is megakadályozza. A portkorlátozás nem fejezhet ki táblajogosultságot, és egy adatbázis-szerepkör nem akadályozhatja meg, hogy egy gazdagép foglalatot nyisson egy nem kapcsolódó alhálózat felé.
Sorolja fel, mit érhet el az átjáró, ahelyett hogy állítaná
Egy határállítás csak annyit ér, mint a mögötte lévő felsorolás. Az átjáró gazdagépén három parancs fedi le az útvonalválasztást, az élő próbát és a kilépési szabályzatot:
ip route get 10.60.4.20
nc -zv 10.60.4.20 5432
sudo nft list chain inet filter outputEbben a sorrendben olvassa a kimenetet. Az útvonal megmondja, hogy a 10.60.4.20 egyáltalán kiválasztódik-e arról a gazdagépről; a próba megmondja, válaszol-e a figyelő; a szabálylista megmutatja, hogy a szabályzat megállítja-e a csomagot, vagy soha nem volt semmi az útvonalában.
Ismételje meg a felsorolást az alkalmazásgazdagépről. Onnan az adatbázis oldala egyetlen lekérdezés, amelyet az alkalmazás szerepkörében futtatnak:
psql -h 10.60.4.20 -U expenses_app -d expenses -c 'select rolname, rolsuper, rolcreatedb from pg_roles'Egy másik sémát olvasni nem tudó szerepkör alatti sikeres kapcsolat más eredmény, mint egy tulajdonosi szerepkör alatti sikeres kapcsolat. Csak a második megállapítás.
Rögzítse az elutasításokat, majd dátumozza a felülvizsgálatot
Az elfogadás eredményként íródik le, nem szándékként: egy munkatársi munkamenet nem érheti el a figyelőt, az átjáró gazdagépe nem érhet el egy nem kapcsolódó alhálózatot, és az alkalmazás szerepköre nem hozhat létre adatbázist. Mindegyik külön ellenőrzés megnevezett tulajdonossal és dátummal.
Tartsa elérhetővé a felügyeletet, a javítást és a helyreállítást a számukra tervezett felügyeleti útvonalon. Az a határ, amely a tulajdonosát is blokkolja, kieséssé válik, és az ilyen kiesésre adott szokásos első válasz a szabály ismételt kiszélesítése. A CISA peremhálózati útmutatása azt kéri, hogy a bejövő és kimenő hozzáférést indokolt portokra és protokollokra korlátozzák, beleértve a belső hálózatok közötti forgalmat is, ami a háttérrendszer által indított irány, amelyet a legtöbb diagram kihagy.
Dátumozza a felülvizsgálatot, és nevezze meg a tulajdonosát. Futtassa újra a felsorolást és a jogosultsági lekérdezést az átjáró lemezképe, az útválasztási tábla vagy az alkalmazás szerepköre minden változása után.