NYÍLT ÉS ZÁRT FORRÁSKÓDÚ OPERÁCIÓS RENDSZEREK LEGGYAKORIBB SZOLGÁLTATÁSAINAK VIZSGÁLATA BIZTONSÁG ÉS TELJESÍTMÉNY SZEMPONTJÁBÓL

VÉDELMI INFOKOMMUNIKÁCIÓ

PÓSERNÉ OLÁH VALÉRIA

NYÍLT ÉS ZÁRT FORRÁSKÓDÚ OPERÁCIÓS RENDSZEREK LEGGYAKORIBB SZOLGÁLTATÁSAINAK VIZSGÁLATA BIZTONSÁG ÉS TELJESÍTMÉNY SZEMPONTJÁBÓL EXAMINATION OF FREQUENTEST SERVICES OF THE OPEN SOURCE AND THE CLOSED SOURCE OPERATION SYSTEMS IN THE ASPECTS OF SECURITY AND PERFORMANCE Világszerte egyre gyakrabban tapasztalható, hogy az egyes országok közigazgatási, katonai, oktatási stb. rendszereit, alkalmazásait állítják át — legfőképpen a költséghatékonyabb működtetés érdekében — nyílt forrású rendszerekre. A cikk megvizsgálja és összehasonlítja a biztonság és teljesítmény szempontjából a legelterjedtebb zárt forráskódú szerver platform legfrissebb verziója (Microsoft Windows Server 2008), valamint az egyik leggyakrabban használt GNU/Linux disztribúció szerver változata (Ubuntu Linux Server Edition) által biztosított leggyakoribb szolgáltatásokat. Kulcsszavak: Linux levelező szerver, Windows Server 2008 levelező szerver, Linux webszerver, IIS 7, felhasználó kezelés, jelszókezelés, tanúsítvány, Linux tűzfal, Windows Server 2008 tűzfal Worldwide it is more and more common that the systems of the national governance, army, education etc. are retooled to open source systems — mainly because of the economical operation. The purpose of the article is to analyze and compare — in the aspects of security and performance — the frequentest services of the operation system ensured by the newest version of the most commonly spread closed source operation system platform (Microsoft Windows Server 2008) and by the version of one of the most commonly used GNU/Linux distribution server (Ubuntu Linux Server Edition).

Bevezetés Kutatásom kezdetén nem terveztem a különböző operációs rendszerek mélyebb vizsgálatát, mivel ma Magyarországon az állami-, közigazgatási 103

NYÍLT ÉS ZÁRT FORRÁSKÓDÚ OPERÁCIÓS RENDSZEREK LEGGYAKORIBB…

rendszerekben túlnyomórészt Microsoft operációs rendszereket alkalmaznak. A nemzetközi tendenciát figyelemmel kísérve azonban egyre többször lehet hallani, olvasni olyan hírt, miszerint világszerte különböző országok közigazgatásában, katonai rendszerében legfőképpen a költségek csökkentése érdekében térnek át nyílt forrású rendszerekre. Mint például: — 11000 számítógépet migrál Linux-ra a német külügyminisztérium 1]; — az Egyesült Királyság kormánya felgyorsítaná a nyílt forráskódú szoftverek felhasználásának ütemét az állami kiszolgáló apparátusban [2]; — a Linux-ra váltáson dolgozik az amerikai hadsereg [3]. Ennek köszönhetően figyelmem az operációs rendszerek képességbeli különbözőségének vizsgálatára irányult, ezért megvizsgáltam és a biztonság és teljesítmény szempontjából összehasonlítottam a legelterjedtebb zárt forráskódú szerver platform legfrissebb verziója (Microsoft Windows Server 2008), valamint az egyik leggyakrabban használt GNU/Linux disztribúció szerver változata (Ubuntu Linux Server Edition) által biztosított szolgáltatásokat. Az összehasonlítás során virtuális gépeket, a teljesítmény méréséhez pedig egy scriptet használtam, mely a gazda gépen méri a virtuális gépek által használt processzor mennyiséget, és így mind a két platform terheltségét monitorozza. A script azt a képességet használja ki, hogy a Linux rendszerekben a folyamatok adatai a /proc/$PID/stat fájlban tárolódnak és mivel a virtuális gép is egy folyamat a gazdagép számára, így a fájlban megtalálható az eddigi használat processzorideje jiffyben1. Bizonyos időközönként megvizsgálva a fájlt megkaphatjuk a jiffy különbségéből, hogy az adott időintervallumban hány százalékban használta a folyamat a processzort. A tesztek végrehajtásakor ügyeltem az azonos körülményekre, mint a virtuális gépek memória- és háttértár kapacitása, valamint, hogy mindkét rendszer képességét kizárólag az alaptelepítés, illetve a disztribúció csomagjai által biztosított képességek alapján vizsgáljam. Azaz Microsoft Windows Server 2008 esetében nem telepítettem további alkalmazásokat, amelyek nem érhetők el a telepítőlemezről, illetve a „Szolgáltatások hozzáadása” menüből. Linux esetén pedig csak a gyári alap tárolókat használtam és nem adtam hozzá további 1

Jiffy a Linux kernel 2.6.x.x verziókban 1/250 mp.

104


szoftverforrást2, valamint nem telepítettem a csomagkezelőn keresztül nem elérhető programot. A mindennapjainkban leggyakrabban használt, a biztonság szempontjából leglényegesebb szolgáltatások képességeit elemeztem, mint levelező-kiszolgáló, webkiszolgáló, digitális tanúsítványok, biztonsági házirend, tűzfal.

1. Levelező-kiszolgáló Manapság már akár egy kisvállalkozásban is elengedhetetlen a saját levelező szerver nyújtotta szolgáltatás, így a biztonságos levelezéshez szükséges programok képességeit fontosnak találtam megvizsgálni.

1.1. Linux A Linux disztribúciók többségében a Postfix a levelező szerver, mely biztosítja például, hogy a rendszergazda leveleket kapjon magától a rendszertől. Alapbeállításban a postaláda formátuma mbox, de van lehetőség Maildir használatára is. SMTP autentikáció Az SMTP szerverek autentikációja azt a célt szolgálja, hogy illetéktelenek ne küldhessenek levelet a mi levelezőszerverünkön keresztül. Az SMTPAUTH egy kliens azonosítására szolgáló kiegészítő, amely segítségével a kliens azonosíthatja magát egy autentikációs mechanizmuson keresztül (SASL3). A forgalom titkosítására TLS-t (Transfer Layer Security) használhatunk. A Postfix két SASL-t támogat: a Cyrus és a Dovecot SASLt. A Dovecot egy mail delivery agent, ami a biztonság szem előtt tartásával készült, ezért a tesztrendszeremen ezt használtam. Támogatja mind a két elterjedt postafiók formátumot: a Maildir-t és az mbox-ot, de alapértelmezésként a Maildir-t használja. A támogatott protokollok: POP3, POP3S, IMAP, IMAPS. A POP3S és IMAPS protokollok SSL titkosítást használnak, így az üzenetek lehallgatás elleni védelme megoldott e protokollok kizárólagos használatával. 2

3

A Linux disztribúciók általában csomagokkal dolgoznak, melyekhez ún. tárolón keresztül juthatunk. SASL: Simple Authentication and Security Layer egy keretrendszer az adatok titkosítására és az autentikációra az Internet protokoll használatával.

105


Naplózás A Postfix az összes napló üzenetét a /var/log/mail.log fájlba menti. A hibaüzenetek és figyelmeztetések a rendes naplófájlon kívül a /var/log/ mail.err és a /var/log/mail.warn-ba is bekerülnek. Üzenetszűrés A levelek szűrése nagyon fontos képessége egy levelező szervernek, mivel az elektronikus levelezés egyik legnagyobb problémája a SPAM, a kéretlen reklámlevél. Továbbá e-mailen keresztül sok vírus, kémprogram, féreg is terjed. Az Amavisd-new4, Spamassasin5, és ClamAV6 programok integrálása a Postfix MTA-val hatásos lehet a probléma orvoslására. A Postfix továbbá képes ellenőrizni az e-mail valódiságát, különböző külső szűrőkkel, melyek képesek detektálni a SPAM-eket, anélkül hogy további nagyobb erőforrás-igényű programot használnánk. Két ilyen gyakran használt szűrő, amelyeket a tesztrendszeremen is alkalmaztam a dkimfilter7 és a python-policyd-spf8. Az üzenetszűrés folyamata: egy e-mail üzenet először valamely külső szűrőn kerül átfuttatásra, a tesztrendszeremben ez a külső szűrő a dkimfilter és a python-policyd-spf volt. Ezután az Amavisd-new továbbítja az üzenetet a ClamAV-nak, ami vírusellenőrzést hajt végre. Amennyiben az vírust talál, a Postfix elveti az üzenetet. Végül a Spamassasin ellenőrzi az addig „tiszta” üzenetet, hogy kiszűrje a lehető legtöbb SPAM levelet. A Spamassasin x-header sort ad a levél fejlécéhez, és továbbítja az Amavisdnew-nak további kezelésre. Ezek után a beállításokon múlik, hogy mi történjen a SPAM levelekkel. A szűrés folyamán a Spamassasin pontozza a 4 5 6 7

8

Egy olyan program, ami képes vezérelni a SPAM, vírus és egyéb szűrőt. Több különböző mechanizmust használó tartalom e-mailszűrő. Nyílt forráskódú vírusellenőrző. Egy Sendmail üzenetszűrő, amely azonosítja a leveleket a DomainKeys Identified Mail szabványhoz. A DomainKeys a Yahoo! és a Cisco Systems által kifejlesztett SPAM szűrő digitális aláírás. A DomainKeys egyedi DNS-aláírással lát el minden, egy szolgáltatótól kilépő levelet. Az üzenetet fogadó szerver ezután visszaellenőrzi a digitális aláírást, ha pedig az nem megfelelő, akkor igen nagy valószínűséggel kéretlen reklámlevélről vagy phising támadásról lehet szó. Engedélyezi a Sender Policy Framework-öt (SPF - az SMTP továbbfejlesztése, egy olyan e-mailtovábbító rendszer, mely hatásosnak tűnik a SPAM-ek ellen. 2003-ban mutatta be Meng Weng Wong, és ez lett a Sender ID elődje) a Postfix segítségével.

106


levelet. Amennyiben egy bizonyos értéket meghalad a SPAM mérőszáma, automatikusan eldobhatjuk a levelet, egy alacsonyabb értéknél pedig megjelöljük a tárgyban, és a felhasználóra bízzuk a döntést. Vigyázni kell az érték beállításánál, mert ha nagyon alacsonyra állítjuk, sok olyan üzenetet is elvethetünk, amelyek nem SPAM-ek (ilyen üzenetek gyakran lehetnek az ingyenes e-mail szolgáltatóktól küldött olyan levelek, ahol reklámok jelennek meg az üzenetben a feladó akarata nélkül).

1.2. Windows A Microsoft Windows Server 2008-ban is rendelkezésre áll levelező szerver. Sajnos azonban a Windows Server 2008 szolgáltatásai közül eltávolították a POP3 szolgáltatást. SMTP autentikáció Az SMTP szerver a Windows Server 2003-ból maradt hátra, nem fejlesztettek rajta, ezért nem része az IIS 7-es verziójának, így az SMTP beállítási lehetőségeit az IIS Manager 6-os verziójában találhatjuk meg. Itt is beállítható naplózás, aminek különböző formátuma lehetséges: W3C9, IIS10, NCSA11, ODBC12. Megadható TLS titkosítás használata, illetve engedélyezett, vagy tiltott hálózatok listája.

1.3. Megállapítások A Windows Server 2008, ellentétben a Linux-szal, POP3 szolgáltatást nem nyújt, SMTP szolgáltatása, mint fentebb leírtam beállítható titkosított adatfolyam használatára, és a titkosítás módja a szabványokhoz igazodik, így azonos a Linuxban implementálttal. Hozzáférés korlátozására ugyanúgy nyújt lehetőséget mind a két rendszer. Bár a Windows Server 2003-ban van SMTP és POP3 szerver is, azok sem nyújtanak semmilyen vírus vagy kéretlen reklámlevél szűrési lehetőséget. A Microsoft kínálatából a Microsoft Exchange Server képes hasonló szolgáltatások biztosítására, de mivel a 9

10 11

12

A World Wide Web Consurtium (W3C) Extended formátum, egy ASCII napló, beállítható, hogy miket kívánunk naplózni. Az IIS egy nem konfigurálható ASCII napló. National Center for Supercomputing Applications (NCSA) egy nem konfigurálható napló formátum webkiszolgálóknak. Open Database Connectivity (ODBC) a naplózást adatbázisba végzi.

107


telepítő nem tartalmazza, további beszerzést igényel, így nem tekintem összehasonlítási alapnak. Ezzel szemben a fent leírt linux-os Postfix, Spamassasin páros képes hatékony védelmet nyújtani Linux, de akár Windows rendszereken is. A hatékonyság teszteléséhez 2000 plain/text formátumú e-mailt használtam. A 2000 e-mail fele SPAM, a fele „tiszta levél” volt. Tesztjeim során küldtem őket összekeverve, majd külön-külön. Megállapítottam, hogy a SPAM szűrés nem nagy erőforrás igényű (a 2000 levél vizsgálata 16 percet igényelt, azaz 1 levelet átlagban 0,48 mp alatt vizsgált meg), valamint kellően nagy hatásfokú (0,3% nem felismert, 0,2% hamisan felismert).

2. WEB-kiszolgáló [4] Ezt a szolgáltatást itt részletesen nem hasonlítom össze, mert azt korábban a Comparing the webservers of the open source and the closed source operation systems című cikkemben már megtettem, csak a főbb megállapításaimat foglalom itt össze. Elterjedtsége miatt Linux esetében a LAMP (Linux, Apache, MySQL, PHP) összeállítást használtam és az Apache webkiszolgáló beállítási lehetőségeit vizsgáltam meg, míg a Microsoft Windows Server 2008 esetén az IIS 7 webszervert vettem górcső alá. Az Apache és az IIS 7 is egy moduláris szerver, így mindkét esetben szabadon kiválasztható az igényeknek megfelelően, hogy mely szolgáltatásokat kívánjuk használni. Mindkét szerver esetén biztosított a megfelelő modul alkalmazásával az adatfolyam titkosítása, beállítható megfelelő naplózás, melyek elemzése lehetővé teszi egy esetleges incidens részleteinek felderítését. A szolgáltatás teljesítmény- és biztonsági teszteléséhez egy egyszerű statikus HTML oldalt, egy dinamikus ASP.NET, és egy SQL Express-t használó ASP.NET alkalmazást használtam. Megvizsgáltam, hogy lehetséges-e az alapértelmezett beállításoknál, egy biztonság szempontjá-ból helytelenül megírt portálnál SQLinjection13 és XSS14 támadás. Megállapítottam, hogy Windows Server 2008 esetén az alapbeállításokkal telepített ASP.NET-ben biztonság szempontjából rosszul megírt portál 13

Az SQL Injection-nek nevezzük azt a támadási módszert, amikor egy oldalra rosszindulatú SQL kód beékelésével végzi el a támadást a behatoló. 14 Az XSS támadás a Cross Site Scripting, amikor egy Javascript, vagy egyéb szkriptet ültetünk be egy dinamikus oldalba.

108


rendszereken sikeresen végrehajtható SQL-injection, azaz hozzáadható egy felhasználó az adatbázishoz, mellyel a későbbiekben beléphetünk az oldalra. Ezzel szemben az Ubuntu Server-nél telepített PHP alapértelmezés szerint nem engedélyezi az ilyen jellegű támadásokat mivel szűri az aposztróf és idézőjel karaktereket, tehát az SQL parancs nem hajtódhat végre. Az XSS támadás ellen az ASP.NET-ben egy olyan védelem van, ami szűri a HTML kódokat, és figyelmeztetést ír ki támadás esetén, a PHP-ban pedig ugyanaz nyújt védelmet, mint az előbbi esetben, azaz az aposztróf és idézőjelek szűrése, mely azonban engedi beszúrni a külső rosszindulatú kódot amennyiben abban nem használják az említett karaktereket. A teljesítmény tesztekhez az ApacheBench programot használtam. Mind a két platformon három oldalt teszteltem, egy statikus, egy dinamikus, és egy SQL lekérdezéses dinamikus oldalt. Az oldalak tesztelésénél 25000 lekérdezést hajtottam végre, egyszerre 10, illetve egyszerre 500 lekéréssel. 10 és 500 lekérdezés között nem tapasztaltam nagy eltérést, ami azt jelenti, hogy jól kezelik a szerverek a konkurens kapcsolatokat. Az SQL tesztekből kiderült, hogy az ASPX sokkal (kb. ötször) nagyobb adatforgalmat generál egy egyszerű tábla adat megjelenítésére. A processzor használatának mértékében lényegi különbséget nem tudtam felfedezni, kivéve azt, hogy a MySQL nagyjából 10-15%-kal kevesebbet használja a kiszolgálót, ugyanazon parancs elvégzéséhez, mint az SQL Express.

3. Digitális tanúsítvány Egy elterjedt használati módja a publikus kulcs alapú kriptográfiának az alkalmazásréteg titkosítása Secure Socket Layer (SSL), vagy Transport Layer Security (TLS) kapcsolat használatával. A HTTPS protokoll — azaz a HTTP TLS használatával, amely mindkét rendszer esetén létfontosságú — digitális tanúsítványt használ. Egy kiszolgáló hitelességét tanúsítvánnyal igazoljuk, melyet általában egy hitelesítő kiszolgálótól veszünk. Gyakran találkozhatunk azonban alternatív megoldással is, amikor a szervezet saját maga írja alá a tanúsítványát, de ez érzékeny adatokat tároló-feldolgozó rendszerek esetében, így a védelmi rendszerek esetén sem lehet megoldás. A hitelesítő kiszolgáló által aláírt tanúsítvány három fontos dolgot nyújt, amit a saját aláírású nem: 109


— a legtöbb számítógép, webböngésző, ami támogatja az SSL használatát, rendelkezik egy listával a hitelesítő kiszolgálókról, amelyek aláírását automatikusan elfogadja; — a saját aláírású tanúsítványt a legtöbb böngésző nem tekinti hitelesnek; — egy hitelesített tanúsítvány igazolja az üzemeltető valódiságát. 3.1. Megállapítások A digitális aláírások, tanúsítványok kezelését szabványok írják le, így a böngészők számára platformtól függő különbség nem lehet. Mindkét vizsgált platform esetében a hitelesítés kiszolgáló számára előállított kérvényben nincs különbség, ám a saját magunk által aláírt tanúsítványok részletesebben beállíthatók Linux alatt.

4. Biztonsági házirend A biztonsági házirendben megadható beállítások, azon belül is a felhasználó- és a jelszókezeléssel kapcsolatosak egy rendszer biztonságos üzemeltetésében kulcs szerepet játszanak, ezért elengedhetetlennek tartottam a két platform képességeit ebből a szempontból is összehasonlítani. 4.1. Felhasználó kezelés Az Ubuntu Linux disztribúcióban az alapértelmezett beállítások szerint a root15 felhasználói fiók tiltva van. Ez biztonsági szempontból egy jó megoldás, mivel egy esetleges behatolás esetén a root felhasználó jogait próbálja megszerezni a támadó. A root helyett az admin csoport tagjai, illetve az /etc/sudoers fájlban felsorolt felhasználók jogosultak a sudo parancs végrehajtására, mely parancs átmeneti rendszergazdai jogosultsággal ruházza fel a parancs kiadóját. Ellentétben a Windows-zal ilyenkor a felhasználónak a saját jelszavát kell használnia, nem kell tudnia a root fiókhoz tartozó jelszót, vagy akár a rendszergazdáétól és a felhasználóétól egyaránt különböző jelszóval is lehet használni, így biztonságosabb. Több felhasználós rendszer esetén új felhasználó létrehozásakor célszerű 15

A root a Linux rendszerekben a rendszergazda, akinek mindenható joga van, általában minden rendszert érintő módosításhoz ilyen szintű hozzáférés kell.

110


megváltoztatni az alapértelmezett jogosultságokat, mivel az operációs rendszer mindenkinek olvasás jogot ad a felhasználói könyvtárra, azaz mindenki láthatja mindenki fájljait. Felhasználó törlésekor egyik platform esetén sem törlődik automatikusan a felhasználó könyvtára. Ez fokozott elővigyázatosságot igényel, mert, ha egy felhasználót olyan UID-vel adunk a rendszerhez, mint amelyikhez tartozó felhasználót töröltük, akkor a törölt felhasználó minden adatához lesz hozzáférési jogosultsága, illetve a vele azonos csoportban lévő felhasználóknak is lesz a beállított jogosultság szerint elérési lehetőségük. Tehát, felhasználó eltávolítása után érdemes archiválni a könyvtárat, majd a tulajdonjogot root/administrator felhasználónak adni. 4.2. Jelszókezelés Nagyon gyakori a szótár alapú próbálkozás, amely gyenge jelszó házirend esetén könnyen alkalmassá válhat a betörésre. Egy erős jelszó házirend sok behatolástól védhet meg. A házirend kigondolásakor azonban figyelnünk kell arra is, hogy a rendszert emberek használják és, ha túl szigorú szabályokat alkotunk (például túl gyakran kell módosítani a hozzáféréshez szükséges jelszavakat), a felhasználók hajlamosabbak kijátszani azokat (az aktuális jelszavukat könnyen hozzáférhető helyen tárolják, például monitorra ragasztják), mely így már kevesebbet ér, mint egy esetlegesen gyengébb, de betartható biztonsági házirend. 4.2.1. Linux Linux rendszeren a PAM (Pluggable Authentication Modules; Csatlakoztatható Azonosítási Modulok) segítségével hozhatunk létre jelszókezelési házirendet. A jelszó az /etc/shadow fájlban, vagy egy távoli szerveren van tárolva, és amikor egy programnak szüksége van a felhasználó azonosítására, akkor a PAM programkönyvtárban (library) tárolt függvényeket biztosít a megfelelő azonosítási módhoz, amelyeket az alkalmazás a felhasználói azonosításra használhat. Mivel ez a program-könyvtár dinamikusan töltődik be, az azonosítási mód megváltoztatható a konfigurációs fájl szerkesztésével. A PAM konfigurációs fájloknak a következő a szintaxisuk: — type control module-path module-arguments; — module-path: ez jelzi a PAM-nek, hogy mely modulokat használja, és (feltételesen) hol találja őket. 111


— module-arguments: olyan argumentumok, amelyeket át kell adni a modulnak. Minden modulnak megvannak a saját argumentumai. Például: bejelentkezési konfigurációnál a „nulok” (az az argumentum amelyet átad a pam_unix.so modulnak, jelezve, hogy az üres („null”) jelszó is elfogadható („ok”)). Jelszó beállításakor a bonyolultság ellenőrzését a pam_cracklib kiegészítő szolgáltatás végzi. A rendszer számára megadható, hogy egy adott karakterosztályra (számjegy – digit, nagybetű – upper, kisbetű – lower és egyéb – other) legfeljebb mennyi jutalompontot adjon. A jutalompontok hangolása a következőképpen történik: Dcredit = N, ucredit = N, lcredit = N, ocredit = N, ahol N az adott osztály karaktereire adható legmagasabb plusz pontok száma. Amennyiben a jelszóban megadott szám alatti vagy azzal megegyező számú adott osztályú karakter szerepel, mindegyikükért egy plusz pont jár. A karakterszámból adódó és a jutalompontok összegének legkisebbikét a minlen=N értékkel szabályozhatjuk. Az N értéke a megengedhető legkevesebb plusz egy. Így a következő beállításokkal Dcredit = 2 ucredit = 1 lcredit = 1 ocredit = 2 minlen = 12 csak olyan jelszó lesz elfogadható, amely vagy legkevesebb 10 kisbetűből áll, vagy ha van benne nagybetű, akkor nem rövidebb, mint 9 karakter; vagy ha van benne két számjegy és nagybetű, akkor nem rövidebb, mint 7 karakter és így tovább. Jelszóváltoztatás esetén a régi és új jelszó elvárt különbsége a difok=N értékkel állítható be. A segítségével megadható, hogy egy adott jelszóban hány karaktert kell mindenképpen lecserélni. Alapbeállítása tíz, de ehhez még egy újabb szabály adódik: amennyiben a jelszó karaktereinek minimum a fele lecserélődik, felülbírálja az itteni beállítást, és a jelszó megfelel. [5] A jelszó érvényességi időtartamának figyelése a legtöbb disztribúció esetén alapértelmezett beállítások szerint tiltva van, de ha a szervezet biztonsági házirendje szükségessé teszi beállítható a bizonyos időközönként való váltás.

112


4.2.2. Windows A Windows szerverben a jelszókezelés házirendjének beállítása két helyen is történhet, attól függően, hogy AD tartományvezérlőről van szó, vagy egyedül álló szerverről. Mind a két esetben ugyanazokat a szabályokat alkalmazhatjuk a frissen létrehozott felhasználókra. A következő opciókat adhatjuk meg:  Enforce password history: hány előző jelszót jegyezzen meg a rendszer, mielőtt ismételten megadható az eredeti jelszó. Értéke 0 és 24 között állítható. A tartományvezérlőkön az alapértelmezett érték 24, a helyi kiszolgálón 0.  Maximum password age: kötelezővé teszi a jelszóváltoztatást a megadott számú nap után. Értéke 1 és 999 között állítható. Ha egy jelszó sosem jár le, akkor 0-t kell megadni. Az alapértelmezett beállítás 42.  Minimum password age: egy jelszót minimum hány napig kell használnia a felhasználónak, mielőtt azt megváltoztathatná. Értéke 0 és 998 között adható meg. Alapértelmezett értéke a tartományvezérlők esetén 1, a helyi kiszolgálóknál 0. Ezt az értéket alacsonyabbra kell állítani, mint a maximum password age-t, amennyiben annak értéke nem nulla.  Minimum password length: a jelszó minimum hány karakterből álljon. Az érték 1 és 14 között állítható. Alapértelmezés szerint a tartományvezérlőkön 7, míg a helyi kiszolgálóknál 0. Amennyiben nem szeretnénk kötelezővé tenni a jelszó használatát, az értéket nullára kell állítani.  Password must meet the complexity requirements: engedélyezhetjük a jelszó bonyolultságának ellenőrzését, amikor a jelszónak meg kell felelnie az alábbi feltételeknek: — nem tartalmazza a felhasználónevet, vagy a felhasználó nevének több mint két egymást követő karakterét; — minimum 6 karakter hosszú; — az alábbi csoportokból legalább háromból tartalmaz karaktereket:  angol nagybetűk (A...Z);  angol kisbetűk (a...z);  szám (0...9)  nem alfabetikus karakter (!.#....) 113


Alapértelmezés szerint a tartomány-kiszolgálókon engedélyezve van és tiltva a helyi szervereknél.  Store passwords using reversible encryption: engedélyezi a jelszavak visszafejthető kódolással történő tárolását. Ebben az esetben azonban a tárolás nem sokkal biztonságosabb, mintha egyszerű szövegfájlba mentenénk el a jelszavakat,de vannak alkalmazások, amelyek igénylik ennek az opciónak a használatát. 4.3. Megállapítások Mint láthatjuk mind a két rendszeren részletesen beállítható a biztonsági házirend jelszókezelése, de Windows Server esetén nem konfigurálható olyan részletességgel, mint Linux esetén. Továbbá a biztonságos jelszó megalkotásához Linux választásakor lehetőség van szótár alapú támadások kivédésére, ellenőrzés által.

5. A tűzfal A tűzfal alapvető feladata a hálózati forgalom ellenőrzése, és különböző szabályok által tiltása, vagy engedélyezése. Egy vállalati szerver esetén, de még otthoni felhasználóknak is ajánlott a tűzfal használata, mivel védelmet jelent főleg külső támadások ellen, de a belső adatkiszivárogtatást is megakadályozhatja. 5.1. Linux A Linux rendszermagja tartalmazza a Netfilter csomagszűrő alrendszert, melyet különböző felhasználói alkalmazásokkal lehet beállítani. Az Ubuntu-ban az alapértelmezett kezelő alkalmazás az UFW (Uncomplicated Firewall). Sokkal elterjedtebb adminisztrációs eszköz a csomagszűrésre és NAT kialakítására az iptables, mely figyeli a csomagok fejlécét, miközben azok áthaladnak rajta, és a megadott szabályok alapján eldönti, mi legyen a sorsuk. Alapértelmezetten három szabálysort (tűzfal láncot) tartalmaz a „szűrési” táblája, melyek az INPUT, OUTPUT és a FORWARD. Minden lánc szabályok sorozata, melyek meghatározzák, hogy az adott fejlécű csomaggal milyen műveletet kell végrehajtani. Ha a szabály nem illeszkedik a csomagra, a lánc következő szabálya kerül vizsgálatra. Amennyiben minden szabály vizsgálata megtörtént, és egyik 114


sem illik a csomagra, akkor a kernel megnézi a lánc házirendjét (irányelv arra az esetre, ha egy szabály sem illik a csomagra) hogy eldöntse, mit kell tenni a csomaggal. Egy tudatosan biztonságra törekvő rendszerben ez általában azt jelenti, hogy a kernel a csomagot eldobja (DROP). [6] Az iptables alkalmas úgynevezett IP maszkolásra is, azaz képes biztosítani több gép számára egyetlen IP címen keresztüli kapcsolódást az internethez vagy más szolgáltatáshoz. Erre jellemzően akkor lehet szükség, ha például nem áll rendelkezésre megfelelő mennyiségű IP cím, vagy, ha kapcsolt vonalon keresztül csatlakozunk az internetre és szeretnénk hozzáférést biztosítani hálózatunk többi gépe számára is. 5.2. Windows A Windows tűzfal a server manager configuration részében érhető el. A szabályok létrehozásában egy varázsló segít. Új szabály hozzáadásakor megadható, hogy bejövő vagy kimenő kapcsolatnál kívánjuk alkalmazni. Kiválasztható, hogy program, port, előre definiált vagy egyéni szabályt szeretnénk létrehozni. Megadható, hogy mely programra, szolgáltatásra legyen érvényes, melyik számítógépekről illetve melyik felhasználónak engedélyezzük vagy tiltjuk a kapcsolatot, milyen típusú protokoll mely portokat használja, mely IP címekre legyen igaz valamint, hogy mely profilok, milyen interfészen használják a parancsot. A szabály érvényesülése esetén a következőket állíthatjuk be: — engedélyezzük a kapcsolatot; — csak titkosított kapcsolatot engedélyezünk; — blokkoljuk a kapcsolatot. A Windows Server tűzfala is biztosít lehetőséget IP maszkolásra az internet kapcsolat megosztása, azaz Internet Connection Sharing (ICS) nevű szolgáltatás segítségével. 5.3. Megállapítások Megállapítottam tehát, hogy a Windows tűzfala is hasonló részletességgel konfigurálható, mint a Linuxé. Véleményem szerint mind a két tűzfal esetében a kiszolgáló biztonsága csak a megfelelő tűzfalszabályok megalkotásán, és beállításán múlik. 115


Összegzés Megvizsgáltam és elemeztem több szerver-szolgáltatást és azok biztonsági beállításait jellegzetes nyílt és zárt forráskódú rendszereken. A nyílt forrású rendszerek nagy előnye és egyben nagy hátránya is a zárt forrásúakéval szemben, hogy betekinthetünk a kódba, így hozzáértő, avatott szemek olyan hibákat vehetnek észre, melyek biztonsági rést jelentenének, így ez rövidebb időn belül javításra kerülhet. Azonban elmondható ez úgy is, hogy sokkal rövidebb időn belül válik sérülékennyé egy nyílt forráskódú operációs rendszer azáltal, hogy bárki betekinthet a kódba. A zárt forrású rendszereknél időnként sokat kell várni a biztonsági javításokra, esetenként éveket, mint történt az például a Server Message Block (SMB) protokoll hibajavításánál, amikor egy hiba lehetőséget adott távolról illetéktelen felhasználónak adminisztrátori jogosultsággal programot futtatni. Ezt az úgynevezett SMBRelay hibát például közel 8 évig lehetett kihasználni Windows rendszereken. [7] Az elvégzett tesztek alapján kijelenthetem, hogy két egyenrangú rendszert sikerült összehasonlítanom, amelyek a vizsgált feladatok mindegyikében megfelelően teljesítettek. Egyes szempontokból az egyik, más szempontokból a másik bizonyult előnyösebbnek, de megállapítható az is, hogy a felhasználás szakszerű volta sokkal többet számít a használhatóságban, mint hogy melyiket választjuk. Mind két platform csak megfelelő szakértelemmel konfigurálva biztonságos.

116


FELHASZNÁLT IRODALOM [1]

Gijs Hillenius: Cost of Open Source desktop maintenance is by far the lowest, http://www.osor.eu/news/de-foreign-ministry-costof-open-source-desktop-maintenance-is-by-far-the-lowest, 2009.01.20.

[2]

BBS NEWS: UK government backs open source, http://news.bbc.co.uk/2/hi/technology/7910110.stm, 2009.02.25.

[3]

Austin Modine: US Army struggles with Windows to Linux overhaul, http://www.theregister.co.uk/2008/02/05/us_army_linux_ integration, 2008.02.28

[4]

V. O. Póserné: Comparing the webservers of the opensource and the closed source operation systems, in Proc of the 5th International Symposium on Applied Computational Intelligence and Informatics, Timisoara, Romania, IEEE Catalog Number CFP0945C-CDR, ISBN 978-1-4244-4478-6, Library of Congress 2009903350, 2009, pp. 169-172.

[5]

Mátó Péter–Borbély Zoltán: Könnyű Álmok. A PAM használata a gyakorlatban. Kiskapu Kft., 2001.

[6]

Gregor N. Purdy: Linux iptables zsebkönyv, Kiskapu 2006., ISBN: 9789639637122

[7]

Microsoft: Miért tartott több mint 7 évig az SMB hiba javítása http://hup.hu/cikkek/20081114/microsoft_miert_tartott_tobb_ mint_7_evig_az_smb_ hiba_javitasa, 2008.12.01

117


118

NYÍLT ÉS ZÁRT FORRÁSKÓDÚ OPERÁCIÓS RENDSZEREK LEGGYAKORIBB SZOLGÁLTATÁSAINAK VIZSGÁLATA BIZTONSÁG ÉS TELJESÍTMÉNY SZEMPONTJÁBÓL

Recommend Documents