Útmutató az informatikai biztonság megvalósítására önkormányzatok számára

Útmutató az informatikai biztonság megvalósítására önkormányzatok számára

Készült az Informatikai és Hírközlési Minisztérium megbízásából

Standard-Média Bt.

2006. március

Az útmutató elkészítésében részt vettek Szigeti Szabolcs (szerk) Krasznay Csaba Kremser Csaba (grafika) Muha Lajos Rigó Ernő További közreműködők: Kincses Zoltán Dr. Szigeti Marcell

Köszönetünket fejezzük ki az Informatikai és Hírközlési Minisztérium munkatársainak, Németh J. Andrásnak és Sikolya Zsoltnak az útmutató elkészítésében nyújtott értékes segítségükért.

Dok id: Verzió: Kibocsátva: Szerkesztő:

IHM-2005-ITSEC-1 1.0 Rev: d 2006. március 15. Szigeti Szabolcs

Tartalom 1 2

Vezetői összefoglaló........................................................................................ - 1 Bevezetés ........................................................................................................ - 3 2.1 A dokumentum célja ............................................................................... - 3 2.2 A dokumentum célközönsége ................................................................. - 3 2.3 A dokumentum szerkezete ..................................................................... - 4 3 Információbiztonság – informatikai biztonság ............................................. - 5 3.1 Védelmi intézkedések ............................................................................. - 5 3.2 Informatikai biztonság ........................................................................... - 7 3.3 Követelmények a közigazgatás számára ............................................... - 8 4 Biztonság megvalósítása ............................................................................. - 10 4.1 Alapvető elvek....................................................................................... - 10 4.2 Helyzetfelmérés .................................................................................... - 11 4.3 Kockázatelemzés................................................................................... - 12 4.4 Védelmi intézkedések ........................................................................... - 14 4.5 Szabályzatok ......................................................................................... - 15 4.6 Az emberi tényező................................................................................. - 16 4.6.1 Jelszavak........................................................................................ - 17 4.6.2 Adathalászat .................................................................................. - 17 4.7 Jellegzetes informatikai architektúrák és rendszerek önkormányzatoknál......................................................................................... - 20 4.8 Rendszerek beállításai.......................................................................... - 22 4.8.1 Windows ......................................................................................... - 22 4.8.1.1 Biztonsági beállítások ............................................................ - 23 4.8.2 Linux .............................................................................................. - 39 4.8.2.1 A Linux egy Windows-felhasználó szemével ......................... - 39 4.8.2.2 A Linux rendszer főbb komponensei...................................... - 47 4.8.2.3 Általános felhasználási tanácsok a Linux rendszerhez ........ - 48 4.8.2.4 A Linux rendszerek alapvető beállításai ............................... - 49 4.8.2.5 A Linux hálózati tűzfala......................................................... - 53 4.8.2.6 Csomagkezelés........................................................................ - 56 4.8.2.7 Hálózati kiszolgálók beállításai ............................................. - 59 4.8.2.8 Honnan tudhatom, hogy feltörték? ........................................ - 63 4.8.3 Tűzfalak ......................................................................................... - 65 4.8.3.1 A tűzfalak típusai ................................................................... - 65 4.8.3.2 Jellegzetes tűzfal architektúrák ............................................ - 65 4.8.3.3 Címfordítás ............................................................................. - 66 4.8.3.4 VPN ......................................................................................... - 67 4.8.3.5 Tipikus tűzfal beállítások....................................................... - 67 4.8.4 Kártékony kódok............................................................................ - 67 4.8.5 Levelezés ........................................................................................ - 69 4.9 Titkosítás............................................................................................... - 70 4.10 Vezetéknélküli hálózatok ..................................................................... - 72 4.10.1 Fogalmak........................................................................................ - 73 4.10.2 Veszélyek........................................................................................ - 73 4.10.3 Biztonsági megoldások .................................................................. - 73 4.10.4 Lényeges tennivalók ...................................................................... - 74 -

I

4.10.5 Példa a beállításokra ..................................................................... - 76 4.10.5.1 Access Point beállítása ........................................................... - 76 4.10.5.2 Kliensek beállítása ................................................................. - 79 4.10.6 Bluetooth biztonság ....................................................................... - 82 4.11 Hordozható eszközök ............................................................................ - 83 5 Üzemeltetés.................................................................................................. - 85 5.1 Mentés ................................................................................................... - 85 5.2 Frissítések ............................................................................................. - 85 5.3 Selejtezés............................................................................................... - 86 5.4 Vészhelyzetek........................................................................................ - 86 5.4.1 További károk megelőzése............................................................. - 86 5.4.2 Hasonló esetek megelőzése ........................................................... - 86 5.4.3 Normál üzem visszaállítása .......................................................... - 86 5.4.4 Nyomozás ....................................................................................... - 87 6 A szabályozási környezet által támasztott igények.................................... - 88 6.1 Jogszabályok ......................................................................................... - 88 6.2 Szabványok és ajánlások ...................................................................... - 88 7 Az önkormányzati környezet specialitásai ................................................. - 93 8 Az elektronikus aláírás................................................................................ - 95 9 Szótár.......................................................................................................... - 109 10 Jogszabályok........................................................................................... - 112 10.1 A területhez kapcsolódó egyéb jogszabályok ..................................... - 112 10.2 A KIETB ajánlásai.............................................................................. - 113 11 Hivatkozások .......................................................................................... - 114 11.1 Általános IT biztonság........................................................................ - 114 11.2 Jogszabályi háttér............................................................................... - 114 11.3 Windows .............................................................................................. - 114 11.4 Linux ................................................................................................... - 114 11.5 Vezetéknélküli biztonság.................................................................... - 115 11.6 Elektronikus aláírás ........................................................................... - 115 11.7 Ábrák jegyzéke.................................................................................... - 115 -

II

Informatikai biztonság

1

Vezetői összefoglaló


Az informatika mindent átszövő fejlődésével az informatikai biztonság az utóbbi évek egyik legfontosabb szakterületévé vált. Számos eset bizonyítja, hogy a biztonság hiánya súlyos anyagi és erkölcsi károkhoz vezet. Nincs ez másként a közigazgatás területén sem, ahol éppen napjainkban alakulnak ki az elektronikus ügyintézés folyamatai, amelyek esetében magyarázat sem szükséges, hogy mennyire kiemelt fontosságú az információ és az informatikai biztonság megvalósítása. Az informatikai biztonság különleges helyzetben van, mert egyszerre van jelen az informatika minden területén, sőt, helyes kialakítása és működtetése jóval túlmutat a pusztán informatikai eszközökön. Ezért az informatikai biztonság nem képzelhető el „termékként”, amelyet megvásárolunk majd beüzemelünk. Az informatikai biztonságot a környezetre szabva kell kialakítani, megvalósítani és működtetni. Mindez azonban koránt sem ördöngösség, annak ellenére, hogy természetesen a mögötte álló elméleti és gyakorlati szakismeretek komoly tudományágat alkotnak. Ugyanakkor az informatikai biztonság problémás terület, hiszen megléte nem látható, nem érzékelhető. Mindig a biztonság hiánya az, amelyet gyakran saját bőrünkön is tapasztalhatunk. Ennek eredményeként gyakran csak akkor történnek lépések, ha már késő, mivel sokan felesleges befektetésnek érzik a biztonság irányába tett lépéseket. A dokumentum elsődleges célja, hogy segítséget nyújtson az informatikai biztonság megfelelő szintjének kialakításához önkormányzati környezetben, figyelembe véve az informatikai biztonság területének jelenlegi helyzetét és a vonatkozó jogszabályi környezetet, elsősorban a 2004. évi CXL. törvényt a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól és annak végrehajtási rendeleteit. Ezek és más korábbi szabályozások jól definiálják a biztonság számára kitűzött célokat, követelményeket és követendő eljárásokat. Az informatika rohamléptékű fejlődéséből adódó részleteket azonban nem tudják és nem is feladatuk követni a jogszabályoknak. Így ezek megismétlése nélkül szükség van olyan közérthető információkra, amelyek „szakácskönyv” szerűen próbálnak útmutatást adni ezen a területen. Jelen dokumentum gyakorlati jellegű, így megpróbálja elkerülni a túl „hivatalos” és formalizált nyelvezetet és módszereket, ehelyett a praktikus információkra koncentrál. Természetesen ezek is köteteket megtöltő mennyiségű információk, amelyek ismételt leírására sem lehetőség, sem szükség nincsen. Ehelyett megpróbálunk az informatikai biztonság kialakításának teljes folyamatába betekintést nyújtani gyakorlatias nézőpontból, úgy, hogy az érdeklődők megismervén ezeket a lépéseket, képesek legyenek önállóan is elmélyedni bennük, ha a szükség úgy hozza. A dokumentum célközönsége kettős. Egyrészt szól minden önkormányzati környezetben dolgozónak, akik akár munkakörüknél fogva, akár a természetes érdeklődésből kifolyólag érdeklődnek az informatikai biztonság iránt. Elsősorban számukra ajánljuk a 3. és a 4.1-4.6, 6., 7. és 8. fejezeteket. Másrészről szól a

-1-



rendszerek beállításával, üzemeltetésével foglalkozó személyeknek, részükre az előbbieken kívül a 4.8.-4.11. és az 5. fejezet tartalmaz konkrét információkat a rendszerek beállításáról. A dokumentum különös tekintettel szól a kisebb informatikai infrastruktúrával rendelkező önkormányzatok ezen infrastruktúráért felelős személyeinek. Különösen javasolt az anyag azon önkormányzatok számára, ahol a szervezet méreténél fogva nem áll rendelkezésre külön emberi és egyéb erőforrás az informatikai rendszerek biztonságának kialakítására és üzemeltetésére, hanem ezt „házon belül” kell megoldani. Az első rész az informatikai biztonság alapvető fogalmaival és a kialakítás lépésivel foglakozik. Bemutatja a védelmi intézkedések kockázatelemzésen alapuló kialakítását. Ennek során nem alkalmaz szigorúan formalizált módszertant, sokkal inkább egyfajta sorvezetőt kíván adni a biztonság megtervezéséhez, amely segíti a feladatok szisztematikus végigvitelét: Egy rendszer, egy szervezet biztonságának kialakítása nem egyszeri lépés. A biztonság nem állapot, hanem folyamat. Ennek megfelelően a biztonság kialakítása több lépésben történik. A lényeges lépések a következők: •

Helyzetfelmérés: ennek során meghatározzuk és osztályozzuk a védendő információkat, erőforrásokat, veszélyeket és fenyegetettségeket.

•

Kockázatelemzés: a helyzetelemzés alapján fenyegetettségek által képviselt kockázatokat.

•

Védelmi intézkedések kidolgozása: a kockázatokat kezelni kell, ezért meghatározzuk a kockázatok kezelésére (csökkentéséhez, elkerüléséhez, elviseléshez) szükséges intézkedéseket.

•

A védelmi intézkedéseket implementáljuk és működtetjük. Ennek során folyamatosan figyelemmel kísérjük és helyesbítjük biztonsági rendszerünket.

meghatározzuk

a

A második rész gyakorlati jellegű információkat ad, amelyek gerincét a két népszerű platform a Windows és a Linux adja. Kitér egyéb, elsősorban informatikai technikákra, mint a tűzfalak vagy a vezetéknélküli hálózatok. Az itt közölt tanácsok, beállítások elsősorban az általános, irodai jellegű környezetről szólnak, nagyméretű komplex rendszerek biztonságának kialakítása túl mutat a kereteken és feltétlenül szakértői közreműködést igényel. A harmadik rész a szabályozási környezetet és az elektronikus ügyintézést mutatja be, valamint ezekhez kapcsolódóan gyakorlati példákon keresztül ismerteti az elektronikus aláírás technológiáját és folyamatát.

-2-


2

Bevezetés

Bevezetés

Az informatika mindent átszövő fejlődésével az informatikai biztonság az utóbbi évek egyik legfontosabb szakterületévé vált. Számos eset bizonyítja, hogy a biztonság hiánya súlyos anyagi és erkölcsi károkhoz vezet. Nincs ez másként a közigazgatás területén sem, ahol éppen napjainkban alakulnak ki az elektronikus ügyintézés folyamatai, amelyek esetében magyarázat sem szükséges, hogy mennyire kiemelt fontosságú az információ és az informatikai biztonság megvalósítása. Az informatikai biztonság különleges helyzetben van, mert egyszerre van jelen az informatika minden területén, sőt, helyes kialakítása és működtetése jóval túlmutat a pusztán informatikai eszközökön. Ezért az informatikai biztonság nem képzelhető el „termékként”, amelyet megvásárolunk majd beüzemelünk. Az informatikai biztonságot a környezetre szabva kell kialakítani, megvalósítani és működtetni. Mindez azonban koránt sem ördöngösség, annak ellenére, hogy természetesen a mögötte álló elméleti és gyakorlati szakismeretek komoly tudományágat alkotnak. Ugyanakkor az informatikai biztonság problémás terület, hiszen megléte nem látható, nem érzékelhető. Mindig a biztonság hiánya az, amelyet gyakran saját bőrünkön is tapasztalhatunk. Ennek eredményeként gyakran csak akkor történnek lépések, ha már késő, mivel sokan felesleges befektetésnek érzik a biztonság irányába tett lépéseket. Az informatikai biztonság sok apró tényezőből tevődik össze, azonban néhány alapelvet szem előtt tartva és néhány egyszerű, gyakorlati lépést megtéve rendszereink biztonsága nagyságrendeket javítható.

2.1 A dokumentum célja A dokumentum elsődleges célja, hogy segítséget nyújtson az informatikai biztonság megfelelő szintjének kialakításához önkormányzati környezetben, figyelembe véve az informatikai biztonság területének jelenlegi helyzetét és a vonatkozó jogszabályi környezetet, elsősorban a 2004. évi CXL. törvényt a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól (Ket.) és annak végrehajtási rendeleteit. Ezek és más korábbi szabályozások jól definiálják a biztonság számára kitűzött célokat, követelményeket és követendő eljárásokat. Az informatika rohamléptékű fejlődéséből adódó részleteket azonban nem tudják és nem is feladatuk követni a jogszabályoknak. Így ezek megismétlése nélkül szükség van olyan közérthető információkra, amelyek „szakácskönyv” szerűen próbálnak útmutatást adni ezen a területen. Jelen dokumentum gyakorlati jellegű, így megpróbálja elkerülni a túl „hivatalos” és formalizált nyelvezetet és módszereket, ehelyett a praktikus információkra koncentrál. Természetesen ezek is köteteket megtöltő mennyiségűek, amelyek ismételt leírására sem lehetőség, sem szükség nincsen. Így megpróbálunk az informatikai biztonság kialakításának teljes folyamatába betekintést nyújtani gyakorlatias nézőpontból, úgy, hogy az érdeklődők megismervén ezeket a

-3-


Bevezetés

lépéseket, képesek legyenek önállóan is elmélyedni bennük, ha a szükség úgy hozza. Az útmutató a gyakorlati lépéseken túl körüljárja a szabályozási környezetet és az elektronikus ügyintézéssel kapcsolatos lépéseket is, ezzel kialakítva a gyakorlati útmutatások környezetét. Az anyag elkészítése során elsősorban a jelenlegi szakmai gyakorlatra támaszkodtunk, valamint felhasználtuk a szabályozási környezet egyes dokumentumait és az Informatikai és Hírközlési Minisztérium által adott anyagokat és információkat.

2.2 A dokumentum célközönsége A dokumentum célközönsége kettős. Egyrészt szól minden önkormányzati környezetben dolgozónak, akik akár munkakörüknél fogva, akár a természetes érdeklődésből kifolyólag érdeklődnek az informatikai biztonság iránt. Elsősorban számukra ajánljuk a 3. és a 4.1-4.6, 6., 7. és 8. fejezeteket. Másrészről szól a rendszerek beállításával, üzemeltetésével foglalkozó személyeknek, részükre az előbbieken kívül a 4.8.-4.11. és az 5. fejezet tartalmaz konkrét információkat a rendszerek beállításáról. A dokumentum különös tekintettel szól a kisebb informatikai infrastruktúrával rendelkező önkormányzatok ezen infrastruktúráért felelős személyeinek. Különösen javasolt az anyag azon önkormányzatok számára, ahol a szervezet méreténél fogva nem áll rendelkezésre külön emberi és egyéb erőforrás az informatikai rendszerek biztonságának kialakítására és üzemeltetésére, hanem ezt „házon belül” kell megoldani.

2.3 A dokumentum szerkezete A dokumentum három fő részre tagolódik. •

Az első rész az informatikai biztonság alapvető fogalmaival és a kialakítás lépésivel foglakozik. Bemutatja a védelmi intézkedések kockázatelemzésen alapuló kialakítását. Ennek során nem alkalmaz szigorúan formalizált módszertant, sokkal inkább egyfajta sorvezetőt kíván adni a biztonság megtervezéséhez, amely segíti a feladatok szisztematikus végigvitelét.

•

A második rész gyakorlati jellegű információkat ad, amelyek gerincét a két népszerű platform a Windows és a Linux adja. Kitér egyéb, elsősorban informatikai technikákra, mint a tűzfalak vagy a vezetéknélküli hálózatok. Az itt közölt tanácsok, beállítások elsősorban az általános, irodai jellegű környezetről szólnak, nagyméretű komplex rendszerek biztonságának kialakítása túl mutat a kereteken és feltétlenül szakértői közreműködést igényel.

•

A harmadik rész a szabályozási környezetet és az elektronikus ügyintézést mutatja be, valamint ezekhez kapcsolódóan gyakorlati példákon keresztül ismerteti az elektronikus aláírás technológiáját és folyamatát.

-4-


3

Információbiztonság – informatikai biztonság


Az információ jelentős értéket képvisel. Különösen igaz ez napjainkban, amikor az informatikai rendszerek hatalmas mennyiségű információt kezelnek, tárolnak és állítanak elő. A bennük áramló információ titkossága, sértetlensége és elérhetősége létfontosságú. Figyelembe véve az ekormányzati, e-közigazgatási rendszerek és szolgáltatások robbanásszerű fejlődését, belátható, hogy az ezekben kezelt információ védelme, azok jellegénél kiemelten kezelendő.

3.1 Védelmi intézkedések Látható, hogy az információ biztonsága és az informatikai biztonság különböző, de egymással szorosan összefüggő fogalom. Az információbiztonság az információ megjelenési formájától függetlenül foglalkozik annak biztonságával. Az információ biztonság nem csak és nem elsősorban informatikai kérdés. Erre a területre tartozik a titkos ügyiratkezeléstől kezdve a tűzvédelemig nagyon sok szabályozás és szakma. Az ezeken alapuló védelmi intézkedések egyik részhalmaza az informatikai rendszerekre vonatkozó intézkedések. Az informatikai biztonság ezzel szemben kifejezetten az informatikai rendszerekben kezelt információ biztonságával foglalkozik. A szokásos definíció szerint informatikai biztonság a védelmi rendszer olyan, a szervezet számára kielégítő mértékű állapota, amely az informatikai rendszerekben kezelt adatok bizalmassága, sértetlensége és rendelkezésre állása szempontjából zárt, teljes körű, folytonos és a kockázatokkal arányos. A védelmi intézkedésekre jellemző, hogy: •

teljes körűek, azaz a rendszer összes elemére kiterjednek,

•

zártak, azaz minden fenyegetést figyelembe vesznek

•

folytonosak, azaz a változó körülmények és követelmények mellett is megszakítás nélkül megvalósulnak.

Jelen dokumentum az informatikai biztonsággal foglalkozik, azonban nem szabad elfelejteni, hogy annak ellenére, hogy „informatikáról” beszélünk, a védelmi intézkedéseknek csak egy része jelent közvetlen informatikai

-5-



tevékenységet, vagy eszközt. Az informatikai biztonsági védelmi intézkedéseket több kategóriába sorolhatjuk1: •

Menedzsment biztonsági intézkedések: olyan intézkedések, amelyek a kockázatok és az informatikai rendszerek biztonságának menedzselésére koncentrálnak. Ide tartoznak: o Kockázatfelmérés, azaz a közigazgatási hatóságnak időnként fel kell mérnie a szervezet működése során felmerülő kockázatokat és az ezek által fenyegetett értékeket. o Tervezés, azaz a kockázatfelmérés alapján tervet kell készíteni, amely leírja a szükséges védelmi intézkedéseket és szabályozásokat. o Rendszer és szolgáltatás beszerzés, azaz a tervezés során előállt terv megvalósítása, amelynek során a szervezet erőforrásokat biztosít a terv megvalósítására és megvalósítja azokat. o Biztonság értékelés és akkreditálás, azaz a terv alapján létrehozott intézkedéseket folyamatosan működtetni és felügyelni kell, hatékonyságukat mérni kell és tervet kell készíteni az esetleg szükséges korrekciókra.

•

Üzemeltetési biztonsági intézkedések: olyan intézkedések, melyeket elsősorban emberek valósítanak meg, hajtanak végre. Ide tartoznak: o Fizikai és környezeti védelem, azaz a védeni kell az informatikai infrastruktúrát és kapcsolódó környezetét a fizikai hozzáféréstől. Biztosítani kell, hogy csak az arra jogosultak férjenek hozzá a rendszerekhez. o Személyzettel kapcsolatos biztonság, azaz biztosítani kell, hogy az informatikai rendszerrel kapcsolatba kerülő személyek megfeleljenek az adott pozícióra vonatkozó biztonsági feltételekre, hogy a biztonság folyamatosan fent legyen tartva a személyek változása esetén is. A biztonsági intézkedéseket be nem tartó személyek ellen szankciókat kell alkalmazni. o Tudatosság és képzés, azaz biztosítani kell, hogy az informatikai rendszerrel kapcsolatban álló személyek tudatában legyenek a tevékenységeikkel kapcsolatos biztonsági kockázatokkal, ismerje a jogszabályi, szabályozási és védelmi hátteret, előírásokat. A személyzet a munkakörének megfelelő képzésben részesüljön az informatikai biztonság területén. o Konfigurációkezelés, azaz ki kell alakítani és folyamatosan karban kell tartani az informatikai rendszer leltárát és alapkonfigurációját.

1

Az Informatikai és Hírközlési Minisztérium ajánlása a közigazgatás biztonsági osztályokba

sorolt informatikai célrendszereire vonatkozó biztonsági intézkedésekre c. tervezet alapján.

-6-



Ki kell alakítani a biztonságot megvalósító konfigurációkat, beállításokat, és folyamatosan ellenőrizni, nyomon követni kell ezek változását. o Üzletmenet-folytonosság tervezése, azaz a közigazgatási hatóságnak terveket kell készítenie, karbantartania és megvalósítania a rendkívüli helyzetekre való reagálásra, a mentési műveletekre és a katasztrófák utáni helyreállításra, annak biztosítása érdekében, hogy a kritikus információs erőforrások rendelkezésre álljanak és rendkívüli helyzetekben is megvalósuljon a folyamatos működés. o Karbantartás, azaz intézkedéseket kell hozni és működtetni annak érdekében, hogy az informatikai rendszerek időszakos és rendszerek karbantartása megvalósuljon, és figyelembe vegye a biztonsági követelményeket.

•

o Adathordozók védelme, azaz a szervezetnek meg kell valósítania az adathordozók illetve az azokon tárolt, szállított adatok védelmét, különös tekintettel a hozzáférési jogosultságokra és az adatok megsemmisítésére. Műszaki biztonsági intézkedések: olyan intézkedések, melyeket elsősorban az informatikai rendszer valósít meg, hajt végre, a rendszer hardver, szoftver összetevőiben megvalósuló mechanizmusok segítségével. Ide tartoznak: o Azonosítás és hitelesítés, azaz a közigazgatási hatóságnak azonosítani kell az informatikai rendszer felhasználóját és hitelesíteni kell azonosságukat, mielőtt hozzáférést engedélyez. o Hozzáférés ellenőrzés, azaz a hozzáférést az arra jogosultakra kell korlátozni. o Naplózás és elszámoltathatóság, azaz biztosítani kell, hogy az informatikai rendszer eseményeiről megfelelő naplózás szülessen, és ezek a naplóbejegyzések a szükséges ideig meg legyenek őrizve. Biztosítani kell, hogy – összhangban a vonatkozó jogszabályokkal – az egyes felhasználói tevékenységek nyomon követhetőek legyenek, a felhasználói felelősség megállapíthatóságára. o Rendszer és információ sértetlenség, azaz a szervezetnek azonosítania, jelentenie és javítania kell az informatikai rendszer hibáit, védekeznie kell a kártékony kódok (vírus, féreg) bejutása ellen és figyelemmel kell kísérnie, a rendszer biztonsági riasztásait. o Rendszer és kommunikáció védelem, azaz monitorozni, ellenőrizni és védeni kell a szervezetből kilépő és az oda belépő információkat. o Reagálás a biztonsági eseményekre, azaz a közigazgatási hatóságnak úgy kell kialakítania rendszerét, hogy lehetővé tegye az észlelését, elemzését, reagálást a biztonsági eseményekre.

-7-



Egyes módszertanok más felosztását alkalmazzák az intézkedéseknek, érdemes ezeket is áttekinteni, mivel más nézőpontból csoportosítja – ugyanezeket – a védelmi intézkedéseket: •

Fizikai védelmi intézkedések. Az informatikai eszközök fizikai védelmét megvalósító intézkedések. Ezek inkább tartoznak a hagyományos biztonságtechnikai területre, de ide tartozik például az elektronikus kisugárzás elleni védelem is.

•

Algoritmikus védelmi intézkedések. Gyakran ezeket az intézkedéseket értik szűk értelemben „informatikai biztonság” alatt, mivel ide tartoznak a titkosítási, vírusvédelmi, hálózati forgalom szűrési stb. intézkedései, vagyis mindazok, amelyek az informatika eszközeivel (algoritmusokkal) megoldható.

•

Adminisztratív intézkedések. Minden olyan intézkedés, amely előírások, szabályzatok formájában jelentkezik, és azok betartását elsősorban szankcionálással éri el. Ezek az intézkedések kicsit a másik kettő fölött helyezkednek el, mivel céljuk többek között az összes védelmi intézkedés egységbe foglalása is (biztonsági politika, stb.)

3.2 Informatikai biztonság Mindezek után tekintsük át, hogy mit takar az informatikai biztonság! Az egyik leggyakrabban használt definíciója szerint a rendszer által kezelt információ biztonsága három pilléren nyugszik: •

Bizalmasság (Confidentiality): az információhoz csak az arra feljogosítottak férhetnek hozzá. Ez a gyakorlatban azt jelenti, hogy biztosítani kell, hogy illetéktelenek vagy ne férhessenek hozzá az adathoz, vagy az adatok olyan formában – pl. titkosítva – legyenek hozzáférhetőek, hogy azt csak az arra jogosultak (személyek, rendszerek) tudják értelmezni.

•

Sértetlenség (Integrity): az információt csak az arra feljogosítottak módosíthatják. Más szóval ez azt jelenti, hogy az adat mindig olyan állapotban legyen, ahogy az utolsó, módosításra jogosult hagyta. Gyakorlatban meg kell akadályozni a módosítás jellegű hozzáféréseket, illetve megfelelő módszerekkel biztosítani kell a jogosulatlan (vagy véletlen, pl. műszaki hibából eredő) módosítások felismerését. A sértetlenség körébe tartozik a letagadhatatlanság (nonrepudiation), az elszámoltathatóság (accountability) és a hitelesség (authenticity). Letagadhatatlanság alatt azt értjük, hogy az információ – jogosult – módosítója vagy előállítója ne tudja letagadni ezt a cselekedetet. Ez nyilvánvalóan alapvető fontosságú például az elektronikus úton indított közigazgatási eljárások, stb. esetében. Az elszámoltathatóság annak biztosítása, hogy az információval kapcsolatos műveletek végrehajtója később azonosítható legyen. Ez többek között megfelelő naplózással biztosítható. A hitelesség a sértetlenség bizonyíthatósága. Ennek tipikus eszköze az elektronikus aláírás.

-8-


•


Elérhetőség (Availability): az információ rendelkezésre áll az arra feljogosítottak számára. Gyakorlatban biztosítani kell, hogy a rendszer, amely az adatot szolgáltatja működőképes legyen, ne lehessen támadással megbénítani, műszaki hiba esetén sem semmisüljenek meg az adatok és az információ értelmezhető formában álljon rendelkezésre.

Ezt a hármast szokás az angol rövidítések alapján CIA elvnek nevezni2. Az informatikai biztonság kialakítása során a cél ezen három feltétel megvalósítása és meglétüknek folyamatos fenntartása. Fontos tudni, hogy az informatikai biztonság által megvalósított célok nem abszolút célok, és csak valamilyen igényszintnek megfelelően értelmezhetőek. Nyilvánvaló például, hogy másként kell értelmezni és biztosítani a rendelkezésre állást és házi számítógép és egy elektronikus piactér esetében. Az önkormányzati környezet esetében számos jogszabály és előírás határozza meg a biztonság igényszintjét, és a megvalósítás során elérendő célokat.

3.3 Követelmények a közigazgatás számára A Ket. által megkövetelt informatikai biztonsági környezetet a 195/2005 (IX. 22.) Kormány rendelet az elektronikus ügyintézést lehetővé tevő informatikai rendszerek biztonságáról, együttműködési képességéről és egységes használatáról definiálja. A rendeletben foglaltak megfelelnek az általános informatikai biztonsági alapelveknek és céloknak, azonban ezeket pontosítják a környezetre vonatkozó kötelező érvényű előírásokkal. A rendelet több alapvető megállapítást tesz, amely igen lényeges a biztonság szempontjából: •

Minőségirányítási rendszerrel kell rendelkezni, amely magában foglalja a biztonsági követelményeket (6. §), és ezt megfelelő dokumentációs rendszerrel támasztja alá (8. §). Mindez hangsúlyozza a biztonság folyamatszerű megközelítését, amely a helyesen kialakított célrendszerre, megfelelően elvégzett tervezésre és kivitelezésre valamint a folyamatos üzemeltetésre épül. A 4.1-4.6 fejezet ismerteti az ennek során végrehajtandó lépéseket és elkészítendő dokumentumokat.

•

A 9. § ismerteti a kockázatelemzés fontosságát. Kiemelendő a 9. § (1), amely kimondja, hogy „A hatóság az informatikai célrendszer informatikai

biztonsági kockázatait legalább kétévenként felméri, és gondoskodik az informatikai célrendszer kockázatokkal arányos védelméről a tervezés, a beszerzés, az előállítás, az üzemeltetés és a felülvizsgálat területén.” Azaz előírja, hogy a biztonsági rendszert periódikusan felül kell vizsgálni, reagálni kell a változó környezet által támasztott igényekre. A kétévenkénti felülvizsgálatot célszerű sűríteni, ha jelentős változás áll be A 4.2-4.3 fejezet bemutatja a helyzetfelmérés és a kockázatelemzés

2

Bár biztonság területe miatt kétségtelen az áthallás a USA hírszerző hivatalának elnevezésével,

a CIA elv elnevezés elterjedt mind a külföldi, mind a hazai szakirodalomban.

-9-



folyamatát. A 10. § felhívja a figyelmet a biztonsági osztályba sorolásra, amely a helyzetelemzés-kockázatelemzés része. •

A 12. § az informatikai rendszerek kiszervezéséről szól és tükrözi azt az elvet, hogy az informatikai biztonság során a teljeskörűségre kell törekedni, azaz a saját rendszerünk biztonságát befolyásolja minden ezzel kapcsolatban lévő más rendszer. Kiszervezés esetén legfontosabb az átláthatóság, azaz a kiszervezett rendszerbe olyan szintű rálátással kell rendelkeznünk, hogy megbizonyosodhassunk a biztonsági szempontból helyes megvalósításról illetve befolyásunk lehessen ebből a szempontból. (12. § (1)). A 13. § hasonló megállapításokat tesz az adatvédelem szempontjából.

A rendelet biztonsági követelményeket állapít meg a 14. §-ban meghatározott (gyak. a csak elektronikusan folytatható ügyek) területekre: •

Ügyfél azonosításával kapcsolatos követelmények (15. §). Az ügyfél azonosításnak meg kell akadályozni a későbbi megszemélyesítést és meg kell akadályozni az elektronikus aláírással ellátott űrlapok újrafelhasználását (visszajátszását). Az elektronikus aláírás kérdéseivel a 8. fejezet foglalkozik.

•

A naplózással kapcsolatos követelmények (16. §). A naplózásnak különös tekintettel ki kell térnie az ügykezelés minden lépésére, olyan szinten, hogy az ügykezelés minden mozzanata rekonstruálható legyen. A naplóállományokat megfelelő módon védeni kell. A naplózás megvalósítása elsősorban az adott alkalmazás feladata, de a követelményrendszerben ezt specifikálni kell.

•

A rendelkezésre állással kapcsolatos követelmények (17. §). Ki kell dolgozni és biztosítani kell a rendszerek megfelelő szintű üzemeltetését illetve helyreállítási tervét. Az üzemeltetéssel foglalkozik az 5. fejezet.

•

A mentéssel és archiválással kapcsolatos követelmények (18. §, 19. §). A mentésnek biztosítani kell az ügyekhez kapcsolódó dokumentumok megőrzését, helyreállíthatóságát és hitelességének megőrzését. A mentési és üzeltmenet-folytonossági terv kialakítása során ezekre ki kell térni. A üzemeltetésről a 5. fejezet, az egyes rendszerekhez kötődő alapvető mentési beállításokról a 4.8. fejezet szól.

•

A vírusok és más támadások elleni védelem követelményei. A rendszerek védelmét biztosítani kell a kártékony kódok és a támadások ellen. A 4.8 fejezet szól az alapvető beállításokról és lehetőségekről ezen a területen.

•

Az adattárolással (12. §) és adattovábbítással (22. §) kapcsolatos követelmények. A vizsgált környezetben elsősorban az adatvédelemmel kapcsolatos feladatok jelentkeznek az általános biztonsági követelmények felett. Az adattovábbítás biztonságában lényeges szerepet játszó tűzfalakról a 4.8.3, a titkosításról a 4.9, a vezetéknélküli hálózatok biztonságáról a 4.10. és az elektronikus aláírásról a 8 fejezet szól.

•

A hozzáférés és a fizikai biztonság követelményei (23. §, 24. §). A hozzáférés során minden félnek azonosíthatónak kell lennie, különös - 10 -



tekintettel az ügyintézésben részt vevő felekre. Az általános biztonsági alapelveknek megfelelően a rendszerekhez való fizikai hozzáférés biztonságát meg kell oldani. •

Az informatikai rendszer kezelésével kapcsolatos követelmények (25. §). Az informatikai rendszerben alkalmazott elemek csak szabályozott körülmények között vehetőek használatba. Ezzel kapcsolatban a 4.11 és 5.3 fejezet szól.

Természetesen a rendelet nem tér és nem is térhet ki a konkrét beállításokra és megvalósításokra, mivel ezek mindig az adott alkalmazástól és helyzettől függenek. Azonban a biztonsági előírások és politika kialakítása során a fentieket figyelembe kell venni és alkalmazni kell.

- 11 -


4

Biztonság megvalósítása


Egy rendszer, egy szervezet biztonságának kialakítása nem egyszeri lépés. A biztonság nem állapot, hanem folyamat. Ennek megfelelően a biztonság kialakítása több lépésben történik. A lényeges lépések a következők: 1. A rendszer leírása, helyzetfelmérés: meghatározzuk a vizsgált rendszer határait, környezetét, az érintett információs és egyéb erőforrásokat, figyelembe véve a rendszer komponenseit, a tárolt, feldolgozott, előállított és továbbított információt, ezek sérülékenységeit, kritikusságát és érzékenységét. 2. A veszélyek meghatározása: a veszély a sebezhetőség kihasználása valamely veszélyforrás által. A lépés során meghatározzuk és felsoroljuk a vizsgált rendszer veszélyforrásait. 3. A sebezhetőségek elemzése, kockázatelemzés: a sebezhetőségeket elemzzük a kihasználhatóság valószínűsége és a kihasználás esetén fellépő hatás súlyossága alapján. 4. Az intézkedések elemzése: megvizsgáljuk a biztonsági intézkedéseket hatékonyságuk és az általuk esetleg indukált más sérülékenységek szempontjából. 5. A valószínűségek meghatározása: a sebezhetőségek kihasználhatóságának valószínűségét osztályokba soroljuk: alacsony, közepes, magas. A vizsgálat során figyelembe vesszük a sebezhetőség jellegét, a veszélyforrás képességeit és motivációját, a meglevő biztonsági intézkedéseket. 6. Hatáselemzés: a sebezhetőségek kihasználásának káros hatásait vizsgáljuk a CIA elv alapján. A hatást alacsony, fokozott és kiemelt osztályokba sorolhatjuk. 7. Kockázat meghatározása: a kihasználhatóság valószínűsége és a hatás alapján meghatározzuk a kockázatot. 8. Biztonsági intézkedések megtervezése: azon menedzsment, üzemeltetési és műszaki biztonsági intézkedések meghozása, amelyek elfogadható szintre csökkentik rendszer kockázati szintjét. 9. Dokumentálás: a folyamat eredményét dokumentálni kell. A védelmi intézkedéseket megvalósítjuk és működtetjük. Ennek során folyamatosan figyelemmel kísérjük és helyesbítjük biztonsági rendszerünket. A következőkben egy egyszerű módszertant mutatunk be ezeknek a lépéseknek végrehajtására. Az itt bemutatott lépések nem szigorúan formalizáltak, sokkal inkább segítséget nyújtanak abban, hogy a biztonság megtervezése és megvalósítása során szisztematikusan tudjuk végigvinni a tervezést, ne kerülje el semmi a figyelmünket.

4.1 Alapvető elvek Nagyon fontos tisztában lenni a biztonság kialakítása során elérendő célokkal. Néhány lényeges pont, amelyet szem előtt kell tartani: - 12 -



•

Ismerd meg magad és ellenséged! Az biztonságot csak úgy lehet kellő szinten kialakítani, ha tisztában vagyunk saját környezetünkkel, rendszerünkkel, igényeinkkel és hasonló rálátással rendelkezünk a fenyegető veszélyekkel. A pontos helyzetfelmérés nélkül csak vaktában hozhatunk intézkedéseket.

•

A biztonság kompromisszumok kérdése. A biztonság kialakítása során fel kell tennünk a következő kérdéseket: Milyen biztonsági problémát kívánunk megoldani, milyen veszélyeket akarunk csökkenteni? A választott megoldások mennyire szolgálják a megoldást? Milyen új biztonsági problémákat vet fel a megoldás? Figyelembe véve a megoldás költségét (nem csak a pénzben kifejezhetőeket) és a megoldás által generált újabb problémákat, érdemes-e ezt a megoldást választani? Látszik, hogy sosem egy jó és egy nem jó megoldás között kell dönteni, hanem különböző környezetben különböző kompromisszumokat kell hozni.

•

Mindent nem védhetünk száz százalékos biztonsággal. Az előbb láthattuk, hogy a biztonság mindig kompromisszum kérdése. Meg kell találni azt a pontot, ahol az adott biztonsági szint elfogadható, anélkül, hogy más téren elfogadhatatlan dolgokat kényszerítene ki. Az indokolatlanul szigorú védelmi intézkedések nem csak túlzottan költségesek, de gyakran akadályozzák a produktív munkát és arra ösztönzik a felhasználókat, hogy szántszándékkal megkerüljék őket, így nagyobb kockázatot jelentve, mint amit az eredeti intézkedés kiküszöbölt. Tipikus eset például a túlzottan bonyolult jelszavak kikényszerítése, amelyet ezután a felhasználók nem képesek fejben tartani, hanem leírják őket.

•

A védelem legyen egyenszilárdságú! Minden védelmi rendszer annyira erős, amennyire erős a leggyengébb láncszeme. A védelem kialakítása során tehát kellő gondossággal tervezzük meg az egyes komponenseket, ugyanis hamis biztonságérzetet adhat az, ha az egyik komponens erős, miközben más komponensekre nem fordítunk kellő figyelmet. Gyakran előfordul, hogy egy technológia (pl. tűzfal, vagy erős titkosítás) meglétével a biztonságot „elintézettnek” tekintik, miközben ezek pusztán önmagukban nem oldanak meg semmit. Az egyenszilárdság kialakítása nem egyszerű, mivel olyan nehezen kezelhető dolgokat kell beilleszteni a rendszerbe, mint az emberi tényező.

•

A védelem ne kerüljön többe, mint a védett érték! Ez nyilvánvaló és tulajdonképpen következik az előző két elvből is. Bizonyos esetekben célszerűbb együtt élni, vagy más módon (pl. biztosítással) kezelni valamely fenyegetettség által jelentett kockázatot. Például hazai viszonyok között nagyok kevés olyan érték van, amelyet érdemes megelőző védelemmel védeni hetes erősségű földrengés ellen, annak ellenére, hogy egy ilyen veszély elvileg nem zárható ki.

•

A biztonság sosem állapot, hanem folyamat. Mivel a biztonság önmagában nem érzékelhető, csak annak hiánya észlelhető, ezért folyamatosan követni kell rendszerünket, olyan jelek után kutatva, amely az aktuális helyzet hiányosságait jelzik, és a megfelelő ellenintézkedéseket meg kell

- 13 -



tenni. Ha kell, módosítani kell a szabályzatokat, eljárásokat. Gyakori eset, hogy ragaszkodnak a valamikor elkészített szabályzatokhoz, beállításokhoz, miközben a megváltozott körülmények miatt ez nagyobb kárt okoz, mint hasznot. •

Válasszuk az egyszerű megoldást! A biztonsági kérdések esetében különösen igaz, hogy ami bonyolult, az valószínűleg nagyobb valószínűséggel tartalmaz olyan hibákat, amelyek biztonsági problémához vezetnek. Törekedjünk a minél egyszerűbb architektúrákra, szabályzatokra és rendszerekre. Nem szabad engedni a kísértésnek, hogy a bonyolult megoldás biztonságosabb. Általában csak annak látszik, de nem az!

•

Legyen többszintű védelem! Több, egymást támogató védelmi vonal többet ér, mint egy, általában még akkor is, ha egyenként gyengébbek. A támadóknak több akadályon kell átverekedni magukat, így nagyobb az esély, hogy még a siker előtt felfedezik őket. Például ha levelező rendszerünkben központi vírusvédelem van, még nem jelenti azt, hogy nem kell az irodai gépeken külön is víruskeresőt (mégpedig lehetőleg a központitól eltérőt) telepíteni.

4.2 Helyzetfelmérés Csak akkor tudjuk rendszereinket, adatainkat biztonságba helyezni, ha tudatában vagyunk a jelenlegi helyzettel. Ezért első és nagyon fontos lépés az átfogó helyzetelemzés. Ennek során felmérjük a rendszereinket, működési eljárásainkat és a kezelt információt. A helyzetfelmérés során elsősorban megállapítjuk a védendő értékeket és az ezekre veszélyt jelentő veszélyforrásokat. Ezeket célszerű kategóriánként számba venni: •

Környezeti veszélyek – pl. természeti károk, tűz, stb.

•

Fizikai veszélyek – lopás, rongálás, fizikai betörés.

•

Informatikai veszélyek – vírusok, számítógépes betörés, stb.

•

Humán veszélyek – szabotázs, gondatlanság, stb.

•

Szervezeti veszélyek – szervezeti problémák, irányítási gondok, stb.

A veszélyforrásokból a helyzetelemzés eredményeként keletkezik egy felsorolás, amely elsősorban intuitív munka eredménye. Ebbe be kell vonni a szervezet minél több munkatársát, mivel általában a különböző területeken, munkakörökben mások a veszélyek és a prioritások. Természetesen figyelembe kell venni a szabályozási környezet által támasztott igényeket is (pl. adatvédelem, titokvédelem).

4.3 Kockázatelemzés A kockázatelemzés során az egyes veszélyforrások által képviselt kockázatot próbáljuk megállapítani. A kockázat meghatározása során a veszély megvalósulásának valószínűsége és az okozható kár alapján, vagy más nézőpontból az adott veszélyt képviselő sérülékenység kihasználhatósága és ennek hatása alapján történik. - 14 -



Egyes módszertanok megpróbálják számszerűsíteni a kockázatot, általában a bekövetkezési valószínűség és az okozott kár nagyságának szorzataként, azonban a gyakorlat sokszor azt mutatja, hogy ez a számszerűsítés nehéz, vagy egyenesen lehetetlen. Különösen igaz ez azért, mert a legtöbb módszertant elsősorban üzleti környezetben történő felhasználásra dolgozták ki, ahol a közigazgatási környezethez képest gyakran könnyebb a károk számszerűsítése (veszteség, elmarad haszon, stb.). Ezért a gyakorlatban célszerűbb kategóriákkal dolgozni, amelyek az adott környezet működéséhez igazodnak. Az hatások kategorizálása a közigazgatás szemszögéből: •

Alacsony, várhatóan korlátozott hátrányos hatást gyakorol a közigazgatási szervezet műveleteire, vagy a szervezet eszközeire. A korlátozott hátrányos hatás azt jelenti, hogy: o A szolgáltatási képességet oly mértékben és olyan időtartamra csökkentheti, hogy a szervezet képes végrehajtani ugyan elsődleges funkcióit, de a funkciók hatásossága észrevehetően csökken. Az ügyek lefolytatásában fennakadást okoz, de a sikeres lefolytatást és határidők betartását nem veszélyezteti. o A szervezeti eszközök kisebb mértékű károsulását eredményezi. o Kisebb mértékű pénzügyi veszteséget okoz. o A jogbiztonságot kisebb mértékben veszélyezteti, a személyes és/vagy közhiteles adatok védelmével kapcsolatban felmerül a lehetőség, hogy a helyzet javítása nélkül az adatok védelme sérülhet.

•

Fokozott, várhatóan komoly hátrányos hatást gyakorol a közigazgatási szervezet műveleteire, vagy a szervezet eszközeire. A komoly hátrányos hatás azt jelenti, hogy: o A szolgáltatási képességet oly mértékben és olyan időtartamra csökkentheti, hogy a szervezet képes végrehajtani elsődleges funkcióit, de a funkciók hatásossága jelentős mértékben csökken. Az ügyekkel kapcsolatban olyan szintű adatvesztés következik be, amely az ügyek folytatását megakasztja, a határidők betartását lehetetlenné teszi vagy más útra (papír alapú) tereli. o A szervezeti eszközök jelentős károsulását eredményezi. o Jelentős pénzügyi veszteséget okoz. o A jogbiztonságot jelentős mértékben veszélyezteti, személyes és/vagy közhiteles adatok védelme sérül.

•

Kiemelt, várhatóan súlyos vagy katasztrofális hatást gyakorol közigazgatási szervezet műveleteire, vagy a szervezet eszközeire.

a

A súlyos vagy katasztrofális hátrányos hatás azt jelenti, hogy: o A szolgáltatási képességet olyan mértékben és olyan időtartamra csökkentheti, illetve akár meg is szűntetheti, hogy a szervezet nem - 15 -



képes végrehajtani egy vagy több elsődleges funkcióját. Az ügyekkel kapcsolatosan olyan szintű adatvesztés következik be, amely lehetetlenné teszi az ügy folytatását és az eredeti helyzet helyreállítását. o A szervezeti eszközök lényegi károsulását eredményezi. o Lényegi pénzügyi veszteséget okoz. o A jogbiztonságot alapvetően veszélyezteti, a személyes és/vagy közhiteles adatok védelme súlyosan és jóvátehetetlenül sérül. Hasonló módon a bekövetkezési valószínűséget is kategorizálhatjuk: •

Magas – bármikor előfordulhat. mert pl. gyakori esemény, vagy a támadást bárki végrehajthatja. Ilyen lehet például egy olyan vírustámadás, amelyet nagyrészt automatizált kártékony kódok hajtanak végre

•

Közepes – gyakran előfordulhat, pl. szakértő támadó által végrehajtható. Ilyen lehet egy célzott számítógépes betörés a rendszerbe.

•

Alacsony – az előfordulása a vizsgált rendszer vagy szervezet működési idejéhez képest nem gyakori. Ilyen lehet például tűzeset vagy természeti csapás.

A várható kár és a bekövetkezés valószínűsége alapján a kockázat is kategorizálható: hatás \ valószínűség magas

közepes

alacsony

alacsony

mérsékelt alacsony

fokozott

jelentős

mérsékelt alacsony

kiemelt

kritikus

jelentős

alacsony mérsékelt

A táblázat a kockázatot az alacsony, mérsékelt, jelentős és kritikus kategóriákba sorolja. Az egyes besorolások az igényszintek alapján természetesen módosíthatóak, sőt, igény esetén akár a kár, akár az előfordulás valószínűségére és használhatóak más felbontások. A lényeg nem az értékeken van, hanem azon, hogy képesek legyünk prioritásokat felállítani a kockázatok között, így megfelelően koncentrálva a kritikus pontokra. A következő táblázat egy kiragadott példa a veszélyek felsorolásra és a kockázatelemzésre: Veszély

Típus

Leírás

Kár

Valószínűség

Kockázat

Hardverhiba

környezeti

Hardverhiba kiszolgálóban

a

Jelentős

Ritka

Mérsékelt

Vírus-támadás

Informatikai

Vírus kerül a belső számítógépes rendszerbe

Közepes

Állandó

Jelentős

Adathordozó

Humán

Dolgozó

Közepes

Gyakori

Mérsékelt

érzékeny

- 16 -



elvesztése …

adatokat tartalmazó adathordozót veszít el …

…

…

…

…

4.4 Védelmi intézkedések A fenti alapelvek figyelembevételével úgy tudjuk kidolgozni védelmi rendszerünket, hogy felmérjük a különböző veszélyeket, az általuk jelentett kockázatot, majd ezt összevetve a kockázat kezelésére alkalmas védelmi és más intézkedésekkel, kiválasztjuk a megfelelő intézkedést. A prioritások megállapításával meghatározzuk, hogy mely kockázatokkal kívánunk (kell) először foglalkozni, illetve milyen kockázati szintig kívánunk védelmi intézkedéseket hozni, és melyek esetében véljük elfogadhatónak a kockázatot. A védelmi intézkedések, az előzőkben foglaltak alapján a menedzsment, üzemeltetési és műszaki intézkedések csoportjaiba sorolhatóak, azonban felállítható egy másik nézőpont szerinti csoportosítás, amely segíti a veszélyekhez rendelt intézkedések kidolgozását, azon az alapon, hogy a veszélyt megelőzni, észlelni, vagy javítani kívánjuk: •

Megelőző (preventív): a megelőzés során olyan tevékenységeket kell végrehajtani, amely lehetetlenné teszi a veszélyes esemény bekövetkeztét. Megelőző intézkedés például email tartalomszűrés, amellyel megelőzzük vírusok levelezésen keresztüli bejutását.

•

Észlelő (detektáló): az észlelés során a már folyamatban lévő támadást, károkozást próbáljuk – lehetőleg minél hamarabb – észlelni, majd ez alapján megszüntetni, mielőtt lényegi károkozásra kerülne sor. Ilyen például a behatolás jelző (IDS) rendszer használata, amely gyanús hálózati forgalom esetén riasztást ad. Az észlelés alapján azután más tevékenységeket is végezhetünk.

•

Javító (korrektív): a javító intézkedés a már megtörtént esemény által okozott kárt csökkenti vagy szünteti meg. Javító intézkedés például a rendszer visszaállítása mentésből, de ilyen intézkedés akár az is, ha biztosítással rendelkezünk, amely kár esetén biztosít fedezetet.

Ezt a hármast szokás az angol megnevezések alapján PreDeCo-nak (MÉJ elvnek) nevezni3. Természetesen előfordulhat, hogy bizonyos esetekben valamelyik típusú védelmi intézkedés nem értelmezhető, vagy úgy ítéljük, hogy nincsen rá szükség. Az egyes veszélyforrásokra vonatkozóan most már megállapíthatóak a védelmi intézkedések, ezek kidolgozása során használhatjuk a CIA elvet, minden veszélyforráshoz hozzárendelve az általa képviselt kockázatot, az azt megvalósító 3

Erre jelenleg nincs jó magyar elnevezés, ezért javaslatot teszünk a MÉJ (Megelőző, Észlelő,

Javító) elv elnevezésre, de vegyük figyelembe, hogy a külföldi és a hazai szakirodalom is PreDeCo-nak hívja.

- 17 -



bizalmasság, sértetlenség vagy rendelkezésre állás sérülését és az ezeket megelőző, detektáló vagy javító intézkedéseket. Ennek táblázatos összefoglalása egy egyszerű példával: Veszély

Kockázat

Intézkedés M

Hardver meghibásodása

Mérsékelt É

-

J

Vírusszűrés, tűzfal, felhasználók oktatása Víruskereső

M Vírustámadás

C Redundáns rendszer, megelőző karbantartás -

Jelentős É J

…

…

…

Nem védjük / biztosítás …

I Redundáns rendszer, megelőző karbantartás Integritás ellenőrző kriptográfiai eszközök Biztonsági mentés Vírusszűrés, tűzfal, felhasználók oktatása Integritás ellenőrző kriptográfiai eszközök Biztonsági mentés …

A Redundáns rendszer, megelőző karbantartás Rendszerfelügyelet működtetése Tartalék rendszer, biztonsági mentés Vírusszűrés, tűzfal, felhasználók oktatása Rendszerfelügyelet, víruskereső Tartalék rendszer, biztonsági mentés …

A táblázatot minden veszélyre kitöltve meghatározhatóak azok a védelmi intézkedések, amelyek az adott kockázat kezelésére alkalmasak, vagy amelyeket alkalmazni kívánunk. Természetesen, ahogy a példában is előfordul, hogy a táblázat egyes mezői kitöltetlenek, mivel az adott sérülékenység nem értelmezhető és/vagy az adott kockázatot nem kívánjuk vagy nem tudjuk kezelni. Ezzel a módszerrel szisztematikusan végig gondolható a szervezet informatikai védelme, és meghatározhatóak és dokumentálhatóak a védelmi intézkedések. A lényeg nem a „táblázatgyártásban” van, hanem ha követjük a fenti eljárást, akkor biztosak lehetünk abban, hogy sikerült átfogóan végiggondolni a biztonsági kérdéseket, nem hagytunk „rést”. Az informatikai biztonságnak pedig a teljes szervezetre nézve átfogónak kell lennie. Az intézkedéseket besoroljuk a menedzsment, üzemeltetési vagy műszaki kategóriákba, így elhelyezhetőek a szervezet szabályozásaiban. Az intézkedéseket implementálni kell. Ezek egy része informatikai feladat, más része pedig szabályzatok és egyéb előírások meghozatalát igényli. Az intézkedések kialakítása és meghozatala természetesen nem jelenti a tevékenység befejezését, az elemzést rendszeresen meg kell ismételni, és a változó körülmények, fenyegetettségek és üzemeltetési tapasztalatok alapján módosítani, helyesbíteni kell. Az egyik leggyakoribb hiba az egyszer kialakított védelmi intézkedések „kőbe vésése”, mivel a változó körülmények között egy védelmi intézkedés akár későbbiekben károssá is válhat.

- 18 -



4.5 Szabályzatok Mindegyik szervezet működésének hatékonysága a munkafolyamatok szervezettségétől függ. A hatékony működés egyik legfontosabb alappillére az informatika, aminek ezért legalább annyira szervezettnek kell lennie, mint a többi folyamatnak. A jól szervezett informatikai infrastruktúra biztosítja ugyanis, hogy a bizalmasság, a sértetlenség és különösen az elérhetőség, azaz az informatikai biztonság három alapelve teljesülhessen. A láthattuk, hogy ehhez a fizikai és algoritmikus védelmi megoldásokon kívül adminisztratív eszközökkel is tenni kell. Adminisztratív elvek alatt alapvetően a belső szabályozásokat kell érteni. A belső szabályozások azonban a legtöbb szervezetnél hiányoznak, a vezetők nem mindig ismerik fel a fontosságát, szemben a fizikai és algoritmikus védelemmel. Azonban ahol vannak ilyen szabályok, ott sem mindig működnek a rossz tervezés miatt. Egy szabályzatnak ugyanis nem szabad öncélúnak lenni. Legtöbb esetben külső szakértő készíti el a szabályzatokat úgy, hogy a szervezet felelősei nem tudnak, vagy nem akarnak bekapcsolódni a szabályalkotásba. Így készülnek olyan írások, amiket utána senki nem tart be, mert annyira nem illeszkednek a mindennapi ügymenetbe, hogy lehetetlen rávenni a munkatársakat a használatára. Egy szabályzat létrehozása tehát a vezetőségi döntéssel kezdődik. Ha megfogalmazódott az igény, célszerű szakértő segítségét igénybe venni. Vele együtt kell áttekinteni a jelenlegi folyamatokat, és ez alapján meghatározni, hogy tulajdonképpen mi is a szabályozás célja. Ehhez nagy segítséget nyújt a fejezet elején leírt helyzetelemzés és kockázatelemzés. Ezekből származnak a védelmi intézkedések, amik között adminisztratív intézkedések is találhatók. A teljesség igénye nélkül a következő területekre születhetnek szabályzatok: •

Fizikai biztonság o Üzletmenet-folytonossági terv • Hitelesítés és hálózati biztonság o Hálózati hozzáférés o Jelszavak o Távoli elérés • Internetezési szabályok • E-mail szabályok • Vírusvédelemmel kapcsolatos szabályok • Titkosítási szabályok • Szoftverfejlesztési szabályok Alapvetően fontos a szabályzatok összeállításánál, hogy maradéktalanul figyelembe kell venni a szervezet működését, lehetőségeit és képességeit. Nem szabad olyan szabályokat előírni, amit a munkatársak képtelenek betartani vagy akadályozza a munkájukat. Viszont meg kell velük értetni, hogy ők a legkritikusabb alkotórészei az informatikai infrastruktúrának, ha egy ember hibázik, azzal az egész rendszer veszélybe kerül. A jól összeállított szabályzatok betartásával azonban minimálisra lehet csökkenteni a kritikus hibák számát.

- 19 -



Bár a vizsgált környezetre kevésbé jellemző, de természetesen figyelembe lehet az ISO9001 minőségirányítási és az ISO27001 (BS7799) információvédelmi szabványokat, amelyek mintaként szolgálhatnak.

4.6 Az emberi tényező Minden szervezet legfontosabb értéke az információ, amivel dolgozik. Napjainkban az információ egyre inkább elektronikus formában jelenik meg. Az információ megszerzéséhez tehát elektronikus támadásokat hajtanak végre, például az interneten keresztül. A támadások végrehajtásához azonban az alapvető adatokat a legegyszerűbb az információval dolgozó felhasználótól megszerezni. Az informatikai támadásoknak csak 20%-a történik rosszul beállított informatikai rendszerek gyengeségeinek kihasználásával. A maradék 80% vagy belső támadás, vagy kiszivárgó belső információ (pl. jelszó) segítségével elkövetett támadás. A közigazgatás különösen érzékeny az ilyen jellegű támadásokra, ezért minden köztisztviselőnek szükséges tudnia, hogy milyen módon próbálhatják megszerezni tőle az értékes információkat. Egy mondás szerint az informatikai problémák legnagyobb része a billentyűzet és a szék között van. Ez többnyire abból adódik, hogy a felhasználó nincsen tisztában azzal, hogy amit a számítógéppel csinál, nem csak a saját gépére lehet kihatással, hanem a teljes rendszerre is. Márpedig minden rendszer annyit ér, amennyit a leggyengébb láncszeme. Ha egy felhasználó kiadja a jelszavát, a támadó a bejuthat a védett rendszerbe, ezzel fontos információkat szerezhet. Ez egy nyilvánvaló támadás, sokszor mondják el, hogy jelszavakat nem szabad kiadni. Egy ügyes támadónak azonban már az is kiindulópont, ha a rendszer felépítését megismeri. Ezért a legjelentéktelenebb információt sem szabad kiadni, mert soha nem lehet tudni, hogy a támadónak mi képvisel értéket. A felhasználók alapvetően segítőkészek, a paranoia nem tartozik az alapvető emberi jellemhez. Ezt használja ki az „social engineering” támadás, melyre igazán jó magyar kifejezést még nem alkottak. Leginkább megtévesztésnek nevezhetjük. A támadó ugyanis egyszerű pszichológiai eszközöket bevetve megtéveszti a felhasználót úgy, hogy az önként kiadja neki a kulcsinformációkat, nem is sejtve, hogy épp olyat tesz, amit nem szabad. Ez történhet személyesen, telefonon keresztül vagy akár e-mailben is. Nagyon nehéz ellene védekezni, azonban ez a fejezet talán segít a támadások felismerésében.

4.6.1

Jelszavak

A legalapvetőbb szabály: a jelszavakat soha, senkinek ne adjuk ki. Persze bizonyos feltételeknek eleget kell tenni ahhoz, hogy ennek a szabálynak értelme legyen. A rossz jelszó megválasztása feleslegessé teszi a social engineering támadást, mert gépi erővel kitalálható vagy feltörhető. Azaz a jó jelszónak a következő két tulajdonsága van. Legalább 8 karakter hosszú és tartalmaz kis- és nagybetűt, valamint számot. Emellett legyen könnyen megjegyezhető. Például a vezetéknév, a keresztnév és a születési dátum egy-egy szótagja összekeverve, véletlenszerűen kis- és nagybetűkkel elég jó védelmet biztosíthat. Egy rossz jelszót, mely pl. 5 karakter hosszú, és értelmes, szótári szót tartalmaz, néhány perc alatt fel lehet törni. További jó tanács, hogy legalább két jelszóval

- 20 -



rendelkezzünk. Az egyiket az érzékeny helyeken kell használni, pl. a közigazgatás belső rendszereiben, a másikat pedig az összes internetes portálon, internetes levelezőn. Ez azért fontos, mert egy böngészőbe beírt jelszót akár a saját géphez hozzáférő ember, de főleg a weboldalt működtető jó vagy rosszindulatú személy könnyen meg tudja szerezni. A böngészőbe írt jelszó tehát könnyen kiszivároghat, és ha ez megegyezik a belső rendszerben használttal, viszonylag könnyű az informatikai betörést végrehajtani.

4.6.2

Adathalászat

Egy példán keresztül szemléltetjük4, hogy hogyan történik egy fent vázolt támadás. Ez a példa egy ún. phising, magyarul adathalászati támadás. Ennek során a felhasználó egy megtévesztő elektronikus levelet kap, valamilyen hitelesnek tűnő szervezettől, hitelesnek tűnő szöveggel, melyben megkérik, hogy látogasson el egy weboldalra, ahol írja be a felhasználónevét és a jelszavát. A példában egy Ügyfélkapu elleni phising támadást szimulálunk, melynek kivédésére találhatunk segítséget az Ügyfélkapu Segítség menüje alatt. A támadás első lépése, hogy az áldozat egy hitelesnek tűnő e-mailt kap, ebben az esetben a feladó a „Kormányzati Portál Ügyfélszolgálat”, az [email protected] címről. A levél tárgya a Regisztrációs figyelmeztetés. Az e-mail tartalmaz egy fejlécet is, hogy a hitelesség látszatát tovább erősítse. A levél figyelmeztet arra, hogy az Ügyfélkapu műszaki problémák miatt elveszítette a tárolt jelszavakat, ezért szükség van a jelszavak újbóli beírására. A levélben egy bonyolult hivatkozás is el van helyezve, melyre azonban kattintani is lehet az egyszerűség miatt.

4

Az itt bemutatott példa fiktív, tudomásunk szerint ilyen támadás nem történt. A valós

önkormányzati környezetet (Ügyfélkapu) pusztán illusztrációként használjuk, mivel a legtöbb, emberi tényezőn alapuló támadás azon alapul, hogy hamis és valós információk keverésével tévesztik meg az embereket. A bemutatott lépések (hamis, információt kérő email, hamis weboldal, stb.) jellemzőek a phising támadásokra.

- 21 -



1. ábra: Phising támadás

Ami a hitelesség látszatához kell, az e-mail cím, mely minden levelezőben egyedileg beállítható, a fejléc, mely az Ügyfélkapuról egyszerűen megszerezhető és egy olyan szöveg, mely eléggé hivatalosan van megfogalmazva. A tapasztalatok szerint a felhasználók nagyobb része gondolkodás nélkül rákattint a hivatkozásra, melynek hatására az alábbi weboldal jelenik meg.

2. ábra: Hamis weboldal

A megjelenő weboldal újfent hitelesnek tűnik, hiszen nagyon hasonlít az Ügyfélkapu hivatalos oldalára. Az oldalon megjelenő szöveg megerősíti az e-mail - 22 -



szövegét. A megjelenő űrlapon lehetőség van beírni a felhasználónevet és a jelszót, majd az OK gomb megnyomásával megjelenik az Ügyfélkapu hivatalos oldala, ahol már gond nélkül működik a belépés. A felhasználók nagy része elégedetten nyugtázza a történéseket, és hamarosan el is felejtik azt. De észre kell venni a trükköket, amit a támadó használt. A böngészőben a hivatkozás a www.magyarorszag.hn hondurasi weboldalra mutat. A támadó ilyen oldalt könnyen és alacsony költséggel létrehozhat, ha ezt a címet regisztrálja. Mivel ez csak egyetlen karakterben különbözik a hivatalos oldaltól, nagyon nehéz észrevenni a sok karakter között ezt az apró eltérést. Az oldal egy az egyben az Ügyfélkapu elfelejtett jelszavakat elküldő oldala, azzal az apró különbséggel, hogy az E-mail cím űrlapmező Jelszóra van kicserélve. A szövegben pedig néhány szó lett csak kicserélve. Érdemes összehasonlítani a fenti képernyőképet az eredeti oldallal.

3. ábra: Az eredeti weboldal

Miután a felhasználó az OK gombra kattint, és megjelenik az eredeti Ügyfélkapu oldal, a támadó már birtokában van a felhasználó jelszavának. Ezzel a jelszóval az Ügyfélkapun a felhasználó helyett be tud lépni, és bármilyen ügyet el tud intézni, melyhez nem szükséges személyes megjelenés. Az ilyen támadások elsősorban internetes banki rendszerek és elektronikus közigazgatási szolgáltatások ellen jelennek meg. Általában úgy védik ki, hogy az ügyintézés elkezdéséhez vagy SMS-ben érkezik egy ideiglenes jelszó vagy elektronikus aláíráshoz kötik az ügyintézést. Ha azonban nincs ilyen védelem, akkor sem kell megijedni, csak tudatában kell lenni néhány alapvető szabálynak. A legfontosabb, hogy egyetlen bank vagy kormányzati szerv sem lép kapcsolatba az ügyféllel elektronikus levélen keresztül akkor, amikor valami történik a jelszavával. Már csak azért sem, mert a jelszavak és a teljes rendszer biztonsági mentésére nagyon sokat költenek, így - 23 -



legfeljebb kisebb fennakadások lehetnek. A jelszavak elvesztése akkora kár egy ilyen szervezetnek, hogy hivatalosan, hagyományos levélben lép kapcsolatba a felhasználóval. Tehát semmilyen hivatalosnak tűnő e-mailnek nem szabad hinni, ha a jelszavunkat kéri! A böngészőben megjelenő oldalt is viszonylag egyszerűen le lehet ellenőrizni. A közigazgatási és banki oldalak titkosított adatcsatornán keresztül kommunikálnak az ügyféllel. A böngésző jobb alsó sarkában ilyenkor egy lakat ikonja jelenik meg. Mielőtt bármit is beírunk az űrlapba, kattintsunk kétszer erre az ikonra. Ekkor megjelenik a honlap tanúsítványa, mely mindent elárul az adott oldalról. Az Ügyfélkapu esetében az alábbi tanúsítványt láthatjuk.

4. ábra: Ügyfélkapu tanúsítványa

A tanúsítványban a Tulajdonos mezőre kattintva lehet megnézni, hogy kié a honlap. Az Ügyfélkapu esetében a tulajdonos a Miniszterelnöki Hivatal Elektronikus Kormányzati Központja, tehát az oldal hiteles. További hasznos információ, hogy a magyar honlapok tanúsítványainak kiállítója legtöbbször a Netlock Kft., így ha a Kiállító mezőre kattintunk, és ott a NetLock nevet látjuk, szintén bizonyosak lehetünk abban, hogy a honlap nem a becsapásra jött létre. A phising támadás mellett a másik gyakran alkalmazott adatlopási trükk során az ügyfelet telefonon hívják fel. Minél nagyobb egy szervezet, annál kevésbé valószínű, hogy az alkalmazott mindenkit ismer. Az ilyen szervezeteknél fordulhat elő, hogy valaki, magát rendszergazdának bemutatva hívja fel a dolgozót telefonon, és bizonyos dolgokat kér. Például a jelszavát. Ez a hagyományos social engineering támadás. Újra meg kell említeni a legfontosabb szabályt. Jelszót soha, senkinek nem szabad kiadni, még belső embernek sem. A hálózathoz hozzáférő rendszergazda ugyanis pontosan annyi dologhoz fér hozzá, amennyihez engedélye van. Nincs olyan szituáció, amikor egy alkalmazott jelszavára lenne szüksége. A rendszerben használt jelszavakat egyébként a rendszergazda sem tudja elolvasni, de meg tudja azokat változtatni.

- 24 -



Akkor is gyanakodjunk, ha a telefonáló a számítógépes hálózat kiépítéséről vagy a szervezet működéséről kérdez. Ez lehet hiteles hívás, azonban ha bizonytalanok vagyunk, inkább továbbítsuk a kérést a szervezeten belül olyan embernek, aki járatos az informatikában. Minden gyanús kérdésre a legjobb válasz az, hogy „nem tudom” vagy az, hogy „nem emlékszem”. A legbiztosabb, ha ilyen információt csak olyannal osztunk meg, akit személyesen ismerünk. De jelszót neki sem szabad kiadni!

4.7 Jellegzetes informatikai architektúrák és rendszerek önkormányzatoknál Informatikai szempontból az önkormányzatok nem különböznek jellegzetesen más irodai, üzleti környezettől. Mégis célszerű áttekinteni a jellegzetes architektúrákat biztonsági szempontból. Tekintsük át a jellegzetes architektúrákat! •

Önálló alkalmazás. A legegyszerűbb felépítés, a felhasználó számítógépén fut az alkalmazás, és az esetleges – alkalmazástól független – állománymozgatáson kívül, nincs kapcsolata más rendszerekkel. Tipikusan ilyen architektúrájú pl. egy szövegszerkesztő program. Mivel az alkalmazásnak rendszerint nincsen a normál felhasználói felületen kívül kapcsolódási pontja, ezért nem jellemző a támadása. Ennek ellenére több aktív támadás is elképzelhető, mint például a Word makró vírusok, amelyek egyszerű dokumentumcserével terjednek.

•

Kliens-szerver típusú alkalmazás. Ennek több típusa is van, de mindegyikben közös, hogy van egy vagy több szerver (kiszolgáló), amely valamilyen szolgáltatásokat nyújt a klienseknek (ügyfelek). A kliens és a szerver valamely kommunikációs csatornán, rendszerint hálózaton keresztül kapcsolódnak egymáshoz. A klines és a szerver kérdés és válaszüzenetek formájában kommunikál. Egyszerű kliens-szerver architektúra egy adatbázist használó alkalmazás. A kliensen futó program kapcsolódik az adatbáziskiszolgálóhoz és a működéshez szükséges adatokat az adatbáziskezelőn tárolja. De kliens-szerver a web böngészés is, ahol a böngésző kér le dokumentumokat a web kiszolgálótól, értelmezi majd megjeleníti azokat. A kliens-szerver architektúrák több biztonsági kérdést is felvetnek: •

Meg kell oldani a kliens és a szerver azonosítását, azaz a szerver csak megfelelő kliensnek engedjen csatlakozást, a kliens pedig biztos legyen abban, hogy mely szerverhez csatalakozik.

A kliens szerver architektúrákat tovább lehet bontani a kliens „tudása” illetve a rétegek száma szerint: •

Vastag kliensek – a kliens érdemi feladatokat lát el az alkalmazás működésében, vagyis az alkalmazás funkcióinak bizonyos részei a kliensben vannak megvalósítva. Jelenleg talán a legelterjedtebb megoldás, az általános kliens-szerver elvek vonatkoznak rá.

- 25 -


•


•

Vékony kliensek – a kliensnek csak megjelenítő szerepe van, az alkalmazás maga kiszolgálón működik, csak a ki és bementeti adatok jelennek meg a kliensen. Hagyományosan ezt az elvet hívták terminál alapú működésnek, ennek modern megvalósítása, amikor a kliens ténylegesen csak a képi megjelenítését végzi az alkalmazásnak. Ilyen pl. a Windows terminál kiszolgáló. A kliensen az alkalmazás semmilyen funkciója sem valósul meg, ezért jól alkalmazható kevésbé védett kliensek esetében.

•

Háromrétegű architektúrák – ez az architektúra elválasztja az adatbázist, az alkalmazás logikát és a megjelenítést három, külön rétegbe. Mindegyik réteg adott felületen keresztül kommunikál egymással. Előnye, hogy a jól definiált felületek lehetővé teszik, hogy bármely réteg lecserélhető legyen. Ez különös jelentőséggel bír az e-kormányzati alkalmazásoknál, ahol az interoperabilitás kiemelt fontosságú.

•

Többrétegű architektúrák – a háromrétegű architektúra általánosított formája. Az alkalmazás logikát megvalósító réteg többrétegűként van megvalósítva.

Peer-to-peer (p2p, egyenrangú alkalmazások közötti kapcsolat). Minden részt vevő elem egyenrangú, a kommunikáció, adatcsere egymáson keresztül folyik. Ilyen felépítésű a legtöbb fájlcserélő, vagy a Skype telefon alkalmazás, de közigazagatási környezetben egyelőre csekély az alkalmazása. A p2p architektúra nagyszintű hibatűrést és anonimitást képes megvalósítani.

Önkormányzati környezetben mindenképpen a kliens-szerver architektúra a legjellemzőbb. A biztonságot megvalósító számra ez azt jelenti, hogy legalább három komponenssel kell foglakozni, többrétegű architektúrák esetén pedig még többel: •

A szerver

•

A kliens

•

A kettő közötti kommunikáció

Nagyon fontos, hogy bármely komponens biztonsági hiányossága kihat az egész rendszer biztonságára. Gyakori hiba, hogy például a szervert erősen védik külső támadás ellen, de a támadó a védtelen klienst „ugródeszkaként” használva képes kompromittálni a szervert.

4.8 Rendszerek beállításai A következőkben a Microsoft Windows és a Linux rendszerek alapvető biztonsági beállításait ismertetjük. Ezen leírás nem helyettesíti sem a gyártói előírásokat vagy a felhasználói dokumentációt, és nem kíván olyan mélységben foglalkozni a kérdéssel, amelyem valószínűleg amúgy is szakértő (rendszerintegrátor, biztonsági szakértő, stb.) segítségét igényelné komplex rendszerek esetében. Megad viszont általánosan használható tanácsokat, amelyek alkalmazása

- 26 -



környezettől függetlenül (de annak messzemenő figyelembevételével!) képes a rendszer biztonságának növelésére.

4.8.1

Windows

A legelterjedtebb asztali operációs rendszer a Microsoft Windows család. Kijelenthető, hogy a modern biztonsági követelményeknek csak a Windows 2000 és a Windows XP, illetve a Windows 2000 és 2003 Server felel meg. Régebbi (Windows 95, 98, NT4) rendszerekkel csak korlátozottan lehet biztonságos rendszert kialakítani, és mivel már a gyártói támogatás sem teljeskörű, ezért ezek használata nem, vagy csak különleges körülmények (pl. teljesen zárt hálózat) javasolt. A legfejlettebb biztonsági rendszerekkel a Windows XP Service Pack 2, illetve kiszolgáló oldali megfelelője a Windows 2003 Server rendelkezik, ezért elsősorban ezzel a rendszerrel foglalkozunk. A Windows egy nagyon komplex operációs rendszer, ráadásul nagyon különböző környezetben használható: •

Otthoni számítógépen. Ebben az esetben általában nincsen szükség a felhasználó szintű megkülönböztetésre, a felhasználók védésére egymástól. A Windows XP Home rendszer erre a célra szolgál, nem is tartalmazza ezeket a védelmi funkciókat. Ez irodai környezetben viszont nem elfogadható.

•

Kisméretű irodai hálózatok. Az ilyen hálózatokra illeszkedik a Windows „munkacsoport” (Workgroup) modellje, amelynél az egyes számítógépek külön-külön tartják nyilván a felhasználókat, nincs központosított felhasználó és erőforrás-menedzsment. Mindazonáltal az egyes gépek ugyanazon munkacsoportba kapcsolhatóak, és bizonyos erőforrásmegosztás (állományok, nyomtatók) lehetséges. A biztonsági beállítások kezelése nem központosítható, minden gépek külön kell kezelni. Jól alkalmazható otthoni és kis/közepes méretű irodai hálózatok esetén.

•

Vállalati és nagyméretű irodai hálózatok. Az ilyen hálózatokban a felhasználók, erőforrások és biztonsági rendszabályok kezelése központosított a központi címtár (Active-directory, korábbi rendszereknél domain) alapján. Ilyen rendszerek üzemeltetése összetett feladat, központi címtár kiszolgáló(k) szükségesek hozzá. A címtár nem csak a felhasználók központi kezelését teszi lehetővé, de más alkalmazások (levelezés, csoportmunka, stb.) is bekapcsolható a címtárba. Az ilyen hálózatok telepítése és igényeknek megfelelő biztonsági beállítása mindenképpen szakértői feladat, rendszerint a szállítást/telepítést végző rendszerintegrátor feladata.

•

Nagyvállalati hálózatok. Egészen nagyméretű Windows alapú hálózatok esetében több Active-directory alapú címtár szervezhető hierarchikus rendbe. Alapvető működése megegyezik a címtár alapú rendszerekkel. - 27 -



A következőkben bemutatunk néhány alapvető Windows biztonsági beállítást. A beállítások nagyrészt függetlenek a használt környezettől, de elsősorban az egyszerűbb, munkacsoport alapú rendszerekben van igazán létjogosultságuk, mivel a címtár alapú rendszereknél a központosított kezelés miatt elengedhetetlen, hogy erre a célra kiképzett üzemeltető kezelje a rendszert, és a telepítés során már megtörténnek azok a beállítások, amelyek a központi üzemeltetést lehetővé teszik. A kisméretű irodai hálózatokra jellemző viszont rendszerint a felhasználók és az üzemeltetők közösen kezelnek, a beállításokat külön-külön kell megtenni. A Windows igen kifinomult biztonsági lehetőségekkel rendelkezik. Sajnos ez a tény is sok hiba forrása lehet, mivel a sok lehetőség között könnyű hibás beállítást választani. 4.8.1.1 Biztonsági beállítások Már a telepítésnél tartsuk szem előtt a biztonságot! A biztonság kialakítása a telepítésnél történik. Amikre ügyelni kell: • Csak a szükséges komponenseket telepítsük! Amely komponensekre nincs szükség (pl. játékok, üzenő szoftver, stb.), azok telepítését tiltsuk le. Minden felesleges elem rontja a rendszer biztonságát, illetve megnehezíti a biztonságos beállítások megtételét. • Megfelelően alakítsuk ki a háttértárolót! A lemezegység particionálása és a telepítés és üzemeltetés során törekedjünk a felhasználói adatok és a rendszerkomponensek külön partíción/lemezegységen való elhelyezésére. Ez megkönnyíti a hozzáférési jogok helyes beállítását, illetve a biztonsági mentések elvégzését. Windows NT, 2000, XP professional esetén csak NTFS típusú fájlrendszert alakítsunk ki! • Az alapvető biztonsági frissítések telepítése előtt ne kapcsoljuk a rendszert nyílt hálózatra! Bizonyos sérülékenységre olyan automatizált támadások, vírusok, stb. léteznek, amelyek egy frissítés nélkül hálózatra kapcsolt gépet szó szerint percek alatt megfertőznek. A frissítéseket vagy külön, biztonságos gépen töltsük le, és pl. CD-re írva telepítsük az új gépen, de legalább is legyen hálózatunk tűzfal mögött a telepítés során. • A „rendszergazda” felhasználó mellé vegyünk fel más felhasználókat! Bár kényelmes, de veszélyes a minden jogosultsággal rendelkező rendszergazdaként dolgozni. Figyeljünk a biztonsági frissítésekre! Szinte minden szoftver termék esetében folyamatosan kerülnek felszínre biztonsági problémák. A gyártók periodikusan frissítéseket bocsátanak ki ezek javítására. Az eddigi statisztikák azt mutatják, hogy a legnagyobb károkat okozó vírus és egyéb támadások alapjául szolgáló hibákra már hónapokkal, néha évekkel korábban megvolt a javítás. Ennek ellenére a rendszerek üzemeltetői nem telepítették a javítócsomagokat, így a támadások sikerrel jártak. A Windows termékcsalád gyártója, a Microsoft is felismerte, hogy automatizált javítási lehetőségek nélkül a rendszerei biztonsága nagyon alacsony szintű lehet. Ezért rendelkezésre áll a Windows Update rendszer, amely automatikusan letölti - 28 -



és telepíti a biztonsági frissítéseket. Ez a megoldás könnyen kezelhető kisméretű irodai hálózatok esetén. Nagyméretű vállalati hálózatoknál van lehetőség központosított frissítésekre is, ez további szoftver infrastruktúrát igényel (System management Server, stb.) A Windowshoz alapvetően három fajta javítási csomagokat érhetőek el: •

Service Pack (javító csomag, SP): egy, két évente megjelenő javítócsomag, amely tartalmazza az addig megjelent javításokat, és általában néhány funkcionális fejlesztést is. Általában javasolt a legújabb Service Pack telepítése, Windows XP-nél erősen javasolt az SP2 telepítése, mivel az jelentős biztonsági újításokat tartalmaz. A Service Packok kumultívak, tehát a legújabb tartalmazza a korábbi csomagokat is, így SP2 telepítése előtt nem kell SP1-et telepíteni.

•

Kritikus javítások: valamely újonnan felfedezett, súlyos biztonsági hiba kijavítására. Ezeket a javításokat gyakorlatilag kötelező telepíteni, csak igen indokolt esetben tekintsünk el tőlük. A Microsoft rendszerint minden hónap második keddjén jeleníti meg ezeket a javításokat, de nagyon kritikus esetben korábban is.

•

Nem kritikus javítások: olyan javítások, vagy funkcionális újdonságok, amelyek nem befolyásolják a rendszer közvetlen biztonságát, de célszerű őket telepíteni. Szintén minden hónap másik keddjén jelennek meg.

A telepítéseket legegyszerűbben a Windows Update segítségével tehetjük meg, illetve be lehet kapcsolni az automatikus frissítést, amely a kritikus javításokat magától telepíti, amint megjelentek. A frissítések kézzel is telepíthetőek a Windows Update webhely felkeresésével, ehhez Internet Explorer szükséges.

5. ábra: Automatikus frissítés beállítása

Az automatikus frissítések a „Sajátgép” tulajdonságai, vagy a „bezérlőpult” megfelelő pontjából kapcsolható be. A Windows XP Service Pack 2 első indításkor felajánlja az automatikus frissítések bekapcsolását, és ha ez nem történik meg, akkor folyamatosan „nyaggatja” a felhasználót.

- 29 -



A frissítések az Internet Explorer eszközök/Windwos Update menüpontjából is telepíthetőek, ilyenkor kézzel választhatjuk ki a telepítendő frissítéseket és a kritikus frissítéseken kívül más frissítéseket is telepíthetünk. A frissítések ezen kívül külön is letölthetőek a Microsoft letöltő központból (http://www.microsoft.com/downloads/) és telepíthetőek hálózatra nem kapcsolt gépekre is.

6. ábra: Windows Update közvetlenül a böngészőből

A kritikus javításokat általában célszerű azonnal telepíteni, amint megjelennek, de ügyeljünk arra, hogy volt már rá példa, hogy egy javítás gondot okozott, így a legnagyobb biztonság érdekében a kritikus javításokat is érdemes teszt rendszeren kipróbálni. A többi frissítés esetében pedig mindenképpen hasznos a leírások alapján és tesztrendszeren megvizsgálni, hogy esetleg valamely alkalmazással nem lép-e fel inkompatibilitás. Használjunk víruskeresőt! Nyilvánvaló biztonsági lépés a víruskereső használata. A Windows közvetlenül nem tartalmaz víruskeresőt, bár a frissítés rendszeresen tartalmaznak egy eszközt, amely az esetleges káros kódokat eltávolítja, ez azonban nem helyettesíti a megelőző jellegű víruskeresőt. Ezért külön kell megvásárolni és telepíteni valamely gyártó víruskeresőjét. A víruskeresők használatakor a következő pontokat kell figyelembe venni: •

A víruskereső a céloknak megfelelően legyen beállítva! A legtöbb víruskereső igen szerteágazó beállítási lehetőségekkel rendelkezik, a keresés mélységét, idejét, tárgyait, stb. tekintve. Célszerű tehát először megismerkedni a termékkel, mivel az alapbeállítások nem mindig alkalmasak irodai környezetben való alkalmazásra.

- 30 -



•

Folyamatosan legyen frissítve a vírusadatbázis! Minden víruskereső képes automatikusan frissíteni magát, de ennek a funkciónak be kell kapcsolva lennie! Erre a telepítés során ügyelni kell. Fontos arra figyelni, hogy a frissítés általában időhatárhoz kötött, csak a megfelelő licenszek meglétekor történik meg. Gyakori hiba, hogy bár a licenszt megvásárolták, elmarad az aktiválási kódok bevitele, vagy a frissítés az új verzióra, így megszűnik a vírusadatbázis frissítése.

•

Legyen terv a vírusfertőzések bekövetkeztére. A víruskeresők sem védenek százszázalékosan, ezért fontos, hogy legyen megfelelő biztonsági mentés, amely alapján egy esetleges összeomlás visszaállítható. Ugyancsak legyen arra terv, hogy elháríthatatlan vírusfertőzés észelésekor milyen más tennivalók vannak. Ilyenkor jellemző, hogy le kell állítani külső és esetleg a belső hálózati kapcsolatokat, a fertőzés továbbterjedésének megakadályozására.

Használjunk tűzfalat! A tűzfal alapvető védelmi eszköze az irodai hálózatnak. Windows alkalmazása esetében (de más rendszereknél is) tulajdonképpen kötelező a belső hálózatot tűzfallal védeni, olyan módon, hogy kívülről ne lehessen tetszőleges kapcsolatot létesíteni a belső munkaállomások felé. A tűzfallal védett hálózaton túl célszerű személyes tűzfalat is használni. A Windows XP SP2-től az operációs rendszer is rendelkezik beépített személyes tűzfallal, de nagyobb „tudású” tűzfalak is kaphatóak, más gyártótól.

7. ábra: Tűzfal beállítások a hálózati kapcsolatoknál

A tűzfal alapértelmezésben be van kapcsolva, ez ellenőrizhető a hálózati kapcsolatok mappában, ahol kis lakat ikon jelzi a bekapcsolt tűzfalat. A tulajdonságok „Általános „ fülén ki és bekapcsolható a tűzfal. A tűzfalat tartsuk bekapcsolva, kivéve, ha biztosak vagyunk benne, hogy nincs rá szükség, mert például nincs nyilvános hálózatra kapcsolva a gép. A bekapcsolt tűzfal csak minimális teljesítménycsökkentést okoz, amely modernebb gépeken észrevehetetlen.

- 31 -



8. ábra: Windows tűzfal engedélyezése

„Speciális” fülét választva átállíthatóak a tűzfal paraméterek. Általában, ha a számítógépen nem futtatunk kiszolgáló alkalmazást, akkor nincs szükség különleges beállításokra. A tűzfal hasznos szolgáltatása a számítógépről induló kapcsolatok figyelése. Ha ismeretlen program kíván kapcsolatot nyitni, akkor riasztást ad a tűzfal, mivel lehet, hogy pl. egy vírus próbál a gépről továbbterjedni. Természetesen a legtöbb program jogosult hálózati kommunikációra, így azokat a tűzfal szabadon engedi kommunikálni. Az engedélyezett programok listája a „Kivételek” fül választásával szerkeszthető. Ha olyan alkalmazást telepítünk, amely várhatóan hálózaton keresztül működik, célszerű előre felvenni. Ha egy alkalmazás, amely nincs engedélyezve, mégis kapcsolat nyitással próbálkozik, a tűzfal riasztást ad, amely során lehetőségünk van ezt a kapcsolatot letiltani, egyszeri alkalommal, vagy állandóan engedélyezni. Lényeges, és erre minden felhasználó figyelmét fel kell hívni, hogy amennyiben ilyen figyelmeztetést lát, továbblépni csak akkor szabad, ha megbizonyosodott arról, hogy a kapcsolat valóban engedélyezhető.

- 32 -



9. ábra: Tűzfal által blokkolt/engedélyezett programok

Használjunk NTFS fájlrendszert minden meghajtón! A Windows többféle fájlrendszert támogat, ezek közül azonban csak az NTFS rendelkezik megfelelő védelmi lehetőségekkel. Más állományrendszerek (pl. FAT, FAT32) nem ismerik a felhasználó és a felhasználóként külön definiálható jogosultságok fogalmát, így nem alakítható ki állományvédelem. Ráadásul, nagyméretű meghajtókon az NTFS jóval hatékonyabb, és nagyobb méretű állományokat képes kezelni.

10. ábra: Fájlrendszer típusának ellenőrzése

- 33 -



A fájlrendszer típusát a meghajtó tulajdonságai között nézhetjük meg, az „Általános” fülön. Ha a fájlrendszer nem NTFS, akkor a convert parancssori programmal később is NTFS-sé lehet konvertálni. Mindazonáltal javasolt már a telepítéskor NTFS-re formázni a meghajtót, mert különben külön kell a konvertálás után beállítani a jogosultságokat. Később a rendszerhez adott lemezmeghajtók esetében ügyeljünk, hogy a formázás NTFS típusú legyen.

11. ábra: Fájlrendszer típus megadása formázáskor

Kapcsoljuk ki az automatikus futtatást! Az automatikus futtatás (Autorun) arra szolgál, hogy adathordozó (CD, USBdrive) behelyezése esetén a rajta lévő program automatikusan elinduljon. Ez alaphelyzetben be van kapcsolva, és biztonsági szempontból igen veszélyes, mert egy támadó könnyen rávehet valakit ara, hogy egy megfelelően elkészített adathordozót behelyezzen. Az automatikus futtatás többféle módon kikapcsolható, a házirendek segítségével az egész gépre tiltható. Ehhez a Start menü Futtatás pontjába írjuk be a következőt: gpedit.msc! A „Felügyeleti sablonok” közül válasszuk ki a „rendszer” pontot és az „Automatikus lejátszás kikapcsolása” pontban engedélyezhetjük vagy tilthatjuk az Autorunt. Különböző segídprogramokkal, mint pl. a Microsoft PowerToys TweakUI-al lemezmeghajtóként és adathordozó típusonként külön állíthatjuk az automatikus lejátszást. A TweakUI egyébként egy igen hasznos segédprogram, szabadon letölthető a Microsoft weboldaláról, a http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx címről.

- 34 -



12. ábra: Automatikus lejátszás beállítása a TweakUI-val

Használjuk a fájlrendszer titkosítás lehetőségét!

Ismert, hogy fizikai hozzáférés esetében a legtöbb védelmi rendszer hatékonysága romlik. Ha egy számítógéphez, vagy háttértérjához (merevlemez) valaki közvetlenül hozzáfér, akkor képes a rajta lévő adatokat leolvasni (pl. a merevlemezt átszereli egy másik számítógépbe). Bár egy megfelelő védelemmel ellátott irodában ennek kicsi a valószínűsége, kritikus lehet egy hordozható számítógép esetében, amelyet viszonylag könnyű ellopni, vagy elveszíteni. Az ilyen veszély kiküszöbölésre szolgál a titkosított állományrendszer (EFS – Encrypted File System).

13. ábra: Titkosítandó mappa tulajdonságai

A rendszer tetszőleges mappáját és a benne levő állományokat titkosíthatjuk. Ehhez az adott mappa tulajdonságok menüpontját kell választani, majd az általános beállításokon belül a speciális attribútumokat. Itt megadhatjuk, hogy a mappa titkosított legyen-e. A rendszer rákérdez, hogy a beállítást akarjuk-e további al-mappákra alkalmazni.

- 35 -



Bekapcsolt tikosításnál csak az állomány tulajdonosa képes hozzáférni és értelmezni a tartalmat, még fizikai hozzáférés esetében is! Ebben az esetben egy ellopott laptop számítógépből hiába szerelik ki a merevlemezt és helyezik át más számítógépbe, a titkosított állományokat nem lehet értelmezni. A titkosítást ki lehet kapcsolni, ekkor a rendszer visszafejti az állományokat. Igen lényeges, hogy a titkosítás miatt, ha a felhasználó elfelejti a jelszavát, senki nem lesz képes újra elérni az állományokat. Tehát a jelszavak tárolásánál meg kell oldani a jelszavak visszanyerhetőségét (pl. jelszófüzet biztonságos helyen tárolva, stb.).

14. ábra: Titkosítás engedélyezése

Ügyeljünk az operációs rendszertől független biztonságra! Mivel egy rendszer biztonsága a leggyengébb láncszemtől függ, ezért természetes, hogy pusztán az operációs rendszer védelmével nem lehet a teljes rendszer biztonságát garantálni. Fizikailag hozzáférve egy munkaállomáshoz vagy kiszolgálóhoz, számtalan módja van annak, hogy a rendszer biztonságát megsértsük. Windows rendszerben (de ez szinte minden más rendszerre igaz) tárolt adatokhoz például könnyen hozzá lehet férni, ha új rendszert telepítünk, vagy rendszerindító lemezzel sikerül másik operációs rendszert indítani. Ezért fontos, hogy néhány alapvető operációs rendszertől független beállítást megtegyünk: •

A BIOS-ban állítsuk be a merevlemezt elsődleges rendszerindító eszköznek. Így nem lehet más operációs rendszert indítani.

•

A BIOS beállításokat védjük jelszóval! Így elkerülhető, hogy valaki átállítsa őket. Szükség esetén lehetséges a gép indítását is jelszóhoz kötni egyes BIOS változatok esetében.

•

A számítógépben csak olyan eszközök legyenek, amelyekre valóban szükség van. Például, ha fennáll a kockázata annak, hogy belső munkatárs adatokat csempész ki, akkor a gépből el kell távolítani az adathordozók fogadására alkalmas eszközöket (CD író, USB csatlakozó, stb.)

- 36 -


•


Az eszközöket biztosítsuk az ellopás, szétszerelés ellen! A fenti védelmi lépések egyszerűen megkerülhetőek, a gép felnyitásával, ellopásával.

Ügyeljünk az állománymegosztásokra! Irodai környezetben fontos a dokumentumok és egyéb állományok megosztása. Ugyanakkor nyilvánvaló, hogy biztonsági szempontból igen lényeges kérdés, hogy kik és hogyan férhetnek hozzá a megosztott állományokhoz. Lényeges pontok: •

Sose teljes lemezegységet, mindig csak mappákat osszunk meg! Így sokkal pontosabban tudjuk, hogy mi van megosztva rendszerünkön, illetve véletlenül nem adunk hozzáférést más, pl. rendszerállományokhoz.

•

Ha csak olvasásra kell megosztani állományokat, akkor a megosztás is csak olvasható legyen! Értelemszerű tanács, mégis gyakori, hogy véletlenül írásra is meg vannak osztva olyan dokumentumok, állományok, amelyekhez másoknak csak olvasási hozzáférést szeretnénk adni.

•

A jogosultsági rendszer segítségével csak azoknak engedjünk hozzáférést, akinek tényleg kell! Gyakori, hogy az egyszerűség kedvéért nem törődnek a megosztás jogosultságaival. Ez hiba!

•

Ügyeljünk az alapértelmezett megosztásokra! A munkacsoport környezteben működő Windows XP létrehoz különböző „megosztott dokumentumok” nevű megosztásokat az egyes felhasználók számára, a könnyű dokumentumcsere érdekében. Ha erre nincs szükség, szüntessük meg!

A rendszerben érvényben lévő megosztásokat legegyszerűbben a parancssorból kiadott a net share paranccsal nézhetjük meg.

15. ábra: Megosztások megtekintése

A példában látszik, hogy a gépen a D:\Dokumentumok mappa Dokumentumok néven meg van osztva. A $ jelre végződő nevű rejtett megosztásokat a Windows adminisztrációs célból alkalmazza, csak adminisztrátori jogokkal lehet elérni. Fokozott biztonsági követelmények esetén megszüntethetőek, azonban bizonyos szolgáltatások és alkalmazások igényelhetik őket, tehát próbát kell tenni. Ügyeljünk a felhasználói fiókokra! A biztonságos működés alapfeltétele, hogy azonosítani tudjuk a rendszerhez hozzáférő felhasználókat. Az alkalmazott architektúrától függően a felhasználókat központilag vagy egyedileg kell nyilvántartani, de a megoldástól függetlenül fontos figyelembe venni néhány fontos pontot:

- 37 -



•

Ne legyenek közös felhasználók. Gyakori hiba, hogy az egyszerűség kedvéért csak egy felhasználót vesznek fel, akkor is, ha a rendszert többen használják. Mivel a Windows képes a felhasználók szerinti védelem megvalósításra és naplózásra, ezért mindenképpen külön felhasználói fiókot kapjon minden személy, aki jogosult a rendszert használni. Aki viszont nem jogosult, az ne kapjon semmilyen hozzáférést.

•

Csak annyi jogosultságot adjunk, amennyi feltétlenül szükséges. Különösen vonatkozik ez a „rendszergazda” jogosultságra. Bár gyakran egyszerűsíti bizonyos feladatok végrehajtását, ha egy felhasználó rendszergazda (azaz tagja a „rendszergazdák” csoportnak), ez azzal a veszéllyel jár, hogy véletlenül vagy kártékony kódon (trójai program) károkat okoz, mivel jogosultsága van megtenni olyan műveleteket, amelyekkel kárt okozhat.

•

Tiltsuk le a nem használt flhasználókat. Különösen vonatkozik ez a „vendég” és a „távoli segítségnyújtás” felhasználóra. Tekintsük át a rendszerben szereplő felhasználókat, és ha gyanúsat tapasztalunk, tiltsuk illetve szüntessük meg.

Az összes felhasználót megtekinthetjük és kezelhetjük a vezérlőpult felhasználói fiókok pontjának „speciális” gombját megnyomva.

16. ábra: Az felhasználók kezelése a helyi számítógépen

Megfelelő jelszavakat használjunk! A jelszavak kezelése az egyik legkritikusabb pont az informatikai rendszerek működtetésében. A jó jelszónak több, egymásnak ellentmondó követelményt kell kielégítenie: •

Legyen kellően bonyolult ahhoz, hogy találgatással vagy próbálgatással ne lehessen kitalálni. Bonyolult jelszó, az, amely kellően sok karakterből áll, nem értelmes szavakból áll, vegyesen tartalmaz betűket, számokat, írásjeleket.

- 38 -



•

Ne legyen túl bonyolult ahhoz, hogy a felhasználók ne tudják megjegyezni, mert ekkor fennáll annak az esélye, hogy leírják és a számítógép mellett tárolják.

•

Ugyanakkor a fontos jelszavakat (pl. rendszergazda) célszerű jól őrzött jelszófüzetben tárolni, mivel elfelejtésük komoly problémát okozhat. A jelszófüzethez való hozzáférést természetesen szabályozni kell.

•

A rendszer írja elő az időnkénti jelszócserét, de ne legyen túlzottan gyakori, mert ez arra ösztönzi a felhasználókat, hogy leírják, vagy szisztematikusan generálják (pl. ha havonta előírjuk a jelszó változtatását, akkor előbb-utóbb az adott hónap nevét fogják jelszóként használni, stb.)

•

Ha a kockázatelemzés során úgy véljük, hogy a kellő biztonságot csak túlzottan bonyolult jelszóval lehet elérni, akkor inkább fontoljuk meg más vagy kombinált megoldásokat, mint pl. jelszó és chip-kártya, vagy ujjlenyomatolvasó.

A Windows lehetőséget biztosít arra, hogy különböző jelszó kezelési rendeket alakítsunk ki. Az Active Directory vagy domain rendszerekben központilag kezelhető a jelszóházirend. Munkacsoport esetében az egyes munkaállomásokra külön kell beállítani a jelszó-házirendet, a Start/felügyeleti eszközök/Helyi biztonsági házirend programmal.

17. ábra: Jelszóházirend beállítása

A jelszóházirend kikényszeríti, hogy a felhasználók megfelelően erős jelszót használjanak. Az emberi tényező figyelembe vételével számíthatunk arra, hogy a felhasználók megpróbálnak minél egyszerűbb jelszavakat használni, mint pl. születési időpont, házastárs neve, egyszerű szavak. Léteznek különböző jelszó „törő” programok, amelyek segítségével a rendszergazda ellenőrizheti a jelszavak bonyolultságát. Egyik ilyen népszerű program a John The Ripper, amely szabadon letölthető a http://www.openwall.com/john/ címről. A program megpróbálja szótár és különböző kombinációk alapján megfejteni a jelszavakat. Ha sikerül, akkor valószínűleg a jelszó gyenge, és a felhasználó utasítható a jelszó cseréjét. Ügyeljünk a biztonsági mentésekre! A biztonsági mentés kérdése természetesen nem Windows specifikus, de nem lehet elégszer hangsúlyozni! Központosított felügyelet esetén „illik” a mentést is

- 39 -



központosítva megoldani. Gyakori módszer az, hogy a dolgozók a központi állomány-kiszolgálón tartják a dokumentumokat és csak a szerver kerül mentésre. Erre jól használható a Windows 2000 és XP „kapcsolatnélküli állományok” szolgáltatása. Ennek engedélyezésekor az állománykiszolgálón lévő fájloknak helyi másolata keletkezik, amely a hálózati kapcsolat megszakadásakor is rendelkezésre áll, majd a kapcsolat helyreállásakor szinkronizálás történik.

18. ábra: Kapcsolat nélküli fájlok engedélyezése

A kapcsolat nélküli állományok különösen alkalmasak csak időlegesen kapcsolatban lévő eszközöknél, mint pl. laptopok. Természetesen nem helyettesíti a biztonsági mentést, de a megkönnyíti a központi mentést. A központosított mentési megoldások befektetés igényesek, ezért a legtöbb kisközepes irodai környezetben nem alkalmazzák, az egyes számítógépek mentése egyedileg történik (történne). Hogyan lehet ezt megoldani, lehetőség szerint egyszerű, mégis megbízható és olcsó módon? •

Kismennyiségű adatokat legegyszerűbben optikai adathordozóra menthetünk (CD, DVD). Az CD/DVD írók és a nyersanyag ára drámaian zuhant az utóbbi években, így talán ez az egyik legköltség-hatékonyabb eljárás. A Windows XP képes külön segédprogram nélkül is CD/DVD írásra, ha a meghajtó tulajdonságai között engedélyezzük az írást. Ekkor egyszerűen a meghajtóra másolunk állományokat, a Windows jelzi, hogy kész az állományok kiírására, amelyet ha engedélyezünk, megtörténik az írás.

- 40 -



19. ábra: CD írás engedélyezése

Természetesen valamely CD író programmal (pl. Nero, Easy CD creator, stb.) sokkal kifinomultabban tudunk írást végezni, pl. elmenthetjük az írandó állományok listáját, így később gombnyomásra egész könyvtárakat menthetünk. A CD-re, DVD-re történő mentés egyetlen hátránya az adathordozó mérete. Egy CD 650-750megabájt, egy DVD 4,5-9 gigabájt mennyiségű információt tud eltárolni. Szöveges dokumentumokból ez hatalmas mennyiség, de pl. fénykép, stb. jellegű állományokhoz kevés lehet, figyelembe véve, hogy már 200-300 gigabájtos merevlemezek kaphatóak kereskedelmi forgalomban. •

A mentés során felhasználhatjuk a hálózatot, szélessávú kapcsolat esetében egész nagy mennyiségű adatot lehet egészen messzi helyszínen lévő számítógépekre átmásolni.

•

A nagyméretű meghajtókat is felhasználhatjuk mentésre. Egy külső, USB diszk ház segítségével a mentés idejére a számítógéphez csatlakoztathatunk egy nagyméretű lemezegységet, és egyszerűen átmásoljuk rá az állományokat. A mentés végeztével a lemez biztonságos helyen elhelyezhető.

•

Kevesebb mennyiségű adat esetén szintén használhatóak az USB Flash meghajtók. Ezek maximális kapacitása jelenleg néhány gigabájt. A Windows 2000 és az XP külön szoftver telepítése nélkül támogatja az USB lemezegységeket.

- 41 -



20. ábra: USB lemezegység és USB Flash meghajtó

•

Igen nagy mennyiségű adat mentésére szalagos egységeket használnak, ezek rendszerint nagy beruházást, professzionális mentő szoftvereket és professzionális rendszerintegrációs feladatot igényelnek, azonban igen nagy hatékonyságúak és megbízhatóságúak.

•

Kisebb igényekre megfelel a Windows saját mentő szoftvere is, amely a Start/programok/kellékek/rendszereszközök/biztonsági másolat menüpontból érhető el. A program lehetővé teszi különböző mentő eszköz használatát, időzített és inkrementális (csak az utolsó mentés óta változott adatok mentése) mentést. Mindazonáltal kis irodai környezetben elegendőek az egyszerűbb megoldások is.

Használjunk házirendeket! A Windows igen sok biztonsági paramétere módosítható a házirendek segítségével. Ezek teljes felsorolása itt nem lehetséges, de számtalan beállítást lehet a rendszerre (és a felhasználókra) kényszeríteni. A biztonsági házirendet a Start/Felügyeleti eszközök/Helyi biztonsági házirend program segítségével lehet beállítani a munkaállomásokon. Active Directory vagy domain esetében a tartományvezérlőn kell a poledit programmal szerkeszteni.

21. ábra: Házirendek kezelése

- 42 -



Megfelelően állítsuk be a jogosultságokat! A Windows igen kifinomult jogosultsági rendszerrel rendelkezik. A különböző rendszer erőforrásokra hozzáférési listákat lehet definiálni. Ezt elsősorban az állományokra és megosztásokra lehet jól alkalmazni. A hozzáférési lista során felhasználónként, csoportonként tudjuk definiálni a lehetséges műveleteket, külön a művelet engedélyezését és tiltását. Ennek segítségével összetett módon lehet jogosultságokat kiosztani. Tipikus alkalmazása a különböző felhasználókhoz (pl. projekt csoport tagok) tartozó dokumentumok védése úgy, hogy mindenki csak ahhoz fér hozzá, amelyhez valóban szükséges. Mappákra és állományokra a tulajdonságok „biztonság” fülét választva tudjuk szabályozni a hozzáférést. Természetesen ez csak NTFS fájlrendszer esetében működik.

22. ábra: Mappa biztonsági beállításai

Használjuk a naplózást! A naplózás célja a rendszerben történő események feljegyzése. Rendszeresen tekintsük át az eseménynaplót, gyanús jelek után kutatva. Az eseménynapló a Vezérlőpult / Teljesítmény és karbantartás / Felügyeleti eszközök / Számítógépkezelés pontban található. A naplózásnál fontos, hogy ne vesszen el naplózási információ. Kritikus rendszereknél be kell állítani, hogy a maximális napló állomány méret elérésekor a rendszer riasztást adjon, vagy leálljon. A napló állományokat is menteni kell, a rendszeres mentés során, illetve külön mentési szabályokat kell hozni a naplók mentésére és hosszútávú tárolására. Ellenőrizzük a rendszer biztonsági beállításait! A számítógép és a szoftver megfelelő beállításait ellenőrizni kell, méghozzá nem csak egyszer, a telepítés után, hanem folyamatosan, időről időre. Az alapvető biztonsági beállítások vizsgálatára különböző eszközök léteznek. Ezek közül az egyik, amely kifejezetten Windowshoz lett kifejlesztve, és szabadon hozzáférhető,

- 43 -



a Microsoft Baseline Security Analyser (MBSA, Microsoft Biztonsági Alapbeállítás Ellenőrző). Az eszköz letölthető a www.microsoft.com/technet/security/tools/mbsahome.mspx oldalról. Jelenleg az MBSA nem érhető el magyarul, angol, német, francia és japán változata van, de természetesen használható magyar nyelvű Windows rendszerek elemzéséhez. Az MBSA használatához keressük fel a fenti oldalt, töltsük le és telepítsük a szoftvert.

23. ábra: Az MBSA honlapja

A program indítása után magától letölti a legújabb megvizsgálandó adatokat, így az elemzés naprakész lesz a sérülékenységek tekintetében. Ennek megfelelően célszerű időközönként, illetve nagyobb konfiguráció változtatások után az MBSAt újra lefuttatni. A vizsgálat során lehet egy vagy több számítógépet kiválasztani célpontnak. Több gép választása esetén meg kell adni az IP cím tartományt, amelyet át kívánunk vizsgálni. Így például megadható a teljes irodai címtartomány, az összes számítógép elemzéséhez.

- 44 -



24. ábra: Célpontválasztás

A célpont kiválasztása után elindítható az elemzés, amely a célpontok számától függően eltart egy ideig. Az elemzés végén megtekinthető az elemzés eredménye. Az egyes vizsgált pontoknál megjelenik az adott sérülékenység meglétét jelző összefoglalás, illetve lekérdezhető a részletes eredmény, valamint a kijavításra javasolt tennivalók.

25. ábra: MBSA eredmények

- 45 -



A MBSA nem csak az operációs rendszer beállításait vizsgálja, de egyéb Microsoft termékek, mint pl. Office vagy SQL Server egyes sérülékenységeit is figyeli. A lenti példa mutatja a biztonsági frissítések hiányáról szóló részletezést, amely egyes Office komponensek frissítésének hiányát jelzik.

26. ábra: Sérülékenység részletezése

Természetesen a MBSA által adott eredményeket össze kell vetni a rendszer számára megkívánt feltételekkel, így ha sérülékenységet jelez, az nem jelent feltétlenül hibát, hiszen lehet olyan indok, amely miatt az adott beállítás helyes, de mégis hibának érzékeli a vizsgálat. Ugyanez fordítva is igaz, az, hogy nem jelez hibát a MBSA, a rendszer még nem feltétlenül biztonságos, csak a vizsgált sérülékenységek vannak kiküszöbölve.

4.8.2

Linux

A Linux, mint szabad forráskódú operációs rendszer, egyre gyakrabban fordul elő nem csak kiszolgálói szerepben, de asztali számítógép operációs rendszereként is, mivel beszerzési költsége alacsony (sok változat ingyen letölthető), ugyanakkor eléggé fejlett ahhoz, hogy a célnak megfeleljen. Irodai környezetben a Microsoft Windows rendszerek szinte egyed-uralkodóak voltak, viszont a Linux, mint a Unix operációs rendszerek egyik leszármazottja, alapvetően más elveken működik, főleg a biztonság tekintetében. Ezért célszerű a Linux biztonsági kérdéseit a Windows-hoz képesti összehasonlítással megközelíteni. Szem előtt

- 46 -



tarjuk azonban azt, hogy Linux rendszerek jelenleg inkább kiszolgálói feladatkörökben szerepelnek, mint asztali rendszerként, ezért a következőkben nagyobb hangsúlyt helyezünk az ilyen jellegű felhasználásnál szükséges beállításokra. A Linuxból különböző ú.n. disztribúciók léteznek, ezért ez egyes rendszerek között, bár alapvető felépítésben azonosak, sok apró eltérés lehetséges. 4.8.2.1 A Linux egy Windows-felhasználó szemével Az alábbiakban megpróbálunk gyengéd bevezetést adni a Linux világába azok számára, akik a Windows rendszerek felhasználásában, esetleg alapfokú adminisztrációjában már jártasságra tettek szert. Az alábbi szakaszokban elsőként egy-két fontos alapfogalom magyarázata következik, majd a két rendszer legfontosabb különbségeire és hasonlóságaira világítunk rá, végül áttekintését adjuk a Linux rendszer alapkomponenseinek.

Alapfogalmak A Windows világában kevéssé használatos fogalmak alábbi definíciói nem tekinthetők teljes értékűnek, a célunk inkább a figyelem felhívása a legfontosabb aspektusokra, mintsem a pontos lexikális meghatározás. •

Nyílt forráskód (open source): a GNU/Linux rendszerek egyik legkarakterisztikusabb jellemzője, hogy a rendszert alkotó szoftverek nem csak gépi kódban futtatható, ún. bináris formátumban állnak a felhasználók rendelkezésére, hanem az ebben a környezetben általánosan használatos GPL licencelés által kötelezően előírtaknak megfelelően a forráskódok is nyilvánosan elérhetők és bárki által módosíthatók. A nyílt forráskódú fejlesztési modell általában együtt jár szabad, internetes fejlesztői közösségek létrejöttével, vagyis a szoftverek mögött általában nem cégek, hanem ad hoc csoportok, ritkábban pedig nonprofit alapítványok, vagy egyes esetekben a Linuxot támogató és felhasználó vállalatok állnak. A fentiek számos különbséget eredményeznek a nyílt forrású kódokból épülő rendszerek és a Windowshoz hasonló üzleti szoftverek között, ezek értékelése azonban nem képezi jelen ismertetőnk témáját.

•

Rendszermag (kernel): a Linux szó szoros értelemben véve nem takar

mást, mint a fizikai hardver és az operációs rendszer közti alapvető összekötőkapocsként is felfogható, a mai napig eredeti programozója, Linus Torvalds által karbantartott alapszoftvert, a rendszermagot, más szóval kernelt. A Linux szó a mai közhasználatban azonban általában a Linux kernelre épülő operációs rendszert, sőt, nem egy esetben az operációs rendszerben futtatható felhasználói alkalmazások összességét is jelentheti, ezért az eredetileg Linuxnak nevezett rendszermagra mégis inkább a kernel szó használatos. A Linux kernel felépítését tekintve ún. monolitikus, amely azt jelenti, hogy a kernel alapvető funkciói, mint processzkezelés, memória-management, és a hardveres eszközöket működtető vezérlőmodulok (driverek) egy összefüggő, közös tárterültetet használó kódbázisként jelennek meg a rendszerben. A monolitikus

- 47 -



felépítés előnye a kernel részegységei közti adatcsere egyszerűsége, gyorsasága, hátránya azonban a variálhatóság csökkenése, melyre a modern Linux kernelek LKM (loadable kernel module, vagyis betölthető kernelmodul) támogatása nyújtott részleges megoldást, ezzel lehetővé téve az egyes részegységek futásidejű betöltését és eltávolítását. Az LKMtámogatás előtti időkben a nyílt forráskódú kernel egyes hardveres konfigurációkhoz illeszkedő testreszabása és lefordítása jelentette a kezdő felhasználók számára az egyik legnagyobb akadályt. A kernel fejlesztése – a korábbi verziók folyamatos követő karbantartásától eltekintve – alapvetően két párhuzamos szálon folyik: a széleskörű felhasználásra szánt „stabil” kernelverziók második számjegye páros (pl. 2.6.3), a friss, és emiatt esetlegesen „instabil” megoldásokat tartalmazó verziók második számjegye pedig páratlan (pl. 2.5.3). •

Disztribúció: a kernel szó pontosított értelmezése alapján már látható,

•

Csomag (package): a disztribúciókat alkotó szoftverek telepítését általában, de nem minden esetben a disztribúcióra jellemző ún. csomagkezelő alrendszer végzi. A csomagkezelő a telepítésre kiválasztott komponenseket, a szoftverek futtatható állományait, adatfájljait és konfigurációs állományait, valamint az ezeknek a rendszerbe történő beillesztését vagy az onnan való eltávolítását elősegítő információk együttesét az ezeket tartalmazó ún. csomagokból nyeri ki. A csomag szó ilyen értelmezése nem tér el jelentősen a más rendszerekben hasonló kifejezéssel jellemzett, általában tömörített és kötegelt fájltárolási módszert takaró „archív” fogalmától, egyszerűsítve egy megszabott könyvtárstruktúrát és metaadatokat tartalmazó, például zip formátumú fájlként is gondolhatunk rá. A legelterjedtebb disztribúciókban a csomagok meta-információként tartalmazzák azoknak a csomagoknak vagy

hogy a közhasználatban csak „Linux”-ként nevezett rendszer valójában egy nehezen definiálható szoftverhalmaz leírására szolgál. A Linux rendszereket alkotó, többé-kevésbé együttműködő szoftverek egy csoportosítását „terjesztésnek”, vagyis disztribúcióknak nevezik. Az egyes disztribúciók mögött a nyílt forráskódnál leírtakhoz hasonlóan nonprofit közösségek (pl. Debian, Gentoo, Slackware, Ubuntu), más esetekben pedig vállalati szolgáltatásokat és zárt kódú szoftvereket is forgalmazó cégek (Redhat, Novell) állnak. A Linux disztribúciókat általában verziószámokkal is jellemzik, ez azonban nem jelent többet, mint a komponensként felhasznált szoftverek bizonyos verziószámainak halmazát, valamint az ezeket összefogó disztribúciós rendszer, mint például a telepítőszoftver, kernelkiegészítések és egyéb segédprogramok megadott verzióit, tehát a Mandrake 15.2-es Linux disztribúció például tartalmazhatja pontosan ugyanazt a verziójú rendszermagot, mint a Redhat 11-es verziója, még akkor is, ha megjelenésük közt több hónap is eltelt, hisz a különböző disztribútorok más-más stratégiával végzik a kiadást. Szokás még „stabil” és „instabil” disztribúciókról beszélni a kernel fejlesztésénél leírtakhoz hasonlóan, azonban a verziószámozás itt már nem tartalmaz erre vonatkozó információt, disztribúciónként más-más logikával találkozhatunk.

- 48 -



alternatíváiknak verziószám-feltételekkel kiegészített listáját is, melyek az adott csomag által tartalmazott szoftver sikeres futtatásához, vagy egyes szolgáltatásainak igénybevételéhez szükségesek. Így a csomagkezelőkre épülő csomagkönyvtár-kezelő szoftverek képessé válnak a függőségek kielégítésére vagy az esetleges ütközések feloldására is, mely jelentősen egyszerűsíti a telepítési folyamatot és végső soron a rendszer karbantartását. •

X: A Linux nem grafikus operációs rendszer. A grafikai funkciók ugyanolyan szoftverként telepíthetők a rendszerbe, mint bármely más alkalmazás. A legelterjedtebben használt grafikai alkalmazás az eredetileg nem (vagy nem a jelenlegi értelmében) nyílt forráskódú X Window System koncepcióit követi, ilyen szoftver az XFree86 és az ebből – licencelési okokból – kiágazó fejlesztésű (ún. „forkolt”) X.org, mindkettőre röviden az „X” kifejezés használatos. Az X a Linux kernel funkcióira építve grafikus felületet, valamint felhasználói interfészkezelési (egér, billentyűzet, stb...) szolgáltatásokat nyújt a Linux rendszerben futó programok számára. Fontos koncepcionális jellemző, hogy az X ezt a szolgáltatást akár távolról, TCP/IP protokollon keresztül is nyújtani képes, vagyis megoldható az, hogy az egyik számítógépen futó X-kiszolgáló a másik számítógépen futó program képét jeleníti meg, illetve ennek a programnak nyújt felhasználói interfészkezelési szolgáltatásokat. Ezzel a megoldással elérhető az, hogy egy nagyobb teljesítményű gép több grafikus programot futtasson, melyeknek megjelenítését és felhasználói interakcióját több különálló Xkiszolgáló (X server) szolgáltatja. Ez gyakorlatilag azt jelenti, hogy egy (akár monitor nélkül üzemelő) központi szervergéphez több grafikus felhasználói terminál is kapcsolódhat, melyekre természetes reakcióként használhatjuk a „grafikus kliens” szót, azonban az X-architektúra szemszögéből mégis ezek a gépek lesznek az „X-szerverek”, célszerű ezzel a látszólagos fogalmi ellentmondással tisztában lennünk. A mindennapokban a grafikus funkciókkal teletűzdelt Linux disztribúciók is az X rendszert használják grafikus megjelenítésre, egy számítógépen futtatva a grafikus alkalmazásokat és az X-szervert is.

•

Ablakkezelő (window manager, wm): az X-szerver önmagában nem nyújt

más grafikus operációs rendszerekhez hasonló felhasználói felületet, ezek a Linux rendszerben maguk is önálló alkalmazásokként, vagy ezek együttműködő csoportjaként jelennek meg. A grafikus felhasználói felület egyik alapfunkciója az ablakkezelés, vagyis az egyes grafikai alkalmazások keretbe foglalása, elhelyezési, átfedési, átméretezési lehetőségek nyújtása a felhasználó számára. Már sejthető, hogy ezt a feladatot látja el az ún. ablakkezelő alkalmazás. További fogalmak külön-külön történő definícióját kerülve elmondjuk, hogy az ablakkezelés mellett alapvető komponensek még a tipikus grafikai elemek (gombok, legördülő listák, stb...) gyűjteményei, az ún. widgetek, valamint a grafikai kezelőeszközök (panel, feladatkezelő, „Start” menü, stb...), melyek szintén külön-külön alkalmazásokként, vagy függvénykönyvtárakként telepíthetők. Az ablakkezelők, widget-könyvtárak és egyéb grafikai eszközök széles palettája áll a Linux-felhasználók rendelkezésére, azonban ki kell - 49 -



emelnünk két komplex megoldást, a KDE és a Gnome környezetet, melyek széles körűen elterjedtek, saját fejlesztői környezettel, (Gnome esetén választható) ablakkezelővel, widgetekkel és rendszeralkalmazásokkal (panel, vezérlőpult, intéző, böngésző, konzol, stb...) rendelkeznek. A két rendszer közti átjárhatóság a fenti strukturáltság tükrében már látható: nincs másra szükség, csak arra, hogy a megfelelő komponensek az alkalmazások rendelkezésére álljanak.

Különbségek Az alábbiakban Linux és Windows rendszerek közti legfontosabb technikai különbségeket tekintjük át. Az alapfogalmak definícióinál leírtakhoz hasonlóan itt sem a végletekig menő pontosság, hanem inkább a biztonsági szempontból, vagy a rendszer működésének megértése érdekében alapvető fontosságú jellegzetességek kidomborítása tekinthető célunknak. VFS

A DOS rendszerben megszokott fájlrendszer logikáját követő Windowsfelhasználó számára talán az első és legfontosabb szokatlan dolog a Linux strukturált fájlrendszerében rejlik. A megszokott betűjelekkel megkülönböztetett logikai és fizikai meghajtók és a rajtuk található, általában lazának tekinthető fájlstruktúra helyett a Linux rendszerben egy logikai meghajtó, az ún. VFS (Virtual File System – virtuális fájlrendszer) található, mely egy előre pontosan meghatározott könyvtárszerkezetnek ad otthont. Erre a virtuális fájlrendszerre, pontosabban ennek egyes könyvtáraiba csatlakoztathatók („mountolhatók”) a rendszer fizikai és logikai meghajtói, emiatt természetesen a fájlrendszer különböző pontjain más más lehet a rendelkezésre álló szabad lemezterület, mely biztonsági szempontból hasznos lehet, ha a rendszer egyes, nagyobb tárterületet is felemészteni képes funkcióit nehezebben kordában tartható felhasználók számára szeretnénk elérhetővé tenni. Az alábbiakban tekintsük át a VFS alapvető szerkezetét: •

/: a VFS gyökerének megnevezésére használatos, a „legfelsőbb” könyvtár, melyet más néven gyökérnek, vagy angol szakkifejezéssel root könyvtárnak is szoktak nevezni. A root könyvtár a hasonló elnevezés ellenére nem keverendő össze a későbbiekben ismertetésre kerülő root felhasználóval.

•

/home: a rendszer felhasználói számára fenntartott személyes (ún. home) könyvtárakat tartalmazza. Egyes rendszereken előfordul, hogy a felhasználók nagy száma miatt még valamiféle, például a felhasználók csoportjai, vagy nevük kezdőbetűje szerinti alábontással is találkozhatunk ezen a helyen. A rendszerbe más nevében jogosulatlanul belépő felhasználók kezdetben itt juthatnak fontos információkhoz, például a kompromittált felhasználói elérés naplófájljai alapján következtethetnek egyes szolgáltatások meglétére.

- 50 -



•

/root: az előzőekben már megemlített, speciális szerepű root felhasználó home könyvtárának helye.

•

/boot: a rendszerindítás kezdete során felhasznált fájlok, például a rendszermag lelőhelye.

•

/tmp: átmeneti fájlok tárolására használt terület. Biztonsági szempontból fontos szem előtt tartani, mert erre a területre a rendszer összes felhasználója helyezhet el állományokat, ezért érdemes lehet helykorlátozási lehetősséggel élni ezen a helyen, valamint figyelmet kell fordítani a könyvtár szokásostól eltérő tartalmára is, mert egy betörés korai jeleire is akadhatunk itt.

•

/var: ide kerülnek azok az állományok, melyek gyakran változnak, például itt találhatók a különböző általános célú adatbázisok, a rendszer naplófájljai, a futó programok futásidejű információit tároló jelzőfájlok. A könyvtár mérete rendeltetéséből adódóan nagyon dinamikusan változhat.

•

/etc: a rendszer biztonsági szempontból talán legérdekesebb könyvtára, melyben a telepített alkalmazások globális, alapértelmezett konfigurációi, valamint az operációs rendszer beállításai találhatók. A Windowsfelhasználók számára hasznos lehet az /etc könyvtárra egyfajta registryként, vagy .ini fájlok gyűjteményeként tekinteni.

•

/bin: az operációs rendszer alapját képző bináris állományok gyűjtőhelye. Itt kapnak helyet az alapparancsok, mint a könyvtárlistázást, másolást, stb. végző programok, a felhasználói parancsértelmezést végző ún. shellek és egyéb fontos segédprogramok. Egy rendszer feltörésének során gyakran cserélik le ezeket a fontos komponenseket, ezért érdemes a könyvtár tartalmát figyelemmel kísérni. A könyvtár szerepét tekintve hasonlít a c:\windows könyvtárhoz a windowsos gépeken.

•

/sbin: annyiban különbözik a /bin könyvtártól, hogy itt azok a binárisok kapnak helyet, melyek használatát kimondottan a rendszergazda számára tartják fenn. A felhasználók alapértelmezett elérési útvonalában („path”) általában nincs benne ez a könyvtár. Szintén gyakran cserélnek le itt is fájlokat a rosszindulatú behatolók. Talán ez a könyvtár áll legközelebb a c:\windows\system* könyvtárak szerepéhez.

•

/lib: a rendszer alapkomponenseihez tartozó osztott függvénykönyvtárak, Windows-terminológia szerint jó közelítéssel a .dll-ek (Linux rendszerekben általában .so fájlok) gyűjtőhelyeként lehet rá tekinteni. Szintén gyakran cserélnek le itt is fájlokat egy behatolás esetén.

•

/usr, /usr/local, /opt: felépítésüket tekintve ezek a könyvtárak hasonlítanak a root fájlrendszerre, vagyis megtalálható bennük általában legalább a /bin és a /lib alkönyvtár. Ezekre a helyekre telepítendők általában a felhasználói programok, vagyis szerepét tekintve leginkább a windowsos Program Files könyvtár áll hozzájuk közel. A /usr/local könyvtár jelentősége, hogy a rendszer csomagkezelője által nem támogatott, másként („kézzel”) telepített programokat ide célszerű

- 51 -



elhelyezni, így elkerülhető a kézi telepítés és a csomagkezelő rendszer ütközése. •

/usr/share: itt találhatók a rendszer megosztott erőforrásai, vagyis például a betűtípusok, ikonok, a telepített programok dokumentációi és egyéb statikus adatbázisok. Mivel a rendszerben itt található a legtöbb különböző fajta fájl, a rosszindulatú támadók gyakran próbálnak ide saját célú fájlokat elrejteni.

•

/mnt: a VFS-be ideiglenesen csatlakoztatott kötetek, pl. floppy, CD-ROM, távoli Windows-megosztások, stb. kerülnek általában ide.

•

/dev: ez a könyvtár meglehetős fejtörést okozhat egy Windows-felhasználó számára, különösen, ha egyes példaparancsokban találkozik a benne található, látszólag mindig 0 byte méretű fájlokra vonatkozó utalásokkal. A Linux rendszerben a kernel eszközmeghajtóinak nagy részét és a rendszer egyes egyéb szolgáltatásait speciális fájlokon keresztül lehet elérni. Alapvetően két speciális fájl létezik, az egyik csoport a „blokkspeciális”, mely kezelését tekintve leginkább egy virtuális fájlhoz hasonlít, ilyen fájlok kapcsolódnak például a rendszerbe csatlakoztatott merevlemezekhez és azok partícióihoz (pl. a /dev/hda2 a rendszer elsődleges IDE merevlemezének második partíciója), a másik csoport a „karakter-speciális” fájloké, melyek csak folyamszerűen írhatók és olvashatók, vagyis egyszerűen fogalmazva nem lehet bennük visszatekerni, ilyen fájl csatlakozik például a karakteres terminálhoz, vagy ilyen az univerzális nyelő, mely minden adatot eldob, amit beleírnak. Ez utóbbi fájl, vagyis a /dev/null linuxos szakmai berkekben egyfajta kifejezéssé nőtte ki magát, a szemétkosár szinonimájaként is használatos. A /dev könyvtár speciális szerepe miatt a rendszer alapvető erőforrásaihoz történő felhasználói hozzáférés biztonsági szabályozására kitűnően alkalmas.

•

/proc, /sys: szintén speciális könyvtárakról van szó. A bennük található fájlokból a kernel futásidejű információi olvashatók ki, egyes esetekben pedig futásidejű paraméterállításra is ezeken a fájlokon keresztül nyílik lehetőség. A /proc könyvtárban találhatók például a futó processzek azonosítói alapján elnevezett alkönyvtárakban a kernel által az adott processzről nyilvántartott publikus információk, mint például az erőforrásfoglalás mértéke, vagy az aktuális munkakönyvtár. Mindkét könyvtár védelme célszerű lehet az általuk nyújtott kényes információk miatt.

Fontos még megjegyezni, hogy a VFS a könyvtár-, fájl- és speciális fájlbejegyzések mellett támogatja a szimbolikus linkek létrehozását, melyek egyfajta mutatóként viselkednek, a rájuk történő hivatkozás valójában az általuk mutatott VFS bejegyzésre lesz érvényes. A szimbolikus linkek mellett ún. „hard” linkek is létrehozhatók, melyek egy fájlrendszeren belül a standard fájlok teljesértékű alternatív neveiként szolgálhatnak. A link típusú bejegyzéseken kívül találkozhatunk még a rendszer processzei közti kommunikációt elősegítő nevesített kommunikációs csatornákat jelző speciális fájlokkal (ún. named pipe

- 52 -



és named socket) is, ezek felhasználási lehetőségei azonban nem képezik jelen dokumentum tárgyát. Jogosultságkezelés

A Linux jogosultságkezelése lehetőségeit és adminisztrációját tekintve a DOS alapú Windows rendszerekét messze felül-, az újabb, NT technológiára épülő Windows rendszerekét pedig messze alulmúlja. A rendszerben minden folyamat (processz) egy felhasználóhoz kerül hozzárendelésre, minden felhasználót egy egész szám, az úgy nevezett UID (User ID) azonosít. A felhasználók csoportokba rendezhetők, minden felhasználónak kötelező egy elsődleges csoportba tartoznia, valamint szinte tetszőleges mennyiségű kiegészítő csoportba is bekerülhet. A csoportokat szintén egész számokkal, ún. GID (Group ID) számmal jelölik. A rendszerben két kiemelt UID létezik, az egyik a rendszergazdát, másnéven root felhasználót azonosító 0 sorszámú, a másik pedig a 65535 sorszámú, minden jogától megfosztott, ún. nobody („senki”) felhasználót azonosítja. Ez a két sorszám a GID-ek körében is hasonló névvel és tartalommal került ellátásra, azonban ezek nem olyan fokon jelentősek, például a root GID önmagában még nem jelent adminisztrátori jogkört, ehhez ugyanis az UID-nek is megfelelőnek kell lennie. Fontos megjegyezni, hogy nem a név, hanem az UID számít, vagyis ha több felhasználót is 0-s UID-del látunk el, mindannyian egyenjogúak lesznek a root felhasználóval. A root gyakorlatilag a rendszer teljes ura, minden fájlhoz hozzáférhet, minden műveletet végrehajthat, ráadásul ebben semmilyen standard módon nem korlátozható. Sajnos sok alkalmazás igényel különböző okokból olyan jogosultságokat, melyeket csak 0 UID-del lehet elérni, és még mindig nem teljes körben elterjedt gyakorlat, hogy az ilyen feladatokat leválasztják az alkalmazás egyéb fukcióiról, hogy az egyéb funkciók végrehajtására egy alacsonyabb privilégiumszinten, vagyis egy más felhasználó nevében kerüljön sor. A leírtak miatt egy általános Linux rendszerben rengeteg root jogosultságú processz fut folyamatosan, melyek védelme gyakorlatilag első számú prioritás egy biztonsági szempontból tudatos rendszertulajdonos számára. A root felhasználó szerepét részletező kitérő után visszatérünk a jogosultságrendszer bemutatására. A különböző felhasználóiés csoportazonosítókhoz rendelt processzek és a VFS közti kapcsolatot az teremti meg, hogy minden VFS-bejegyzés szintén egy UID/GID-pároshoz került hozzárendelésre, itt sajnos azonban már nem engedélyezett a több csoportba való tartozás. Az adott processz és adott VFS-bejegyzés közt fennálló jogkört ezek után egy háromszintű jelzésrendszer adja meg úgy, hogy a bejegyzés három különböző szinten három különböző jogosultságot ad meg saját elérési feltételeként. A három alapvető jogosultsági szint a következő: •

U (User): a fájlhoz rendelt UID-del azonos felhasználói azonosítójú processzre vonatkozó jogok.

- 53 -



•

G (Group): a fájlhoz rendelt GID-del azonos csoportazonosítójú processzre vonaktozó jogok. Itt a rendszer figyelembe veszi a processz elsődleges és kiegészítő csoportjait is.

•

(Others): a rendszer összes processzére vonatkozó jogosultságok.

A három alapvető jogosultság pedig: •

R (Read): olvasási jog. Standard, és speciális fájlok esetén a fájl tartalmának, könyvtárak esetén pedig a könyvtárlista olvasásának joga.

•

W (Write): írási jog. Fájlok esetén a fájl tartalmának felülírását és a fájl bővítését teszi lehetővé, könyvtárak esetén pedig a könyvtár tartalmának módosítására ad lehetőséget.

•

X (eXecute): futtatási jog. Fájlok esetén a fájl indítható állományként történő futtatását teszi lehetővé (Linuxban nincs jelentősége a fájl kiterjesztésének), könyvtárak esetén a könyvtárba való belépést engedélyezi, mely a legtöbb művelethez (például új fájl vagy alkönyvtár létrehozása!) szükséges.

A Windows-felhasználókat gyakorta megzavaró jelenség lehet az, ha egy fájlra érvényes írási joggal rendelkező processz nem képes a fájlt törölni, majd például újra létrehozni, mert az azt tartalmazó könyvtárra nem rendelkezik írási joggal, a fájl tartalma azonban ilyenkor is nullázható. A fenti leírt háromszor három jogosultságot bináris jelzőbitként felfogva gyakorta ábrázolják 0 prefix jelölésű oktális (nyolcas számrendszerbeli) alakban, ahol a számjegyek pont a különböző szintekhez tartozó jogosultságokat jelenítik meg, vagyis például a 0754 oktális szám jelentése: R,W,X jog a tulajdonosnak, R,X jog a csoportnak és R jog mindenkinek. Az UGO, RWX alapjogosultság-rendszert még további három, a VFS bejegyzéseihez rendelhető, minden processzre érvényes jogosultság egészíti ki, ezek: •

SUID (Set UID): csak érvényes X jog mellett értelmes. Fájlok esetén a fájl futtatását kezdeményező processz érvényes UID-jétől függetlenül a futtatás során létrejövő új processz a fájlhoz rendelt UID értékét örökli. Könyvtárak esetén a könyvtárban létrehozott új bejegyzések UID-értéke meg fog egyezni a könyvtárhoz rendelt UID-értékkel.

•

SGID (Set GID): szintén csak érvényes X jog mellett értelmes. A SUID jogosultsághoz hasonlóan működik, csak a GID vonatkozásában.

•

T (sTicky): fájlok tekintetében ma már nincs gyakorlati jelentősége, könyvtárak esetén a processzek csak azokat a bejegyzéseket módosíthatják, melyek UID-értéke azonos a műveletet végrehajtani kívánó processzével.

Biztonsági szempontból talán az egyik legfontosabb jogosultság a SUID, melyet gyakran egyszerűen kisbetűvel suid-ként írnak. Látható, hogy egy root tulajdonában levő suid bináris futtatásával bármelyik felhasználó a root jogkörébe kerül a futtatás idejére, vagyis egy potenciális privilégiumszintnövelési lehetőségről van szó. Emiatt a suid binárisok kezelése különleges - 54 -



figyelmet igényel minden Linux rendszerben: fontos, hogy számuk minimális legyen és maguk az alkalmazások pedig lehetőleg minden kihasználható hibától mentesek legyenek, mivel egy suid program futásának belső hiba miatti váratlan megszakadása a futtató felhasználót a processz jogaihoz juttatja (ezt használja ki például a legtöbb helyi futtatásra tervezett puffer-túlcsordulási hibát kihasználó rosszindulatú segédprogram). Látható, hogy a vázolt jogosultságbeállítási lehetőségekkel bonyolultabb helyzetek már nagyon nehezen kezelhetők, mert a VFS-bejegyzésekhez rendelhető három jogosultsági szint meglehetősen szegényes, ráadásul hiányzik a jogosultságok automatikus öröklődésének lehetősége is. A problémát megoldandó elterjedőben van az ún. POSIX ACL rendszer, melyhez azonban jelen írásunk idején még a legtöbb alkalmazás nem alkalmazkodott megfelelően. Csomagkezelés

Az alapfogalmak közt már szó esett róla, de fontosnak tartjuk külön kiemelni, hogy a Linux disztribúciók jellemzően csomaggyűjteményekre (package repository) épülnek, melyek az Interneten keresztül általában közvetlenül az operációs rendszerből elérhetőek. Ezen gyűjtemények nem csak szigorúan véve az operációs rendszert tartalmazzák, hanem a legtöbb esetben minden olyan szoftvert is, melyek a megfelelő licenszfeltételek mellett elérhetőek az adott disztribúcióban, így gyakran találkozhatunk olyan Linuxot futtató számítógéppel, melyen egyetlen más forrásból telepített alkalmazás sincsen. A rendszer előnye az egységes telepítési felület is, azonban legfontosabb az, hogy a szoftverek biztonsági frissítéseire is ezen a módon nyújt lehetőséget. Ám ezzel a lehetőséggel élni is kell. Parancssor-orientáltság

A modern grafikus operációs rendszerekkel ellentétben a Linux továbbra is megőrizte parancssor-orientáltságát, vagyis a legtöbb rendszerközeli funkció csak karakteres terminálon kiadott parancsok kiadásával, vagy szöveges konfigurációs állományok szerkesztésével érhető el. Ennek egyik oka talán a rendszeren futó alkalmazások sokszínűsége, mely meglehetősen nehézzé teszi egy központi konfigurációs felület kialakítását, bár erre egyre több jó kezdeményezésnek lehetünk tanúi.

Hasonlóságok Tárgyalt főbb különbségeik ellenére a Linux és Windows rendszerek sok közös vonással is rendelkeznek. Ilyen például a parancsértelmező, másnéven shell: a windowsos világ command.com, vagy cmd.exe nevezetű értelmezőjének megfelelőjét nevezik így a Linuxos környezetben. Fontos megjegyezni, hogy minden felhasználó rendelkezik egy alapértelmezett shell-lel, leggyakrabban a manapság elterjedten használatos bash vagy sh parancsértelmezővel. Szintén hasonló a rendszerben futó processzek kezelésének alapkoncepciója, ugyanúgy értelmes a CPU-kihasználtság, vagy memóriafoglalás fogalma,

- 55 -



ugyanúgy jönnek létre új végrehajtási szálak, és ugyanúgy lehetőség van azok szelektív leállítására megfelelő jogosultságok esetén. A két rendszer internetes hálózat felé nyújtott képe meglehetősen hasonló, egyszerűen a TCP/IP hálózati szabványoknak való megfelelés okán. Egy Microsoft IIS webkiszolgálót pontosan ugyanúgy kell a kliensek számára elérhetővé tenni, mint egy linuxos Apache webszervert. A Windows XP beépített tűzfala hasonló filozófiát követ, mint a linuxos iptables, a kernel által szolgáltatott tűzfalmegoldás. Mindkettő a hálózati kommunikációs rétegben működik, alapvetően csomagokkal és kapcsolatokkal, portokkal és IPcímekkel dolgozik, vagyis használata különbözik a kiterjedt grafikus felületet és folyamatos felhasználói interakciót alkalmazó, jellemzően alkalmazásokkal és a hozzájuk rendelt hálózati jogosultságokkal operáló személyi tűzfalaktól. Meg kell azonban említenünk, hogy az iptables segítségével lényegesen szélesebb eszköztárral rendelkezünk egy hálózat felügyeleti feladatainak megoldásakor. A két rendszer közti legnagyobb hasonlóság azonban valószínűleg biztonsági szempontból figyelhető meg: mindegy, hogy egy frissítések nélküli, hibás konfigurációval ellátott Windows, vagy Linux rendszert kötünk az Internetre, biztosak lehetünk benne, hogy a rendszer hamarosan kompromittálódni fog. Ezért nem árt mindkét rendszer esetében ugyanazokat az irányelveket szem előtt tartani, sosem bízhatunk egy telepített környezet biztonságában csak azért, mert a telepítőkorongra bizalomkeltő név került. 4.8.2.2 A Linux rendszer főbb komponensei A rendszer fontos összetevőit a rendszerindítási végigkövetésével mutatjuk be.

folyamat

áttekintő

1. A számítógép BIOS-a a rendszer indításakor betölti a rendszer elsődleges boot-eszközének első blokkját. Linux rendszerek esetén egy specializált rendszerbetöltő kód kapja meg a vezérlést, mely általában egy menüvel rendelkező rendszertöltő minialkalmazás, ún. bootloader felolvasását és indítását végzi el. A menü nem minden esetben jelenik meg a felhasználó számára is, előfordulhat, hogy egy rövid várakozási idő után egy menüpontot automatikusan választ ki a rendszer és ebbe a folyamatba kell valamely billenyű lenyomásával beavatkozni. Két elterjedt bootloader áll rendelkezésünkre, az egyik a nagyobb múltú, de nem olyan általános LILO (LInux LOader), a másik pedig pedig a frissebb fejlesztésű, ígéretes, de még nem olyan széles körben elterjedt GRUB (GRand Unified Bootloader) névre hallgat. 2. A bootloader feladata, hogy a rendszer indítását előkészítse a Linux kernel memóriába való betöltésével. A kernel számára indítási paramétereket lehet átadni, melyeket a bootloader saját konfigurációja alapján specifikál, majd a felhasználó által megadott paraméterekkel egészít ki. A legtöbb disztribúcióban a rendszerbetöltés szerves részét képzi a kernelmodulokat (vö. LKM) tartalmazó kezdeti ramdrive (initrd, initial ramdrive) is, melyet szintén a bootloader készít elő a kernel számára.

- 56 -



3. A Linux kernel ezután megkapja a vezérlést és elvégzi a rendszer inicializálását, kezdve az alaplapi erőforrások, a processzor és a memória felismerésétől egészen a rendszert kiegészítő hardverelemek meghajtóinak az initrd-ről történő betöltésével. A rendszer gyökerének felcsatolása után a vezérlést a kiemelt szerepű, 1-es azonosítójú processz, az init kapja meg. 4. Az init processz jellemzően az /etc/inittab fájlban található konfigurációs beállítások alapján egy futási szintre (runlevel) állítja a rendszert, majd az ezen a szinten meghatározott egyéb alkalmazások indítását végzi el. A legfontosabb runlevelek: 0 (rendszer leáll), 1 (egy felhasználós karbantartási üzemmód), 2-5 (normál felhasználói üzemmódok), 6 (rendszer újraindul). Az init a rendszer felhasználása során végig a memóriában marad. 5. A normál futási szinten a felhasználó számára általában több virtuális karakteres konzol (tty) áll rendelkezésére, melyeket a getty program szolgáltat. Ezeken a konzolokon alapértelmezésben leggyakrabban a felhasználó belépését lehetővé tevő login program fut, mely a rendszer autentikációs moduljaihoz (PAM, Pluggable Authentication Modules) fordul az azonosítás során. A login sikeres autentikáció esetén a felhasználót egy parancsértelmezőhöz, például a bash-hoz irányítja. A legtöbb modern rendszer a karakteres terminálok mellett egy vagy több grafikus terminált is indít a már említett X segítségével. Az X felületen való beléptetést általában egy grafikus login program, leggyakrabban az xdm (standard), kdm (KDE), vagy gdm (Gnome) végzi el. 4.8.2.3 Általános felhasználási tanácsok a Linux rendszerhez Mielőtt rátérnénk a rendszer konkrét konfigurációs lehetőségeinek tárgyalására, az előző fejezet reményeink szerint valóban csak a fontos jellegzetességeket átölelő megállapításai alapján máris felhívhatjuk a figyelmet pár általános, de biztonsági szempontból mégis roppant hasznos gyakorlati tanácsra. •

Mellőzzük a root felhasználóként való munkavégzést a mindennapi feladatok során! Mivel minden egyes root jogokkal futó alkalmazás tovább növeli azt a kockázatot, hogy az alkalmazás hibáit kihasználva jogosulatlanul magas privilégiumszint szerezhető, kézenfekvő, hogy ne így használjuk azokat a funkciókat, melyek jól működnek egyszerű felhasználóként is. Ezen biztonsági tényezők mellett meg kell említenünk az emberi tényező által jelentett kockázatot is: mivel a root felhasználó számára gyakorlatilag nincsenek korlátok a rendszerben, egy hibás utasítással könnyen okozhatunk az egész rendszer működésére nézve visszavonhatatlan károkat. Egyes újabb Linux disztribúciókban már tiltott a root felhasználóként való belépés, csak az egyszerű felhasználók számára egy felügyelt privilégiumnövelést lehetővé tevő sudo parancs segítségével lehet a rendszergazda nevében parancsokat végrehajtani. Bár nem tesszük le egyértelmű voksunkat emellett a megoldás mellett, láthatólag működőképes ez a koncepció is. Veszélyt jelent azonban, hogy a felhasználó

- 57 -



kezébe ilyen módon kerülő root jogosultság az adott felhasználó jelszavához van kötve alapértelmezésben, így egy illetéktelen behatoló, amennyiben a felhasználó jelszavát megszerzi, őt megszemélyesítve rendszergazdai jogokhoz is juthat. •

Ne hagyjunk gyengén konfigurált, biztonsági frissítések nélküli rendszert a hálózaton! Az előző fejezetben a Windows rendszerrel való hasonlóságok taglalásakor már utaltunk erre a tanácsra. A probléma nem csak abban rejlik, hogy a gyenge rendszert feltörhetik, esetleg visszavonhatatlan károkat okozva, de az is komoly problémát okozhat, hogy a kompromittált rendszerbe belépő felhasználók viselkedését, esetleg autentikációs információit felhasználva más, alapvetően jobban védett rendszereinkbe is megkönnyíthetjük a továbbhaladást. Különösen fontos ez a Linux rendszerek esetében, ahol a távoli biztonságosnak vélt belépést lehetővé tevő ssh parancs lecserélése a legtöbb rootkit alapvető tevékenységei közé tartozik.

•

Lehetőleg ne használjuk a telepítőrendszerek előre elkészített telepítési profiljait A felhasználók igényeinek megfelelni próbáló, jellemzően grafikus telepítővel ellátott Linux disztribúciók gyakran próbálják a felhasználót minél kevesebb döntési helyzetbe kényszeríteni, ezért általában alapértelmezett telepítési profilokat ajánlanak fel, melyek kiválasztása gyakran a felhasználó számára valójában teljesen szükségtelen, nemritkán egyúttal nagyon laza konfigurációs korlátokkal ellátott csomagok ezreinek telepítését eredményezik. Mivel tízannyi alkalmazás és konfigurációs beállítás vélhetőleg tízannyi biztonsági rést rejt, nem szorul magyarázatra, miért jár magasabb kockázattal az előregyártott rendszerek használata.

•

Tudatosan válasszunk a biztonsági szempontokat befolyásoló lehetőségek között! Az „ami nem szabad, azt tilos” itt is érvényes, vagyis lehetőleg mellőzzük a binárisok suid opcióval történő telepítését, még akkor is, ha a konfigurációs program figyelmeztet az esetenkénti csökkent használhatóságra: ráérünk a kérdéses funkciókat akkor engedélyezni, ha valóban szükség lesz rájuk. Ugyanígy elmondhatjuk, hogy a TCP/IP protokollon keresztül is elérhető szolgáltatások (pl. adatbázisszerverek, CVS, rsync, stb.) telepítésekor válasszuk a csak lokális elérhetőséget lehetővé tevő funkciókat, hiszen gépünk hálózati profilját szűkre szabva csökkentjük a támadási lehetőségeket is. Bizonyos disztribútorok (pl. Adamantix) a fenti elveket követve építik meg rendszereiket, azonban el kell ismernünk, hogy a biztonságos alapbeállítások sokhelyütt okozhatnak bosszúságot a felkészületlen felhasználók számára, ezért néhány elterjedt rendszer szinte teljes „átjáróház” alapbeállítások használata esetén, mivel ezeknél fontosabbnak tartották a kényelmi funkciók hangsúlyozását. Döntsünk céljainknak megfelelően!

- 58 -



4.8.2.4 A Linux rendszerek alapvető beállításai Az alábbiakban áttekintését kívánjuk nyújtani a Linux rendszerek hálózati képének kialakításához szükséges alapvető ismereteknek. A fejezet inkább az alapkoncepciók és legfontosabb parancsok bemutatására korlátozódik, nem egy tejeskörű referenciaanyag szerepét kívánja betölteni. Ennek ellenére konkrét példákon keresztül is törekszünk a fontosabb tényezők bemutatására.

Hálózatkezelés A Linux alapvetően hálózati operációs rendszer, a futtatható programok jó része rendelkezik valamilyen IP-alapú kommunikációval kapcsolatos funkcióval. Ennek megfelelően a hálózati beállítások már a kernelnek is alapvető részét képzik. Elkészíthető ugyan olyan speciális Linux disztribúció, mely egyáltalán nem ismeri a „hálózat” fogalmát, azonban erre a mindennapokban elvétve találhatunk csak példát. A fentiek fényében talán nem meglepő, hogy egy általános Linuxnak kötelező komponensét képzi legalább egy hálózati interfész, mégpedig a speciális ún. loopback, vagy rövid nevén lo hálózati eszköz, mely nevével összhangban egy hurkot képez a rendszerben: a hozzá érkező, a rendszerből kifelé igyekvő hálózati üzeneteket visszafordítja, és befelé érkező üzenetekként adja tovább. A loopback interfész számára kijelölt hálózati cím a 127.0.0.1, melynek a legtöbb rendszerben alapértelmezésben a localhost név felel meg. A loopback interfész számos praktikus alkalmazási lehetőséget nyújt a felhasználó számára, de legfontosabb felhasználása a hálózati szoftverek helyi gépen történő felhasználásában rejlik, ez a hurok teszi lehetővé, hogy például a helyi számítógépen futó webkiszolgálót az ugyanezen gépen futó webböngészőn keresztül el lehessen érni, még akkor is, ha a rendszer nem rendelkezik egyébként hálózati kapcsolattal. Természetesen a Linux rendszerek nem csak önmagukkal tudnak kommunikációt folytatni, a napjainkban használatos összes elterjedt hálózati kapcsolati formát támogatják. Az alábbiakban ezek közül emeljük ki a legfontosabbakat, azonban előtte még szót kell ejtenünk az Internetre való csatlakozás alapvető komponenseiről is. Hálózati alapbeállítások – az ifconfig parancs

A hálózati kapcsolat mindig egy fizikai eszközön keresztül valósul meg, melyhez általában a Linux kernel megfelelő eszközvezérlőjére van szükség. A fizikai eszköz a vezérlőmodul betöltése után az ifconfig parancs segítségével tekinthető meg. Ez egy szöveges parancs, mely alapértelmezésben csak a root felhasználó elérési útvonalában található meg. Segítségével megtekinthetjük a rendszerben aktív működésre kész hálózati eszközöket, valamint azok legfontosabb fizikai és logikai paramétereit, mint például az eszköz által küldött és fogadott üzenetek száma, az eszköz fizikai hálózati címe, vagy az eszközhöz rendelt IP-cím. Az ifconfig segítségével nem csak megtekinthetőek, hanem be is állíthatóak az eszközök erre alkalmas paraméterei.

- 59 -



Az alábbiakban tekintsünk két konkrét példát az ifconfig parancs használatára. Az alábbi példában két hálózati eszközt, egy eth0 nevű Ethernet interfész, és a már említett lo interfész beállításait tekinthetünk meg mintarendszerünkben: klapp:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:0C:6E:A6:18:0B inet addr:10.0.0.153 Bcast:10.0.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1390 errors:0 dropped:0 overruns:0 frame:0 TX packets:1368 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:911808 (890.4 KiB) TX bytes:129352 (126.3 KiB) Interrupt:18 Memory:ec800000-0 lo

Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:325 errors:0 dropped:0 overruns:0 frame:0 TX packets:325 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:39987 (39.0 KiB) TX bytes:39987 (39.0 KiB)

A következő parancs segítségével az eth0 interfész IP-címét és alhálózati maszkját (subnet mask, netmask) állítjuk át. A broadcast címet a rendszer ebben az esetben automatikusan kiszámítja: klapp:~# ifconfig eth0 10.1.2.3 netmask 255.255.255.0

Mint látható, a parancsnak siker esetén nincs kimenete, vagyis a sikert azzal könyvelhetjük el, ha nem kapunk hibaüzenetet. Ez sok más szöveges parancs esetén is hasonlóan működik Linux rendszerekben. A fenti parancs hatása nem rögzül a rendszer konfigurációjában, maximálisan csak a számítógép újraindításáig marad érvényben. A parancs részletesebb használatáról a man ifconfig parancs ad információt. Vezeték nélküli hálózat – az iwconfig parancs

Az egyre szélesebb körben elterjedt vezetéknélküli, ún. WLAN hálózati interfészek olyan új paraméterek megadását tették szükségessé, mint például az adatok kódolásához használatos WEP kulcsok, melyek nem állnak rendelkezésre az általánosabb célú ifconfig parancsban. A problémát az iwconfig utasítás oldja meg, mely használatát tekintve meglehetősen hasonló, ám lehetőséget ad további paraméterek megadására is. A parancs részletesebb használatáról a man iwconfig parancs ad információt. Útválasztás – a route parancs

Windows rendszerekben a hálózati beállítások egy központi konfigurációs felületen keresztül lekérdezhetők és módosíthatók. Linux esetében sincs ez másképp, azonban ennek módja disztribúciónként teljesen eltérő lehet, emiatt továbbra is az univerzális parancssori beállításokkal foglalkozunk.

- 60 -



A rendszer alapértelmezett hálózati átjárójának beállítására ad lehetőséget a route parancs. Ez a parancs meglehetősen bonyolult hálózati beállításokat is lehetővé tesz, mi itt csak az alapvető funkciók bemutatására szorítkozunk. A parancs az ifconfig utasításhoz hasonlóan az aktuálisan érvényben levő beállítások megtekintésére és módosítására is alkalmazható. Az alábbi példában először az elsőként említett funkciót használjuk ki: klapp:~# route Kernel IP routing table Destination Gateway Iface 10.0.0.0 * eth0 default 10.0.0.1 eth0

Genmask

Flags Metric Ref

Use

255.255.255.0

U

0

0

0

0.0.0.0

UG

0

0

0

A fenti kétsoros táblázat egyes rendszereken természetesen sokkal bonyolultabb is lehet, az útvonalválasztási döntések során a rendszer a táblázat sorain fentről lefelé haladva keresi az első illeszkedő célcímet, a Destination és Genmask paraméterek együttes megfelelése esetén pedig az Iface paraméter által meghatározott hálózati eszközön keresztül Gateway átjárónak, vagy * paraméter esetén átjáró használata nélkül közvetlenül a címzettnek továbbítja az üzeneteket. A fenti példán látható, hogy az előző szakaszban konfigurált eth0 interfész számára helyi alhálózatba közvetlenül, míg a többi IP-címre a 10.0.0.1 című alapértelmezett („default”) átjárón keresztül kerülnek az üzenetek. Részletesebb magyarázat nélkül lássunk egy példát az alapértelmezett átjáró átállítására, mely általában a táblázat utolsó sorában kap helyet, ezért nem szükséges az egyébként sajnos elkerülhetetlen soronkénti törlés és újrafelvitel. klapp:~# route add default gw 10.0.0.2

A fenti parancs eredményeképp a route táblázat utolsó, nem default gateway-t tartalmazó sora után a 10.0.0.2-es IP cím kerül alapértelmezett átjáróként való kijelölésre. A sort ugyanezzel az utasítással törölhetjük, csak az add kulcsszó helyett a del parancsot kell megadnunk. A parancs részletesebb használatáról a man route parancs ad információt. Itt tartjuk fontosnak megjegyezni, hogy a Linux rendszerben a route és ifconfig parancsok által elérhető funkciók csak szűk részhalmazát képzik a valóban rendelkezésre álló lehetőségeknek, például a rendszerben több párhuzamos útválasztási táblázat üzemelhet és a hálózati interfészek beállításai sem mind érhetők el az általánosabb ip parancs használata nélkül, ennek részletesebb bemutatása azonban nem képzi jelen dokumentum tárgyát. Automatikus IP-hozzárendelés – a dhclient parancs

Egyes hálózati környezetekben előfordulhat, hogy a linuxos munkaállomás számára automatikusan kiosztott IP cím áll rendelkezésre. Ennek detektálására szolgál a dhclient parancs, mely indítása után a megadott hálózati interfészen - 61 -



elvégzi a cím automatikus beállítását. A parancs használata nem jelent különösebb problémát, ha a kérdéses hálózati interfész, jelen példánkban az eth0, már rendelkezésre áll a rendszerben. Ehelyütt lássunk egy példát a dhclient program kimenetére: klapp:~# dhclient eth0 Internet Software Consortium DHCP Client 2.0pl5 Copyright 1995, 1996, 1997, 1998, 1999 The Internet Software Consortium. All rights reserved. Please contribute if you find this software useful. For info, please visit http://www.isc.org/dhcp-contrib.html Listening on LPF/eth0/00:0c:6e:a6:18:0b Sending on LPF/eth0/00:0c:6e:a6:18:0b Sending on Socket/fallback/fallback-net DHCPREQUEST on eth0 to 255.255.255.255 port 67 DHCPACK from 10.0.0.1 bound to 10.0.0.153 -- renewal in 21600 seconds.

Modemes kapcsolat – a PPP alrendszer

A Linux rendszerekben az eddig ismertetett parancsokat általában a kernel megfelelő eszközvezérlőinek betöltése után minden további probléma nélkül használhatjuk a hálózati interfészek beállítására. Nem így van ez a modemes kapcsolatok esetén, ahol is a bonyolult modemkezelés és behívási szolgáltatások már nem kaphattak helyet a rendszermagban. Az említett feladatokat végzi el a pont-pont közti protokollokon (Point to Point Protocol, PPP) kialakított kapcsolatokért felelős ún. PPP démon. A PPP alrendszer helyes működésének eredményeképp az ifconfig parancs kimenetén egy ppp0, vagy ehhez hasonló elnevezésű virtuális hálózati interfész jelenik meg, mely a PPP démon által a távoli Internet szolgáltatóval bonyolított kommunikációs szolgáltatásokat teszi az általános Linux alkalmazások számára az eddigiekben leírtakhoz hasonlóan elérhetővé. A démon neve a Linux rendszerekben általában pppd, konfigurációját az /etc/ppp könyvtárban találhatjuk. Az esetenként bonyolult magyarázatokra okot adó konfiguráció részletezése nélkül áttekintőleg elmondhatjuk, hogy a PPP alrendszer az említett két fontos feladat, vagyis a telefonvonalra csatlakozó modem kezelése és azáltal a soros adatkapcsolati vonal formájában szolgáltatott távoli Internet-kiszolgálóval való kommunikáció feladatait végzi el. A modem konfigurációját általában a szolgáltatóra (ún. peer, vagy provider) vonatkozó opciók között elszórva találhatjuk meg. Részletesebb információt találhatunk a man pppd parancs által megjelenített dokumentációs oldalról kiindulva. A PPP alrendszer konfigurációját rengeteg különböző segédprogram támogatja, ezek közül talán a legelterjedtebb a pppconfig felület, mely az /etc/ppp könyvtár megfelelő előkészítését végzi el a felhasználótól érthetőbb formában bekért szolgáltatói információk alapján. Feltéve, hogy a pppconfig parancs során a szolgáltatót az alapértelmezett „provider” névvel azonosítottuk, a csatlakozás a következő parancs kiadására indul meg: - 62 -



klapp:~# pppd call provider

Kényelmesebb, de nem minden esetben elérhető a szintén parancssoros wvdial alkalmazás, mely csak a minimálisan szükséges alapvető információk, például a telefonszám/felhasználónév/jelszó hármas alapján próbál minden egyéb bonyolult beállítást – több vagy kevesebb sikerrel – automatikusan kikövetkeztetni a wvdialconf parancs futtatása során. Az alapelvek és alapvető parancsok ismertetése után összefoglalva kezdő felhasználók számára azt ajánlhatjuk, próbálkozzanak a választott Linux disztibúció által nyújtott kényelmi PPP konfigurációs szolgáltatások használatával kapcsolatot építeni, mert a parancssori megoldások bonyolultsága minden bizonnyal riasztólag hathat a rendszerrel ismerkedők számára. ADSL kapcsolatok – a PPPoE

Jelen dokumentum írása idején hazánkban már széles körben elterjedt ADSL kapcsolatok Linux rendszerekkel történő felhasználása a modemes kapcsolatnál leírtakhoz hasonlóan működik, néhány nem lényegi különbséggel. Az ADSL modem jellemzően nem a klasszikus soros porton kapcsolódik a számítógéphez, hanem egy szabványos Ethernet kártyán (Linuxban pl. eth0) keresztül, melyet más célra ez idő alatt nem használhatunk. Emiatt a PPP alrendszer módosításokra szorult, és létrejött az ún. PPP over Ethernet, röviden PPPoE alrendszer, mely működésében és parancsaiban is a már ismertetett rendszerhez hasonlít. A PPPoE alrendszerben a pppoe elvenezésű démon végzi a hálózati kapcsolat felépítését, szintén az /etc/ppp konfigurációs könyvtár alapján. A beállításokban a legtöbb rendszeren a pppoeconf parancs segítségére is számíthatunk. A PPP megoldásoknál leírtakhoz hasonlóan itt is a megfelelő disztribúció ADSL-támogatásának felhasználását javasoljuk. Névfeloldás – a DNS resolver

A fentiekben ismertetett hálózati, illetve végsősoron internetes kapcsolódási lehetőségek közül nem mindegyik és nem minden esetben hozza magával egy alapvető szolgáltatás, a névfeloldás (Domain Name Service, DNS) megfelelő konfigurációját. Ha azt tapasztaljuk, hogy rendszerünk IP-címek segítségével megfelelően képes kommunikálni, azonban internetes domainnév alapján már nem, gyanakodhatunk arra, hogy nincs megfelelő névkiszolgáló az /etc/resolv.conf fájban. A fájl – önmagáért beszélő – tartalmára egy példa: nameserver 233.163.24.63 nameserver 64.77.243.12

Egy másik, szintén a névfeloldással kapcsolatos fájl az /etc/hosts, melyben előredefiniált IP-cím- és domainnév-megfeltetéseket találhatunk. Itt szerepel például a már említett 127.0.0.1 loopback-cím és a localhost név összerendelése is. Fontos tudni, hogy a hosts fájl tartalma felülbírálja a resolv.conf állományban megadott névszerverek által szolgáltatott

- 63 -



információkat, de természetesen csak a helyi számítógépen. A fájl tartalmára egy egyszerű példa: 127.0.0.1 10.0.0.1

localhost www.albirouter.hu

4.8.2.5 A Linux hálózati tűzfala Fejlődése során a Linux kernel egyik alapszolgáltatása, a csomagszűrő tűzfal sok változáson ment keresztül, melynek részeként az elsődleges felhasználói felületet szolgáltató parancssoros vezérlőprogramok is sokat változtak. Jelen dokumentumban csak a napjainkban használatos ún. iptables megoldással foglalkozunk. Alapvető működés

Az iptables, ahogy neve is sejteni engedi, a rendszerben közlekedő IP-csomagok áthaladását szabályozó táblázatok útján nyújt tűzfalszolgáltatásokat. Mivel a csomagok továbbítását a kernel végzi, célszerű volt a fejlesztés során az iptables szűrőképességeit is itt elhelyezni. Ebből következően a Windows rendszerekben telepíthető személyi tűzfalaktól eltérően az iptables szabályaiban többnyire csak áttételesen hozhatjuk kapcsolatba a rendszerben futó felhasználókat és alkalmazásokat azok forgalmával. Az összerendelés leginkább az alkalmazások által folytatott kommunikáció jellemzői (például cél- és forráscímek, forgalomtípus stb.) alapján történhet meg. Az iptables alapértelmezésben három fő táblát bocsát a felhasználó rendelkezésére, melyekben az útválasztásnál korábban már leírtakhoz hasonlóan fentről lefelé, az egymást követő szabályok közül az első illeszkedő által meghatározott döntés jut érvényre. A három alaptábla a következő: •

INPUT: ebbe a bemeneti táblába kerülnek azok az IP-csomagok, melyek a rendszer bármelyik hálózati interfészén keresztül közvetlenül rendszerhez, illetve a rendszerben futó valamely hálózati alkalmazáshoz érkeznek.

•

OUTPUT: ebbe a kimeneti táblába kerülnek azok az IP-csomagok, melyeket a rendszeren futó valamely alkalmazás küld valamely hálózati interfészen keresztül.

•

FORWARD: ebbe a táblába azok a csomagok kerülnek, melyek a rendszeren keresztül, annak egyik interfészén át bejutva, majd egy másik interfészen továbbhaladva egy másik rendszer IP-címére kerülnek továbbításra. A táblában csak akkor történnek döntések, ha a táblát tartalmazó számítógép IP-hálózati átjáróként üzemel más számítógépek számára, vagyis a helyi gépre vonatkozó biztonsági szabályoknak nem itt van helye.

Az említett három táblán kívül tetszőleges számú további tábla is létrehozható, melyek bármely táblában megadott szabály ugrási célpontjaként feldolgozási szabályok egyszerű csoportos megadására adnak lehetőséget.

- 64 -



Mindegyik alaptáblához meg kell adni egy alapértelmezett (ún. policy) döntést, mely akkor kerül végrehajtásra, ha a táblába érkező IP-csomag egyik szabályra sem illeszkedett. A legfontosabb döntések listája: •

ACCEPT: a csomag elfogadásra kerül, vagyis a szabály illeszkedése esetén kikerül az aktuális alaptáblából és továbbhalad célja felé.

•

DROP: a csomag feldolgozása egyszerűen „eldobja”.

•

RETURN: a csomag a tábla alapértelmezett döntésének lesz alárendelve. Az alaptáblákhoz általában DROP vagy ACCEPT policy (alapértelmezett döntés) tartozik, a felhasználó által definiált táblákban a RETURN döntés az adott táblába való belépést eredményező szabályt követő szabályra tereli a feldolgozást (mintha egy függvényből térnénk vissza).

•

LOG: a csomag adott paraméterei a kernel alapértelmezett naplófájljába kerülnek, ezzel segítve a rendszer adminisztrátorát az esetleges problémák felderítésében. Az ilyen döntést tartalmazó szabályok nem szakítják meg a feldolgozási folyamatot.

•

REJECT: a csomag a DROP szabályhoz hasonlóan eldobásra kerül, azonban ezzel egyidőben a küldő számára egy megadható típusú, elutasító ICMP-üzenet is feladásra kerül. Ezzel a szabállyal például megoldható, hogy a külső szemlélő számára az adott csomag mintegy „célt tévesszen”, vagyis az iptables használatának tényét segíthet elkendőzni, mintha a rendszer az adott csomaggal nem tudott volna mit kezdeni, mert például nem fut a csomag által címzett szolgáltatás. Természetesen más célokra is használható.

megszakad,

az

operációs

rendszer

Az iptables természetesen rengeteg egyéb döntést is lehetővé tesz, ezek bemutatása azonban nem fér jelen dokumentum keretei közé. Csak annyit jegyzünk itt meg, hogy az iptables használatáról a man iptables parancs ad bővebb felvilágosítást. Az iptables szabályait kihasználva olyan lehetőségek állnak rendelkezésünkre, mint például egy számítógép internet-kapcsolatának megosztása más gépekkel (Network Address Translation, NAT), vagy egy számítógépre érkező bizonyos típusú forgalom továbbirányítása más számítógépekhez (load balancing, port forwarding). Az iptables alrendszer beállításait az iptables parancs segítségével módosíthatjuk. Mivel már az egyszerű, kevés szolgáltatást nyújtó rendszereken is bonyolult táblákkal kerülhetünk szembe, és a táblák kezelése a sorrendiségi kötöttségek miatt meglehetősen nehézkes, ajánlatunk az, hogy keressük meg Linux disztribúciónk grafikus tűzfalbeállítási felületét, vagy legalábbis alkalmazzuk a teljes iptables táblarendszer standard kimenetre történő mentésére és standard bemenetről történő visszaállítására szolgáló iptables-save és iptables-restore parancsori utasításokat. Az iptables-save egy egyszerű kimenetére adunk most egy magyarázatokkal ellátott példát, csak az alapvető lehetőségek érzékeltetése végett:

- 65 -



# Generated by iptables-save v1.2.11 on Sat Feb 25 14:34:01 2006 *filter :INPUT DROP [9363:636002] :FORWARD ACCEPT [98520:53054447] :OUTPUT ACCEPT [330496:569437802] -A INPUT -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT -A INPUT -i eth1 -j ACCEPT -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 2121 -j ACCEPT COMMIT # Completed on Sat Feb 25 14:34:01 2006

A fenti szabályok eredményeképp a három alaptábla rendre a DROP, ACCEPT, ACCEPT policy beállítást kapja, vagyis a FORWARD és OUTPUT táblák alapértelmezetten minden IP-csomagot átengednek, az INPUT táblában pedig alapértelmezésben minden csomagot eldob a rendszer. Ezután következnek az INPUT tábla szabályai, melyeket a -A INPUT karaktersor vezet be. A másik két alaptáblában nincsenek további szabályok. Az INPUT tábla szabályainak részletes elemzésétől eltekintve, a fentről lefelé haladó feldolgozási sorrendet is figyelembe véve, rendre a következőképp megfogalmazható döntéseket hozza a rendszer: •

A helyi számítógépről a helyi számítógépre a loopback IP-címen keresztül irányuló minden csomagot elfogad.

•

Minden csomagot elfogad, amely az eth1 hálózati interfészen keresztül jut be a rendszerbe.

•

Minden csomagot elfogad, amely egy belülről kifelé irányuló kérésre válaszként érkezik (RELATED), vagy egy már felépített kapcsolat részét képezi (ESTABLISHED).

•

Minden TCP/IP-csomagot beenged, melynek célportja rendszerben alapértelmezett porton futó ssh-kiszolgáló.

•

Minden TCP/IP-csomagot beenged, melynek célportja a 2121, jelen esetben például a rendszerben nem alapértelmezett porton futó ftp-kiszolgáló.

a

22-es,

a

Mivel az INPUT tábla a DROP policy-t alkalmazza, a rendszer a többi forgalmat eldobja. Ehelyütt jegyezzük meg, hogy a „mindent tilos, amit nem szabad” elvnek megfelelően célszerű legalább az INPUT láncon az ismertetett struktúrát alkalmazni. A *filter az alapértelmezett iptables-táblakészlet kiválasztására szolgál, hasonlóképp a COMMIT sor hatására az iptables-restore parancs érvénybe léptetné a leírt műveleteket, ha standard bemenetén a fenti példa tartalmával találkozna. tcpwrapper

Említést kell még tennünk egy alkalmazásszintű biztonsági megoldásról is, melyet a napjainkban használt Linux rendszerek már a rendszer

- 66 -



alapkönyvtárába épített szolgáltatásként szinte minden hálózati kiszolgáló alkalmazásra nézve kihasználhatóvá tesznek. A megoldás tcpwrapper néven vált ismertté, mert a megoldás lényegét az szolgáltatja, hogy a rendszer TCP-t használó alapvető kommunikációs funkcióit nyújtó függvények köré egyfajta védelmi burok készítését teszi lehetővé. A rendszer két alapvető konfigurációs fájlon keresztül bírható működésre: Az /etc/hosts.deny fájl tartalmazza azon internetes címek listáját melyek számára a megadott szolgáltatások elérése megtagadásra kerül. A fájl értelmezése egy példán keresztül: ALL: PARANOID sshd: ALL ftp: .gonoszok.hu,10.0.0.

Az első sor értelmében a hozzáférést minden szolgáltatásra vonatkozóan minden olyan gép számára megtagadjuk, melynek internetes domain neve nem az IPcíméhez tartozik. A második sor minden host számára tiltja az ssh-szolgáltatás elérését, az utolsó sor pedig tiltja a gonoszok.hu és aldomainjei, valamint a 10.0.0 kezdetű IP-címek számára az ftp-szolgáltatás elérését. Az /etc/hosts.allow fájl az előzőekhez hasonló sorokat tartalmaz, azonban ezek értelmezése fordított, és a hosts.deny utasításainak részleges érvénytelenítésére használatosak, vagyis például a fenti állományhoz tartozó hosts.allow az ssh-hozzáférést engedélyezi a 10.0.0.153 IP-címről: sshd: 10.0.0.153

A fentiekről bővebb információt a man tcpd parancs által megjelenített dokumentációs oldalról kiindulva találhatunk. 4.8.2.6 Csomagkezelés Röviden szót kell ejtenünk a csomagkezelés alapvető koncepcióiról. Mint ahogy már a Linux és Windows rendszerek közti különbségeket taglaló szekcióban erre utaltunk, a Linuxban az alkalmazásokat a kötött struktúrájú fájlrendszer pontjaira szétszórtan, általában ún. csomagkezelő alkalmazások segítségével kell telepíteni. Telepítés forráskódból – gyorstalpaló

Első lépésként nem a csomagkezelő megoldással ismerkedünk meg, hanem a klasszikus, és a legtöbb disztribúción működőképes forrásból történő telepítés áttekintését adjuk meg. Általános esetben egy linuxos alkalmazáshoz tömörített forráskód formájában juthatunk hozzá. A tömörített állományok végződései általában .tar.gz, .tgz vagy .tar.bz2, az első két esetben gzip tömörítésű tar, utóbbi egy esetben pedig bzip2 tömörítésű tar állományról van szó. Mindkét esetben az első lépés az archívum kitömörítése, például az mplayer.tar.bz2 állomány esetében következő parancs segítségével:

- 67 -



[mcree@klapp:/tmp]-$tar xvjf mplayer.tar.bz2 Mplayer-1.0pre7try2/libavformat/sgi.c Mplayer-1.0pre7try2/libavformat/sierravmd.c Mplayer-1.0pre7try2/libavformat/sol.c Mplayer-1.0pre7try2/libavformat/swf.c Mplayer-1.0pre7try2/libavformat/tcp.c Mplayer-1.0pre7try2/libavformat/udp.c ... ...

A parancs az aktuális könyvtárba, illetve ennek általában egy alkönyvtárába (jelen esetben: Mplayer-1.0pre7try2) kicsomagolja a forráskódokat, gzip fájlok esetén az xvjf paraméterek közül a j-t z-re kell cserélnünk. Ezután következik a forráskód helyi futtatási környezetre történő testreszabása, melyhez a legtöbb (de nem minden egyes!) forráshoz mellékelnek egy configure nevezetű parancsot, melyet a program forráskönyvtárából kell kiadnunk az alábbiak szerint: [mcree@klapp:/tmp/MPlayer-1.0pre7try2]-$./configure Detected operating system: Linux Detected host architecture: i386 Checking for cc version ... 3.3.5, ok Checking for host cc ... cc Checking for CPU vendor ... AuthenticAMD (6:8:1) Checking for CPU type ... AMD Athlon(TM) XP 2100+ Checking for GCC & CPU optimization abilities ... ... ...

Megjegyezzük, hogy a további konfigurációs futásának eredménye mely alapján már a fordítása:

parancs általában elfogad egy --help paramétert, mely opciók megadhatóságát fedheti fel. A parancs sikeres egy Makefile nevű állomány az aktuális könyvtárban, make parancs kiadásával elvégezhető az alkalmazás

[mcree@klapp:/tmp/MPlayer-1.0pre7try2]-$make ./version.sh `cc -dumpversion` make distclean make[1]: Entering directory `/tmp/MPlayer-1.0pre7try2' ... ...

A make nem ritkán hosszas futásának eredményeként létrejönnek az alkalmazást alkotó bináris állományok, melyek általában futásra készek, azonban előfordulhat, hogy további telepítési lépésekre van szükség, ekkor a make install parancs segítségével véglegesíthetjük az alkalmazás telepítését. Általános konvenció, hogy ez az utasítás az /usr/local könyvtárat használja telepítési célpontként, azonban legyünk óvatosak, mert nem minden forráskódkészítő tartja be ezt az íratlan szabályt, így egy feleslegesen telepített program eltávolítása az esetenként hiányzó make uninstall parancs nélkül nagy munkába kerülhet.

- 68 -



Az itt leírt egyszerű műveletsor természetesen nem fedheti le egy általános forráskódból történő telepítés során felmerülő összes hibalehetőséget, a hiányzó parancsoktól és rendszerkönyvtáraktól a fordítási hibákig vagy speciális teendőkig bezárólag, mégis sok esetben ez a tudás már elegendő lehet egy egyszerű, vagy gondosan megszerkesztett alkalmazás használatához. Csomagkezelési alapok

A csomagkezelés a jelenleg használatos disztribúciókban az egyszerű, forráskódalapú megoldáson kívül általában két elterjedt rendszerre épül. Az egyik a Debian, és az erre épülő rendszerekben használatos .deb formátumra és a dpkg csomagkezelőre, a másik pedig a RedHat, és az erre épülő rendszerekben használatos .rpm formátumra és az rpm csomagkezelőre épülő megoldás. Mindkét megoldás alapvetően egy módosított, megszabott szerkezetű, és metainformációkkal ellátott tömörített fájlformátumra, az ún. csomagra, és a rendszerben telepített csomagok nyilvántartására szolgáló adatbázisra épít. A csomagok jellemzően már lefordított alkalmazásokat tartalmaznak, ezért általában egy forráskódhoz tetszőleges számú csomag készülhet el. Egy csomag telepítésekor a rendszerben használatos csomagkezelőt szólítjuk fel az adott csomag telepítésére, például dpkg csomagkezelő esetén a joe nevű szövegszerkesztőt tartalmazó csomag telepítése: klapp:~# dpkg --install joe_3.1-0.2_i386.deb (Reading database ... 134167 files and directories currently installed.) Preparing to replace joe 3.1-0.2 (using joe_3.1-0.2_i386.deb) ... Unpacking replacement joe ... Setting up joe (3.1-0.2) ...

A szövegszerkesztő ettől a ponttól kezdve a rendszer bármely felhasználója számára elérhető a joe parancs segítségével. A rendszerbe telepített csomagok listáját szintén a csomagkezelő bocsátja rendelkezésünkre a fenti példát folytatva, ha kíváncsiak vagyunk a „jo” kezdőbetűjű csomagokra: klapp:~# dpkg --list "jo*" Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Halfinstal |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: upper ||/ Name Version Description +++-==============-================================================== ii joe 3.1-0.2 user friendly full screen text edito un john <none> (no description available) un jove <none> (no description available) un joystick <none> (no description available)

A listában szereplő csomagok közül csak a „joe” áll rendelkezésre, míg a többiek verziószáma ismeretlen. A csomag eltávolítása a nevének ismeretében szintén a csomagkezelő segítségével történhet: - 69 -



klapp:~# dpkg --remove joe (Reading database ... 134166 files and directories currently installed.) Removing joe ...

Az rpm csomagkezelő esetén az eljárás ezzel megegyező, azonban a paraméterezés eltérhet. Mindkét rendszerben a megfelelő man oldal állhat rendelkezésünkre bővebb információval. Hálózati csomagkezelés, automatikus frissítések

A legtöbb modern Linux rendszer már rendelkezik parancssoros, vagy grafikus ún. csomagkezelő-frontendekkel, melyek az előző részben említett manuális telepítési és törlési eljárásokat feleslegessé teszik. Ezek a frontendek a csomagok egymás közti függési viszonyainak kielégítésén kívül a legtöbb esetben internetes csatlakozási lehetőséggel is rendelkeznek, mely segítségével könnyen elérhetők az adott disztribúció biztonsági frissítései is. Nem egy esetben találkozhatunk a Windows update szolgáltatásaihoz hasonló automatikus frissítési rendszerrel is, azonban ha választott disztribúciónkban ez még nem lenne elérhető, esetleg az adott számítógép nem grafikus munkaállomásként, hanem kiszolgálóként funkcionál, érdemes lehet saját automatikus frissítési rendszert kidolgoznunk. Egy ilyen frissítési rendszer alapvető kelléke egy hálózati csomagkezelő frontend (például apt-get, yum), egy megfelelő internetes kapcsolaton keresztül elérhető biztonsági frissítéseket tartalmazó csomagtárhely és egy időzítési mechanizmus is. Utóbbira szolgál praktikus alapként a legtöbb rendszerben alapértelmezett cron hosszútávú ütemező, melynek központi konfigurációját az /etc/crontab fájl tartalmazza. Egy példát szolgáltat a rendszer naponta történő automatikus biztonsági frissítésére az alábbi konfigurációs részlet: 30 0

* * *

root

apt-get update; apt-get upgrade

A fenti sor bevitele után a hosszútávú ütemezőt újra kell indítanunk a változások érvénybeléptetésének érdekében. A sor eredményeképp 0:30-kor (30 0) minden nap (* * *) a root felhasználó nevében futtatásra kerül egy csomaglistafrissítés (update) és egy rendszerfrissítés (upgrade) az apt-get frontend segítségével, természetesen ehhez az szükséges, hogy frontend számára (annak konfigurációs állományaiban) egy megfelelő frissítésekkel szolgáló csomaggyűjtemény elérhetőségét is megadjuk. Bővebb információt az említett parancsok man oldalai adhatnak. 4.8.2.7 Hálózati kiszolgálók beállításai Az alábbiakban a Linux rendszereken leggyakrabban megtalálható hálózati szolgáltatásokkal kapcsolatos legfontosabb jellemző biztonsági szempontokra és konfigurációs lehetőségekre hívjuk fel a figyelmet.

- 70 -



Webszolgáltatások

A webszolgáltatások általában addig nem jelentenek problémát, míg egyszerű HTML állományok és képek terjesztésére használják őket, azonban attól a pillanattól, hogy a kiszolgáló oldalán a felhasználók látogatásaitól függően parancsok végrehajtására is sor kerül, ez a helyzet az ellenkezőjére változik, és elmondhatjuk, hogy az ilyen rendszerek a jelenlegi Internet legveszélyeztetettebbjei közé sorolhatók, mivel a felhasználói interakciót lehetővé tevő alkalmazások számos és szerteágazó módon okozhatnak problémákat. A legelterjedtebb webkiszolgáló, az apache a szabványos CGI felületen keresztül teszi lehetővé a kiszolgáló-oldali programfuttatást. Egyszerű példaként tekintsünk egy számlálót, mely az adott weboldalra látogatók számára megjeleníti, hogy eddig hányan nézték meg a lapot. A feladat végrehajtásához egy általános célú számlálóprogramot választottunk, melynek megjelenését a számlálóra történő hivatkozásban megadott paraméterek segítségével lehet befolyásolni. Látható, hogy egy hibásan megvalósított számlálóprogram segítségével a webszerver sebezhetővé válik, hisz egy rosszindulatú támadó a paraméterek megfelelő változtatásával távolról, szinte anonim módon akár általa kívánt műveletek végrehajtására is ráveheti a webszerver által futatott CGI programot. Különösen nagy veszélyt jelentenek a SUID jelzőbittel, különösen a root tulajdonú SUID bittel ellátott CGI állományok, hisz gyakorlatilag távoli root elérést biztosíthatnak a webszerveren keresztül. Látható, hogy minden egyes CGI alkalmazás biztonsági kockázata növeli a választott webkiszolgáló által önmagában jelentett kockázatot, ezért különös figyelemmel kell eljárni minden aktív tartalommal kapcsolatban. Nem képeznek ezalól kivételt például az apache kiszolgálóba bépülő PHP és PERL értelmező által feldolgozott oldalak sem, hiszen ezek biztonsági szempontból önálló CGI alkalmazásként foghatók fel. Figyelmet kell fordítanunk a felhasználóazonosításra is, mert hiába rejtjük jelszavas védelem mögé kényes webes alkalmazásainkat, ha a jelszó könnyen megszerezhető az azonosítást végző felhasználó számítógépén, vagy helyi hálózatán elhelyezett lehallgatóprogram segítségével. Ez ellen az apache esetében egyszerűen az SSL kiegészítés megfelelő konfigurációjával védekezhetünk. Egy virtuális domain SSL-es védelmét például az alábbi konfigurációs részlet mutatja: SSLCertificateFile /etc/apache2/ssl/cert.pem Listen 443 NameVirtualHost 225.40.37.62:443 SSLEngine on ...

Az SSL-tanúsítvány (certificate) megadása után arra utasítjuk az apache kiszolgálót, hogy az alapértelmezett 443-as TCP porton SSL-védelemmel ellátott, HTTPS szolgáltatásokat nyújtson. Ez persze önmagában még nem nyújt védelmet a lehallgatáson kívül semmi ellen, azonban az egyes funkciók védelmét

- 71 -



is megoldhatjuk egy megfelelő helyen, például a fenti virtuálishost-definícióban elhelyezett jelszavas védelemmel: AuthName "titkos lap neve" AuthType Basic AuthUserFile /var/www/titkos/.htpasswd Require valid-user

A .htpasswd fájl a felhasználónév/jelszó-párosokat tartalmazza, tartalmát a htpasswd parancs segítségével bővíthetjük, a többi mező tartalma szinte fixnek tekinthető, a „titkos lap neve” oldalanként célszerűen változó paraméter. Bővebb információért érdemes elolvasni az apache ide vonatkozó dokumentációját. Proxy-szolgáltatások

Hálózati szolgáltatások körében jellemzők az ún. proxy, vagy gyenge magyar fordítással „átjátszó” jellegű alkalmazások, melyek általában a közös Internetelérést próbálják segíteni, vagy a gyakran használt állományok tárolásával, vagy egyszerűen a hozzáférés lehetőségének puszta megadásával. Fontos figyelmet fordítani az ilyen alkalmazások hozzáférésvédelmére, mivel könnyen kihasználhatók az Internet más számítógépeinek támadására a proxy üzemeltetőjének nevében. Azokat a proxykat, melyek a világ minden csücskének engedélyezik a hozzáférést, szakszóval szokás „open proxy”-nak is nevezni, sok nemzetközi szervezet nyújt tiltólistákat, melyek az ilyen gépek kizárását teszik lehetővé web- és egyéb szolgáltatók számára, ebből is látszik, milyen fontos figyelmet fordítani a kérdésre. Az egyik elterjedten használt, alapvetően webes proxy a squid, melynek védelmét az előzőekben említett módszerekkel iptables, vagy tcpwrappers segítségével is megoldhatjuk, de maga az alkalmazás is lehetőséget nyújt ilyen irányú korlátozások bevezetésére, melyre egyszerű példát nyújt az alábbi konfigurációs részlet: acl all src 0.0.0.0/0.0.0.0 acl helyi src 127.0.0.1/255.255.255.255 http_access allow helyi http_access deny all

A fenti példában egy „helyi” elnevezésű csoportot (a neve itt ACL – access control list) definiálunk, melynek tagjai lehetnek azok, akik a 127.0.0.1 címről adják fel kéréseiket (a / jel utáni rész az alhálózati maszk), az „all” nevű csoportnak hasonló logikával minden IP-cím tagja. A középső sorban engedélyezzük számukra a proxy-kiszolgáló elérését, majd végül tiltjuk a bármely más címről történő elérést. Levelezési szolgáltatások

A második legelterjedtebb internetes szolgáltatás, a levelezés, másként SMTPkiszolgálás, az előzőekben leírtakhoz hasonlóan súlyos problémákkal küzd. Gyakori az e-mail-szolgáltatások vírusok által történő kihasználása, mely ellen a levelezőszerverre telepített vírusszűrési megoldással (lásd: mailscanner, amavis) - 72 -



védekezhetünk, melynek pontos konfigurációja túlmutat jelen dokumentum keretein, főként mivel nem is az adott rendszer biztonsági tényezőjéről van szó, hisz a kiszolgáló a vírusokat legfeljebb továbbítja, maga jellemzően nem fertőződhet, azonban megemlítünk egy elterjedt konfigurációs hibát, melyet a kéretlen levelek szűrésére alkalmazott programokban is gyakran elkövetnek. A hiba forrása általában a konfigurációt végző személy tudatlan jóindulatában keresendő, mert helyes döntésnek feltételezi a fertőzött levelek feladóinak értesítését. Mivel azonban a legtöbb rosszindulatú levélküldő automata napjainkban már hamisítja a feladót, az ilyen értesítők az esetek nagy részében célt tévesztenek, ezzel legfeljebb rémület vagy bosszúság okozására alkalmasak. A proxy-szolgáltatások esetén leírt problémához hasonló az ún. „open relay” kategóriájú konfigurációs hiba, mely azt eredményezi, hogy egy levelezési kiszolgáló bárki számára elfogad leveleket. A proxyknál említett tiltólisták a levelezési rendszerek körében még aktívabban működnek a rengeteg kéretlen üzleti célú levél („spam”) miatt, ezért itt is célszerű megtenni a megfelelő ellenintézkedéseket. Mivel egyes helyzetekben nem megoldható a legitim levélforrások IP-cím szerinti meghatározása, fontos lehetőség a kevélküldés elötti kliensazonosítás. A korai levelezőkliensek nem támogattak levélküldés elötti azonosítási mechanizmusokat, viszont a levélfogadás során már abban az időben is természetesen szükséges volt a levelesládák elkülönítése. A POP3 levélfogadási protokoll azonosítási mechanizmusát használja ki az ún. „POP before SMTP” mechanizmus, mely csak akkor engedi egy forráscímről a levelek továbbküldését, ha ugyanerről a címről a közelmúltban sikeres POP3 bejelentkezést hajtottak végre. A modern levelezőkliensek kivétel nélkül támogatják az ún. SASL autentikációt, mely segítségével a továbbküldés (relaying) megfelelő keretek közé szorítható. Linux rendszerekben a feladat megoldásához szükséges egy ún. SASL autentikációs démon (neve általánosan saslauthd) telepítése, mely az azonosítási szolgáltatásokat nyújtó kiszolgálók, például az SMTP-kiszolgáló számára lehetővé teszik különböző azonosítási szolgáltatások, kezdetben és alapértelmezésben célszerűen a Linux felhasználóazonosítási mechanizmusa, a PAM rendszeren keresztüli felhasználói autentikációt. Egy elterjedt levelezőkiszolgálón (ún. Mail Transport Agent, MTA), a postfix alkalmazáson keresztül lássunk egy konkrét beállítási példát az ismertetett felhasználói autentikáció megvalósítására (részlet az /etc/postfix/main.cf állományból): smtpd_sasl_auth_enable = yes smtpd_sasl_exceptions_networks = 127.0.0.0/8 smtpd_sasl_application_name = smtpd

A második sor a helyi hálózatról való levélküldés SASL azonosítás nélküli engedélyezését szolgálja, az utolsó sorban pedig a saslauthd számára jelezzük a szolgáltatást igénybevevő alkalmazás nevét, mely alapján az azonosítási szolgáltatások finomhangolása végezhető el.

- 73 -



A webszolgáltatások esetében leírt jelszólehallgatási problémával itt is találkozhatunk, melynek megoldására az ott leírtakkal egybecsengően a TLS/SSL csatornavédelmi mechanizmust célszerű felhasználnunk. Az előző példában választott postfix rendszer esetében ez a következőképp valósítható meg: smtpd_use_tls = yes smtpd_enforce_tls = no smtpd_tls_CAfile = /etc/postfix/tls/cacert.pem smtpd_tls_cert_file = /etc/postfix/tls/cert.pem smtpd_tls_key_file = $smtpd_tls_cert_file

A második sorban a TLS kötelezővé tételét kapcsoljuk ki, erre akkor lehet szükség, ha nem minden kommunikációs partner támogatja ezt a fajta védelmi mechanizmust. Az utolsó három sorban a hitelesítő hatóság által kibocsátott tanúsítványokat és a kommunikáció során használt titkos kulcsot tartalmazó állományok elérhetőségét adjuk meg az apache esetén leírtakhoz hasonlóan. Távoli adminisztráció

Linux rendszereknél gyakori felhasználói igény a távoli bejelentkezés és adminisztráció lehetősége. Napjainkban már nem jellemző a titkosítatlan kommunikációs csatornákat használó telnet protokoll használata, mindenütt az ssh (secure shell) megoldással találkozhatunk, melynek funkcióit Linux alatt az OpenSSH programcsomag látja el. Az OpenSSH biztonsági szempontból meglehetősen fejlett alkalmazáscsomag, ám kritikus fontosságú szerepe miatt érdemes folyamatos frissentartására figyelmet fordítani, ugyanis a múltban már több komoly sebezhetőséget felfedeztek benne. Az ssh program használata során fontos tisztában lennünk a legfontosabb hibalehetőségekkel, melyek mindegyike a rendszer kulcskezelésével kapcsolatos. Az egyik ilyen hiba a kulcsalapú azonosítás esetén fordul elő. Az OpenSSH lehetőséget nyújt a felhasználó számára egy jelszóval védett kulcspár generálására az ssh-keygen segédprogrammal, melynek publikus összetevőjét a megfelelő távoli kiszolgálókra eljuttatva a kulcspár jelszavának ismeretével végezhető el az azonosítás. Ez biztonsági szempontból is előnyös lehet, mert nem ad lehetőséget a távoli gép kompromittálása esetén sem jelszólehallgatásra. Mivel a kulcspár titkos komponense reményeink (!) szerint nem kerül ki a számítógépünkről, hajlamosak lehetünk gyenge jelszót választani, sőt a rendszer engedélyezheti a jelszavas védelem teljes elhanyagolását is. Biztonsági szempontból talán nem is szorul bő magyarázatra, hogy ez rossz gyakorlat. A jelszó ismételt begépeléséből származó kényelmetlenségeket enyhíthetjük az ssh-agent kulcskezelő használatával, melynek bővebb használatáról az OpenSSH dokumentációjában olvashatunk. Az egyik legfontosabb biztonsági szolgáltatás az ún. ssh host fingerprinting, mely segítségével a csatlakozó kliensek meggyőződhetnek a távoli kiszolgáló „személyazonosságáról”. Ennek érdekében az első csatlakozáskor minden távoli gép „ujjlenyomatát” egy helyi adatbázisban tárolják el, melynek változásáról figyelmeztetik a csatlakozni kívánó felhasználót. Fontos, hogy az alábbihoz - 74 -



hasonló váratlan hibaüzenetek felett ne lépjünk gyanakvás, vagy utánajárás nélkül tovább: [root@klapp:~]-$ssh tavoli.gep WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 36:ac:21:41:84:6f:44:2d:a2:71:5a:42:32:be:1c:a2. Please contact your system administrator. Host key verification failed.

Fájlszolgáltatások

Az Internet történetének okai folytán gyakorlatilag komolyabb biztonsági óvintézkedésre lehetőséget nem nyújtó FTP szolgáltatás használatának csak nagyon gondosan felügyelt körülmények közti, például kizárólag helyi hálózati, vagy csak anonymous (azonosítás nélküli) letöltési lehetőségeket nyújtó felhasználását javasoljuk. Hasonló javaslatokkal élünk a windowsos hálózati kommunikációs szolgáltatásokat nyújtó samba szolgáltatással kapcsolatban is, azzal a kiegészítéssel, hogy itt a csak olvasható hozzáférés sem tekinthető biztonságosnak a protokoll összetettsége miatt. Fájlok csak olvasható megosztására a HTTP protokoll, vagyis az apache vagy valamelyik egyszerűbb, ezért potenciálisan kevesebb hibalehetőséget tartalmazó webkiszolgáló javasolható, a rendszer felhasználóinak a távoli fájlfeltöltést pedig célszerűen az OpenSSH programcsomagban is alapszolgáltatásként megtalálható scp program segítségével tehetjük lehetővé. Internetes alapszolgáltatások

Linux rendszerekben a ritkán használt hálózati szolgáltatások egy univerzális szolgáltató alkalmazáson, az ún. internet-szuperszerveren (inetd) keresztül érhetők el. Ezen szolgáltatások általában nem feltétlenül szükségesek, ezért érdemes rendszerünk ezen hálózati felületét is a lehetőségekhez mérten szűkre szabni az /etc/inetd.conf konfigurációs fájl megfelelő átszerkesztésével. GUI-szolgáltatások

A grafikus felület szolgáltatásai rendkívül szerteágazók lehetnek. Mivel a grafikus felület futtatása erősen ellenjavalt rendszergazdai (root) privilégiumokkal, a legtöbb esetben biztonsági szempontból a felhasználó biztonságilag tudatos viselkedése elegendő a rendszer megfelelő használatához. Az X kiszolgáló grafikus szolgáltatásai a legtöbb disztribúcióban nem érhetők el tetszőleges külső számítógépről, azonban erről gondoskodhatunk megfelelő tűzfalbeállítások érvénybeléptetésével is, illetve minden felhasználó egyénileg szabályozhatja a saját grafikus felületéhez történő hozzáférési lehetőségeket az xhost parancs segítségével. Például az xhost - utasítás csak az adott X környezetet futtató felhasználó számára engedélyezi a hozzáférést, az xhost + parancs pedig mindenki számára engedélyezi a csatlakozást, melybe a X - 75 -



kiszolgáló megfelelő beállításai esetén a távoli internetes állomások is beleértendők. 4.8.2.8 Honnan tudhatom, hogy feltörték? Az alábbiakban megpróbálunk egy könnyen végigkövethető eszköztárat adni arra az esetre, ha gyanú merülne fel bennünk Linux-alapú rendszerünk épségét illetőleg. Ha gyanús jelekre akadunk, fontos megőriznünk hidegvérünket, ugyanis meggondolatlan „óvintézkedésekkel” könnyen eltüntethetjük a behatolás forrására utaló nyomokat, vagy akár újabb károkat is okozhatunk. A legegyszerűbb, legkevesebb szakértelmet követelő eszköz a chkrootkit nevű alkalmazás, mely az ismert rootkitek („feltőrőkészletek”) nyomai után kutat, sajnos azonban előfordulhatnak olyan fájlok vagy helyzetek, mikor ezen az úton hamis riasztáshoz jutunk, ezért nem szabad egy „INFECTED” üzenet után rögtön a rendszer újratelepítésébe fognunk, azaz a program jelzéseit fenntartással kell fogadnunk. Ennek ellenére a chkrootkit hasznos lehet sok esetben, amikor ún. „script kiddie”-k (nem komoly tudással rendelkező, ám annál ambíciózusabb támadók) akcióit kell lefülelni, amelyeket többnyire valamely készen elérhető, általános vagy gyakori sebezhetőségeket kereső és kihasználó „rootkit”-eket (feltörőkészleteket) felhasználva hajtanak végre.

Futó processzek Gyanút kelthet egyszerűen a rendszer lassabb működése, vagy a futásra kész processzek számának gyanúsan magas értéke is. Ez utóbbi információt a w parancs kimenetének első sorában a „load average” értékből olvashatjuk ki, három, egyre növekvő időintervallumra (rendre 1, 5, 15 perc) vonatkozóan. A normális értékek tipikusan a rendszerben található processzorok számánál nem sokkal nagyobbak: klapp:~# w 11:22:00 up

2:55,

1 user,

load average: 0.33, 0.38, 0.25

Nagyobb szakértelmet és némi kézimunkát igényel a /proc könyvtár tartalmának, pontosabban a processzazonosítók listájának (PID) összevetése a ps ax parancs kimenetével, mivel az utóbbi utasítást gyakorta kicserélik, hogy rejtve maradhassanak az esetleges behatolás nyomai, a /proc azonban sokkal nehezebben hamisítható. Egyébként is érdemes a rendszer összes futó processzét áttekinteni, hátha szokatlanul magas CPU-terhelésű, vagy egyszerűen nem rendszerünkre való alkalmazásokat találunk. Hasznos információt rejthet a nyitott állományok, portok és egyéb speciális eszközök listája is, melyet az lsof parancs segítségével kérdezhetünk le. Azok a processzek, melyek látszólag szokatlan bejegyzéseket tartanak nyitva, további vizsgálatot igényelhetnek.

Megváltozott fájlok Hasznos lehet még frissen létrehozott fájlok után kutatnunk a rendszer fontosabb könyvtáraiban, ugyanis a fájlok létrehozási dátumának utólagos

- 76 -



módosítására szintén meglehetősen kevés lehetőség áll egy támadó rendelkezésére. A kutatáshoz hasznunkra válhat a find parancs, mely segítségével a szokásosnál frissebb, nagyobb, vagy SUID jelzéssel rendelkező állományok gyors áttekintésére nyílhat lehetőségünk. A rendszer csomagkezelőjétől általában megtudható, mely csomagok milyen fájlokat tartalmaznak, sőt, egyes esetekben még pontos méretinformációkkal is szolgálhat rendszerünk. Érdemes lehet a szokatlan fájlok eredetének ilyen irányú megvizsgálása is. Az egyes fájlok pontosabb azonosítását segítheti a file alkalmazás, mely tartalmi követelmények alapján képes típusmeghatározásra, vagyis a speciálisan, vagy megtévesztő módon elnevezett állományok felderítésére hasznos segédeszköznek bizonyulhat. A fájlok változásainak nyomonkövetésére megelőző eszközként alkalmazhatók olyan eszközök, melyek a fájlrendszeren rendszeresen végighaladva ellenőrzőösszegeket képeznek a fontos területekről, melyek változásáról aztán jelentést tesznek a rendszergazdának. Ilyen alkalmazás például a tripwire, az fcheck vagy az aide.

Gyanús konfigurációs és naplóbejegyzések Az /etc könyvtárban számtalan helyen nyílhat lehetőség egy támadó számára olyan módosítások elhelyezésére, melyek lehetővé teszik a rendszer újraindítása után az esetleges backdoorok („hátsó kapuk”), rejtőzködő és károkozó programok újbóli elindítását. A legfontosabb ilyen helyek: •

az /etc/inittab fájl és az /etc/rc.d könyvtár, melyek az init processz által automatikusan elindítandó alkalmazásokat tartalmazzák

•

az /etc/crontab, valamint az /etc cron szóval kezdődő egyéb könyvtárai, melyek a hosszútávon ütemezett alkalmazásindításokat tartalmazzák

A /etc/passwd fájlban tekintsük át a rendszer felhasználóinak listáját, ellenőrizzük le, hogy valóban csak a root felhasználó rendelkezik-e :0: felhasználói azonosítóval, és nincsenek-e olyan felhasználók, melyekről nem tudunk. A rendszer alapértelmezett naplóbejegyzéseit tartalmazó /var/log könyvtárban érdemes lehet a részleges vagy teljes törlés nyomai után kutatnunk. Részleges törlésre utalhat a hosszabb, bejegyzések nélkül eltelt időszak. A rendszerbe való bejelentkezések és azok forrásának naplóját adja a last program, a lastlog parancs pedig a rendszer felhasználóinak legutóbbi bejelentkezéseit mutatja. Mindkét kimenetben érdemes károkozásra és szokatlan tevékenységekre, például szokatlan helyről vagy időben történő bejelentkezésre utaló nyomok után kutatnunk.

- 77 -



Szokatlan hálózati működés Számítógépünk hálózati forgalmát a tcpdump, vagy az ennek grafikus felületet adó ethereal program segítségével is megvizsgálhatjuk. Kutassunk gyanús forgalom után! A számítógép hálózati interfészei és route táblája is megváltozhat egyes rosszindulatú felhasználási módok eredményeképpen. Az ifconfig és route parancsokkal ellenőrizzük, hogy rendszerünk nem rendelkezik-e szokatlan IPcímekkel és hálózati interfészekkel! Az nmap program hasznos lehet egy Linux számítógép távolról történő felmérésére, segítségével szokatlan kifelé nyújtott szolgáltatások nyomára akadhatunk.

4.8.3

Tűzfalak

A tűzfalak feladata a hálózati forgalom megszűrése, ezáltal a nem kívánt hálózati forgalom megakadályozása. Az elnevezés nem véletlen, a hálózati tűzfal célja a veszélyes kódok, tartalom tovaterjedésének megakadályozása. Kijelenthető, hogy a tűzfal alapvető védelmi eszköze az informatikai rendszereknek. 4.8.3.1 A tűzfalak típusai A tűzfalakat többféle módon csoportosíthatjuk. A működés elve alapján lehet: •

Csomagszűrő tűzfal (packet filter): a hálózati forgalom szűrését alacsonyszintű jellemzők alapján (IP cím, protokoll) történik. A csomagszűrő tűzfalak felépítése egyszerű, működésük gyors. A csomagszűrő tűzfal nem tesz lehetővé nagyon összetett szűrési lehetőségeket. A csomagszűrők tovább bonthatóak állapotmentes és állapottartó fajtára. Az állapottartó csomagszűrő ugyan csomag szinten szűr, de a szűrés során elemzi és figyelembe veszi az addig forgalmat.

•

Alkalmazási szintű átjáró (application level gateway, proxy): ez a fajta tűzfal az adott alkalmazás (web, levelezés, stb.) adatforgalmát elemzi és dolgozza fel. Az alkalmazás szintű tűzfal igen kifinomult szűrési lehetőségeket tesz lehetővé, azonban felépítésük összetett és minden alkalmazás számára külön kell felépíteni.

•

A fenti kettő kombinációja. Rendszerint a hatékonyság érdekében kombinálni szokás a két megoldást.

A védendő célpont alapján: •

Személyes tűzfal (personal firewall): egy számítógépet vagy eszközt védő tűzfal. A tűzfal szoftver magára a védendő eszközre van telepítve. A hálózati tűzfalakhoz hasonló csomagszűrő képességeken kívül fontos tulajdonsága, hogy észlelni tudja az adott gépen futó alkalmazások által kezdeményezett hálózati kapcsolatokat így a nem biztonságos alkalmazásokat meg tudja gátolni a kommunikációban, illetve észleli, ha valamely kártékony kód hálózati forgalmat generál.

- 78 -


•


Hálózati tűzfal (vagy egyszerűen tűzfal): egy teljes hálózatot védő tűzfal. Rendszerint a belső hálózat és a külvilág csatlakozási pontján helyezkedik el, olyan módon, hogy a teljes fogalom áthalad rajta. Ez a tűzfal elsősorban a belső hálózatot védi a kívülről jövő nem kívánatos forgalom ellen, de másodsorban védi a külvilágot az esetlegesen saját hálózatunkból induló támadások ellen.

4.8.3.2 Jellegzetes tűzfal architektúrák Tűzfalat leggyakrabban belső hálózat (intranet) védelmére használunk. Ebben az esetben a belső és a külső hálózat (internet) kapcsolódási pontján helyezkedik el a tűzfal, amelyen minden hálózati forgalom áthalad és csak a tűzfalon keresztül, ellenőrzötten haladhat át bármilyen forgalom az internet és az intranet között. Ennél összetettebb megoldás a demilitarizált zóna (DMZ) használata. Az intranet és az internet mellett megjelenik a DMZ, amely arra szolgál, hogy a külvilág felé szolgáltatást nyújtó eszközök helyezkedjenek el itt. Ebben az esetben forgalomszűrés történik az internet-DMZ, az internet-intranet és a DMZ-intranet között is. Ez a megoldás arra szolgál, hogy a kívülről elérhető szolgáltatások feltörése esetén is legyen mégegy védelmi vonal a belső hálózatig. Belső hálózaton belül is előfordulhatnak tűzfalak, amelyek segítségével a belső hálózat további védelmi zónákra osztható. A személyes tűzfalak csak egyetlen gépet védenek, rendszerint hálózati tűzfalakkal kombinálva célszerű őket használni. 4.8.3.3 Címfordítás Nem szorosan tűzfal funkció, de szinte minden esetben tűzfalakkal együtt alkalmazzák, illetve a tűzfal valósítja meg a címfordítást (NAT – Network Address Transaltion, hálózati cím fordítás). Az egyes hálózati eszközöket azonosító IP címek véges erőforrások. Az internet elérést nyújtó szolgáltató csak véges számú IP címet tud rendelkezésre bocsátani, így elvileg csak annyi eszköz lenne képes hálózati kommunikációra, amennyi IP cím rendelkezésünkre áll. Szerencsére felismerhető egy jellegzetesség a belső hálózatok működésében. A legtöbb kliens jellegű eszköz (jellegzetesen irodai számítógépek) a küldő internet felé csak kezdeményeznek kapcsolatokat, de nem fogadnak onnan, sőt kívánatos, hogy kívülről ne lehessen kapcsolatot kezdeményezni. Kapcsolatot csak a belső hálózatból kell elfogadniuk, pl. megosztott állományok kiszolgálására. A kiszolgálóknak, mint pl. a web kiszolgálónak, vagy levelezés kiszolgálónak értelemszerűen képesnek kell lenniük kapcsolat indítására és fogadására is. Kiszolgálókból azonban rendszerint kevés van, így a rendelkezésre álló IP címek is elegendőek lehetnek. Ez alapján a következő megoldást lehet alkalmazni: •

A belső hálózatban használjunk privát IP címeket! A szabványok különböző címtartományokat definiálnak belső használatra. Ilyen címtartományok a (10.0.0.0 - 10.255.255.255, 172.16.0.0 - 172.31.255.255 és 192.168.0.0 - 192.168.255.255). Ezek alapján a belső hálózatunk szinte korlátlan méretű lehet, hiszen ezekben a tartományokban elegendő címtér

- 79 -



áll rendelkezésre. Ha a belül lévő eszközöknek ebből a tartományból osztunk címeket, akkor az egymással való kommunikáció már megoldott. •

A külső kapcsolatra néhány, vagy egy IP cím elegendő, ha megoldjuk, hogy a kifelé irányuló kapcsoltnál egy eszköz (a NAT) a benti címet áttranszformálja a külső címre. A külvilág számára úgy látszik, mint ha a kapcsolatot a NAT eszköz indította volna. A visszaérkező adatok is a NAT eszközhöz érkeznek, amely „tudja”, hogy mely kapcsolathoz mely belső cím tartozik, mivel a kapcsolat felépítésekor ezt eltárolta. A címeket ismét kicseréli az eredetire és továbbítja a belső hálózatba. Így egy belülről indított kapcsolat működik, minden belső eszköz képes elérni a külvilágot, pusztán a rendelkezésre álló egyetlen IP cím segítségével.

•

Kívülről érkező kapcsolatok esetében más a helyzet. A NAT eszköz ilyenkor magától nem tudja, hogy mely belső gépet szeretnék kívülről elérni. Így a kapcsolat nem lesz sikeres. Lehetséges azonban a NAT eszközben olyan statikus beállításokat előre felvenni, amely alapján a külső IP cím egy adott portjára (pl. web esetén a 80-asra) beérkező forgalmat egy belső kiszolgálóhoz irányítja, ugyancsak címtranszformáció segítségével. Így tehát lehetővé válik szolgáltatások nyitására a külvilág felé.

Fontos tudni, hogy bizonyos esetekben a NAT nem jó megoldás, mert bizonyos alkalmazások nem tűik el a címek cseréjét, de az esetek igen nagy részében nagyon jól használható az IP címek szűkösségének elkerülésére. Ugyanakkor a NAT-nak van egy biztonsági szempontból hasznos mellékhatása, elrejti a belső hálózatot. A külvilág csak az egyetlen külső IP címet látja, és nem képes elérni belső számítógépeket. Ez nagyon jó első lépcsős védelem. Természetesen ez nem véd olyan veszélyek ellen, mint a más módon (pl. levélben, vagy belülről kezdeményezett letöltéssel) átvitt kártékony kódok. Így önmagában a NAT nem alkalmas védelemnek, de fontos komponens. Természetesen megfelelő mennyiségű IP cím esetén nem szükséges NAT-ot használni, a belső hálózat elrejtése megoldható megfelelő tűzfal szabályok alkalmazásával. A NAT megvalósítására különböző eszközök léteznek, rendszerint a hálózati kapcsolatot biztosító útválasztó, vagy tűzfal képes NAT-olásra. De egy Windows vagy Linux alapú PC is képes az internetkapcsolat megosztására. Ennek ellenére nem javasolt asztali gépeket használni ilyen célra, sokkal egyszerűbb megoldás dedikált eszköz használata. 4.8.3.4 VPN A VPN a virtuális magánhálózatot jelent. Ez arra szolgál, hogy a belső hálózatot egy virtuális kapcsolaton keresztül összekössük valamely más helyen lévő hálózattal vagy eszközzel. Ez a virtuális kapcsolat titkosított, így a nyilvános internet is használható a belső hálózathoz való biztonságos csatlakozásra. A VPN alkalmas arra, hogy távolról (otthon, szálloda, stb.) úgy kapcsolódjunk a belső hálózathoz, mint ha közvetlenül ott lennénk, így a VPN jól használható távmunka stb. céljára. A VPN megvalósítása rendszerint – részben – a tűzfal

- 80 -



feladata, de nagy teljesítményigény esetén dedikált VPN eszközt lehet alkalmazni. 4.8.3.5 Tipikus tűzfal beállítások Az elsőszámú tűzfal szabály: minden tilos, ami kifejezetten nincs megengedve! Ez azt jelenti, hogy alaphelyzetben mindenforgalmat tiltani kell, majd csak azt megengedni, amelyre valóban szükség van. A környezet ismerete nélkül pontos beállítási tanácsokat nehéz adni, de le lehet fektetni néhány alapelvet: •

Kívülről jövő kapcsolatot nem engedélyezünk, illetve csak a valóban szolgáltatást nyújtó eszközök, és lehetőleg DMZ-ben elhelyezkedő eszközök felé. Ha NAT-ot alkalmazunk, ez a feltétel gyakorlatilag automatikusan teljesül.

•

Belülről kifelé irányuló kapcsolatot csak azokra a protokollokra/szolgáltatásokra engedélyezünk, amelyre szükség van. Ezzel nem csak a munkaidőben történő csevegést, stb. tudjuk megakadályozni, de a szándékolt, vagy véletlen módon belülről induló támadásokat (pl. vírus terjedése), amely a komoly erkölcsi károk mellett anyagi és információ biztonsági kárt is jelenthet.

•

Az előzőhöz kapcsolódóan kifejezetten tiltani kell az intranetből az internet felé irányuló levelezés (SMTP) kapcsolatokat. Levelet továbbítani csak a levelező szerveren keresztül szabad, ezért egyedül neki van megengedve a levél továbbítása. Ezzel nagymértékben tudjuk csökkenteni a levél útján terjedő vírusok kijutását, illetve az általuk képviselt egyéb veszélyeket (létezik olyan vírus, amely a számítógépen található dokumentumokat küldi el véletlen címekre!)

Ismételten hangsúlyozzuk, hogy a tűzfal akkor hasznos komponense a védelmi rendszernek, ha a környezetnek megfelelően van beállítva. A tűzfal nem lehet öncélú eszköz, az igények és a kockázatelemzés alapján kell kidolgozni azokat a beállításokat és kompromisszumokat, amelyeket majd a tűzfalban kell forgalomszűrésként megvalósítani.

4.8.4

Kártékony kódok

Minden rosszindulatú kódokkal foglalkozó írás első és legnehezebb feladata az, hogy meghatározza, mi is az, amit a köznyelv vírus alatt ért, milyen alfajai vannak és azokat hogyan csoportosítjuk. A szakirodalomban rengeteg meghatározást találhatunk, ezért az alábbiakban csak a leggyakoribb, illetve napjaink legfontosabb típusaival foglalkozunk. Ezek a vírusok, a férgek, a trójaiak, a hátsókapuk és a rootkitek. A vírusok olyan programok, melyek úgy képesek sokszorosítani magukat, hogy saját kódjukat egy ártalmatlan programhoz csatolják. A vírusok csak úgy tudnak egyik számítógépről a másikra terjedni, hogyha a fertőzött fájlt hálózaton vagy valamilyen adathordozón továbbítják. Tipikusan pusztító szándékkal írják meg őket, pl. fájlokat törölnek le. Az ilyen típusú kártékony kódok egyre kevésbé vannak jelen napjainkban. - 81 -



A férgek annyiban különböznek a vírusoktól, hogy nem csatolják a kódjukat más fájlokhoz, hanem saját maguk képesek futni és így rombolni. A másik különbség, hogy képesek önmagukat terjeszteni. Általában a belső hálózaton vagy az interneten küldik szét önmagukat. Sokszor az interneten keresztül is képesek megfertőzni a számítógépet egy programhibát kihasználva. Leggyakrabban emailben kapják meg a felhasználók, mellékletként. Valamilyen megtévesztéssel megpróbálják elérni, hogy a felhasználó futtassa le az e-mail mellékletét, így meg tudják fertőzni a számítógépet, aminek internet kapcsolatát kihasználva terjesztik magukat. A trójai olyan kártékony program, mely legitim alkalmazásnak álcázza magát. Sokszor a felhasználó egy internetről származó program telepítésével egy trójai programot is telepít a számítógépére. A trójai program pedig valamilyen nem kívánt funkciót valósít meg, pl. jelszófigyelő programot helyez el a számítógépen, azaz kémkedik a felhasználóról. A hátsókapuk olyan alkalmazások, melyek célja tipikusan a fertőzött számítógéphez való távoli hozzáférés biztosítása, lehetőleg észrevétlenül. Hátsókapuk férgekkel vagy trójaiakkal is kerülhetnek a számítógépekre. A tömegesen telepített hátsókapukon keresztül távirányíthatóvá vált számítógépek ezrei alkotják az ún. zombihálózatot, melyek a tömeges kéretlen e-mail küldések és bizonyos szervezetek szerverei ellen indított túlterheléses támadások mögött állnak. Az összes fenti kártevőnek a legfontosabb, hogy rejtve tudjanak maradni a megfertőzött számítógépen. Ebben segítenek a rootkitek, melyek fájlokat, könyvtárakat, regisztrációs bejegyzéseket vagy folyamatokat képesek elrejteni a felhasználó és sokszor a víruskereső programok elől is. A kártékony kódok folyamatosan fejlődnek, szinte minden évben valamilyen új fertőzési technikát ismerhetünk meg. 2006-ban a rootkittel támogatott fertőzések elterjedése várható. Szemléletes megnézni, hogy hogyan terjed egy féreg, például a Sober.Y. Első lépésként a felhasználó kap egy e-mailt, melynek van egy melléklete.

- 82 -



27. ábra: Sober.Y vírus (forrás: F-Secure)

A Sober.Y féreg esetén az üzenet feladójaként az FBI jelenik meg, és azt jelzik a felhasználónak, hogy több illegális weboldalon naplózták a számítógépét. Egyúttal kérik, hogy válaszoljon a csatolt tömörített fájlban található kérdésekre. A mit sem sejtő felhasználó megnyitja a ZIP fájlt, és elindítja a benne található állományt. Ez az állomány a féreg, mely elkezdi megfertőzni a gépet. Először néhány fájlt másol a számítógépre, majd néhány bejegyzést helyez el a regisztrációs adatbázisban. Ezzel biztosítja, hogy a számítógép minden indításánál betöltődjön. A következő lépése az, hogy összegyűjti a számítógépen tárolt e-mail címeket, majd azokra is elküldi saját magát. Bizonyos férgek emellett még hátsókapukat is nyitnak a számítógépen.

4.8.5

Levelezés

Az elektronikus levelezés (email) elengedhetetlen a modern közigazgatásban, ugyanakkor nem kellően kialakított rendszerek és eljárások jelentős kockázati tényezőt jelentenek. A levelezéssel összefüggő közvetlen és közvetett kockázatok: •

Vírusok és egyéb kártékony kódok. Jelenleg az email a „legnépszerűbb” terjesztő közeg kártékony kódokra. A különböző levélen át terjedő vírusok és férgek különböző módon, pl. a felhasználó címjegyzékét használva, saját magukat küldik tovább. Ezek a módszerek kihasználják az emberi tényezőt, mivel rendszerint arra építenek, hogy az ismerőstől kapott levelet kinyitjuk és futtatjuk a mellékelt programokat.

•

Információ kiszivárogtatás. Akár kártékony kódokon keresztül, akár véletlen vagy szándékolt módon a levelezés hatékony módja információ kijuttatásának. Léteznek féreg programok, amelyek véletlenszerűen dokumentumokat küldenek ki levélben, de volt már ara is példa, hogy valaki tévedésből a magánlevélbe szánt bizalmas dokumentumot egy nyilvános levelezési listára küldte ki.

- 83 -


•


Kéretlen reklámlevelek (Spam). A kéretlen reklámlevelek továbbítása, tárolása, kitörlése időbe és infrastruktúrába kerül. Ugyanakkor könnyen előfordulhat, hogy a sok kéretlen levél között „elvesznek” a fontos levelek.

A levelezési problémák kezelése több szinten lehetséges: •

Tartalomszűréssel: a levelezést kezelő kiszolgálón víruskeresőt kell használni, amely a beérkező, de a címzetthez még el nem jutott levelet ellenőrzi, és szükség esetén szűri. A tartalomszűrés során nem csak vírusokat, de spam-et vagy bármilyen más tartalmat is szűrhetünk. A legtöbb víruskereső szoftver gyártójának van olyan terméke, amelyek kereső modulként használhatóak a népszerű levelező kiszolgálókon. A kifelé irányuló levelezés is szűrhető. Különböző szintű szűréseket alkalmazhatunk, pl. csatolmányokat nem fogadunk el kívülről, de a belső levelezésben engedélyezzük.

•

A levelező klienseken is telepíteni kell víruskeresőt, amivel a kiszolgáló szintű szűrésen átjutó kódokat foghatjuk el.

•

Felhasználók oktatása: az internet levelezés önmagában nem tekinthető sem megbízhatónak, sem biztonságosnak. Könnyen hamisítható a feladó, a tartalom. A levelek nem feltétlenül érnek célba. Ezeknek a veszélyeknek minden felhasználónak tudatában kell lennie. Gyanús tartalmú levél esetében (ahogy ez az emberi tényezőről szóló fejezet mutatja) más csatornán meg kell győződni a tennivalókról.

•

Titkosítás, elektronikus aláírás. Titkosítás és elektronikus aláírás használatával a levelezés biztonsága és megbízhatósága nagyban javítható. Amennyiben ilyen szintű biztonságra van igény, használni kell ezeket.

4.9 Titkosítás Általában mindent megteszünk, hogy biztonságban tudjuk az információ. Jó lenne, ha csak az látná, akire tartozik. Biztosak akarunk lenni abban, hogy a kapott információ egyezik-e azzal, amit elküldtek nekünk. Ismerni szeretnénk a kommunikációban résztvevő szereplőket és az adat forrását. Az információt szeretnénk konkrét személyhez kötni. Meg akarjuk határozni, hogy egy kommunikáció során melyik szereplő mit tehessen, és mihez férhessen hozzá és ezeket a jogokat akár vissza is tudjuk vonni. Az információ érvényességi idejét tudnunk kell. Szeretnénk egy megbízható harmadik személytől jóváhagyást kapni az információ hitelességére. Tudni akarjuk az információ keletkezésének pontos idejét. Erre tanúkat is szeretnénk. Meg akarjuk erősíteni az információ érkezését. Érdekel, hogy a küldőnek volt-e joga elküldeni az információt. Néha szükség van a kommunikáló felek névtelenségére, viszont azt is szeretnénk, ha senki nem tagadhatná le az információcserét. Az évszázadok során kialakultak azok a protokollok és eljárások, amivel a fizikai dokumentumokat meg lehet védeni. Ezek azonban nem feltétlenül elégségesek, szükséges még a törvényi biztosíték és az adatkezelés megbízhatósága. Ilyen például a postai levélküldésnél a boríték, amivel a dokumentum bizalmasságát tudjuk megőrizni. A digitális világban is érvényesek ezek az elvek, csak a bitek - 84 -



világában a megvalósítás körülményesebb feladat. A kriptográfia alapelvei biztosítják azt, hogy az elektronikus dokumentumok is eleget tegyenek minden elvárásnak, amit az információ biztonságával szemben támasztunk. Ezek az elvek a 3. fejezetben leírtak alapján némi átcsoportosítással a következők: •

Bizalmasság: az információt mindenki elől el kell rejteni, kivéve azokat, akik fel vannak hatalmazva a tartalomhoz való hozzáférésre. A bizalmasságot mind fizikai, mind matematikai megoldásokkal biztosítani tudjuk.

•

Sértetlenség: biztosítja az adat változatlanságát, jelzi, ha illetéktelenül megváltoztatták az információt. A megváltoztatás lehet beszúrás, törlés vagy helyettesítés.

•

Hitelesség: biztosítja mind a kommunikáló felek, mind az adatok azonosítását.

•

Letagadhatatlanság: lehetetlenné teszi a felek számára valamely korábbi tevékenység letagadását.

Ezek biztosítására a digitális világban matematikai algoritmusokat használunk. A ma használt algoritmusok matematikai értelemben vett nagy nehézségű számelméleti problémákon alapulnak. Példának általában a prímfaktorizációt szokták felhozni, de vannak más ilyen jellegű problémák is. Jó algoritmust kitalálni nem egyszerű dolog. Számtalanszor volt arra példa, hogy szoftverfejlesztő cégeknél a programozók (kriptológiai ismeretek nélkül) kísérleteztek új algoritmusok kifejlesztésével és saját programjaikba való beépítésével. Ezen próbálkozások eredményei azonban nem feleltek meg a célnak. A kriptoanalízissel foglalkozó matematikusok sok ilyet vizsgáltak meg, és rendszerint néhány óra elég volt ahhoz, hogy az algoritmust megfejtsék és feltörjék. Téves tehát az a képzet is, hogy az algoritmus nem ismerete megemeli a biztonság szintjét. Léteznek olyan - nagy szakértelemmel rendelkező kriptográfusok által kifejlesztett - algoritmusok is, amelyeknek ismert a működése, mégis kevesebben bíznak meg bennük. Tipikus példa erre a DSA (Digital Signature Algorithm) amelyet az NSA (National Security Agency, USA Nemzetbiztonsági Hivatal, Amerikai Egyesült Államok) fejlesztett ki. Még nem találtak rá jó törő eljárást, de a felhasználók, illetve a többi kriptográfus tart tőle, hogy esetleg az NSA szakemberei ismernek hozzá mégis egy algoritmust, amivel rövid idő alatt visszafejthetnek bármit, csak ezt nem tették közzé. Egy jó algoritmus feltörése nehéz feladat. A kriptoanalitikusok világában a "feltörés" szó alatt egy olyan eljárást kell érteni (pl. ismert nyílt szöveg alapú támadás, rejtjelezett szöveg alapú támadás stb.), amellyel a kriptográfusok által kitalált rejtjelező, vagy digitális aláírást létrehozó algoritmus által előállított kódolt szöveghez (olvashatatlan, értelmetlen írásjelekből álló szöveghez, szövegrészhez) meg tudják találni a dekódoló kulcsot, és így vissza tudják fejteni vele a kódolt szöveget. Ez közérthetőbben, de mégis egy kicsit a matematika oldaláról nézve azt jelenti, hogy a rejtjelezés során, ha a kulcs méretét (aminek segítségével az olvasható szöveget kódolom, azaz értelmetlen szöveggé alakítom át) növelem néggyel (ami négy bittel hosszabb kulcsot jelent), akkor visszafejtésnél 24-szer (16-szor) annyi esetet kell megvizsgálnom (hiszen egy bit - 85 -



kétféle értéket vehet fel: nullát és egyet). A valóságban más jellegű matematikai számításokat kell végezni, de jól szemlélteti, hogy a kulcsméretet lineárisan (itt: néggyel) növelve a visszafejtéshez szükséges idő exponenciálisan nő. Egy algoritmus akkor tekinthető "feltörtnek", ha ezen visszafejtéshez találnak olyan módszert, ami sokkal kevesebb időt igényel. Egy exponenciális időben feltörhető algoritmusnál egy 4096 bites kulcs esetén a mai összes szuperszámítógépnek együtt is több időre lenne szüksége, mint ahány másodperc eltelt az Univerzum születése óta. Az információ elrejtésének vágya szinte egyidős az emberi kultúrával. Az első emlékek időszámításunk előtt 1900 évvel, az ókori Egyiptomból származnak. Ekkor már használták a titkosítást a diplomáciai és katonai életben. A kriptográfia azonban egészen a XX. századik inkább művészet volt, mintsem tudomány. A matematika csak a múlt század elején fedezte fel magának a kriptoanalízis diszciplínáját. Nagy lökést adott a II. világháború, ami a frontok mögött a kódfejtők csatáját is eredményezte. Ennek a titkos háborúnak köszönhetjük a számítógépek megjelenését – amikre az ellenség üzeneteinek megfejtésére volt szükség. Az 1960-as években a számítógépek egyre szélesebb körű polgári használata miatt vált szükségessé a kódolás elterjedése. A gyakorlatban kétfajta titkosítási módszert alkalmaznak. Az egyik a szimmetrikus, a másik az aszimmetrikus kulcsú titkosítás. A szimmetrikus kódoló algoritmusoknál egyetlen titkosító kulcs van, amit titokban kell tartania a felhasználónak. Szimmetrikus kódoló algoritmusok esetén a rejtjelezett kommunikáció megkezdése előtt valamilyen módon a felek egymás tudomására kell, hogy hozzák a titkos kulcsokat, ami nehezen oldható meg biztonságos módon. Előnye, hogy kis kulcsméretekkel kell dolgozni, így a titkosítás és a dekódolás rövid időt vesz igénybe. Az aszimmetrikus (vagy nyilvános kulcsú) kódoló algoritmusok esetén két kulcsot használnak. A nyilvános kulcs szabadon terjeszthető, bárki megismerheti, a titkos kulcsot viszont titokban kell tartani. Az egyik csak a másikkal nyitható, azaz ha valamit titkosítunk a nyilvános kulccsal, akkor az csak a hozzá tartozó titkos kulccsal dekódolható. A kódolás történhet nyilvános kulccsal (rejtjelezés), és titkos kulccsal is (ha az üzenet lenyomatát kódoljuk ezzel, akkor az lesz a digitális aláírás). Ezt a 8. fejezetben részletesen leírjuk. A hibrid rejtjelezés használatánál a két módszer keveredik: aszimmetrikus kulcsok segítségével megállapodnak a felek egy közös - szimmetrikus - kulcsban (session key), és ezen kulcsot használva folytatják a rejtjelezett kommunikációt. A hibrid rejtjelezés ötvözi az aszimmetrikus kódolás egyszerűbb kulcshasználatát (nincs szükség kulcscserére) és a szimmetrikus kódolás gyorsaságát. A 4.7.1-es fejezetben már láthattunk példát a titkosítás gyakorlati használatára. A Windows beépített fájltitkosítása mellett azonban még számtalan más segédprogram szolgál adataink megvédésére. A titkosítás használata azon fájlok esetében indokolt, melyek minősített információkat tartalmaznak. Különösen nagy hangsúlyt kell fektetni a kódolásra abban az esetben, ha a minősített információk esetleg kikerülhetnek a védett környezetből pl. laptopon, pendriveon vagy memóriakártyán. Ilyen esetben a szimmetrikus kulcsot használó Advanced Encryption Standard (AES) titkosító eljárás használata javasolt, - 86 -



minimum 128, de inkább 192 bit hosszúságú kulcs felhasználásával. Egy ilyen kulcs feltörése a jelenleg ismert technológiákkal több milliárd évig tartana. Titkosítás esetén kritikus fontosságú a felhasznált kulcsok biztonsági mentése. Ha egy kulcs gondatlanságból vagy szándékosan elveszik, a titkosított állományt nem lehet visszafejteni, gyakorlatilag elveszettnek tekinthető. A közigazgatásban várhatóan elérhető lesz olyan szolgáltatás, mely képes megbízhatóan tárolni a titkosításra használt kulcsokat, így megelőzhetők lesznek a kulcsok gondatlan kezeléséből eredő adatvesztések. A technológia bevezetésénél így a kulcsvisszaállítási-szolgáltatás igénybevételét is fontolóra kell venni.

4.10 Vezetéknélküli hálózatok Az utóbbi évek robbanásszerű fejlődést hoztak a vezetéknélküli technológiák területén. Ezek lehetővé teszik számítógépek és egyéb eszközök összekapcsolását vezetékezés nélkül. A vezetéknélküli kommunikációnak többféle megoldása létezik: •

Mobiltelefonos adatátvitel (GPRS, EDGE, 3G, stb.): az országos mobiltelefonhálózatokon keresztüli adatátvitel. Jellegzetesen előfizetéses szolgáltatás keretében használható, és működésében hasonlít a hagyományos betárcsázásos vagy a modernebb szélessávú internetszolgáltatásra, de kialakítható két tetszőleges mobil készülék között is hálózati kapcsolat.

•

Bluetooth adatátvitel: a Bluetooth mobil eszközök (telefon, PDA, laptop, stb.) közötti adatátvitelre szolgál, rendszerint rövid távolságon (néhány méter) belül.

•

WiFi (IEEE 802.11) adatátvitel: a vezetékes Ethernet hálózat kiváltására kidolgozott megoldás.

A következőkben főleg a WiFi hálózatokkal foglalkozunk, mivel a vizsgált környezetben ezek jelentik a legnagyobb biztonsági kihívást. Bár általában irodai környezetben célszerűbb vezetékes hálózatot használni biztonsági és megbízhatósági okokból, mégis előfordulhatnak olyan helyzetek, amikor a WiFi használata megkerülhetetlen. Jellemző példa erre, amikor műemlékvédelmi vagy építészeti okokból nem építhető ki vezetékes hálózat.

4.10.1

Fogalmak

A WiFi elnevezés valójában több különböző teljesítményű hálózati technológiát takar. Az első, ma már nem használt változat 2 Mbps sebességig volt használható. A manapság leggyakrabban használt változat az IEEE802.11b és az IEEE802.11g, az előbbi 11, az utóbbi 54 Mbps sebességig működik. A nagyobb sebességű (g) eszközök rendszerint képesek alacsonyabb sebességű (b) hálózaton is működni. A WiFi hálózatok alapvetően kétféle üzemmódban működhetnek:

- 87 -



•

Ad-hoc mód: az egyes WiFi eszközök közvetlenül egymással kommunikálnak. Ilyen módon kapcsolható össze egymással például két hordozató számítógép, más eszközök igénybevétele nélkül.

•

Infrastruktúra (infrastructure) mód: a WiFi hálózat központilag vezérlet a hozzáférési pontok (Access Point, AP) által.

Az esetek nagy részében infrastruktúra módban működő WiFi hálózatokkal találkozunk, tehát a továbbiakban ezzel foglalkozunk. A WiFi hálózat működése során az AP-ok hirdetik az általuk szolgáltatott hálózatot. A hálózat azonosítója az SSID (Service Set IDentifier). A kliensek konfigurációjukban beállított SSID-jű hálózathoz csatlakoznak.

4.10.2

Veszélyek

A legnagyobb problémát maga a vezetéknélküliség. A vezetékes hálózatok fizikai védelme viszonylag jól megoldható. A kábelezés az épületen belül védetten vezethető és megfelelő eszközök használatával biztosítható, hogy az illetéktelen csatlakozás megakadályozható illetve észlelhető legyen. A WiFi hálózat azonban nem ér véget az épület falainál, ez jelentős biztonsági problémák forrása. A következő tipikus támadási formák fordulhatnak elő: •

Passzív lehallgatás – a támadó megfigyeli a hálózati forgalmat és így illetéktelenül jut adatokhoz. Ez a támadás megfelelő eszközökkel egészen nagy távolságról is elvégezhető és mivel passzív, teljességgel felderíthetetlen.

•

Illetéktelen kapcsolódás a hálózathoz – a támadó rákapcsolódik a WiFi hálózatra és aktívan részt vesz annak működésében. Gyakori, hogy a támadás csak a hálózat (internet-elérés) használatára korlátozódik, a támadó nem akar adatokat lopni, nem is érdekli a hálózati forgalom, csak hozzáférést szeretne.

•

Kliensek „eltérítése” – a támadó egy „hamis” hálózatot állít fel, és a felhasználók hozzá, nem pedig az eredeti hálózathoz csatlakoznak. Ezek után a kliensek forgalmát a támadó megfigyelheti.

4.10.3

Biztonsági megoldások

WiFi hálózatoknál alapvetően két feladatot kell megoldani: szabályozni a hozzáférést a hálózathoz illetve titkosítással megakadályozni a forgalom „lehallgatását”. Az eredeti elképzelés szerint a WEP (Wired Equivalent Privacy – vezetékessel egyenértékű biztonság) szolgáltatta volna a WiFi hálózatok védelmét. Sajnos azonban a WEP tervezési hiányosságok miatt nem képes ellátni feladatát. Több olyan program is elérhető, amely automatikusan képes feltörni WEP titkosítással ellátott hálózatokat, akár pár percen belül is. Vagyis a WEP több a semminél, de ha rendelkezésünkre áll jobb megoldás, akkor inkább azt kell használni. A WEP hiányosságainak kiküszöbölésére hozták létre a WPA (WiFi Protected Access – védett WiFi hozzáférés) megoldást, illetve ennek végleges, szabványosított formáját a WPA2-őt. A WPA és a WPA2 gyakorlatilag - 88 -



megegyezik, a WPA2 képes a még erősebb AES titkosításra. Jelenleg még kevés eszköz támogatja a WPA2-t, ez azonban gyorsan változni fog. Alapvető megkülönböztetést kell tenni kisméretű (otthoni, vagy irodai) és nagyméretű (pl. vállalati) WiFi hálózatok között, mivel ezek kezelése eltérő megoldásokat igényel. Ennek megfelelően a WPA is megkülönbözteti a kétfajta hálózatot, és rendszerint különböző kategóriájú AP-ok szükségesek működtetésükhöz. •

Kisméretű hálózatok esetében rendszerint a felhasználók autentikációját egyszerű módszerekkel oldják meg, összekötve a titkosítással, például manuálisan kiosztott jelszavakkal. Kevés, ritkán változó mennyiségű felhasználó és kis kiterjedésű hálózat esetében elegendő lehet ilyen hálózatot üzemeltetni, mivel infrastrukturális és üzemeltetési munkaigénye alacsony. Ezt korábban WPA-PSK (WPA Pre-shared Key, előre kiosztott WPA kulcs) néven, a szabvány kialakítása óta WPA Personalként (személyi WPA) ismert.

•

Nagykiterjedésű, sokfelhasználós hálózatok más megoldásokat alkalmaznak. Az autentikációt az EAP (extensible Authentication Protokoll – kiterjesztehtő autentikációs protokoll) valamely formájával oldják meg, központi autentikációs szerverrel (pl. RADIUS). Ezt a módot hívják WPA Enterprise-nak (Vállalati WPA).

Előfordul, hogy régebbi eszközök nem ismerik a WPA-t. Ebben az esetben először nézzük meg a gyártó web oldalát, hogy van-e frissített firmware vagy meghajtó program. A legtöbb eszközhöz a WPA megalkotása után a gyártó kiadott frissítést, amellyel WPA-képessé tehető. Ha ilyen nincs, akkor érdemes megfontolni az eszköz lecserélést. Ha ez sem lehetséges, akkor alternatív módon kell megoldani a WiFi biztonságát, pl. VPN alkalmazásával.

4.10.4

Lényeges tennivalók

A vezetéknélküli hálózatunk megfelelő beállítása több lépéses folyamat és bizonyos mértékben függ a rendelkezésre álló eszközök által támogatott lehetőségeitől is. A következőkben a lényeges pontokat emeljük ki. A hálózat legtöbb paraméterét az AP-kon kell beállítani: •

Sose hagyjunk AP-okat alapbeállításon! A legtöbb AP alaphelyzetben minden biztonsági beállítás nélkül indul, teljesen nyílt módban. Ezért előbb hajtsuk végre a megfelelő beállításokat, csak utána csatlakoztassuk a hálózatunkra, különben rést nyithatunk a hálózaton. Szerencsére az újabb eszközök már nagyon egyszerűen, gombnyomásra biztonságossá állíthatóak be.

•

Az SSID megválasztása: az SSID önmagában nem alkalmazható védelem kialakítására, azonban megfelelő megválasztása megnehezítheti a támadó dolgát. A legtöbb AP rendelkezik valamilyen alapértelmezett SSID-vel (pl.: Cisco eszközökben: tsunami, Linksys eszközökben: linksys). Ezeket látva a támadó arra következtethet, hogy az eszközök nem lettek helyesen felkonfigurálva, így érdemes támadni őket. Másik gyakori hiba, hogy az SSID-t valamilyen beszédes értékre állítják be (pl.: penzugy). Ez szintén

- 89 -



felkeltheti a támadó kíváncsiságát. A hálózat SSID-ját mindenképpen állítsuk át gyári alapértelmezésről, és lehetőleg semmitmondó vagy értelmetlen szó legyen. •

Az SSID hirdetése: A legtöbb AP alaphelyzetben hirdeti a hálózat SSIDjét. Hacsak nem célunk, hogy nyilvánosan hirdessük a hálózatot, ezt meg kell szüntetni. Kapcsoljuk ki az SSID hirdetést (SSID broadcast)! Az SSID „titkolása” nem teszi lehetetlenné az SSID meghatározását, de kevésé lesz „feltűnő” a hálózatunk, így a támadó esetleg más célpont után néz.

•

MAC szűrés: amennyiben a kliensek száma kicsi és nagyrészt változatlan, akkor célszerű MAC (hálózati csatoló azonosítója) szerinti szűrést célszerű alkalmazni. Ebben az esetben az AP-ok csak a számukra engedélyezett című klienseket engedi csatlakozni. Ez a szűrés nem ad megkerülhetetlen védelmet, de nehezíti a támadó dolgát. Ezért szükség esetén használjunk MAC cím szerinti szűrést!

•

Amennyiben az eszköz támogatja, WPA titkosítást használjunk! A WiFi titkosítási megoldásai közül jelenleg egyedül a WPA tekinthető biztonságosnak. A korábbi, WEP megoldás, hibái miatt, könnyen feltörhető. Kész eszközök rendelkeznek, amelyekkel a támadók a WEP hálózatokat törhetik.

•

Ne engedjünk AP-kat telepíteni engedély nélkül! Gyakori, hogy a felhasználók, munkatársak irodájukban AP-okat telepítenek, azért, hogy más vezetéknélküli eszközeiket használni tudják.

•

Különleges biztonsági igények esetében ne támaszkodjunk csupán a WiFi biztonságra, használjunk VPN-t! A VPN teljes hálózati forgalmat titkosítja, az alatta lévő hálózati infrastruktúrától függetlenül így annak sikeres lehallgatása esetén sem sérül az információ biztonsága.

•

Az AP-ok úgy legyenek a hálózatra kötve, hogy szükség esetén gyorsan leválaszthassuk róla. Ha betörést észlelünk a vezetéknélküli hálózaton keresztül, a WiFi infrastruktúrát képesek legyünk egy lépésben leválasztani a belső hálózatunkról. Célszerű az AP-ket külön vezetékes hálózaton és aktív eszközökön át összekötni és egy ponton, egy tűzfalon keresztül kapcsolni a hálózatra.

•

Ne engedjük az AP-ok kezelését WiFi-n keresztül! A legtöbb AP lehetővé teszi, hogy a beállításait csak vezetékes hálózaton keresztül csatlakozva lehessen módosítani. Így a pusztán vezetéknélküli hozzáféréssel rendelkező támadó nem képes módosításokat tenni az AP-ban.

Bizonyos beállításokat azonban a klienseken kell megtenni: •

Az általában használt hálózatot (SSID) vegyük fel elsődlegesként, azaz a kliens először ehhez próbáljon csatlakozni. Ezzel elejét lehet venni annak, hogy a kliensek más hálózatra jelentkezzenek fel, ha hálózatunk nem elérhető.

•

Ne engedjük a klienst tetszőleges hálózathoz csatlakozni! A támadó zavarhatja a hálózatunkat, és így ráveheti a klienseket arra, hogy az általa

- 90 -


felállított „hamis” forgalmukat. •


hálózathoz

csatlakozzanak,

majd

megfigyelheti

A kliensek különböző módon tárolják a jelszavakat, van, amely konfigurációs állományokban, van amely a Windows registry-ben. Bizonyos kliensek esetében ezek könnyen kiolvashatóak, ha illetéktelen kézbe kerül a kliens számítógép. Tájékozódjunk, hogy a kliens program hogyan tárolja az érzékeny információkat, és ennek alapján dolgozzuk ki a tennivalókat rendkívüli esetekre.

Egyéb tennivalók: •

Ügyeljünk az illegális AP-okra! Gyakori eset, hogy a felhasználók saját kényelmük érdekében AP-okat telepítenek irodájukba, vagy más helyekre. Mivel ezek nem részei az engedélyezett infrastruktúrának, ugyannak nagy valószínűséggel nincsenek kellő biztonsággal felkonfigurálva, biztonsági rést jelenteken. Mivel egy ilyen AP a belső hálózatra van csatlakoztatva, ezért a veszély nagy, hiszen a tűzfalat megkerülve közvetlen utat nyitnak a védett hálózatba. Ritkábban előfordulhat, hogy támadási céllal telepítenek jól álcázott AP-kat, akár azért, hogy a klienseket ezekre csatlakoztatva azok forgalmát megfigyeljék, akár azért, hogy rejtett csatornát nyissanak a belső hálózatba. Volt példa arra, hogy a támadó egy kisméretű AP-t csatlakoztatott titokban a belső hálózathoz, majd azon keresztül képes volt bármikor behatolni. Az ilyen AP-k nehezen megtalálhatóak, mivel a támadó ügyel aminél rejtettebb működésre.

•

Folyamatosan figyeljük a WiFi infrastruktúra használatát! Kapcsoljuk be a naplózási lehetőségeket, és kísérjük figyelemmel. Ha a megszokottól eltérő viselkedést észlelünk, mint például hirtelen megnövekedett forgalom, vagy kliens szám, keressük meg az okát.

•

Ha szükség van biztonságos belső WiFi hálózatra és „vendég” jellegű hozzáférésre is, akkor ezekre a célokra két, szeparált infrastruktúrát építsünk ki! A két felhasználási cél által megkövetelt beállítások egymásnak ellentmondóak, így ha egy hálózaton belül próbáljuk meg megvalósítani, biztonsági rések keletkeznek. Vagy külön AP-okat telepítsünk, vagy nagyvállalati kategóriájú AP-k rendszerint képesek egy eszközön belül több hálózat kiszolgálására. A külön WiFi hálózatok forgalmát természetesen külön kell kezelni, más tűzfal szűrési beállításokkal stb.

4.10.5

Példa a beállításokra

A következőkben bemutatunk egy példát biztonságos WiFi hálózat kialakítására. A következőket vettük figyelembe a tervezés során: •

A hálózat egy kisméretű, irodai hálózat, néhányszor tíz klienssel. Ez a hálózati méret nem követel meg összetettebb infrastruktúrát. Lényegesen több és esetleg gyorsan változó felhasználó esetében célszerű valamilyen külön autentikációs eljárással és központosított felhasználó kezeléssel (pl. RADIUS) működő hálózatot kiépíteni. Ennek ismertetése meghaladja a

- 91 -



jelenlegi kereteket, eszközigénye lényegesen nagyobb, tervezését és kialakítását célszerű szakemberre bízni. •

A választott biztonsági protokoll a WPA-PSK, azaz minden kliensen be kell állítani a megosztott WPA kulcsot.

•

További biztonsági lépésenként MAC szűrést alkalmazunk.

•

A pédában szereplő AP egy Linksys WRT54G WiFi router, a kliensek Microsoft Windows XP Service Pack 2 operációs rendszerrel rendelkeznek.

4.10.5.1 Access Point beállítása A legtöbb AP web alapú kezelői felülettel rendelkezik. Tájékozódjunk a kézikönyvében, hogy hogyan lehet ezt a felületet elérni. Ne feledkezzünk meg a gyári alapértelmezett adminisztrátori jelszó átállításáról! A következő példák egy Linksys WRT54G WiFi eszközzel készültek, amely és hasonló készülékek különösen népszerű otthoni és irodai felhasználásra, mivel szélessávú eléréshez jól alkalmazható belső vezetékes és vezetéknélküli hálózat kialakítására. Más eszközökben is hasonló beállítási lehetőségek léteznek, a kézikönyv segítségével ezek megtalálhatóak. Első lépésben az alapvető WiFi jellemzőket kell beállítani. Az ábrán látszik, hogy a hálózatunk SSID-je „vezeteknelkuli” lesz. Az SSID hirdetését (SSID broadcast) kikapcsoljuk.

28. ábra: Alapvető WiFi beállítások

Következő lépésben a biztonsági beállításokat tesszük meg. A választott biztonsági megoldás a WPA Personal, TKIP titkosítással. WPA kulcsnak kellően

- 92 -



hosszú és bonyolult jelszót adjunk meg, hogy a szótár alapú támadásokat megelőzzük!

29. ábra: Biztonsági beállítások

Amennyiben szükséges – bár a WPA nem teszi feltétlenül szükségessé – állítsunk be MAC szűrést. Ez rendszerint két lépésben történik, a szűrés engedélyezésével és a szűréslista beállításával. A legtöbb AP lehetővé teszi, hogy a MAC szűrést ideiglenesen kikapcsolva a kliensek csatlakozhassanak, majd a csatlakozott klienseket automatikusan felvehetjük a szűrési listába. Természetesen lehetőség van a MAC címek kézi beírására. A kliens eszközök MAC címe rendszerint fel van tüntetve az eszközön, de Windows alatt a parancssorból kiadott ipconfig /all, Linux alatt pedig az ifconfig paranccsal megállapítható.

30. ábra: MAC szűrés engedélyezése

- 93 -



31. ábra: MAC szűrési lista szerkesztése

Végül, érdemes beállítani azt, hogy az AP-t csak vezetékes hálózatról lehessen kezelni.

i 32. ábra: Menedzsment hozzáférés beállításai

- 94 -



4.10.5.2 Kliensek beállítása A Windows WiFi telepítő varázslójában (Service Pack 2) három lényeges paramétert kell beállítani, ezeknek meg kell egyezniük az AP-ban beállított értékekkel: • Az SSID-t állítsuk be saját hálózatunk SSID-jére. Mivel az AP-ban ki van kapcsolva az SSID hirdetése, ezért nem fog feltűnni az elérhető hálózatok listájában, tehát kézzel kell beírni. • A hálózati kulcs hozzárendelése legyen manuális, majd az AP-ban beírt WPA kulccsal megegyező értéket kell megdani. • Kapcsoljuk be a WPA-t! Első lépésként, ha az adott WiFi eszközhöz adott meghajtó nem tartalmaz külön programot a beállításokhoz, akkor használjuk a Windows saját beállító programját, a vezeték nélküli hálózati kapcsolatok megnyitásával. Mivel a hálózatunk SSID-je nem látszik, ezért a hálózat egyelőre nem fog feltűnni a hálózati listában. A hálózat beállítása pontot választva elindul a telepítő varázsló.

33. ábra: WiFi hálózat keresése és beállítása

Mivel új hálózatot kívánunk felvenni, válasszuk ezt a pontot!

34. ábra: Telepítő varázsló új hálózathoz

- 95 -



Következő lépés az SSID és a biztonsági beállítások meghatározása. Írjuk be ugyanazt az SSID-t, amit a hálózatra beállítottunk. Válasszuk a kézi kulcsbeállítást, és a WPA titkosítást.

35. ábra: Alapvető WiFi kliens beállítások

Ezután meg kell adni a WPA kulcsot, amelynek természetesen meg kell egyezni minden adott hálózatban lévő eszközön. A kulcsot kétféle módon adhatjuk meg, vagy szöveges kulcsként, vagy hexadecimális (0-9, A-F) formában. A könnyebb begépelhetőség érdekében kikapcsolhatjuk a karakterek elrejtését, amennyiben biztosak vagyunk abban, hogy senki nem figyeli meg, amint bevisszük a kulcsot. Ez a beállítás csak a begépelést segíti, egyébként nincs hatással a kulcs biztonságára.

- 96 -



36. ábra: WPA kulcs bevitele a kliensbe

Ezzel a hálózat alapvető paramétereit beállítottuk. Lehetőség van a beállítások átvitelére más gépekre is, mivel mindenhol ugyanazokat a paramétereket kell beállítani. Több gép esetében érdemes ezt a segítséget igénybe venni, egy USB meghajtó segítségével. A Windows felmásolja a megfelelő beállításokat a meghajtóra, amelyet más gépekhez csatlakoztatva és elindítva a rajta lévő beállító programot, a paraméterek átkerülnek, anélkül, hogy a jelszavakat, stb. újra kellene gépelni.

37. ábra: Beállítások átvitele

A varázsló befejeztével ellenőrizhetjük, hogy sikeres volt a csatlakozás a hálózathoz. A Windows ezután megjegyzi a beállításokat, így később - 97 -



automatikusan tud csatlakozni a hálózathoz. Az automatikus csatlakozásokat és azok sorrendjét az „Előnyben részesített hálózatok…” pontban tudjuk módosítani.

38. ábra: Sikeres kapcsolat ellenőrzése

4.10.6

Bluetooth biztonság

Főleg kéziszámítógépek és mobiltelefonok képesek Bluetooth kommunikációra. A Bluetooth összetett protokoll nem elsősorban hálózati elérésre szolgál (bár arra is alkalmas), hanem eszközök közötti adatcserére. Így például mobiltelefonok, PDAk címjegyzékét, naptárbejegyzéseit lehet elérni, de alkalmas például mobiltelefonok és kihangosítók összekapcsolására is. A Bluetooth hatótávolsága a legtöbb hordozható eszköznél néhány méter, így a támadónak fizikailag is közel kell kerülnie az eszközhöz, ez megnehezíti, de nem teszi lehetetlenné a támadásokat. Néhány alapvető beállítással azonban kellően biztonságossá tehetjük a Bluetooth eszközöket: •

Az eszköz ne legyen „látható”. Bluetooth eszközök hirdethetik magukat, ilyenkor más Bluetooth eszköz fel tudja deríteni. Erre akkor van szükség, amikor két eszköz között adatátvitelt akarunk végrehajtani. Ilyenkor az egyik eszközzel meg kell keresnik a másikat. Értelemszerű, hogy az eszköznek láthatónak kell lennie. Ha két eszköz között állandó vagy gyakori kapcsolatra van szükség, akkor az eszközöket párosítani (pairing) kell. A párosítás után már nincs szükség a láthatóságra, ki lehet kapcsolni.

•

Csak indokolt esetben engedélyezzük a jóváhagyás nélküli kapcsolódást. Párosított eszközök esetén a legtöbb berendezésen lehet engedélyezni, hogy automatikusan, jóváhagyás nélkül kapcsolódjanak. Ez felderíthetetlenné teszi, ha esetleg egy engedélyezett eszköz csatlakozik.

- 98 -



•

Kapcsolódási kérelem esetén gondosan tanulmányozzuk, hogy honnan és milyen célból történik. Ha nem vagyunk biztosak, ne engedélyezzük az adatátvitelt. Egyes mobil vírusok terjednek ilyen módon.

•

Ha nincs szükség Bluetooth-ra állandóan, akkor csak addig engedélyezzük, amíg használjuk

4.11 Hordozható eszközök A hordozható eszközök előtérbe kerülésével újabb fenyegetettségek merültek fel. A hordozható eszközök kategóriájába különböző eszközök tartoznak: • Hordozható számítógépek (laptop) • Tenyérszámítógépek (PDA) • Mobiltelefonok • Adathordozók (Pen-Drive, stb.) A hordozható eszközök által megvalósított fenyegetés elsősorban a nehezen kivitelezhető fizikai védelemben rejlik. A modern adathordozók és hordozható számítógépek hatalmas mennyiségű adatot tudnak tárolni, így elvesztésük hatalmas károkat tud okozni, esősorban az információk illetéktelen kezekbe jutása miatt. Javaslatok a károk elkerülésére, minimalizálására: •

Adminisztratív előírásokat kell hozni az ilyen eszközök kezeléséről. Meg kell tiltani a besorolás érzékeny információk ilyen eszközökön történő szállítását, tárolását. Az előírások betartását ellenőrizni és megsértésüket szankcionálni kell.

•

Az információk biztonsági besorolása során határozzuk meg, hogy melyeket lehet és melyeket nem lehet mobil eszközön tárolni.

•

Alkalmazzunk titkosított adattárolást. Hordozható számítógépek esetén használjunk titkosított fájlrendszert. Egyes USB adathordozók képesek titkosított adattárolásra megfelelő kiegészítő programok segítségével.

•

Óvatosan tároljunk jelszavakat hordozható gépeken. Amíg egy irodai számítógépen elfogadható lehet adott esetben pl. a levelező kiszolgálóba való belépéshez szükséges jelszó „megjegyeztetése”, mivel a rendszer más védelme biztosítja, hogy ehhez a jelszóhoz ne lehessen hozzáférni, egy ellopott laptoton tárolt jelszavak megszerzése más rendszerek biztonságát is veszélyezteti.

•

Ha lehetséges használjunk egyéb biztonsági módszereket. Laptopok, PDAk rendelkezhetnek olyan biztonsági eszközökkel, mint intelligens-kártya olvasó, vagy ujjlenyomat-olvasó. Használjuk ezeket!

•

Az olyan, mobil eszközökre jellemző és potenciális kockázatot jelentő vezetéknélküli szolgáltatásokat, mint a Bluetooth, vagy a WiFi, megfelelően biztosítsuk, ha nincs rá szükség, kapcsoljuk ki!

- 99 -


5

Üzemeltetés

Üzemeltetés

A biztonság sosem tekinthető statikusnak. A rendszert folyamatában kell tekinteni, és a teljes életciklusa alatt biztosítani kell a megkívánt biztonságot fenn kell tartani. A következőkben néhány fontos területet emelünk ki.

5.1 Mentés A biztonsági mentés fontosságát nem lehet elégszer hangsúlyozni. Ennek ellenére, főleg kisebb rendszerek esetében, nagyon elhanyagolt terület, és csak súlyos adatvesztés után döbbenek rá, hogy mennyire lényeges. A biztonsági mentés célja az értékes adatok megőrzése kritikus rendszerösszeomlás után. Érdemes figyelembe venni, hogy egy számítógépes rendszer minden komponense pótolható, az adatok kivételével. A biztonsági mentésnek a következőknek kell eleget tennie: •

Legyen friss! Egy rendszerösszeomlásnál annyi adatot fogunk elveszíteni, amennyi a legutóbbi mentés óta keletkezett. A mentés gyakoriságát ennek megfelelően kell meghatározni. Szabályzatba kell foglalni a mentések végrehajtását és naplót kell vezetni a végrehajtásról.

•

Legyen visszaolvasható! Triviálisnak tűnik, de előfordul, hogy a mentéshez olyan szoftvert használnak, amellyel nehéz más rendszeren visszaolvasni a mentést. Ha az eredeti rendszer üzemképtelen, szükség lehet időlegesen visszaállítani más rendszerre a mentést. Célszerű időnként próba visszatöltést tartani.

•

Biztos helyen tároljuk! A biztonsági mentés nem ér semmit, ha csőtörés, tűz vagy lopás során az eredeti rendszerrel együtt megsemmisül! Tartsuk más helyiségben vagy tűzbiztos páncélszekrényben. Ugyanakkor önkormányzati rendszerek mentése biztosan tartalmaz olyan adatokat, amelyek jogszabályi előírás alapján adatvédelmi szempontból érzékenyek. Szükség esetén használjunk olyan megoldást, amely a mentést titkosítva tárolja, vagy tároljuk és szállítsuk fizikailag biztos módon!

•

Ne keverjük össze a nagy rendelkezésre állást a biztonsági mentéssel. Az olyan megoldások, mint pl. a lemezegységek tükrözése, RAID alrendszerek, stb. Növelik a rendelkezésre állás nagyságát és az adatbiztonságot, mert pl. egy lemezegység meghibásodása esetén is működőképes marad a rendszer, de nem helyettesítik a biztonsági mentést. Egy teljes RAID lemezegység is teljesen tönkre tud menni, pl. tűz, villámcsapás stb. esetén, ekkor a rajta tárolt adatok elvesznek, vagyis mentésre ekkor is szükség van!

A mentések megoldása nagyon függ az alkalmazott rendszertől. Nagyobb infrastruktúrák esetében valószínűsíthető, hogy a központosított mentés megoldott. Kisebb rendszerek esetében viszont valószínű, hogy nincsen ilyen, tehát az adott rendszer lehetőségeinek megfelelően kell megoldani a mentést.

- 100 -


Üzemeltetés

5.2 Frissítések Ahogy már a Windows biztonságnál szó esett róla, alapvető fontosságú, hogy a rendszerhez kibocsátott frissítések telepítésre kerüljenek. Célszerű alkalmazni az automatikus frissítéseket, mivel nem várható el a felhasználóktól, hogy rendszerüket maguktól frissítik, sőt nem is célszerű, ha egyébként jogosultak frissítésre. A gondos üzemeltető figyelemmel kíséri a gyártói weboldalakat és egyéb fórumokat a legújabb frissítések nyomon követésére.

5.3 Selejtezés Gyakori hiba, hogy nem fordítanak kellő figyelmet az informatikai rendszer életciklusának végén a rendszer megfelelő kezelésére. Pedig számítógépek, adathordozók selejtezése, kidobása könnyen okozhat jogszabályi előírásokba ütköző helyzeteket. Ismert, hogy még fizikailag sérült adathordozókról is lehetséges adatok visszanyerése, ezért fontos, hogy adatvédelmi szempontból ezeket is úgy kell kezelni, mint a hagyományos, papír alapú dokumentumokat. Fontos, tehát, hogy selejtezés esetén biztosítsuk az adathordozó tárolt adatok megbízható megsemmisítését. Ez CD lemezek esetén minimálisan azok összetörését vagy bezúzását jelenti, merevlemezek és mágneses adathordozók esetében pedig a többszöri felülírást (erre léteznek célprogramok) vagy különösen védett adatok esetében a fizikai megsemmisítést.

5.4 Vészhelyzetek Minden megelőző intézkedés dacára előfordulhatnak vészhelyzetek. A gondos üzemeltető természetesen rendelkezik tervekkel vészhelyzet esetére, de az is nyilvánvaló, hogy minden különleges eseményre nem lehet felkészülni. Ilyen esetekben négy fontos célt kell szem előtt tartani: • Lehetőség szerint előzzük meg a további károkat. • Hozzunk megfelelő intézkedéseket a hasonló esetek elkerülésére. • Segítsük elő a normál üzem visszaállását. • Segítsük elő az okok kiderítését vagy a nyomozást. A következőkben néhány jellegzetes esetre vonatkozó példákat mutatunk be.

5.4.1

További károk megelőzése

Tervekkel kell rendelkezni, hogy vészhelyzetben milyen lépésekre van szükség. Ilyen lépések lehetnek pl. a külső hálózati kapcsolat megszakítása, a belső hálózat particionálása a támadás, vírusfertőzés továbbterjedésére, védett rendszerek lekapcsolása, stb. Fontos arra figyelni, hogy megtaláljuk a kellő kompromisszumot a kár megelőzése és a rendszer ezen célú megállítása között, hiszen nem szerencsés, ha bármely támadási jelre azzal válaszolunk, hogy megszüntetjük rendszerünk működését. A megfelelő logikai zónák kialakításával a támadás súlyosságától függően van lehetőségünk arra, hogy milyen mértékben avatkozzunk be a rendszer működésébe.

- 101 -


Üzemeltetés

Néha célszerű a támadásra úgy reagálni, hogy hagyjuk a támadást folyni, de közben, a támadó számára lehetőleg észrevétlenül, megfigyeljük tevékenységét. Ez segíthet a következő pont megvalósításában.

5.4.2

Hasonló esetek megelőzése

Megtörtént támadás esetén nem elegendő az aktuális támadást megszüntetni, pl. a hálózati kapcsolat megszakításával, hiszen várható, hogy azon a módon, ahogy ez a támadó bejutott, más is be fog jutni. Meg kell keresni és be kell tömni a biztonsági rést! Ebben nagy segítségre lehet, ha megfigyeljük a támadás folyamatát, ugyanis ekkor könnyebben tudunk következtetni arra, hogy mi is volt az a tényező, amelyet kihasználva bejutott a támadó.

5.4.3

Normál üzem visszaállítása

A normál üzem visszaállítása egy támadás után igényli nem csak a sérült adatok visszaállítását, de a rendszer integritásáról való megbizonyosulást is, nem hagyott-e a támadó olyan „hátsó ajtót” amelyen keresztül visszatérhet. Erre célra különböző eszközök léteznek, amelyek a rendszer aktuális állapotát összehasonlítják valamely korábban elmentett állapottal (rendszerint ellenőrzőösszegek alapján). Természetesen kétséges helyzetben legcélszerűbb a rendszer újratelepítése, ez azonban általában munkaigényes és nagy fennakadással áll. Célszerű lehet a telepített és felkonfigurált rendszerről egy „pillanatfelvételt” készíteni, amely lehet a merevelemez másolata Norton Ghost, vagy hasonló programokkal. Probléma esetén csak ezt a másolatot kell visszatölteni és visszaáll az eredeti állapot. Ez a megoldás kellő körültekintéssel használva nagyon gyors visszaállást tesz lehetővé, de nem szabad megfeledkezni a mentés óta történt változtatások (és biztonsági javítások!) feltöltéséről.

5.4.4

Nyomozás

Gyakori, hogy a normál üzem visszaállítása után szeretnénk kideríteni az okokat, vagy akár más lépésekre, pl. rendőrségi feljelentés is sor kerülhet. Nagyon fontos, hogy képesek legyünk a nyomokat megőrizni. A fontosabb lépések: •

Készítsünk egy-az-egy másolatot a merevlemezekről! Erre több eszköz is alkalmas, pl. a Norton Ghost Windos alatt, vagy a dd parancs Linux alatt. Természetesen szükség van egy legalább akkora méretű lemezre, mint amelyről másolatot készítünk. A további vizsgálódást ezen a másolaton végezzük.

•

Mentsük el, esetleg nyomtassuk ki a releváns napló állományokat! Gyakori, hogy a normál működés során a napló állományok előbb-utóbb felülíródnak, így a régebbiek elvesznek. Ezt meg kell akadályozni!

•

Jegyezzünk fel minden fontos adatot (rendszerben futó programok, fehasználók, stb. listája.

- 102 -


Üzemeltetés

- 103 -


6

A szabályozási környezet által támasztott igények


2000 júniusában meghirdették az eEurope 2002 nevű akciótervet „Információs társadalom, mindenkinek” címmel, majd 2002 júniusában a sevillai csúcson elfogadták az eEurope 2005 című „hároméves tervet”. Ebben a tervben az eKormányzati szolgáltatások mellett, megjelent az informatikai biztonság fejlesztésének igénye. Hasonlóan az informatikai biztonság erősítését tűzte ki célul az OECD 2002-ben meghirdetett akciója, „OECD irányelvek a biztonságos informatikai rendszerekért és hálózatokért: a biztonsági kultúra irányába” címmel. Csatlakozásunk előkészítéseként 2003 végén elfogadásra került az Informatikai és Hírközlési minisztérium gondozásában a Magyar Információs Társadalom Stratégia (MITS) és ezzel összhangban a Miniszterelnöki Hivatal Elektronikuskormányzat-központ által kidolgozott eKormányzat 2005 stratégia és akcióterv.

6.1 Jogszabályok A közigazgatás informatikai, informatikai biztonsági feladatait elsősorban a 2004. évi CXL. törvény a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól X. Fejezete (Elektronikus ügyintézés és hatósági szolgáltatás), és az ezt kiegészítő 193/2005. (IX. 22.) Korm. rendelet az elektronikus ügyintézés részletes szabályairól, a 194/2005. (IX. 22.) Korm. rendelet a közigazgatási hatósági eljárásokban felhasznált elektronikus aláírásokra és az azokhoz tartozó tanúsítványokra, valamint a tanúsítványokat kibocsátó hitelesítésszolgáltatókra vonatkozó követelményekről, a 195/2005. (IX. 22.) Korm. rendelet az elektronikus ügyintézést lehetővé tevő informatikai rendszerek biztonságáról, együttműködési képességéről és egységes használatáról és a 12/2005. (X. 27.) IHM rendelet az elektronikus ügyintézési eljárásban alkalmazható dokumentumok részletes technikai szabályairól határozza meg. Természetesen a területet még számos egyéb jogforrás szabályozza, ezek felsorolása megtalálható a 10.1 fejezetben.

6.2 Szabványok és ajánlások A Kormányzati Informatikai Egyeztető Tárcaközi Bizottság (KIETB) a kormányzati informatikával, a modern állam működésével a Magyar Információs Társadalom Stratégiába illeszkedő eKormányzat 2005 Elektronikus Kormányzat Stratégia és Programterv végrehajtásával kapcsolatos stratégiai összehangoló, iránymutató funkciókat lát el. Ajánlásait a központi közigazgatásban kötelező felhasználni, de ezek egy része az önkormányzatok szempontjából is figyelembe - 104 -



veendő, mivel így biztosítható az „egységes” elektronikus ügyintézés. A KIETB ajánlások a 10.2 fejezetben találhatóak. A tételes és részletes szakmai előírásokat nyújtó szabványok és ajánlások közül az Amerikai Egyesült Államok a NIST5 Special Publication 800 sorozatának „NIST SP 800-12, An Introduction to Computer Security: The NIST Handbook”, a német BSI6 „IT Baseline Protection Manual”, kiadványain túl a Brit Szabványügyi Hivatal7 „BS 7799 Part 1, Code of practice for information security management” kiadványa vált ISO/IEC 17799:2005 számon „Information Technology – Code of practice for information security management” néven nemzetközi szabvánnyá. A ISO/IEC 27001:2005 számon nemzetközi szabvánnyá vált BS7799 2. része8 elsősorban a szervezet vezetésének szól, és a megfelelési és az ellenőrzési követelményeket tartalmazza. Az ISO/IEC 17799 szabvány alapvetően abban különbözik a korábbi informatikai biztonsági ajánlásoktól, hogy nem követelményeket ír elő, hanem – a minőségbiztosításról szóló ISO 9000 szabványhoz hasonlóan – a teljes körű informatikai biztonság megteremtéséhez szükséges szervezési, szabályozási szempontrendszert adja meg.

5

National Institute of Standards and Technology

6

Bundesamt für Sicherheit in der Informationstechnik

7

British Standard Institute

8

A BS 7799 második részét 2002-ben módosították az ISO 9001:2000 és az ISO 14001:1996

szabványokkal való harmonizáció miatt. Az aktuális változat a BS 7799 Part 2:2002, Information security management systems – Specification with guidance for use.

- 105 -



Az informatikai biztonság kérdésével számos más szabvány és ajánlás foglakozik. Gyakran hivatkoznak ezen területen az ITIL9-re és a COBIT10-ra. Az ITIL, „Az informatikaszolgáltatás módszertana” egy az informatika, mint szolgáltatás egészére kiterjedő, nemzetközileg széles körben elfogadott dokumentum. Az ITIL-ben a biztonságirányítás, bár önálló folyamat, amennyire csak lehetséges, integrálódik a többi folyamatba. Az ITIL Biztonságirányítás (Security Management) kötete a BS7799 szabványt használja hivatkozásként, amikor a létező ITIL folyamatokat bővíti a biztonságirányítással. A COBIT az információrendszer ellenőrök egy nemzetközileg is ismert és elfogadott, az informatikai rendszerek szervezéséhez, és különösen az ellenőrzéséhez szükséges irányelveket tartalmazó dokumentum. A biztonság kérdésére nagy hangsúlyt fektet, de részleteiben nem foglalkozik a kérdéssel. 9

ITIL = IT Infrastructure Library

Az ITIL kezdetben brit szabvány (BS 15000) és kormányzati ajánlás volt, a közigazgatási területen általában megkövetelték az alkalmazását. Mivel a gyakorlati alkalmazás tapasztalatai kedvezőek voltak, a módszertant a piaci környezetben is egyre inkább használni kezdték. Az ITIL-t egyre inkább használni kezdték a szigetországon kívül is. Egyre több országban alakultak helyi Fórumok, ezek összefogására létrejött az IT Service Management Forum International, amely a nemzeti fórumokon keresztül egyrészt segítette az ITIL terjedését, másrészt ügyelt arra, hogy az egységes maradjon. Az ITIL mára „de facto” nemzetközi szabvánnyá vált, amelynek több országban működik felhasználói szervezete, meghatározó módszertanná vált az informatikai infrastruktúra és informatikaszolgáltatás irányítása területén. Az ITIL-t számos nemzetközi informatikai cég is elfogadta és támogatja, így például a Hewlett Packard, Microsoft, IBM stb. Ezek a cégek saját gyakorlatukba beépítették az ITIL terminológiáját és megközelítését. Sok szolgáltató, amely támogató szoftver eszközöket kínál, igyekszik azokat ITIL konformmá tenni, hogy ezzel is javítsa piaci pozícióját. A ITB Infrastrúktura menedzsment címen 15. számú ajánlásaként kiadta. A 3.1 verziót 2002. novemberében honosították. 10

COBIT = Control Objectives for Information and Related Technology

Az Information Systems Audit and Control Foundation (Információs Rendszerek Ellenőrzésével és Vizsgálatával foglalkozó Alapítvány), az IT Governance Institute és a COBIT: Control

Objectives for Information and Related Technology (Információ.technológiai Kontroll Irányelvek) támogatói elsősorban azzal a céllal dolgozták ki az Összefoglaló áttekintés, a Keretrendszer, az

Ellenőrzési irányelvek, a Vezetői útmutató, az Auditálási útmutató és az Alkalmazási módszerek elnevezésű kiadványokat (együttesen a Termék.), hogy forrásanyagot biztosítnak az ellenőrzési szakemberek számára. A COBIT üzleti folyamatokra helyezi a fő hangsúlyt, és az ezeket támogató informatikai folyamatokhoz kapcsolódóan, amelyek négy területre öszpontosít: tervezés és szervezet; beszerzés és üzembe állítás; informatikai szolgáltatás és támogatás valamint felügyelet.

- 106 -



Az Informatikai Tárcaközi Bizottsága (ITB) „Informatikai biztonsági módszertani kézikönyv” címet viselő, 1994-ben kiadott ITB 8. számú ajánlása eredeti célja a szervezetet az informatikai biztonsági koncepciójának kialakítására történő felkészítés volt. A biztonsággal kapcsolatos legfontosabb tudnivalók, valamint az informatikai biztonság és a szervezet összbiztonsága közötti összefüggések meghatározó elemei a kézikönyvhöz csatolt mellékletekben találhatók meg. A

ITB 8. számú ajánlását, mint az informatikai biztonság – CRAMM alapú – kockázatelemzési módszertanát a közigazgatás területén kívül is elterjedten használják.

Az Informatikai Rendszerek Biztonsági Követelményei című, ITB 12. sz. ajánlás de facto szabvánnyá vált. Kidolgozásánál elsődleges szempont volt, hogy ne csak a logikai védelem előírásait tartalmazza, hanem jelenjenek meg benne az adminisztratív és a fizikai védelem követelményei is. A logikai védelem (hardver, szoftver, hálózatok) esetében az ITSEC lett adaptálva, ugyanakkor részletes követelményeket és védelmi intézkedéseket tartalmaz az informatikai biztonság adminisztratív és a fizikai védelem területeire, a szervezeti, személyi és fizikai biztonság kérdéseire is. A gazdasági élet számos szereplője a saját biztonsági politikája kialakításakor figyelembe vette a 12. sz. ajánlást, több esetben a mai napig is belső szabályzóként, követelményrendszerként használják a biztonsági követelmények meghatározására. Az CC feldolgozására és honosítására irányuló munka hazánkban 1997-ben kezdődött, majd 1998-ban a ITB 16. sz. ajánlásaként „Common Criteria (CC), az

informatikai termékek és rendszerek biztonsági értékelésének módszertana” címen, mint a Common Criteria 1.0 változatának hazai feldolgozása kiadásra került. A ITB 16. sz. ajánlása helyét a MIBÉTS, a Magyar informatikai Biztonsági Értékelési és Tanúsítási Séma vette át.

A Magyar Információs Társadalom Stratégia készítéséről rendelkező 1214/2002. (XII.28.) sz. Kormányhatározat alapján az Informatikai és Hírközlési Minisztérium 2004-ben úgy döntött, hogy a nemzetközi trendekkel összhangban kidolgoztatja a szervezeti szintű informatikai biztonság követelményeit és a vizsgálat rendjét – mint Információs Társadalom Koordinációs Tárcaközi Bizottság ajánlásait – az ISO/IEC 1779911 nemzetközi szabvány alapján, az ISO/IEC TR 1333512 műszaki beszámoló, továbbá a NATO C-M(2002)4913 és az Európai Unió 2001/264/EK14 releváns szabályozásai figyelembe vételével. A szervezeti szintű informatikai biztonsági ajánlástervezetek közös, összefoglaló elnevezése a Magyar Informatikai Biztonság Irányítási Keretrendszer (MIBIK). A MIBIK – jelenleg – két kötetből áll. Az első Az Informatikai Biztonság Irányításának Követelményrendszere (IBIK), a második Az Informatikai 11 ISO/IEC

17799:2000 „Information Technology – Code of practice for information security

management” 12 ISO/IEC

TR 13335 Guidelines for the Management of IT Security (GMITS)

13

Security within the North Atlantic Treaty Organisation (NATO)

14

Európai Unió Tanácsának Biztonsági Szabályzata

- 107 -



Biztonság Irányításának Vizsgálata (Tanúsítása) – módszertan (IBIV) címet

viseli.

Az IBIK azoknak ad segítséget az informatikai biztonság szervezeti szintű kezeléséhez, akik saját szervezetükben a biztonság kezdeményezéséért, megvalósításáért és megtartásáért felelnek. A követelményrendszer átfogó tájékoztatást ad a szervezetek vezetésének és szakembereinek az informatikai biztonsággal kapcsolatos követelményekről. Felhívjuk a figyelmet, hogy a változó viszonyok között a mindenkori hatályos jogszabályok keretei között kell alkalmazni ezt az ajánlást. Az IBIK célja a szervezetek részére egységes elveken nyugvó, a nemzetközi szabványokhoz és ajánlásokhoz igazodó olyan hazai előírások biztosítása az informatikai biztonságának megteremtéséhez. Az IBIK szerkezetében pontosan követi az ISO/IEC 1779:2000 nemzetközi szabványét, és tartalmában is többnyire erre épül, a már fent említett további anyagok felhasználásával. Ezzel a megoldással azt biztonság alapelvet követi, miszerint a védelmi intézkedéseknek a rendszer összes elemére ki kell, hogy terjednek (teljes körűség), és valamennyi releváns fenyegetést figyelembe kell venniük (zártság). Az IBIK alapján elkészíthetők az informatikai biztonság alapdokumentumai (az informatikai biztonságpolitika, az informatikai biztonsági stratégia és az Informatikai Biztonsági Szabályzat), segítséget ad a biztonságos működéshez szükséges szervezeti struktúra, a személyi, a fizikai és az elektronikus információvédelem kialakításához. A szervezetek vezetése és belső ellenőrző szervei által végrehajtott ellenőrzések mellett a nemzetközi, de már a hazai gyakorlatban is egyre jobban terjed – megfelelő felkészülés után – a BS 7799 (ISO/IEC 17799) szabványnak való megfelelést bizonyító audit elvégzése. A hazai gyakorlatban nincs elfogadott, elismert eljárásrend erre a tanúsítási folyamatra, ezért szükségesnek látszott, hogy az informatikai biztonság vizsgálatára megfelelő módszertan kerüljön kiadásra, amely a vizsgálatokon túl felhasználható a ISO/IEC 27001:2005 (BS 7799-2:2002) szabvány szerinti auditok során, illetve az azokra történő felkészüléshez. Az IBIV célja az informatikai rendszereinek biztonsági vizsgálatához egységes módszertan biztosítása A vizsgálati módszertan alapját a ITB 8. számú ajánlás15, a BS 7799-2:2002 szabvány, és az ehhez kapcsolódó PD 3001 – PD 3005 munkadokumentumok képzik. Az IBIV három fő részből áll:

15 A

Miniszterelnöki Hivatal Informatikai Tárcaközi Bizottsága (ITB) „Informatikai biztonsági

módszertani kézikönyv”, Budapest – 1994.

- 108 -


1.


Az informatikai rendszer biztonságának vizsgálata (kockázatelemzés) Az informatikai rendszer biztonságának kockázatelemzés alapú vizsgálatát írja le. Ez az eljárásrend egy CRAMM16 alapú, a ITB 8. számú ajánlása alapján, annak aktualizálásával készült kockázatelemzési módszertan.

2.

Az Informatikai Biztonság Irányítási Rendszer folyamatainak vizsgálata A vizsgálati eljárás az Informatikai Biztonság Irányítási Rendszer17 folyamatainak vizsgálatához adnak részletes segítséget.

3.

Biztonsági intézkedések vizsgálata Itt a biztonsági rések feltárásához az un. Gap ananlysis került felhasználásra. A részletes és teljes körű kérdőívek feladata az informatikai biztonsági intézkedések részletes vizsgálata, azaz segítségükkel részletesen meghatározhatjuk, hogy az IBIK követelményei mennyiben kerültek megvalósításra. A kérdések az IBIK pontjait követve a teljes követelményrendszert vizsgálják.

Természetesen az informatikai biztonság területén számos egyéb nemzetközi és hazai szabvány és ajánlás is létezik, például az: •

ISO/IEC 9796 a digitális aláírás,

•

ISO/IEC 9797 az üzenethitelesítés,

•

ISO/IEC 13888 a letagadhatatlanság,

•

ISO/IEC 15816 a hozzáférés-ellenőrzés,

•

ISO/IEC 18014 az időbélyegzés,

•

ISO/IEC 18028 a hálózatbiztonság,

•

ISO/IEC 18033 a rejtjelzés (titkosítás),

•

ISO/IEC 19790 a kriptográfiai témájában került kiadásra.

modulok

biztonsági

követelményei

Valamint az Informatikai és hírközlési Minisztérium ajánlásai: •

Az Informatikai és Hírközlési Minisztérium ajánlása a közigazgatásban a hitelesítés-szolgáltatók által végzett viszontazonosítás protokolljának műszaki specifikációjára

•

Az Informatikai és Hírközlési Minisztérium ajánlása a közigazgatásban alkalmazható elektronikus aláírási szabályzatok készítésére

•

Az Informatikai és Hírközlési Minisztérium ajánlása a közigazgatásban alkalmazható elektronikus aláírás formátumok műszaki specifikációjára

16 CRAMM

= CCTA Risk Analysis and Management Method. CCTA = Central Computer and

Telecommunications Agency. 17 Information

Security Management System (ISMS)

- 109 -



•

Az Informatikai és Hírközlési Minisztérium ajánlása a közigazgatásban alkalmazható végfelhasználói tanúsítványok szerkezetének és adattartalmának műszaki specifikációjára

•

Az Informatikai és Hírközlési Minisztérium ajánlása a közigazgatásban alkalmazható időbélyegzés formátum műszaki specifikációjára

•

A közigazgatásban biztonságos azonosításra, hitelesítésre, elektronikus aláírásra és titkosításra alkalmazható intelligens kártyák fájlszerkezetének és interfészének műszaki specifikációja

- 110 -


7

Az önkormányzati környezet specialitásai


A közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló 2004. évi CXL. törvény 8. § (1) bekezdése előírja, hogy „A közigazgatási hatósági eljárásban az egyes eljárási cselekmények törvény, kormányrendelet és önkormányzati rendelet eltérő rendelkezése hiányában, jogszabályban meghatározott módon, elektronikus úton is gyakorolhatók.” A helyi önkormányzat képviselő-testületére, átruházott hatáskörben annak szerveire, a főjegyzőre, a jegyzőre (körjegyzőre), a képviselő-testület hivatalának ügyintézőjére, a megyei jogú város kerületi hivatalának vezetőjére, a hatósági igazgatási társulásra előírja, hogy azok az ügyfelek hatékonyabb tájékoztatása, ügyintézésük elősegítése érdekében elektronikus tájékoztató szolgáltatásokat nyújthatnak, illetve a szolgáltatás nyújtására törvény kötelezheti őket. Az önkormányzatok és más szervezetek kapcsolattal rendelkeznek a központi közigazgatás elektronikus ügyintézési rendszeréhez és szolgáltatásaihoz. Az ügyfelek hatékonyabb tájékoztatása érdekében elektronikus tájékoztató szolgáltatások célja, hogy teljes körű tájékoztatást adjon az ügyfeleknek a közigazgatási szervezet hatáskörébe tartozó eljárásokkal kapcsolatos tudnivalókról. Ennek elsősorban arra kell koncentrálnia, hogy az egyes kérelmeket milyen formában (rendszeresített nyomtatvány űrlapon vagy sem), milyen kötelező tartalmi elemekkel kell benyújtani, milyen mellékleteket kell csatolni, mekkora illetéket kell leróni, szükséges-e személyes megjelenés, A KIETB 19. számú ajánlása a központi államigazgatás szervezetei által működtetett honlapok tartalmi és formai követelményeire részletes előírásokat és útmutatót ad, és bár az önkormányzatok számára nem kötelező, használatát javasoljuk, mert részben megkönnyíti a tervezési munkákat, részben az ügyfelek számára is könnyebbség az azonos elveken működő honlapok használata. Az elektronikus ügyintézés esetében a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló 2004. évi CXL. törvény és az 1044/2005 Korm. határozat előírásai alapján az ügyfél-azonosítást szükségessé tevő közigazgatási elektronikus szolgáltatások elektronikus aláírást nem használó természetes személy ügyfelek számára csak az Ügyfélkapun történő belépéssel, és az ott végzett azonosság ellenőrzés után vehetők igénybe. Az 1044/2005 (V.11.) Korm határozat 2. pontja kimondja, hogy „A Ket.-ben rögzített alapvető infrastrukturális szolgáltatásokat biztosító központi elektronikus szolgáltató rendszer felügyeletét, üzemeltetését a Miniszterelnöki Hivatal biztosítja. Az elektronikus aláírással nem rendelkező természetes személy ügyfelek azonosítása kizárólagosan az e központi rendszer részét képező ügyfélkapu igénybe vételével történhet.” A KIETB az ügyfélkapu szolgáltatásaihoz történő kapcsolódás műszaki specifikációja című 21. számú ajánlása bemutatja, hogy az ügyfélkapuhoz csatlakozni szándékozó, elektronikus közigazgatási ügyintézést biztosítani kívánó közigazgatási szervek, illetve a számukra fejlesztést és üzemeltetést végző informatikai szolgáltatók számára

- 111 -



•

milyen szolgáltatásokat biztosít az ügyfélkapu az ügyfelek azonosításához; • hogyan tudják saját portál rendszerük szolgáltatásai közé az ügyfélkaput beilleszteni; • hogyan nyújthatják saját szolgáltatásaikat a kormányzati portálon keresztül; • milyen követelményeknek kell megfelelniük a sikeres csatlakozás érdekében. Ennek megfelelően a központi elektronikus szolgáltató rendszer ezen szolgáltatása minden elektronikus közigazgatási ügyintézést, vagy adatbázisból adatszolgáltatást biztosítani kívánó, arra jogosult szerv számára díjtalanul áll rendelkezésre. A 195/2005. (IX. 22.) Korm. rendelet az elektronikus ügyintézést lehetővé tevő informatikai rendszerek biztonságáról, együttműködési képességéről és egységes használatáról 3. § (1) alapján az informatikai és hírközlési miniszter ajánlást bocsát ki az elektronikus ügyintézés biztosításához kapcsolódó műszaki előírásokról, valamint a közigazgatási nyilvános kulcsú infrastruktúra, különösen a közigazgatási gyökér-hitelesítésszolgáltató működtetésének feltételrendszeréről. A 195/2005. (IX. 22.) Korm. rendelet 8. § (1) szerint „a hatóságnak rendelkeznie kell: a) az informatikai célrendszer felépítésére vonatkozó rendszerleírásokkal és modellekkel, b) az informatikai célrendszerben tárolt és feldolgozott adatok tárolási szerkezetének és szintaktikai feldolgozási szabályainak leírásával, c) az adatokhoz történő hozzáférési rend meghatározásával, valamint d) az informatikai célrendszer működtetésére vonatkozó utasításokkal és előírásokkal. (2) A hatóság a saját maga által üzemeltetett informatikai célrendszer vonatkozásában belső szabályzatában meghatározza az informatikai célrendszer üzemeltetésével és ellenőrzésével kapcsolatos egyes munkakörök betöltéséhez szükséges informatikai ismereteket. (3) A hatóság köteles az informatikai célrendszer informatikai biztonsági követelményeiért általánosan felelős személyt és az informatikai célrendszer üzemeltetéséért önállóan felelős személyt kinevezni …” A 195/2005. (IX. 22.) Korm. rendelet előírja az informatikai biztonsági irányítási és kockázat felmérési alapelveket. Ez alapján az informatikai célrendszer informatikai biztonsági kockázatait legalább kétévenként fel kell mérni, és gondoskodni kell az informatikai célrendszer kockázatokkal arányos védelméről a tervezés, a beszerzés, az előállítás, az üzemeltetés és a felülvizsgálat területén. A 195/2005. (IX. 22.) Korm. rendelet V. fejezetében általános informatikai biztonsági követelmények vannak informatikai biztonsági irányítási rendszer kialakítására, az informatikai biztonsági terv tartalmára. Az informatikai és

- 112 -



hírközlési miniszter ajánlást bocsát ki a biztonsági tervek részletes tartalmára nézve18.

18

Jelenleg ezek az anyagok véleményezés alatt állnak.

- 113 -


8

Az elektronikus aláírás


A közigazgatási hatósági eljárás és szolgáltatás általános szabályairól szóló 2004. évi CXL. Törvény (KET) végrehajtási rendeletei (vhr.) részletesen, többször is foglalkoznak az elektronikus aláírással. A kiemelt figyelem ellenére azonban viszonylag kevesen ismerik és még kevesebben használják a technológiát, annak ellenére, hogy ez lehetne az egyik igazi kulcsa a távoli, megjelenés nélküli elektronikus ügyintézésnek. Ebben a fejezetben közérthetően bemutatjuk, hogy mit is kell elektronikus aláírás alatt érteni és a gyakorlatban mit jelentenek a KET vhr.-ekben található előírások. Gyakori tévedés, hogy az elektronikus aláírás alatt a hagyományos kézi aláírás digitalizált, szkennelt változatát értik, esetleg egy szöveg alá begépelt nevet. Az elektronikus aláírásnak semmi köze nincs a hagyományos aláírásunkhoz, nem kell tollat a kezünkbe venni az elektronikus aláírás létrehozásához. Elektronikusan aláírni csak elektronikus adatot tudunk. Elektronikus adat alatt pedig bármilyen, a számítógépen található fájlt lehet érteni (pl. Word dokumentum, PDF fájl, stb.). Az elektronikus aláírás egy olyan bonyolult matematikai művelet, melynek során biztosítani lehet, hogy az eredeti elektronikus dokumentumot az a személy hitelesítette, akinek ehhez joga volt, ezt később nem tagadhatja le és a dokumentum nem változott meg a hitelesítés óta. A KET vhr.-ek sokszor hivatkoznak olyan fogalmakra, melyekhez az elektronikus aláírás folyamatát részleteiben ismerni kell. Az alábbiakban bemutatjuk ennek a folyamatnak az elméletét, majd a gyakorlatát is. Összefoglalva az elektronikus aláírás a gyakorlatban egy olyan digitális adat, mely: • az aláírt dokumentum lenyomatát felhasználva, • az aláíró titkos kulcsával kódolva jön létre, • mely egy aláírás-létrehozó eszközön található, • felhasználva az aláíró tanúsítványát, • amiben a dekódoló nyilvános kulcs is megtalálható, • melynek érvényessége a visszavonási listán található, • valamint tartalmazhat egy időbélyegzőt, • melyek a időbélyeg-szolgáltatótól19 szerezhetők be. A lenyomat olyan meghatározott hosszúságú, az elektronikus dokumentumhoz rendelt bitsorozat, amelynek képzése során a használt eljárás (lenyomatképző eljárás) a képzés időpontjában teljesíti a következő feltételeket: • a képzett lenyomat egyértelműen származtatható az adott elektronikus dokumentumból;

19

Rendszerint hitelesítés-szolgáltatók nyújtanak időbélyeg-szolgáltatást

- 114 -


• •


a képzett lenyomatból az elvárható biztonsági szinten belül nem lehetséges az elektronikus dokumentum tartalmának meghatározása vagy a tartalomra történő következtetés; a képzett lenyomat alapján az elvárható biztonsági szinten belül nem lehetséges olyan elektronikus dokumentum utólagos létrehozatala, amelyre alkalmazva a lenyomatképző eljárás eredményeképp az adott lenyomat keletkezik.

A lenyomat tehát az eredeti elektronikus dokumentumból származó kivágott és matematikailag összekavart darab. Az elektronikus dokumentumból csak egyfajta lenyomat állítható elő, de a lenyomatból nem lehet visszaállítani az eredeti dokumentumot. 001 101 010 010 001 110 100 011 111 0 39. ábra: Lenyomat képzése az elektronikus dokumentumból

A titkos kulcs (vagy más néven aláírás-létrehozó adat) olyan egyedi adat (jellemzően kriptográfiai magánkulcs), melyet az aláíró az elektronikus aláírás létrehozásához használ. Ezt az egyedi adatot csak és kizárólag az aláíró ismeri. Ez a kulcs valamilyen bonyolult matematikai eljárás segítségével végrehajtott kódoláshoz szükséges paraméter, szám. Az elektronikus aláírás második lépése a képzett lenyomat titkosítása. Mint írtuk, a lenyomat mindenhol különösebb nehézség nélkül előállítható az eredeti dokumentumból. Így ha az eredeti dokumentum megváltozik (pl. egy szerződésben a tartozás összege egy nullával csökken vagy nő) az a személy, aki megváltoztatta a dokumentumot, egyszerűen elő tud állítani egy új lenyomatot. Ha azonban a titkos kulccsal titkosítjuk a lenyomatot, biztosak lehetünk abban, hogy a lenyomat és ezen keresztül a dokumentum is ugyanaz, amit az aláíró el akart nekünk küldeni.

- 115 -



001 101 010 010 001 110 100 011 111 0

110 110 111 100 001 101 011 101 110 1

40. ábra: A lenyomat kódolása a titkos kulccsal

Az aláírás-létrehozó eszköz olyan hardver, illetve szoftver eszköz, melynek segítségével az aláíró az aláírás-létrehozó adatok (titkos kulcs) felhasználásával az elektronikus aláírást létrehozza. Tipikusan egy intelligens kártya, vagy egy számítógépen tárolt fájl. Biztonságos aláírás-létrehozó eszközről (BALE) többek között akkor beszélhetünk, ha az a titkos kulcsot minden körülmények között biztonságosan megőrzi, onnan kinyerni nem lehet. A BALE-kre vonatkozó előírásokat a törvény rögzíti. Ezek mindig valamilyen hardver eszközök, rendszerint intelligens kártyák, de létezik más megoldás is. Intelligens kártyákkal az élet minden területén lehet találkozni. Ebbe a csoportba tartoznak a mobiltelefonok SIM kártyái, az új típusú bankkártyák, melyeken chip található, sőt a különböző chippel ellátott vásárlói hűségkártyák is. Elektronikus aláíráshoz ezek egyik speciális fajtája, a kriptográfiai kártyák használhatók.

001 101 010 010 001 110 100 011 111 0

110 110 111 100 001 101 011 101 110 1

41. ábra: Titkos kulcs az aláírás-létrehozó eszközön

A tanúsítvány a hitelesítés-szolgáltató (megbízható harmadik fél) által kibocsátott igazolás, amely az aláírás-ellenőrző adatot (nyilvános kulcs) egy meghatározott személyhez kapcsolja, és esetlegesen igazolja valamely más tény, - 116 -



tulajdonság fennállását, például a hatósági (hivatali) jelleget. A tanúsítvány mindenki számára megismerhető, az internetről letölthető. A tanúsítvány feladata, hogy az elektronikus aláírást megszemélyesítse, azaz olyan adatokat közöljön a címzettel, melyek segítik a feladó azonosítását. A tanúsítványban ezért megtalálható az aláíró neve, e-mail címe, városa, esetleg cégének neve. Ezek az információk azonban nem elégségesek az aláíró teljesen egyedi azonosításához a hagyományos értelemben (pl. a Szabó Géza, Budapest, [email protected] adathalmaz nem elég egy személy azonosításához). A valódi személlyel csak a hitelesítés-szolgáltató képes összekapcsolni a tanúsítványt, egy megkülönböztetett adat, pl. a tanúsítvány sorszáma alapján. A technológia lehetőséget adna arra, hogy a tanúsítványba olyan megkülönböztetett adat kerüljön, mely a közigazgatási eljárások során leegyszerűsítené az azonosítást (adószám, személyi azonosító, stb.), erre azonban a magyar adatvédelmi szabályozás miatt nincs lehetőség. Ennek a problémának a megoldására vezették be a viszontazonosítást, mely egyedi magyar megoldás. Azzal, hogy az aláírt lenyomatot és a tanúsítványt hozzákapcsoljuk az eredeti dokumentumhoz, létrejött az alap elektronikusan aláírt dokumentum.

001 101 010 010 001 110 100 011 111 0

110 110 111 100 001 101 011 101 110 1

42. ábra: Alap elektronikusan aláírt dokumentum

Az időbélyegző az elektronikus dokumentumhoz végérvényesen hozzárendelt vagy azzal logikailag összekapcsolt olyan adat, amely igazolja, hogy az elektronikus dokumentum az időbélyegző elhelyezésének időpontjában változatlan formában létezett. Ez a gyakorlatban azt jelenti, hogy az aláírás után egy megbízható szolgáltatótól kérünk egy pontos időpontot, ami mindenki számára bizonyítja az aláírás pontos dátumát és időpontját. Azért szükséges külső helyről időpontot szerezni, mert az elektronikus aláírási folyamatokban az időpontokkal is lehetőség van visszaéléseket elkövetni. Mindkét félnek az a megfelelő, ha az időt is egy megbízható harmadik fél szolgáltatja. Az alap elektronikusan aláírt dokumentum kiegészítve időbélyegzővel technikailag már teljesen bizonyító erejűnek tekinthető. Az időbélyegzés során az időbélyegzőszolgáltató is digitálisan aláírja az eredeti dokumentum lenyomatát, amihez még a pontos időt is hozzákapcsolja.

- 117 -



001 101 010 010 001 110 100 011 111 0

110 110 111 100 001 101 011 101 110 1

43. ábra: Időbélyegzővel ellátott elektronikusan aláírt dokumentum

A nyilvános kulcs (aláírás-ellenőrző adat) olyan egyedi adat, melyet az elektronikusan aláírt elektronikus dokumentumot megismerő személy az elektronikus aláírás ellenőrzésére használ. Mindenki által megismerhető paraméter, tipikusan egy szám. Segítségével a titkos kulccsal kódolt digitális adat dekódolható. Ez az adat szerepel a tanúsítványban is, így mindenki számára hozzáférhető. Amikor az aláíró elküldte az elektronikusan aláírt dokumentumot a címzettnek (ellenőrzőnek), az a következőket látja: az eredeti dokumentum, az aláíró titkos kulcsával titkosított lenyomat, a tanúsítvány és az időbélyegző. Ezekből az adatokból kell megállapítani, hogy az aláírás megfelel-e az ellenőrző elvárásainak, illetve hogy érvényes-e. Ennek a következő lépései vannak: • Az ellenőrző is elvégzi a lenyomatolást a megkapott dokumentumon. Ezzel keletkezik egy lenyomat az ellenőrző oldalán is. • A tanúsítványból kiveszi a nyilvános kulcsot, ezzel dekódolja az aláíró által küldött titkosított lenyomatot. • A dekódolt lenyomatot összehasonlítja a saját maga által generált lenyomattal. Ha ez a kettő megegyezik, akkor biztos lehet benne, hogy a dokumentum ugyanaz, amit az aláíró elküldött.

- 118 -



001 101 010 010 001 110 100 011 111 0 001 101 010 010 001 110 100 011 111 001 0 101 010 010 001 110 100 011 111 0

110 110 111 100 001 101 011 101 110 1

110 110 111 100 001 101 011 101 110 1

44. ábra: Az aláírás ellenőrzésének folyamata

A nyilvános kulcs fogalmának bevezetésével együtt kell megemlítenünk, hogy mindazok a technikák, melyekről beszélünk az ún. nyilvános kulcsú infrastruktúrában (public key infrastructure – PKI) használatosak. Ennek elemei a titkos és a nyilvános kulcs. Képzeljünk el egy ládát, melybe a titkunkat rakjuk. A ládán egy olyan lakat van, melyben két kulcslyuk található. Az egyik kulcslyukhoz egyetlen kulcs létezik, mely a mi birtokunkban van. A másik kulcslyukhoz tetszőleges kulcsot lehet készíteni. A lakat tulajdonsága, hogy ha az egyik kulccsal bezárjuk, csak a másikkal lehet kinyitni. Ez azt jelenti, hogy ha az egyetlen kulccsal zárjuk be a ládát, akkor bárki ki tudja nyitni, ha viszont bárki bezárja a ládát, csak mi tudjuk kinyitni a saját kulcsunkkal. Az első esetben az, aki kinyitja a ládát, biztos lehet abban, hogy bármi is van a ládában, azt mi, az egyetlen kulcs birtokosa tettük be. A második esetben, bárki bármit is zár be a ládába, biztos lehet abban, hogy csak mi, az egyetlen kulcs birtokosa vehetjük azt ki. Ez a magyarázat elsőre valószínűleg eléggé bonyolultnak tűnik, de ha a kedves Olvasó kicsit jobban átgondolja, azonnal megérti a titkos és nyilvános kulcsok működését. Visszatérve az aláírás ellenőrzésének folyamatára, a következő fontos fogalom a visszavonási lista, mely egy gép által értelmezhető lista, melyet a hitelesítésszolgáltató tesz közzé. Tartalmazza azokat a tanúsítványokat, melyek idő előtt

- 119 -



érvénytelenné váltak. Azokat az elektronikus aláírásokat, melyek az aláírás időpontja előtt visszavont tanúsítványok felhasználásával készültek, nem fogadhatók el. Tanúsítványt általában akkor vonnak vissza, ha elveszett a titkos kulcsot tároló aláírás-létrehozó eszköz.

001 101 010 010 001 110 100 011 111 0 001 101 010 010 001 110 100 011 111 001 0 101 010 010 001 110 100 011 111 0

110 110 111 100 001 101 011 101 110 1

110 110 111 100 001 101 011 101 110 1

45. ábra: Visszavonási lista ellenőrzése

A hitelesítés-szolgáltató egy elektronikus aláírással kapcsolatos szolgáltatást nyújtó természetes személy, jogi személy vagy jogi személyiség nélküli szervezet. Gyakorlatilag az a megbízható harmadik fél, akiben törvény adta kötelezettségei miatt mindenki megbízhat. Feladata a tanúsítványok kibocsátása és kezelése, a titkos kulcs elhelyezése az aláírás-létrehozó eszközön és az időbélyegző szolgáltatása.

- 120 -



001 101 010 010 001 110 100 011 111 0 001 101 010 010 001 110 100 011 111 001 0 101 010 010 001 110 100 011 111 0

110 110 111 100 001 101 011 101 110 1

110 110 111 100 001 101 011 101 110 1

46. ábra: A hitelesítés-szolgáltató

Ebből az elsőre bonyolultnak tűnő eljárásból a felhasználó azonban csak nagyon kevés dolgot érzékel. Nézzük át még egyszer a teljes folyamatot, ezúttal fényképekkel és képernyőképekkel dokumentálva, mi is az az elektronikus aláírás.

- 121 -



47. ábra: Biztonságos aláírás-létrehozó eszköz

Ahhoz, hogy egy dokumentumot elektronikusan alá tudjunk írni, mindenek előtt szükségünk van a biztonságos aláírás-létrehozó eszközre, ami egy ún. intelligens kártya. A képen két, bankkártyához hasonló intelligens kártyát lehet látni. Ami a hagyományos bankkártyától megkülönbözteti, az a rajtuk található chip. Ezekben a chipekben tárolják az aláírás-létrehozó adatot, azaz a titkos kulcsot. Az egyik képen látható kártya fokozott biztonságú, a másik minősített elektronikus aláírás létrehozására használható. Látszólag semmi különbség nincs a két kártya között. A látszat ebben az esetben nem csal. Műszakilag mind a két kártya azonos. Ami megkülönbözteti őket, az az elektronikus aláírásról szóló 2001. évi XXXV. számú törvény. Eszerint a fokozott biztonságú elektronikus aláírással ellátott elektronikus iratok az írásbafoglalás jogszabályi követelményének felelnek meg. A minősített elektronikus aláírással ellátott elektronikus okiratokat teljes bizonyító erejű magánokiratnak minősíti, így a bíróságoknak nem kell külön mérlegelniük ezek bizonyító erejét. A jogszabály szerint a minősített elektronikus aláírás olyan fokozott biztonságú elektronikus aláírás, amelyet az aláíró biztonságos aláírás-létrehozó eszközzel hozott létre, és amelynek hitelesítése céljából minősített tanúsítványt bocsátottak ki. Tehát csak jogi különbség van a két típus között. A kártyák és a számítógép között a kártyaolvasó teremt kapcsolatot. A kártyaolvasó feladata, hogy a számítógép által kiadott parancsokat végrehajtsa a kártyán található adatok felhasználásával. A legtöbb kártyaolvasó egyszerűen, USB csatlakozón keresztül kapcsolható a számítógépre, a Windows XP és az új Linux disztribúciók pedig automatikusan elvégzik a telepítését. Ezután az intelligens kártyákhoz szükséges szoftvereket kell feltelepíteni. Minden

- 122 -



kártyához külön program van, csak ezek telepítése után lehet elérni a kártyákat a számítógépről. Az elektronikus aláírás létrehozásához szükség van még egy elektronikus aláírás-létrehozó szoftverre. Ennek három típusa ismert. • Az első változat a felhasználó számítógépére települ, a Start menüből érhető el, használata megegyezik bármelyik másik programéval. Így kell kezelni a nem párbeszédre épülő elektronikus ügyintézés során érkező elektronikusan aláírt dokumentumokat, melyek e-mail-ben érkeznek. Egyszerűen meg kell nyitni a mellékletben küldött dokumentumot egy elektronikus aláírás-ellenőrző szoftverben. Ennek változata az aláírt email használata, amely során nem egyedi dokumentumokat, hanem elektronikus levelet írunk alá. Ebben az esetben rendszerint a levelező program beépített aláírás funkcióját vehetjük igénybe. • A második típus az internetes böngészőből érhető el, általában az Internet Explorerből, ritkábban Mozilla Firefox vagy Opera alól. Erre példa az Ügyfélkapu elektronikus aláírásra használt modulja. Ez a párbeszédre épülő elektronikus ügyintézés módszere. • A harmadik típus a felhasználók elől rejtve marad, ezek egy szerveren futnak és automatikusan írják alá a dokumentumokat. A közigazgatáson belüli és a közigazgatástól az állampolgárok felé zajló kommunikációban az első változatot érdemes használni, hiszen a munka az adott számítógépen történik. Az állampolgároktól a közigazgatás felé zajló kommunikáció esetén a második módszer javasolt, mert ekkor az állampolgároknak nem szükséges saját aláíró szoftverrel rendelkezniük. Nagy mennyiségű, automatikus aláírás létrehozásánál a harmadik változat a leghatékonyabb, hiszen máshogy gyakorlatilag elképzelhetetlen több tízezer aláírt dokumentum előállítása. Az elektronikus aláírás folyamatából ezeknek az összetevőknek a használatával a felhasználó a következőket látja: • Be kell dugni a kártyát az olvasóba • A szoftverben ki kell választani az aláírandó fájlt • Rá kell kattintani az aláírás gombra • Be kell írni a PIN kódot • Elmenteni az aláírt fájlt, és elküldeni a címzettnek

Az első lépés az, hogy a kártyát bedugjuk az olvasóba. Ekkor a számítógép felépíti a kapcsolatot a kártyával.

- 123 -



Az aláíró alkalmazásban kiválasztjuk azt a dokumentumot, amit elektronikusan alá akarunk írni. Ezután rá kell kattintani az aláírás gombra. A szoftver elkészíti a lenyomatot a fájlról, és elküldi azt a kártyának.

A kártyaolvasó elkezd pirosan villogni. Megérkezik a lenyomat a szoftvertől.

Ahhoz, hogy a lenyomatot a titkos kulccsal kódolni lehessen, azaz elkészülhessen a digitális aláírás, be kell írni a kártya PIN kódját, hiszen ezzel bizonyítjuk, hogy jogosultságunk van a kulcshoz való hozzáféréshez.

- 124 -



Az olvasó újra pirosan villog. Ekkor készül el a kódolt lenyomat, ami a kártyaolvasón keresztül visszajut az aláíráslétrehozó szoftverhez.

Amennyiben a szoftver beállításaiban szerepel az időbélyegző kérése, az interneten keresztül automatikusan elkészül az időbélyegző az aláíráshoz. Miután az aláírás elkészítése véget ért, a szoftver megjeleníti az aláíró és az időbélyegző adatait.

- 125 -



Az elektronikusan aláírt dokumentum pedig nem más, mint egy újabb fájl, ami ún. XML formátumban tárol minden lényeges adatot, így az aláírt fájl, az aláíró tanúsítványát, az időbélyegzőt, stb. Ezt a fájlt kell elküldeni a fogadónak.

A fogadó a megkapott XML fájlt betölti az aláírásellenőrző szoftverébe. Igen egyszerű dolga van, hiszen az Ellenőrzés gombra kattintva a szoftver minden szükséges lépést elvégez. Ellenőrzi azt, hogy az aláírás nem sérült-e meg, megnézi, hogy a tanúsítvány nincs-e rajta a visszavonási listán, nem járt-e le. Amennyiben mindent rendben talált, ezt jelzi a felhasználónak.

- 126 -



Az aláíró tanúsítványát is megnézetjük a megfelelő gombra kattintva. Ebből olyan fontos információk derülnek ki, mint a tulajdonos adatai (általában név, cím, e-mail cím), a tanúsítvány lejárati ideje, vagy a kibocsátó hitelesítés-szolgáltató.

A tanúsítványláncból derül ki, hogy az adott tanúsítvány kibocsátója megfelel-e a közigazgatás által támasztott igényeknek. Amennyiben a legfelső szinten levő hitelesítés-szolgáltató a vhrekben nevesített közigazgatási gyökér-hitelesítésszolgáltató, az aláírás biztosan megfelel az elvárásoknak.

48. ábra: Aláírás ellenőrzésének folyamata

A fenti folyamat az általános aláírási és ellenőrzési folyamatot mutatja be. A képernyőképek illusztrációk, kisebb eltérésekkel minden Magyarországon forgalomban levő szoftver hasonló módon működik. A közigazgatásban a jövőben felhasználására kerülő elektronikus aláírás-ellenőrző szoftverek nagy valószínűséggel az „Ellenőrzés” gombra kattintás után elvégzik mindazt a vizsgálatot, melyet a 193/2005. (IX. 22.) Kormányrendelet IV. fejezete előír, így - 127 -



semmilyen manuális ellenőrzés nem lesz szükséges. Ez az igen egyszerű ellenőrzési eljárás nagyban megkönnyíti a köztisztviselők munkáját elektronikusan aláírt dokumentumok fogadásánál. Az ebben a rendeletben említett elektronikus űrlap nem más, mint egy böngészőben megjelenő internetes oldal, melyet az állampolgár kitölt, elektronikusan aláír. Ez az űrlap a hivatal szerverén tárolódik, az ellenőrzésre ott kerül sor. Általában ez a típusú ellenőrzés automatikus, a szerverre telepített program végzi, de ha nem ilyen megoldást használnak, az ellenőrzés ugyanolyan folyamat, mint amit az előzőekben leírtunk. A közigazgatásban használt elektronikus aláírási folyamatot azonban néhány további szabály árnyalja. A legfontosabb ezek közül talán a viszontazonosítás folyamata. Az elektronikus aláírás hagyományos használatánál az aláíró személyazonossága a tanúsítványból derül ki egy egyedi azonosító alapján (pl. adószám). Magyarországon a személyes adatok védelme érdekében nincs lehetőség ilyen, hatóság számára egyértelmű azonosító használatára. Emiatt a technológia csak utólagos ellenőrzést tesz lehetővé, azaz vitás eseteknél be lehet vonni a hitelesítés-szolgáltatót a tanúsítványhoz tartozó személy azonosításához. A magyar jogszabály a viszontazonosítás bevezetésével lehetőséget teremt a megelőző azonosításra. Ez azt jelenti, hogy a hivatal, miután megkapta az állampolgár elektronikusan aláírt beadványát, az abban szereplő személyes adatokat és a tanúsítványt elküldi a hitelesítés-szolgáltatónak, ahol ellenőrzik, hogy a személyes adatok és a tanúsítvány összetartozik-e. Az ellenőrzés eredményét igennel vagy nemmel jelzik a hivatal felé. A viszontazonosítás elektronikusan és papíralapon is történhet. Mivel a papíralapú adminisztráció hosszadalmas és bonyolult, a közeljövőben minden bizonnyal az elektronikus aláírás-ellenőrző szoftverekbe be fog épülni a viszontazonosítás képessége is, azaz a köztisztviselő automatikusan megkapja a viszontazonosítás eredményét. A fentiekből látszódik, hogy egy elektronikusan aláírt beadvány ellenőrzéséhez optimális esetben csak internet kapcsolat és egy egérkattintás szükséges, majd a képernyőn megjelenő zöld pipákból vagy vörös ikszekből látszik, hogy az adott elektronikus aláírás elfogadható-e vagy további intézkedést igényel. A 195/2005. (IX. 22.) Kormányrendelet 18. §-a rendelkezik az elektronikusan aláírt dokumentumok archiválásáról. A hosszútávú elektronikus aláírás legfőbb problémája az, hogy a hitelesítő adatok az évek múlásával gyakorlatilag elérhetetlenné válnak. Hitelesítő adat a teljes tanúsítványlánc, illetve a visszavonási listák. Emiatt egy ügyirat hitelességének ellenőrzése több év távlatában nehéz feladat. Maga az ügyirat olvasható marad, csak a hozzá tartozó elektronikus aláírás ellenőrzése nehezedik meg. A hiteles archiválás ezért egy viszonylag komplex feladat, melynek megoldását mindenképpen archiválási szolgáltató közbeiktatásával célszerű megoldani. Jelenleg ilyen szolgáltató nincs Magyarországon, de ha élesen felmerül az igény, meg fog nyílni ez a piac is. Minden tanúsítvány tartalmaz egy hivatkozást a hitelesítési rendre. A hitelesítési rend adja meg, hogy az adott tanúsítvány milyen körülmények között használható. A 194/2005. (IX. 22.) Kormányrendelet határozza meg, hogy milyen tanúsítványok használhatók elektronikus aláíráshoz a közigazgatásban. Ezeket a szabályokat foglalja írásba a hitelesítési rend, melyet a hitelesítés-szolgáltatók adnak ki. Ezek a rendek a hitelesítés-szolgáltatók oldalán érhetők el. Minden - 128 -



hitelesítési rendnek egy egyedi azonosítója van. Annak megállapítása, hogy egy tanúsítvány felhasználható-e a közigazgatási eljárás során, az ellenőrző szoftver feladata kell, hogy legyen, hiszen ez egy lépés az ellenőrzési folyamatban. Azonban minden érdeklődő elolvashatja a dokumentumot, és így megállapíthatja, hogy tényleg a szabályoknak megfelelően lett-e kibocsátva az adott tanúsítvány. Az elfogadható hitelesítési rendek mellett még további elfogadási és aláírási szabályokat lehet felállítani az elektronikus aláírási szabályzatban. Például, amikor a hivatal küld elektronikusan aláírt dokumentumot egy másik hivatal vagy egy állampolgár felé, szembesülni kell az aláírási jogosultság kérdésével. Minden szervezetben megvan az a személy, akinek megvan a jogosultsága egy ügyiratot aláírni. Az elektronikus aláírás ebben a tekintetben nem különbözik a hagyományos aláírástól. Célszerű tehát az elektronikus aláírást is hasonlóan kezelni a hagyományos aláíráshoz, esetleg a saját aláírási szabályzatot kiegészíteni az elektronikus formára is. A közigazgatásban használható hitelesítési rendeket, minden más elektronikus aláíráshoz kapcsolódó hivatalos információval együtt a Nemzeti Hírközlési Hatóság honlapján lehet összegyűjtve megtalálni. Az NHH elektronikus aláírási nyilvántartásában többek között megtalálható a hitelesítés-szolgáltatók listája, a kapcsolódó jogszabályok, és a regisztrál elektronikus aláírás szakértők listája. Ez utóbbit célszerű igénybe venni akkor, ha e-aláíráshoz kapcsolódó szakértelemre van szükség.

- 129 -


9

Szótár

Szótár

ACL

Access Control List – hozzáférési lista. Egy objektumhoz (pl. állomány) való hozzáférést leíró bejegyzések listája. Rendszerint pl. felhasználó és az általa elvégezhető és tiltott műveletek listáját tartalmazza.

Adminisztratív biztonság

Az információ védelme adminisztratív eszközökkel. Pl.: jelszókezelési szabályzat.

Algoritmikus biztonság

Az információ védelme informatikai eszközökkel. Pl.: titkosítás.

Autentikáció

Annak a megállapítása, hogy valaki, vagy valami az-e, mint akinek állítja magát.

Autorizáció

Valakinek vagy valaminek a feljogosítása valamely művelet elvégzésére, vagy valamely infomációhoz való hozzáférésre.

Back-up

Biztonsági mentés.

Bizalmasság

Az információhoz csak az arra feljogosított férhet hozzá.

Bluetooth

Mobil eszközök (Telfon, PDA, stb.) összekapcsolására szolgáló technika.

CIA

Confidentiality (bizalmasság), Integrity (sértetlenség), Availabily (rendelkezésre állás). Az informatikai biztonság alapkövei.

CPU

Központi feldolgozó egység (Central Processing Unit), (mikor)processzor, a számítógép fő műveletvégző egysége.

DHCP

Dinamikus hoszt konfiguráló protocol (Dynamic Host Configuration Protocol) megoldás arra, hogy az egyes hálózatra kapcsolt számítógépeket automatikusan lássunk el különböző konfigurációs paraméterekkel (IP cím, DNS kiszolgáló címe stb.)

DNS

Domain Name System – az interneten található eszközök névvel való elérhetőségét biztosító rendszer.

Elektronikus aláírás

Olyan eljárás, amely segítségével megbizonyosodhatunk az elektronikus információ forrásáról és sértetlenségéről.

Észlelő intézkedés

Olyan védelmi intézkedés, amely észleli a veszélyes esemény bekövetkeztét.

Féreg

Önállóan terjedő kártékony kód.

Fizikai biztonság

Az információt kezelő rendszerek fizikai védelmét megvalósító védelmi intézkedések. Pl.: tűzvédelem, lopás elleni védelem.

- 130 -

vezetéknélküli


Szótár

Flash drive

Mozgó alkatrészt nem tartalmazó adathordoz.

Frissítés

Szoftverekhez kiadott javítás.

GIU

Informatikai rendszerek grafikus felülete.

Hátsó ajtó

(back door) Informatikai rendszerben elrejtett lehetőség arra, hogy a védelmi szabályokat megkerülve hozzá lehessen férni a rendszerhez.

Házirend

Olyan szabályok gyűjteménye, amelyeket a rendszer a szereplőkkel betratat.

Hitelesség

A sértetlenség bizonyíthatósága

HTTP

Hypertext Transfer Protocol – a web alapvető adattovábbító protokolja, elsősorban hipertext (html) lapok továbbítására. Alapvetően szöveges, kérés-válasz jellegű protokoll.

Információ

Jelentést hordozó adat.


Olyan előírások és intézkedések végeredménye, amely biztosítja az informatikai rendszerekben tárolt, feldolgozott, előállított információ bizalmasságát, sértetlenségét, rendelkezésre állását.

IP cím

TCP/IP alapú rendszerekben egy eszköz azonosítására szolgáló cím.

Javító intézkedés

Olyan védelmi intézkedés, amely a már bekövetkezett esemény által okozott kárt csökkenti vagy szünteti meg.

Kiszolgáló

Szerver. eszköz.

Kliens

Valamely informatikai szolgáltatást igénybevevő eszköz.

Kockázatelemzés

Módszer, amely segítségével meghatározzuk kockázatokat és azok nagyságát.

Kulcs

Olyan információ, amely a titkosítási folyamatban az adott algoritmus működését vezérli.

Letagadhatatlanság

Annak biztosítása, hogy az információn műveletet végző ne tudja ezen cselekményét később letagadni.

Linux

Szabad forrású operációs rendszer.

Megelőző intézkedés

Olyan védelmi intézkedés, amely a veszélyes esemény bekövetkeztét gátolja meg.

Parancssor

Informatikai rendszerek olyan felülete, ahol a felhasználó parancsok begépelésével kommunikál a programmal.

PDA

Kisméretű hordozható számítógép, Tenyérszámyítógép.

PKI

Nyilvános kulcsú infrastruktúra (PKI). A nyilvános kulcsú titkosításon és a megbízható harmadik feleken alapuló

Valamely

- 131 -

szolgáltatást

nyújtó

informatikai


Szótár

megoldás felek hitelesítésére, elektronikus aláírásra, rejtjelezésre. PreDeCo

A védelmi intézkedések fajtái. Preventive (megelőző), detective (észelő), corrective (javító). MÉJ.

Protokoll

Szabályrendszer, amely kommunikációját

Rendelkezésre állás

Az információt az arra feljogosított igénye szerint elérheti.

Root-kit

Olyan kártékony kód, amely hozzáférést (pl. hátsó ajtó) biztosít a támadónak, miközben önmagát különböző eszközökkel elrejti a legális felhasználók elől.

Sértetlenség

Integritás. Az információt csak az arra feljogosított változtathatja.

Tanúsítvány

Olyan elektronikus adat, amely megbízható harmadik fél segítségével tanúsítja a kérdéses rendszer, kommunikáló fél azonosságát.

TCP/IP

Az internet kommunikációs alap protokollja.

Tűzfal

Olyan hálózati eszköz, amely képes valamilyen szabályrendszer alapján számítógép hálózat forgalmát szűrni.

USB

Számítógépek és perifériák vezetékes összekapcsolására szolgáló technológia.

Ügyfélkapu

Központosított felület elektronikus közigazgatási ügyek intézésére.

WEP

A WiFi korábbi, jelenleg már nem biztonságos biztonsági rendszere.

WiFi

Vezetéknélküli hálózati technológia (IEEE802.11)

Windows

A Microsoft operációs rendszer családjának neve.

WPA

A WiFi jelenleg biztonságosnak tekintett biztonsági rendszere

- 132 -

leírja

informatikai

eszközök


10

Jogszabályok

Jogszabályok

10.1 A területhez kapcsolódó egyéb jogszabályok 1992. évi LXIII. törvény a személyes adatok védelméről és a közérdekű adatok nyilvánosságáról. 1992. évi LXVI. törvény a polgárok személyi adatainak és lakcímének nyilvántartásáról 1993. évi XXXI. törvény az emberi jogok és az alapvető szabadságok védelméről szóló, Rómában, 1950. november 4-én kelt Egyezmény és az ahhoz tartozó nyolc kiegészítő jegyzőkönyv kihirdetéséről 1995. évi LXV. törvény az államtitokról és a szolgálati titokról 1995. évi LXVI. törvény a közokiratokról, a közlevéltárakról és a magánlevéltári anyag védelméről 1995. évi CXIX. törvény a kutatás és a közvetlen üzletszerzés célját szolgáló névés lakcímadatok kezeléséről 1995. évi CXXV. törvény a nemzetbiztonsági szolgálatokról (38–72. §, 3. sz. melléklet) 1996. évi XX. törvény a személyazonosító jel helyébe lépő azonosítási módokról és az azonosító kódok használatáról 1996. évi LVII. törvény a tisztességtelen piaci magatartás és a versenykorlátozás tilalmáról 1997. évi XLVII. törvény az egészségügyi és a hozzájuk kapcsolódó személyes adatok kezeléséről és védelméről 1998. évi VI. törvény az egyének védelméről a személyes adatok gépi feldolgozása során, Strasbourgban, 1981. január 28. napján kelt Egyezmény kihirdetéséről 1999. évi V. törvény a Magyar Köztársaság Kormánya és a NATO között Brüsszelben, 1994. július 5-én aláírt Biztonsági Megállapodás és az annak mellékletét képező Ügyvezetési Szabályzat megerősítéséről és kihirdetéséről 2000. évi IV. törvény az információ biztonságáról szóló, Brüsszelben, 1997. március 6-án kelt NATO Megállapodás megerősítéséről és kihirdetéséről 2001. évi XXXV. törvény az elektronikus aláírásról. 2001. évi CVIII. törvény az elektronikus kereskedelmi szolgáltatások, valamint az információs társadalommal összefüggő szolgáltatások egyes kérdéseiről 2003. évi C. törvény az elektronikus hírközlésről 2003. évi CXXIX. törvény a közbeszerzésekről (üzleti titok) 2005. évi LIII. törvény az egyének védelméről a személyes adatok gépi feldolgozása során, Strasbourgban, 1981. január 28-án kelt Egyezménynek a felügyelő hatóságokról és a személyes adatok országhatárokat átlépő áramlásáról szóló, Strasbourgban, 2001. november 8-án kelt Kiegészítő Jegyzőkönyve kihirdetéséről - 133 -


Jogszabályok

2005. évi LXXVIII. törvény a Nemzeti Akkreditáló Testület szervezetéről, feladat- és hatásköréről, valamint eljárásáról 2005. évi XC. törvény az elektronikus információszabadságról 43/1994.(III.29.) Korm. rendelet a rejtjeltevékenységről 50/1998.(III. 27.) Korm. rendelet a zártcélú távközlő hálózatokról, az EKG-ról 47/2002.(III. 26.) Korm. rendelet a kormányzati elektronikus aláírási rendszer kiépítésével összefüggő egyes kormányrendeletek módosításáról 179/2003.(XI. 5.) Korm. rendelet a nemzetközi szerződés alapján átvett, vagy nemzetközi kötelezettségvállalás alapján készült minősített adat védelmének eljárási szabályairól 180/2003.(XI. 5.) Korm. rendelet a Nemzeti Biztonsági Felügyelet részletes feladatairól és működési rendjéről, valamint az iparbiztonsági ellenőrzések részletes szabályairól 13/2003. (X. 3.) IHM rendelet az egyes hírközlési és informatikai termékek megfelelőségét vizsgáló vagy ellenőrző, illetőleg tanúsító szervezetek kijelölésének részletes szabályairól 44/2005. (III. 11.) Korm. rendelet a kormányzati informatika koordinációjáról és a kapcsolódó eljárási rendről 45/2005.(III. 11.) Korm. rendelet a Nemzeti Hírközlési Hatóságnak az elektronikus aláírással kapcsolatos feladat- és hatásköréről, valamint eljárásának részletes szabályairól 193/2005. (IX. 22.) Korm. rendelet az elektronikus ügyintézés részletes szabályairól 194/2005. (IX. 22.) Korm. rendelet a közigazgatási hatósági eljárásokban felhasznált elektronikus aláírásokra és az azokhoz tartozó tanúsítványokra, valamint a tanúsítványokat kibocsátó hitelesítésszolgáltatókra vonatkozó követelményekről 195/2005. (IX. 22.) Korm. rendelet az elektronikus ügyintézést lehetővé tevő informatikai rendszerek biztonságáról, együttműködési képességéről és egységes használatáról 335/2005. (XII. 29.) Korm. rendelet a közfeladatot ellátó szervek iratkezelésének általános követelményeiről 9/2005. (VII. 21.) IHM rendelet az elektronikus aláírási termékek tanúsítását végző szervezetekről, illetve a kijelölésükre vonatkozó szabályokról 12/2005. (X. 27.) IHM rendelet az elektronikus ügyintézési eljárásban alkalmazható dokumentumok részletes technikai szabályairól 13/2005. (X. 27.) IHM rendelet a papíralapú dokumentumokról elektronikus úton történő másolat készítésének szabályairól

- 134 -


Jogszabályok

10.2 A KIETB ajánlásai KIETB 24. számú ajánlása a központi közigazgatási szervek szoftverfejlesztéseihez kapcsolódó minőségbiztosításról és minőségirányításról A KIETB 23. számú követelményeiről

ajánlása

az

informatikai

szerződések

általános

A KIETB 22. számú ajánlása a kormányzati intézmények informatikai stratégiájának készítéséről A KIETB 21. számú ajánlása az ügyfélkapu szolgáltatásaihoz történő kapcsolódás műszaki specifikációjáról A KIETB 19. számú ajánlása a központi államigazgatás szervezeteinek internettevékenységéről, valamint az általuk működtetett honlapok tartalmi és formai követelményeiről (Verzió: 2.0)

- 135 -


11

Hivatkozások

Hivatkozások

11.1 Általános IT biztonság Hun-CERT: http://www.cert.hu/ Internetbiztonsági linkgyűjtemény: http://internetbiztonsag.lap.hu/ Az informatikai hálózati infrastruktúra biztonsági kockázatai és kontrolljai: http://www.cert.hu/ismert/00tanulmany/index.html Security Focus (angol): http://www.securityfocus.com/ Secunia – IT termékek biztonsági problémái (angol): http://secunia.com/ Információs Társadalom Koordinációs Tárcaközi Bizottság Informatikai Biztonság Albizottság: http://www.itktb.hu/engine.aspx?page=iba_oldal

11.2 Jogszabályi háttér 2001. évi XXXV. törvény az elektronikus aláírásról (Eat.) 2004. évi CXL. törvény a közigazgatási hatósági eljárás és szolgáltatás általános szabályairól (Ket.) 193/2005. (IX. 22.) Korm. rendelet az elektronikus ügyintézés részletes szabályairól (193/2005. Korm. rendelet) 194/2005. (IX. 22.) Korm. rendelet a közigazgatási hatósági eljárásokban felhasznált elektronikus aláírásokra és az azokhoz tartozó tanúsítványokra, valamint a tanúsítványokat kibocsátó hitelesítésszolgáltatókra vonatkozó követelményekről (194/2005. Korm. rendelet) 195/2005. (IX. 22.) Korm. rendelet az elektronikus ügyintézést lehetővé tevő informatikai rendszerek biztonságáról, együttműködési képességéről és egységes használatáról (195/2005. Korm. rendelet) 335/2005. (XII. 29.) Korm. rendelet a közfeladatot ellátó szervek iratkezelésének általános követelményeiről (KEIR rendelet) 12/2005. (X. 27.) IHM rendelet az elektronikus ügyintézési eljárásban alkalmazható dokumentumok részletes technikai szabályairól (12/2005. IHM rendelet) 13/2005. (X. 27.) IHM rendelet a papíralapú dokumentumokról elektronikus úton történő másolat készítésének szabályairól (13/2005. IHM rendelet)

11.3 Windows Microsoft Windows biztonság: http://www.microsoft.com/hun/biztonsag/default.mspx Microsoft Windows biztonsági oldala (angol): http://www.microsoft.com/security/default.mspx Windows biztonsági linkek: http://www.prog.hu/linkek/3020/Windows+biztonsag.html

- 136 -


Hivatkozások

11.4 Linux Linux szakmai fórum, hírek magyarul: http://www.linux.hu és http://www.hup.hu Linux dokumentációk magyarul, kezdőknek is: http://www.szabilinux.hu Linux dokumentációk angolul: http://www.tldp.org Internetes szabványok gyűjteménye: http://www.faqs.org/rfcs Linux disztribúciók listája: http://distrowatch.com

11.5 Vezetéknélküli biztonság Vezetéknélküli biztonsági portál: http://www.wardrive.net/ IEEE802.11 biztonsági linkek: http://www.drizzle.com/~aboba/IEEE/

11.6 Elektronikus aláírás E-Group Rt.: http://www.egroup.hu Elektronikus aláírási termékfejlesztők: Elektronikus aláírással kapcsolatos linkgyűjtemény: http://e-alairas.lap.hu/ Hitelesítés-szolgáltatók: Információs

Társadalom

Koordinációs

Tárcaközi

Bizottság

Elektronikus

Közigazgatás Albizottság: http://www.itktb.hu/engine.aspx?page=elka_oldal Kopint-Datorg Rt.: http://www.kopdat.hu/multisigno/ Magyar Elektronikus Aláírás Szövetség (MELASZ): http://www.melasz.hu Magyar Telekom Rt.: http://eszigno.tsystems.magyartelekom.hu/hitelesitesszolgaltatasok.vm MÁV Informatika Kft.: http://www.mavinformatika.hu/ca/ MÁV Informatika Kft.: http://www.mavinformatika.hu/ca/ Microsec Kft.: http://www.e-szigno.hu/ Microsec Kft.: http://www.e-szigno.hu/ Nemzeti

Hírközlési

Hatóság

elektronikus

http://www.nhh.hu/menu2/m2_4.htm Netlock Kft.: http://www.netlock.hu/ Netlock Kft.: http://www.netlock.hu/ Polysys Kft.: http://www.polysys.hu SDA Stúdió Kft.: http://www.sdakft.hu/

- 137 -

aláírás

nyilvántartás:


Hivatkozások

11.7 Ábrák jegyzéke 1. ábra: Phising támadás .................................................................................... - 18 2. ábra: Hamis weboldal ..................................................................................... - 18 3. ábra: Az eredeti weboldal ............................................................................... - 19 4. ábra: Ügyfélkapu tanúsítványa...................................................................... - 20 5. ábra: Automatikus frissítés beállítása ........................................................... - 24 6. ábra: Windows Update közvetlenül a böngészőből ........................................ - 25 7. ábra: Tűzfal beállítások a hálózati kapcsolatoknál ....................................... - 26 8. ábra: Windows tűzfal engedélyezése .............................................................. - 26 9. ábra: Tűzfal által blokkolt/engedélyezett programok.................................... - 27 10. ábra: Fájlrendszer típusának ellenőrzése .................................................... - 28 11. ábra: Fájlrendszer típus megadása formázáskor......................................... - 28 12. ábra: Automatikus lejátszás beállítása a TweakUI-val .............................. - 29 13. ábra: Titkosítandó mappa tulajdonságai ..................................................... - 29 14. ábra: Titkosítás engedélyezése ..................................................................... - 30 15. ábra: Megosztások megtekintése.................................................................. - 31 16. ábra: Az felhasználók kezelése a helyi számítógépen ................................. - 32 17. ábra: Jelszóházirend beállítása .................................................................... - 33 18. ábra: Kapcsolat nélküli fájlok engedélyezése .............................................. - 33 19. ábra: CD írás engedélyezése ......................................................................... - 34 20. ábra: USB lemezegység és USB Flash meghajtó......................................... - 35 21. ábra: Házirendek kezelése............................................................................ - 35 22. ábra: Mappa biztonsági beállításai .............................................................. - 36 23. ábra: Az MBSA honlapja .............................................................................. - 37 24. ábra: Célpontválasztás.................................................................................. - 38 25. ábra: MBSA eredmények .............................................................................. - 38 26. ábra: Sérülékenység részletezése ................................................................. - 39 27. ábra: Sober.Y vírus (forrás: F-Secure).......................................................... - 69 28. ábra: Alapvető WiFi beállítások ................................................................... - 77 29. ábra: Biztonsági beállítások ......................................................................... - 77 30. ábra: MAC szűrés engedélyezése.................................................................. - 78 31. ábra: MAC szűrési lista szerkesztése........................................................... - 78 32. ábra: Menedzsment hozzáférés beállításai .................................................. - 79 33. ábra: WiFi hálózat keresése és beállítása .................................................... - 80 34. ábra: Telepítő varázsló új hálózathoz........................................................... - 80 35. ábra: Alapvető WiFi kliens beállítások ........................................................ - 81 36. ábra: WPA kulcs bevitele a kliensbe ............................................................ - 81 37. ábra: Beállítások átvitele.............................................................................. - 82 38. ábra: Sikeres kapcsolat ellenőrzése.............................................................. - 82 39. ábra: Lenyomat képzése az elektronikus dokumentumból ......................... - 96 40. ábra: A lenyomat kódolása a titkos kulccsal................................................ - 96 41. ábra: Titkos kulcs az aláírás-létrehozó eszközön......................................... - 97 42. ábra: Alap elektronikusan aláírt dokumentum ........................................... - 97 43. ábra: Időbélyegzővel ellátott elektronikusan aláírt dokumentum.............. - 98 44. ábra: Az aláírás ellenőrzésének folyamata .................................................. - 99 45. ábra: Visszavonási lista ellenőrzése ........................................................... - 100 46. ábra: A hitelesítés-szolgáltató .................................................................... - 101 -

- 138 -


Hivatkozások

47. ábra: Biztonságos aláírás-létrehozó eszköz................................................ - 101 48. ábra: Aláírás ellenőrzésének folyamata ..................................................... - 106 -

- 139 -

Útmutató az informatikai biztonság megvalósítására önkormányzatok számára

Recommend Documents