Informatika | UNIX / Linux » Jónás Zsolt - Linux alapú weboldal létrehozása

Tartalomjegyzék 1. Bevezető3 1.1 Megvalósítandó feladat3 2. Feladat részletes ismertetése5 3. Felhasznált komponensek7 3.1 Operációs rendszer7 3.11 Debian GNU/Linux7 3.2 Fejlesztői környezet7 3.21 VIM8 3.3 Programozási nyelvek8 3.31 Perl8 3.32 HTML9 3.33 CSS10 3.4 Szerver programok10 3.41 Apache10 3.42 BIND910 3.43 DHCP311 3.44 Samba11 3.5 Adatbázis programok12 3.51 MySQL12 3.52 OpenLDAP13 3.6 Levelezéshez használt programok13 3.61 Postfix14 3.62 AMaViSd-new14 3.63 ClamAV14 3.64 SpamAssassin15 3.65 Courier Mail Server15 3.66 SquirrelMail16 3.7 Egyéb16 3.71 OpenSSH16 3.72 NetFilter / IPTables16 3.73 Shaperd17 4. Megvalósítás ismertetése18 4.1 Hardver18 4.11 Szerver-gépek18 4.12 Aktív eszközök19 4.13 IP-cím tartományokról19 4.14 Kialakított hálózati topológia20 4.2 Szoftver beállítások szerver oldalon23 4.21 Jelszó nélküli felhasználó-azonosítás kulcsok segítségével SSH esetén23 4.22 DHCP-kiszolgáló24 4.23 BIND925 4.24 Apache26 4.25

Samba26 4.26 LDAP létrehozása és a hozzá kapcsolódó programok beállítása29 4.27 MySQL32 4.28 Postfix33 4.29 AMaViSd-new35 4.210 ClamAV37 4.211 SpamAssassin38 4.212 Courier Mail Server39 4.213 SquirrelMail39 4.214 Shaperd40 4.3 Szoftver beállítások kliens oldalon41 4.31 Windows XP41 4.32 Debian GNU/Linux42 4.4 Honlap használata, működési folyamatai44 4.41 Szobai Internet-elérés igénylés44 4.42 Kabinetes Internet-elérés igénylés45 4.43 Nyomtatás a HÖK-ös nyomtatóval46 4.5 Perl szkriptek46 5. Tervezői döntések összefoglalása53 5.1 Kivitelezés elemzése, lehetséges alternatív megoldások bemutatása53 5.11 Exim, Postfix, Qmail vagy Sendmail?53 5.12 Perl vagy PHP?54 5.13 Mi az SNMP?54 5.14 MySQL vagy PostgreSQL?55 5.2 Végkövetkeztetés56 1. Bevezető 3 1. Bevezető 1972-ben a Xerox Corporation1 úgy döntött, hogy egy olyan számítógépet állít elő, amelyet kutatási célokra lehet majd felhasználni. A tervezés és munka eredményeként

megszületett az Alto névre hallgató számítógép, amely a nevét a Xerox Palo Alto Research Center2-ről kapta, ahol is kifejlesztésre került. Az Alto Ed McCreight, Chuck Thacker, Butler Lampson, Bob Sproull, és Dave Boggs összefogásának eredményeként született meg. Az elképzelés az volt, hogy egy olyan gépet kell alkotni amely kényelmesen elfér egy irodában, de mégis elegendően erős ahhoz, hogy sok funkciós operációs rendszert és grafikus felületet tudjon futtatni. 1978-ban a Xerox ötven Alto-t adományozott a Stanford Egyetemnek, a Carnegie-Mellon-nak, és az MIT-nak (Massachusetts Institute of Technology). Ezek a gépek nagyon gyorsan asszimilálódtak a kutatási közösségben és nagyon hamar szabvánnyá váltak ebben a közegben. [1] A sors fintora, hogy bár az Alto-nak két generációját is elkészítettek a 70-es évek során, és még egy prototípus is telepítésre került belőle a Fehér Házban, a Xerox kereskedelmileg sosem

hasznosította a modern személyi számítógépek és grafikus felületek ősének számító csodálatos rendszert. [2] Manapság egy grafikus felület nem újdonság, desktop környezetben a gyors és hatékony munkavégzés alapfeltétele. 10-15 évvel ezelőtt még szokatlan volt, ha egy vállalat elindította saját honlapját/portálját. Mára eljutottunk oda, hogy ha hatékonyan akar működni egy vállalat, akkor rendelkeznie kell egy IT részleggel, amely létrehozza, üzemelteti és fejleszti a vállalat számítógépes infrastruktúráját. Sőt, pár évvel ezelőtt elkezdődött a vállalatok „webesítése” Manapság alig találni olyan vállalatot, amelynek ne lenne belső vállalati webes felülete. 1.1 Megvalósítandó feladat A mai „trendet” szem előtt tartva, rendszergazdaként egy olyan belső elérésű weboldal létrehozása volt a feladatom a Szent László Katolikus Szakkollégiumban, amelyen keresztül a kollégiumba beköltözött lakók

internet-elérést igényelhetnek. Csatlakoztatják a számítógépüket a számítógépes hálózatra a falicsatlakozón keresztül, a weboldalon igényelnek maguknak IP-címet, majd a kérés feldolgozása után a kollégium tűzfal szervere lehetővé teszi az internet elérését. 1. http://wwwxeroxcom 2. http://wwwparcxeroxcom 1. Bevezető 4 Ezen felül meg kellett valósítani egy nyomtató szervert is, amelyen keresztül a kollégium lakói távolról, a saját szobájukból nyomtathatnak. Természetesen a rendszernek figyelnie kell a nyomtatásokat: ki, mikor és mennyit nyomtat. Az eltárolt adatok alapján minden hónap végén email-ben jelentést kell küldenie a nyomtatásért felelős személynek, hogy a nyomtatási díjak beszedhetőek legyenek. 2. Feladat részletes ismertetése 5 2. Feladat részletes ismertetése A Szent László Katolikus Szakkollégiumban laktam már egy éve, amely során félévkor átvettem a rendszergazdai feladatok

ellátását, bár akkor még nem hivatalosan. Az év végén – elismervén munkámat – megbíztak azzal, hogy lássam el a következő év során a rendszergazdai teendőket, valamint töltsem be a – frissen megalapított – Informatikai Tanács elnöki posztját. Ennek keretén belül felkértek – a szakdolgozatomnak is választott – feladatra Adott volt egy teljesen üres terem, amelyben ki kellett alakítanom egy számítógépes kabinetet, amelyben a Széchenyi István Egyetemtől kapott 10 számítógépet kellett elhelyeznem rákötve a számítógépes hálózatra1, valamint ugyan ebben a teremben (2.1 Ábra: Kabinet terem) kellett elérhetővé tennem a Hallgató Önkormányzat (HÖK) nyomtatóját, hogy a belső hálózaton keresztül bárki nyomtathasson. 2.1 Ábra: Kabinet terem Üzembe kellett állítanom egy DHCP-kiszolgálót, hogy az internet beállítása nagyságrendekkel egyszerűbb legyen felhasználói oldalról, valamint a rendszer esetleges

átalakítása is egyszerűen, zökkenőmentesen megtörténhessen, úgy hogy a felhasználók maximum egy kis „internet-szünetet” tapasztaljanak. A DHCP-rendszer áldásos hatását meg is tapasztalta a kollégium, amikor belső IP-címes hálózatról átálltunk egy egyetemi IP-cím tartományra. A váltás után a felhasználók számítógépei már az új IP-cím tartományból kaptak IP-címet, így a felhasználók semmilyen változást nem tapasztaltak, egy kis kellemetlenséget2 leszámítva. Egy DHCP-kiszolgáló segítségével rendszeradminisztrátori oldalról állíthatjuk a kliensek hálózati beállításait és ez magával hozza azt a tényt, hogy a felhasználóknak nem kell tudniuk az adott hálózatra vonatkozó IP- és DNS címeket, netmask értékeket, stb. Azonban van igény arra, hogy mindezek ellenére tudjanak kapcsolódni egymás gépeihez, amihez tudni kellene a másik felhasználó IP-címét. E probléma megoldásaként össze kellett állítanom egy

DNS-szervert, így a felhasználónak a csatlakozáshoz csak a másik fél „DNS-nevét” kell 1. A számítógépes kabinet kivitelezése nem képezi részét a szakdolgozatomnak, mert annak létrehozásáról is lehetne írni egy külön szakdolgozatot. 2. A átállás után a DHCP másik IP-címet küld a felhasználónak, akinek a gépe átáll az új IP-címre, így az összes megnyitott kapcsolata megszakad, de az új címmel kezdeményezett kapcsolatok már létrejönnek. Az átállás során történő megnyitott kapcsolatok megszakadása elkerülhetetlen. 2. Feladat részletes ismertetése 6 tudnia. Minden felhasználó saját maga adhatja meg a „DNS-nevét”, amikor internet-elérést igényel. Ezen felül meg kellett alkotnom egy központosított felhasználóazonosítási rendszert (LDAP), amelyben az internet-hozzáférést (szobai vagy kabinetes) igényelt felhasználókat kell tárolni (MySQL). Ezen azonosítási adatbázis révén megoldható az, hogy bárki

nyomtathasson a hálózaton keresztül (Samba-LDAP) a HÖK nyomtatójával úgy, hogy nyomon követhető legyen a folyamat, és a hónap végén beszedhető legyen a nyomtatás ellenértéke. A feladat megvalósításában teljesen szabad kezet kaptam, egyetlen megkötés volt, miszerint pénzt nem tudnak áldozni a feladat kivitelezésére a kollégium részéről, csak az Informatikai Tanács keretében költekezhettünk. Szerencsére, szoftveres oldalról nem volt semmilyen megkötés, így azokat a programokat használhattam, amelyeket jól ismertem, vagy épp meg akartam ismerni, mert a feladatra az a legalkalmasabb. A következő fejezetben részletesen bemutatom a választott programokat. 3. Felhasznált komponensek 7 3. Felhasznált komponensek Több tényező is befolyásolt, amikor a felhasznált komponenseket kiválasztottam. Két alapvető tényező azonban jelentősen leszűkítette a felhasználható programok körét. Az első ilyen tényező volt a nyílt

forráskódú programok használata, a másik pedig a minél kisebb hardver követelmény. Ennek tükrében röviden bemutatom a feladat megvalósításához felhasznált összetevőket olyan sorrendben, ahogy a használatuk egymásra épül. 3.1 Operációs rendszer Mivel fontos tényező volt a nyílt forráskódú programok használata, ezért vagy valamelyik *BSD1 vagy GNU/Linux operációs rendszer közül volt célszerű választani. Mivel nem ismerem mélyebben a *BSD rendszereket, ezért maradtak a GNU/Linux-ok. 3.11 Debian GNU/Linux http://www.debianorg Választásom a Debian GNU/Linux operációs rendszerre esett. Kiforrott csomagkezelő rendszere miatt könnyedén telepíthető és frissíthetők a már feltelepített programok. Elsődlegesen szerver disztribúciónak szánják, de könnyen varázsolható belőle desktop rendszer is. A Debian készítőinek elsődleges szempontja a terjesztés összeállításánál a stabilitás és hibamentesség. Ez érezhető is a

1,5-2 éves kiadási periódusokból Szerverre telepített programoknál nem elsődleges szempont az új funkciók implementálása, sokkal fontosabb, hogy stabilan, megbízhatóan működjön. A létrehozott rendszerben három Debian-t futtató szerver működik együtt, hogy a különböző szolgáltatásokat a felhasználók bármikor zavartalanul használhassák. 3.2 Fejlesztői környezet Egy jól megválasztott fejlesztői környezet – a megvalósítandó feladattól, méretétől függően – akár napokkal, hónapokkal is lerövidítheti a fejlesztési időt. 1. FreeBSD, OpenBSD, NetBSD, stb 3. Felhasznált komponensek 3.21 8 VIM1 http://www.vimorg A sor-orientált szövegszerkesztők fénykorának végéhez jelentősen hozzájárult az első, képernyő-orientált szövegszerkesztők program, ami nem volt más, mint a vi (visual editor). A Vim a vi szerkesztőből született, mint a neve is mutatja: Vi Improved. [3] [4] Az eredeti unix-os szövegszerkesztő az

ed volt, amely egy sor-orientált szövegszerkesztő, azaz használatakor csak az aktuálisan szerkesztett sor volt látható. Bill Joy 1976 környékén kezdte el fejleszteni a vi programot. Ez volt az első képernyő-orientált szövegszerkesztő A tervezésekor szem előtt tartották a lassú hálózati kapcsolatokat, így fürgén dolgozhatunk vele nagy fájlok esetén is akár egy modemes kapcsolatot használva. [5] Bram Moolenaar 1988-ban kezdte el fejleszteni a Vim programot, akkor még Amigán. 1991-ben jelent meg a Vim első változata. 1992-ben portolták Unix alá és elérte a vi szintjét, ez volt az a pont, amikor a Vim ténylegesen Vi Improved lett (Vim 2.0) 1994 augusztusában jelent meg a Vim 3.0, amely már támogatta a többszörös bufferelést és az ablakokat2. 1996 májusában a Vim kiadásának legnagyobb újdonsága a megjelent GUI volt, amelyet Robert Webb fejlesztett. „Syntax coloring/highlighting” az 1998 februárjában megjelent Vim 5.0-ban jelent meg3

A „Folding”4 képesség a legfigyelemreméltóbb lehetőség a 2000 júliusában megjelent Vim 6.0a-ban [6] 3.3 Programozási nyelvek Honlap elkészítéséhez elengedhetetlen, hogy ismerjük azokat a programozási nyelveket, amellyel weboldalt hozhatunk létre, ezért bemutatom a felhasznált három nyelvet. 3.31 Perl http://www.perlorg A programnyelveknek fontos részei a szkript nyelvek. Az egyre gyorsabbá váló számítógépeken egyre jobb teljesítménnyel futnak a szkript nyelveken írt programok. 1. A fejlesztés során egyik legsűrűbben alkalmazott eszköze volt számomra és fontosnak tartom a bemutatását, mert sajnos méltatlanul kezelik általában az emberek. Igaz, hogy elriasztó lehet egy karakteres szövegszerkesztő, de a megtanulásába fektetett időt többszörösen meghálálja. 2. Ne felejtsük el, hogy a Vim egy karakteres program, így az ablak fogalma is karakteres képernyőn értendő 3. Nagy segítség programozás és GNU/Linux vagy Unix

rendszer konfigurálása esetén 4. Jelentése: összehajt, összecsuk Ezzel a képességgel a megírt függvényeinket összecsukhatjuk egy sorrá A rendszer fejlesztésekor nagy segítség volt számomra. 3. Felhasznált komponensek 9 Manapság nem csak a rendszergazdai feladatok automatizálására használatosak, hanem hasznos, fontos feladatokat ellátó programokat is írnak általuk. GNU/Linux operációs rendszeren az egyik legnépszerűbb kéretlenlevél-szűrő programot Perl nyelvben írják. Valamint az Internet és Web programozás kapcsán is nagy népszerűségre tett szert. Mondhatjuk, hogy a CGI (Common Gateway Interface) programok döntő többségét Perl vagy PHP nyelven írják. [7] Larry Wall az Egyesült Államok nyugati partján egy cég rendszergazdájaként dolgozott, amikor létrehozta a Perl programnyelvet, amelynek először nem Perl volt a neve. Larry hosszas keresgélés után a Pearl (Practical Extraction And Report Language) nevet választotta,

azonban ilyen nevű grafikai programnyelv már létezett, így alakult ki a Perl név. A Perl első verziói már ismerték a fájlkezelést, a skalárokat, a jelentésformátumokat és a mintaillesztést, azonban nem ismerte az asszociatív tömböket (hash) és csak csekély számú függvényt használt. A programnyelv működési körének bővülése jelentősen fokozódott, miután Larry felrakta az Internetre. A Perl nyelv figyelemre méltó tulajdonsága a (könyvtár)modulok kezelése. Nagyon sok független programozó készít programmodulokat, amelyek éppen olyan hasznosak, mint maga a nyelv. Érdemes meglátogatni valamelyik CPAN (A Comprehensive Perl Archive Network – Széleskörű Perl Archívum-hálózat) webhelyet. A CPAN oldalak hirdetmények, témaismertetők, terjesztések, dokumentációk, portok és szkriptek szerint rendezik . Több mint 70 CPAN Web helyet tartanak számon, amelyek felépítése szabványosított. [3] 3.32 HTML http://w3c.org/MarkUp A HTML

(Hyper Text Markup Language) fejlesztésekor egy böngészőfüggetlen nyelv kifejlesztése volt a cél. A parancsokat „<” és „>” jelek közé kell zárni (értsd: <html parancs>). A böngészőpiac erősödésének következtében a szabványosítás sokszor nem tudta követni a különböző böngészőkben megjelent új lehetőségeket. Ennek következtében sok olyan oldal volt / van, amit csak kizárólag az egyik böngészőkészítő cég programjával lehet megnézni. Ez többlet költséget ró a készítőkre, mert a a megjelenítő programkódot el kell készíteni mindegyik böngészőre. 1997-be alkotta meg a World Wide Web Consortium (W3C) a 4.0-ás HTML szabványt, amely az eddigi legutolsó Kiszámolható, 3. Felhasznált komponensek 10 hogy hét éves szabvány, de még mindig tartalmaz olyan parancsokat, amiket nem támogat mindegyik böngésző. [8] 3.33 CSS http://w3c.org/Style/CSS A CSS-t (Cascading Stylesheet – lépcsőzetes

stíluslapozás) röviden csak stíluslapozásnak nevezzük. Használatával definiálhatunk különböző stílusokat, a HTML fájlban pedig csak hivatkoznunk kell az adott elemnél, hogy melyik stílus tartozik hozzá. Ezáltal rövidebb forráskód alakulhat ki, ugyanis minden stílust csak egyszer kell definiálni, és után csak hivatkozunk rá (rövidebb forráskód kisebb sávszélességigény kisebb költségek és kisebb erőforrásigény). A megjelenítés minden apró porcikáját befolyásolhatjuk, ezáltal pontosabban szerkeszthetünk meg egy weboldalt. A CSS szintén szabványosított, azonban ne feledkezzünk meg róla, hogy itt is érvényes az a megállapítás, hogy nem elég a szabvány puszta léte, a böngészőknek aszerint is kell működniük, azonban ez nem mindig van így. [8] 3.4 Szerver programok A kliens gépek felől érkező kérésekre a szerver küld választ, azonban ezeket a válaszokat először elő kell állítani, erre valók a

szerver-programok (kiszolgálók). 3.41 Apache http://apache.org A megalkotott honlapot elérhetővé is kell tenni, erre nincs alkalmasabb, mint egy webszerver. Választásom a – méltán népszerű – Apache programra esett. A felmérést végző szervezettől függően, de a különböző statisztikákat átlagolva elmondható, hogy az Apache fut a webszerverek durván 50%-án. Ez az arány bizonyítja, hogy igen is van létjogosultsága a nyílt forráskódú programoknak. Sok egyéb kényelmi szolgáltatása mellett kezeli a „virtuális host”-okat, valamint képes SSL kapcsolatra létrehozására is. 3.42 BIND9 http://www.iscorg/sw/bind Névszerverek közül a választásom a BIND9 (Berkeley Internet Name Domain v9) programra esett, amely az egyik legelterjedtebb névfeloldó-szerver. Azért választottam ezt, mert a néhány DNS-szerverprogram közül ezt ismerem egyedül. Jól konfigurálható és a beállítófájljai 3. Felhasznált komponensek 11 könnyen

előállíthatók akármelyik szkript nyelvvel is, ezért nem is kerestem másikat. Ez a szerverprogram végzi el a névfeloldást és a fordított névfeloldást is. 3.43 DHCP3 http://www.iscorg/sw/dhcp Az egyszerűbb és kényelmesebb használat érdekében DHCP (Dynamic Host Configuration Protocol – Dinamikus állomáskonfigurációs protokoll) osztja ki az IP-címeket a lakók számítógépeinek. Ezáltal a beköltözés során nem kell különböző misztikusnak tűnő számokat megtanulniuk, hanem csak rádugják a számítógépüket a hálózatra. Minden hálózati kártyának van egy egyedi MAC (Medium Access Control) azonosítója, amit a rendszer nyilvántart a hozzárendelt IP-címmel együtt. Ezáltal, ha valamelyik lakó bekapcsolja a számítógépét, akkor az operációs rendszere kapcsolatba lép a DHCP-kiszolgálóval, ami válaszul visszaadja a kliens számára fenntartott IP-címet. 3.44 Samba http://samba.org Az LDAP-kiszolgáló elvégzi a felhasználó

azonosítását, azonban szükség vagy egy fájl-szerverre, ami tárolja a felhasználók fájljait. Ezen felül a Samba-kiszolgáló végzi a nyomtató-megosztást is. GNU/Linux rendszeren az egyetlen teljes értékű1,2 fájl-szerver a Samba, amelyet eredetileg Andrew Trigdell kezdett el fejleszteni. Az SMB (Server Message Block) protokoll használatával a Samba az operációs rendszerek bámulatos sokasága között teszi lehetővé az erőforrások megosztását. A Samba a NetBIOS-ból fejlődött ki, bár a NetBIOS nem annyira protokoll, mint inkább hálózati programok írásához építőköveket szolgáltató programozási felület (API). Bár a legtöbben úgy tekintenek a Samba-ra, mint amivel egy NT-kiszolgálót kiválthatunk egy linux-os géppel, azonban a Samba képes fájlmegosztási szolgáltatást biztosítani Windows 95/98/NT/2000/XP, OS/2, VMS, AIX, HP-UX, Linux és még sok más rendszer között. [9] A Samba két legfontosabb démonja az nmbd és az smbd. Az

első egy NetBIOS névkiszolgálóként működik, az utóbbi pedig az SMB kiszolgáló feladatait látja el. Képes tallózásvezérlőként (local master) és tartománygazdaként (domain master) is működni, valamint nyújthat WINS szolgáltatást is. 1. Elsősorban nyílt forráskódú programra értem 2. Többek között létezik az NFS is, de a Samba sokkal több szolgáltatást nyújt 3. Felhasznált komponensek 3.5 12 Adatbázis programok Központosított felhasználó-kezelést megvalósítani csak adatbázisok használatával lehet. A feladat kivitelezésénél két adatbázist is használtam. 3.51 MySQL http://dev.mysqlcom Adatbázis-kezelésről általában akkor beszélünk, amikor a feldolgozandó, kezelendő adatok mennyisége olyan nagy, hogy azok már semmiképpen nem férnek el a számítógép operatív memóriájában, így a háttértáron kell elvégeznünk a munkát. Mivel a számítógép memóriája nagyságrendekkel gyorsabb, mint bármely

háttértár, az adatbázis-kezelés a kezdetek óta speciális problémákat vetett fel. A Unix rendszerek által biztosított szűrőprogramok (sort, grep, awk, stb.) ha nem szükséges, nem olvassák be a bemenő adatokat egyszerre a memóriába, így képesek igen nagy adatmennyiséget feldolgozni. Ennek ellenére az „adatbázis-kezelés” kifejezésen nem ezeket az eszközöket értjük, hanem különleges, kimondottan nagy adatmennyiség feldolgozására készült programokat. Napjaink relációs adatbázisainak kezelésére adatbázis-kiszolgálókat használunk. Az adatbázis-kiszolgáló olyan programrendszer, amely több felhasználó által kezelt adatbázisokon végez műveleteket. Általában megengedett, hogy egy adatbázist egy időben több felhasználó is használhasson, az ebből adódó problémák kezelését ugyanis szintén az adatbázis-kiszolgálón futó programok végzik. GNU/Linux rendszereken igen elterjedt mind a MySQL és mind a PostgreSQL

adatbáziskiszolgáló. Diplomamunkám megvalósításához a MySQL programot választottam. Adatbázisban jelenleg csak 56 felhasználó adatát kell tárolni, de ha minden lakó szeretne internet-elérést, akkor is maximum 106 fő adatát kellene tárolni. Ilyen mennyiség esetén szinte mindegy, hogy melyik adatbázis-kiszolgáló programot használja az ember. A PostgreSQL inkább hatalmas adatbázisok esetén mutatja meg az erejét. Az adatok mennyisége és felhasználása alapján a választásom a MySQL programra esett, mert csak egyszerű (select, insert, update, delete, stb.) műveleteket kell végrehajtani az adatbázis-táblákon, és ilyen műveletek esetén a MySQL kiemelkedően gyorsan dolgozik. [10] 3. Felhasznált komponensek 3.52 13 OpenLDAP http://www.openldaporg Minél több szolgáltatást és programot használnak egy vállalaton belül, minél több helyen használunk felhasználó-azonosítást, annál nehezebb rendszergazdaként kézben tartani

a felhasználók azonosítását. Nagy segítséget jelent egy központosított azonosítási rendszer Egy központi adatbázis használatával a biztonság is nagymértékben növelhető. Azonban gondot jelenthet, ha ez a központi adatbázis valami oknál fogva elérhetetlenné válik, ezért célszerű hibatűrő telepet használni. Azonban szakdolgozatom során nem volt szükség HA (high availability – magas rendelkezésre állású) géptelepre. A feladat kivitelezéséhez egy LDAP-kiszolgáló (Lightweight Directory Acces Protocol – Pehelysúlyú könyvtárhozzáférési / címtárhozzáférési protokoll) végzi el a központosított felhasználó-azonosítást, amire az OpenLDAP kiszolgáló-programot használtam fel. Azonban jó, ha tudjuk, hogy léteznek más programok is, amelyek megvalósítják az LDAP-t. Ilyen például a Netscape Directory Server, a Sun ONE Directory Server és korlátokkal ugyan, de a Microsoft Active Directory is a Windows 2000 szerverben.

Megjegyzem, hogy a Novell NDS rendszerében alkalmazhatunk „LDAP-illesztő interface”-t, így ez a rendszer is megfelelhet – szükség esetén – egy LDAP-kiszolgálónak. Az LDAP v3 protokoll, amelynek támogatása az OpenLDAP 2.0-ás változatában jelent meg, képes a TLS (Transport Layer Security – Szállítási rétegbeli biztonság) alapú védelemre – ezt a megoldást a böngészők és a levelezőprogramok is használják. A TLS az SSL (Secure Sockets Layer) utódja. 3.6 Levelezéshez használt programok Igyekeztem egy biztonságos levél-szervert összeállítani, amelybe természetesen beletartozik a víruskeresés és a SPAM szűrése is. 3.61 Postfix http://www.postfixorg A Postfix egy MTA (Mail Transfer Agent), mely szabadon elérhető az IBM Public License alatt. Eredetileg Wietse Venema kezdte el fejleszteni az IBM támogatásával Vmailer név alatt, 3. Felhasznált komponensek 14 de később nevet kellett változtatni, mivel az említett nevet

már más termék használta, így született a Postfix név. Méltán híres teljesítményéről, biztonságosságáról, és igen széles körű konfigurálási lehetőségeiről, ideértve pl. akár LDAP alapú lookup-okat, és különböző SPAM/UCE szűrési lehetőségeket is. A Postfix fejlesztésénél fő szempont továbbá a "szép" kód, és a kompatibilitás más MTA-kal, mely jelenti az RFC-k pontos betartását, vagy akár a sendmail-ből, illetve qmail-ből (pl: Maildir támogatás) ismert adminisztrálási megoldásokkal való kompatibilitást, lehetővé téve a könnyű átállást Postfix-re. 3.62 AMaViSd-new http://www.amavisorg Az AMaViSd-new egy olyan szkript, ami interfészt biztosít a levélküldő ügynök (MTA) és a különböző víruskeresők és tartalomszűrők (például SPAM) között. Támogatja az összes levélküldő ügynököt (MTA) az általános SMTP szűrő (filter) módon keresztül (ideális a Postfix-hez és az Exim-hez).

Gyorsabb és biztonságosabb az SMTP filter módot használni, mint az AMaViS cső (pipe) klienst. 3.63 ClamAV http://www.clamavnet A Clam AntiVirus egy GPL license-szű víruskereső program UNIX rendszerekhez. Főleg mail-szerverbe integrálva használják, elsősorban a csatolások (attachment) átvizsgálására. A kereső tartalmaz egy flexibilis, stabil és több-szálas működést is támogató motort, valamint képes automatikusan frissíteni a vírus-adatbázisát az Interneten keresztül. A víruskereső főbb jellemzői: • parancssoros keresési • milter interfész a sendmail számára • adatbázis frissítés digitális aláírás támogatásával • valós idejű keresés (Linux és FreeBSD rendszeren) • több mind 20000 vírus, féreg és trójai program detektálása • beépített támogatás: RAR (2.0), Zip, Gzip, Bzip2, Tar, MS OLE2, MS Cabinet files, MS CHM (Tömörített HTML), MS SZDD • beépített támogatás: mbox, Maildir és raw

postafiókokhoz 3. Felhasznált komponensek 3.64 15 SpamAssassin http://spamassassin.org A SpamAssassin (SA) egy úgynevezett "pontozásos" rendszerben működő levélszemét szűrő. Használatához át kell rajta hajtani a beérkező leveleket, és a SA különböző szempontok (trágár szavak, csupa nagybetű a tárgyban, nem azonosítható küldő, és egyéb SPAM-ra utaló jelek) alapján pontozza a levél tartalmát, fejlécét, stb. Milyen technika alapján szűr? • fejléc elemzés • szöveg elemzés • feketelisták (mail-abuse.org, ordborg, stb) • Razor SPAM-adatbázisa (http://razor.sourceforgenet) Ha a levél egy előre beállított pontszámot elér, akkor SPAM-nak minősül, és innentől kezdve eldönthetjük, hogy mit szeretnénk vele kezdeni. A SA kombinálható víruskeresővel is, így hatékony védelmet adhat a vírusok, férgek (worm) és egyéb elektronikus kártevők ellen. A SA tanítható is, azaz a beérkezett SPAM-okból

képes bővíteni a felismeréshez használt adatbázisát. 3.65 Courier Mail Server http://www.courier-mtaorg A Courier levél-átviteli ügynök (MTA) egy integrált levelezés/csoportmunka kiszolgáló, olyan open commodity(?) protokollokon alakul, mint például az ESMTP, IMAP, POP3, LDAP, SSL és HTTP. A Courier ESMTP-t, IMAP-ot, POP3-at, webmail-t és levelezőlista szolgáltatásokat biztosít egyetlen konzisztens keretrendszerben. Egyedi komponensek ki- és bekapcsolhatóak tetszés szerint. A Courier-ben most implementálásra került alap web-alapú naptár és határidőnapló szolgáltatások, a webmail modulba integrálva. Továbbfejlesztett csoportmunkanaptár szolgáltatások is jönnek hamarosan 3.66 SquirrelMail http://www.squirrelmailorg SquirrelMail egy alapszintű webmail csomag, amit tiszta PHP4 nyelven írtak, beleértve a tiszta PHP nyelvű támogatást az IMAP és az SMTP protokollhoz. Az összes általa előállított oldal tiszta HTML 4.0 (JavaScript

igény nélkül) nyelven készül a teljes böngészőfüggetlen 3. Felhasznált komponensek 16 megjelenítés érdekében. Kevés követelményt támaszt a futtatásához, ezen felül könnyű telepíteni és beállítani. A SquirrelMail minden funkciót képes megvalósítani, amit egy átlagos levelező program is tud: MIME támogatás, címjegyzék, mappa műveletek, stb. 3.7 Egyéb Az egész rendszer kialakításához és biztonságos üzemeltetéséhez felhasználtam még az alábbi programokat. 3.71 OpenSSH http://openssh.org Az SSH a Secure Shell rövidítése. Segítségével bejelentkezhetünk egy másik gépre A telnet-tel ellentétben az SSH titkosítja az adatátvitelt, ami csökkenti az adatátviteli sebességet és jobban terheli az erőforrásokat, azonban a biztonság érdekében vállaljuk ezt a többlet terhet. A Berkeley egyetem által megvalósított rsh, rcp, rlogin (az úgynevezett r*) parancsok leváltására hozták létre, ugyanis egyre fontosabb

szerepet kapott a biztonság. A telnet, FTP és az r* parancsok az adatokat titkosítatlan formában küldözgetik, így könnyen ellophatók az adatok, jelszavak. Az SSH ugyan azokat a funkciókat biztosítja, mint az r* parancsok, csak használhatók különböző kódkönyvtárak és azonosító módszerek. 3.72 NetFilter / IPTables http://netfilter.org A netfilter egy beépített blokkoló keretrendszer a 2.4x-es és 26x-es Linux kernel-ekben A keretrendszer képes csomagokat szűrni, hálózatcímet és portszámot fordítani (NAT/NAPT), valamint képes egyéb csomagmanipulációkra. Újratervezett és nagymértékben javított utódja a Linux 2.2x ipchains és a Linux 20x ipfwadm rendszerének Az iptables egy általános táblastruktúra szabályrendszerek definiálására. Minden IP táblázaton belüli szabály több osztályozót (iptables matches) tartalmaz és egy hozzá kapcsolódó eseményt (iptables target). A netfilter, iptables és a kapcsolat követés, valamint a

NAT alrendszer együttesen képzik a keretrendszert. 3. Felhasznált komponensek 17 Főbb tulajdonságok • nem állapottartó (stateless) csomagszűrés (IPv4 és IPv6) • állapottartó (stateful) csomagszűrés (IPv4) • hálózatcím és portszám fordítás (NAT/NAPT) • flexibilis és bővíthető kialakítás • többrétegű API felület a külső fejlesztők számára • hatalmas plugin és module gyűjtemény patch-o-matic csomagban Mire használható a netfilter / iptables? • építhető stateless és stateful csomagszűrő tűzfal • a NAT és a MASQUERADE használatával internet megosztás hozható létre, ha nincs elég publikus IP-cím • NAT használatával létrehozhatók átlátszó (transparent) proxy-k • egyéb csomagmanipulációk (mangle), úgymint TOS/DSCP/ECN bit-ek változtatása az IP csomagok fejlécében 3.73 Shaperd http://webs.sinectiscomar/lesanti/shaperd Felhasználó-módban futó sávszélesség-korlátozó

program TCP/IP hálózatokban. A Shaperd a háttérben fut, mint egy normál daemon program, azonban szüksége van valamilyen csomagtovábbító mechanizmusra, ami átadja neki a csomagokat. Jól együttműködik a Linux 2.4 netfilter / itptables rendszerével 4. Megvalósítás ismertetése 18 4. Megvalósítás ismertetése A felhasznált komponensek és a részletes feladatleírás ismertetése után felvázolom a megoldás menetét röviden, majd az egyes részfeladatok teljes megvalósítását. A feladat két részre bontható: hardver és szoftver. Az alábbiakban ismertetem mindkettő felé támasztott igényeket és követelményeket, valamint a feladat kivitelezését. 4.1 Hardver A feladat kivitelezése előtt egy számítógép végezte a tűzfal, web-szerver és többé-kevésbé a DNS feladatát. A vezetőség számítógépparkjában történt fejlesztések során a leselejtezett gépekből kaptunk két darabot, így a három számítógépből lehetőségem

nyílt létrehozni egy olyan szerverfarmot, amelyben logikailag és fizikailag is elszeparálható szolgáltatásokat külön szervergépre tudtam helyezni. 4.11 Szerver-gépek Az alábbi listában bemutatom a rendelkezésemre álló számítógépeket. Látható, hogy mindegyik „szerver” gépben Celeron processzor dolgozik. Azonban, mint köztudott, a Celeron processzorokat közel sem szerverekbe szánják, nem arra tervezték őket, hogy napi 24 órában dolgozzanak. A tűréseknek és az előírásoknak nem megfelelő Pentium típusú processzorokból lettek a Celeron-ok. Ennek tudatában próbáltam a szolgáltatásokat elosztani, kikapcsolni a titkosításokat, ahol nem létkérdés, azaz minimalizáltam a szerverek terhelését. WOTAN szerver: • Celeron@333MHz, 384MB RAM, 4GB IDE HDD • IP-címei: 192.16811, 192168211, 19322515118 • ADSL kapcsolat biztosítása a vezetőségi gépeknek (igazgatói, gazdasági, lelkészségi) • DNS, DHCP, Postfix és Apache

(http://sztlkk.hu) ZEUS szerver: • Celeron@333MHz, 64MB RAM, 3GB IDE HDD • IP-címei: 192.168334, 192168212, 1921681001, 19322515117 • tűzfal és sávszélesség-korlátozás ellátása 4. Megvalósítás ismertetése 19 SUN szerver: • Celeron@300MHz, 92MB RAM, 3GB IDE HDD • IP-címe: 192.16821200/32 • Samba, MySQL, LDAP és Apache (http://it.sztlkkhu – csak belső hálóról) 4.12 Aktív eszközök Egy hálózat áteresztő képessége jelentősen függ az aktív eszközök minőségétől és tulajdonságaitól, valamint a megfelelően kialakított függőleges és vízszintes kábelezéstől. Az alábbi aktív eszközök álltak rendelkezésemre a feladat kivitelezésekor: • 1 db Nortel Networks Baystack 350-24T Switch (Nortel switch) • 1 db HP ProCurve Switch 2524 J4813A (HP switch) • 1 db Cisco System FastHub 400 Series (Cisco FastHub) • 2 db Series Mikro Networks Ethernet HUB-16+ (HUB#1 és HUB#2) Nem aktív eszközök, de

logikailag ide tartoznak a patch-panelek: • RiT SMART UTO 24 ISO/IEC 11801 CATEGORY 5 • RiT SMART UTO 48 ISO/IEC 11801 CATEGORY 5 • EMInet System CAT5E-16 Unshielded (kabinet terem) 4.13 IP-cím tartományokról Négyféle IP-cím tartományt használ a rendszer a működése során, a következőkben ezeket az IP-cím tartományokat mutatom be, hogy melyiket mely gépek használják és mikor. 192.16810/24 A vezetőségi gépek ebből az IP-cím tartományból kapnak IP-címet. Ebből a hálózatból nem látható a kollégium lakói számára fenntartott hálózat. 192.1681000/24 A kollégiumba beköltöző hallgatók IP-cím igényléséhez használatos hálózat. A rendszer által ismeretlen számítógépek ebből a hálózatból kapnak IP-címet, hogy elérjék az IT honlapját1 és tudjanak igényelni maguknak rendes IP-címet, amivel tudnak internetezni. 1. De mást nem 4. Megvalósítás ismertetése 20 192.168210/24 A kollégium lakói számára

fenntartott hálózat. Ez egy egyetemi belső hálózatos címtartomány, de csak a mi kollégiumunk használhatja. Ennek köszönhetően a tűzfalunk nem végez címfordítást, hanem csak szűri a rajta átmenő csomagokat a portok és címek alapján, valamint megvalósítja a sávszélesség-korlátozást. A NAT-olást az egyetem fő router gépe végzi 193.22515116/28 Szintén az egyetemtől kapott címtartomány, külső IP-címes alhálózat, amiből 14 IP-cím használható. A használatából eredő veszélyek miatt csak kivételes lakók kaphatnak innen IP-címet. 192.168330/24 A két rádiós eszköz, az egyetem és a kollégium router-e (ZEUS) tartozik csak bele. Azért hoztuk létre az Széchenyi István Egyetem rendszergazdájával, hogy az egyetem felöl érkező broadcast üzeneteket még az egyetem oldalán megfogja, valamint a mi broadcast üzeneteinket se enged át az egyetem felé. Ezzel jelentősen tudtuk növelni az áteresztőképességet, jelentősen kevesebb

csomag vesz el ezután. 4.14 Kialakított hálózati topológia Két Internet csatlakozással rendelkezik a kollégium. Ez lehetőséget adott arra, hogy a vezetőségi gépek Internet ellátását teljesen elszeparáljam a kollégium lakói által használttól. A vezetőségi gépek a HUB#2 eszközre csatlakoznak, amire csatlakozik a WOTAN szerver is, biztosítva számukra az Internet-megosztást, DHCP-, DNS-, SMTP- és POP3-szolgáltatásokat, valamint a tűzfal szerepét is ő tölti be erre a hálózatra. Ez a hálózat a 19216810/24-es című A Nortel és HP switch-eket egy szálon (trunk-ölés nélkül) kötöttem össze, hogy minél több hely maradjon rajtuk a szobai gépek számára, de sajnálatos módon így sem elég e kettő kapacitása, fel kellett használnom még egy 16 portos hub-ot is (HUN#1). Figyeltem rá, hogy a kialakított hálózat áteresztő képessége a lehető legjobb legyen, ezért a ZEUS és a WOTAN szerver is a logikailag középen elhelyezkedő HP

switch-re került, így nem fordulhat elő az, hogy valakinek két switch-en keresztül kell mennie a szerverig és onnan tovább az Internetre. Műszakilag megoldható lenne, hogy több szálon legyenek összekötve (trönk) az aktív eszközök, azonban nem áll rendelkezésre megfelelő számú switch a kivitelezéshez. A switch-ek virtuális áramköröket hoznak létre az aktív portjaik között, így egy 10/100-as switch-en keresztül egyszerre több szálon is lehet tölteni 100Mbit-es sebességgel. Dedikált 4. Megvalósítás ismertetése 21 sávszélességet biztosít a virtuális áramkörrel összekötött két portnak, azonban, ha két switch-et kötünk össze, ott, azon az egy kábelen keresztül maximálisan 100Mbit-es sebességet érhetünk el. Azaz, ha egyszerre 2 szálon töltünk át adatot a két switch között, akkor a két szál összesen is csak 100Mbit-es sebességet ad, tehát 1 szál átviteli sebessége egyből a felére csökken. A switch-ek 24

portosak, így könnyen belátható, hogy az egy kábeles összeköttetés kevés, de sajnálatos módon nincs lehetőség több szálas összeköttetésre (trunk-ölésre), mert akkor nem férne rá minden szoba a három aktív eszközre. Megoldás lenne még, ha vennénk gigás uplink-et a két switch-be, azonban a beültethető csatlakozók darabonkénti 70.000,0 HUF nettó értéke túl sok számunkra jelen pillanatban. Erre a hálózatra rákötött számítógépek vagy a 192.168210/24-es (belső IP-címes) vagy a 19322515116/28-as (külső IP-címes) hálózatból kapnak IP-címet. Természetesen a két hálózat számítógépei elérik egymást mindenféle címfordítás nélkül, úgymond transparent módon (átlátszó) köti össze a ZEUS szerver a két hálózati tartományt. A rendszer által még nem ismert gépek a 192.1681000/24-es hálózatból kapnak IP-címet, azonban ebből a hálózatból csak a SUN szerver látható, hogy elvégezhető legyen az IP-cím

igénylés, de az igénylési folyamatról majd később. Ezen felül a kabinet terem számítógépei számára is kellett Internet-elérést biztosítanom. A kabinet teremben foglal helyet a Cisco FastHub, ami szintén a logikailag középen elhelyezkedő HP switch-re csatlakozik, amire kötöttem rá a 10 kabinetes számítógépet és a SUN szervert. Bár a kabinet terem kialakításának megtervezését és kivitelezését is én végeztem, azonban ez nem képezi részét a szakdolgozatomnak, így a kabinet terem fizikai (kábelcsatornázás, kábelbeültetés, stb.) kivitelezését nem részletezem Az egész rendszer topológiai kialakítása a „4.11 Ábra: Hálózati topológia” ábrán látható Mind a függőleges, mint a vízszintes kábelezés CAT5-ös UTP kábelezéssel megvalósították meg még 5 évvel ezelőtt, így az elérhető legnagyobb elméleti átviteli sebesség 100Mbit/sec. A hub eszközre kötött szobák átviteli sebességét sajnos maga a hub

bekorlátozza 10Mbit/sec sebességre, valamint tovább rontják a hub felépítéséből és működéséből adódó gyakori ütközések, de ez a lassulás csak a kollégium belső hálózatán érezhető, mivel az internet-elérés sebessége csak 11Mbit, amit az egyetemtől „kapunk” egy 802.11b-s rádiós eszközön keresztül. 4.11 Ábra: Hálózati topológia WOTAN szerver lelkészségi igazgatói gép gép gazdasági gép HUB#2 ADSL internet csatlakozás felhasználók gépei Nortel switch kabinet terem gépei felhasználók gépei HUB#1 4. Megvalósítás ismertetése HÖK nyomtatója SUN szerver Cisco fasthub felhasználók gépei HP switch ZEUS szerver Rádiós internet csatlakozás 22 4. Megvalósítás ismertetése 4.2 23 Szoftver beállítások szerver oldalon A biztonságos működéshez érdemes finomhangolni egy-két szolgáltatást. Ebben az alfejezetben végigveszem az egyes programok beállítását, amelyek nélkül nem

működhetne biztonságosan a kialakított rendszer. 4.21 Jelszó nélküli felhasználó-azonosítás kulcsok segítségével SSH esetén Egyik legfontosabb biztonsági beállítás, ugyanis a SUN szerver által előállított DHCP, DNS és IPTables beállítófájlokat el kell juttatni a megfelelő szervernek és az adott szolgáltatást újra is kell indítani. A jelszót nem írhatjuk be a szkript programban (biztonsági okokból), ezért biztonságos jelszó nélküli azonosítást kell alkalmazni. Első és egyben elengedhetetlen lépés, hogy saját kulcspárt készítsünk az ssh-keygen programmal. Két választási lehetőségünk van: vagy RSA- vagy DSA-kulcsokat használunk Az RSA-szabadalom lejárt 2000 szeptemberében, azonban az SSH Protocol v.2 DSA rendszerű kulcsokat használ alapesetben, valamint a DSA-kulcsok szabadon használhatóak, nyílt szabványként lett kifejlesztve. DSA-kulcsok létrehozása 1 2 3 4 5 6 Bash$ ssh-keygen -t dsa . Your identification has

been saved in /home/jonci/.ssh/id dsa Your public key has been saved in /home/jonci/.ssh/id dsapub . Bash$ A „-t dsa” paraméter megadásával kérhetjük (1. sor) a DSA-kulcspár generálását Az alapértelmezett kulcshossz 1024 bit. Az 512 bites RSA/DSA-kulcsok nyers erő (brute force) módszerével könnyen feltörhetők. A 2048 bites kulcsok nem sokkal biztonságosabbak a 1024 bites kulcsoknál, azonban jelentősen lassítják a kódolási folyamatot. A kulcspár létrehozása során két kulcsfájl jön létre. Az egyik a titkos (3 sor), a másik a nyilvános (4 sor) kulcsunkat tartalmazza. A nyilvános kulcsot el kell juttatni a távoli gépen a $HOME/.ssh/ könyvtárunkba és hozzá kell fűznünk az authorized keys fájlhoz1. A paranoiánktól függően választhatunk több különböző módszer között az átvitelre. Az interneten keresztüli adatátvitelre az ssh nyújtja a 1. Szerver beállításától függően adódhat úgy is, hogy az authorized keys2 fájlt kell

használni 4. Megvalósítás ismertetése 24 legbiztonságosabb közeget, azonban ez is kijátszható, így az ajánlott módszer az, ha valamilyen adathordozót (floppy, CD, Pendrive, stb.) választunk a kulcs átvitelére A kulcs átvitele után az ssh <távoli gép> parancs kiadásakor az ssh szerver jelszó nélkül beenged minket, ugyanis a generált DSA-kulcspárunkkal azonosítjuk magunkat. /etc/ssh/sshd config részlet 1 2 3 PasswordAuthentication no PermitRootLogin yes PermitEmptyPasswords no Ha az azonosítás nem sikerült, akkor a név/jelszó módszerrel még mindig azonosíthatjuk magunkat, azonban ez utóbbit érdemes letiltani az sshd config fájlban, ha biztosra akarunk menni (1. sor) Abban az esetben, ha nem akarjuk tiltani a név/jelszó azonosítást, legalább tiltsuk meg a bejelentkezést a root felhasználó számára (2. sor), valamint ne engedélyezzük az üres jelszót (3. sor) Távoli parancsvégrehajtás ssh-val 1 Bash$ ssh <távoli

gép> <parancs> 2 ssh $SZERVER WOTAN sh /etc/init.d/dhcp3-server restart 2>&1 > /dev/null Távoli gépen történő parancsvégrehajtásra szintén az ssh programot használhatjuk. A parancs szintaktikáját az 1. sorban láthatjuk A DHCP-kiszolgáló újraindítását – a szabalyok dhcp perl szkriptben – a 2. sorban látható módon oldottam meg E megoldás az egyik legegyszerűbb egy távoli gépen futó daemon program újraindítására. 4.22 DHCP-kiszolgáló A vezetőségi számítógépek számára is a WOTAN szerver biztosítja az IP-cím kiosztást DHCP-vel. Ebben semmi különleges beállítási opció nincs, ellenben a szobai IP-címek kiosztásával. Ugyanis egy fizikai kábelezésen három IP-cím tartományt használunk: 192.1681000/24, 192.168210/24, 193.22515116/28 Ezen okból kifolyólag„shared-network” beállítást kell alkalmazni. Ennek a beállítását (3-17 sor) lehet látni dhcp.conf fájlban: 4. Megvalósítás

ismertetése 25 /etc/dhcp3/dhcp.conf részlet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 default-lease-time 3600; max-lease-time 7200; shared-network 192.168100-19216821-193225151 { subnet 192.1681000 netmask 2552552550 { # dns, domain, router, broadcast címek megadása default-lease-time 60; max-lease-time 120; } subnet 192.168210 netmask 2552552550 { # dns, domain, router, broadcast címek megadása # ismert kliens IP-címének hozzárendelése a MAC-címéhez } subnet 193.22515116 netmask 2552552550 { # dns, domain, router, broadcast címek megadása # ismert kliens IP-címének hozzárendelése a MAC-címéhez } } A 192.1681000/24-es hálózat IP-cím igénylésre szolgál csak, azért az alap lejárati idő 60, a maximum lejárati időt 120 másodpercnek (6-7. sor) állítottam be, ugyanis a rendszer két percenként ellenőriz1, hogy újra kell-e indítania valamelyik szolgáltatást (DHCP, DNS, tűzfal). A MAC-címhez rendelt IP-címeket nem írtam be a kezdeti fájlba,

ugyanis azt a szabalyok dhcp (lásd később) perl szkript generálja a felhasználói adatbázisból. 4.23 BIND9 A WOTAN biztosítja az egész kollégium számára a névfeloldást, valamint a külső IP-címesek névfeloldását az Internet felé is. A program alapbeállítása megfelelő, csak a zónabejegyzéseket hoztam létre: /etc/bind/named.conf részlet 1 2 3 4 zone ”sztlkk.hu” { type master; file ”sztlkk.hu”; }; 5 6 7 8 zone ”21.168192in-addr” { type master; file ”sztlkk.hurev”; }; 9 10 11 12 zone ”sztlkk.szehu” { type master; file ”sztlkk.szehu”; }; 13 14 zone ”16/28.225193in-addr” { type master; 1. Indoklása a „Perl szkriptek / szabalyok ervenyesitese” alfejezetben 4. Megvalósítás ismertetése 15 16 26 file ”sztlkk.szehurev”; }; Az 1-8. sorig szerepel a belső IP-címek zónafájljainak megadása: DNS (1-4 sor) és reverse DNS (5-8. sor) Az 9-16 sorig pedig a külső IP-címek zónafájljainak megadása szerepel:

DNS (9-12. sor) és reverse DNS (13-16 sor) A megadott zónafájlokat teljes egészében a szabalyok dns (lásd később) perl szkript generálja. 4.24 Apache Természetesen SSL titkosítás támogatásával feltelepítettem, hogy titkosított csatornán keresztül történjen a bejelentkezés a honlapra. Az SSL támogatás beállítása Debian GNU/Linux rendszeren nagyon könnyen elvégezhető néhány dialógus ablak megválaszolásával, ezért csak a virtuális host létrehozását mutatom be: /etc/apache/httpd.conf részlet 1 2 3 4 5 6 7 8 NameVirtualHost 192.16821200 <virtualhost it.sztlkkhu> serveradmin it@sun.solarsystemsztlkkhu Documentroot /var/www/it servername it.sztlkkhu ErrorLog /var/log/apache/it/error.log CustomLog /var/log/apache/it/access.log common </virtualhost> Az it.sztlkkhu névfeloldását a WOTAN gép végzi Azért kellett virtuális host-ot létrehozni, mert a SUN szerver fő honlapja másra van fenntartva, meg azért is, mert a SUN

gép címe igazából: sun.sztlkkhu A 2-8 sorig tart az itsztlkkhu virtuális szerver definiálása és ez egyéb lokális paraméterek beállítása. 4.25 Samba A Samba valósítja meg a fájl-szerver funkciót (tárolja a felhasználók profil könyvtárát) és végzi el a felhasználó hitelesítését szükség esetén. A legszebb a Samba-ban, hogy képes akár egyszerre is együttműködni az összes Windows változattal más operációs rendszerek mellett. /etc/samba/smb.conf részlet: a [global] rész 1 2 3 4 [global] netbios name = sun workgroup = KABINET comment = LDAP es NYOMTATO server 4. Megvalósítás ismertetése 5 6 7 8 9 10 server string = %h server (Samba %v with LDAP) client code page = 852 character set = ISO8859-2 valid chars = 0x8B:0x8A 0xFB:0xEB time server = yes case sensitive = no 11 12 13 14 15 16 17 18 19 20 21 22 23 24 null passwords = no encrypt passwords = true password level = 10 password server = sun security = user domain master = yes local

master = yes preferred master = yes os level = 99 domain logons = yes logon path = \%Lprofiles\%u logon home = \%L\%U logon drive = X: logon script = login.bat 25 26 27 28 29 30 31 32 33 passdb backend = ldapsam:ldap://localhost:389/ ldap ssl = off ldap admin dn = "cn=admin,dc=sztlkk,dc=hu" ldap suffix = "dc=sztlkk,dc=hu" ldap user suffix = "ou=Users" ldap machine suffix = "ou=Computers" ldap group suffix = "ou=Groups" ldap delete dn = no ldap passwd sync = no 34 35 36 load printers = yes printcap name= /etc/printcap.cups printing = bsd 27 A 2-5. sorig általános beállításokat tartalmaz, gépnév munkacsoport/tartomány, stb, valamint a 6-7. sorig beállítjuk, hogy helyesen kezelje a magyar karaktereket A 8 sor megadásával érhetjük el, hogy bármelyik magyar Windowstól érkező fájlnévben szereplő őŐűŰ karakter helyesen tárolódjanak. A 11-13. sorig terjedően növeljük kicsit a biztonságot, majd 16-20 sorig

beállítjuk, hogy a Samba szerverünk legyen a domain master, valamint ha több domain master lenne a hálózatban, akkor versenyezzen az elsőbbségért. A 15 sorban user a beállított érték, mert a Samba szerver végzi el a hitelesítést felhasználóként az LDAP adatbázis felhasználásával, nem pedig magát a bejelentkezett számítógépét akarjuk hitelesíteni. A 21-24. sorig határozzuk meg, hogy a beléptetés során a kliens gép honnan vegye a felhasználó profil könyvtárát, valamint beállítódik még pár hálózati beállítás. 4. Megvalósítás ismertetése 28 Az igazi lényeg a 25-33. sorig található meg Itt adjuk meg a Samba-nak, hogy jelszóadatbázis merre található (LDAP), valamint az LDAP-adatbázisra vonatkozó úgynevezett ”suffix”-eket (utótag, rag, toldalék): magára az adatbázisra, valamint a felhasználók és a számítógépek bejegyzéseihez. A 34-36 sorig pedig a nyomtató beállítása található /etc/samba/smb.conf

részlet: a [netlogon] rész 37 38 39 40 [netlogon] comment = Network Logon Service path = /var/lib/samba/netlogon browseable = no A 24. sorban megadott login szkript program könyvtárát is meg kell osztani, hogy a kliens gépek hozzáférhessenek a bejelentkezés alkalmával. Természetesen, nem kell tallózhatónak lennie (40. sor) mivel megadtuk a szkript nevét (24 sor), nem kell tudnia a felhasználónak, hogy milyen más szkriptek találhatók itt még meg, ugyanis lehet személyre szabott szkripteket is készíteni. /etc/samba/smb.conf részlet: a [profiles] rész 41 42 43 44 45 46 47 48 49 50 51 52 [profiles] comment = Network Profiles Service path = /var/lib/samba/profiles/%u read only = no create mask = 0600 directory mask = 0700 writable = yes guest ok = no root preexec = PROFILE=/var/lib/samba/profiles/%u;if [ ! -e $PROFILE ] ; then mkdir -pm700 $PROFILE; chown %u.%g $PROFILE; fi; /usr/lib/cgi-bin/kabinetgepekfoglaltsaga pre %m %u root postexec =

/usr/lib/cgi-bin/kabinetgepekfoglaltsaga post %m %u A felhasználó saját profil könyvtárának megosztását végezzük el a 43. sorban, aminek a végén szereplő %u helyére a felhasználó login neve helyettesítődik be, így minden felhasználó számára egyedi profiles nevű megosztás jön létre, ami a saját windows-os profil könyvtárát tartalmazza. Továbbá megadtam egyéb biztonsági beállításokat, úgy mint: létrehozott fájl jogai (45. sor), létrehozott könyvtár jogai (46 sor), vendég felhasználó ne férjen hozzá (48 sor). A 49-51 sor tartalmazza a lefuttatandó parancsot a hitelesített felhasználó bejelentkezése előtt (bejegyeztetem, hogy melyik felhasználó mikor melyik géphez ült le), valamint a 52. sorban megadom, hogy melyik programot kell lefuttatni, amikor a kapcsolat megszűnik a szerver és a felhasználó között. 4. Megvalósítás ismertetése 29 /etc/samba/smb.conf részlet: a [printers] rész 53 54 55 56 57 58 59 60 61

[printers] browseable = no path = /tmp printable = yes guest ok = no public = no writeable = no create mode = 0777 print command = /usr/lib/cgi-bin/nyomtatas %u /tmp/%s A HÖK birtokol egy nyomtatót, amit szívesen átadott a számunkra, hogy csináljunk belőle egy – a számítógépes hálózaton keresztül – mindenki számára elérhető nyomtatót. A legjobb megoldás, hogy a nyomtatást is a hitelesítést végző szerver végezze1. Az 55 sorban adtam meg, hogy a nyomtatandó dokumentum ideiglenesen hova kerüljön a nyomtatásig. A 61 sorban adtam meg, hogy a nyomtatandó dokumentumot melyik program nyomtatja ki sikeres hitelesítés esetén. Természetesen a megadott szkriptet2 is én írtam, hogy a kinyomtatandó oldalszámot és annak árértékét is elmenthessem a MySQL adatbázisba. 4.26 Mint LDAP létrehozása és a hozzá kapcsolódó programok beállítása a legtöbb hálózati szolgáltatás, képes egyszerre több kiszolgálón futni:

adatbázis-többszörözéssel (replication) vagy átirányítással (referral). Az én esetemben ilyen lehetőségekre nem volt szükség a felhasználók relatív alacsony száma miatt. Ezért az OpenLDAP libraries config állományát az alábbi módon állítottam be (ldap.conf): /etc/ldap/ldap.conf részlet 1 2 3 4 BASE dc=sztlkk, dc=hu URI ldap://localhost:389 ssl no pam password crypt Az alapvető beállításokat adhatjuk meg az adatbázis-kezelő library-knek, miszerint milyen névtérhez (namespace) tartozik az adatbázis (1. sor), merre található meg (2 sor), használjunk-e SSL titkosítást vagy sem (3. sor), valamint a jelszavak tárolásának módját (4 sor). SSL titkosítást azért nem használok, mert csak a – már említett – kabinet teremben lévő gépek léphetnek be a tartományba. E gépek egy switch-en keresztül csatlakoznak a Samba-t és 1. A legjobb megoldás az lenne, ha a MySQL és az LDAP is külön-külön szerveren lenne, de az IT anyagi

helyzete ezt nem teszi lehetővé. 2. Ismertetése a „Perl szkriptek / nyomtatas” alfejezetben 4. Megvalósítás ismertetése 30 az LDAP-t futtató SUN szerverhez, ezért a jelszavak sniffe-elése nem lehetséges, így az amúgy sem erős gép terheltsége legalább nem nő tovább. Magát a szerver részt a slapd daemon program valósítja meg, amin a slapd.conf beállítófájllal állíthatunk a kívánalmaink szerint: /etc/ldap/slapd.conf 1 2 3 4 5 6 7 include include include include include include schemacheck /etc/ldap/schema/core.schema /etc/ldap/schema/cosine.schema /etc/ldap/schema/inetorgperson.schema /etc/ldap/schema/nis.schema /etc/ldap/schema/samba.schema /etc/ldap/schema/qmail.schema on 8 9 suffix directory "dc=sztlkk,dc=hu" "/var/lib/ldap" 10 11 rootdn rootpw "cn=admin,dc=sztlkk,dc=hu" $rootpw A felhasználók eltárolását különböző sémák szerint tehetjük meg. A használt séma fájlok írják elő, hogy milyen

tulajdonságokat (például: vezetéknév, keresztnév, azonosító szám (UID), home könyvtár, email-cím, stb.) lehet megadni egy-egy felhasználóhoz és melyek megadása kötelező. Az 1-6 sorig terjedően írom elő a használni kívánt sémafájlokat A 7 sorban bekapcsoltam a séma ellenőrzést, így a bejegyzések hozzáadását és módosítását ellenőrzi a szerver, hogy biztosan megfeleljen az objektum-osztályaik definícióinak. Különösen hasznos volt, mialatt írtam a CGI szkriptet, mert így nem adódtak hosszá az adatbázishoz hibásan megadott bejegyzések. A 8. sorban megadom a már az ldapconf fájlban is látott ”suffix”-et, a 9 sorban pedig az adatbázist tartalmazó könyvtárat adtam meg. Amikor létrehozzuk az LDAP adatbázist, teljesen üres. Az adatbázishoz való hozzáférés az adatbázisban lehet engedélyezni. Mivel az adatbázis üres, ezért kell egy ideiglenes pótmegoldás, amit a kezdeti adatfeltöltés után célszerű megszüntetni.

Ezt a pótmegoldást szolgálja a 10-11. sorban megadott név/jelszó páros Miután létrehoztunk egy admin felhasználót, akinek megadtunk minden jogot az adatbázisra, töröljük ezt a két sort, vagy legalább „kommentezzük ki”. 4. Megvalósítás ismertetése 31 rootpw legenerálása „xxx” jelszóval: 1 2 3 4 Bash$ slappasswd -h {SSHA} New password: Re-enter new password: {SSHA}I/58KBqXfByX6XW+9mAMxzLn3l5+95A7 Legfelső szint létrehozása az LDAP-adatbázisban Az alábbi bejegyzés hozzáadásával kell kezdeni, kell egy közös gyökér, ahonnan ered majd az egész LDAP-fa: toplevel.ldif fájl: 1 2 3 4 5 6 dn: dc=sztlkk,dc=hu objectClass: top objectClass: dcObject objectClass: organization o: SzTLKK dc: sztlkk Azonban ezt a csomagtelepítő automatikusan megteszi a slapd csomag telepítésekor. Admin felhasználó hozzáadása az LDAP-adatbázishoz Kell az adatbázisba egy olyan felhasználó, akinek joga lesz minden további módosítást elvégeznie:

samba tartomány (domain), számítógép, csoport, felhasználó hozzáadása és elvétele. Ez a felhasználó az admin, akit a következő bejegyzés hozzáadásával hozhatunk létre: admin.ldif fájl: 1 2 3 4 5 6 dn: cn=admin,dc=sztlkk,dc=hu objectClass: simpleSecurityObject objectClass: organizationalRole cn: admin description: LDAP administrator userPassword: {crypt}$adminpass A csomagtelepítő ezt is automatikusan megteszi a slapd csomag telepítésekor. A legfelső szint és az admin felhasználó hozzáadásához szükséges a slapd.conf 10-11 sora A telepítés befejezése után azt a két sort töröljük ki. Szükség esetén bármikor visszaírhatjuk, de normális használat mellett többé nem lesz rá szükség. 4. Megvalósítás ismertetése 32 root felhasználó hozzáadása az LDAP-adatbázishoz A root felhasználó megadása is szükséges volt számomra, mert ezzel a felhasználóval lehet csak beléptetni számítógépet a tartományba. root.ldif

fájl: 1 2 3 4 5 6 7 8 9 10 dn: uid=root,dc=sztlkk,dc=hu uid: root objectClass: account objectClass: sambaSamAccount sambaSID: $sid-1000 sambaPrimaryGroupSID: $sid-1001 displayName: root sambaLMPassword: $lmpass sambaNTPassword: $ntpass sambaAcctFlags: [U ] Az 5. és 6 sorban szükséges a tartomány SID azonosítója, amit az alábbi módon tudhatunk meg: SID megtudakolása: 1 2 bash$ net getlocalsid SID for domain SUN is: S-1-5-21-716841307-2303509190-3857244813 Végül elő kell állítani az LM és NT jelszavakat, amik lehetnek azonosak és különbözőek is: LMPassword és NTPassword előállítása „xxx”, majd „xxx” és „yyy” jelszóval: 1 2 bash$ mkntpwd xxx 7DABB104AB058D91AAD3B435B51404EE:C889C75B7C1AAE1F7150C5681136E70E 3 4 bash$ mkntpwd -L xxx -N yyy 7DABB104AB058D91AAD3B435B51404EE:43F89EA52127F0183429B6D83FF37F61 4.27 MySQL A MySQL program nem szorul mélyebb konfigurációra, az alap telepítéskor egy jól beállított rendszer kapunk kézhez.

Azonban érdemes megismerni egy-két beállítási lehetőségével: /etc/mysql/my.cnf részlet 1 2 3 4 [mysqld] skip-networking datadir = /var/lib/mysql port = 3306 4. Megvalósítás ismertetése 33 A mysqld (mysql daemon) beállításának része a kiemelt három beállítás, az 2. sorban állítjuk be, hogy a MySQL szerver csak lokális kérésekre feleljen, azaz a hálózatról érkező kéréseket dobja el. Mivel a honlap ugyanazon a gépen helyezkedik el, mint amelyiken a MySQL-adatbázis is helyett foglal, így nyugodtan beállíthatjuk ezt, csak a biztonságot növeljük vele. A 3 sorban változtathatjuk meg az adatbázisok fájlrendszer szintű helyét A 4 sorban pedig a kommunikációs portot állítottam be, amin keresztül a kliens program kéréseket intézhet a szerver programhoz. 4.28 Postfix Habár a Debian GNU/Linux operációs rendszer alapértelmezett mail-kiszolgálója az Exim, azonban én lecseréltem ezt a Postfix nevű kiszolgálóra. Jobban,

részletesebben konfigurálható, valamint jobban is integrálható az LDAP-ból történő hitelesítés a programba. /etc/postfix/main.cf részlet 1 2 3 4 5 6 7 8 9 10 11 smtpd banner = $myhostname ESMTP $mail name (Debian/GNU) delay warning time = 4h myhostname = sztlkk.hu alias maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf alias database = hash:/etc/aliases myorigin = /etc/mailname mydestination = sztlkk.hu, sztlkkszehu, localhost mynetworks = 127.000/8 192168210/24 19322515116/28 mailbox size limit = 0 home mailbox = Maildir/ content filter = smtp-amavis:[127.001]:10024 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 local transport = virtual virtual mailbox base = /var/mail/ virtual mailbox maps = ldap:/etc/postfix/ldap-aliases.cf virtual uid maps = static:vmail virtual gid maps = static:vmail virtual minimum uid = 1000 virtual mailbox limit = 0 ldapvirtual server host = ldap.sztlkkhu ldapvirtual server port = 389 ldapvirtual bind = yes ldapvirtual bind dn =

cn=admin,dc=sztlkk,dc=hu ldapvirtual bind pw = {SSHA}I/58KBqXfByX6XW+9mAMxzLn3l5+95A7 ldapvirtual search base = dc=sztlkk,dc=hu ldapvirtual query filter = (&(|(mail=%s)(mailAlternateAddress=%s))( (AccountStatus=active)(accountStatus=shared))) ldapvirtual result attribute = mailMessageStore 28 29 30 31 32 33 34 35 36 ldapalias server host = ldap.sztlkkhu ldapalias server port = 389 ldapalias bind = yes ldapalias bind dn = cn=admin,dc=sztlkk,dc=hu ldapalias bind pw = {SSHA}I/58KBqXfByX6XW+9mAMxzLn3l5+95A7 ldapalias search base = dc=sztlkk,dc=hu ldapalias query filter = (&(|(mail=%s)(mailAlternateAddress=%s))(| (AccountStatus=active)(AccountStatus=shared))) ldapalias result attribute = mail 4. Megvalósítás ismertetése 34 Az 1. sorban az Postfix köszöntő szövegét lehet beállítani (lásd: telnet smtp-szerver 25) A 2. sorban beállított érték szerint, ha nem tudja a szerver elküldeni a levelet 4 órán belül, akkor küld erről egy értesítést a feladónak,

de tovább próbálkozik a kézbesítéssel. A 3 sor magától értetendő. A 4 és 5 sorokban az alias-okat tartalmazó adatbázisokat adtam meg A 6 sorban megadom a szerver levelezési nevét. A 7 sorban megadom, hogy milyen címre érkező leveleket fogadjon el. A 8 sorban azokat a hálózatcímeket adtam meg, amelyből használhatják a szervert, mint SMTP-kiszolgáló. A 9 sorban megadottak szerint lehet beállítani a levelesláda maximális méretét byte-ban. A 10 sorban Maildir levelesláda formátumot állítottam be, tettem ezt annak érdekében, hogy IMAP protokollal is le lehessen kérni a leveleket, valamint webmail szolgáltatást is nyújthasson a szerver. A 11 sorban pedig megadom, hogy melyik portra továbbítsa a levelet tartalomszűrés végett. A 12-27. sorig állítom be, hogy a virtuális postafiókokhoz használja az LDAP hitelesítést 19-27. sorig adom meg az admin felhasználót (22 sor) és jelszavát (23 sor), amivel a felhasználó adatait (25-27) lehet

lekérdezni az LDAP-adatbázis fából (24. sor) A 13 sorban adom meg a virtuális mailbox-okat tartalmazó könyvtárat. A 15-16 sorban adtam, hogy a levelek melyik UID és GID számmal tárolódjanak. A 28-36. sorig azt állítottam be, hogy a Postfix képes legyen kiolvasni az LDAP-felhasználó alternatív email-címeit is. A beállítások értékei megegyeznek az előbbi szakasszal, mert ugyan abból az LDAP-adatbázisból olvassuk ki, mint az előbb. A /etc/postfix/main.cf 4 sorában megadott /etc/postfix/ldap-aliasescf fájl nézzük át egy kicsit: /etc/postfix/ldap-aliases.cf 1 2 server host = ldap.sztlkkhu search base = dc=sztlkk, dc=hu Ha van a rendszerben olyan felhasználó, akit úgy tárolunk a rendszerben (és a postafiókját is), mint ha „rendes” felhasználó lenne (csak éppen az LDAP-szerverből hitelesítjük), akkor ezt a fájlt meg kell adni a /etc/postfix/main.cf fájlban Két sorból áll, az elsőben megadjuk az LDAP-szerver címét, a másikban pedig

a kiindulási pontot. 4. Megvalósítás ismertetése 35 A Postfix programnak van egy másik beállító fájlja is, ami szintén módosításra szorul a rendszer (víruskeresés, SPAM szűrés) helyes működése érdekében. /etc/postfix/master.cf részlet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 smtp-amavis unix y 2 -o smtp data done timeout=1200 -o disable dns lookups=yes 127.001:10025 inet n n -o content filter= -o local recipient maps= -o relay recipient maps= -o smtpd restriction classes= -o smtpd client restrictions= -o smtpd helo restrictions= -o smtpd sender restrictions= -o smtpd recipient restrictions=permit mynetworks,reject -o mynetworks=127.000/8 -o strict rfc821 envelopes=yes smtp inet n y smtpd -o content filter=smtp-amavis:[127.001]:10024 smtp smtpd A látható 16. sort egyszerűen be kell illeszteni a mastercf fájlba A sorok részletes ismertetését itt most kihagyom, mert túllógna ezen szakdolgozat keretein. Röviden, ez a rész írja elő, hogy melyik

porton kell átadni a beérkező levelet az AMaViSd-new programnak, ami lefuttatja a víruskeresést, SPAM-szűrést, majd az melyik porton adja vissza az eredeti vagy a figyelmeztető (találat esetén) levelet. 4.29 AMaViSd-new A levelek víruskeresésében elengedhetetlen láncszem. Ez a program köti össze az MTA-t és a víruskeresőt, ezért ennek a jó beállítása szintén elengedhetetlen a vírusos levelek elfogásában. Nagyon sok víruskeresőt támogat, azonban én csak a ClamAV-t használom, mert ez az egy ingyenes1. /etc/amavis/amavisd.conf részlet 1 2 # @bypass virus checks acl = qw( . ); # @bypass spam checks acl = qw( . ); 3 $inet socket port = 10024; 4 5 6 7 $final virus destiny $final banned destiny $final spam destiny $final bad header destiny 8 $warnvirusrecip = 1 = = = = D DISCARD; D DISCARD; D DISCARD; D PASS; 1. Az F-Prot is ingyenes, de csak magán felhasználók számára, azonban a kollégium nem minősül annak 4. Megvalósítás

ismertetése 9 $sa local tests only = 0; 36 # (default: false) 10 11 12 13 14 15 16 $first infected stops scan = 1; @av scanners = ( [Clam Antivirus-clamd, &ask daemon, ["CONTSCAN {} ", "/var/run/clamav/clamd.ctl"], qr/OK$/, qr/FOUND$/, qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ], ); 17 18 19 20 21 @av scanners backup = ( [Clam Antivirus - clamscan, clamscan, "--stdout --no-summary -r --tempdir=$TEMPBASE {}", [0], [1], qr/^.*?: (?!Infected Archive)(.*) FOUND$/ ], ); Az első két sor „kikommentezett”, azaz nem érvényesül a beállításuk, azonban így jó. Azért mutatom be, mert az érvényesítésükkel lehet kikapcsolni a víruskeresést (1. sor) és a SPAM-szűrést (2. sor) Tehát azzal kapcsoljuk be ezt a két funkciót, hogy a két sort „kikommenteztük”. A 3 sorban határozhatjuk meg a használt socket portját, alapértelmezetten a 10024-es portot használja. Ha megváltoztatjuk, akkor figyeljük rá, hogy a Postfix

master.cf fájljában is írjuk át a portot, mert különben a Postfix nem tudja majd átadni a levelet az AMaViSd-new-nak. A 4-7 sorig terjedő beállításokban adhatjuk meg, hogy a beérkező vírusos, tiltott, SPAM vagy hibás fejlécű levelekkel mi történjen. Alapesetben a küldő értesítése van beállítva az első három esetben, a negyedikben pedig a továbbengedés. Azonban nem tartom jónak a feladó értesítését, mert a vírusos és a SPAM levelek terjedése már így is jelentős mértéket öltött, ezért a sok ilyen jellegű levelekre történő válaszlevél küldése csak tovább rontja a hálózatok áteresztő képességét. Ennek fényében, az ilyen jellegű leveleket eldobatom, csak a címzett felhasználó kap egy értesítést (8. sor) A 9 sorban azt állítottam be, hogy ne csak helyi tesztelésen essenek át a levelek, azaz, ha szükséges, akkor használja az internet-elérést a tesztelés során a SpamAssassin. Mint írtam már, az AmaViSd-new

több víruskeresőt is támogat egyszerre, amelyeket ha beállítottuk, akkor használ is, egymás után futtatja le őket a levélen. Azonban beállítható, hogy amint valamelyik kereső vírust talál, akkor fejeződjön be a keresés, ne futtassa le a sorban következő víruskeresőket. Én ezt bekapcsoltam a 10 sorban, bár nincs jelentősége, mert amúgy is csak egy víruskereső van beállítva. A 11-20 sorig pedig a ClamAV víruskereső használatának beállítása látható. 4.210 ClamAV A mai helyzetben szinte megengedhetetlen, hogy az ember gépén ne legyen víruskereső. A GNU/Linux rendszerekre szinte említésre sem méltó számú vírus, férget írtak, de azért 4. Megvalósítás ismertetése 37 akadnak. Azonban elsősorban a GNU/Linux rendszereken elhelyezett víruskeresők egyéb rendszerek védelmére szolgálnak, mert ha nem védenénk őket, akkor a sávszélesség pazarlása (vírusok terjedése) a tiszta rendszereket is hátrányosan érintené.

Ezért érdemes „tartani” egy jól beállított víruskeresőt a levélvírusok ellen is. /etc/clamav/clamd.conf részlet 1 2 3 4 5 6 7 8 9 10 User amavis ScanArchive ArchiveMaxRecursion 5 ArchiveMaxFiles 1000 ArchiveMaxFileSize 10M DatabaseDirectory /var/lib/clamav/ ScanOLE2 ScanPE DetectBrokenExecutables ScanHTML Az 1. sor egy nagyon fontos beállítást tartalmaz Mivel a ClamAV-t levelek ellenőrzésére használjuk, és az AMaViSd-new-t használjuk az MTA és a víruskereső összekapcsolására, így a víruskeresőnek is az AMaViSd-new felhasználójának nevében kell futnia, hogy hozzáférjen az átadott fájlokhoz. A 2 sorban beállítottam, hogy a csatolt archív fájlokban is keressen, amit 5 szintű mélységig hajt végre (3. sor) Összesen csak 1000 fájlt néz át egy levélben maximum (4. sor), és egy levél mérete nem haladhatja meg a 10MByte-ot (5 sor) A 6 sorban az vírusadatbázis könyvtárát adhatjuk meg. A 7 sorban megadtam, hogy a Microsoft Office

fájlokat is vizsgálja át (macro vírusok). A 8 sorban beállítottam a Portable Executable fájlok ellenőrzését, ez egy futtatható fájlformátum a 32-bites Windows rendszereken. A 9 sorban bekapcsoltam a hibás futtatható fájlok ellenőrzését. A 10 sorban pedig a HTML fájlok átvizsgálását írtam elő (JavaScript, VisualBasic script, stb.) Azonban mit érne egy jól beállított víruskeresési rendszer, ha a vírus-adatbázis nem naprakész. A ClamAV rendelkezik egy daemon programmal, amivel naprakészen tarthatjuk a víruskereső vírus-adatbázisát. /etc/clamav/freshclam.conf részlet 1 2 3 4 5 DatabaseOwner amavis Checks 24 DatabaseMirror db.huclamavnet DatabaseMirror database.clamavnet DatabaseDirectory /var/lib/clamav/ 4. Megvalósítás ismertetése 38 Itt is beállítjuk, hogy az amavis felhasználó nevében tevékenykedjen (1. sor) A 2 sorban a napi frissítések kezdeményezésének számát adtam meg. A 3 és 4 sorban azokat a szerver címeket adtam

meg, ahonnan frissítheti a vírus-adatbázist. Az 5 sorban pedig megadtam neki, hogy melyik könyvtárban található a vírus-adatbázis. 4.211 SpamAssassin A kéretlen levelek szűrésére a SpamAssassin programot használom, ami alapbeállításokkal is nagyon jól működik, de azért rendelkezik pár hasznos állítható opcióval: /etc/spamassassin/local.cf részlet 1 2 auto whitelist path rewrite subject 1 3 4 report safe 1 bayes path /var/lib/amavis/.spamassassin/bayes /etc/spamassassin/auto-whitelist A 1. sorban megadhatjuk a whitelist1 útvonalát A 2 sorban állíthatjuk be azt, hogy a SpamAssassin szükség esetén a tárgy sorában megjelölje a levelet, hogy SPAM. A 3 sorban beállítottam, hogy mindenképpen tegyen jelentést a levél fejlécében, ha nem SPAM, akkor is. Egy kis ideig figyelve a levelek tartalmát és az általuk elért pontszámot, biztosabban megállapítható az a pontérték, aminek elérése esetén a levél SPAM-nek minősüljön. Végül,

a 4. sorban a SPAM adatbázis tárolási könyvtárát adtam meg, ugyanis a sa-learn programmal lehet tanítani a SpamAssassin-t és a megtanult szabályokat az itt megadott könyvtárban tárolja. Érdemes egy pillantást vetni a SpamAssassin egy másik beállító fájljára is. Tipikus hiba szokott lenni, hogy ezt a fájlt nem módosítják: /etc/default/spamassassin részlet 1 2 enable=1 OPTIONS="-d -m 10 -a" Ugyanis, alapértelmezetten a SpamAssassin futása ki van kapcsolva. A futásának engedélyezését az 1. sorban látottak szerint lehet A 2 sorba megadhatunk pár opciót a futás mikéntjéhez. A „-d” jelentése, hogy daemon programként, a háttérben fusson A „-m 10” 1. Fehér-lista, az ezen szereplő email-címek automatikusan tiszta (clean) állapotúak, nem ellenőrzi őket 4. Megvalósítás ismertetése 39 jelentése, hogy egyszerre 10 gyerek-processzt hozhat létre. A „-a” opcióval pedig a auto-whitelists használatát engedélyeztem.

4.212 Courier Mail Server A levelek leszedéséhez (POP3) vagy megtekintéséhez (IMAP) is szükséges hitelesítés, ezért itt is be kell állítani az LDAP-szerver elérését: /etc/courier/authldaprc részlet 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 LDAP SERVER LDAP PORT LDAP BASEDN LDAP BINDDN LDAP BINDPW LDAP TIMEOUT LDAP AUTHBIND LDAP MAIL LDAP FILTER LDAP GLOB UID LDAP GLOB GID LDAP HOMEDIR LDAP MAILDIR LDAP FULLNAME LDAP CRYPTPW LDAP DEREF LDAP TLS ldap.sztlkkhu 389 dc=sztlkk,dc=hu cn=admin,dc=sztlkk,dc=hu {SSHA}I/58KBqXfByX6XW+9mAMxzLn3l5+95A7 15 1 uid (AccountStatus=active) vmail vmail mailMessageStore mailMessageStore cn userPassword never 0 Itt már részletezni sem kell a beállításokat, ugyan azokat kell beállítani, mint a többi szolgáltatásnál. 4.213 SquirrelMail Alapesetben is jól beállított webmail-t kapunk a telepítése után, azonban érdemes itt is belenyúlni kicsit a beállításokba: /etc/squirrelmail/config.php részlet 1 2 $squirrelmail

default language = hu HU; $default charset = iso-8859-2; Az fentebb látható két sorban megadtam, hogy magyar nyelvű felületet mutasson (1. sor), valamint helyesen jelenjenek meg az ékezetes karakterek (2. sor) 4. Megvalósítás ismertetése 40 4.214 Shaperd A különböző fájlmegosztós programok nagyban terhelik a sávszélességünket, ami amúgy sem túl nagy, így szükséges volt „beüzemelni” egy sávszélesség-korlátozó programot a fájlmegosztós1 programok lassítására2: /etc/shaperd/shaperd.conf 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 class BelsoIP-kifele { bandwidth = 25.0 kbyte/s ipv4 classifier saddr=192.168210/2552552550 queue limits = 0 kb 200 packets borrow from KulsoIP-kifele } class BelsoIP-befele { bandwidth = 100.0 kbyte/s ipv4 classifier daddr=192.168210/2552552550 queue limits = 0 kb 200 packets borrow from KulsoIP-befele } class KulsoIP-kifele { bandwidth = 25.0 kbyte/s ipv4 classifier

saddr=193.22515116/255255255240 queue limits = 0 kb 200 packets borrow from BelsoIP-kifele } class KulsoIP-befele { bandwidth = 100.0 kbyte/s ipv4 classifier daddr=193.22515116/255255255240 queue limits = 0 kb 200 packets borrow from BelsoIP-befele } Lehet látni, hogy mind kifelé mind befelé működik a korlátozás. Befelé 200kbyte/sec, kifelé 50kbyte/sec sebességet enged maximum. Mivel két IP-cím tartomány van, ezért kell ennyi bejegyzés, viszont a sávszélesség-korlátozás esetén „egy hálózatként” akartam kezelni ezeket, azért adtam meg az 5., 11, 17 és 23 sorban a „borrow from” opciót, amivel azt lehet jelezni, hogy melyik másik részből „vehet át” sávszélességet, ha ott éppen van „felesleges”, ki nem használt sávszélesség. 4.3 Szoftver beállítások kliens oldalon A szakdolgozatom témaköre a szerverek beállítása, azonban a munkám része volt a kabinet terem kiépítése és az ott elhelyezett számítógépek üzembe

helyezése is (Windows XP és Debian GNU/Linux operációs rendszerek telepítése, beállítása), ezért röviden leírom a két rendszer beállítását. 1. Direct Connect, Gnutella, WinMX, Kazaa, stb 2. Létezik iptables-hez egy p2p modul, ami képes detektálni ha egy csomag valamelyik fájlmegosztós programhoz tartozik, így ezeket a csomagokat át tudom adatni a sávszélesség-korlátozó programnak. 4. Megvalósítás ismertetése 4.31 41 Windows XP Két alapvető beállítást eszközölni kell, hogy egyáltalán szóba jöhessen a hálózatról történő felhasználó-hitelesítés. Először a biztonság fokozásának érdekében a ”Vezérlőpult / Felhasználói fiókok / A felhasználók be- és kijelentkezési módjának megváltoztatása” alatt kapcsoljuk ki ”Az üdvözlőképernyő használata” menüpontot, így nem lehet látni, hogy milyen felhasználók léteznek a rendszerben, minden felhasználónak be kell írnia a saját azonosítóját és

jelszavát, majd ki kell választania, hogy tartományba akar belépni, végül pedig kezdeményezni a bejelentkezési folyamatot az OK gomb lenyomásával. Ezután a rendszert be kell léptetni a megfelelő tartományba: ”Vezérlőpult / Rendszer / Számítógépnév / Módosítás” alatt váltsunk át a ”Munkacsoportról” ”Tartományra”, a tartomány neve pedig legyen: KABINET (lásd fentebb: ”/etc/samba/smb.conf részlet: a [global] rész” 3. sora) A tartományba lépéshez meg kell adni a root felhasználót1 és jelszavát. A sikeres hitelesítést követően a felhasználó saját profil könyvtárát át kell tölteni a fájl-szerverről az operációs rendszernek. Ezt a Windows XP automatikusan megteszi, azonban pár beállított alapértéket meg kell változtatni: A regedit programmal eszközölt változások: / Sajátgép / HKEY LOCAL MACHINE / SYSTEM / CurrentControlSet / Services / Netlogon / Parameters / • "RequireSignOrSeal"=dword:00000000

• "SignSecureChannel"=dword:00000000 A gpedit.msc programmal eszközölt változások: / Számítógép konfigurációja / Felügyeleti sablonok / Rendszer / Felhasználói profilok / • Központi profilok gyorsítótárba helyezett példányainak törlése: E N G E D É LY E Z V E • Felhasználó kiléptetése, ha hiányoznak a központi profilok: E N G E D É LY E Z V E • A központi profilban végzett módosításoknak a kiszolgálóhoz való továbbításának megakadályozása: T I LT VA 1. Arról a root felhasználóról van szó, amelyiket a ”root felhasználó hozzáadása az LDAP-adatbázishoz” résznél hoztunk létre. 4. Megvalósítás ismertetése 42 Az említett változtatások után újraindítjuk az operációs rendszert és máris elérhetővé válik a hálózatról történő felhasználó-azonosítás. 4.32 Debian GNU/Linux A névszolgáltatás alrendszer konfigurálása Az NSS (Name Service Subsystem) feladata elvégezni a

felhasználói nevek és az uidNumber egymáshoz rendelését, ezért rakjuk fel ezt a csomagot és állítsuk is be: 1 apt-get install libnss-ldap Nyissuk meg a /etc/nsswitch.conf fájlt, és módosítsunk néhány sort, hogy az NSS a lokális fájlokban, majd az LDAP-ban keresse meg a leképezéshez szükséges információt: /etc/nsswitch.conf részlet 1 2 3 passwd: group: shadow: files ldap files ldap files ldap Ezután az imént feltelepített lib számára adjuk meg az LDAP szerverünk elérhetőségét: /etc/libnss-ldap.conf részlet 1 2 host ldap.sztlkkhu base dc=sztlkk,dc=hu A hitelesítés beállítása A PAM (Pluggable Authenticaion Module) célja az, hogy az egyes hitelesítést végző modulok könnyen cserélhetőek legyenek egy szoftver alatt, és ne okozzon nagy problémát pl. az, ha lokális hitelesítésről át szeretnénk térni LDAP hitelesítésre. A Debian a Potato óta PAM-ot használ. A hitelesítéshez fel kell tenni az LDAP-os PAM csomagot: 1

apt-get install libpam-ldap 4. Megvalósítás ismertetése 43 Majd a konfigurációja során meg kell adni az LDAP szerver elérhetőségét. Ha minden jól megy, akkor a fájlhoz nem kell hozzányúlni, mert a csomag telepítése során feltett kérdésekre válaszolva a megfelelő fájl legenerálódik: /etc/pam ldap.conf részlet 1 2 3 4 host ldap.sztlkkhu base dc=sztlkk,dc=hu rootbinddn cn=admin,dc=sztlkk,dc=hu pam password crypt Minden szolgáltatás (service, program), ami használ PAM-ot külön konfigurációs fájllal rendelkezik a /etc/pam.d könyvtárban Minden egyes szolgáltatást külön be kell konfigurálni arra az estre, ha szeretnénk, hogy az a szolgáltatás használja az LDAP szervert a hitelesítéshez. A login szolgáltatás beállítása: /etc/pam.d/login részlet 1 2 3 auth auth auth sufficient sufficient required pam unix.so nullok pam ldap.so use first pass pam deny.so 4 5 account account sufficient sufficient pam unix.so pam ldap.so 6 7

password password sufficient sufficient pam unix.so nullok obscure min=4 max=8 md5 pam ldap.so A passwd szolgáltatás beállítása: /etc/pam.d/passwd részlet 1 2 password password sufficient sufficient pam unix.so nullok obscure min=4 max=8 md5 pam ldap.so Mivel a feladat minden más szolgáltatás (többek között például: ssh, sudo, kdm, stb.) esetében is ugyan, ezért nem részletezem tovább. 4. Megvalósítás ismertetése 44 Name Server Caching Daemon Azért, hogy ne kelljen minden egyes „ls -l” parancs kiadásakor az LDAP szerverhez fordulni, telepíthetjük az nscd nevű programot, amely pontosan ezeknek az információknak a cache-elését végzi el. Telepítése a következő paranccsal történik: 1 apt-get install nscd 4.4 Honlap használata, működési folyamatai Több funkciót is megvalósít a honlap, ezért most leírom a főbb funkciók működését, a megvalósított folyamat során történő eseményeket. 4.41 Szobai

Internet-elérés igénylés Egyik legfontosabb része a honlapnak. Nagy áttörést jelentett az ezelőtti időszakhoz képest Sikerült pénzforrást teremteni a HP switch-re, így minden szobát be tudtam kötni a hálózatba. Azonban ez nem lett volna még elég a teljes automatizálás eléréséhez. Lehetővé kellett tenni, hogy mindenki a saját szobájából tudjon IP-címet igényelni. Amikor az Internet-elérést igénylő lakó először ráköti a számítógépét a számítógépes hálózatra, akkor kap egy IP-címet a 192.1681000/24-es hálózatból (2 és 254 között véletlenszerűen). Ezzel az IP-címmel nem tud mást elérni, csak az IT honlapját (http://it.sztlkkhu) A honlapon kitölti a „szobai internet” igénylése menüpontban az űrlapot és az IT szabályzatának ide vonatkozó részének elfogadásával megtörténik a Internet-elérés igénylésének leadása. A rendszer két percenként ellenőrzi az igényléseket1, ha még fel nem dolgozott

igénylést talál, akkor az új igénylő és adatai bekerülnek a MySQL- és az LDAP-adatbázisban. Ha még nem járt le a türelmi idő (lásd: következő bekezdés), akkor egyúttal létrejönnek a DNS, DHCP és IPTables beállítófájlok. A megfelelő helyre eljuttatott2 beállítófájlok és az adott szolgáltatások újraindítása után azonnal elérhetővé válik az igénylő számára az Internet. A türelmi idő az adott félév első napjától az adott félév második hónapjának 15. napjáig tart A türelmi időszak alatt be kell fizetni az Internet-elérés használati díjának ellenértékét az IT 1. Ezért is van beállítva a DHCP-kiszolgálón, hogy a 1921681000/24-es hálózatban a lejárati idő alapesetben egy perc, de maximum két perc. 2. Az SSH programcsomagban található scp program használom erre A bejelentkezéshez használandó jelszó kikerülését már leírtam a „Jelszó nélküli felhasználó-azonosítás kulcsok segítségével SSH

esetén” fejezetben. 4. Megvalósítás ismertetése 45 számlájára és bemutatni valamelyik IT tagnak, aki bejegyzi a honlapon. Ugyanis az internet feleves tilto perl szkript lefut a türelmi időszak lejárta után és letiltja azokat a felhasználókat, akik nem fizették be a használati díjat. Akik a türelmi idő lejárta után igényelnek Internet-elérést, azok az igénylés leadása után bekerülnek ugyan az adatbázisba, de még nem tudnak internetezni. Ha befizetik és a befizetésről szóló csekket be is mutatják valamelyik IT tagnak, akkor a csekk bemutatásának bejegyzése és a felhasználó engedélyezése után ezen felhasználók Internet-elérése is engedélyezetté válik. Az igénylés során meg kell adni többek között egy felhasználói nevet és egy jelszót, ami kell a nyomtatáshoz, a kabinet teremben a gépekre történő bejelentkezéshez, egyszóval mindenhez amihez a hitelesítés az LDAP-adatbázisból történik meg, valamint az IT

honlapra. Ezen felül meg kell adni a számítógép MAC-címét1 és a kívánt DNS-nevet. 4.42 Kabinetes Internet-elérés igénylés A kabinetes Internet-elérés igénylésének esetén is ugyanazok a szabályok érvényesek, mint szobai Internet-elérés igénylésekor, csak itt nem kell megadni MAC-címet és DNS-nevet. Ebben az esetben a lakó nem tud a szobájából internetezni, csak a kabinet teremben levő számítógépeket használhatja, amire bejelentkezni csak az igényléskor megadott felhasználói nevet és jelszavat használva tud. A számítógépre történő bejelentkezés után használhatja a feltelepített programokat (szövegszerkesztő, táblázatkezelő, képszerkesztő, zenelejátszó, stb.), internetezhet, nyomtathat. 4.43 Nyomtatás a HÖK-ös nyomtatóval A nyomtatáshoz azonosítanunk kell magunkat. A kabinet gépek esetén az operációs rendszerbe történő bejelentkezés alkalmával megtörténik a hitelesítés. Ezután bármelyik programban

csak rá kell nyomni a nyomtatás ikonra, ennek hatására a nyomtatandó dokumentum átkerül a Samba-szerverre, ahol a nyomtatas szkript megnézi, hogy hány oldal a nyomtatandó dokumentum. Az átvizsgálás után a lapszám és az árértéke bekerül a MySQL-adatbázisba, majd elkezdődik a nyomtatás. A nyomtatási folyamat a „441 Ábra: Nyomtatási folyamat” ábrán látható: 1. Segítségképpen a honlap az igénylési oldalon előre kitölti a MAC-címet, amit a háttérben az oldal saját maga távolról megtudakol az igénylő számítógépétől. 4. Megvalósítás ismertetése 46 elküldése nyomtatandó Felhasználó gépe i ent h t au nyomtatás SAMBA ada t ok ió kác elm LDAP ent ése MySQL nyomtató 4.41 Ábra: Nyomtatási folyamat 4.5 Perl szkriptek A weben keresztül vezérelhető felügyeleti rendszer lelkét adják ezek a szkriptek: előállítják az IT honlapját, karbantartják a MySQL- és LDAP-adatbázist, vezérlik a másik

kettő szervert, elvégzik a nyomtatást, stb. A továbbiakban ezeket a szkripteket1 mutatom be it.cgi sorok száma: 4118 A IT weblapját előállító perl szkript. Az egész rendszer magját képezi, ő irányítja a folyamatokat, futtatja le a külső szkripteket, kezeli a felhasználókat és az adatbázisokat. Sok függvényt hoztam létre benne, de csak a fontosabbakat mutatom be funkciójuk szerint: 1. Több mint 5000 sor együttvéve az összes szkript, így a forráskódokat csak CD-n mellékeltem 4. Megvalósítás ismertetése 47 it.cgi::Admin jelszovalto sorok száma: 341 Kezdetben tényleges csak az admin felhasználók1 jelszavának megváltoztatására volt. Azonban a honlap fejlődése közben ide került be az „A rendszer finomhangolása” menüpont is, amiben a rendszert lehet átállítani: például a türelmi időszak vagy a nyomtatási költségek megváltoztatása, stb. it.cgi::Felhasznalo bekijelentkezes sorok száma: 98 Az rendszerbe felvett

felhasználók a weboldalra is be tudnak jelentkezni, meg tudják nézni saját adataikat (IP-cím, nyomtatási költség, stb.) A bejelentkezési folyamatot végzi el ez a függvény. it.cgi::Felhasznalo informaciosoldal sorok száma: 444 A felhasználó a weboldalra bejelentkezve, megnézheti a rendszerben tárol adatait: domain név, IP-cím, MAC-cím, nyomtatott oldalak száma és költsége, stb. Ezen felül lehetősége van megváltoztatni a jelszavát, valamint a MAC-címét. A MAC-cím megváltoztatásának lehetőségét azért tartottam fontosak, mert ha vesz valamelyik felhasználó új hálózati kártyát, akkor ne kelljen engem megkeresnie. Habár nem kap internetezésre használható IP-címet, azonban az IT weblapját eléri. Oda bejelentkezve, képes megváltoztatni a rendszerben tárolt MAC-címét. A megváltoztatása után, újra megkapja az internetezésre is használható IP-címét és újra tud internetezni. A MAC-cím újbóli megváltoztatása csak 30 nap

múlva lehetséges, de mint minden mást is, a weblap admin felhasználói megváltoztathatják ezt a beállítást „A rendszer finomhangolása” menüpontban. it.cgi::Felhasznalo felvetele sorok száma: 587 Négyféle felhasználó felviteli oldal van a weboldalon: szobai és kabinetes Internet-elérés igénylés, valamint az weboldal admin felhasználója is fel tudja venni mind a kétféle felhasználót. Célszerű volt egy függvénnyel megcsinálni A függvény kezeli a MySQL táblákat, az LDAP-adatbázist, valamint létrehozza a postafiókot „szobai” felhasználó felvétele 1. A weboldal admin felhasználói, akik az oldalra bejelentkezve felvehetnek, törölhetnek, engedélyezhetnek, tilthatnak felhasználókat, módosíthatják a rendszer beállításait, stb. 4. Megvalósítás ismertetése 48 esetén. Ha még tart a türelmi idő, akkor létre hozatja a DHCP, a DNS és tűzfal konfigurációs fájlokat, valamint érvényesítteti is őket.

it.cgi::Felhasznalo csekkfizetese sorok száma: 84 A türelmi idő végére be kell fizetni az igényelt Internet-elérés ellenértékét. Ha be is mutatják a csekket valamelyik IT tagnak, akkor az bejegyzik az adott felhasználóhoz, hogy befizette az internet-csekket. Tiltásra kerül az összes olyan felhasználó, aki nem fizet a türelmi idő végéig it.cgi::Felhasznalo engedelyezese sorok száma: 107 Letiltott felhasználó engedélyezésére szolgál. Egy felhasználó több miatt is kaphat tiltást: nem mutatta be a befizetett internet-csekket, az Internet használatára vonatkozó IT szabályzatot nem tartotta be, vagy vírusos lett a gépe és a megadott határidőre nem tisztította meg. A felhasználó engedélyezése után (LDAP) létrehozza a DHCP, a DNS és tűzfal konfigurációs fájlokat, valamint érvényesíti őket. it.cgi::Felhasznalo tiltasa sorok száma: 116 Felhasználó tiltására használatos, ami történhet automatikusan vagy manuálisan. Az előző

függvénynél említettem, hogy miért kaphat egy felhasználó tiltást. Ha a türelmi idő alatt nem mutatja be a felhasználó a befizetett internet-csekket, akkor a rendszer automatikusan tiltja a türelmi idő lejárata után. A tiltás folyamán újragenerálja a DHCP, a DNS és tűzfal konfigurációs fájlokat, valamint érvényesíti őket. it.cgi::Felhasznalo torlese sorok száma: 116 Az oldalon külön lehet törölni szobai és kabinetes felhasználót is. Célszerű volt ezért erre is készíteni egy külön függvényt. A kabinetes felhasználókat csak a MySQL-adatbázisból kell eltávolítani. A szobai Internet-elérést igénylők esetén nem csak a MySQL-adatbázisból kell törölni, hanem a felhasználókat törölni kell az LDAP-adatbázisból, valamint törölni kell a fájljaikat a mail-szerverről is. Ezek után létrehozza a DHCP, a DNS és tűzfal konfigurációs fájlokat, valamint érvényesíti őket. 4. Megvalósítás ismertetése 49

it.cgi::Adatbazislekerdezes sorok száma: 241 Az oldalon többször is szükség van arra, hogy olvassunk a MySQL-adatbázisból (például: felhasználók, nyomtatási lista, kabinetes gépek foglaltsági listájának lekérdezése, stb.) Ezért készítettem egy függvényt, amit megfelelően felparaméterezve, visszaadja a kívánt értékeket a kívánt táblázatból. szabalyok ervenyesitese sorok száma: 28 Két percenként fut le ez a szkript és megnézik, hogy érkezett-e kérés, hogy valamelyik szolgáltatás (DHCP, DNS, tűzfal) újra be kell állítani. Ilyen kérés lehet: szobai Internet-elérés igénylése, szobai felhasználó hozzáadása vagy eltávolítása, esetleg a MAC-cím 1 megváltoztatása. Szükség esetén meghívja a megfelelő szolgáltatás beállításáért felelős szkriptet. szabalyok dhcp sorok száma: 84 A DHCP-kiszolgáló beállítófájlját állítja elő, juttatja át a WOTAN szerverre és indítja újra a szolgáltatást. A

szobai felhasználók, a szerver- és a kabinetgépek adataiból dolgozik szabalyok dns sorok száma: 163 A DNS-kiszolgáló zónafájljait állítja elő, juttatja át a WOTAN szerverre és indítja újra a szolgáltatást. A szobai felhasználók, a szerver- és a kabinetgépek adataiból dolgozik szabalyok tuzfal sorok száma: 147 Az iptables beállítófájlját állítja elő, juttatja át a ZEUS szerverre és érvényesíti a fájlban szereplő szabályokat. A szobai felhasználók, a szerver- és a kabinetgépek adataiból dolgozik 1. Több megoldást is számításba vettem a kérések feldolgozásához A döntésemet a „ Végkövetkeztetés” alfejezetben indoklom. 4. Megvalósítás ismertetése 50 kabinetgepekfoglaltsaga sorok száma: 102 Az Internet-elérés igénylésekor meg kell adni egy felhasználónevet és egy jelszót. Ezzel a név/jelszó párossal be lehet jelentkezni a kabinet teremben lévő számítógépekre. A bejelentkezéskor az adott géphez

bejegyzésre kerül az adott felhasználó neve és a bejelentkezés időpontja, így bármikor meg lehet nézni az IT honlapján, hogy van-e üres gép a kabinet teremben. Kijelentkezéskor pedig a szkript beállítja a „szabad” jelzést a gépre a MySQL-adatbázisban. Ezen felül egy listába is bekerül az adott gép használati ideje nyomtatas sorok száma: 167 A hálózaton keresztüli nyomtatáskor a Samba fogadja a nyomtatandó fájlt, sikeres hitelesítés esetén meghívja a Samba ezt a szkriptet és átadja neki, hogy melyik fájlt nyomtassa ki. A szkript átkonvertálja a PostScript fájlt a Ghostscript (gs) segítségével a nyomtató által is érthető formátumra, közben pedig megszámolja az oldalak számát és kiszámítja a nyomtatási költséget. A nyomtatási adatokat hozzáadja a felhasználó már meglévő adataihoz, amik a MySQL-adatbázisban tárolódnak, valamint a nyomtatásokról is készíttetek egy listát, így visszamenőleg bármikor

megtekinthető, hogy ki mikor mennyit nyomtatott. nyomtatas havi nullazas sorok száma: 45 Minden hónap első napján nulla óra nulla perckor fut le. Feladata, hogy jelentést küldjön email-ben azokról a felhasználókról, akik az előző hónapban több mint 500 Ft értékben nyomtattak, és nullázza a havi nyomtatási adataikat (lapszám, költség) a MySQL-adatbázisban – természetesen a június, az augusztus és szeptember hónap kivétel. Az utolsó kettő magától értetendő, mivel ilyenkor csak vendégek tartózkodhatnak a kollégiumban, azonban az első magyarázatra szorulhat. Már június hónapban elkezdődnek a kiköltözések, így ebben a hónapban már csak azonnal fizetendő kézpénzért szabad nyomtatni, ezért ez feleslegessé teszi a július hónap elején történő jelentést. Azonban, ha valaki mégis nyomtatna és kiköltözéskor valamiért kimaradna ennek az ellenőrzése, akkor is legyen nyoma, beszedhető legyen a nyár vagy a következő

félév folyamán a nyomtatás ellenérték. Június elején esedékes jelentésküldés azért marad el, mert – mint említettem már – június folyamán már csak kézpénzes nyomtatás van, így bárkinek bármennyire kevés is van a számláján, mindenképpen jelentést kell küldeni és a nyomtatási adatait nullázni kell a MySQL-adatbázisban. Erről külön szkript gondoskodik 4. Megvalósítás ismertetése 51 nyomtatas feleves sorok száma: 44 Június elején már nem kell nézni, hogy ki mennyi nyomtatási díjjal tartozik, mindenképpen jelenteni kell email-ben és le kell nullázni a nyomtatási adatokat. A két szkriptet összevonva, írhattam volna egybe is és paraméterezéssel elérhetném a két különböző funkciót. Próbáltam minden funkciót külön fájlba elhelyezni, hogy a fájl neve alapján látható legyen a funkciója, ne kelljen paraméterezni. Tettem ezt azért, mert nem tudom, hogy milyen utódom lesz a kollégiumban rendszergazdai

pozícióban. internet feleves tilto sorok száma: 45 Lefuttatásakor megnézi a dátumot, ha elmúlt a türelmi idő, akkor minden olyan felhasználót tiltólistára tesz, aki nem fizette be az „internet-csekket”, vagy befizette, de még nem mutatta be valamelyik IT tagnak és így nem történt meg a csekk bemutatásáról szóló bejegyzés a nevéhez a MySQL táblázatban. Ezután újrageneráltatja a DHCP, DNS és tűzfal beállító fájlokat és újraindíttatja a szolgáltatásokat, így megszűnik azoknak a felhasználónak az Internet-elérése, akik nem fizettek még. A legegyszerűbb e szkript futását beautomatizálni a cron programmal, amit egyébként az it.cgi meg is tesz az Admin jelszovalto függvényében. urites felhasznalok sorok száma: 82 A felhasználók eltávolítását végzi el. Meghívásának hatására a felhasználók eltávolításra kerülnek a MySQL- és az LDAP-adatbázisból, valamit a WOTAN szerverről is törlődik a postafiókja. 5.

Tervezői döntések összefoglalása 52 5. Tervezői döntések összefoglalása Bármilyen rendszert is rakjunk össze, szinte elkerülhetetlen, hogy a végén ne végezzünk róla elemzést. Többféle készíthető, ám én most inkább csak az alternatív lehetőségeket veszem sorra, valamint levonom a végkövetkeztetést a kialakított rendszerrel kapcsolatban. 5.1 Kivitelezés elemzése, lehetséges alternatív megoldások bemutatása Az esetek döntő többségében egy feladatot különböző módszerekkel, más-más programok felhasználásával is megoldhatjuk, elvégezhetjük. Az elvégzendő feladattól függ, hogy melyik megoldást választjuk, de persze a döntést szubjektív indokok is befolyásolhatják. A szakdolgozatom létrehozása során történt nagyobb döntéseket járom körül és indokolom meg. 5.11 Exim, Postfix, Qmail vagy Sendmail? A Debian GNU/Linux disztribúcióban az alapértelmezett MTA az Exim. A Debian volt az első GNU/Linux rendszer

amivel megismerkedtem és nem is váltottam az évek alatt. Ezáltal az Exim volt az az MTA, amivel megismerkedtem és használtam. Sokáig kielégítette a kívánalmaimat, azonban amikor eljött az az időszak, amikor egyre több szerver raktam össze és telepítettem. Ekkor merült fel benne a gondolat, hogy érdemes lenne váltani, ekkor tanácsolták a Postfix programot. Az ismerkedést hamar „barátság” váltotta fel, bármilyen megoldás könnyen beállítható, nagyon jól együttműködik sok más programmal és jó teljesítményt lehet vele elérni gyengébb processzoron is. Azonban az vitathatatlan, hogy a Qmail ilyen téren verhetetlen és nem csak GNU/Linux rendszeren tarják a leggyorsabb, legfürgébb MTA-nak. Viszont számomra a Postfix még nem okozott csalódást, nem éreztem még, hogy váltanom kellene róla, így nem próbáltam még ki a Qmail-t. A Sendmail az az MTA, ami megosztja a közösséget, lehet szeretni, lehet utálni, de közömbösnek lenni

nehéz. A régi nagy öreg MTA A hosszú évek alatt nagyon sok funkciót implementáltak bele és ennek köszönhetően a beállítófájlját sikerült teljesen elbonyolítani. Egy sokat látott linux-os rendszergazda is megvakarja a fejét, amikor meglátja. Nagyon sok lehetőség rejlik benne, de sajnálatos módon, az új funkciók megírása közben nem fordítottak kellő figyelmet a biztonságra és ennek köszönhetően jelentősen lecsökkent a „piaci részesedése” az MTA-k között. 5. Tervezői döntések összefoglalása 53 Ha az ember kellő figyelemmel és odafigyeléssel dolgozik, akkor mindegyik MTA-val meg tudja valósítani amit szeretne, azonban én a Postfix-et választottam, mert elkötelezték magukat az ide vonatkozó RFC-k teljes betartása és a tiszta, átlátható forráskód mellett, valamint fontos szempont a kompatibilitás más MTA-kal. 5.12 Perl vagy PHP? Számos internetes kommunikációs csatornán folytak/folynak eszmecserék a

témában. Igazából nem lehet megmondani, hogy melyik is a jobb. Mind a Perl-ben, mind a PHP-ban vannak jó dolgok. Mindkettőnek megvannak az előnyei és hátrányai is A PHP-be, magába a nyelvbe sok mindent beleintegráltak, verzióról verzióra, míg a Perl nyelv kevesebbet változik, és a flexibilitást úgy éri el, hogy külső modulok valósítják meg a legtöbb hasznos funkciót. Ugyanakkor vannak dolgok amiben a PHP nem teljesen átgondolt és nem teljesen logikus. Ez érthető is, hiszen a Perl 1988-ban született, a PHP meg 1996-tól létezik, de előbb utóbb kinövi a gyermekbetegségeit. Összességeben mindkét nyelvnek megvannak az előnyei és hátrányai Érdemes mindkét nyelvet megismerni, és mindig azt a nyelvet használni, amelyik megfelelőbb az elvégzendő feladatra. Az általam létrehozott rendszerben több perl-szkript is helyett kapott a CGI mellett, többek között ezért is döntöttem a Perl mellett. 5.13 Mi az SNMP? Az SNMP a Simple Network

Management Protocol (Egyszerű hálózatfelügyeleti protokoll). A protokoll alapjainak a leírását az FRC 1155-1158 és az RFC 1213-as dokumentumok tartalmazzák. Az SNMP lényegében egy a hálózatfelügyelet alapjait magába foglaló hálózati kommunikációs meghatározás-gyűjtemény. A hálózati környezet karbantartását, megfigyelését teszi lehetővé. Miért nem használtam SNMP-t? IP-címhez párosított MAC-cím szűrés van a tűzfalon (iptables), így csak azokat a gépeket engedi ki, amik a megfelelő IP- és MAC-címmel bírnak. A megoldás előnye, hogy bárki átköltözhet másik szobába, vagy csak ideiglenesen átviheti a gépét másik szobába, akkor is megkapja a gépe a neki járó IP-címet és a tűzfal is kiengedi. A kollégium laptop számítógépét hálózati karbantartásra, analízisre szoktam használni, amit bármelyik szobában üzembe helyezve, megkapja az IP-címét és már lehet is dolgozni rajta. 5. Tervezői döntések

összefoglalása 54 A megoldás hátránya, hogy a MAC-cím könnyen megmásítható, így a rendszer könnyen kijátszható. Más nevében lehet tevékenykedni Ezért előnyös lenne, ha a switch minden portjához hozzárendelne a rendszer egy MAC-címet, plusz az olyan eszközöket, amelyeket hordozgatunk, legyen az laptop vagy egy USB-s BlueTooth eszköz. Az ilyen eszközök vásárlása nem szokott sűrűn történni, így még kivitelezhető is lenne, azonban sajnos nem mindegyik aktív eszközünk menedzselhető, ezért az egyenlő elbírálás nevében az SNMP-vezérlést elvetettem. 5.14 MySQL vagy PostgreSQL? Az RDBMS (relational database management system), azaz relációs adatbázis kezelőtől elvárható tulajdonságok: • Automatizáció Pl. Ha egy tranzakció során a backup művelet és az update között telne be a háttértár, akkor az update-t kell elvetni. • Konzisztencia Pl. Ha kapcsolt táblák közül az egyikből törlünk egy rekordot, ne maradjanak

"árva" rekordok az alárendelt táblában. • Elszigetelés Pl. Egy tranzakció mindaddig legyen láthatatlan más tranzakciók számára, amíg az teljesen be nem fejeződött. • Tartósság Pl. a tranzakciók menet közben is tárolva legyenek, tehát ha valamiért elszáll a rendszer, akkor is "emlékezzen", hogy folyamatban volt egy tranzakció. MySQL • Nincsen tranzakciókezelés! A MySQL sebességre optimalizált, de ezzel veszélyezteti a konzisztenciát. • sokkal kevesebb függvényt és funkciót képes értelmezni, mint bármely más adatbáziskezelő rendszer • csak tábla szintű lock-olás van • Ben Adida a Massachusetts Műszaki Egyetem Phd hallgatója szerint a MySQL csak egy feldicsőített fájlrendszer, nem pedig adatbázis-kezelő 5. Tervezői döntések összefoglalása 55 PostgreSQL • nem olyan gyors, mint a MySQL, de képes tranzakciókezelésre, rekordlock-olásra • több hasznos függvénnyel és

beállítási lehetőséggel rendelkezik • triggerelt lekérdezések is végrehajthatóak • ANSI SQL 92 típusok és funkciók • hosszú azonosító nevek A PostgreSQL-t inkább a professzionális felhasználásokhoz készítették és komoly, nagy szerverekhez is kiváló Oracle, vagy MsSQL helyett. A MySQL is egyre jobb, de otthoni és web-es alkalmazásokhoz javasolt inkább. Kis adatbázisoknál "egyszerűbbségéből" adódóan gyorsabb. Az adatok mennyisége és felhasználása alapján a választásom a MySQL programra esett, mert csak egyszerű (select, insert, update, delete, stb.) műveleteket kell végrehajtani az adatbázis-táblákon, és ilyen műveletek esetén a MySQL kiemelkedően gyorsan dolgozik. 5.2 Végkövetkeztetés A lassan fél éve napi 24 órában működő rendszer beindítása – leszámítva egy-két kisebb hibát – zökkenőmentesen sikerült. Óvatosan kellett dolgoznom és tesztelnem, mert ez előző rendszert nem volt

szabad leállítanom, teljesen észrevétlenül kellett felépítenem az új rendszert. Teljes tesztelésre nem volt lehetőségem, mert az év végén a vizsgaidőszakban nem kockáztathattam, hogy egy esetleges programhiba miatt leálljon a teljes internet-elérés. Nyáron pedig festés volt több szinten, többek között a szerverszobában is, ezért ezt az időszakot sem használhattam fel tesztelésre. Nem maradt más hátra, mint az augusztus utolsó napjaiban elkezdődött beköltözési időszak. Az átgondolt fejlesztésnek és az egyes alrészek alapos tesztelésének köszönhetően az éles tesztelésen jól vizsgázott a rendszer és az első napon az összes apró hiba is eltávolításra került. A kérések feldolgozására kialakított két percenkénti feldolgozási megoldás is jól vizsgázott. Könnyen kialakítható lett volna, hogy egy igénylés leadásakor azonnal elinduljon a feldolgozási procedúra – persze zárolással megoldva, hogy egyszerre csak egy

feldolgozás fusson – azonban a beköltözési időszakban ez folytonos szolgáltatás-újraindítást eredményezett volna. Ezt a folytonosságot próbáltam megszakítani a két – kezdetben öt – perces várási ciklussal. 5. Tervezői döntések összefoglalása 56 Összefoglalva, a kialakított három számítógépes szerver-farm jól tűri a megpróbáltatásokat. Weben keresztül a felhasználók saját magunknak igényelhetnek Internet-elérést. Ezentúl csak a következő feladatokat kell ellátni weben keresztül: Internet-eléréshez befizetett csekkek bejegyzése a felhasználóhoz, esetleges letiltott felhasználó engedélyezése, felhasználó letiltása, ha okot adott rá, valamint a kiköltözött felhasználó eltávolítása a rendszerből. Sajnos redundáns szerver-farm kialakítására nem volt lehetőségem, így az it mentes szkripttel végrehajtott mentés az egyetlen beiktatott biztonsági megoldás, de a felhasználásával így is könnyen

visszaállítható a szerverek állapota egy kis Debian GNU/Linux telepítési ismerettel. Irodalomjegyzék [1] http://portal.fsnhu/modulesphp?name=News&file=article&sid=4524 [2] http://pcforum.hu/hirek/?qnid=1400 [3] Pere László - LINUX felhasználó ismeretek I (2002) [4] Jónás Zsolt - GNU/Linux kezelési ismeretek II (2004) [5] http://www.bellevuelinuxorg/vi/historyhtml [6] http://www.vmunixcom/vim/histhtml [7] Michael McMillan - Perl 1 (1998) [8] http://fikusz.hu/kurzusok/html [9] Marcel Gagné - LINUX rendszerfelügyelet (2002) [10] Pere László - LINUX felhasználó ismeretek II (2002)