Tegyük fel, hogy holnap feltörik a webszervert. Milyen más eszközöket érhetnek el onnan? A válasz is meghatározza, hogy az incidens egyetlen szolgáltatásra korlátozódik-e, vagy a vállalkozás további részeit is veszélyezteti. Egy javítás az ismert sérülékenység ellen véd. A jól megtervezett hálózat emellett a lehetséges következményeket is korlátozza.
A példa egy fiktív ügyfélportál: a felhasználók bejelentkeznek, rendeléseket néznek meg és dokumentumokat töltenek le. Az alkalmazásnak meghatározott adatbázis-kapcsolatra van szüksége. Ebből nem következik, hogy a NAS felügyeletéhez, a mentési szerverhez vagy a virtualizációs gazdagéphez is hozzá kell férnie. Ezt a különbséget technikai szabályokkal kell érvényesíteni.
A feltört szolgáltatás az elérhető útvonalakat használja
Egy sérülékenység lehetővé teheti idegen kód futtatását a webalkalmazás jogosultságaival. A további lehetőségek többek között a hálózati szabályoktól, szolgáltatásfiókoktól, tárolt hitelesítő adatoktól és más sérülékenységektől függenek. A hálózati elérhetőség még nem jelent sikeres hozzáférést. A feltört webszerver sem veszi át automatikusan az egész LAN irányítását.
A kockázat akkor nő, ha az elérhető belső szolgáltatások túl széles jogosultságokkal párosulnak. A támadónak ilyenkor kevesebb határt kell átlépnie. Ezt a más rendszerekre történő lehetséges továbbterjedést oldalirányú mozgásnak nevezzük. A tervezés során ezért hasznos abból kiindulni, hogy egy alkalmazást már feltörtek.
„A” hálózat: a portál egy tagolatlan vállalati hálózatban működik
Az első kialakításban a portál, az adatbázis, a fájltároló és a felügyeleti felületek közös hálózatban vannak. A peremtűzfal ugyan korlátozza a bejövő kapcsolatokat, belül azonban széles engedélyek vagy elégtelen elkülönítés érvényesül. A webszerver ezért több rendszert érhet el, mint amennyit a feladata megkövetel.
A közösen használt rendszergazdai fiók tovább rontja a helyzetet. Ugyanez igaz az írási joggal csatolt mentési könyvtárra vagy az alkalmazás könyvtárában tárolt, széles hozzáférést adó hitelesítő adatokra. A működő mentés keveset ér, ha a feltört szolgáltatás a mentés felügyeletét vagy az összes mentési példányt is módosíthatja.
„B” hálózat: a zónák és a szabályok korlátozzák a kapcsolatokat
A második kialakításban az internetes kérések először egy meghatározott frontendhez vagy fordított proxyhoz érkeznek. Ez érheti el a szükséges alkalmazást egy külön webes szegmensben. Az alkalmazás csak a nélkülözhetetlen kapcsolatot kapja meg egy konkrét adatbázis-célhoz. A felügyelet, a mentési rendszerek és más belső szolgáltatások elkülönített zónákban vannak; a webes szegmens felől a szükségtelen hozzáférések tiltottak.
A VLAN logikailag tagolja a hálózatot. A kapcsolatok ellenőrzése dönti el, hogy ebből hatékony biztonsági határ lesz-e. A túl megengedő VLAN-ok közötti útválasztás az elkülönített hálózatokat újra nagyrészt összeköti. Egy VLAN-on belül is szükség lehet az egyes munkaterhelések közötti további szűrésre.
Az OPNsense vagy a Sophos Firewall alkalmas platform lehet a megfelelő szabályokhoz, más megfelelő termékek mellett. A konkrét források, célok, szolgáltatások, felelősségek és az ellenőrzött megvalósítás számítanak. A kezelés és az elérhető funkciók platformonként eltérnek. Egy terméknév önmagában nem ír le kipróbált biztonsági architektúrát.
A fordított proxy és a WAF továbbra is a védelem része
A fordított proxy összefoghatja a nyilvános hozzáféréseket, kezelheti a TLS-kapcsolatokat, és a kéréseket kijelölt backendekhez továbbíthatja. A HAProxy ehhez többek között HTTP- és TCP-üzemmódot támogat. Ez nem jelent általános proxyfunkciót tetszőleges protokollokhoz. Az elé helyezett webalkalmazás-tűzfal, vagyis WAF bizonyos kártékony webes kéréseket felismerhet és elutasíthat.
Ezek az összetevők nem helyettesítik a biztonságos alkalmazásokat, az időben telepített frissítéseket és a korlátozott backend-hozzáférést. Hibás szabályok vagy egy másik elérhető belépési pont megkerülhetővé tehetik a védelmet. Ezért a példában a proxy mögött feltört alkalmazás is csak a kifejezetten szükséges célokat érheti el.
A kimenő és a belső forgalomra is figyelni kell
A döntő kérdés nem csupán az, hogy ki kapcsolódhat a webszerverhez. Hová kezdeményezhet kapcsolatot maga a szerver? Elérheti a NAS felügyeleti felületét? Szüksége van tetszőleges internetes célok elérésére? Milyen belső szolgáltatások kellenek valóban a többi konténernek?
A kimenő forgalom, azaz az egress tervezésébe a névfeloldás, az időszinkronizálás, a frissítések és a külső interfészek is beletartoznak. A szükséges célokat célzottan kell engedélyezni. A belső rendszerek közötti, gyakran kelet–nyugati forgalomnak nevezett kommunikációhoz is egyértelmű szabályok kellenek. Az IPv6-nak és az alternatív útvonalaknak ugyanazt a tervezett elkülönítést kell betartaniuk.
A kapcsolati terv rögzíti a forrást, a célt, a szükséges szolgáltatást, a rendeltetést és a felelőst. Ezután ellenőrzött körülmények között tesztelni kell az engedélyezett és a tiltott útvonalakat. A naplózásnak és a monitorozásnak a váratlan sikeres kapcsolatokat és a gyanús blokkolt próbálkozásokat is láthatóvá kell tennie. Az igazolt hatás nélküli szabály még nem megbízható bizonyíték.
A virtuális gépekhez és konténerekhez megfelelő határok kellenek
A virtuális gépnek saját vendég operációs rendszere van; a konténerek jellemzően a gazdagép kernelét használják közösen. Mindkét modellhez megfelelő hálózati és jogosultsági beállítások szükségesek. A Proxmox VE gazdagépekhez és vendégrendszerekhez is kínál tűzfalszabályokat. A ténylegesen működő szintek és funkciók a tűzfal backendjétől és a valóban bekapcsolt lehetőségektől is függenek.
Docker esetén az azonos bridge-hálózaton lévő konténerek kommunikálhatnak egymással. A kimenő kapcsolatok nem korlátozódnak automatikusan nyilvános célokra. A közzétett portok további belépési pontokat hozhatnak létre. Host hálózati módban a konténerek a gazdagép hálózati névterét osztják meg; itt nincs önálló hálózati izoláció.
A többletjogok, a gazdagép feleslegesen csatolt könyvtárai és a Docker-sockethez való hozzáférés jelentősen kiterjeszthetik egy incidens következményeit. Az elkülönített alkalmazáshálózatokat, a minimális jogosultságokat, a megfelelő gazdagéptűzfal-szabályokat és az ellenőrzött DNS- és egress-útvonalakat ezért együtt kell megtervezni. Itt is a ténylegesen működő konfiguráció dönt.
Áttekinthető kezdés kisebb vállalkozásoknak
- Szolgáltatások felmérése: dokumentálni kell a nyilvános alkalmazásokat, függőségeket és felelősöket.
- Zónák meghatározása: a nyilvános munkaterheléseket, adatokat, felügyeletet és mentéseket védelmi igény szerint kell elkülöníteni.
- Kapcsolatok indoklása: csak meghatározott források, célok és szolgáltatások maradjanak engedélyezve; a többit ott kell tiltani, ahol ez üzemeltetési szempontból megfelelő.
- Felügyelet védelme: megbízható hozzáférési útvonalak, megfelelő VPN- és MFA-megoldások, valamint külön fiókok szükségesek.
- Üzemeltetés bevonása: tervezni kell a frissítéseket, központi naplókat, riasztásokat és függetlenül védett mentéseket, kipróbált helyreállítással.
- Hatás igazolása: rendszeresen felül kell vizsgálni a szabályokat, időben korlátozni a kivételeket, és változtatás után újra tesztelni.
A módosításokhoz előkészítés, megfelelő karbantartási időablak és visszaállítási lehetőség kell. Egy általános tiltás jogos alkalmazásokat vagy a saját felügyeleti hozzáférést is megszakíthatja. Először a függőségeket kell felmérni, majd ellenőrzött átállás után a felelősökkel együtt igazolni az üzleti működést.
Egy alkalmazás feltörése nem feltétlenül rántja magával a hálózatot
A PHP2Shell-cikkek a PHP sérülékenységeire adott válaszról és az AI támogatásával végzett felmérésről adják az aktuális kiindulópontot. A NAS, a Docker és a nyilvános szolgáltatások kiegészítő ellenőrzése tartós architekturális kérdéshez vezet: mely kapcsolatokra és jogokra van valóban szüksége az adott szolgáltatásnak?
A DAXS a felmérésben, a kommunikációs tervben, a megvalósításban és az ellenőrizhető üzemeltetésben segít. Akár helyben, akár privát felhőben, akár nyilvános felhőplatformon fut az alkalmazás, a védelmi határoknak a tényleges igényhez kell igazodniuk. Beszéljük át az Ön konkrét környezetét.
Források: OPNsense: szabályok és állapottartó szűrés · Sophos Firewall: zónák, szabályok és naplózás · HAProxy: HTTP- és TCP-üzemmódok · Docker: bridge-hálózatok · Docker: host hálózati mód · Docker: daemon, jogosultságok és biztonsági határok · Proxmox VE: tűzfaldokumentáció · NCSC: a továbbterjedés korlátozása, a felügyelet és a mentések védelme.
