Póserné Oláh Valéria Nyílt és zárt forráskódú operációs rendszerek

VÉDELMI INFOKOMMUNIKÁCIÓ

103

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, kato-nai, 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ít-ja a biztonság és teljesítmény szempontjából a legelterjedtebb zárt forráskódú szerver plat-form legfrissebb verziója (Microsoft Windows Server 2008), valamint az egyik leggyak-rabban használt GNU/Linux disztribúció szerver változata (Ubuntu Linux Server Edition) által biztosított leggyakoribb szolgáltatásokat. Kulcsszavak: Linux levelező szerver, Win-dows Server 2008 levelező szerver, Linux webszerver, IIS 7, felhasználó kezelés, jelszóke-zelé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

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

104

rendszerekben túlnyomórészt Microsoft operációs rendszereket alkalmaz-nak. 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átus-ban [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 bizton-sá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 alap-telepí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.


105

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 rend-szertő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 SMTP-AUTH 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 SASL-t. 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értelme-zé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ál-nak, így az üzenetek lehallgatás elleni védelme megoldott e protokollok kizárólagos használatával.

2 A Linux disztribúciók általában csomagokkal dolgoznak, melyekhez ún. tárolón keresz-

tül juthatunk. 3 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.


106

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 dkim-filter7 é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 dkim-filter é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 Amavisd-new-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 Egy olyan program, ami képes vezérelni a SPAM, vírus és egyéb szűrőt. 5 Több különböző mechanizmust használó tartalom e-mailszűrő. 6 Nyílt forráskódú vírusellenőrző. 7 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ó.

8 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.


107

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ő szer-ver. Sajnos azonban a Windows Server 2008 szolgáltatásai közül eltávo-lí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 Micro-soft Exchange Server képes hasonló szolgáltatások biztosítására, de mivel a

9 A World Wide Web Consurtium (W3C) Extended formátum, egy ASCII napló, beállít-

ható, hogy miket kívánunk naplózni. 10 Az IIS egy nem konfigurálható ASCII napló. 11 National Center for Supercomputing Applications (NCSA) egy nem konfigurálható nap-

ló formátum webkiszolgálóknak. 12 Open Database Connectivity (ODBC) a naplózást adatbázisba végzi.


108

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 dinami-kus 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 SQL-injection13 és XSS14 támadás.

Megállapítottam, hogy Windows Server 2008 esetén az alapbeállítások-kal 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 rosszindu-

latú 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.


109

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 — az-az 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:


110

— 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 hiteles-nek;

— egy hitelesített tanúsítvány igazolja az üzemeltető valódiságát.


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 tartot-tam 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 jogosult-sá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.


111

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/admi-nistrator felhasználónak adni.

4.2. Jelszókezelés

Nagyon gyakori a szótár alapú próbálkozás, amely gyenge jelszó házi-rend 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 azon-ban 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 ki-já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; Csatla-koztatható Azonosítási Modulok) segítségével hozhatunk létre jelszóke-zelési házirendet. A jelszó az /etc/shadow fájlban, vagy egy távoli szerve-ren 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 konfigu-rá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.


112

— module-arguments: olyan argumentumok, amelyeket át kell adni a modulnak. Minden modulnak megvannak a saját argumentumai. Pél-dá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 karak-terosztá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.


113

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ályo-kat 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ér-lő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 (!.#....)


114

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.


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árogta-tá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 (Uncomplica-ted 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 FOR-WARD. 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


115

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 csatla-kozunk 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.


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 megal-kotásán, és beállításán múlik.


116

Ö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.


117

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-cost- of-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


118

Documents

Póserné Oláh Valéria Nyílt és zárt forráskódú operációs rendszerek