Egy benchmark megjelölte a VPN-portot? Ellenőrizze az ellenőrzés hatókörét

A szkennere megjelöli a VPN-portot, a jegy ezt nyilvános figyelőként fogalmazza át, és a következő vita arról szól, hogy valódi-e a kitettség. A megállapítás ritkán mondja azt, amit az olvasó feltételez. Egy rögzített hatókörű benchmark-ellenőrzést idéz, és a portszám csak egyetlen bemenet abba a hatókörbe.

Olvassa el az ellenőrzést, mielőtt megvédi a portot. Az ítéletként olvasható megállapítás általában egyetlen erőforrásra alkalmazott predikátum.

Mit is idéz valójában a megállapítás sora

Minden benchmark-megállapítás négy dolgot hordoz, amelyeket érdemes szétválasztani: a dokumentumot és a revíziót, amelyből származik, az értékelt erőforrást, az eredményt kiváltó predikátumot és azt a lefedettséget, amelyet az audit valójában elért. A csapatok általában csak az erőforrást idézik — egy biztonsági csoportot vagy egy hálózati ACL-t vagy egy gazdagépet —, majd a portról vitatkoznak. A predikátum dönti el, hogy a figyelője egyáltalán benne volt-e a hatókörben. Nélküle számról vitatkozik szabály helyett.

Az Amazon Security Hub dokumentációja fizetős PDF nélkül is láthatóvá teszi ezt a szétválasztást:az EC2-ellenőrzések oldala felsorolja a biztonsági csoportok ellenőrzéseit a 22-es és 3389-es port korlátlan elérésére, és a hálózati ACL-eket saját feltételekkel rendelkező más erőforrásként kezeli. Ugyanazok az adminisztratív portok, más objektum, más teszt. Ezt a granularitást örökli egy megállapítás.

aws ec2 describe-security-groups --group-ids sg-0d1f8a2c4b6e9f3a1 --output json
aws ec2 describe-network-acls --filters Name=entry.port-range.from,Values=22 --output table

Válassza szét a nyilvános figyelőt az adminisztratív hozzáféréstől

Az internetről UDP 1194-et elfogadó VPN-figyelő és a csak belépés után elérhető SSH-szolgáltatás különböző kitettségi utak. Az elsőt lefedő ellenőrzés lehet, hogy semmit sem mond a másodikról, a másodikat lefedő pedig figyelmen kívül hagyhatja az elsőt. Az egyiken átment eredmény nem állítás a másikról, bármennyire hasonlóan hangzik a kettő egy státuszmegbeszélésen.

Kezelje minden utat saját soraként az áttekintésben.

Ezután ellenőrizze, mit engedélyez maga az átjáró. Egy alagút elfogadása nem ugyanaz, mint adminisztratív jogok adása az átjárón, és egyik sem egyenlő a mögötte lévő kiszolgáló elérésével. Bontsa a kérdést arra, ki tud csatlakozni, ki tud adminisztrálni és mit érhet el az alagút. Ez a három válasz különböző rendszerekből jön, és rutinszerűen egyetlen mondatba olvasztják őket, amely alapján senki sem tud cselekedni.

Az erőforrás dönti el, hogy a port egyáltalán benne van-e a hatókörben

Egy biztonsági csoport szabálya, egy alhálózati ACL-bejegyzés és egy gazdagép-tűzfal szabálya mind engedélyezhet forgalmat, mégis csak az egyikük lehet az objektum, amelyet az ellenőrzés értékel. A tényleges engedélyezés a párhuzamos csoportok, mindkét címcsalád és a előttük álló bármely tiltó szabály kombinálását jelenti. Egy port, amely elbukik egy csoportszintű ellenőrzésen, még mindig elérhetetlen lehet, és egy port, amely átmegy rajta, még mindig blokkolható beljebb.

Itt megy félre egy másik környezet szabályainak átültetése. A hálózati ACL-ek állapot nélküliek és sorrendben értékelődnek; a biztonsági csoportok állapotot tartanak és csak engedélyeznek. Az egyiktől kölcsönzött szabálymodell nem írja le a másikat, és lefordítása magabiztos választ ad a rossz objektumról.

Rögzítse a döntést, hogy a következő audit újra felhasználja

Amikor a hatókör valóban kétértelmű, írja le az ellenőrzés revízióját, az erőforrás azonosítóját, az idézett predikátumot és a bizonyítékot, amely eldöntötte. Foglalja bele, mit zárt ki és miért. Ez a feljegyzés teszi lehetővé, hogy egy második bíráló ugyanarra a következtetésre jusson a teljes benchmark újraolvasása nélkül, és ez az egyetlen dolog, amely túléli a személyzetcserét.

Egy „VPN-port átvizsgálva” feliratú feljegyzés garantálja, hogy a vita jövő negyedévben visszatér. Nevezze meg helyette az értékelőt, a revíziót és a bizonyítékot.