A DMZ kifejezés meghatározás nélkül érkezik. Egy tétel egy biztonsági átvizsgálási listán, egy mondat egy gyártó megerősítési dokumentumában, egy követelmény egy álláshirdetésben, közvetlenül a TLS és a legkisebb jogosultság mellett.
Utánanézel, és egy tűzfal ábráját találod három hálózati kábellel. Az egyik az internetre megy, a másik egy sor szerverhez, a harmadik egy irodai LAN-ba. Te viszont egyetlen bérelt szervert üzemeltetsz, egyetlen nyilvános IP-vel és egyetlen tartalék hálózati interfész nélkül.
Az első kép egy valódi DMZ-architektúra. Egyetlen szerveren a biztonsági céljának egy részét reprodukálni tudod: korlátozni, hogy az internet meddig ér el. Amit ugyanazon a gépen nem tudsz reprodukálni, az a különálló hálózati határ, amitől egy DMZ egyáltalán DMZ lesz.
A rövid verzió
- A DMZ elválasztja azokat a szolgáltatásokat, amelyeket idegeneknek el kell érniük, mindattól, amit egyébként üzemeltetsz.
- Sosem a kábelezésről szólt: arról szólt, hogy a nyilvános oldalon bekövetkező kompromittálódás ott meg is álljon.
- Beállíthatsz egy tűzfalat úgy, hogy közben mégsincs DMZ-d.
- Egyetlen szerver egyetlen nyilvános IP-vel csökkentheti a kitettséget fordított proxyval, gazdagépes tűzfalszabályokkal és privát vagy loopback kötésekkel, de nem hoz létre külön DMZ-szegmenst.
- Ez a változat közös kernelen osztozik azzal, amit véd, ezért csökkentett kitettségként számold, ne elszigetelésként.
Amit ez a cikk nem tárgyal
A tárgykör itt a gondolati modell, és három szomszédos témát szándékosan érintetlenül hagyunk.
- Nincsenek megvalósítási lépések. Nem szerepel itt fordított proxy konfiguráció, tűzfalszabály-szintaxis, sem ajánlás arra, melyik eszközt telepítsd.
- Nincs otthoni router beállítás. Egy otthoni router "DMZ host" kapcsolója egészen mást jelöl.
- Nincs ítélet a zero trustról. Hogy a hálózati perem még mindig a helyes elsődleges védelmi eszköz-e, valódi vita, és itt nem dől el.
Mi az a DMZ, és mire való?
A DMZ, vagyis demilitarizált zóna, egy hálózati szegmens a nem megbízható internet és egy belső hálózat között. Azokat a szolgáltatásokat tartalmazza, amelyeknek nyilvánosan elérhetőnek kell lenniük, például a web- és levelezőszervereket. Minden más egy második határ mögött marad, így a nyilvános szolgáltatás elérése nem jelenti a többi elérését.
A Mozilla DMZ-ről szóló szójegyzék-szócikke egyetlen tagmondatban foglalja össze ennek a lényegi felét: csak bizonyos meghatározott végpontokat tesz elérhetővé, miközben kívülről megtagadja a hozzáférést a belső hálózathoz. Ez a teljes tervezési cél, bármilyen eszközre való hivatkozás nélkül megfogalmazva.
A klasszikusan ott lakó szolgáltatástípusok magából a célból következnek. Webszerverek, levelezőszerverek, FTP-szerverek, VoIP-szerverek: olyasmi, amihez idegeneknek csatlakozniuk kell tudni. A címtárszerverek, adatbázisok, fájlmegosztások, belső alkalmazások és adminisztrációs felületek nincsenek ezen a listán, mert kívülről senkinek sem szabadna elérnie őket.
A tulajdonságot tartsd meg, ne a képet. A három hálózati interfész csak az egyik módja annak, hogy külön bizalmi határt hozz létre. A felhőalapú és az egyszerveres megoldások ugyanazt a kitettség-korlátozási elvet másképp is alkalmazhatják, de magát a DMZ-t csak azok a megoldások reprodukálják, amelyekben van külön peremzóna.
Hogyan működik a klasszikus, három interfészes DMZ?
A klasszikus DMZ kétféleképpen épül fel. Az egytűzfalas kialakítás egyetlen tűzfalnak ad három interfészt: egyet az internet, egyet a DMZ, egyet a belső hálózat felé. A kéttűzfalas kialakítás a DMZ-t két különálló tűzfal közé helyezi. Mindkettő ugyanazt a szabályt érvényesíti. Az internet elér a DMZ-ig. Az internet soha nem ér el a belső hálózatig.
Az egytűzfalas (háromlábú) modell
Egy tűzfal, három hálózati interfész. Az első az internet felé néz. A második a DMZ felé, ahol a nyilvános szolgáltatások laknak. A harmadik a belső hálózat felé. A tűzfal átengedi az internetről a DMZ meghatározott portjaira érkező forgalmat, átengedi a DMZ-ből befelé menő szűk forgalmat ott, ahol egy alkalmazás megköveteli, és minden mást megtagad.
Ennek az alaknak a neve háromlábú tűzfal. Minden zónák között átkelő csomag egyetlen eszközön halad át, ami azt a tűzfalat a zónaközi forgalom egyedüli meghibásodási pontjává teszi. Ha kiesik, a kapcsolat és a szabályok érvényesítése a tűzfal hibaviselkedésétől és az általad kiépített redundanciától függően sérül.
Egy évtizedet töltöttem hálózatüzemeltetéssel egy internetszolgáltatónál, és a DMZ-interfészben az lepte meg az embereket, mennyire nincs benne semmi különös. Egy hétköznapi ethernet-port, amelyhez a tűzfal konfigurációjában más bizalmi címke tartozott. Az architektúra nem a rézben volt. A szabálykészletben volt, és abban, hogy valaki alaposan végiggondolta, melyik irányba engedélyezett minden egyes forgalom.
A kéttűzfalas (háttal egymásnak) modell
Két tűzfal sorba kapcsolva, közöttük a DMZ-vel. A külső tűzfal beengedi az internetforgalmat a DMZ-be, tovább nem. A belső csak azt a konkrét, DMZ-ből befelé menő forgalmat engedi át, amelyre egy alkalmazásnak szüksége van. A DMZ-ig eljutó támadónak még mindig át kell kelnie a belső tűzfal szabályhatárán, mielőtt elérné a belső hálózatot.
Két tűzfal két külön érvényesített szabályhatárt ad, de egyben konfigurációt, javítgatást és üzemeltetési bonyolultságot is hoz. A külső határ meghibásodása vagy kompromittálódása nem szünteti meg automatikusan a belsőt, bár a védelem továbbra is azon múlik, hogyan van beállítva és kezelve a két tűzfal.
Ugyanaz a DMZ, mint a tűzfal?
Nem. A DMZ egy különálló peremhálózat vagy hálózati szegmens. A tűzfal egy elterjedt védelmi eszköz, amellyel az adott zóna, az internet és a belső hálózat közötti forgalmat szabályozzák. Tűzfalszabályokat lapos hálózaton is beállíthatsz anélkül, hogy DMZ-t hoznál létre, tehát a különbség architekturális, nem pusztán konfigurációs kérdés.
A keveredés érthető. A tűzfal az a tárgy, amelyre belépsz, az a dolog, amelynek konfigurációs fájlja, gyártója és támogatási szerződése van, ezért magához gyűjti annak a nevét is, amit előállít. Egy szegmensbe viszont soha senki nem lép be.
A következmény a lehető legrosszabb pillanatban jelentkezik. Tételezd fel, hogy a nyilvános webszervered kompromittálódott, mert előbb-utóbb így lesz. Lapos hálózaton a támadónak most már van egy hídfője egy olyan gépen, amely eleve beszélhet az adatbázisoddal, a fájlszervereddel és az adminisztrációs felületeiddel, a köztük való mozgás pedig csupán egy már engedélyezett hozzáférés használata. Ezt az oldalirányú vándorlást hívják laterális mozgásnak, és a második határ pontosan ennek a megállítására létezik. A DMZ nem akadályozza meg, hogy a webszervert feltörjék. Azt akadályozza meg, hogy egy feltört webszerverből minden máshoz vezető hozzáférés legyen.
Egy pontosítás, amíg a fogalom itt van előttünk: az otthoni vagy kisirodai router "DMZ host" beállítása másik funkció. A kéretlen bejövő forgalmat továbbítja egyetlen belső eszközre, azt közvetlenül kitéve az internetnek; különálló, védett DMZ-hálózatot nem hoz létre.
Hogyan alkalmazd a DMZ elveit egyetlen szerveren?
Egyetlen szerver egyetlen nyilvános IP-vel reprodukálni tudja a DMZ kitettség-korlátozási céljának egy részét, anélkül hogy a hálózati elkülönítését is reprodukálná. Egy fordított proxy lehet az egyetlen nyilvános belépési pont, az alapértelmezetten tiltó bejövő tűzfalszabályok kizárhatják a többit, a belső szolgáltatások pedig a nyilvános cím helyett loopbacken vagy privát interfészen figyelhetnek.
Indulj ki abból a megkötésből, amelyet ez a szakasz feltételez: egy VPS, egy nyilvános interfész, és nincs külön tűzfaleszköz és nincs általad felügyelt DMZ-alhálózat. Ilyen felállásban a klasszikus háromlábú topológiát nem tudod ugyanazon a gépen reprodukálni. A gazdagépes tűzfalszabályok, a szolgáltatások figyelési címének megválasztása és egy fordított proxy továbbra is csökkentheti a kitettséget, de ugyanazt az elszigetelési határt nem hozza létre.
Egy fordított proxy elfoglalhatja a nyilvános interfészt a következő portokon: 80 és 443 és a webes forgalom egyetlen alkalmazásszintű belépési pontja lehet. Ez szűkíti a nyilvános támadási felületet, de nem egyenértékű egy különálló DMZ-interfésszel, mert a proxy továbbra is ugyanazon a gépen osztozik a mögötte lévő szolgáltatásokkal.
A gazdagép bejövő tűzfalszabályai átengedik ezt a két portot, a többit eldobják. A gépen bármelyik másik szolgáltatás futhat és figyelhet, de kívülről semmi nem tud hozzá kapcsolatot kezdeményezni. Ez egyetlen gépen közelíti a „csak a szándékolt portok érhetők el” elvet; a belső hálózattal szemben külön határt nem hoz létre.
Az alkalmazásszerverek, adatbázisok és admin felületek ne a nyilvános címen figyeljenek. Ha a proxy ugyanazon a gépen fut, figyelhetnek loopbacken; ha máshol fut a privát hálózaton, figyelhetnek privát címen. Mindkét esetben a nyilvános interfészen nincs figyelő ezekhez a szolgáltatásokhoz, így egy bejövő szabály megnyitása pusztán azon az interfészen nem teszi őket elérhetővé.
Az adminisztratív hozzáférés a belső oldalra tartozik, nem a DMZ-oldalra. Ha az SSH-t és a felügyeleti felületeket kiveszed a nyilvános útvonalból, VPN vagy privát hálózat mögé, azzal megelőzöd a nyilvános internetről indított közvetlen kapcsolatokat.
Hogyan feleltethetők meg a DMZ fogalmai a VPC-alhálózatoknak és a biztonsági csoportoknak?
A klasszikus modell fogalmilag elég szorosan megfeleltethető a felhőbeli hálózati alapelemeknek, de nem egy az egyben. Egy DMZ-szegmensből nyilvános alhálózat lesz. A belső hálózatból privát alhálózat lesz, internetátjáró felé vezető útvonal nélkül. A tűzfal szabálykészlete pedig szétoszlik a biztonsági csoportok között, amelyek az erőforrások hálózati interfészeihez kapcsolódnak, és a hálózati ACL-ek között, amelyek az alhálózatokhoz.
| Klasszikus elem | Felhőbeli megfelelő | Mit érvényesít |
|---|---|---|
| DMZ-szegmens | Nyilvános alhálózat | Internetes útvonalat biztosít; az erőforrásnak ezen felül nyilvános címre és a forgalmat engedélyező biztonsági szabályokra is szüksége van |
| Belső hálózati szegmens | Privát alhálózat | Nincs közvetlen útvonal az internetátjáróhoz, így az internet ezen az úton nem tud közvetlen kapcsolatot kezdeményezni |
| Zónák közötti tűzfalinterfész | Útválasztó tábla + internetátjáró csatolása | Hová irányítható a forgalom; azt, hogy egy erőforrás elérhető-e, továbbra is a nyilvános címzés és a biztonsági vezérlők döntik el |
| Tűzfal-szabálykészlet (zónánként) | Hálózati ACL-ek | Állapotmentes engedélyező és tiltó szabályok, az alhálózat szélén kiértékelve |
| Tűzfal-szabálykészlet (gazdagépenként) | Biztonsági csoportok | Állapottartó engedélyező szabályok, a hozzájuk rendelt erőforrások hálózati interfészeire alkalmazva |
| Nyilvánosan elérhető szolgáltatás a DMZ-ben | Terheléselosztó vagy proxypéldány a nyilvános alhálózatban | Az egyetlen belépési pont, amelyen a forgalomnak át kell haladnia |
A felhőszolgáltatók maguk is használják ezt a szókincset, ami jó bizonyíték arra, hogy a fogalom máig eleven. Az AWS hálózati blogja ezt írja le: egy Amazon VPC-re épülő DMZ-architektúrát amely elkülöníti a nyilvánosan elérhető szolgáltatásokat a belső hálózatoktól, és a VPC Block Public Accessre épül, egy 2024 novemberében bevezetett, Régió szintű védelmi eszközre.
Ennek a megfeleltetésnek a teherhordó része az alhálózat. Egy nyilvános alhálózat attól nyilvános, hogy az útválasztó táblája egy internetátjáróra mutat. Mivel az útválasztó táblák döntik el, merre utaznak a csomagok, az alhálózatok elrendezése bármelyik egyedi szabály előtt formálja a kitettségedet.
A megfeleltetés egyetlen konkrét ponton tökéletlen. Egy tűzfalinterfész egy egész szegmensre nézve érvényesített határt; egy biztonsági csoport viszont egy erőforrás hálózati interfészéhez kapcsolódik. Ugyanabban a privát alhálózatban két gép teljesen eltérő biztonsági csoportokat viselhet, így az érvényesítés finomabb bontásban történik, mint amit egy fizikai interfész valaha elért. Ez rendszerint előrelépés. Egyben azt is jelenti, hogy egy alhálózat neve kevesebbet árul el arról, mi érhető el, mint amennyit régen egy hálózati ábra elárult.
Hol marad alul az egyszerveres változat
Egyetlen gépen a nyilvánosan kitett folyamat és a belső szolgáltatások közös kernelen és közös gépen osztoznak. A különálló szegmensek átkényszerítik a támadót egy hálózati határon, amelyet egy tűzfal vizsgál; egyetlen gép nem. Az egyszerveres minta csökkenti a kitettséget. Az elkülönítést nem reprodukálja.
Ha a fordított proxyt úgy törik fel, hogy a támadó kódfuttatást szerez, az a kód már azon a gépen fut, amelyen az adatbázisod is. A loopbackre kötés ilyenkor nem segít, mert a loopback a gazdagépről elérhető. A konténeres vagy felhasználói elszigetelés megemelheti a szükséges ráfordítást, de az azonos gépen futó konténerek továbbra is osztoznak a gép kernelén. A klasszikus modellben a támadó következő lépése egy csomag volt egy vezetéken, amit valami megvizsgált. Itt egy helyi socket.
A gyakorlati következmény egy küszöb, nem ítélet. Amikor az, ami a proxy mögött áll, többet ér, mint egy második gép ráfordítása, használj két gépet és köztük egy privát hálózatot. Ehhez ebből a cikkből semmit sem kell újratanulni, mert egyik része sem szólt soha a hardverről.
Építkezz Linux VPS-en root hozzáféréssel, NVMe-vel és AMD EPYC teljesítménnyel.
Linux csomagok megtekintéseA perem már nem az egyetlen hely, ahol biztonsági szabályokat lehet érvényesíteni. A zero trust architektúra megszünteti a hálózati elhelyezkedésen alapuló hallgatólagos bizalmat, a következővel épített privát összeköttetés pedig WireGuard vagy Tailscale csökkentheti a nyilvános kitettséget. Egyik megközelítés sem váltja ki automatikusan a szegmentálást vagy az engedélyezést. A szűkebb kérdésben az álláspontom egyértelmű. Gondolati modellként: válaszd szét azt, ami elérhető, attól, ami nem, és tudd, melyik határ tartja bent a kompromittálódást. Ez a kérdés túléli a fent említett összes architektúrát, és épp ezért érdemes ma is megválaszolni.
Gyakran ismételt kérdések
Ugyanaz a DMZ, mint a VPN?
Nem. Különböző problémákat oldanak meg. A DMZ azt szabályozza, mit érhetnek el a nem megbízható kívülállók, azzal, hogy csak egy szűk szolgáltatáskört tesz elérhetővé, mást semmit. A VPN a megbízható kívülállóknak ad privát utat befelé, hitelesítve őket egy olyan hálózatra, amelyet egyébként nem érnének el. Sok hálózat mindkettőt üzemelteti, és egyik sem helyettesíti a másikat.
Biztonságos a DMZ?
A DMZ nem teszi biztonságossá a kitett szolgáltatást. Azt korlátozza, meddig ér el annak kompromittálódása. A nyilvánosan elérhető szolgáltatás továbbra is nyilvánosan elérhető, továbbra is ki van téve az egész internetnek, és továbbra is a maga jogán igényel javításokat, felügyeletet és megerősítést. A DMZ arról dönt, mi történik azután, hogy elesik, nem arról, hogy elesik-e.
Kell DMZ, ha csak egy szerverem van?
A klasszikus értelemben nem, és egyetlen gépen amúgy sem tudnál építeni ilyet. A három interfészes topológia külön hálózati szegmenseket igényel, egy szervernek egyetlen nyilvános IP-vel pedig egy sincs. Amit tehetsz, az a kitettség kézben tartása: legyen egy fordított proxy az egyetlen nyilvános belépési pont, a többi bejövő portot alapból tiltsd, a belső szolgáltatások pedig loopbacken vagy privát címen figyeljenek. Ez csökkenti, meddig ér el az internet, de nem szigeteli el a nyilvános szolgáltatást a gép többi részétől. Amikor az, ami a proxy mögött áll, többet ér egy második gép áránál, használj két gépet és köztük egy privát hálózatot.
Miért hívják demilitarizált zónának?
A kifejezés a katonai jelentésből származik: ütközőterület két szemben álló erő között, ahol egyik sem uralja teljesen. A hálózati használat megőrzi a képet: a DMZ sem a nem megbízható külvilághoz, sem a megbízható belsőhöz nem tartozik egészen.

Beszélgetés
Hozzászólások
Jelentkezzen be a beszélgetéshez.