Segédlet a BorderManager Enterprise Edition 3.5 alkalmazásához Scott Jones – Novell Consulting
Bevezető A BorderManager Enterprise Edition (BMEE) egy szoftvercsomag, amelynek célja, hogy javítsa és bővítse az NDS és a NetWare biztonsági és kapcsolati szolgáltatásait. A BMEE az alábbi szolgáltatásokkal bővíti a NetWare-t: • WAN-médiák kezelése • Emelt szintű csomagszűrés • Hálózati címfordítás (Network Address Translation, NAT) – a patchelt NetWare 5-ben már benne van; • Virtuális magánhálózatok (VPN) kezelése, telephelyek közötti és kliens-telephely típusúaké egyaránt • Távoli hozzáférés (RADIUS-szal) és modemmegosztás • IP-átjárók – IPX/IP és IP/IP áramköri átjárók (circuit gateway) • Különféle proxyszolgáltatások, többek között láthatatlan HTTP-proxy • Különféle cache-szolgáltatások, mindkét irányúak • Hozzáférés-vezérlés • Tartalomszűrés A jelen dokumentum a BMEE 3.5-ös verzióját tárgyalja. Javalatot tesz a szerverek elhelyezésére és konfigurációjára, valamint néhány megjegyzést ejt a BorderManager telepítéséről és a szokásos szolgáltatások konfigurációjáról. Habár a BMEE egyes komponensei kezelik az IPX/SPX-protokollokat is, az alábbiakban csak TCP/IP-ről lesz szó.
A szerverek elhelyezése és konfigurációja Fizikai és logikai elhelyezés A BorderManager-szerverek a fizikai és logikai hálózaton való elhelyezése a legfontosabb tervezési szempont. Ez határozza meg, hogy a kitűzött célok hogyan valósíthatók meg (ha egyáltalán). A helyes elhelyezés kialakításához pontosan ismerni kell a hálózati infrastruktúrát. Ahhoz, hogy tűzfalként szolgáljon, a BMEE-szervernek legalább két hálózat interfésszel kell rendelkeznie, és a hálózatok közötti átjáróként működnie (ld. 1. ábra). Előfordulhat azonban is, hogy egy BMEE-szervernek csak egy fizikai csatolója van. Az ilyen, végponti elhelyezés megfelelő lehet például a RADIUS- vagy VPN-szerverek számára, ha nem használunk tűzfalszolgáltatásokat. Még a proxy/cache-szolgáltatások is működtethetők egy végponti szerveren, bár ez esetben a felhasználók egyszerű módon megkerülhetik a proxyt.
1. ábra: BMEE-szerver, mint átjáró, tűzfalként alkalmazva
Tűzfal- vagy hierarchikus cache-szolgáltatások tervezését a legfelső ponton kezdjük. Ez jellemzően az elsődleges kapcsolat az Internet felé. Az eszköz, amely a csatlakozást biztosítja, lehet akár egy BMEE-szerver, akár egy külső útválasztó. Akármelyik is, az első BMEE-szervernek rendelkeznie kell egy olyan interfésszel, amelynek legalább egy bejegyzett nyilvános IP-címe van (célszerű ezt a kártyát PUBLIC névre keresztelni). Ha a szerver statikus címfordítást (NAT-ot) végez, akkor egynél több nyilvános címre is szükség lehet. Alakítsunk ki elegendően nagy alhálózatot ahhoz, hogy bőségesen megfeleljen a hálózat előrelátható igényeinek. Ha az Internet-szolgáltató számozatlan vagy nem útirányított (unrouted) kapcsolatot biztosít, akkor szükség lesz egy külső útválasztóra is, mint az első BMEE-szerverrel együtt a kapcsolódást biztosító eszközre. A 2. ábra e konfigurációra mutat példát..
2. ábra: BMEE-szerver nem útirányított ISP-kapcsolat esetén
Távoli telephelyeken pénz takarítható meg, ha a BMEE-szerver biztosítja a kapcsolatot. A BorderManager kezeli a legtöbb WAN-médiát, így a bérelt vonalakat, a Frame Relay-t, az ISDN-t és az ATM-et. A szolgáltatók azonban a legtöbb esetben adnak egy útválasztót, akár kell, akár nem, így feleslegben maradhat egy eszköz a szerver mellett. Ha az ISP a nyilvános hálózatot elérhetővé teszi a közte és az ügyfél közötti vonalon, akkor ezt az extra útválasztót lehet transzparens bridge-ként használni. Megjegyzés: A rendszer kezeli a behívásos kapcsolatokat is, de ezek hasznáalta nem ajánlott. Egy állandó 56/64 vagy T1/E1 kapcsolat a legstabilabb és a legegyszerűbben konfigurálható. Nagyobb szervezeteknél előfordulhatnak olyan komplex igények, amelyek megkövetelik, hogy a BMEE-szolgáltatások több szerverre való elosztását és egy ún. „demilitarizált zóna” (DMZ) kialakítását. Tegyük fel például, hogy több száz felhasználó számára kívánunk NAT- és VPN-szolgáltatásokat biztosítani. Mivel mindkettő igen processzorigényes funkció, érdemes külön szervereket alkalmazni. A VPN-szerverek azonban nem tehetők a NAT-eszközök mögé. Ez esetben ugyanis, mivel a NAT új fejlécet tesz a csomagokra, nem lehetséges a SKIP-párbeszéd a VPN-csomópontok között és nem tudják megbeszélni a titkosítás módját sem. A VPN-szervernek tehát a NAT-szervernél „feljebb” kell elhelyezkednie. (Az egyéb típusú tűzfalmegoldások kialakításáról részletesen a BMEE termékdokumentációjában lehet olvasni.) A saját belső hálózaton belül a szokásos infrastruktúra-tervezési elvek érvényesek. Például célszerű a szerverek közötti ugrások számának minimalizálása egy hierarchikus cache-struktúra kialakításával. Ez azt eredményezheti, hogy néhány külső útválasztót el kell távolítani, vagy át kell konfigurálni őket hídnak. Az útválasztó-hardver helyben hagyása tartalék kapcsolatot biztosíthat: ha a BMEE-átjárószerver hosszabb időre kiesne, a régi útválasztó gyorsan átkonfigurálható. Elhelyezés az NDS-fán belül Habár a BorderManager egy szerverközpontú termék, az NDS-t használja a konfiguráció részleteinek tárolására és a a hitelesítéshez. Szinte minden alkalmazásszintű konfiguráció a „Szerver”-objektum segítségével történik. A BMEE „Szerver”-objektumainak a címtárfában való elhelyezése tehát kritikus fontosságú, csakúgy, mint annak eldöntése, hogy a szerverek mely replikákat tartalmazzák. A BorderManager-szervereket lehetőleg a felhasználóihoz közel kell elhelyezni az NDS-címtárfában. Egy helyi iroda esetében például a BMEE-átjárószervert lehetőleg az adott földrajzi hely OU-jába tegyük. A cél, hogy minimálisra csökkentsük a címtárfában való keresgélést és a szerver által igényelt replikák számát. Ha megvalósítható, tegyük az összes felhasználót és szabályt egy helyi replikába (a szabályok elhelyezéséről később még szólunk). Megjegyzések a szerver konfigurációjával kapcsolatban A proxy/cache szerverek finomhangolásakor az alábbi minimális környezeti beállításokra van szükség: set maximum packet receive buffers = 2500 set minimum packet receive buffers = 1000 set new packet receive buffer wait time = .1 sec set maximum interrupt events = 50 set maximum service processes = 1000
set set set set
minimum service processes = 500 new service process wait time = .3 sec worker threads execute in a row count = 15 pseudo preemption count = 200
set set set set
immediate purge of deleted files = on enabled file compression = off enable disk read after write verify = off maximum file locks = 100000
set set set set set set set set set
garbage collection interval = 5 directory cache allocation wait time = 0.1 sec directory cache buffer nonreferenced delay = 60 min maximum number of internal directory handles = 500 maximum directory cache buffers = 10000 minimum directory cache buffers = 2500 maximum concurrent directory cache writes = 125 maximum concurrent disk cache writes = 750 dirty disk cache delay time = .1 sec
E beállítások értelmét a TID #2949807 és a TID #10012765 taglalja (megtalálható a http://support.novell.com címen). Szintén e TID-ek segítenek abban, hogy további hangolás esetén mit érdemes állítani. •
•
•
•
•
Maximum Physical Receive Packet Size. A BMEE online dokumentáció tartalmazza a „Maximum Physical Receive Packet Size” (maximális fizikai fogadási csomagméret) változó javasolt beállításait, és ezek általában helyesen működnek is. Az egyetlen kivétel, hogy ha a szerverben lévő WAN-kártya frame relayhez csatlakozik, akkor a telekommunikációs kapcsoló miatt lehetséges, hogy 1514-nél kisebb értéket kell beállítani. Ha a javasolt beállításokkal nem folyik adat át a WAN-kapcsolaton, akkor a PING.NLM segítségével, a ping-csomag méretének 1514-ről való folyamatos csökkentésével határozzuk meg azt az értéket, amelyeknél már jönnek válaszok, és legyen ez a maximum fizikai fogadási csomagméret. Szintén megoldás a Set Use Specified MTU = On parancs kiadása, de az ronthatja az átviteli teljesítményt. Ha a WAN-kapcsolat Point-to-Point Protocolt (PPP-t) használ – ilyen lehet egy behívásos vonal vagy egy „clear channel” DDS-áramkör –, akkor a maximális fizikai fogadási csomagméretet 10-zel meg kellhet növelni a javasolt értékekhez képest, a PPP-fejléc miatt. Minimális hardverkövetelmények. Az összes BorderManager-szolgáltatás képes egyidejűleg futni meglepően gyenge hardveren. Ha a szerverben van legalább 64MB RAM, akkor képes kiszolgálni egy kisebb csoportot. A cache-funkciók azonban óriási mértékben növekednek több RAM használata esetén; 256 MB vagy több memória javasolt, amennyiben lehetséges. Mivel a titkosítás és a csomagfordítás processzorigényes funkciók, nagy környezetekben (több mint néhány száz felhasználó esetén) a VPN, a NAT és az IP-átjárókat célszerű külön szerverekre tenni. Szerverkötetek. Célszerű külön köteteket készíteni a cache és a naplózás számára, hogy a SYS kötet ne teljen be. A cache hatékonysága javítható 8 vagy 16 kilobájtos blokkok használatával, a tömörítés és a blokk-részallokáció kikapcsolásával. Az NSS-kötetek jól használhatók a cache számára, de további finomhangolásra van szükség (ld. TID #2949807). Statikus útválasztás. Ahol csak lehetséges, használjunk statikus útválasztást a BMEE-szervereken. Ez minimális mértékben terheli meg a szervert és nem növeli az útválasztó útkeresési forgalmát, amely már így is létezhet a hálózaton. Mivel a BMEE-szerverek tipikusan „felfelé irányú” (upstream) átjárók, az egy statikus alapértelmezésű útvonal és a minimális hálózati utak beírása igen egyszerű lehet. A licenceléssel kapcsolatos kérdések. A BorderManager licencrendszere eltér e legtöbb többi Novell-termékétől. A hálózati réteg szolgáltatásaihoz (szűrés, NAT, telephelyek közötti VPN s.í.t.) csupán egy szerverlicencre van szükség. A felhasználói hitelesítést igénylő szolgáltatásokhoz (távoli hozzáférés, tartalomszűrés stb.) felhasználói licencet igényelnek. A felhasználók a szerveren futó BorderManager-alkalmazáshoz hitelesítik magukat, nem pedig a NetWare-hez, így a BorderManager-szervereken általában elég a hozzájuk kapott NetWare-alaplicenc. Az egyes komponensek külön is kaphatók, háromféle csomagban (Firewall Services, VPN Services és Authentication Services), amely a dedikált szerverek használata esetén pénzt takaríthat meg.
A BorderManager telepítése Ha kialakítottuk a szerverek helyét, aBorderManager telepítése már egyszerű. A telepítőprogram az összes komponenst előkészíti a konfiguráláshoz. A telepítés három lépésből áll: • A BorderManager telepítése a szerveren • Az NWAdmin-bővítőmodulok telepítése • A CyberPatrol telepítése (igény esetén) A BorderManager telepítése a szerveren A BMEE 3.5 NetWare 4.11, 4.2, 5.0, 5.1, valamint a Kisvállalati NetWare 4.2, 5.0 vagy 5.1 változataira telepíthető. Az aktuális OS-szervizcsomagokat fel kell telepíteni. Az online dokumentáció minden egyes OS-hez külön telepítési utasításokat tartalmaz. A BorderManager kiterjeszti az NDS sémáját, így a telepítő személynek Supervisor joggal kell rendelkeznie a címtárfa gyökerét illetően. Csakúgy, mint minden egyéb fontos NDS-művelet előtt, ellenőrizzük a címtárfa állapotát, mielőtt a telepítéshez látnánk. Alapértelmezés szerint a BRDCFG.NLM betöltődik, miután a szervert a telepítés végeztével újraindítjuk. A „Secure the Public Interface” (a nyilvános interfész biztosítása) funkcióval bekapcsoljuk a csomagszűrőket az alapértelmezésű szűrőkkel. NetWare 4.x-en alapértelmezés szerint az összes BMEE-szolgáltatás le van tiltva. NetWare 5-ön alapértelmezés szerint a hozzáférés-vezérlés és a HTTP-proxy be vannak kapcsolva, minden más BMEE-szolgáltatás pedig ki. Az NWAdmin-bővítőmodulok telepítése A szervizcsomag telepítése és a szerver újraindítása után futtassuk le a a SYS:PUBLIC¥BRDRMGR¥SNAPINS¥ könyvtárban található SETUP.EXE nevű programot, amely a NetWare Administrator moduljait telepíti. Ha a PKI-modul még nincs fent a szerveren, azt is telepíti, de a SYS:PUBLIC¥ könyvtárba. Onnan kézzel kell átmásolni a PKISNAP.DLL-t a WIN32¥SNAPINS¥ alkönyvtárba. A CyberPatrol telepítése (opcionális) A CyberPatrol egy sor előre elkészített „URL-tiltó” (deny-by-URL) szabály, amely a SYS:ETC¥CPFILTER¥CP_SETUP.EXE futtatásával telepíthető. A BorderManager a CyberPatrol egy 45 napos próbaváltozatát tartalmazza.
A BMEE konfigurációja: a szerverkonzol A BorderManager konfigurációjának nagy része az NWAdminból végezhető el. Az alacsonyabb rétegek konfigurációjának nagy részét azonban a szerverkonzolnál, az INETCFG, FILTCFG és NWCCON segédprogramokkal kell elvégezni. Két további segédprogram – a VPNCFG és a BRDCFG – használatos még, valamint egy NIASCFG nevű átjáró NLM az összes segédprogramhoz. A csomagszűrés és a NAT tipikusan két olyan szolgáltatás, amelyet a szerverkonzolnál kell konfigurálni. A csomagszűrés a legegyszerűbb hálózatihatár-védelmi mechanizmus. A szűrők a hálózati és szállítási rétegekben működnek, és minden más BorderManager-komponens előtt hajtódnak végre. A szűrőket a FILTCFG.NLM-mel konfigurálhatjuk. A dinamikus NAT (vagy az útválasztás nélküli IP-átjáró) egyfajta „természetes” tűzfalat biztosít abban az értelmeben, hogy az Internetről senki nem tud párbeszédet kezdeményezni egy belső csomóponttal. Nem védi ugyanakkor magát a BMEE-szervert, sem a statikus NAT-ra beállított gépeket. A hozzáférési szabályok hiánya esetén e funkciók azt sem tudják korlátozni, hogy a felhasználók milyen forgalmat kezdeményezhetnek. A csomagszűrők képesek kitölteni ezeket a hézagokat. Jellemzően kétfajta hozzáállás van a csomagszűrés (és a hálózati határ védelmének) kialakítása során: az egyik az „engedni mindent és külön tiltani”, illetve a „tiltani mindent és külön engedélyezni”. A BorderManager alapértelmezés szerint az utóbbit alkalmazza. Ha a telepítés során még nem tettük volna meg, az alapértelmezésű szűrők és kivételek a BRDCFG elindításával hozhatók létre. Ez az alábbi tagadó TCP/IP csomagszűrőket hozza létre: Forrás- interfész
Célinterfész
Protokoll ID
Forrásport
Célport
Forráscím
Célcím
Public
Bármi
IP
Mind
Mind
Bármi
Bármi
Bármi
Public
IP
Mind
Mind
Bármi
Bármi
A BRDCFG ezenkívül létrehozza az alábbi szűrési kivételeket is: Forrás- interfész
Célinterfész
Protokoll ID
Forrásport
Célport
Forráscím
Célcím
Public
Bármi
TCP
Mind
443
Bármi
Bármi*
Public
Bármi
TCP
Mind
1024-65535
Bármi
Bármi
Public
Bármi
UDP
Mind
1024-65535
Bármi
Bármi
Public
Bármi
TCP
Mind
213
Bármi
Bármi
Public
Bármi
TCP
Mind
353
Bármi
Bármi
Public
Bármi
UDP
Mind
353
Bármi
Bármi
Public
Bármi
SKIP (57)
Mind
Mind
Bármi
Bármi
Public
Bármi
TCP
Mind
80
Bármi
Bármi
Bármi
Public
IP
Mind
Mind
Bármi
Bármi
* Ez a nyilvános interfész tényleges IP-címe.
Ne feledjük, hogy a BorderManager 3.x képes állapotmegőrző (stateful) szűrésre is. Amennyiben szükséges, az 1024-65536-os dinamikus portokhoz rendelt kivételek törölhetők. Ezután a BorderManager-szerveren és a statikus NAT-tal elért gépeken futó szolgáltatások stateful-szűrői beírhatók. Ez így biztonságosabb konfiguráció, mivel a dinamikus portok blokkolva vannak, kivéve, ha ténylegesen egy párbeszédben vesznek részt. Hálózati címfordítás (Network Address Translation, NAT) A NAT használatával megoldható, hogy a BorderManager-szerver mögött, a szervezet belső hálózatán ún. „magán” ill. bejegyzetlen IP-címeket használjunk. A dinamikus NAT legnagyobb előnye a gyorsan fogyó nyilvános IPv4-címek megőrzése – hisz egyetlen bejegyzett cím képes kiszolgálni privát csomópontok ezreit. Kellemes mellékhatás ezenkívül, amit már említettünk az előző részben, hogy a dinamikus NAT egyfajta természetes tűzfalat hoz létre, amely megakadályozza, hogy a nyilvános Internetről bárki párbeszédet kezdeményezzen egy belső csomóponttal. Ha arra van szükség, hogy egy belső gépet is el lehessen érni az Internetről, akkor egy, a NAT-szerver nyilvános interfészéhez kötött nyilvános címet kell választani számára, azt leképezni az adott gép belső, privát címére. Ezt hívjuk „statikus NAT”-nak. A belső gép védelmére ezután szűrőket tehetünk a nyilvános címre. A nyilvános interfészen működő dinamikus és statikus NAT-ot az INETCFG-ben állíthatjuk be (ld. 3. ábra), a Bindings |
| Expert TCP/IP Bind Options | Network Address Translation pontban. Tetszés szerint választhatjuk a dinamikus és statikus NAT-ot, vagy a kettő kombinációját. Ha csak statikus NAT-ot választunk, de nem töltjük ki a NAT-táblázatot, a beállítás visszaáll csak dinamikusra. A rendszer újrainiíializálása után működik a NAT-szerver!
3. ábra: A dinamikus és statikus NAT bekapcsolása az INETCFG.NLM-ben
A statikus NAT konfigurálásához válasszunk nyilvános címeket azon gépek számára, amelyek ezt igénylik. Vegyük fel ezeket a NAT-táblázatba, összerendelve a megfelelő belső, privát címekkel. Ezután adjuk a nyilvános címeket a BMEE-szerver nyilvános interfészéhez az „add secondary ipaddress xx.xx.xx.xx” konzolparanccsal (címenként külön kell kiadni). Ezek a címek automatikusan a megfelelő interfészhez lesznek rendelve. E parancsokat írjuk be az AUTOEXEC.NCF végére is, az INITSYS.NCF sor után. A másodlagos IP-címek konfigurációja a „display secondary ipaddress” konzolparanccsal ellenőrizhető. A NAT bekapcsolása után lehetséges, hogy ki kell még adni a következő konzolparancsot: „set nat dynamic mode to pass thru = on”. Ez akkor szükséges, ha a nyilvános Internetről elérendő alkalmazások (GWIA, HTTP és others) a NAT-ot működtető gépen futnak. A belső hálózaton tetszés szerinti címek használhatók. Ha viszont az Interneten valójában is létező címeket osztunk ki, akkor a belső csomópontok e címek valódi tulajdonosaival képtelenek lesznek kommunikálni.
A BMEE konfigurációja: NetWare Administrator Lezárva a hálózati határt a csomagszűrőkkel és a NAT-tal, hozzáláthatunk az alkalmazási réteg szolgáltatásainak konfigurálásához az NWAdminban. Itt állíthatjuk be a VPN-t, a hozzáféréseket, a proxykat és a cache-t. Mielőtt hozzálátnánk a szolgáltatások konfigurálásához a „Szerver”-objektum BorderManager Setup lapján, feltétlenül vegyük fel a szerverre a szükséges IP-címeket és pontosan határozzuk meg, hogy azok nyilvános vagy privát címek. Az NDS-ben végrehajtott BMEE-beállítások automatikusan szinkronizálódnak az NLM-ekkel, és azonnal hatályba lépnek. Hozzáférési szabályok A hozzáférési szabályok a „Szerver”-objektum BorderManager Setup lapján az „Enforce Access Rules” négyzet kijelölésével kapcsolhatók be. A hozzáférési szabályok minden felhasználóra érvényesek, akik a BMEE-szerveren keresztül próbálnak haladni. Alapértelmezésként egy „Deny All” (minden tiltása) szabály rakódik a „Szerver”-objektumra, amely az új szabályok készítésével folyamatosan egyre lejjebb csúszik a listában (mindig az utolsó). Szemben a ZENworks irányelveivel, a BorderManager-szabályok nem felhasználó- vagy konténer-, hanem szerverközpontúak. Minden egyes alkalommal, amikor egy BMEE-szerver üzembe áll, a szerver kikeresi a címtárfából a szabályokat, a „Szerver”-objektumtól egészen fel a címtárfa gyökeréig. Csak felfelé keres, más O-kban és OU-kban nem. Minden megtalált szabály a szerver ACL-jébe kerül, ahol az alábbiak szerint rakódik sorba: • A „Szerver”-objektumon belül létrehozott szabályok • A „Szerver”-objektum szülőkonténerében létrehozott szabályok • A többi felette lévő konténerben létrehozott szabályok • Az O-konténerben létrehozott szabályok Megjegyzés: Az ACLCheck a változásokat 15 percenként keresi ki, teljes frissítést pedig 24 óránként végez.
A szerver minden egyes felhasználói kérést összevet az ACL-ben lévő szabályokkal, ellenőrizve, hogy vonatkozik-e szabály az adott kérésre. Ha igen, a keresés leáll – vagyis a szerveralapú szabályok elsőbbséget élveznek. Egy példa arra, hogyan is működik mindez: O=EMEA (szabály=DENY ALL) └──────OU=Corp (szabály =DENY ALL) └──────OU=Legal (szabály =ALLOW ALL) └──────CN=BMEE_Server Ha mindhárom konténerben találhatók felhasználók, akkor úgy gondolhatnánk, hogy kizárólag a Legal konténer felhasználói férhetnek hozzá a BMEE_Serverhez. Csakhogy a szerver a szabályokat a „Szerver”-objektumtól felfelé keresi ki, így már a az OU=Legal (szabály=Allow All) szinten talál megfelelő szabályt. Vagyis mindhárom konténer felhasználói teljes hozzáférést élvezhetnek. Az egyes hálózatok igényei eltérő szabály-elhelyezési döntéseket eredményezhetnek. Kis környezetekben az összes szabály a „Szerver”-objektumokba beírásával egyszerűsíthető az élet. A konténerszinten megadott szabályok viszont nagyobb környezetben segíthetnek elkerülni a dupla munkát, hiszen az összes lejjebb található szerverre érvényesek. Szintén segíthenek a felügyeleti szerepek elosztásában – de ügyeljünk a replikák elhelyezésére. A szabványos NDS-tervezési elvek betartásával elkerülhető a címtárfában való felesleges keresés, a túl sok replika hasnzálata és a WAN-kapcsolatokon keresztüli replikálás. Ne felejtsük, hogy a CyberPatrol-szabályok csak a „Szerver”-objektumokon állíthatók be. Ez szándékosan van így, a licencrend betartása érdekében.
