DIPLOMAMUNKA
Leleszi Gábor
Debrecen 2013
Debreceni Egyetem Informatika Kar
KOMPLEX HÁLÓZATI INFRASTRUKTÚRA TERVEZÉSE ÉS IMPLEMENTÁCIÓJA
Témavezető: Dr. Varga Imre Egyetemi adjunktus
Készítette: Leleszi Gábor Mérnök informatikus
Debrecen 2013
Tartalomjegyzék 1.
Bevezetés......................................................................................................................................... 1
1.1 Intézményi szükségletek ................................................................................................................. 3 2.
Állapotfelmérés ............................................................................................................................... 5
3.
Tervezés ........................................................................................................................................ 10
4.
Implementáció ............................................................................................................................... 22 4.1
Korrekt hálózati összeköttetések megvalósítása ................................................................... 22
4.2
Szerver telepítése................................................................................................................... 25
4.3
Szolgáltatások telepítése és konfigurációja ~ Szerver konfiguráció ..................................... 29
4.3.1
Csomagszűrés „tűzfal” - IPTables ................................................................................. 29
4.3.2
Dinamikus hoszt konfiguráció - DHCP......................................................................... 32
4.3.3
Távoli elérés és menedzsment – SSH............................................................................ 34
4.3.4
Proxy - Squid ................................................................................................................. 36
4.3.5
PDC és fájlszerver - Samba ........................................................................................... 37
4.3.6
DNS – Bind ................................................................................................................... 46
4.4
5.
Tesztelés ................................................................................................................................ 52
4.4.1
Teszt üzem 1.................................................................................................................. 52
4.4.2
Teszt üzem 2.................................................................................................................. 55
Ajánlás a jövőre ............................................................................................................................. 59 5.1
Hálózat .................................................................................................................................. 59
5.2
Hardver .................................................................................................................................. 62
6.
Összefoglalás................................................................................................................................. 65
7.
Felhasznált irodalom ..................................................................................................................... 67
8.
Függelék ........................................................................................................................................ 69
9.
Melléklet ....................................................................................................................................... 73
10. Köszönetnyilvánítás ...................................................................................................................... 73
1. Bevezetés Évekkel korábban világosan láttam magam előtt, hogy informatikával szeretnék foglalkozni, így tanulmányaimat ezen vezérelvet követve indítottam útjára. Mindenekelőtt a számítógépes hálózatokkal, hálózati operációs rendszerekkel (speciálisan a UNIX szerű GNU/Linux operációs rendszerekkel - disztribúciókkal) és kiszolgáló szerverekkel szeretek foglalkozni. Érdeklődési területeimhez szorosan kapcsolódik még azon hardver és szoftver ismeretek elsajátítása, melyek hálózatokkal, illetve hálózati kiszolgálókkal kapcsolatosak. A jövőbeni munkahelyemen az említett szakterületekkel szándékozom a lehető legmagasabb szinten foglalkozni. Szakdolgozati témaválasztásom során olyan téma után kutattam ahol az említett témakörökben szerzett eddigi jártasságomat megmutathatom, tudásomat elmélyíthetem, új technológiákkal ismerkedhetek meg, valamint felmérhetem, hogy mit is tudok valójában. Különösen fontosnak tartottam saját magam megmérettetését. Mindeközben különböző kérdések merültek fel bennem: Vajon hogyan teljesítek majd egy bonyolult, elvontabb probléma megoldása során egy igazi éles helyzetben? Képes leszek megoldani az adott problémát egy teljesen ismeretlen szituációban? Mindezt szinte teljesen egyedül, a lehető legkevesebb segítséggel. Tehát egy komplex, tág témakörben gondolkoztam. Lehetséges, hogy túl tágra is sikeredett. A témaválasztással szinte egy időben lehetőségem nyílt, hogy a debreceni Diószegi Sámuel Szakközép- és Szakiskola hálózati infrastruktúráját modernizáljam, valamint egy új hálózati kiszolgáló telepítését, konfigurációját, üzembe helyezését elvégezzem az intézményben. Mindezt szabad szoftverek felhasználása mellett. Tehát kiemelném, hogy szakdolgozatom nem csupán elméleti (persze ez is fontos részét képezi a témának), hanem nagyrészt gyakorlati fronton mozog. Ezért a „Komplex hálózati infrastruktúra tervezése és implementációja” fog diplomamunkám témájául szolgálni. Jelen téma kidolgozásával kapcsolatban fontosnak vélem, hogy nagy mennyiségű tapasztalatot tudhatok majd magaménak és megtanulhatom mi a valódi önálló munkavégzés. Valami újnak a létrehozása… Vélhetően kitágul majd gondolkodásmódom, hiszen nem csak egy mikro (főleg az otthoni, vagy nagyon kicsi vállalkozásokra célzok) környezetet kell kialakítanom, hanem egy valódi, egészen komplex világot kell átlátni és lehetőleg minél hasznosabb módosításokat alkalmazva. Mindezt alacsony költségvetés mellett egy jelenleg is működő hálózati infrastruktúrában. Munkám további céljai: • Az olvasó szeme elé tárni egy olyan szerver környezet kialakítását, melynek alapjául kizárólag szabad szoftverek szolgálnak. Melyet bárhol, bárki saját belátása szerint használhat fel, telepíthet, konfigurálhat és üzemeltethet vele rendszereket.
[1]
• A szabad szoftverek – mint a „szabad választás alternatívája” – bemutatása. Miszerint e szellemi termékek is ténylegesen használhatóak ugyanolyan kielégítően egy valós szituációban (sőt az esetek többségében jobban is), mint fizetős társaik. • Egy olyan referencia-dolgozat létrehozása, mely alapul szolgálhat egy kis és középvállalat (KKV), illetve egy közoktatást ellátó intézmény számára, hogy saját hálózatát megtervezze, kialakítsa azt, és különböző szolgáltatásokat implementáljon helyi hálózatába, hálózati kiszolgálók segítségével. • A dolgozat nem terjed ki a tűz- és munkavédelmi előírásokkal kapcsolatos fontos tudnivalókra, a teljes elméleti háttér bemutatására, a legfontosabb strukturált hálózati ismérvekre és a legapróbb részletekre sem, ugyanis e témák tárgyalása, valamint egy adott problémakör legmélyebb részletekig való kibontása – pl. strukturált hálózatok – egy újabb szakdolgozati témát merítenének ki. Szem előtt kell tartanom, mi a tanulmányom pontos célja. Dolgozatomban előre jól definiált módon fogok haladni. 1. Az első konzultációs időpontban felmérem az intézmény igényeit. 2. A további találkozók folyamán analizálom az iskola hálózati, hardveres és szoftveres adottságait. 3. Olykor a fontosabb szakaszoknál kis mértékben bevezetem az olvasót a strukturált hálózatok világába. Ha a korlátok engedik, kitérek a használt szabványokra, s e szabályok gyűjteményét is bemutatom néhány mondatban. 4. Kitérek a hálózatok előnyeire. 5. Az aktuális hálózati állapotról egy hálózati diagramot készítek, amely valósághűen ábrázolja majd az aktuális állapotokat. Ezen hálózati diagram megrajzolásához a Microsoft Visio 2010-es segédprogramját fogom használni. 6. Megtervezem, hogyan fogom kivitelezni az intézmény elvárásait, milyen szolgáltatások szükségesek hozzá, s ezeket szakszerűen bemutatom. 7. Implementálom a tervemet. 8. Felállítok egy tesztelési időszakot, hogy ne sérüljön az esetlegesen előforduló hibák miatt a már működő hálózat. 9. Migrálom a jelenlegi rendszert. 10. Méréseket végzek a rendszer állapotával, teljesítményével kapcsolatban, mind hálózati, mind pedig hardveres szempontból. 11. Kidolgozok egy tervet a jövőre nézve, melyben bemutatom, hogyan lehet még hatékonyabbá tenni a belső hálózati infrastruktúrát, valamint az elkészült tervet egy új hálózati diagrammal szemléltetem.
[2]
1.1 Intézményi szükségletek Az intézménnyel való egyeztetéseket követően körvonalazódott bennem, mely szolgáltatások megvalósítását szeretné az intézmény elérni. A költségvetés szűkös, így nincs lehetőség új hardver elemek beszerzésére, valamint megfelelő strukturált hálózat kialakítására sem, ezért dolgozatomban ezen témakörökkel kapcsolatos tudnivalókat elméleti síkon fogom megközelíteni, s bemutatni azt. Ezért néhol a kelleténél aprólékosabban is kitérek a hálózatokkal kapcsolatos fontos tudnivalókra. Az intézménynek az alábbi törekvéseit véltem felfedezni: A belső hálózat (LAN) megfelelő védelmének kialakítása a külső-belső támadásokkal szemben és egy kellően szigorú hozzáférés szabályozás kialakítása. Ezen szabályozás nem lehet sem túl komplex, sem túl egyszerű, hiszen egy túlságosan védett övezet megnehezítené a dolgozók munkakörülményeit, és ha belegondolunk szükségtelen is. Az arany közép utat kell megtalálni. Adott szolgáltatásokhoz csak az arra jogosult személynek legyen hozzáférése. Ezen feladatok megvalósítása egyértelműen egy speciális tűzfal szerver felállítását (is) követeli. Továbbá biztosítani kell a hálózati forgalom szűrését, és a szerveren futó szolgáltatásokhoz (services) való hozzáférést is szabályozni kell. Az iskola számítógépeinek tartományba léptetése a legfontosabb célok között szerepel. A számítógépek tartományba léptetésének számos előnye van, pl. megoldott a központi jogosultság kezelés, a felhasználók profiljainak, adatainak központi helyen történő tárolása, vándorló (roaming) profilok létrehozása pl. a hallgatók számára. Sőt adott a megosztott nyomtató és más erőforrás használatának lehetősége. Ennél a lépésnél kell a legjobban elgondolkodnunk (2013 végén, 2014 elején), hogy milyen disztribúciót választunk a feladatot megvalósító szolgáltatás alá. Bővebben lásd: Szolgáltatások bemutatása, Tervezés, Implementáció Egy olyan központi fájlszerver felállítása, mely megbízhatóan működik, s ki tud szolgálni egy kezdetben kb. 100-120 kliensből álló kis hálózatot, vagy akár ennek sokszorosát is. Ezen igények számára egy olyan szolgáltatást volna célszerű találnom, mely könnyedén együtt tud működni a tartományba léptető szoftverrel, ugyanis a fájlszerveren tárolt fájlokat a tartományi felhasználóknak is el kell érniük. E fájlszerveren biztonsági mentések, közös munka könyvtárak, felhasználói és tanári profilok stb. fognak helyet kapni, megfelelően szigorú jogosultság-kiosztással. Az alacsony sávszélességű internetkapcsolat optimális kihasználtsága. Lehetőleg a meglévő sebesség felgyorsítása (gyorsítótár alkalmazásával), valamint a hozzáférések korlátozása és a tartalom szűrése. Ezen igények megvalósításához mindenképpen egy proxy szervert kell majd felállítanom. Az alkalmazásnak robosztusnak, nagy terhelést kibírónak kell lennie, hiszen gondoljunk csak bele, mi a legnépszerűbb szolgáltatás egy közoktatást ellátó
[3]
intézményben? Az Internet. Tehát mindenki a proxy szervert fogja majd kérésekkel bombázni. Ezen szolgáltatások működéséhez sok-sok beállítás szükséges még milliónyi apró beállítást kell elvégeznünk, valamint a Linux rendszer és szervizek finomhangolása is ránk vár. Megemlítenék néhány nagyobb, csendesen a háttérben futó szolgáltatást, mint például a DHCP szervert, melynek felállítása lehetővé teszi, hogy az IP címeket ne kézzel, hanem dinamikusan osszuk ki kliensenként. Az IP címek kiosztását a számítógépekben lévő hálózati kártya fizikai címéhez (MAC) fogom kötni. Ezen beállítási lehetőség először időigényesnek, akár feleslegesnek is tűnhet, ám biztonsági, és a későbbi menedzselhetőség szempontjából is nagyon hasznos ötlet. Ebben a helyzetben hálózatunkhoz csatlakozva csak olyan eszköz fog kapni IP címet, melynek arra jogosultsága van. Egyéb feladataink is vannak, pl. rendszerbeli biztonsági beállítások elvégzése, a csoport/felhasználói jogosultságok kezelése, erőforrás kiosztás kezelése stb. Akár rendszeres időszakos biztonsági mentés (backup) - helyi és távoli kiszolgáló(k)ra is. A helyi adatok újbóli duplikációja miatt szoftveres azonnali duplikáló alkalmazást kell kialakítani, a rugalmas tárterület kezelése érdekében jó ötlet egy logikai kötetkezelő felállítása is. A fejlesztésekre szánt költség, mint azt korábban említettem, meglehetősen kevés – mondhatni szinte semmi – így komoly hardveres beruházásra és neves gyártók termékeinek a megvételére, pl. Cisco nem lehet számítani. Csak és kizárólag néhány 24 portos TP-Link switch eszköz, gigabites adatátviteli sebességre képes egyszerű desktop hálózati kártya (Network Interface Card) beszerzése fog megtörténni, mindez a javaslatomra. Összefoglalva, az eredeti intézményi cél egy tartalék szerver kialakítása, mely OSS alapokon nyugszik, funkcionalitását tekintve teljesen megegyezik az elsődleges Windows szerverrel, sőt többet nyújt. Végül mindkét szerver Linux alapokon történő tovább üzemeltetése.
[4]
2. Állapotfelmérés Ezen fejezet fő célja, hogy felmérjem és bemutassam az iskola jelenlegi állapotát és feltérképezzem az alkalmazott technológiákat, hogy megkeressem a „miértekre” a választ. A hálózati állapot szemléltetéséhez készítettem egy hálózati diagramot, amely a 11. oldalon található, valamint beszúrásra került az iskola alaprajza (10. oldal), s mellékletben a helyszínen készült fényképekkel is szemléltetésre kerül az aktuális hálózati állapot. Az iskola három internetkapcsolattal rendelkezik. Ezek közül az első kettő a leginkább használatos a mindennapi iskolai életben. Az első internetkapcsolat egy DIGI által szolgáltatott 10/10 Mbps sebességű kapcsolat, amely monomódusú optikai kábelen csatlakozik be az épületbe, egy Huawei menedzselhető switchet használva a kapcsolat végződtetésére. Vegyük észre a teljesen szimmetrikus fel és letöltési sebességet. Ez egy iskola számára különösen fontos lehet. A második internetkapcsolat egy standard, Sulinet által biztosított 4 Mbps sebességű vonal. Az efféle vonalak aszimmetrikus le/feltöltési sebességűek. Az utolsó internetkapcsolat egy 5 Mbps-os Invitel (ADSL). Érdekességként megemlíteném, hogy a Sulinet egy iskolának csak egy internetkapcsolatot biztosít(hat), melynek sávszélessége általában az említett 4 Mbps, s emellé társul vajmi kevés feltöltési sávszélesség, kb. 256-512 kbps. Ezért válik szükségessé további nagyobb kapacitású szélessávú internetkapcsolat bekötése az iskolákba.
Ábra 2 - Sulinet
Ábra 1 – Digi
Ábra 3 - Invitel
[5]
Az első két internetkapcsolatot egy két WAN porttal rendelkező TL-Link TL-R480T+ router kapcsolja össze. A router egy egyszerű Small Office Home Office (SOHO) kategóriájú eszköz, ám képes a kapcsolatok – manuálisan megadott – százalékarányos elosztására. Ezzel a funkcióval eltér, s valamivel felülemelkedik az átlag SOHO routerek képességein. Jelenleg 70-30%-ban a terheli a forgalmat a forgalomirányító a két kapcsolat irányában. Értelemszerűen a gyorsabb kapcsolat felé kerül a forgalom 70%-ának kiosztása. A harmadik kapcsolatra közvetlenül a „C” épület csomópontja, és néhány „A” épületbeli csomópont csatlakozik, ezen a kapcsolatra csatlakoztatott eszközök teljesen el vannak szeparálva a LAN-tól. Az elhelyezett access pointok (AP-k) – melyek valójában routerek – tulajdonképpen nem is AP-k, hanem router funkcionalitást látnak el, ráadásul DHCP szerverként is működnek, s különböző hálózati tartományból szolgáltatnak IP címet a hozzájuk kapcsolódó hosztoknak. Ezen kellemetlenség miatt szintén LAN szegmensek keletkeznek, szeparálódik a LAN. Az alábbi hibákra figyeltem fel a hálózati felmérés során: -
-
-
-
A strukturált hálózat nagymértékben sérült. Nincs kialakítva szerver szoba, a rendezők és rendező szekrények allapota, mérete, felépítése kifogásolható, vagy teljesen hiányoznak. A kábelezés nem egységes és a kábelek sérültek, nincsenek tartalék végpontok kialakítva, így a bővíthetőség lehetősége nem adott. Alulméretezett hálózattal állunk szemben. A hálózati dokumentáció, telepítési napló sosem létezett. A hálózat kiépítése illogikus. A rendszerbe felesleges vagy alulméretezett switchek kerültek beépítésre. A hálózati aktív/passzív elemek bárki számára könnyedén vagy akadálymentesen hozzáférhetőek. Rack szekrény és fizikai védelem hiánya A hosztoknak egy része nem éri el a központi szervert, melynek egyik oka, hogy – az iskola által – AP-nak feltételezett eszközök valójában routerek, s különböző belső hálózati azonosító címeket szórnak. Tehát nem AP, hanem router funkcionalitást látnak el, mely a hálózategyes részeinek szeparálódását eredményezi. Ezt egyszerűen meg lehetne oldani, ha AP üzemmódba konfigurálnánk a routereket. Egyes kapcsolatokat használó kliensek nem érik el egymást. Feleslegesen sok internetkapcsolat használata. (Sok lassú internetkapcsolat használata egy gyors és megbízható, valamint egy tartalék internetkapcsolat helyett). A vonalak használata illogikusan kiosztott. Csak két védelmi vonal (tűzfal) található a hálózatban: o Cisco 1711-es router szoftveres tűzfala, melyet a Sulinet konfigurál. o A fentebb említésre került SOHO kategóriás router, tűzfal konfiguráció nélkül. SOHO kategóriás, megbízhatatlan eszközre van bízva a teljes hálózat működése.
[6]
-
Redundáns eszközök hiánya mely az esetleges hardver hiba kiküszöbölése, megbízhatóság és rendelkezésre állás növelése érdekében segítségül szolgálna. A hálózat aktív/passzív eszközei nem kapcsolódnak szünetmentes tápellátásra (UPSre), kivéve a két szervert.
Lássuk most az épület alaprajzát.
Ábra 4 - A terület alaprajza
A 4. ábrán látható, hogy több épületcsoport található egy viszonylag nagy kiterjedésű területen, s szinte minden részegységen belül biztosítva van az internet hozzáférés. Az épületek közé kategória négyes típusú réz kábel van kihúzva, mely nem biztonságos megoldás, de hogy miért, arra a következő fejezetekben térünk ki. Ezen rajz ismerete fontos a számunkra, ugyanis a lentebb említésre kerülő diagram egyes részei építenek a rajzon jelölt objektumokra. A korábban elkövetett hibákból (felületes rajzok, pontatlan helyszíni jegyzetelés stb.), tapasztalatokból tanulva elkészítettem az aktuális állapotot szemléltető hálózati diagramot, és pontosan felmértem az intézmény igényeit is. A következő ábrán látható minden fontos aktuális részlet.
[7]
Ábra 5 - Szemléltető diagram - aktuális hálózati állapot
Magyarázat: Az intézmény teljes belső hálózata CAT 5, CAT 5e és néhol CAT 6 (fali FTP kábel) típusú kábelezést használ. Többnyire SOHO kategóriás TP-Link nem menedzselhető kapcsolókkal találkozhatunk, a 8 portos kiviteltől egészen a 24 portosig. A kapcsolók kezdetben 10/100 Mbps sebességűek voltak, ám javaslatomra néhány központi switch cserélésre került, melyek már támogatják a gigabites sebességet. Az olcsó eszközök miatt VLAN-ok kialakítására sincs lehetőség. Ezt nagy hiányosságnak ítélem, ugyan a virtuális LAN-oknak saját ütközési és üzenetszórási tartományuk van, így ezek szeparáló hatással bírnak, mely tulajdonság előnyös lehet az intézmény különböző szerveződési egységeinek az elhatárolására. Az épületben nincs strukturált kábelezési rendszer. A routerek a switch-ekhez hasonlóan szintén az egyszerű otthoni kategóriába sorolhatóak, s többnyire a TP-Link illetve a D-Link kínálatából találhatunk eszközöket. A sulinetes vonal azonban komolyabb CISCO-s eszközöket tartalmaz, egy 1711-es routert és egy 2950-es Catalyst switchet. Ezek felett ugyan eljárt már az idő (kb. 10 évesek), de máig megbízhatóbbak, mint az olcsó névtelen, vagy otthoni használatra szánt eszközök. A korrekt hálózat megtervezésével kapcsolatos feladataink a tervezés és az implementáció szakaszban folytatódnak.
[8]
Lássuk tehát, milyen kiszolgáló szerverekkel rendelkezik az intézmény. Server 1:
Erős hardver elemekkel felszerelt desktop gép
Alaplap Processzor Memória Grafikus kártya Merevlemez Egyéb
Asus P7P55D Intel Core i5 760 8 GB Corsair XMS3 CMX8GX3M4A1600C9 (4x 2GB KIT) Nvidia GeForce 7600 GS Western Digital (WD) 1 TB 2 db Adaptec AAR-2420SA RAID, SATA II RAID vezérlő Szünetmentes tápegység (UPS). 1 db
Server 2:
FujitsuMI3W-D2779
Processzor Memória Grafikus kártya Merevlemez Egyéb
Intel Xeon x3430 2,6 GHz 4 GB DDR III Integrált WD 500GB, SATA2 (WD 5000AAKS) * D-Link Gigabit hálózati kártya * UPS*
2 db 1 db
A *-gal jelölt részek előzetes javaslatomra kerültek beszerzésre. A „Server2” néven emlegetett hardvert kaptam először felkészítésre, ám sajnálatos módon személyi számítógépnek állították be e szervert. Hogy ez miért történt, arra az implementációs szakaszban térek majd ki. Így tehát virtuális megoldáshoz kellett folyamodnom, mely konfigurációját tekintve a Tervezés szakaszban leírt paraméterekkel van felruházva. Az iskola számítógépek száma: 120-130, melyek közül. kb. 70 db munkaállomás Microsoft Windows 7 Ultimate operációs rendszerrel van telepítve, a maradék PC-k kb. 99%-án Microsoft Windows XP Professional rendszer üzemel.
[9]
3. Tervezés A tervezés során először érdemes a hardver beállításait megtervezni, majd logikusan a szoftveres konfigurációt elvégezni. Ebben a fejezetben ezt a két témát, illetve a hozzá kapcsolódó fontos ismérveket fogom boncolgatni. A sajnálatos történések miatt (az intézmény elhagyása, bővebben: Implementációs szakasz) az eredeti szerver hardver elemeiről készült fotókat és BIOS beállításokat csak mellékletként, mint érdekesség tudom bemutatni. A „Server1” néven ismert szerveren jelenleg Microsoft Windows Server 2008 R2-es hálózati operációs rendszer üzemel, amely elsősorban a számítógéptermekben található munkaállomások tartományba léptetését végzi. További fontos feladata a felhasználók munkakönyvtárainak tárolása, biztonsági mentések megőrzése, valamint fájlszerver funkciók betöltése. Ezen követelményeket egy Ubuntu 12.04.3 LTS szerver - Samba szervizt futtatva könnyedén el tudná látni, az aktuális operációs rendszernél kevesebb erőforrás felhasználása mellett, jobb teljesítményt biztosítva. A „Server2” néven említett szerver volt első ízben – teljes egészében – rám bízva. A kiszolgálón az Intézményi szükségletek fejezetben az említett okok miatt az Ubuntu 12.04.03 LTS (legfrissebb stabil, hosszú távon (kb. 2017 első negyed évéig) biztonsági frissítésekkel támogatott) kiadás 64 bites server változatát fogom futtatni. A szerverben 4 GB memória található, melynek megcímzését egy 32 bites operációs rendszer már nem képes megtenni. Hardver beállítása: A további munkámat virtuális környezetben folytatom, mely virtuálisan összeállított szerver alapjául saját, otthoni konfigurációm szolgál. Alaplap: Intel DZ68DB Processzor: Intel Core i5 3570k Memória: 2 db 4 GB-os Kingston DDRIII 1333 MHz (Kit) Merevlemez: 3 db 1 TB WD 1002FAEX SATA3 Hálózati kártya: 2 db Intel Gigabit NIC. A virtuális szervert úgy állítom össze, hogy az a lehető legjobban hasonlítson az eredeti szerverre, s hasonlóképpen végezhessem a konfigurációját. A hardver tervezése során a diszkek munkába állítása a legfontosabb feladatunk, így mindössze ennek a tárgyalására térek most ki. Összesen 3 TB-nyi tárterület áll rendelkezésünkre, diszkenként 1-1 TB-onként szétosztva. Célunk az adataink biztonságban tartása, így (biztonsági mentés mellett) RAID1 tömb beállítására lesz szükség. A tömböt kétszer 1 TB HDD és egy spare (tartalék) diszk fogja alkotni. Ezen tükrözött tömbre (/dev/md0) egy logikai kötet kezelőt (LVM) fogok telepíteni,
[10]
mely képes a rendelkezésre álló tárhely rugalmas elosztására, mindezt a futó rendszer alól, valós időben. A RAID1 tömb feladata, hogy az adatokat egyszerre két helyre rögzítse (diszkenként külön-külön), így az adatok kétszeres megbízhatósággal állnak a rendelkezésünkre. A disztribúció felől a két diszk egy tömbként látszik majd a rendszerben, s e tömböt valójában a szoftveres RAID vezérlő (MD) kezeli, s adminisztrációs eszközként járul hozzá az MDADM segédprogram. Az operációs rendszeren belül a kernelnek része az MD, mely egy logikai blokk eszközt biztosít a tömb elérésére. Mennyi a valós tárhely a háromszor 1 TB HDD-ből? Biztonságra törekedtünk, megkaptuk. A rendelkezésre álló tárhely tehát: 1 TB. A kétszer 1 TB HDD alkotja a /dev/md0 tömbünket. Mindkét HDD-n ugyanaz az adat látszik, 1 TB HDD pedig tartalék diszkként funkcionál, mely az /dev/md0 tömbből kieső bármelyik diszk helyére automatikusan csatolódik. A hibás diszk kiváltása után pedig az adatok szinkronizációja történik. Ez több terabájtnyi adat esetén hosszú időt vehet igénybe. A szoftver beállítása: Egy Linux kiszolgáló telepítése és konfigurálása esetén az nem egyszerű feladat. Minden mozzanatot részletesen meg kell tervezni, igényeket felmérni, alaposan megfontolni, hogy ezek megvalósítása érdekében milyen lépéseket kell tenünk. A kiszolgálókat nem egy-két hónapra, hanem hosszú évekre tervezzük, konfiguráljuk, tehát nagy odafigyeléssel szükséges dolgoznunk. A telepítési folyamat fontosabb lépéseit későbbi fejezetben tárgyaljuk, viszont most kell szót ejtenünk a legfontosabb komplexebb beállítások miértjeire és a szervizek rövid bemutatására. Az első bonyolultabb tervezési pont a telepítés során a (1) partíciók beállítása. Ez képezi a rendszerünk alapját! Mennyire partícionáljuk szét a rendszerünket? Mit érdemes külön partícióra tenni és mit nem? Tudjuk, hogy milyen elvárásoknak kell megfelelnünk, s ezeket figyelembe véve kell meghozni a döntéseinket. • A tűzfal, DHCP, SSH és más apróbb szolgáltatás szinte közömbös a merevlemez méretére, típusára, fájlrendszerére, ám a jogosultság kezelésére e szervizek esetén is figyelnünk kell. • Szükségünk van proxy-ra is, ami alapvetően számtalan apró fájllal dolgozik és „szemeteli” a merevlemezt. Figyelnünk kell tehát a partíciók használatának módjára, ez egy linux disztribúció esetén a large_file, news stb. opciók jól megválasztását jelenti, és a csatolási opciókra is figyelnünk kell. Lásd: 16. oldal • Egy fájl szerver felállítására is szükség van, melynél mérhetetlenül fontos egy megfelelően előkészített partíció. • A fontos adatokat duplikálnunk kell, a duplikálására minimum egy RAID1 felállítása szükséges, nem is beszélve a biztonsági mentések létrehozásáról, mely mentéseket földrajzilag távoli helyen lévő szerverre, merevlemezre, szalagra, felhőben stb. kell(ene) tárolni, ám erre most nem térek ki. • Valamint a tárterület dinamikus kezelése érdekében LVM-et kell konfigurálnunk RAID1 fölött.
[11]
A hivatalos partícionálási sémát használom majd a RAID1 LVM fölötti megvalósításában. Lásd: Irodalomjegyzék: I2. Tehát a rendszer gyökerét (/), /home, /var, /usr, /tmp, esetleg a /usr/local könyvtárakat érdemes külön partícióra tenni. Hosszú utánajárás után arra a következtetésre jutottam, hogy ez így helyes, ám a /usr/local alkönyvtárát nem fogom külön partícióra tenni, ugyanis a tervezett használati mód mellett nincs szükség a rendszerbe forgatni programokat. Ezen programok karbantartása egyébként is plusz feladat lenne, s ez valóban nem szükséges a számunkra. Az ajánlott partíciókon felül létrehozok egy-két nagyobb méretű partíciót, melybe a /var/spool/squid3 cache könyvtár kerül majd csatolásra és a Samba megosztások, mely az /srv könyvtárat kapja csatolási pontként. A rendszerünknek valahonnan (2) bootolni kell, tehát szükségünk lesz egy elsődleges, bootolható partícióra, melyen semmiképpen sem szabad RAID-et és LVM-et telepíteni, ugyanis a telepítő – alaphelyzetben – nem képes a rendszer indítását elvégezni ilyen helyről. Jelenleg a rendszerben formázatlan HDD-ket találunk, ám a HDD-ket fel kell készítenünk a partíciók fogadására, tehát létre kell hoznunk rajta egy partíciós táblát. A partíciós tábla tárolja a partíciókra vonatkozó információkat, mint pl. a partíció, kezdete, vége, mérete, stb. és a rendszer betöltő programot is. A disztribúciónk sokféle partíciós tábla típust ismer, melyeket különböző architektúrájú gépeknek tart fent, pl.: MAC partíciós tábla a Macintosh gépeknek, MS-DOS-t a hagyományos x86-os gépeknek, GPT-t az új nagyméretű HDD-ket kezelő rendszereknek, jellemzően a 2TB-nál nagyobb méretű HDD-ken GPT partíciós tábla van. Ugyanis az MS-DOS által használt MBR nem tud 2 TB-nál nagyobb méretű lemezeket megcímezni, stb.… Az MS-DOS partíciós tábla létrehozása után a lemezeket ugyanúgy kell felkészítenünk. Elsődleges és logikai partíciókat kell kia.akítani a lemezen. Egy elsődleges partíció elkészítése a /boot számára - a boot zászló beállításáról el nem feledkezve- a legfontosabb feladatunk, hiszen csak ezzel lehet a rendszer képes a bootolásra. A logikai RAID partíciók elkészítése után be kell állítanunk a szoftveres RAID vezérlőt. RAID1-et használva egy spare (tartalék) diszkkel, majd (3) LVM-et konfigurálnunk RAID1 felett. Lásd: 31. Oldal 11, 12. ábra. A spare diszk használata sok kérdést vet fel a szakemberek körében. Ha belegondolunk három db teljesen egyforma HDD-t „vásároltunk”, s ha elromlik közülök egy, akkor valószínűsíthetően a másik kettő is közel abban az időben hibásodik majd meg. Így a spare diszk nem nyújt plusz biztonságot. Azonban a hardveres RAID vezérlőkben létezzik (létezhet) olyan funkció, amely mindaddíg kikapcsolt állapotban tartja a spare diszket míg nincs rá szükség. Tehát véleményem szerint aknázzuk ki a lehetőségét ebben a környezetben is. A RAID1 konfigurálásának befejeztével létre kell jönnie egy /dev/md0 logikai eszköznek, amin elvégezzük az LVM beállítását. A fizikai kötet önmagában nem tud létezni,mert egy kötetcsoportnak kell, hogy a tagja legyen. Létrehozzuk ezt a kötetcsoportot, majd ezen belül a logikai köteteket. Fájlrendszert telepítünk rájuk, és beállítjuk a csatolási pontokat, opciókat. A
[12]
GRUB-ot a /dev/sda1-re telepítjük. A telepítés végeztével blokk szinten kell átmásolnunk a merevlemezek első 446+66=512 byte-ját a másik két lemezre, hogy egy diszk kiesése esetén is tudjon bootolni a rendszerünk. A Squid által használt cache partíción érdemes a következő (4) csatolási opciókat beállítani: noatime, nodev, nosuid, noexec, defaults. A Samba megosztásokat tartalmazó partíción lehetővé kell tennünk, hogy a Windows rendszerekből ismert jogosultságok érvényesüljenek a Unix jogosultságkörében, ezért extended ACL szolgáltatást kell telepítenünk és beállítani ezen partíción. Esetleg kvóta meghatározása is szükségessé válhat. Ezen mount zászlók rendre a következőek: user_xattr, acl, barrier=1, usrquota, grpquota, defaults További rendszerszintű könyvtárrészek, mint pl. a / (gyökér), /home, /usr, /var, /tmp, /boot csatolásiopcióit tetszés szerint változtathatjuk. A csatolt könyvtárrészekben ezeket a számomra jónak vélt módon beállítom. A következő csatolási opciókból válogattunk – magyarázat: • defaults Ez az alapértelmezett opciók használatát jelenti (rw, suid, dev, exec, auto, nouser, és async) • rw A fájlrendszer írható/olvasható módon csatoljuk • ro A fájlrendszer csak olvasható módon csatoljuk • suid A felcsatolt fájlrendszeren a set uid és set gid bitek használata engedélyezett • nosuid Az előző ellentéte • dev A blokk eszközök használata engedélyezett • nodev Az előző ellentéte • exec A bináris fájlok végrehajtása engedélyezett a fájlrendszeren. • noexec Az előző ellentéte • auto A mount -a parancs kiadásakor és a rendszerinduláskor a fájlrendszer csatolásra kerül. • noauto Az előző ellentéte • user A fájlrendszert felhasználók is (le/fel) csatlakoztathatják. • nouser Az előző ellentéte • sync A fájlrendszeren található fájlokon a változtatásokat azonnal ki kell-e írni a lemezre. • async Az előző ellentéte • atime A fájl elérésekor (olvasásra megnyitás) a hozzáférés ideje frissül • noatime Az előző ellentéte. Ha kikapcsoljuk, valamelyest gyorsítjuk a fájlrendszer működését
[13]
Meg kell terveznünk (5) milyen csomagokra lesz szükségünk. Mint pl. Midnight Commander – Windowsos körökből ismert Total Commander linuxos alternatívája. Nem árt, ha van egy saját, jól megszokott szövegszerkesztő: nano, mcedit, vi, stb. Én a vi-t szeretem, s ezt is telepítem majd fel, valamint szükségesek a szolgáltatásaink: iscp-dhcpserver, opensshserver, squid3, bind9, samba4. A kiegészítőket, függőségeket majd letölti és feltelepíti a telepítő. (6) Az IPTables tűzfal scriptünk tervezése során egy szempontot kell szem előtt tartanunk: nem lehetünk eléggé paranoiásak! Minden oldalról számítanunk kell támadásra. Akár a megbízhatónak hitt LAN felől is érheti támadás a szervert. Ennek esélye nagyobb probléma, mint azt gondolnánk. Legyünk alaposak, tervezzük meg precízen a szabályainkat és ne engedélyezzük csak azokat a csomagokat, amelyek feltétlenül szükségesek. A legnépszerűbb szolgáltatások listája megtalálható a /etc/services fájlban. Ez hasznára lehet a most kezdőknek. (7) A DHCP kizárólag ismert MAC című klienseknek osszon IP címet, lehetőleg azt, amit mi szeretnénk, ez így elég biztonságos. Ne válasszunk túl nagy IP tartományt, a nagy üzenetszórási tartomány nem feltétlenül jó a számunkra. Példámban a 192.168.0.0/24-es hálózatból fogom a címeket osztani. (8) Az SSH – mint távoli menedzselő alkalmazásunk – biztonságára különösen oda kell figyelnünk, ugyanis a védelmi vonalon átjutva az egész szerverünk biztonsága odaveszhet. Ha a támadó bejutott a szerverre és megszerezte a legmagasabb jogosultsági – root – szerepkört, bátran kijelenthetjük, hogy a támadó birtokába került a szerverünk. (9) A SQUID konfigurációjának végrehajtásakor figyeljünk, hogy csak annak a hálózatrésznek adjunk hozzáférést, amelynek valóban szükséges. Működjön a háttérben – transzparens mód –, s lehetőleg több fájlt tartson a memóriában, hogy gyorsítsuk a működését. A cache könyvtár szerkezet megfelelő kiválasztása stb. (10) A Samba4 beállításának megtervezése okozhatja a legtöbb problémát a számunkra. Utána kell néznünk milyen új függőségek merülnek fel a szolgáltatás telepítése közben. Melyek azok az előkövetelmények, amelyekkel már számolnunk kell a 4. verziójú Samba telepítésénél: pl. NTP, extended-ACL. Mely szolgáltatásokat foglalta magába? Pl. beépített LDAP-pal rendelkezik. A domain és rendszer szintű userek összehangolása – Winbind vagy külső LDAP szerver, s még sorolhatnám. Ezen szolgáltatással egy időben érdemes a DNS szerver telepítését és konfigurációját végezni, ugyanis külön-külön való konfigurációjánál adódhat némi nehézségünk. Meg kell terveznünk, hogy melyek azok a jogosultsági körök és megosztások, amelyekre szükségünk lesz:
[14]
• Jogkörök: rendszergazda, igazgató, titkárok, tanárok, hallgatók • Megosztások: o Publikus megosztások, melyek bárki számára hozzáférhetőek – tipikusan a hallgatóknak, ám mindenki csak a saját fájlját módosíthatja, de mindenkiéhez hozzáférhet. o Saját könyvtár a tanároknak o A titkárok számára egy munka könyvtár, amelyben tárolhatja mindenki a saját munkáját. Ezen belül egy könyvtár mely célja a titkárok által közösen kezelt fájlok elhelyezése. o Saját könyvtár az igazgatónak, helyettesnek és a rendszergazdának. o ECDL érettségi és egyéb vizsgákhoz előre legyártott könyvtárak • Mentések könyvtárai • stb. A helyes jogosultság beállítás elengedhetetlen a könyvtárakon… Mielőtt tovább mennénk és elkezdenénk az Implementációs szakaszt, merüljünk el kissé a szolgáltatásaink elméleti hátterében, tehát (11) bemutatnám nagyon röviden az egyes fontosabb szolgáltatásokat. Linux netfilterét szokás IPTABLES-nek is nevezni, ugyanis ezzel a paranccsal végezzük a csomagszűrő beállítását. Általában a csomagok fejlécében megtalálható információk alapján értelmezi a hozzá kerülő információt, ám más lehetőségünk is van az illeszkedés ellenőrzésére. Tehát az említett paranccsal veszünk fel új szabályokat a láncokra. A láncok táblánként léteznek. Ez azt jelenti, hogy nem egy adott lánc tartozik több táblához, hanem a táblákhoz tartozik több lánc. Pl. a később említésre kerülő „filter” táblához tartozik az INPUT, OUTPUT illetve a FORWARD lánc is. A netfilterben számos beépített lánc található: INPUT - a helyi processnek (folyamatnak) címzett csomagok. Az OUTPUT - a helyi process által létrehozott csomagok, FORWARD a szerveren áthaladó csomagok, melyeknek útja pl. be: eth0, ki: eth1. Esetünkben ez a helyzet. A PREROUTING lánc a route-olás előtt álló csomagok helye, lánca. Végül a POSTROUTING, mely a route-olás utáni csomagok számára van fenntartva. Ezen láncok nem törölhetőek. A beépített láncokhoz táblák kapcsolódnak: NAT - a hálózati címfordításnál használjuk, általában az OUTPUT, POSTROUTING, PREROUTING láncokon. Filter - csomagszűréskor alkalmazzuk INPUT/OUTPUT/FORWARD láncokon. Mangle - a csomagok módosítására, megjelölésére alkalmas. Ezen táblával nem fogok dolgozni. Ha nem adunk meg táblát a szabályaink létrehozásakor, a filter táblához adódik hozzá a szabályunk. Lehetőség van a láncokra – a tűzfalunkra - úgynevezett irányelvet (policy-t), másképpen fogalmazva alapértelmezett szabályt adni. A policy meghatározza, hogy azok a csomagok,
[15]
amelyek a láncban nem illeszkedtek semmire, s elérték a lánc végét, mi történjen velük. Ezen esemény lehet engedélyezés (ACCEPT, default érték) vagy eldobás (DROP – nincs visszajelzés a feladónak a csomag eldobásával kapcsolatban). DROP esetén a csomag eldobódik/nem kerül feldolgozásra.
Ábra 6 - Csomagok haladása, Forrás: http://www.ironflake.org/
A csomag végighalad a láncokban felvett szabályainkon, majd a rendszer sorban kiértékeli őket. Ha illeszkedés történik, vagyis matchel az adott hálózati csomag az adott szabályra, akkor az a szabály végrehajtódik. Ha nem, akkor halad tovább a csomag, majd a policy szerinti esemény történik vele. A csomagok útját a felállított szabályrendszerünk határozza meg. Lehetőségünk van akár egyegész IP cím tartományról érkező összes kérést átirányítani egy másik szerverre, vagy akár el is dobhatjuk a tartományból érkező kéréseket. A lehetőségeink szinte végtelenek. Fontos megemlíteni, hogy a láncaink a hálózati csomagok haladásába való bekapcsolódási pontok, a táblák pedig ezeken a csomagokon végzett műveletek típusát határozza meg.
A UNIX/Linux szerverek távoli elérésére a legbiztonságosabb módszer az SSH - Secure Shell, egy olyan alkalmazás, ami biztosítja a felek közötti kommunikáció, adatfolyam titkosítást. A név nem csak egy biztonságos kiszolgáló - ügyfél típusú alkalmazást jelent. Az SSH jelenti magát a hálózati protokollt, a titkosított adatcsatornát biztosító alkalmazást, a kliens és szerver programot, egyszóval az egész komplex programcsomagot. Az SSH számos egyéb szolgáltatást nyújt számunkra egy csomópont biztonságos elérésén kívül. Tulajdonképpen nevezhetnénk egy rendszermérnök, egy takarítónő vagy akár egy gimnazista svájci bicskájának is, ugyanis bárki, bármikor, bárhol bármilyen célra használhatja az SSH-t. A használatához igazán nem szükséges mérnöki tudás, hihetetlenül egyszerű és mindemellett biztonságos alkalmazás.
[16]
Képes tehát: • • • • •
Biztonságos adatcsatorna kialakítására, melyen fájlátvitelre van lehetőség Más protokollok beágyazására – tunneling Secure FTP – Biztonságos FTP kialakítására X11-es (megjelenítési protokoll) forwardolására Távoli parancskiadásra (jómagam ezt a funkcióját szeretem a legjobban). Ezt a következőképpen viszi végbe: Az azonosítási folyamat után az SSH kiolvassa a passwd fájlból, hogy az azonosított userhez milyen shell tartozik, s biztosítja azt számára.
És sok-sok egyéb szolgáltatás, amire talán nem is gondolnánk, hogy képes lehet. Érdekességképp megemlíthető, hogy az SSH v2 az újabb verzió, amely nem a v1 alapján készült – ugyanis abban több biztonsági rés is felfedezhető, – hanem egy teljesen a semmiből, a nulláról írt új verzió.
Következzék a Proxy! Proxy-nak – proxy szervernek – nevezünk egy olyan alkalmazást vagy szervert, ami a kliens gép és az internet között helyezkedik el, mint harmadik fél. A proxy fogadja a kliens általi kéréseket, műveletet hajt végre azon. A kliens által kért tartalmat a cél szerver felé irányítja – általában a HTTP kéréseket egy web szerver felé, majd a távoli szerver válaszát továbbküldi a kliensnek.
Ábra 7 - Proy működése Forrás: http://hadmernok.hu/
Miért is fontos ez nekünk? A proxy mögé rejtve hálózatunkat, klienseinket, védhetjük meg a károsnak ítélt tartalmaktól, egyszerűen menedzselhetővé vállalnak a kérések, hatalmas, akár több gigabájtnyi cache területként szolgálhat, ezáltal gyorsítja internet-kapcsolatunkat. Ugyanis a kliensek minden egyes kéréssel a proxy szerverhez fordulnak, a szerver lekéri az adott webhelyről a tartalmat, el cache-eli és szolgáltatja a kliensnek. Ha ezt az adatot egy újabb kliens is kéri, a proxynak nem kell érte „kimenni” az internetre, hanem saját
[17]
gyorsítótárából – ami lényegesen gyorsabb, mint egy szokásos internetkapcsolat – szolgálja ki a kéréseket. A SQUID proxy egy igazán robosztus rendszer. Rengeteg lehetőséget nyújt a számunkra, a teljesség igénye nélkül felsorolnék néhányat: • • • •
tartalomszűrés hozzáférés szabályozás cache transzparens üzemmód
A Samba 3.5.x-es verziója szabályos tartományba léptetést tud végrehajtani a Microsoft Windows rendszereken az XP-vel bezárólag. Az újabb rendszerek szabályos tartományba léptetésére azonban csak a Samba 4.0-ás verziója képes. Az említett kiadás a legtöbb disztribúciónak a repository-jában még nem lelhető fel. Ez várhatóan a 2014-es év közepére, végére fog megtörténni. Ilyen pl. a Debian GNU/Linux is. Ezen rendszerrel kezdtem a későbbi implementációs szakaszban leírtak megvalósítását, ám a Samba 4.0-s szerviz nehézkes beállításai és a forrásból való telepítés hátrányai miatt kénytelen voltam a Debian alapú Ubuntu disztribúcióhoz nyúlni, az Ubuntu alapú Zentyal rendszer repository-ját használva. A szolgáltatás megalkotásának hátterében (főként) a Windows és UNIX operációs rendszereket futtató számítógépek közötti együttműködés (fájl- és nyomtató megosztás, tartományba léptetés) megvalósítása állt. Ezen szolgáltatásokat SMB protokollal valósítják meg. A Samba nyílt forráskódú (OSS) – melyet GNU General Public Licence (GPL) szerint terjesztenek. A Samba által kínált szolgáltatások – a teljesség igénye nélkül: • Egy/több fájlrendszer, könyvtár megosztása; • Szerveren/kliensen telepített nyomtatók megosztott használata; • Windows operációs rendszert futtató kliensek tartományba léptetése; • A 4.x verziótól kezdve e szolgáltatások kibővültek és teljes körűen azon szolgáltatásokat tudja nyújtani, mint a Microsoft Windows Active Directory-ja. • A 4.x-es verzióban beépített LDAP szerver, Kerberos hitelesítő rendszer, belső és külső névszerverekkel való együtt működés, címtárszolgáltatások stb. található meg. • A 4.x verziót teljesen a Windows Szerververziókból ismert AD képmására alkották meg. A Samba service működésének feltétele két Unix démon: (forrás: K6) smbd: Lehetővé teszi fájlok, nyomtatók megosztását a hálózatban, és az ügyfelek azonosságának, hitelességének és jogosultságának vizsgálatát.
[18]
nmbd: Egy egyszerű névkiszolgáló. Figyeli a névkiszolgálóhoz intézett kérdéseket, és a kérésre rendelkezésre bocsátja a megfelelő információkat. Ugyancsak ez a démon adja át a hálózatnak a tallózó listákat, és vesz részt a hálózati fő tallózó kiválasztásában. A WINS (Windows Internet Name Service, Windows internet névkiszolgáló) kezeléséről gondoskodik, és segítséget nyújt a tallózásban. A WINS a NetBIOS Microsoft Windows általi megvalósítása. A NetBIOS nevet a telepítésekor megkapja a PC-nk, mely általában megegyezik a PC nevével. A NetBIOS a TCP/IP protokoll fölött működik. Használata előnyös az alacsony darabszámú hálózatoknál, hiszen nem kell felállítani WINS vagy DNS szervert a gépek névfeloldásához. Fontos megemlíteni, hogy nem lehet egy azon hálózatban két egyforma, megegyező nevű számítógép! Ugyanis a számítógép a hálózati kommunikáció folyamatában a TCP/IP kapcsolódás előtt küld egy broadcast üzenetet a hálózatban. Ezen üzenetben közzé teszi, hogy milyen NetBIOS névvel kíván jelen lenni a hálózatban, s ha már van a hálózatban a broadcastot kibocsájtó számítógéppel egyező nevű PC vagy hálózati kommunikációra képes eszköz, akkor e csomópont válaszüzenetet (hibajelzést) küld a kibocsájtó gépnek. A kibocsájtó gépnek azonban eddigre már van IP-je, de a TCP/IP protokoll készlet, a kapott hibajel után letiltja a kifelé való kommunikálást, így a csomópont nem lesz képes a hálózati kommunikációra. A DNS – Domain Name Service működése egy átlagos felhasználónak fel sem tűnik, ám megléte mégis alapvető a világunkban. Használjuk mindennapjaink során, ha beírjuk a böngészőnkbe egyik kedvenc weblapunk címét. Az interneten IP cím alapján működnek a kérések ám a DNS segítségével az IP címekhez a könnyebb megjegyezhetőség kedvéért nevet rendelhetünk. Fontos megemlíteni, hogy nem csak IP címekhez rendelünk nevet, hanem ezt visszafelé is meg kell, hogy valósítsuk, ugyanis ezzel ellenőrizzük a név hitelességét. Előfordulhat, hogy a kommunikációs viszonyba egy nem kívánt harmadik fél becsatlakozik és magát hirdeti, mint az adott név „tulajdonosa”, azonban ha visszaellenőrizzük, hogy az adott címhez milyen név tartozik – ha tartozik – és nincs egyezés, akkor biztosak lehetünk, hogy valami turpisság van a dologban. Ezt a folyamatot inverz névfeloldásnak nevezik. Az IP cím-ből domain név feloldás érdekében bevezették az in-addr.arpa (IPv4 esetében) illetve az ip6-arpa. (IPv6-nál) domaint. Egy publikus IPv4-es IP cím pl. a 173.194.39.98. Az ehhez a címhez tartozó nevet úgy kapjuk meg, hogy az említett in-addr.arpa domain rendszertől lekérdezzük a 98.39.194.173.in-addr.arpa névhez tartozó rekordot.
[19]
A következő példából kiderül, hogy valójában mire is szerettem volna rávilágítani. Ha beíjuk a böngészőnkbe a 193.6.135.21 IP címmel rendelkező host IP címét – mely egy publikus IP v4-es hálózati cím-, ami egyértelműen beazonosítja a világhálón elérhető gépet, szemünk elé tárul az informatika kar (régi) honlapja: www.inf.unideb.hu. Ezt a szolgáltatást (névből IP cím meghatározás) biztosítja számunkra a DNS szolgáltatás, s máris látható, hogy milyen fontos szolgáltatás ez. Ábra 8 – Névfa
A DNS által kezelt nevek fa struktúrába sorolhatók, a fa gyökere az, ami a hierarchiában előtte található. A feloldás visszafelé történik, vegyük pl. a http://www.inf.unideb.hu. domain címet (egyébként a cím végén van egy pont (.)), de nem azért mert lezártam a mondatot, hanem mert ott a helye, így teljes egy FQDN. Minden FQDN-t ponttal zárunk, ugyanis ez a legmagasabb szintű névszerver jelölése (a később említendő névfa gyökere), de a mindennapi életben ezt, az egyszerűség miatt elhagyjuk. Viszont azt tudnunk kell, hogy ezt a böngésző automatikusan oda illeszti a domain név végére. Lássunk tehát egy példa fát: (Ábra 8, később erre még jobban kitérünk a Bind bemutatásánál) A fenti cím (szerver) Magyarországon (.hu, egyébként ezeket a végződéseket: .com, .info, stb. TLD-nek nevezzük) van, a Debreceni Egyetem tulajdonában (ő gondoskodik az ’unideb’ domain kezeléséről, melynek egy ’aldomain’-je az ’inf’ majd ’alaldomainje’ a ’www’). Mindjárt látható, hogy ez egy hierarchikus, robusztus rendszer. A domain nevekről általában: (forrás: K1) FQDN (Fully Qualified Domain Name) a domain név egész hossza, ami hostnévtől a gyökérig tart. A domain név pontokkal elválasztott szakaszait szegmenseknek nevezzük. Mint ahogyan azt korábban említettem, a domain név végét, teljességét a név végén található pont jelzi. A domain nevekben megengedett karakterek: A latin ABC betűi a-tól Z-ig, a számjegyek [0-9] és a kötőjel (-). Ez egy klasszikus szabály, de lásd: RFC2782. Kis- és nagybetű egyformán használható, és nem jelent különbséget. Az ékezetes karakter használata nem megengedett. Egy domain név úgynevezett fa-szerkezetet alkot, vagy másképpen hierarchiába rendeződnek a nevek. Egy ilyen hierarchia egyébként 127 szint mélységű lehet. A fa csúcsán a gyökér (root) – a pont (.) – áll, s innen kezdődik a név feloldása, tehát a domain végéről kiindulva. A
[20]
név végi pont valójában elhagyható, ugyanis a böngésző kiegészíti, de hivatalosan ez is része a domainnek. A név „részegységeit” ponttal választjuk el egymástól, ezek lesznek a névfa ágai. E névfa adminisztratív célból – pl. egy intézmény által – egyben kezelt részeit DNS zónáknak nevezzük. A zóna állhat mindössze egyetlen domainből is, pl. www.google.com, vagy tartozhat alá sok-sok aldomain is. Ezen zóna és zóna fájl helyének megadása és létrehozása, valamint szerkesztése az egyik legfontosabb feladatunk. A zónákat kezeli a Bind DNS server, melyekben explicite megadottak a zónával és a zóna- fájllal kapcsolatos tulajdonságok. A zónafájlokban különböző rekordbejegyzések találhatóak, amelyek pontosan megadják a zóna által definiált hoszt, vagy hosztok adatait pl. címét és nevét, típusát, pl. név szerver, levelező szerver stb. A névfeloldás folyamata a következőképpen zajlik. Tegyük fel, hogy a valami.hu nevet kell feloldani, mert pl. ide szeretnénk FTP-vel kapcsolódni vagy éppen levelet küldeni. Az általunk használt alkalmazásnak pl. böngészőnek, FTP kliensnek, megadjuk a valami.hu domain nevet. Ekkor az adott programnak meg kell tudnia, hogy milyen IP cím is tartozik valójában ehhez a domain névhez. Ezt a funkciót ellátó egységet „rezolver”-nek nevezzük. A számítógépünkön a TCP/IP protokoll család beállításánál meg kellett adni egy vagy több DNS szervert. (vagy DHCP-n ezt is megkaptuk) Az itt megadott címeken található DNS szerverekhez fordul a rezolver. A DNS szerver lehet szerver saját maga, vagy bármely gép az interneten (ekkor a rezolver kéri meg a távoli gépet a név feloldására). Gyakorlatilag minden TCP/IP-t használó, hálózatra kapcsolt számítógépen szükség van rezolverre és DNS szerver megadására. A rezolver tehát nem végez közvetlenül névfeloldást, hanem bizonyos általa ismert névszervereket kér meg arra, hogy ezt a feloldást elvégezzék.
[21]
4. Implementáció Ezen fejezetnek legfontosabb célja a beállítások elvégzése, azok ismertetése, valamint egy működő kiszolgáló felépítése az alapoktól a teljes körű, megbízható, stabil, gyors (és persze ingyenes) Linux kiszolgálóig. A lényeges részeket igyekszem a lehető legtisztábban elmagyarázni – ha szükséges kissé „konyhaibb” nyelvezetet használva, illetve a konfigurációs beállítások miérteit tisztázni az olvasó számára. Egyes parancsok pontos taglalásának ismertetésére azonban nem fordítok túlzottan nagy figyelmet, ugyanis ezek megértéséhez néhol komolyabb előismeret szükséges, s ez nem feltétlenül releváns információ az olvasónak. A parancsok manuál lapjaiban a lehető legrészletesebben ismertetve vannak a kapcsolók jelentései, és magának a parancsnak pontos működése és feladata.
4.1
Korrekt hálózati összeköttetések megvalósítása
A feladatunk, hogy kialakítsunk az eredeti hálózati környezetből egy korszerűbbnek mondható hálózati infrastruktúrát. Milyen módosítások szükségesek ehhez? Ismételten megemlíteném, hogy új eszköz vásárlására nincs lehetőség, így „abból kell gazdálkodni, amink van”. A problémát először fizikai oldalról kell megközelíteni, így a legfontosabb teendőink a következőek: 1. internetkapcsolatok helyes szétosztása 2. terhelés elosztás 3. minden kapcsolat egy helyen végződtetése szerver(ek) 4. LAN védelme
a végződtetések helye: a központi
A két lassabb, kevés forgalmat produkáló kapcsolatot a TL-R80T+ router két WAN portján célszerű végződtetni. Belátható, hogy a lassabb vonalak kezelése a gyengébb eszköz feladata, mivel így kevésbe terhelődik a forgalomirányító processzora, s esetleges kiesése esetén nem bénul meg a teljes hálózat. A 10/10 Mbps sebességű vonal kezelését bízzuk a megbízható, erős hardver elemekkel rendelkező szerverre. A vonalat a szervergép Ethernet kártyájára kell kötnünk. Ahhoz, hogy a másodlagos (tartalék) szerver is rendelkezzen internet hozzáféréssel, csatlakoztatnunk kell a TL router egy switch portjára. Ezen módosításaink máris két védelmi ponton nehezíti meg egy esetleges támadó útját a belső hálózat felé vagy a szerver irányába.
[22]
A védelmi vonalainkat tehát a helyesen konfigurált routereink és a saját szigorú tűzfalszabályokkal rendelkező szervereink alkotják. Az elvégzett módosításoknak köszönhetően, elértük a kitűzött célunkat, elhatároltuk a külvilágot és a LAN környezetet. A LAN logikus megtervezése nem egyszerű feladat. A helyes hálózati összeköttetések kialakítása, az AP-k beállítása és megfelelő elhelyezése tervezést igényel. A „gondnok”, az „élelmezés”, a „szalon” és a „matek-fizika szertár” eddig közvetlenül csatlakoztak a Sulinet Cisco switchére, azonban mi a fenti módosításunkkal levágtuk őket erről a vonalról. Mindezt többek között a csomópontok védelme érdekében (is) tettük. Ez azonban még nem elegendő, a LAN-ra való csatlakoztatásukat meg kell oldani. Legésszerűbb, ha az említett felhasználókat az „A” épületben található 24 portos 10/100 Mbps sebességű TP Link switchre csatlakoztatjuk. Az AP-kon firmware frissítést célszerű végeznünk, ám sajnos erre nem kaptam engedélyt. A router-eket AP üzemmódba kapcsoljuk, hogy azok többé ne szeparálják a LAN-t , s fix IP címet osztunk nekik MAC cím alapján. Ezeket táblázatban feltüntetjük az utókor számára, így azokat később könnyen el tudjuk érni a beállított IP cím alapján. Gondoskodnunk, kell a megfelelően erős azonosításról (minimum felhasználónév+jelszó), valamint a DHCP szerver funkció és a tűzfalazás kikapcsolása is szükséges, ugyanis ezeket a szolgáltatásokat a szervernek kell végeznie. A vezetéknélküli kliensek csatlakoztatására WPA2/AES titkosítást használunk. Ez elég erős, és nehezen törhető fel. Talán a ma általunk ismert legbiztonságosabb vezeték nélküli titkosítási forma. Az „R.Wifi 01” és „R.Wifi 02” wireless csatorna választását nem célszerű automatikusan rábízni a routerekre. A 2,4 GHz-en működő routerekben 13 csatorna található, ám ezekből csak 3 nem átfedő, ezek rendre az 1-6-11-es csatornák, lásd: 9. ábra. Illetve, mint tudjuk, ezen a frekvencián üzemelnek még más rádióhullámos technológiák pl. a bluetooth. Ezek pedig zavarhatják a jeleket. Az egyes és tizenegyes csatornákon való üzemeltetésük jónak tűnik. Az egyes csatornák átviteli sebessége 2,4 GHz-en 20 MHz, ezen csatornán maximálisan 75 Mbps-os sebesség érhető el. Ha a csatornát zavarja valami más, mondjuk egy szomszédos csatorna sávban működő router, akkor a sebesség egyértelműen csökken. Ezért választunk nem átfedő csatornákat. Egyébként a 802.11n szabványú fejlettebb routerek már az 5 GHz-es tartományban (is) működhetnek, ahol már 40 MHz egy csatorna szélessége, és max. 600 Mbps-os sebesség is elérhető és bónuszként 21 db 20 MHz-es, és 9 db. 40 MH-es egymást nem átfedő csatornából válogathatunk. Szóval kevésbe telített még ez a frekvencia tartomány.
[23]
Ábra 9 - Frekvencia tartományok, Forrás: http://www.odessaoffice.com
Még nem vagyunk készen. Az internetvonal „levágásával” az „A” épületben található TL switch mögött elhelyezkedő hosztokat is elvágtuk a belső hálózattól, így ezen TL kapcsolót is csatlakoztatni kell a LANra. A legésszerűbb a „T30-back” switchre való csatlakoztatása lenne, azonban problémába ütközünk. A „B” épület T14-es terme és az „A” épület 24 portos switch-e közötti távolság bőven 100 m fölött van, így nem használhatunk csavart érpárt. Lásd: [F2]. ábra. Sőt a TIE/EIA 568-as szabvány sem engedi ezt meg. A különálló épületek azonos földpotenciálja fizikailag nem biztosítható, s ha két különböző földpotenciállal rendelkező épületet kötünk össze galvanikus – rezes hálózattal, akkor kóboráram folyhat a két épületrész között. Ezért a két épület közé optika kábelt kell kihúznunk, és egy-egy média konverterrel a végeken átalakítani a kábeleket rezes csatlakozásra. A média konverter lehet pl. TP-LINK MC220L 1000M, melynek ára 5-10.000 Ft között helyezkedik el. E konverter optikai csatlakozója SFP típusú, melybe leggyakrabban LC csatlakozóval (létezik még sok más optikai kábel csatlakozó) ellátott optika kábelek köthetőek. Az optikai kábelünk pedig a jövőre gondolva 10 Gbps-os legyen, a kitűzött sebességet mind a mono módusú, mind a multi módusú kábel is bőven elbírja, de valószínűleg nem lesz szükségünk egyszerre több jel továbbítására a közegen, így a mono kábel választása elegendő a számunkra. Ezek a mono kábelek 9/125 mikronosak, tehát a belső mag 9 mikron átmérőjű, a külső réteg pedig 125 mikron. Végső feladatunk a könyvelés számítógépeit lecsatlakoztatni a T30-back switchről és a logikailag és fizikailag is a hozzá tartozó négy portos switchre kell kötnünk azokat. E switch a változások alkalmazása után kevés lesz a számunkra, nyolc portosra kell bővítenünk Az APkat már korábban beállítottuk így már nem routerként, hanem – helyesen – AP-ként funkcionálnak. Az „R.Wifi 03” azonosítóval ellátott acces point a T30-as teremben helyezkedik el, ennek ellenére a T29-re van kötve. Ezért ezen összeköttetést is T30-front„R.Wifi03”-re kell módosítanunk.
[24]
Ábra 10 - Módosított állapot
A 4.1-es szakasz törzsében leírt változásokat a 10. ábra szemlélteti.
4.2
Szerver telepítése
A Diószegi Sámuel Szakközép– és Szakiskola az implementáció közben, kissé tisztázatlan okra hivatkozva „kihúzta” a kezem alól a kiszolgáló szervert. Ezzel meghiúsítva a saját céljukat – melyre az intézmény rendszergazdája kért fel ,– miszerint szeretnének egy teljes értékű kiszolgálót az iskola számára, mely nyílt forráskódú, ingyenes Linux disztribúciót futtat, megteremtve ezzel az alternatívát a Microsoft Windows szerverek későbbi kiváltására. Sajnos nem áll rendelkezésemre elegendő idő egy újabb szerver gép beszerzésének kivárása, ezért a teljes implementációs szakaszt és tesztelést virtuális környezetben valósítom meg. A korábban elkészített részeket valamelyest módosítanom is kell, hogy a beállítások igazodjanak a virtuális környezethez. A virtuális környezetben elvégzett beállítások után szintén egy teljesen jól működő – ingyenes – Linux szervert fogunk kapni.
[25]
Az első lépés az Ubuntu Linux rendszerünk telepítő fájljának beszerzése a hivatalos honlapról. A telepítés során a korábban említett szerverekre szánt verzió, 64 bites architektúrára fejlesztett példányát használjuk fel: „ubuntu-12.04.3-server-amd64.iso”. A stabil kiadás választása mindenképpen fontos döntés, hiszen egy éles környezetben működő rendszernél nem engedhető meg szoftverhiba, és így a rendszer váratlan lefagyása. Ilyen hibák egy tesztelés alatt álló verzió esetében előfordulhatnak. A dolgozatban kizárólag parancssoros felületen fogok dolgozni – CLI – GUI-ra vagyis grafikus felhasználó felületre egyáltalán nincs szükség. A GUI a rendszerünk biztonságát veszélyezteti, illetve a teljesítményét és a stabilitását is ronthatja. A fő különbég a 64 bites illetve 32 bites rendszerek között, hogy a kétfajta architektúra regiszterei és a buszainak szélességei eltérőek (32 64 bit). A 64 bites operációs rendszer esetében nagyobb teljesítményre számíthatunk, természetesen csak akkor, ha mind a hardver, mind a telepített szoftverek 64 bitesek. A korábbi fejezetekben említett virtuális gép fog a hálózati operációs rendszerünk „vasaként” szolgálni. Az installációs folyamat a következő: (a fontosabb részek kiemelésével) -
-
-
-
-
Nyelvi és területi beállítások: Időzóna, karakterkiosztás, billentyűzet típusának beállítása. UTF-8-as karakterkódolást használunk, magyar (HU) kiosztással. A hálózati hardver (NIC) beállítása: Felkapcsolódik az aktív interfész és IP cím állítására van lehetőségünk, statikusan vagy dinamikusan. Az eth0-s interfészen statikus, 192.168.0.2 IP címet állítunk, az eth1-es interfészt parancssorból állítjuk majd be a LAN számára. A saját belső hálózatomban a szerver lesz a router és a tűzfal. A szimulált külső hálózatban a 192.168.0.1 IP címmel rendelkező router kapcsolódik a külvilág felé. Linux felhasználók felvétele: Fontos az erős jelszó választása, kis- és nagybetű, szám, speciális karakter, min. 8-12 karakter hosszú. Jelen esetben nem veszek fel felhasználót, csak a root-tal konfigurálom a rendszert, majd ezek után hozok létre egy normál felhasználót, ha szükséges. A tartományi bejelentkezéseket a samba-tool segédprogrammal állítjuk majd be. Óra konfigurálása: NTP időszinkronizációt használunk, egy időszinkronizáló szerverhez, hogy a kiszolgálónk órája mindig pontosan járjon. Merevlemezek partícionálása: A partícionálás kézzel történik. Beállítandó, hogy a rendszer könyvtárak mely partíciókon helyezkedjenek el (pl. /dev/sda1), a partíciók milyen típusúak legyenek (pl. EXT4, XFS, stb), s mely speciális csatolási opciók (exec, rw, user, stb) legyenek eszközölve, és további fontos beállítások. A rendszer „szét-partícionálásának” elvével egyes adminisztrátorok egyetértenek, mások pedig kevésbé. Véleményem szerint a „szét-partícionálás” mellett erős érvként említhető meg, hogy külön-külön szabályozhatjuk a könyvtárak (pl.: /home –
[26]
-
-
-
-
-
-
felhasználói könyvtárak helye, /usr, stb) csatolási opcióit, amely növeli rendszerünk biztonságát. Megadható pl. hogy az egyes partíciók milyen jogosultsággal legyenek mountolva, lehessen-e rajta futtatni bináris fájlokat vagy sem, aszinkron vagy szinkron módon törtjén a fájlrendszerhez való hozzáférés (aszinkron – a vezérlés az I/O művelet végrehajtása előtt visszaadódik a programnak, szinkron – a vezérlés csak a művelet végrehajtása után kerül vissza a programnak). Bármely felhasználó csatolhate egy adott partíciót vagy csak a root (default: csak a root), lásd: „Tervezés”. A diszk felosztása során figyelembe kell vennünk, hogy milyen szolgáltatásokat fogunk futtatni, s azok milyen igényekkel rendelkeznek. Milyen biztonsági szinttel szeretnénk dolgozni stb. Esetünkben a Samba illetve a Squid a két legnagyobb szolgáltatás, mely befolyásolni fogja a darabolásunk egyes szakaszait. A proxy cache partícióját (/var/spool/squid3) érdemes külön diszkterületre tenni, s ezen különböző optimalizációs beállításokat végezni, mint például a csatolás folyamán alkalmazandó a noatime, noexec, nosuid, nodev zászlókat. A Samba megosztásokat szintén érdemes külön partícióra helyezni (/srv/…), hiszen a megosztásokat különösen előrelátóan kell kezelnünk. Be kell állítanunk a user_xattr, acl, barrier=1, nodev, és defaults opciókat egyaránt. A barrier=1 opció visszafogja a sebességet, így kisebb eséllyel történik hiba, s kevésbe terhelődik rendszerünk. A legfontosabb szakasz a RAID1 és LVM beállítása. Ezek közül részletezésre szorul az LVM. Létrehozunk egy kötetcsoportot pl. a szerverünk nevével. Ez az esetünkben: vgprobserv. A kötet mérete legyen a teljes 1 TB-nyi tárterület. Ezen belül kell létre hoznunk a logikai kötetcsoportjainkat a következő kezdő méretekkel: - swap - 1 GB, - gyökér (/) - 10 GB, - home - 10 GB, - usr - 10 GB, - var - 10 GB, - srv - 10 GB, - squid - 10 GB, - tmp - 10 GB. Lásd: 11, 12. ábra Az alaprendszer telepítése: Kernel választás! Mindig a disztribúcióban található legfrissebb stabil kernelt válasszuk. Fordíthatunk saját kernelt is, ha nem megfelelő a „gyári” rendszermag, de az Ubuntu által szállított stabil kernel általában megfelelő. Speciális és nagyon új, modern hardver esetén érdemes lehet saját kernelt fordítanunk. A csomagkezelő beállítása: Az univerese és multiverse tárolókat is hozzá kell adnunk a repozitorikhoz, ugyanis néhány Samba függőség csak itt található meg. A biztonsági frissítések nem települhetnek automatikusan. A frissítéseket saját kezűleg biztonságos elvégezni ,
[27]
-
-
-
mindezt kellő odafigyeléss, és még mielőtt bármibe is belekezdenénk egy biztonsági mentéssel jó megelőzni az esetlegesen előfordulható problémákat. Alap szoftverválasztás és telepítésük: Egy szerver esetén fontos, hogy csak a szükséges szolgáltatások, alkalmazások, kiegészítő szoftverek legyenek feltelepítve. A telepítő viszont felajánlja a néhány – választható – „szokásos” szolgáltatásokhoz szükséges szoftverkörnyezetet, azonban semmit sem kell telepítenünk ezek közül. Végeredményképp egy nagyon minimális alaprendszert fogunk kapni. GRUB rendszerbetöltő telepítése: A /dev/sda1 partícióra telepítjük a rendszerbetöltőt. A „Tervezés” partíciók beállításaira vonatkozó szakaszban említett probléma itt jelentkezett volna. Ha LVMre telepíttettük volna a GRUB-ot, akkor a telepítő hibakóddal állt volna le, s a rendszerbetöltő szoftvert kézzel – egy mentő diszkkel bebootlva – kellett volna telepítenünk. Telepítés befejezése: A feltelepített alap rendszer mindössze kb. 700 MB!
Ábra 12 - LVM és RAID beállítás
Ábra 11 - LVM és RAID beállítás
A rendszer újraindítása után a szerver konfigurációja következik. A legelső dolog, amit meg szoktam tenni egy új szerver felállítása esetén, hogy frissítem (apt-get update && apt-get upgrade -y) a csomag tárolókat és a rendszert, majd telepítem a kedvenc CLI-s editoromat a vim-et, az apt-get install vim paranccsal. A korábban említett eth1-s interfész beállítása a következő napirendi pontunk. Ki kell választanunk egy megfelelő privát IP cím tartományt az intézménynek (virtuális értelemben) Kb. 130 számítógéppel rendelkezik az iskola, így egyelőre elegendőnek bizonyul a 192.168.100.0/24-es privát hálózati IP cím tartomány használata. Módosítsuk a kedvenc [28]
editorunkkal az „/etc/network/interfaces” konfigurációs fájlban a következő paramétereket: address, netmask, network, broadcast, dns-search, dns-nameservers. Fontos, hogy beállítsuk a dns-search és dns-nameservers opciókat: probserv.dioszegi.hu-ra illetve az egyes ethernet kártya IP címe: 192.168.100.1 legyen. A szerverünk még csak pár másodperce van telepítve, de mivel az a világhálóra van csatlakoztatva, máris támadások érhetik (sőt érik is). A kockázat minimalizálása érdekében a világháló felé néző (eth0) interfész lekapcsolása szükséges, vagy „a kábel kihúzása a hálózati kártyából”. A biztonság növelése érdekében a tűzfal feltelepítése és konfigurálása a legelső feladatunk. Mint korábban már említettem, a netfilter a Linux rendszermag szerves részét képezi, így már csak a tűzfal script megírása van hátra, lásd: 4.3.1-s fejezet. Mindezek után kezdődhet a szervizek telepítése, melyeket a következő fejezetek taglalnak.
4.3
Szolgáltatások telepítése és konfigurációja ~ Szerver konfiguráció
Ezen fejezet témája meglehetősen gyakorlati, a szerveren futó szervizek telepítését – többnyire tárolóból – és ezek konfigurálását fogom elvégezni. A főbb mozzanatokat bekezdésekbe szedem, s elmagyarázom az olvasónak, mit miért teszek. Megeshet, hogy nem említek mindent, sőt valószínűleg már korábban ez elő is fordult, de a dolgozat méretkorlátja miatt minden beállítás megemlítésére nincs lehetőség, így csak a legfontosabb beállításokat taglalhatom.
4.3.1 Csomagszűrés „tűzfal” - IPTables A tűzfal tulajdonképpen egy shell script, melyet a parancsértelmező ért meg, s az IPTables alkalmazással fogja – sorban – fentről lefelé feldolgozni. A scriptet személy szerint a „/etc/init.d” alá szeretem tenni, s az ’insserv’ programmal beállítani, hogy automatikusan induljon és álljon is le a rendszer leállásával. Hogy mikor is van az elindulás és leállás szakasza, az a mellékelt script fejléc információjában megtalálható. A script jogosultsága: 0700, azaz a tulajdonosnak (root) van kizárólagos hozzáférése a script-hez, mindenki másnak nincs. Az IPTables program verziója: 1.4.12. Néhányan az iptables-save illetve iptablesrestore beépített parancsok köré írnak egy scriptet, melyet inkludolva az interfészek konfigurációs állományában helyeznek el.
[29]
A script logikailag három fontosabb szakaszra osztható: 1. Változó deklaráció (interfészek, parancsok stb.), modulok betöltése (fő és kiegészítő iptables modulok) és kernel flagek beállítása (pl. TCP SYN cookies védelem) 2. Alapszabály – policy meghatározás 3. Szabályalkotás A változódeklaráció segíti a későbbi munkánkat, ugyanis kevesebbet kell gépelnünk, áttekinthetőbb és könnyedén módosítható lesz a kódunk. Egy kissé előreugorva, de el kell magyaráznom miért is lesz evidens a változó deklarációtól a kódunk. Tekintsük a következő szabályt példaként. $IPT -A FORWARD -i $LAN -o $NET -p tcp --dport 443 -j ACCEPT A szabályon látható, hogy változókkal van megadva egy INPUT illetve egy OUTPUT interfész. Ha ezt explicit megadnánk… $IPT -A FORWARD -i eth1 -o eth0 -p tcp --dport 443 -j ACCEPT … akkor a hálózati kártya esetlegesen előforduló cserélésekor az egész scriptet módosítani kellene, és az elgépelés veszélye és az ezzel eltöltött idő is eléggé magas lenne. A különböző modulok, pl. „iptable_nat” szükséges ahhoz, hogy a NAT funkció működjön. A modul betöltését elhalasztva bárhogy is futtatjuk a tűzfalunkat, a NAT-olás nem fog megtörténni. A kernel flagek beállítása is létfontosságú egy tűzfal esetében. Az IP forward képesség engedélyezése a „/proc/sys/net/ipv4/ip_forward” állományban található „1”-s szám beírásával történik, azaz a bekapcsolt (ON) állapotot jelző érték beállításával. Ezen funkcióval állítjuk be, hogy a szerver képes legyen a hálózati csomagok címfordítására. A policy tűzfalunk tám pillére, ehhez mérten építjük szabályainkat. Meghatározza, hogy alapértelmezetten mi történjen azon csomagokkal, amelyek a tűzfalra érkeznek, s nem illeszkednek semmilyen szabályra. Jómagam azt az elvet vallom, hogy a legjobb minden forgalmat tiltani, és sorban engedélyezni azokat a portokat, amelyekre szükségünk van. Nem szabad feleslegesen portokat nyitogatnunk, ezzel réseket ütni a tűzfalon. A láncainkra adott policy-t a -P kapcsolóval határozzuk meg úgy, hogy a kapcsoló után írjuk, a lánc nevét melyre alkalmazni szeretnénk a házirendet. Ami lehet engedélyezés minden csomagra (ACCEPT) vagy pedig eldobás (DROP). Miután letiltottunk minden forgalmat, kezdjük el szépen lassan feltölteni engedélyező szabályokkal a láncainkat. Az INPUT és OUTPUT láncban engedélyeznünk kell minden loopback-ről érkező forgalmat, ugyanis ez a gépünkön belüli forgalom, nem lenne szép dolog ezt letiltva hagyni. Erről a következő szabály gondoskodik – az INPUT láncban – $IPT -A INPUT –i lo -j ACCEPT
[30]
Talán az egyik legfontosabb szabályunk a visszairányú forgalom engedélyezése. A csomagok visszaérkezésének megértéséhez először is meg kell értenünk a TCP háromlépéses kézfogást, melyet megpróbálok a lehető legrövidebben elmagyarázni. A TCP protokoll az ISO/OSI referenciamodell szállítási rétegébe sorolható összeköttetés alapú – kapcsolatállapot alapú – szállítási protokoll. Megbízhatóan működik, melynek alapját a 3way handshake adja. Egy kapcsolat két végén mindig egy kliens és egy szerver áll. 1. A kliens kezdeményezi a kommunikációt a szerverrel. 2. A szerver fogadja a kapcsolat kiépítési kérelmet és nyugtázó üzenetet küld vissza a kliensnek. 3. A kliens megkapja ezt az üzenetet és jóváhagyó választ küld vissza. Ezek után felépült a biztonságos kapcsolat és megkezdődik az adat továbbítás. Ha engedélyezünk az INPUT láncon egy percenként maximum 5 alkalommal történő SSH belépést a következő formában… $IPT -A INPUT –p tcp --dport 22 -m limit --limit 5/minute --limit-burst 1 -j ACCEPT …akkor a kérés ugyan beérkezik a tűzfalra, de a rá adott válasz nem hagyhatja el a tűzfalat, ugyanis nem engedélyezett az általunk korábban jóváhagyott csomag által kezdeményezett vissza irányuló forgalom, a csomag vissza útja. Ezt a következőképpen tehetjük meg az OUTPUT láncban: $IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT Erre szolgálnak az ESTABLISHED (a kapcsolatkövetés, miszerint már mindkét irányban haladnak csomagok) és a RELATED (a csomag új kapcsolatot szeretne létrehozni, de ez az új kapcsolat már egy létező kapcsolattal van összefüggésben) állapotú csomag állapotok. Most, hogy ekkora nagyot ugrottunk, evezzünk egy kicsit egyszerűbb vizekre. A szabályok létrehozásánál rengeteg finomhangolási lehetőség beállítására van módunk. Ezt láthattuk korábban az SSH kapcsolatok engedélyezésénél. Vesézzük ki azt a parancsot. A „-A” kapcsolóval hozzáadhatunk szabályokat egy adott lánchoz, esetünkben ez az INPUT. A „-p” kapcsolóval egy protokoll megadására van lehetőségünk, esetünkben ez a TCP protokoll. A „-dport” kapcsolóval a beérkező csomag cél portját határozzuk meg, ez a standard 22-es SSH port. A „-m limit” kapcsolóval és a társ kapcsolóival limitálhatjuk, hogy időegység alatt hány csomag érkezhet be. A maximum érték túllépése esetén a további csomagok az idő keret lejártáig eldobódnak. A példában 5 csomag érkezhet percenként, a „--limit-burst” alapértelmezett értéke 5, tehát 5 csomag érkezhetne be percenként, ezért a limithez tartozó burst értéket 1-re állítjuk. Hasonlóképpen járunk el a további szabályok hozzáadásánál is. De érdemes vetni még egy pillantást a NAT beállítására. $IPT -t nat -A POSTROUTING -o $NET -j MASQUERADE
[31]
A „-t” kapcsoló megmondja, hogy melyik táblán, esetünkben a NAT táblán kell, hogy működjön a szabály. Majd hozzáadjuk a PREROUTING lánchoz. Erre a láncra kerülnek a tűzfalat elhagyó csomagok. A „-o” kapcsoló megadja a kimeneti interfészt, a konfigban ez egy nevesített konstans, végül a „-j” vagyis a jump, ugorj kapcsoló megadja a csomagok célterületét. Tehát a kimenő csomagokon végezzünk IP címfordítást – MASQUERADE. Ezen szabály akkor is működik, ha dinamikus IP címmel rendelkezünk.
4.3.2 Dinamikus hoszt konfiguráció - DHCP Jelenleg a tárolókban megtalálható legfrissebb stabil kiadást használom, 4.1 verzió. A DHCP csomagját „isc-dhcp-server” az ISC (Internet Systems Consortium) fejlesztette ki. Természetesen, mint minden szolgáltatásnak, ennek is van egyéb alternatívája, de az egyik legtámogatottabb, legelterjedtebb DHCP szerviz csomag a linuxos környezetben az ISC által szállított fejlesztés. E programcsomagnak a letesztelt stabil kiadását az Ubuntu is beforgatta a saját tárolóiba. De még mielőtt belevágnánk a konfigurációba, és meglepődve tapasztalnánk, hogy nem működik a DHCP szerviz, fedezzük fel a hiba okát a tűzfal beállításaiban. Az előző fejezetben egy tűzfalat konfiguráltunk a szerverünkre, mely elég szigorú. Nem engedélyeztük a DHCP démon felé irányuló forgalmakat – tehát a szolgáltatás elérését a LAN irányából: $IPT -A INPUT -i $LAN -p udp --dport 67 --sport 68 -j ACCEPT A DHCP daemon a 67-es UDP porton üzemel, azonban a kliensek a 68-as UDP porttal kapcsolódnak hozzá. A szabály a belső hálózat felől 68-as UDP forrás portról a 67-es UDP célportra érkező csomagokat engedélyezi. (Gondoskodnunk kell a vissza irányról is, vagyis az ESTABLISHED, RELATED állapotok beállításáról az OUTPUT láncban) Most, hogy feltelepítettük a szervizt, és hozzáadtuk a megfelelő szabályokat a tűzfalunkhoz, kezdhetjük a konfigurációt. A következő kérdések merültek fel bennem a konfiguráció megkezdése előtt: -
Adott IP tartomány dinamikus kiosztása Megfelelő átjáró és DNS kiosztás Esetleges fix IP cím kiosztás adott MAC című gépnek IP cím használhatósági idejének megszabása További biztonsági beállítások, mint pl. autoritivitás, ismeretlen MAC című gépek ki nem szolgálása, stb.
A bemutatásra kerülő konfigurációs fájlt CD-n mellékeltem a dolgozathoz, e fájl fontosabb részein fogok most végighaladni.
[32]
A „subnet” …. „netmask” … { } szekció tekinthető a konfiguráció alapjának, vagy nevezhetjük GLOBAL szakaszának is. Ebben, illetve ezen belül kell konfigurálnunk a korábban megfogalmazott igényeinknek megfelelő elvárásainkat. A kiosztható tartományt a „range” „-tól” „-ig”; opcióval definiálhatjuk, a subnet maskot, broadcast címet, default gateway-t, domain nevet, valamit a DNS szerver IP címét rendre az „option subnet-mask”, „option broadcast-address”, „option routers”, „option domain-name”, „option domain-name-servers” parancsokkal állíthatjuk be. Fontos, hogy a sorok végét pontosvesszővel zárjuk! Társíthatunk a kliensek hálókártyájának MAC címéhez is IP címet, mely IP-t mindig csak az adott MAC című gép kap. Erre ad lehetőséget a következő kód csipet: host Titkarno_Mari{ hardware ethernet e8:40:f2:05:a5:85; fixed-address 192.168.0.80; } Ehhez a beállításhoz hasonlít kissé a group {} szekció, melyet tekintsünk a korábban említett subnet … netmask … {} szekció egy csoportjának. Ez a csoport, mint azt a neve is mutatja, egy csoportra jellemző beállításokat tartalmaz. Külön lehet a csoporton belül felvett hosztoknak egységesen lejárati időt, alapértelmezett átjárót, domain nevet stb. beállítani. Lássunk rá egy fiktív példát: group { option routers 192.168.0.2; host pc21 { fixed-address 192.168.0.21; hardware ethernet AA:BB:CC:DD:EE:FF; } host pc22 { fixed-address 192.168.0.22; hardware ethernet AA:BB:CC:DD:EE:FF; } } Hogy az IP címeket a kliensek ne birtokolják az idők végezetéig, lejárati időt kell beállítanunk. Erre a „default-lease-time” illetve a „max-lease-time” opciók használatosak. A „default-lease-time” után másodpercekben megadott időkeret adja azon időt, amelyet alapértelmezetten a kliensnek nyújt a szerver az IP cím lefoglalására, ha az nem kér másikat (csak kevesebbet kérhet). A kliensnek lehetősége van a default időkerettől nagyobb időre lefoglalni az IP címet, de maximum a „max-lease-time” után megadott időegységig.
[33]
Lehetőségünk van továbbá arra is, hogy az általunk ismeretlennek vélt kliensnek nem szolgáltatunk ki IP címet, de mely kliensek nevezhetőek ismeretlennek? Természetesen azok, amelyeket nem vettük fel a korábban említett „host …” beállítással a konfigurációs állományba. Erre tehát a „deny unknown-clients;” paraméter szolgálatos. Kiegészítő opció, ám hasznos lehet hibakeresés esetén az „authoritative” opció. Ha egy DHCP szerver van a hálózatban, akkor az opció bekapcsolása meglehetősen javasolt. Amikor a kliens IP címet kér a szervertől, a szerver megadhatja, megtagadja vagy válaszolni sem köteles a kérésre. - Tegyük fel, hogy szerepel a konfigurációs fájlban az adott MAC című kliens, tehát ismeri a szerver a kért IP címez tartozó tartományt is. Ekkor a DHCP szerver válaszol a kliensnek és DHCPACK üzenetet küld. - Ha ki van kapcsolva az „authoritative” opció, akkor nem válaszol a szerver a kliensnek abban az esetben, amikor a kért IP cím vagy host nem szerepel a konfigurációs fájlban. - Ha be van kapcsolva az opció, és nem ismeri a szerver a kért IP-t, akkor DHCPNAK üzenetet küld vissza válaszul a kliensnek.
4.3.3 Távoli elérés és menedzsment – SSH Az SSH – mint azt a bemutató fejezetben említettem – igazán megbízható felügyeleti, titkosító eszköz, fájlátvitelre is alkalmas, és még sok minden más is egyben. Egy igazi svájci bicska egy hozzáértő kezében, de, hogy helyesen és biztonságosan működjön, pontosan kell bekonfigurálnunk. Egy rosszul beállított SSH szerviz mellett mit sem ér a szerverünkkel kapcsolatban hozott összes óvintézkedés! Ezen fejezet az SSH biztonságos beállítását taglalja, s végighaladunk a mellékelt konfigurációs fájl fontosabb szakaszain. Jelenleg a legfrissebb stabil SSH verziót használom: „OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012”. A konfigurációs fájl, mint megszokhattuk most is a /etc könyvtár alatt helyezkedik el, a ssh/sshd_config állomány formájában. Az állományban felsorolásszerűen helyezkednek el az SSH daemon működéséért felelős beállítások, ezek közül emelnék ki néhányat. A „Port” direktíva határozza meg, hogy a szerviz mely porton, portokon üzemeljen. A standard 22-s TCP portot, azonban a script kiddie-k és számos internetes robot támadja folyamatosan. Érdemes tehát egy 1024 fölötti szabad portot választani az SSH szolgáltatás üzemeltetésére. Hasznos opció még a „ListenAddress” is, ugyanis itt definiálható, hogy mely IP címen milyen porton figyeljen az SSH szerver. Jó ötlet lehet a használata, ha egy publikus IP címen, egy, a standard porttól eltérő porton üzemeltetjük a szervert, míg a lokális címen a standard 22-es porton hagyjuk a szervert.
[34]
A „PermitRootLogin” beállítási lehetőség engedélyezi vagy tiltja a rendszergazda, vagyis a root belépését a szerverre. Mondanom sem kell, hogy ilyet nem engedélyezünk, akármennyire is biztonságos jelszót használunk. Elengedhetetlen opció a „PermitEmptyPasswords no” beállítása is, ugyanis ez engedélyezi vagy tiltja az üres jelszavakkal történő belépést, ezt mindenképpen „no”-ra kell állítanunk! Megemlítendő még a „LoginGraceTime”, mely után egy mp-ben megadott érték adandó. Ezen ideig lehetséges egy felhasználónak azonosítani magát, a belépés során, különben a session bezárul. Vegyük most a következő direktívát: „PubkeyAuthentication”, melynek bekapcsolásával lehetőség nyílik nyilvános kulcsú hitelesítés használatára. Ez egy nagyon hasznos módszer a rendszerünk biztonságának növelésére. Ebben az esetben előzőleg el kell helyezni a szerveren a belépni kívánó felhasználó nyilvános kulcsát. A belépés során a szerveren tárolt nyilvános kulcs és a usernél található privát kulcs összepárosítása történik. Ez a párosítás és hitelesítési folyamat meglehetősen komplex. Ha ezen átmennek a kulcsok, létrejön az SSH session, és adminisztrálhatjuk rendszerünket. A kulcs alapú hitelesítéskor megkülönböztetünk nyilvános és privát kulcsokat. Ezek a kulcsok párban gyártódnak le. A privát és nyilvános kulcsok kezdetben az ügyfél gépen tárolandók (a legyártás helyén, ált. az adott user .ssh könyvtárában), a nyilvánosak pedig később – biztonságos úton a kiszolgálóra juttatva – a kiszolgálón (az adott user .ssh könyvtárának ’AuthorizedKeysFile’ állományába sorfolytonosan beimportálva). Lényeges, hogy mindig azon user .ssh/authorized_keys fájljában legyen a forrás publikus kulcsa, akinek a nevében be szeretnénk majd lépni. A privát kulcs visszafejtése elég nehéz feladat, szinte lehetetlen (sőt), így SSH szerverünk biztonsága „csak” azon múlik, hogy kinek a nyilvános kulcsát importáltuk be rendszerünkbe, tehát kinek adunk engedélyt a belépésre. Valamint a belépő személy mennyire védi a privát kulcsát. Gyakorlatban a privát kulcsot valóban a kelleténél jobban, szinte paranoiásan kell védeni. Ha el is hagyjuk ezt a kulcsot, azt szintén védi egy újabb védelmi vonal, mégpedig a kulcshoz rendelt passphrase. Ahhoz hogy csak kulcsos hitelesítést alkalmazzunk, ki kell kapcsolnunk a jelszó hitelesítést, a „PasswordAuthentication no” utasítással a kiszolgálón, de vigyázzunk! Ha távolról ezt kiadjuk, és mégsem sikerülne a hitelesítés, mert pl. a szerveren rossz helyre másoltuk a privát kulcsunkat, akkor bizony kizártunk mindenkit a szerverből és csak helyileg lehet belépni… Az ügyfél publikus kulcsának authorized_keys fájlba másolását a legkönnyebben a `cat Nyilvános_kulcs_.pub >> aktuális_user_home_dir/.ssh/authorized_keys` parancs kiadásával tehetjük meg. A nyilvános kulcsnak nem kell bekerülni a .ssh/know_hosts állományba, félre értés ne essék, csak az. authorized_keys fájlban van e néhány sornak a helye. Érdemes az eredeti kulcs fájról a másolatot az .ssh/ könyvtárban megtartani. Az ügyfélnél tárolt privát kulcs helye szintén az .ssh/ könyvtárban van (jó, ha ide tesszük a nyilvános kulcs egy másolatát is), ha nem ott van vagy esetleg több kulcsunk is van, akkor az ssh --i /KULCS/HELYE/maga_a_privát_kulcs … megadásával tudunk belépni a kiszolgálóra a megadott kulccsal.
[35]
A publikus és saját kulcsra 0600-s jogot kell adnunk az ügyfél gépen. A privát kulcsra adott jogok automatikusan: -rw-------. Ez így rendben is van. Röviden a trükkökről. Felmerülhet bennünk a kérdés, hogy lehetséges-e olyat csinálnunk, hogy csak bizonyos csoportoknak vagy felhasználóknak engedélyezzük a belépést. Vajon képes erre az OpenSSH? A válasz egyértelműen igen! Szinte mindenre képes ez az okos kis „jószág”. Ezt a funkcionalitást az „AllowUsers’ és „AllowGroup” direktívák használata segíti elő. Építsünk S-FTP szervert, hmm, mi is kell ehhez? Egészen egyszerű egy Open-SSH. Rögtön mutatok is egy példát: Subsystem sftp /usr/lib/openssh/sftp-server Match user proba ChrootDirectory /home/proba AllowTcpForwarding no X11Forwarding no forcecommand internal-sftp A „subsystem sftp” opció adja meg a biztonságos fájlátviteli rendszer abszolút elérési útját. A „Match user” opcióval adjuk meg, hogy mely felhasználónak engedélyezett az SFTP szerver használata, s mely könyvtárba – „ChrootDirectory”. A /home/proba directory-nak mindenképpen a root tulajdonában kell lenni, illetve léteznie kell a proba nevű felhasználónak. Különböző finomhangolási lehetőségeket is beállíthatunk, pl. engedélyezzüke a TCP forwardingot – ezt az SSH tunnelingnél használja az OpenSSH. Illetve a grafikus felhasználói szerver továbbítására (X11) van-e lehetőségünk. Ezen SFTP szervert gyakorlatban nem szükséges megvalósítanom az intézmény számára.
4.3.4 Proxy - Squid A Squidről tudni kell, hogy úgynevezett ACL-ekkel (Acces Control List), vagyis hozzáférési listák alapján szabályozza a forgalmat. A jelenlegi használt verzió: 3.1.19. Egy alap (kezdetleges) konfiguráció első lépése ezen lista létrehozása, majd ott az adott hálózatrész számára engedélyezni a forgalmat. Miért is mondom, hogy „például” hálózatrész? A Squid nagyon sokszínű és nagy tudású proxy, ezáltal lehetőségünk van nem csak hálózatrészt megadni forrásként, ahonnan engedélyezzük a forgalmat, hanem megadhatunk domaint és regex kifejezésekkel szabályozhatjuk, hogy milyen böngésző által megengedett a proxyhoz való hozzáférés stb. Tehát, egy adott hálózatrészből való kérések kiszolgálásért a következő két sor a felelős: acl localnetwork src 192.168.0.0/24 http_access allow localnetwork
[36]
A konfigurációs állományban szereplő „http_access deny all” sor célja, hogy letiltsa a forgalmat a nem engedélyezett hálózatok számára. A konfiguráció egy másik sarkalatos pontja a „http_port 3128 transparent” sorocska, ugyanis ezen a ponton történik meg annak a portnak a meghatározása, amelyen a Squid figyelni fogja a szerverhez való kapcsolódásokat, illetve itt történik meg az üzemmód meghatározása is. A transzparensmód, mint választható üzemmód fontosságát fentebb kiemeltem, azonban hozzátenném még, hogy ezt az üzemmódot a megfelelő tűzfal szabályokkal is alá kell támasztani, különben nem fog helyesen működni a szerver-kliens kommunikáció. Érdekes pontjai a konfigolásnak a cache_ illetve a maximum_ előtaggal kezdődő konfigurációs parancsok, melyek a proxynk finomhangolásáért felelősek. Pl. a „cache_mem 700 MB” utasítással a memóriában tartunk néhány megabájtnyi cache-t, ezáltal nem írunk állandóan minden objektumot a diszkre, igy gyorsítjuk a kiszolgálást. Hisz nem kell mindig a lemezhez fordulni az újabb olvasási és írási műveletek végrehajtásához.
4.3.5 PDC és fájlszerver - Samba Ahhoz, hogy a Samba 4.1.2 domain kontrollert telepíteni tudjuk, rengeteg elő követelménynek kell megfelelni, s csak ezek után kezdhetjük a szolgáltatás telepítését és konfigurációját. Szükséges egy időszinkronizáló szerver, „ntpd” telepítése. Telepítése a szokásos apt-get install paranccsal történik, majd a konfigurációs állományában – „/etc/ntp.conf” – beállítjuk a magyar időszinkronizációs szervereket. A kliensek ekkor még nem férnek hozzá az NTP szerverünkhöz, ugyanis a tűzfal letiltja a kifelé irányuló NTP kapcsolódási kísérleteket is. Az NTP 123-as UDP portját használó csomagokat ki kell engednünk az internet felé az OUTPUT láncon, hogy a helyes időszinkronizációt a szerver meg tudja tenni, és az INPUT láncon a LAN felől jövő 123-as UDP csomagokat engedélyezve kell a hozzáférést megadnunk a kliensnek a szervizhez. A helyes – azonos – szerver-kliens idő a kerberos hitelesítés szempontjából elengedhetetlen. Az „acl” és „attr” csomagok telepítése is szükséges, majd végül a fentebb említett csatolási opciók beállítása marad hátra a „/opt” illetve a „/srv” könyvtárakra, hogy a Windowsos jogosultsági köröket érvényesíteni tudjuk Linux oldalról. Ezek után felvesszük a Zentyal 3.2-es repositorykat a saját tárolóink közül, hogy innen tudjuk feltelepíteni a legfrissebb Samba verziót, és innen is jöjjenek hozzá a biztonsági frissítéseink: apt-get update && apt-get upgrade -y apt-get install -y python-software-properties apt-add-repository ppa:zentyal/3.2
[37]
apt-get update && apt-get upgrade –y Ezek után végre következhet a samba4 csomag telepítése (apt-get install samba4) és konfigurálása. Első lépés létrehozni a domainünket, melyet a Samba4-ben a samba-tool segédprogrammal végezhetünk el: samba-tool domain provision --use-rfc2307 --interactive A parancs kiadása után hasonló kimenetet kell látnunk: Realm [DIOSZEGI.HU]: Domain [DIOSZEGI]: Server Role (dc, member, standalone) [dc]: DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: BIND9_DLZ Administrator password: Test123 Retype password: Test123 Mindezek elvégzése után létrejön DIOSZEGI.HU tartomány, Bind9 DNS szervert használva névfeloldóként. A Samba4 egy Kerberos-nak nevezett hitelesítési protokollt használva győződik meg a hozzá kapcsolódó kliensek hitelességéről, így a szolgáltatást össze kell kapcsolnunk a Samba4 domainnel. A szokott módon feltelepítjük a szervizt (krb5-user), s a telepítés során a feltett kérdésekre az alábbi módon válaszolunk: REALM: DIOSZEGI.HU Kerberos servers for your realm: probserv.dioszegi.hu Administrative server for your Kerberos realm: probserv.dioszegi.hu A kerberos konfiguráció során végzett lényeges módosításokat a „/etc/krb5.conf” fájlban kell elvégeznünk: [libdefaults] default_realm = DIOSZEGI.HU dns_lookup_kdc = no dns_lookup_realm = no ticket_lifetime = 24h default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5 default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5 permitted_enctypes = rc4-hmac des-cbc-crc des-cbc-md5 [realms] DIOSZEGI.HU = { kdc = probserv.dioszegi.hu
[38]
admin_server = probserv.dioszegi.hu default_domain = probserv.dioszegi.hu } [domain_realm] .dioszegi.hu = DIOSZEGI.HU dioszegi.hu = DIOSZEGI.HU Ezek után a Samba4 képes a kiszolgálók hitelesítésére ám a Bind9 DNS szerverünk beállítására még nem került sor. Ezt a következő 4.3.5-s fejezetben említem, ám lejegyezném, hogy ezen Bind beállítások után a Samba4 szolgáltatás újraindítása is szükséges. A Samba a logokban folyamatosan jelezni fogja a nyomtató-megosztás beállításának hiányát, a virtuális környezet miatt sajnos nincs lehetőségünk megosztott nyomtató beállítására, ezért letiltom ezt a funkciót a Samba konfigurációs fájljában: „/etc/samba/smb.conf” load printers = no printcap name = /dev/null disable spoolss = yes A beállítások letesztelésére immáron már nem az egyszerű testparm -v parancs szolgál, hanem a „samba-tool testparm -v”. Ha mindent rendben talált a diagnosztikai alkalmazás, bátran újraindíthatjuk a samba4 szolgáltatást. Haladjunk tovább a követelmények konfigurálásával, és következzék az NTP beállítás. Az NTP szervert már a DHCP konfigurációban megadtunk, de magát a szervert is be kell állítani. Az „/etc/ntp.conf”-ban végzendő néhány apró módosítás megtalálható a mellékelt konfig fájlok között. Lásd: [I7]. Végül indítsuk újra az NTP szolgáltatást. Most következik az egyik legfontosabb beállításunk, a Sambában létrehozott domain userek, és a helyi usereket tartalmazó felhasználói adatbázis „összefésülése”. Erre való a helyi Winbind és PAM konfiguráció. A Winbind tulajdonképpen a különböző felhasználói név adatbázisok közötti kapcsolásra szolgál. Ezen szolgáltatást kell hozzáfűznünk a rendszer PAM (felhasználói azonosítást végző szolgáltatás) konfigurációjához. A beállítás azért mérhetetlenül fontos, mert később Samba megosztásokat fogunk létrehozni. Ha ezt nem állítjuk be, akkor a Samba domain userek a Linux rendszer felől nem nevekkel, hanem számokkal – magas egyedi azonosító, ID – lesznek reprezentálva, s ezeknek a jogosultságkorlátozása meglehetősen nehézkes és helytelen. Hogyan egyszerűbb egy fájlra való hozzáférést megadni egy felhasználónak vagy csoportnak? A csoportnak/felhasználónak a nevével, vagy kilogikázni, hogy az adott csoportnak/felhasználónak milyen csoport/felhasználói számmal (ID-vel) kötődik a rendszerünkhöz.
[39]
- Első lépésként hozzunk létre magunknak egy normál felhasználói fiókot: samba-tool user add teszt.elek, majd adjuk meg a jelszavát, pl.: Test123 (példámban végig ezt illetve a Test1234 jelszavakat használom majd) - A következő beállítási pont, hogy csak egy csoport tagjai léphessenek be a gépre: samba-tool group add "Linux Admins" - Majd hozzáadjuk a felhasználókat a csoporthoz: samba-tool group addmembers "Linux Admins" teszt.elek - Módosítsuk az nsswitch-et ( /etc/nsswitch.conf ), hogy a user és csoport tagságokat a winbind-ból is megpróbálja előkeresni a rendszer: passwd: compat winbind group: compat winbind - Próbáljuk ki: getent passwd teszt.elek DIOSZEGI\teszt.elek:*:3000019:100:Elek Teszt:/home/DIOSZEGI/teszt.elek:/bin/false /opt/samba4/bin/wbinfo -p Ping to winbindd succeeded /opt/samba4/bin/wbinfo -u Administrator Guest krbtgt teszt.elek getent passwd Administrator DIOSZEGI\Administrator:*:0:100::/home/DIOSZEGI/Administrator:/bin/false A felhasználókat a rendszer már mindkét helyről ismeri, ám mindkét helyen (winbind, passwd fájl hash-ei) más módon vannak tárolva az adataik. Annak érdekében, hogy a rendszerünk az adatok tárolásának módjától függetlenül ki tudja olvasni azokat, konfigurálnunk kell a PAMot. A PAM konfigját a „/etc/pam.d” könyvtárban található, haladjunk sorban a common-auth, common-account és common-session fájlokon és szerkesszük őket a következőképpen: auth: - a felhasználó azonosságát ellenőrző modul konfigurációja auth [success=3 default=ignore] pam_unix.so nullok_secure auth [success=ok default=1] pam_winbind.so try_first_pass auth [success=1 default=ignore] pam_succeed_if.so user ingroup\ [DIOSZEGI\Linux Admins] auth requisite pam_deny.so auth required pam_permit.so
[40]
Ez mit jelent nekünk? A rendszer elsőként a „/etc/passwd” fájlban található információ alapján próbálja meg autentikálni a felhasználót: - Ha sikerül, előre ugrik hármat, a pam_permit-re és engedélyezi a belépést. - Ha nem sikerült, akkor tovább lép a Winbind alapú beléptetésre, ami ha sikerül, akkor még ellenőrizzük, hogy tagja-e a felhasználó a „Linux Admins” csoportnak. - Ha bármelyik hibát jelez, akkor a pam_deny-al megtagadjuk a belépést. account: - a felhasználó engedélyeit hivatott megvizsgálni, hogy rendelkezik-e kellő engedéllyel egy adott szolgáltatáshoz való hozzáférés során account sufficient pam_winbind.so session: - a felhasználó munkamenetének (session-jának) kezeléséért felelős modul session required pam_mkhomedir.so session required pam_winbind.so Próbáljunk meg a 2-es virtuális terminálba belépni. Ennek sikeressége egyértelműen látható, ugyanis megkapjuk a promptot, s ezen felül a belépés során a következő logok fognak keletkezni a felhasználók hitelesítését rögzítő naplófájlban: Dec 11 15:04:31 probserv login[2920]: pam_unix(login:auth): authentication failure; logname=root uid=0 euid=0 tty=/dev/tty2 ruser= rhost= user=teszt.elek Dec 11 15:04:31 probserv login[2920]: pam_winbind(login:auth): getting password (0x00000008) Dec 11 15:04:31 probserv login[2920]: pam_winbind(login:auth): pam_get_item returned a password Dec 11 15:04:31 probserv login[2920]: pam_winbind(login:auth): user 'teszt.elek' granted access Dec 11 15:04:32 probserv login[2920]: pam_succeed_if(login:auth): requirement "user ingroup DIOSZEGI\Linux Admins" was met by user "DIOSZEGI\teszt.elek" Dec 11 15:04:32 probserv login[2920]: pam_winbind(login:account): user 'DIOSZEGI\teszt.elek' granted access A szerverre való belépés nem történhetett volna meg, ha az smb.conf konfigurációs fájlban előzőleg nem engedélyezem a domain userek számára a shellt: template shell = /bin/bash. Esetünkben ez a veszélyes lépés azért történt meg, hogy reprezentálni tudjam az előző LOG üzeneteket, s bizonyítható legyen, hogy tényleg be tud lépni a szerverre a tartományi felhasználó. Azonban ismételten megemlíteném, ez nem egy életszerű, biztonságos megoldás. Egy domain usernek tipikusan nincs jogosultsága belépni a szerverre, csak a felhasználó számítógépekbe történő belépésére jogosult. A domain userek rendszerbe történő belépése alap esetben tiltott, azaz a „/bin/false” van a shellnek megadva.
[41]
Most egy érdekes és szemléletes része következik a dolgozatomnak. A kliens számítógépek domainbe léptetését láthatja majd – képekben – az olvasó, illetve a munkaállomásra administratorként és felhasználóként történő bejelentkezés folyamata is bemutatásra kerül.
Ábra 13 - A számítógép domainbe léptetése
Ábra 14 - Window$ XP Login képernyő
A bal oldali ábrán látható a „sasfeszek” elnevezésű számítógép domainbe léptetése. Ehhez a folyamathoz szükséges megadni a számítógép tartományba léptetését végző administratort – linuxos oldal felől – a hozzá tartozó jelszóval, s a sikeres azonosítás bekövetkezte után jelenik meg 13. ábra jobb olsó sarkában látható üdvözlő ablak. (A beléptetés a következő azonosítóval és jelszóval történt: Administrator:Test123) A számítógép újraindítása után a jobb oldali login képernyő fogad minket, mely ablakba először a fentebb említett azonosítókat gépeltük be. Ezáltal a következő fog történni: - Sikeres belépést hajtunk végre. - A számítógépet (mint tartományi munkaállomást) a rendszergazda birtokába vehetjük. - A jogosultságaink azonosak lesznek egy natív, a számítógép telepítésekor létrehozott rendszergazdáéval. - Ha feltelepítjük az „administrator” – rendszergazdai jogú – felhasználóval az RSaT programot, lehetőségünk nyílik a PDC adminisztrációjára is. A számítógépből való kijelentkezés után egy üres login képernyő fogad majd minket, ahol a következő adatokat kell megadni: felhasználó név, amelyet igénybe véve szeretnénk belépni a számítógépre – Adminsitrator, teszt.elek stb. majd az alatta lévő sorban a felhasználónévhez tartozó jelszavat – példánkban Test123, majd a tartományt ahova a belépés történi fog – DIOSZEGI. Ezzel a sémával bármely létező domain userrel be tudunk lépni egy olyan számítógépre, ahol natívan a belépésre jogosult felhasználók egyike sincs feltelepítve.
[42]
Ábra 14 - A „root” user CLI-ből belépve
Ábra 15 – Domain megkísérelt belépés
adminsitratorral
Ábra 16 – Lejárt jelszó
A szerver gépre való belépés szintén úgy működik, ahogy szeretnénk (főleg az „/etc/pam.d./” alatt végzett beállításainknak köszönhetően). Tehát a következő folyamatokon ment át sikeresen a konfigurációnk: A „root” natív linux administratorral sikeres belépést hajtottunk végre. Ezen fontos mozzanatot ábrázolja a 14. ábra. A domain administratorral való belépés nem lehetséges, ez nem rendellenes tevékenység, ez is egy elérendő cél volt a korábbi fejezetekben. Lásd: 15. ábra A „teszt.elek” domain userrel szintén sikeres a belépés, azonban lejárt a jelszava. A domain user jelszó megváltoztatása a 17-es ill. 18. ábrán látható. Ezen jelszó megváltoztatása elvégezhető – a lejárt jelszó ismeretében – a Login képernyőn megjelenő hiba üzenet OK gombjának leütése után, vagy „root” felhasználóval az Ubuntu Linux szerverre belépve, használva a samba-tool segédprogramot.
[43]
Ábra 17 - A domain user lejárt jelszava XP alól
Ábra 18 - Jelszómódosítás
Tipikusan előfordulhat még, hogy egy diákoknak létrehozott felhasználóval lép be minden egyes diák. Ezért vándorló (roaming) profilt – pl. „hallgato” névvel – kell létrehoznunk. Ebben az esetben sajnos nem olyan egyszerű a dolgunk, mint eddig. A roaming profile beállítása egy részt a Samba szerveren CLI-ből, más részt Windows 7 kliens alól (RSaT feltelepítése után) a „dsat.msc”-ben való állítgatással történik. Kezdjük a beallításokat a szerver felől. Először a Samba konfigurációs fájljában kell alkalmaznunk néhány változtatást: vfs objects = acl_xattr map acl inherit = Yes store dos attributes = Yes logon path = \\%L\profiles\%U Ezen opciók lényege tulajdonképpen csak annyi, hogy a Samba globálisan kezelje az összes későbbi megosztásán a kiterjesztett ACL-eket. Megadásra került a vándorló felhasználó profiljának a helye, ahol a %L a szerver NetBIOS nevét – esetünkben „probserv” – a %U pedig az aktuális felhasználó nevét jelenti. Másodszor az említett „profiles” megosztás definiálása és a path-ban megadott hely létrehozása (mkdir -p parancs): [profiles] path = /srv/profiles/ Profil helye a fájlrendszerben read only = no create mask = 0600 directory mask = 0700 profile acls = yes csc policy = disable
[44]
Végül, mint azt korábban említettem, jöhet az RSaT felőli beállítások sorozata!
Ábra 19 - A „profiles” directory előkészítése
A megosztott „profiles” könyvtár a Samba újraindítása vagy a konfigurációs fájl újra betöltése után kihirdetésre kerül a belső hálózatban, és tallózhatóvá válik. Ezen mappán végezzük el a képen látható beállításokat, mindezt a domain adminisztrátorral belépve. A mappa biztonsági beállításait szerkesztve, a képen látható jogosultságokkal kell felruházni az „Administrátor” és a „Domain user” objektumokat, valamint a „Létrehozó tulajdonost és csoportot”. Látható, hogy ezen jogkörök szabályozásával igazából minden előforduló entitást szabályozunk. Értelemszerűen az adminisztrátornak és a létrehozó tulajdonosnak teljes hozzáférést kell biztosítanunk. A domain usereknek illetve a létrehozó csoportnak csak a kép központjában található jogokat szabad megadnunk! Ezen beállítások szükségesek ahhoz, hogy az adott roaming profilt – a „profiles” könyvtárban – csak az azt létrehozó tudja módosítani, egyáltalán magát a mappát létrehozni, törölni csak Ő tudja. Az arra nem jogosultak pedig ne rendelkezzenek jogokkal arra a mappára ahova nincs jogkörük
[45]
Azonban még nem vagyunk készen, még csak előkészítettük a helyet a profiloknak, lássuk a használatba vételt – szintén RSaT alól.
Ábra 20 – Felhasználó profil helyének meghatározása
A 20. ábrán található mozzanat apropója tulajdonképpen a profil elérési útjának megadása. Ezen beállítás elvégzése után bármilyen gépen „hallgato” tartományi felhasználóval belépő személy észreveheti, hogy a hallgató felhasználói profilja a szerverről fog letöltődni, s ugyanoda fognak feltöltődni az elvégzett módosítások a kijelentkezés után. Óriási előnyként hozható fel ez a tulajdonság egy iskola informatika életében. A beállításaink ezek után könnyedén mozgathatóvá, menthetővé, felügyelhetővé válnak. A tervező szakaszban említett megosztások létrehozása tulajdonképpen hasonlóan történik a profilra vonatkozó részletek kihagyásával, így ezt tovább nem részletezném.
4.3.6 DNS – Bind A Bind működésének megértéséhez vissza kell térni egy kicsit a névfához (8. ábra). A Bind DNS alapvetően a zónákra épít. A zóna pedig a névfa egy adott, összefogott része, ezt gyakorlatban egy fájlként kell elképzelnünk (zónafájl). A zónát felfoghatjuk, mint
[46]
adminisztratív egységet, ami állhat egyetlen domain-ből (gyakran így is van), vagy pedig egy domainből és sok-sok az alá rendelt aldomainből. A zónát először definiálnunk kell, erre a ’named.conf.local’ konfigurációs állomány használatos. Majd megadni a zónafájl helyét, és elvégezzük a jogosultsági beállításokat. Végül a zónafájlt megfelelőképpen szerkesztjük (db.dioszegi.hu, db.dioszegi.hu_inverz az inverznévfeloldáshoz). Definiáljunk tehát egy ZÓNÁT: zone "dioszegi.hu" { type master; file "/etc/bind/zones/db.dioszegi.hu"; allow-transfer { localhost; }; allow-query { 127.0.0.1; 192.168.100.0/24; }; notify yes; also-notify { 127.0.0.1; }; }; zone "100.168.192.in-addr.arpa" { … file "/etc/bind/zones/db.dioszegi.hu_inverz"; … }; Egy zóna definiálását a „zone $zona_neve { } ; sorokkal indítunk, s e csoportba kerülnek a zóna beállításai. A ’dioszegi.hu.’ zónában egy elsődleges, mester típusú zónát készítünk. A master típusú zónához tartozó zóna file-t maga az adminisztrátor szerkeszti az adott szerveren kézzel, a másodlagos szervereken megtörténik a zónatranszfer. Zónatranszfert csak a saját szerverünk végezhet, illetve a kéréseket saját magunktól illetve a 192.168.100.0/24-os tartományban található IP címektől fogad. Lássunk egy ZÓNAFÁJL-t: (db.dioszegi.hu) $TTL 86400 $ORIGIN dioszegi.hu. @ IN SOA probserv.dioszegi.hu. root.dioszegi.hu. ( 20131126 ; Serial 86400 ; Refresh 900 ; Retry 604800 ; Expire 86400 ) ; Negativ cache TTL ; @ IN NS probserv.dioszegi.hu. ; Master Name server ; probserv IN A 192.168.100.1 firewall IN CNAME probserv
[47]
A zónafájlt az elsődleges névszerveren az adminisztrátor saját maga kézzel módosítja. A másodlagos szerverre ez a zónatranszferrel kerül átvezetésre. A zónafájl rekordokból épül fel. A rekordok felépítése a következő: címke ttl osztály típus adatok. A ’címke’ a domain rekord neve. Esetünkben @ kezdődik, mert nem szeretnénk ismételten kiírni, hogy dioszegi.hu.. A nevet a Bind tudja, mivel a zónát ezen a néven definiáltuk, de az ORIGIN a zónafájlon belül is átírható, ebben az esetben a kukac a módosított értéket veszi fel. A kukac, mint behelyettesítő karakter van jelen a konfiguráció során. A ’ttl’ a rekordhoz tartozó lejárati időt (time to live) adja meg, másodpercben. Megadása nem kötelező, de ha kihagyjuk, akkor behelyettesítődik a zónára vonatkozó alapértelmezés. Az ’osztály’ értéke a gyakorlatban mindig IN, azaz internet osztály. Elhagyható. A ’típus’ mező mondja meg, hogy milyen fajta információról van szó. Például egy IP cím-ről (A rekord), name szerver információról (NS rekord) stb. Az „A” rekord a leggyakoribb típus, arra szolgál, hogy egy domain névhez IP címet társítsunk. Esetünkben egy példa A rekordra: probserv
IN
A
192.168.100.1
A „probserv” címkével ellátott record valódi domain neve: probserv.dioszegi.hu.. A Bind ebben az esetben is nagyon segítőkész. Látható, hogy nem kell kiírnunk a teljes nevet, hogy definiálni tudjuk a record tulajdonságait. Elég csak az „előtagot” kiírnunk. Az „NS” record a névszerverek definiálásánál használt típus. Ez adja meg egy domain név szerverét (szervereit): @ IN
NS
probserv.dioszegi.hu.
A „CNAME” record kényelmi okok miatt lett kitalálva, úgynevezett aliasnak is felfogható, vagyis egy másik névvel is hivatkozhatunk egy már létező hosztra. Ekkor mind a firewall.dioszegi.hu. mind a probserv. dioszegi.hu. domain begépelésekor ugyanarra a 192.168.100.1 IP című hosztra gondolunk. firewall
IN
CNAME probserv
Az „MX” record a levelező szervereknél használatos típus. Pl.: @ IN
MX
10
masina.valahol.hu.
Az MX után álló szám egy kötelező paraméter, ami a „jóságát” jelenti a definiált hosztnak. Minél kisebb ez a szám, annál jobb az értéke a hosztnak, annál könnyebben lehet fő levelező szervere a domainnek. A „TEXT” record megjegyzésekre használatos. new
TXT "A gép nem létezik"
[48]
A „PTR” - pointer rekord Ezt a szolgáltatást elsősorban nem emberek és kliensek számára vezették be, hanem a szerver programok használják annak kiderítésére, hogy egy hozzájuk érkezett IP csomag küldője milyen domainhoz tartozik valójában. A DNS rendszerben az in-addr.arpa domain alá tartozó ág szolgálja az IP cím - domain név hozzárendelést. Itt a zónák delegálása az IP címtartomány egyes darabjainak megfelelően történik. Példa (db.dioszegi.hu_inverz) $origin 100.168.192.in-addr.arpa. 1 IN PTR probserv.dioszegi.hu. Az ’adatok’ mező a rekord típusától függő információt tartalmaz. Minden zónában kell, hogy legyen SOA típusú rekord. A SOA kulcsszó után következő paraméternek mindig a zónához tartozó master domain név szerver neve kell, hogy legyen (esetünkben: dioszegi.hu.). Ismétlem, nagyon fontos a pontot kitenni a domain végére, ugyanis ha nem tesszük, akkor a Bind kiegészíti a @-nak az értékével az addig beírtakat és így nézne ki: dioszegi.hu.dioszegi.hu. A második paraméter pedig valójában egy e-mail cím speciális alakban, esetünkben: root.dioszegi.hu. Hogyan is kapunk ebből e-mail címet? Egyszerű: a Bind az első olyan pont (.) jelet tartalmazó karaktert, ami előtt nincs backslash jel (\) azt @-ra cseréli. SOA rekordban található információk: A serial érték nagyon fontos. Az értéknek a változtatása (növelése) kötelező minden egyes szerkesztésnél. Ha szerkesztettük a fájlt, akkor a Binddel ezt be kell olvastatnunk: Ezt a konfigurációs fájl újra betöltésével tehetjük meg, ám ha a serial érték nem nagyobb az előzőnél, akkor az elsődleges névszerver betölti a módosított új konfigurációs fájlt ám a másodlagos szerver nem. A Refresh, Retry, Expire, TTL értékeket igazából nem nagyon érdemes változtatnunk. Elég jól kitalálták már ezeket az értékeket a megalkotók. Most, hogy lefektettük a zónánkban található domainünk helyes működésének alapjait, definiáljunk végre a domainben egy hosztot. @ IN
NS
probserv.dioszegi.hu.
; Master Name server
Már sok mindent tudunk, majdnem kész is vagyunk, de még nincs vége. Mi van eddig meg? Definiáltuk a zónákat, megadtuk a tulajdonságait, létrehoztuk és megszerkesztettük a zónafájlt, a rekordokat felvettük, de még nem adtuk meg, hogy mégis ki fér hozzá a zónáinkhoz. Erre a „named.conf.options” konfigurációs állományban használt bejegyzéseket kell szem előtt tartanunk. Hozzunk létre egy acl-t a LAN számára. A LAN ezen beállításunk után, illetve a Bind újraindítását, a DHCP beállítását és egy-két tűzfal szabály kiadását követően használni tudja a DNS szervert.
[49]
Az „acl” direktíva után meg kell adnunk egy nevet, ami azonosítja a LAN-t. Az egyszerűség kedvéért legyen „lan”, s utána kapcsos zárójelek között pontosvesszővel felsorolva megadjuk belső hálózat IP cím tartományát. Fontos, hogy az ACL lezárása után pontosvesszőt tegyünk.: acl lan { 192.168.100.0/24; }; Ezek után következhet az options {….; }; direktíva, melynek törzsében soroljuk fel a Bind-re alkalmazott opciókat. Pl. allow-query { localhost; lan; }; allow-recursion { localhost; lan; }; Az első sor megadja, hogy kitől fogadja a Bind a kéréseket. A második sor pedig definálja, hogy mely klienseknek válaszoljon a Bind a saját zónáin kívül eső adatokkal kapcsolatban. SAMBA4 specifikus beállítások: A 4-es verziójú Samba telepítése után – abban az esetben ha BIND9_DLZ vel telepítettük – létrehoz a „/opt/samba4/private” directory alá egy AD zónát. Ezen zónát tartalmazó zónafájlt kell importálnunk a Bind9 zónafájljai közé. Ezt a Bind központi, zónákat összegyűjtő adatbázisába a „/etc/bind/named.conf.local” fájlban kell elvégeznünk: include /opt/samba4/private/named.conf; A korábban beállított két dioszegi.hu és az inverz dioszegi.hu-t bátran távolítsuk el, ezekre már nincs szükség. A további zóna konfigurációt nem a megszokott kézi konfig fájlban való keresgéléssel végezzük el, hanem a samba-tool segédprogrammal. Fontos, hogy a „/opt/samba4/private/named.conf” zóna fájlt és az „/opt/samba4/private/dns.keytab” adatbázis fájlt adjuk át a „bind” csoportnak (chgrp parancs), majd adjunk a Bind csoportnak olvasási jogot a fájlokra (chmod). Teljes jogosultságot kell adni a zóna hozzáféréshez a belső hálózatunknak. Ezért hozzuk létre a „/opt/samba4/private/named.conf.update.static” fájlt a következő tartalommal: grant DIOSZEGI.HU ms-self * A; grant DIOSZEGI.HU wildcard *.100.168.192.in-addr.arpa PTR; A "/etc/bind/named.conf.options” fájl „listen-on-v6{}” sor utánra írjuk be a „tkey-gssapikeytab "/opt/samba4/private/dns.keytab";” opciót, így a megadott .keytab fájlról innentől kezdve a Bind is tud. Egy Ubuntu server a telepítése közben – ha akarjuk, ha nem – az feltelepít és beállít egy szigorú biztonsági szolgáltatást, amely a kritikus rendszer szintű állományok hozzáférhetőségét szabályozza.
[50]
Ezen szolgáltatás neve: Apparmor. Ezen szolgáltatás tiltja a Bindnek az „/opt/samba4/” alatt található néhány fájl elérését, amely szükséges a Bind számára a fentebb említett okok miatt. Így ezen fájlok elérését engedélyeznünk kell. (Ezeket mind honnan tudom? A rendszer napló fájljából a hiba kiolvasható volt) A legelső sor leírja, hogy az /usr/bin/named bináris milyen korlátozásokkal és engedélyekkel rendelkezik. /etc/apparmor.d/usr.sbin.named /opt/samba4/private/** rkw, /opt/samba4/private/dns/** rkw, /opt/samba4/lib/** rm, /opt/samba4/lib/bind9/** rm, /opt/samba4/lib/private/** m, /opt/samba4/lib/gensec/** r, /opt/samba4/lib/ldb/** r, Utolsó lépésként létre kell hoznunk a zónákat, és hozzáadnunk az adatbázishoz. Zónák létrehozása, hozzáadása, és a helyes kimenet: samba-tool dns zonecreate probserv 100.168.192.in-addr.arpa Password for [
[email protected]]: Zone 100.168.192.in-addr.arpa created successfully samba-tool dns add probserv 100.168.192.in-addr.arpa 1 PTR probserv.dioszegi.hu Password for [
[email protected]]: Record added successfully Ellenőrizzük a 192.168.100.1 (tehát a szerverünk LAN felé néző hálózati interfészén található) IP cím feloldását az nslookup paranccsal. Kimenet: Server: 192.168.100.1 Address: 192.168.100.1#53 1.100.168.192.in-addr.arpa name = probserv.dioszegi.hu. Majd indítsuk újra az apparmor és Bind9 szolgáltatásokat. Pl.: service apparmor restart
[51]
4.4
Tesztelés
A továbbiakban ellenőriznünk kell az elvégzett munkánk gyümölcsét. A tesztelést a kliens virtuális gépeken végezzük, ehhez két különböző teszt operációs rendszert telepítettem az egyegy virtuális hosztra. Az operációs rendszerek, amelyekkel tesztelni fogunk tehát a Windows XP Professional 2003 illetve a Windows 7 Ultimate. A tesztelés oroszlánrészét – mint mindig – most is a Samba szolgáltatásainak tesztelése adja. A korábbi fejezetekben elkészített megosztásokat a belépés lehetőségét, jogosultságát le kell tesztelnünk, ezen fejezet tehát a különféle tesztekről fog szólni. A jogosultságok ellenőrzésének a legegyszerűbb módja, ha bizonyos védett fájlok elérésével próbálkozunk egy illetéktelen személy nevében. Abban az esetben, ha a próbálkozások során csak olyan objektumokhoz férünk hozzá, amelyhez az adott tartományi felhasználónak valóban joga van, akkor nyugtázhatjuk beállításaink sikerességét. Ezen teszteket persze alaposan és kellő körültekintéssel kell végezni. A felhasználóknak tudniuk kell fájlokat létrehozni, elérni, módosítani, törölni stb. ezen opciókra is oda kell figyelnünk. Majd a további fontos szolgáltatások ellenőrzése következik, mint például az IPTables tűzfal scriptünk tesztelése, proxy kipróbálása, esetlegesen egy proxy által szolgáltatott hiba kód produkálása, lásd: Error 404 stb.
4.4.1 Teszt üzem 1 A tesztelés első fázisában tartományba léptetem a két különböző – manapság gyakori – operációs rendszert futtató kliens számítógépet, s az összes korábban létrehozott tartományi felhasználóval megkísérlem a belépést (mindkét rendszerbe). Ha ezen lépés sikeres ellenőrzöm, hogy a megosztások elérése rendben megtörténik-e vagy sem. Végül az összes jogosultsági kört ellenőrzöm, pl.: a rendszergazda, igazgató, tikárok jogosultságait stb. Az implementációs szakaszban látható volt a Windows XP operációs rendszerrel telepített munkaállomások tartományba léptetése, bemutatásra kerül ezen felül a kliensek hálózati beállítása, valamint a Microsoft Windows 7 kliensek beléptetése a tartományba, majd a tartományi felhasználókkal való belépés is. Egy-két képet kiragadok, hogy látható legyen a folyamat sikeressége, ám a beléptetést az összes domain userrel teszteltem mindkét operációs rendszer alól. Tehát az első három napirendi pontunk készen van.
[52]
A 21. ábrán található nézet csak adminisztrátor felhasználóként hívható elő, normál domain felhasználónak nincs jogosultsága a TCP/IP protokoll beállítására. Ez alól a Windows 7 operációs rendszer kivétel. A 22. ábrán látható egy tartományi felhasználó „Csoki Gyár” felhasználónévvel. A hálózati beállítások részleteinél látható még, hogy a 192.168.100.0/24-es alhálózatot használom, s a kliensek egy IP címet kb. 10 percig birtokolhatnak. Fontos megemlíteni, hogy alapesetben a lejárati idő fele után azt újra kell kérnie a kliensnek. Ha ez nem történik meg, és a használati idő lejár, a DHCP kiszolgáló kiosztja más entitásnak az IP címet. A 24 bitet tartalmazó hálózati maszk (255.255.255.0) 256 db. IP cím megcímezését teszi lehetővé az alhálózatban, melyből le kell vonnunk kettőt (magát az alhálózatot azonosító 192.168.100.0 cím, illetve a 192.168.100.255 IP című üzenetszórási cím). Általában a szerveren az első vagy az utolsó kiosztható IP címet adjuk meg. Én jelen esetben az első, azaz a 192.168.100.1/24-es IP címet választottam. A választott tartomány a jövőre nézve is jó darabig elegendő lesz az intézmény számára.
Ábra 21 léptetetve
–
Windows
XP
tartományba
Ábra 22 – Windows 7 „Csoki Gyár” tartományi felhasználóval belépve
[53]
Ábra 23 - Windows 7 „Boros Hordó” tartományi felhasználóval belépve
Talán a legszemléletesebb eredményünk a tartományi felhasználó vándorló profiljának megvalósítása. A vándorló – roaming – profil működésének helyességét a 24. ábra igazolja. A korábbi fejezetekben szó esett a vándorló profil létrehozásáról a „hallgato” felhasználóra nézve. Ezen beállítások elvégzése után kijelentkeztem a virtuális számítógépből, melyre korábban a „hallgato:Test123” azonosítóval és jelszóval voltam belépve, s ellenőrizni kezdtem a szerver konzolján az „/srv/profiles” könyvtárában történt változásokat. A „hallgato” felhasználó belépése után a „profiles” könyvtár alatt létrejött a hallgató nevével jelzett „hallgato” profil könyvtár. Ezt minden bizonnyal jó jelnek vehetjük. Ezen sikerek után felbuzdulva elvégeztem néhány személyes beállítást a felhasználóval, mint pl. egyedi háttér beállítás, asztali parancsikonok elhelyezése, valamint egy könyvtár létrehozása az asztalon. Mit tudunk eddig? A „hallgato” domain felhasználó natívan nincs jelen a kliens gépeken, de minden kliens gépen be tud lépni. A tartományi felhasználók mindegyike natívan kizárólag a PDC-ben van jelen. A felhasználók profilja az első bejelentkezés után a kliens gépen jön létre „hallgato” esetén ez a „C:\Documents and settings\hallgato” könyvtár (Windows XP operációs rendszer alatt). Ezen profil a számítógépen marad a leállítás után is, ám ha vándorló profilokról van szó, akkor a létrejött profil minden egyes kijelentkezéskor a szerverre töltődik fel. Hogy meggyőződjünk a roaming profil helyes működéséőül, erre utaló nyomokat kell keresnünk a „../profiles/hallgato” directory alatt. Ez kijelentkezéskor meg is történt, s ha a 24. ábrára pillantunk látható, hogy a létrehozott mappa is megtalálható a szerveren. Tehát működik a szolgáltatásunk. Ezen túl bármely változás, melyet a „hallgato” felhasználó alkalmaz saját profiljában az a kijelentkezés alkalmával szinkronizálódik a szerverre. Jogosan merül fel bennünk a kérdés, hogy ha minden egyes kijelentkezéskor és belépéskor megtörténik a szinkronizáció, akár egyszerre több helyről is, akkor az nem okoz-e megugró hálózati adatforgalmat. A válasz egyszerű: igen.
[54]
Viszont a felhasználók a tipikus nagy fájlokkal a megosztott könyvtárakban dolgoznak, a profilban pedig csak a változások kerülnek szinkronizálásra.
Ábra 24 - roaming profile
Abban az esetben, ha a vándorló felhasználó egy olyan munkaállomásra kísérli meg a bejelentkezést, ahová eddig még nem tette – tehát ez lesz az első bejelentkezése – akkor a bejelentkezés alatt történő szinkronizálás hosszabb időt és nagyobb hálózati forgalmat fog felemészteni, mint azt megszoktuk, ám ez a későbbi bejelentkezések folyamán beáll a normálisra.
4.4.2 Teszt üzem 2 Ezen alfejezetben ellenőrzésre kerül a tűzfalunk egyes szemléletesebb részének bemutatása, a böngészéshez szükséges szolgáltatások működésének helyessége, illetve ezen felül szemléltetni szeretném a Linux kiszolgáló interfészeinek, routing táblájának beállításait is, mindezeket a Linux parancssoros konzolján át.
[55]
Ára 26 – Ping névfeloldással
Ábra 25 – Interfész konfiguráció és routing tábla
A korábbi fejezetekben beszéltünk az IP cím tartomány kiosztásáról, beállításáról, illetve a hálózati beállítások tesztelésre is kerültek, hiszen helyes IP kommunikáció nélkül nem működne a tartományi belépés, a megosztások elérése, a böngészés vagy akár a szerver LAN felőli pingelése sem. A 25. ábrán látható a két virtuális Ethernet interfészünk konfigurációja, illetve a szerver routing táblája. Minden hálózati kommunikációra képes eszköz rendelkezik saját IP címmel, melyet egy fizikai (vagy virtuális) csatolóhoz köt, ezáltal rendelkeznie kell a csomópontnak routing – azaz forgalomirányítási – táblázattal is. Tehát nem csak a hálózatunk központjában található kiszolgáló szerver rendelkezik ezen tulajdonságokkal, hanem az egyszerű otthoni számítógépünk is. Véleményem szerint az interfészkonfigurációt tekintve magyarázatra mindössze az RX/TX jelölések szolgálnak. A rövidítések a Receive (átvesz, fogad) illetve a Transmit (továbbít, küld) szavakból származnak. Az eth2-s NIC a szerverünk internet felé néző oldala, mely a fotó készülésének pillanatában kb. 315 kilobájtnyi adatot (kb. 3400 csomagban) fogadott, és egy megabájtnyi adatot küldött tovább. A TX számláló akkor is nő, ha az eth1-es kártyára kötött hálózatból valaki megpróbál csatlakozni az internetre, melynek oka egyértelműen felfedezhető a routing táblában. A forgalomirányítási táblázat működését – nagyon röviden – az alábbi példával szemléltetném. 1. A 192.168.100.x IP című kliens kísérletet tesz az index.hu (217.20.130.99) elérésére. Feltételezzük, hogy minden előfeltétel teljesült, pl. sikeres hálózati kommunikáció: L1-L7-s ISO/OSI rétegeken keresztül. 2. Beérkezik tehát a szerverre az IP csomag, routolódik (tűzfal), működésbe lép a routing tábla (a process „ÉS” műveletet hajt végre a cél cím és a routing tábla bejegyzésein, „longest prefix match” szerinti sorrendben, s az illeszkedő soron vagy a default routeon küldi a csomagot). A legkisebb prefix hossz miatt az alapértelmezett átjáróra minden cím illeszkedik. [56]
3. Végül elküldi a kérést a szerver az eth0-s vagy a match-elő interfészen. (217.20.130.99) 11011001.00010100.10000010.01100011 (255.255.255.0) 11111111.11111111. 11111111.00000000 ----------------------------------------------------11011001.00010100.10000010.00000000 217.20.130.0 Azaz nem egyezik az utolsó két cél hálózattal, melyhez a 255.255.255.0-s alhálózati maszk tartozik, így a csomag az eth0-s interfészen fog továbbítódni. Ugyanis a 0.0.0.0 alhálózati IP címre (default gateway) minden IP cím matchel. Ezért nő tehát az eth0 interfész TX számlálója. A 26. ábrán található ping bizonyítja, hogy a DNS és tűzfalszolgáltatásunk (scriptünk) is működőképes.
Ábra 27 - Láthatóan működik a NAT – tűzfal, DNS, Proxy szolgáltatásunk.
Ábra 28 – Proxy reagálása, ill. cache könyvtár szerkezete
[57]
A 27. ábrán látható böngészési folyamat, illetve az index.hu weblap pingelése egy Windows XP operációs rendszert futtató kliensen készült. A képernyőképek szemléltetik a szolgáltatásaink összehangolt működését. Látható, hogy a böngészéshez rengeteg fontos egymásra épülő szolgáltatás szükséges. Nem szeretnék végigmenni az ISO/OSI referencia modell 7 rétegén, de ha csak a hálózati és transzport rétegre fókuszálok, máris látható, hogy mi mindenre van szükségünk. Pl. a TCP/IP protokoll stack helyes működésére, szabályos IP kommunikációra, routolásra, NATolásra, a tűzfalunk helyes működésére. Szükséges továbbá a böngészéshez a névfeloldás, valamint esetünkben a transzparens proxy is, ám ez még nem elegendő, az IP csomagok routingolása, forwardolása, a tűzfal helyes működése talán a legfontosabb. Mindezek működését tehát kiválóan szemlélteti a 27. ábra. A 28. ábrán mindjárt egy proxy szerver által szolgáltatott hiba üzenettel állunk szemben, s láthatóvá válik, hogy a háttérben csendesen egy proxy kiszolgáló működik. Az ábra alján látható továbbá a Linux rendszer felől, hogy hogyan is néz ki a cache terület könyvtárszerkezete. Feltűnhet a számunkra, hogy még alig böngésztünk, de már fel is használtunk 101 megabájtnyi területet. Ha nagyobb méretű, akár több gigabájtnyi cache terület gyűlik össze, a felhalmozott adatmennyiség – azáltal, hogy a belső hálózatról töltődik le – jelentősen képes növelni a hálózati kapcsolat sebességét, valamint nem utolsósorban jelentős sávszélességét is takarít meg.
[58]
5. Ajánlás a jövőre Ezen fejezetben egy olyan átfogó ajánlást szeretnék adni egy oktatási intézmény számára, amelyeket elvégezve egy igazán modern, naprakész informatikai rendszert tudhat majd magáénak. Tény és való, hogy e változtatások nagyobb költséggel járnak, ám a mai fejlődő világban minek, ha nem az oktatásnak kell(ene) a felnövekvő „informatikus” növendékek számára a legjobb technikával szolgálni, hogy Ők fejlődhessenek… Oktatásukat minél magasabb szinten kellene végezni. A magas költségek mellett szóljon még, hogy például a strukturált passzív hálózat kialakítását csak egyszer kell elvégezni 40 évente, és ez, ha valóban jól van megtervezve, akkor egy hosszantartó és minőségi szolgáltatás alapjául tud szolgálni.
5.1 Hálózat Mindenekelőtt az épület kábelezésének rendbetétele lenne a feladatunk. Előre tekintve a jövőre min. 6-os kategóriájú FTP kábelek (bővebben: [F3]) behúzása lenne a cél, s egy központi helyen végződtetni a kábeleket. Tehát szükségessé válik egy szerverszoba kialakítása, megfelelő rack szekrénnyel, szekrényekkel, s a hozzá szükséges kellékekkel. Egy szerverszoba kialakítása nem egyszerű, és egyáltalán nem olcsó feladat. Komoly szakmai jártasságot, tapasztalatot, valamint megfelelő humán erőforrást feltételez. A befutó kábelek végződtetését a rackszekrény patch panelének portjain kell végződtetni. Kb e pontig tart a passzív hálózat, de hogy működjön is a hálózatunk, s ne csak gyönyörködjünk az alkotásunkban, aktív eszközökre is szükségünk lesz Bővebben: 5.2. fejezet Gondoskodnunk kell a szekrény megfelelő áramellátásáról, a terem klimatizálásáról és a biztonságtechnikáról is. A folyamatos áramellátás biztosítása érdekében szünetmentes tápegységeket kell elhelyeznünk, valamint a szoba klimatizálása az ott üzemelő rendszerek túlmelegedésének elkerülése miatt meglehetősen fontos. Egy szekrényben tipikusan az idő múltával egyre csak sokasodnak a jelentős hőtermeléssel működő aktív eszközök. Nem témája a dolgozatomnak az IT biztonságtechnika, de érintőlegesen fontosnak érzek megemlíteni néhány dolgot. Ahhoz, hogy kellően megbízható legyen rendszerünk biztonságossá kell tegyük a „környezetetét” is. Ez alatt értem azt, hogy a kialakított szerverszobába csak az illetékesek számára legyen engedélyezett a bejutás. Hiszen mit ér egy kiépített infrastruktúra, ha bárki könnyedén hozzáférhet, s akarva vagy akaratlanul tönkre teszi (teheti) azt. Tehát a legfontossab feladatunk a védelem! Nem léphet csak úgy be bárki egy ilyen központba, erre külön policyt kell felállítanunk. A szoba környezeti behatásokból adódó védelméről is gondoskodnunk kell. Ha vannak ablakok, azokat ráccsal és árnyékolóval kell ellátni, hogy a nap sugarai ne melegítsék feleslegesen az eszközöket, s egy behatoló dolgát megnehezítsük. A beléptető rendszer, biztonsági ajtó felszerelése stb. biztosítja az [59]
illetéktelen behatolás elleni védelmet. Gondoskodnunk kell a megfelelő mesterséges fényviszonyok kialakításáról, esetleg megfigyelő rendszer telepítéséről is és a tűzvédelmi előírásokról még nem is esett szó. Mint járulékos dolog, egy rack szekrény (+szerver szoba, strukturált hálózat) átadásnál kiemelten fontos a megvalósulási jegyzőkönyv, mely tartalmazza a következő dokumentumokat: • • • • •
•
Elvi rajz a hálózatról, vagyis, hogy a szekrényben található eszközök hogyan kapcsolódnak egymáshoz. Rack szekrény típusa A beépített (beszerelt) aktív (forgalomirányítók, kapcsolók, modem-ek stb) és passzív (patch panelek, kábelek, fali aljzatok stb) eszközök pontos típusa Rack szekrény rajz, melyen látható az eszközök logikus elhelyezkedése Patch lista: a szekrényben található kapcsolódási pontok (switch portok és patch panel portok kapcsolódása, router portok és switch portok kapcsolódásai, switchswitch portok kapcsolódása stb.) Színkódolás: A felhasznált színes kábelek mit jelentenek. Pl. piros: trunk portok, kék: bejövő vonal, fekete: munkaállomások stb.) Minden rack szekrényben szükséges volna egy ilyen dokumentumnak lennie. A valóságban azonban ez ritkán van így. A szekrény feléíptése közben fontos, hogy figyeljünk a szellőzése biztosítására. A rackszekrény-rajz (az eszközök melyik rack unitba kerültek, a kábelek elvezetési módja stb.) elhelyezésére. A kábelek/portok helyes feliratozás különösen fontos. A kábelrendezőkről: Egy rack szekrényben általában (kezdetben nem, hiszen felültervezzük rendszerünket, de előbb vagy utóbb biztosan) hatalmas kábelrengeteg halmozódik fel. Az ebből adódó hibák kikerülésére, valamint az esztétikai szempontok miatt is kábelrendezőket használunk, melyek segítik az óriási „madzag” köteg menedzselését. Ezen feladatokat segítik még a kábelrendező gyűrűk, gyűrűs panelek, kábelkötegelők, stb.
Ábra 29 - Conteg 42U magas álló rack szekrény (Pl. a Contag, R&M, IBM, stb Rack szekrények jó minőségűek), Forrás: http://www.aqua.hu/
[60]
A vásárlásakor a következő néhány szempontot kell szem előtt tartanunk: • Az eszköznek védenie kell a kábeleket a külső sérülésektől: a becsípődéstől, a szigetelés megsértésétől, a kábel minimum hajlítási szögétől, nagyobb szögben való behajlításától. • Méretezhetőség és rugalmasság: az idő előrehaladtával lehetőség legyen a rendszerbe több kábel elhelyezésére is. A kábelek bármilyen irányból történő bevezetésére is alkalmas legyen a rendszer. • Problémamentes átvezetés biztosítása a horizontális kábelezés felé. • Tartósság. Egy RACK felépítése, „belakása”: Általában felülről lefelé töltjük fel a szekrényt, de az ügyfél ezen módosíthat… A nagy hőtermeléssel járó eszközök kerülnek felfelé, hogy ne fűtse alulról a felette elhelyezkedő eszközöket. A súlyos eszközöket a stabilitás és a későbbi üzemeltetés miatt a szekrény aljára kelll elhelyezni. Véleményem szerint egy oktatási intézmény nyugodt szívvel szánhatja rá magát egy ilyen típusú szekrény megvételére.Ez a hatalmas óriás (Ábra 29) kb. 500 kg tömegű, és több mint 200.000 Ft értékű. Valóban hatalmas mind az ára mind pedig a tömege, de tartsuk szem előtt, hogy évekre előre kell terveznünk. Képzeljük el, hogy a szekrénybe befut kb. 500 db merev, nehezen kezelhető hálózati fali kábel. Alapvetően csak ezeknek nagy helyre van szüksége, s még nem is beszéltünk az UPS-ekről, az aktív eszközökről, mint pl. router-ek, switch-ek, rack kivitelű szerverek. Véleményem szerint az iskolába 2 db ilyen szekrényre lenne szükség, valamint a nagyobb hálózati gócokba, mint pl. informatika terem, titkári-, tanári-, igazgatói szoba környéke 2-3 kisebb 10U magas, falra szerelhető Conteg szekrényre. Ezen két nagy szekrényt optikai kábellel kell összekötni, s természetesen ezen optikai kábeleket optikai patch paneleken kell végződtetni. A szekrényt fel kell szerelni további hasznos „földi jóval”, mint például az átláthatóságot és könnyen kezelhetőséget segítő kábelvezető gyűrűvel, gyűrűs panellel, (Ethernet lévén) Cat6 patchpanelekkel, néhány rack kivitelű HP/DELL/IBM szerverrel és szünetmentes tápegységekkel.
Ábra 30 – Fali 10U magas Conteg szekrény, Forrás: http://www.aqua.hu/
[61]
A szekrényben található aktív eszközök, illetve a szünetmentes tápellátást biztosító magas feszültségű eszközök működésük során nagy hőt termelnek. Ha ehhez még párosul egy rosszul hűtött szerverszoba, vagy hirtelen elromlott klimatizáló berendezés, túlmelegedhetnek az eszközeink. Így, hogy a levegő áramlását egy kissé elősegítsük, behelyezhetünk tető ventilátorokat. A 230V-os tápkábelek csatlakoztatására elosztósávot kell behelyezni, illetve külön kábelcsatornát a számukra.
5.2 Hardver A jelenlegi két szerver idővel elavul, meghibásodik, lelassul, ekkor megfontolandó a két gondolatmenet, miszerint a jelenlegi szerverek fejlesztése, vagy egy új hardver vásárlása lenne megfelelő az intézmény számára. Véleményem szerint a csere egy kb. 6-8-10 évet futott szerver esetén – persze csak ha az anyagi oldallal nincs probléma – nem is kérdés. No de mire cseréljük? Tegyük fel, hogy már megvalósítottuk az „álmunkat”, s kialakítottunk egy ideális strukturált hálózatot. Építsünk hát erre! Lássuk, mink van eddig. Rendelkezünk egy-egy központi rack szekrénnyel a fontosabb helyeken, melyben akad még üres hely. Töltsük fel a kihasználatlan helyeket úgy, hogy anyagi szempontból az még beleférjen és az elvárásainkat hosszú távra kielégítse. Vennünk kell egy olyan erős, rack kivitelű, redundáns szervert, ami előreláthatólag jó néhány évig elegendő lesz a számunkra. Jó választás lehet ekkor a „HP Proliant DL170e G6” típusú szerver, mely a következő tulajdonságokkal rendelkezik:
Rack kivitel, 2 U magas, kb. 35-40 kg Akár 2 db Intel® Xeon® 5500 series és Intel® Xeon® 5600 series családból származó számítási egység is belekerülhet. A 16 db RDIMM vagy UDIMM slotba akár 192GB-nyi DDR3-as ECC (hibajavító) memória is behelyezhető. 24 db SAS/SATA csatlakozók szolgálnak a HDD/SSD-k csatlakoztatására Beépített (Smart Array B110i SATA RAID) dedikált hardver RAID vezérlővel találkozhatunk. A hálózatra való csatlakoztatásról egy két portos – integrált – HP gigabites hálózati kártya gondoskodik. A távoli menedzselhetőségről az iLO gondoskodik. Redundáns tápegység. A rack kivitel előnyeként megemlíthető a helytakarékosság, mely igen fontos tényező lehet egy zsúfolt szekrényben. Előbb utóbb mindig zsúfolt lesz egy rack szekrény, mindezt az alacsony költségvetésnek köszönhetjük. Azonban e szerver esetében jómagam nem ezt
[62]
tekintem a legfőbb előnynek, hanem a kompakt kivitelt, s precíz megvalósítást, és jó ár/érték arányt. Egy, a fent felsorolt tulajdonságok maximális kihasználásával felszerelt szerver egy ekkora részre összesűrítve, igenis hatalmas mérnöki tudást feltételez. A hatalmas teljesítményt elérni könnyű: a szerver fedelét felhajtva elénk tárul a hardver, melyet így könnyű bővítenünk. Ekkor ki sem kell szerelnünk a szervert a rackből, egyszerűen kihúzzuk az oldalára felszerelt sínek segítségével, felhajtjuk a fedelet és szerelhetővé válik az eszköz. A fent felsorolt processzorcsaládok közül választott Intel® Xeon® Processzor X5550 CPUból kettőt a szerverünkbe helyezve eddig soha nem látott számítás teljesítményt kapunk. Persze ez világviszonylatban nagyon kevés, de intézményünk számára bőven sok. Egy ilyen CPU-ból egy db 4 maggal rendelkezik és magonként két program párhuzamos végrehajtására van lehetőség (Hyper Threading) valamit 3 GHz körüli órajellel számolhatunk (magonként!) . Valljuk be őszintén, ez nem kis teljesítmény. Talán elég lesz jó néhány évre, s még nem is beszéltünk a 192 GB-nyi memória lehetőségéről. Azonban e szerver tápellátásról is gondoskodnunk kell, ez komoly feladat, s megoldásához tudnunk kell mi fog még a szekrénybe kerülni. Lássuk tehát az aktív hálózati eszközöket… Az intézmény 150-200 db csomópont csatlakoztatását szeretné megvalósítani (de ha egy intézmény szándékai mögé nézünk, akkor belátható, hogy ezen felül kell terveznünk néhány végponttal). Kb. 5-7 gigabites switchre (néhány PoE-s ra) és egy routerre van szükségünk. Alacsony költségvetés mellett jó választás lehet a switch tekintetében a „Planet GSW-2401” (40.000 Ft/db) Ezen switch rengeteg hasznos tulajdonsággal rendelkezik: 24 db. 1000 Mbps-os port, rack kivitel, kis fogyasztás, jumbo frame támogatás – azaz extra nagyméretű kereteket használva gyorsíthatjuk a hálózatot. Ezen switch-ből érdemes 5db-ot venni. (Szóval eddig kb. 5*20-22, azaz 100-110 végpontnyi port áll rendelkezésünkre) „Planet FGSW-4840S” (50.000 Ft/db) 48 db. 100 Mbps-os port és 2 darab 1000 Mbps-os port az uplinkelésre. Valamint két SFTP modul is található benne, így akár optikai csatlakozásra is képes. Ezen switch-ből elegendő a számunkra egy darab, s a lassabb eszközök elhelyezésesére használhatjuk. Ezen switchből kb. 1 db-ot érdemes vásárolnunk, ezáltal a port számunk 110-ről minimum 158-ra nőtt. „Planet FGSW-2612PVM” (100.000 Ft/db) 24 db. 100 Mbps-os port, 2 darab 1000 Mbpsos port, illetve az előző szériához hasonlóan itt is megtalálható a 2 darab SFP port, EXTRA a 12 db. PoE port, mely a távoli eszközök áramellátását is képes megoldani rezes kábelen keresztül. A port számunk 2 ilyen switch vásárlása esetén 158+48 azaz 206 portra bővül minimálisan! „Routerboard RB1100AHx2” (80.000 Ft/db) routert választva biztosak lehetünk, hogy akár a 100 Mbit/s-os internet vonalon való forgalomirányítással is megbirkózik. Ezen állításomat a weblapon: http://routerboard.com/RB1100AHx2 olvasható tesztek alapján
[63]
bátran ki merem jelenteni. Ahol olvasható, hogy 512 byte-os csomagméret és 25 egyszerű csomagszűrő szabály alkalmazása mellett képes az eszköz kb. 500 Mbps-os vonal kezelésére. Az eszközök kiválasztása után már csak egy szünetmentes áramforrásra van szükségünk. Az eszközök mellé kb 2 kVA-as szünetmentes tápegység használata javasolt. Az eszközök összes áramfelvétele kb. 1200 kVA, ám azzal számolva, hogy az eszközök induláskor jóval nagyobb áramfelvétellel rendelkeznek, mint a működésük során, ezért 1,6-2,0 kVA teljesítményfelvétellel jó ha számolunk. Hogyan jött ki ez az 1200 kVA körüli érték? Az eszközök adatlapjain található maximális áramfelvételeket összeadva. A szerver veszi fel a legtöbbet kb. 870W-ot (4 HDD-vel). Az 5 db GSW-2401 kapcsoló, kb. 90 W-ot vesznek fel összesen, az FGSW-4840S kb. 24 W-ot, a PoE-s FGSW-2612PVM switch már maximálisan 150 W áramfelvétellel működik. Az RB1100AHx2 routerünk maximálisan 25 W-tal gazdálkodik. Így nagyjából, kis biztonsági tartalékkal és egyéb veszteségekkel és a későbbi bővítést szem előtt tartva jó, ha nagyjából 1500 kW-tal számolunk! Az UPS-ekről tudni illik, hogy különböző árkategóriákban találhatóak a háromfajta kimenetet (négyszög, trapéz, szinusz) produkáló típusok. A jövőre tekintettel, ill. hogy egyes eszközöknél nem találtam meg, hogy milyen fajta bemeneti jelet igényelnek, illetve mekkora mértékben viselik el a kapcsolási időt (ha az UPS átkapcsol, s már nem hálózatról, hanem akkucsoportról működnek az eszközök), így szinusz jelet előállító, kapcsolásiidő-mentes APC szünetmentes vásárlása mellet döntenék. A típus: „APC Smart-UPS RT 2000VA RM 230V”SURT2000RMXLI.
[64]
6. Összefoglalás Diplomamunkám megírása közben rengeteg nehézségbe ütköztem. Valójában lényegesen többe, mint azt kezdetben gondoltam. Ezen nehézségek többsége leginkább a szerver beállításával és a szakdolgozatom kezdeti helyéül szolgáló Diószegi Sámuel Szakképző- és Szakiskolával kapcsolatban történtek meg. Nem bánom a problémákat, sőt örülök neki, hogy előfordultak, sokat tanultam belőlük. Mit is értem el? Sikerült megmérettetnem magam, egy olyan feladatot valósítottam meg, amely nem sikerült volna akárkinek. Kitartást, koncentrációt, nagymértékű odafigyelést, pontosságot és erőfeszítést igényelt részemről. A tervezési szakasz megalkotása kissé nehézkes volt számomra, ugyanis szeretek rögtön belevágni abba az „izgalmas nagy fába”, s ott menet közben elgondolkozni a probléma megoldásán. Ez rossz szokás, melyet sikerült végre levetkőznöm, s próbáltam részletesen körüljárni az adott problémakört, majd megtervezni a szükséges lépéseket. Úgy érzem ez is sikerült! Létrehoztam egy olyan szabad szoftvereket használó kiszolgáló szervert, amely alternatívaként szolgálhat fizetős társaikkal szemben, sőt tipikusan jobb is (hozzáértő személy kezében). Egy oktatási intézmény bátran használatba veheti az elkészített kiszolgálót, mely teljesítené az „Intézményi Szükségleteket” (1.1 fejezet). Beállításra került: • Egy többé-kevésbé szigorú tűzfal, mely elegendő védelmet nyújt a mögötte álló LANnak. A szigorú tűzfalszabályok logikusan lettek kiépítve. Ennek kifejezetten örülök. • Megoldottam a szerver biztonságos távoli menedzselését az SSH – többek között – szerver felügyeleti alkalmazás felhasználása mellett. • Az alacsony sávszélességű internet kapcsolat optimális kihasználására felállításra került egy transzparens proxy, így a felhasználók a nagyméretű cache partíciónak és gyors szerver/hálózati reakcióknak köszönhetően gyorsabban érik el adatokat, ezzel kevesebb sávszélességet használnak fel. • A lehető legnehezebb feladatot is sikerült megvalósítanom. Az intézmény ezen túl linux alapokon is képes tartományvezérlő szervert használni, melyben minden Windows AD-ben megtalálható összes funkció implementálva van. Ezen service beállítása meglehetősen időigényes, és nehéz feladat volt a számomra, de sikerült. Erre vagyok a legbüszkébb! A kezdeti kitűzött célomat is elértem. Új technológiával találkoztam, s meg is tanultam őket, gondolok itt főleg a Samba 4-re és a Bind 9 DNS szolgáltatásokra. Sokat tanultam a
[65]
hibáimból, és úgy érzem, a jövőben könnyedén fogom venni ezen apróbb akadályokat (sőt a nagyobbakat is), s nyújtani tudom azt a színvonalat, amit elvárok saját magamtól. Gyakorlatban sajnos nem sikerült megvalósítanom az iskola három tantermének átállítását Linux alapú szerverek által nyújtott szolgáltatások használatára, ám virtuális környezetben az intézmény által felállított követelmények maradéktalanul működnek, s helyt állnak. Ha biztosítani tudtak volna számomra egy valódi szerver gépet, akkor e célom útjába bizonyára semmi sem állhatott volna. A dolgozatom megírásának kezdeti szakaszában minden szerver oldali konfigurációt, hálózati módosításokat stb. a helyszínen, gyakorlatban végeztem el az intézményben, ám egy idő után a félig kész kiszolgáló szervert elvették tőlem, s anyagi okokra hivatkozva beállították azt egy irodai környezetben működő egyszerű munkaállomásnak, azt hiszem egy titkárnő számára. Így munkámat virtualizált környezetben voltam kénytelen folytatni. Mindezeket összegezve úgy érzem hasznosat, s maradandót alkottam. Mely persze nem lett tökéletes, újból és újból találok benne fejleszteni valót, azonban nem ereszthettem bő lére gondolataimat, nem valósíthattam meg mindent, nem magyarázhattam el mindent, mindezek oka főként a dolgozat terjedelmével kapcsolatos szigorú követelmények. Örülök, hogy teljesítettem a kitűzött céljaimat!
[66]
7. Felhasznált irodalom Könyvek (magyar): [K1] [K2] [K3] [K4] [K5] [K6]
Andrew S. Tanenbaum - Számítógép-hálózatok, PANEM KFT, 2004 Az internet DNS – Pásztor Miklós, MTA SZTAKI/ASZI CCNA 1 v3.1– Cisco Systems, Inc.,2004 Gregor N. Purdy - Linux iptables zsebkönyv, Kiskapu, 2006, ISBN: 9639637122 Himanshu Dwivedi – SSH a gyakorlatban, Kiskapu, 2004, ISBN: 9789639301818 Samba a könyv
Katalógusok (angol): [C1] [C2] [C3]
CommscopeSystimaxSolutioncatalog 2008 European ProductCatalog 2009, AMP NETCONNECT Building Networks R&Muniversecatalog 2008
Internet: [I1] Dér Balázs - Passzív hálózati elemek felépítése http://www.johanyak.hu/files/u1/segedlet/halozatepites/er_Balazs_Passziv_halozati_el emek_telepitese.pdf 2013. május [I2] Debian Particionálási séma https://www.debian.org/releases/oldstable/i386/apcs03.html.en 2013. december [I3] Free software http://www.gnu.org/philosophy/free-sw.hu.html 2013. május [I4] GNU, GNU/Linux, GPL license http://hu.wikipedia.org/wiki/GNU http://hu.wikipedia.org/wiki/GNU_General_Public_License http://hu.wikipedia.org/wiki/Linux 2013. június [I5] HowtoGeek http://www.howtogeek.com/ 2013. június [I6] IETF https://www.ietf.org/ 2013.augusztus [67]
[I7] ISO/IEC 11801 szabvány http://en.wikipedia.org/wiki/ISO/IEC_11801 2013. augusztus [I8] Samba – Wiki https://wiki.samba.org/index.php/Samba 2013.november [I9] Squid – Wiki http://wiki.squid-cache.org/BestOsForSquid 2014. január [I10] UTP, STP, FTP http://wiki.hup.hu/index.php/Csavart_%C3%A9rp%C3%A1r 2013. szeptember
[68]
8. Függelék [F1]. EIA/TIA-568 és ISO/IEC11801 szabványok jellemzői. (C = CLASS)
EIA/TIA568
ISO/IE C 11801
Vezeték típus
Sávszélesség
Csillapítás (dB/km)
Adatátvi teli sebesség( Mbps)
Távolság(m )
Alkalmazási terület
CAT 1 CAT 2 CAT 3 CAT 4 CAT 5
C. A C. B C. C -
UTP UTP UTP UTP UTP
1 MHz 4 MHz 16 MHz 20 MHz 100 MHz
98 72 65
1 4 10 16 100
100 100 100 100 100
CAT 5e
C. D
UTP
100 MHz
24
1000
100
CAT 6
C. E
UTP
250 MHz
21,3
1000
100
CAT 6a
C. EA*
UTP
500 MHz
20,9
10000
100
CAT 7
C. F
600 MHz
20,8
10000
100
CAT 7a
C. FA*
STP, SSTP STP, SSTP
1000 MHz
20,3
10000
100
Telefon Token Ring Ethernet Token Ring Fast Ethernet Gigabit Ethernet Gigabit Ethernet Gigabit Ethernet Gigabit Ethernet Gigabit Ethernet
[F2]. Ethernet és IEEE szabványok átviteli közegekre
Ethernet szabvány
IEEE Vezeték szabványok típus
Category / Módus
Adatátviteli sebesség
Hossz (m)
10Base-2
802.3
vékony koax
-
10 Mbit/s
185
10Base-5
802.3
vastag koax
-
10 Mbit/s
500
10Base-T
802.3
-
10 Mbit/s
100
10Base-F
802.3
csavart érpár (réz) optika (fény)
-
10 Mbit/s
2000
[69]
100Base-T4
802.3u
100Base-TX
802.3u
100Base-FX
CAT 3
100 Mbit/s
100
CAT 5
100 Mbit/s
100
802.3u
csavart érpár (réz) csavart érpár (réz) Optika
Mono/multi
100 Mbit/s
220
1000BaseTX 1000Base-SX
802.3z
Optika
Mono/multi
1000 Mbps
100
802.3z
Optika
Multi
1000 Mbps
220-550
1000Base-LX
802.3z
Optika
Multi
1000 Mbps
1000Base-CX
802.3z
Twinaxial
-
1000 Mbps
5000(mono) 500 /multi) 25
1000Base-T
802.3ab
Csavart érpár Optika
CAT 5e
1000 Mbps
100
Mono
1000 Mbps
100 km
1000Base-ZX 10GBASE-SR
802.3ae
Optika
Multi
10000 Mbps
400 m
10GBASE-LX4
802.3ae
Optika
Multi/mono
10000 Mbps
10GBASE-LR, 10GBASE-ER 10GBase-SW, LW, EW (Összefoglalóan: 10GBase-W)
802.3ae
Optika
Mono
10000 Mbps
240-300m(multi), 10km (mono) 10-40km
802.3ae
Optika
Multi
10000 Mbps
300m
[F3]. Kábel típusok U/UTP (vagy egyszerűen UTP) az erek páronként (4 érpár) össze vannak csavarva, ezzel ellenállóbbak lesznek a környezeti hatásokkal szemben, megszűnik a csavarás nélküli állapotban jelentkező antennahatás. A csavarás hatására megszűnik az erek közötti interferencia, nem lesznek hatással a jelek egymásra, nem lesz áthallás az erek között. A 4 érpárt szintén egymásba csavarják, és egy külső védő köpennyel borítják be, melynek anyaga PVC, jobb minőségű kábeleknél LSZH, LSFRZH. A PVC tűzvédelmileg nem hatékony anyag, égése során mérgező gázok szabadulnak fel, azért ajánlható tűzvédelmi minősített kábeleket használni –mint pl. az LSZH - a kritikus területeken, melynek anyaga teflon vagy halár.
[70]
S/UTP (Shielded UTP) - Kábelharisnyával árnyékolt UTP. Ezen kábel esetében az ér párak nincsenek árnyékolva, hanem az egymásba csavart 4 érpár van kívülről egy védő, árnyékoló fóliával ellátva. Ezen kábelek szintén rendelkeznek az UTP kábel fizikai tulajdonságaival, viszont valamivel vastagabbak. Néha egy merevítő szál is található a kábelben, ami a védőcsőben „gégecső”, vagy kábelcsatornában való húzást segíti.
STP (Shielded Twisted Pair) kábelek, esetében a külső zajok ellen a réz vezetékek szintén csavarva vannak, de páronként árnyékolva is lettek, így ismét nő a kábel ellenálló képessége a zajokkal szemben. Ezen kábelek vastagabbak, nehezebbek és merevebbek az UTP kábelnél.
S/STP (Shielded STP) – Két réteg kábelharisnyával bevont UTP. Ezen típusú kábel az előző kábel tulajdonságaival rendelkezik, páronként árnyékoló kábelharisnyával vannak bevonva a kábelek, majd a 4 csavart érpár szintén egy árnyékoló réteggel lettek bevonva. Ez a kábel a legmerevebb, legnehezebben szerelhető.
SF/UTP: (Shielded és Foiled UTP) A kábelben a nagyobb zavarvédelem érdekében az árnyékoló kábelharisnya mellett még egy árnyékoló fémhálót (fémfóliát) is alkalmaznak.
[71]
S/FTP – Kábelharisnyával kívülről árnyékolt kábel, és ezen felül a kábelben található érpárok páronként fémfóliával vannak ellátva.
F/FTP – Kívülről Fém fóliával árnyékolt kábel, mely belsejében szintén fémfóliával ellátott érpárok húzódnak.
[72]
9. Melléklet Mellékletként csatoltam egy CD-t a szakdolgozatomhoz, melyben szerepel: • • • • • •
A kezdeti hálózati diagram, eredeti, szerkeszthető formában, valamint képként Az összes felhasznált vagy felhasználásra szánt fotó Az intézmény által rendelkezésre bocsájtott adatok A megtervezett korszerű hálózati diagram, szintén eredeti, szerkeszthető formában A szerveren az összes – általam – módosított konfigurációs fájl Az Ubuntu disztribúció telepítőfájlja
10. Köszönetnyilvánítás Hálával tartozom családomnak, akik támogatták tanulmányaimat, otthoni kísérleteimet, fejlesztéseimet, és biztosították az ehhez szükséges erőforrásokat. Köszönettel tartozom gimnáziumi informatika tanáromnak és barátomnak, Dancs Sándornak, akihez bármikor bármilyen jellegű kérdéssel bátran fordulthattam. Hálával tartozom Dr. Varga Imre egyetemi adjunktusnak, illetve témavezetőmnek, aki terelgetett a helyes úton a dolgozatom írása közben, valamint csupa hasznos ötlettel, tanáccsal látott el. Végül, de nem utolsó sorban munkatársaimnak és barátaimnak a T-Systems Magyarország Zrt. dolgozói közül, kik segítették strukturált hálózatokkal és aktív hálózati eszközökkel kapcsolatos kutatásaimat: Streit Artúr, Kecskeméti Csaba, Erdélyi János, Szabó László.
[73]
