Active Directory replikáció tűzfalon keresztül

Cikkünkhöz mellékletünk egy RPC.REG állományt, amit futtatva, a 49152-es portra korlátozza a replikációs RPC forgalmat. Újraindítás szükséges.

Először járjuk egy kicsit körül az Active Directory replikáció adatátviteli megoldásait. Két alapvető átviteli típust különböztetünk meg a tartományvezérlők között: a távoli eljáráshívást (Remote Procedure Call = RPC) és a Simple Mail Transfer Protocol-t (SMTP). Utóbbi a séma és a globális katalógus átvitelében vesz részt, de kimarad a névtér egyéb adatforgalmából. Mivel szabványos levélküldési protokollként terjedt el világszerte a hálózati eszközök - többek között a tűzfalak - fel vannak készítve a fogadására. De mi a helyzet a dinamikus RPC-vel? Olyannyira beépült az operációs rendszerbe, hogy nélküle nem is működik. Próbáljuk meg leállítani a szolgáltatások között, azonnal kapunk egy hibaüzenetet és leáll a számítógép. Tehát nem csak tűzfalra, de az RPC-re is szükség van. Probléma, hogy nem minden tűzfal "szereti", sőt egyenesen tiltja az ilyen irányú forgalmat. Három alapelvet szokás a tűzfal konfigurációban alkalmazni, ha replikációs adatokat is át kell engedni:

Mindhárom módszernek vannak előnyei és hátrányai. Nem igényel tartományvezérlő konfigurálást az első módszer, ami pozitív. Ellenben átjárhatóvá válik a tűzfal és ezáltal jelentősen csökken a biztonság, persze még így is jobb, mint ha egyáltalán nem lenne, de csökken az eredeti szerepe. Említettük a dinamikus RPC kifejezést, de vajon mit jelent? Egy önkonfiguráló mechanizmust, amely UUID azonosítókat jegyez be a regisztrációs adatbázisba. UUID = Universal Unique Identifier (~ univerzálisan egyedi azonosító). Az előállító algoritmus garantálja, hogy az egész világon nem lehet két egyforma UUID. Amikor elindul az RPC szolgáltatás véletlenszerűen foglal magának magas portokat (high ports) és hozzácsatolja az UUID-hez. Bár legközelebbi alkalommal ismét megpróbálja ugyanazokat a portokat lefoglalni, mint az első alkalommal, ha nem sikerül áttér másikra. A klienseknek perszer fogalmuk sincs, hogy végül is melyikeken lehet kommunikálni a kiszolgálóval. Áthidaló megoldásként a 135-ös porton keresztül csatlakoznak a Portmapper szolgáltatáshoz és lekérik a szükséges információkat. Ilyen feltételek mellett nehéz tűzfalat konfigurálni. Mely portokat kell nyitva hagyni a dinamikus RPC átengedéséhez? Attól függ milyen szolgáltatások vannak használatban. Iránymutatásul nézzük meg az alábbi táblázatot:

Látható, hogy nem kevésről van szó. És ráadásul nagy része nincs is használva, de nem tudható előre, hogy melyikek. Ez az oka a biztonság jelentős csökkenésének.

Jó lenne valahogy korlátozni az RPC-t, ami nem lehetetlen. Megoldható, hogy a teljes forgalom egyetlen porton keresztül haladjon. Előnye, hogy jelentősen növekszik a biztonság. Hátránya, hogy az összes tartományvezérlő regisztrációs adatbázisát módosítani kell. Be kell tartani bizonyos szabályokat, ha az Internet jelenti két tartományvezérlő között az átviteli közeget. Nem választhatunk teljesen szabadon portot, az Internet Assigned Numbers Authority (IANA) szervezet kimondja, hogy csak 49152-65535 közötti értékek használhatók erre a célra. Módosítsuk az összes tartományvezérlő beállítását az alábbiak szerint:

Indítsuk el a REGEDIT.EXE segédprogramot és tallózzunk el a registry következő kulcsához:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Szolgáltatáss\NTDS\Parameters]

Hozzunk létre egy új duplaszó (REG_DWORD) bejegyzés "TCP/IP Port" néven. Értéknek írjuk be a 49152-65535 közötti számok valamelyikét. Vigyázzunk a szerkesztésnél, mert alapértelmezésben hexadecimális számot vár a REGEDIT. Exportáljuk a kulcsot egy .REG állományba és vigyük át a többi tartományvezérlőre (cikkünk mellékletében található egy minta állomány, amely 49152-es értéket állít be). Újra kell indítani a számítógépeket a változtatás érvényesítéséhez. Ennek megfelelően a következő táblázatban található portokat kell nyitva hagyni a tűzfalon:

Immár jelentősen szűkült a lehetőségek száma.

Térjünk át a harmadik megoldásra az IP Security (~IP biztonság) alkalmazására. Biztonsági szempontból mindenképpen ez jelenti a legjobb megoldást. A teljes adatforgalom titkosított IP csomagokba ágyazódik, megfelelő védelemmel ellátva és így továbbítódik a hálózaton keresztül. Védve van az útközben előforduló estleges lehallgatások és módosítások ellen. Háttérben a kerberos protokoll adja mindehhez a biztosítékot. Mind a küldőnek, mind a fogadónak hitelesítenie kell magát, ami tovább növeli a biztonságot. Hátrányaként megemlíthető, hogy ismét konfigurálni kell az összes tartományvezérlőt, továbbá figyelembe kell venni, hogy a kerberos megköveteli a felektől, hogy ugyanabban a tartományban legyenek. Utóbbi inkább csak elméleti probléma. Nem elméleti viszont, hogy IP Security mellett nem lehet hálózati címfordítást (Network Address Translation = NAT) használni, mert az IP címekből képzett ellenőrző összeg beépül a csomagba. A biztonságot tetézni lehet még egy VPN (Virtual Private Networking = virtuális magánhálózat) kapcsolattal PPTP (Point-to-Point Protocol) protokollal.

Fentiek használata esetén a következő portokat kell nyitva tartani a tűzfalon:

Megjegyzés: Az IP Security és VPN kapcsolatok kialakításáról szóló cikkeink a hivatkozásokban találhatók.