KÖZIGAZGATÁSI INFORMATIKAI BIZOTTSÁG. 25. számú Ajánlása. Magyar Informatikai Biztonsági Ajánlások (MIBA)

KÖZIGAZGATÁSI INFORMATIKAI BIZOTTSÁG

25. számú Ajánlása Magyar Informatikai Biztonsági Ajánlások (MIBA) 25/3. Informatikai Biztonsági Iránymutató Kis Szervezeteknek (IBIX)

1.0 verzió

2008. június

Informatikai Biztonsági Iránymutató Kis Szervezeteknek - IBIX

Közigazgatási Informatikai Bizottság 25. számú Ajánlása Készült a Miniszterelnöki Hivatal megbízásából Összeállította: Szigeti Szabolcs CISA, CISM, CISSP Közremőködött: Krasznay Csaba CISA, CISM, CISSP, Muha Lajos PhD, CISM, Rigó Ernı, Szigeti Szabolcs CISA, CISM, CISSP.

. Az ajánlás a Közigazgatási Informatikai Bizottság (KIB) Jogi és Mőszaki Szabályozási Albizottsága észrevételei alapján véglegesített tartalommal a KIB tagjainak 2008. május-júniusi elektronikus távszavazása alapján került elfogadásra

2

Magyar Informatikai Biztonsági Ajánlás


TARTALOMJEGYZÉK BEVEZETÉS ............................................................................................................................6 A DOKUMENTUM CÉLJA...............................................................................................7 A DOKUMENTUM CÉLKÖZÖNSÉGE ...........................................................................9 A DOKUMENTUM SZERKEZETE ..................................................................................9 INFORMÁCIÓBIZTONSÁG – INFORMATIKAI BIZTONSÁG ...................................11 VÉDELMI INTÉZKEDÉSEK ..........................................................................................11 INFORMATIKAI BIZTONSÁG ......................................................................................14 A SZABÁLYOZÁSI KÖRNYEZET ÁLTAL TÁMASZTOTT IGÉNYEK ....................17 JOGSZABÁLYOK............................................................................................................17 AZ ÖNKORMÁNYZATI KÖRNYEZET SPECIALITÁSAI..........................................18 KÖVETELMÉNYEK A KÖZIGAZGATÁS SZÁMÁRA ...............................................20 BIZTONSÁG MEGVALÓSÍTÁSA......................................................................................24 ALAPVETİ ELVEK........................................................................................................25 HELYZETFELMÉRÉS.....................................................................................................27 KOCKÁZATELEMZÉS ...................................................................................................28 VÉDELMI INTÉZKEDÉSEK ..........................................................................................31 SZABÁLYZATOK ...........................................................................................................33 AZ EMBERI TÉNYEZİ ..................................................................................................35 Jelszavak.....................................................................................................................35 Adathalászat ...............................................................................................................36 RENDSZEREK BEÁLLÍTÁSAI ......................................................................................39 Windows.....................................................................................................................39 BIZTONSÁGI BEÁLLÍTÁSOK...........................................................................................40 Linux ..........................................................................................................................64 A LINUX EGY WINDOWS-FELHASZNÁLÓ SZEMÉVEL ...........................................65 1. Alapfogalmak...........................................................................................65 2.

3.

Különbségek.............................................................................................68 1.

VFS ......................................................................................................69

2.

Jogosultságkezelés ...............................................................................72

3.

Csomagkezelés.....................................................................................75

4.

Parancssor-orientáltság ........................................................................75 Hasonlóságok ...........................................................................................75

A LINUX RENDSZER FİBB KOMPONENSEI ...............................................................76 ÁLTALÁNOS FELHASZNÁLÁSI TANÁCSOK A LINUX RENDSZERHEZ..............77 A LINUX RENDSZEREK ALAPVETİ BEÁLLÍTÁSAI .................................................79 Hálózatkezelés.................................................................................................79 Hálózati alapbeállítások – az ifconfig parancs............................................80 Magyar Informatikai Biztonsági Ajánlás

3


Vezeték nélküli hálózat – az iwconfig parancs ...........................................81 Útválasztás – a route parancs ......................................................................81 Automatikus IP-hozzárendelés – a dhclient parancs...................................83 Modemes kapcsolat – a PPP alrendszer ......................................................83 ADSL kapcsolatok – a PPPoE ....................................................................84 Névfeloldás – a DNS resolver.....................................................................85 A LINUX HÁLÓZATI TŐZFALA.......................................................................................85 Alapvetı mőködés.......................................................................................86 tcpwrapper...................................................................................................89 CSOMAGKEZELÉS .............................................................................................................90 Telepítés forráskódból – gyorstalpaló.........................................................90 Csomagkezelési alapok ...............................................................................91 Hálózati csomagkezelés, automatikus frissítések .......................................93 HÁLÓZATI KISZOLGÁLÓK BEÁLLÍTÁSAI .................................................................94 Webszolgáltatások.......................................................................................94 Proxy-szolgáltatások ...................................................................................95 Levelezési szolgáltatások ............................................................................96 Távoli adminisztráció..................................................................................98 Fájlszolgáltatások........................................................................................99 Internetes alapszolgáltatások.......................................................................99 GUI-szolgáltatások......................................................................................99 HONNAN TUDHATOM, HOGY FELTÖRTÉK? ...........................................................100 Futó processzek.............................................................................................100 Megváltozott fájlok .......................................................................................101 Gyanús konfigurációs és naplóbejegyzések..................................................101 Szokatlan hálózati mőködés..........................................................................102 Tőzfalak....................................................................................................................102 A TŐZFALAK TÍPUSAI.....................................................................................................103 JELLEGZETES TŐZFAL ARCHITEKTÚRÁK .............................................................103 CÍMFORDÍTÁS ...................................................................................................................104 VPN ........................................................................................................................................106 TIPIKUS TŐZFAL BEÁLLÍTÁSOK ................................................................................106 Kártékony kódok ......................................................................................................107 Levelezés ..................................................................................................................109 TITKOSÍTÁS - REJTJELEZÉS......................................................................................110 4



VEZETÉKNÉLKÜLI HÁLÓZATOK ............................................................................113 Fogalmak ..................................................................................................................114 Veszélyek .................................................................................................................114 Biztonsági megoldások.............................................................................................115 Lényeges tennivalók.................................................................................................116 Példa WiFi beállításokra ..........................................................................................119 ACCESS POINT BEÁLLÍTÁSA........................................................................................119 KLIENSEK BEÁLLÍTÁSA ................................................................................................123 Bluetooth biztonság..................................................................................................127 HORDOZHATÓ ESZKÖZÖK .......................................................................................127 ÜZEMELTETÉS..................................................................................................................129 MENTÉS .........................................................................................................................129 FRISSÍTÉSEK.................................................................................................................130 SELEJTEZÉS ..................................................................................................................130 VÉSZHELYZETEK........................................................................................................131 További károk megelızése.......................................................................................131 Hasonló esetek megelızése ......................................................................................131 Normál üzem visszaállítása ......................................................................................132 Nyomozás.................................................................................................................132 AZ ELEKTRONIKUS ALÁÍRÁS ......................................................................................133 SZÓTÁR................................................................................................................................151 JOGSZABÁLYOK...............................................................................................................155 A TERÜLETHEZ KAPCSOLÓDÓ EGYÉB JOGSZABÁLYOK.................................155 A KIETB AJÁNLÁSAI ..................................................................................................157 HIVATKOZÁSOK...............................................................................................................158 ÁLTALÁNOS IT BIZTONSÁG.....................................................................................158 JOGSZABÁLYI HÁTTÉR .............................................................................................158 WINDOWS .....................................................................................................................159 LINUX.............................................................................................................................159 VEZETÉKNÉLKÜLI BIZTONSÁG ..............................................................................159 ELEKTRONIKUS ALÁÍRÁS ........................................................................................159


5


BEVEZETÉS Az informatikai rendszerek egyre átfogóbb alkalmazása érinti a társadalom minden rétegét (az államigazgatást, a kritikus infrastruktúrákat, a gazdasági és a civil szférát) és ezek kapcsolatát. Ebbıl következıen egyre nagyobb értéket képvisel az információ-technológiai eszközökben feldolgozott adat, melynek megsérülése vagy szándékos veszélyeztetése (beleértve az információval történı visszaéléseket és az adatok meghamisítását is) mérhetetlen károkat okoz(hat). Az informatikai rendszereket üzemeltetı vezetık és üzemeltetık felelıssége kiterjed az informatikai adatvagyon, az adatokhoz kapcsolódó személyiségi jogok védelmére is, melyet a társadalmi, szervezeti érdekeken túlmutatóan jogszabályi elıírások is elvárnak. Mindezek miatt kiemelt igény mutatkozik az informatikai biztonság garantálására. Az informatikai biztonság – mely tartalmazza az információk és az informatikai eszközök és szolgáltatások védelmét is - sokrétő fogalom, fejlesztése, folyamatos fenntartása minden résztvevı felelıssége, egyúttal szerteágazó szaktudást igényel. A szervezetek hatékony vezetése és rendeltetés szerinti mőködtetése csak a szükséges információ birtokában valósítható meg. Jelentıs anyagi és erkölcsi károkat okozhat, ha az információ nem hozzáférhetı, megsérül, vagy illetéktelen kezekbe jut, ezért kiemelten fontos feladat egy informatikai biztonsági irányítási rendszer mőködtetése. Információs rendszereink és hálózataink egyre gyakrabban érintettek különbözı forrásból származó biztonsági fenyegetésekkel, többek között a számítógépes csalással és a bizalmas információk illetéktelen megszerzési törekvéssel szemben. A szándékos károkozások technikai lehetıségeinek széles skálája áll a rosszindulatú támadók rendelkezésére. Ismeretes, hogy a védelmi rendszerek fejlıdésével – annak ellenére, hogy a támadó rendszerek kifejlesztése egyre több szaktudást igényel – jelentıs károkat okozó támadások végrehajtása minimális felkészültséggel is eredményt hozhat, mivel a támadó rendszerek (hacker- és kémprogramok, vírusok, …) jelentıs eszközparkja az interneten szabadon hozzáférhetı. Ezért a szervezeti szinten megtett védelmi intézkedések hatékonysága érdekében szükség van az informatikai termékekre és rendszerekre elıírt technológiai biztonsági követelményekre, valamint az ezek teljesítését igazoló garanciákra is.

6



A fentieknek megfelelıen az informatikai biztonság közvetlenül és alapvetıen függ: •

mind az informatikai rendszert üzemeltetı szervezet folyamataitól, biztonságot menedzselı szervezeti struktúrájától, hozzáértı humán erıforrásaitól, szabályozási rendszerszerétıl, a szabályok betartásának ellenırzésétıl;

•

mind a szoftver és hardver termékek, valamint az ezekbıl integrált komplex informatikai rendszerek és alkalmazások biztonsági megfelelıségétıl;

•

valamint e két terület egymásra ható kapcsolatától.

A Miniszterelnöki Hivatal Elektronikuskormányzat-központ megrendelésére elkészült a Magyar Informatikai Biztonsági Ajánlások (MIBA) címő ajánlássorozat. A MIBA fı célja, hogy biztonságos informatikai rendszerek kialakítását és fenntartását segítse elı. A nemzetközi szabványokhoz és ajánlásokhoz igazodva a MIBA három fı részbıl áll: •

A

Magyar

Informatikai

Biztonsági

Keretrendszer

(MIBIK)

szervezeti

szempontból kezeli az informatikai biztonság kérdését. Ezért a MIBIK a biztonságos informatikai rendszerek irányításáért, menedzseléséért felelıs vezetıknek, illetve a szervezet egészére vonatkozó követelmények teljesülését értékelı szakembereknek szól. •

A Magyar Informatikai Biztonság Értékelési és Tanúsítási Séma (MIBÉTS) technológiai szempontból kezeli az informatikai biztonság kérdését. Ezért a MIBÉTS célközönsége az informatikai rendszer kialakításáért, fejlesztéséért felelıs vezetık, valamint az informatikai termékek és rendszerek biztonsági értékelését és tanúsítását végzı szakemberek köre.

•

Az Informatikai Biztonsági Iránymutató Kis Szervezetek Számára (IBIX) olyan szervezeteknek nyújt segítséget biztonságos informatikai rendszereik kialakításához, amelyek nem rendelkeznek jelentısebb informatikai rendszerrel, illetve ehhez elkülönült informatikai személyzettel.

Ez a dokumentum az IBIX ajánlást tartalmazza.

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 kis szervezeteknél, figyelembe véve az ezeknél a szervezeteknél kitőzött célokat és a rendelkezésre álló lehetıségeket.


7


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 elıfordul, hogy felesleges, meg nem térülı 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 az alapelveket szem elıtt tartva és néhány egyszerő, gyakorlati lépést megtéve rendszereink biztonsága nagyságrendeket javítható. A jelenlegi – fıleg kormányzati és közigazgatási területre érvényes – szabályozási környezet jól definiálja az informatikai biztonságban elérendı célokat, de az informatika rohamléptékő fejlıdésébıl adódó részleteket nem tudják és nem is feladatuk követni a jogszabályoknak. Így pusztán az elıírások 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 egyben megjelentetésére 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

8



érdeklıdık megismervén ezeket a lépéseket, képesek legyenek önállóan is elmélyedni bennük, tudjanak a terület szakértıivel „szót érteni”. 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. 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.

A DOKUMENTUM CÉLKÖZÖNSÉGE Az ajánlás – jellegénél fogva – elsısorban a kis kormányzati, közigazgatási, önkormányzati szervezetek számára készült, ez azonban nem jelent kizárólagosságot. Természetesen bizonyos elıírások csak rájuk érvényesek, azonban bármely kismérető szervezet, kisvállalkozás, közintézmények, stb. haszonnal forgathatják. A dokumentum célközönsége kettıs. Egyrészt szól azoknak, akik ilyen szervezeteknél dolgoznak és 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 az elsı részben leírt, a biztonság megteremtésével kapcsolatos ajánlásokat/feladatokat. 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 túl/felül a második rész tartalmaz konkrét információkat a rendszerek beállításáról.” Különösen javasolt az anyag azon szervezetek számára, ahol a szervezet méreténél fogva nem áll rendelkezésre külön, a szakterületen jártas emberi erıforrás az informatikai rendszerek biztonságának kialakítására és üzemeltetésére, hanem ezt házon belül, alapvetıen más területen jártas informatikai munkatársak igénybevételével vagy esetleg külsı szolgáltatásként (outsourcing) kell megoldani.

A DOKUMENTUM SZERKEZETE A dokumentum két fı részre tagolódik. •

Az elsı rész az informatikai biztonság alapvetı fogalmaival és a kialakítás lépésivel foglakozik. Összefoglalja a szabályozási környezetet vonatkozó részeit. 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 útmutatót kíván


9


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úlmutat a kereteken és feltétlenül szakértıi közremőködést igényel. Gyakorlati példákon keresztül ismerteti az elektronikus aláírás technológiáját és folyamatát.

10



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 különösen az e-kormá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ı.

VÉDELMI INTÉZKEDÉSEK 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 szervezet célja ezeknek a védelmi intézkedéseknek a meghozatala a biztonság kialakításának folyamata eredményeként. 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.


11


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 tevékenységet, vagy eszközt. Az informatikai biztonsági védelmi intézkedéseket több kategóriába sorolhatjuk: •

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 szervezetnek idınként fel kell mérnie a szervezet 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 auditá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

12



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


13


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 kikerülı és az oda bekerülı adatokat.. 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. 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.)

A kategóriákba sorolás segít a biztonsági intézkedések szisztematikus számbavételében.

INFORMATIKAI BIZTONSÁG Mindezek után tekintsük át, hogy mit takar az informatikai biztonság! Az már elıbb röviden említett 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

14



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

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, támadás vagy mőszaki hiba esetén se módosuljanak vagy 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 nevezni1. Az informatikai biztonság kialakítása során a cél ennek a három feltételnek a megvalósítása és meglétüknek folyamatos fenntartása. Fontos megjegyezni, 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 elektronizált közhivatal esetében. A kormányzati, közigazgatási 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. A szabályozási 1

Bár biztonság területe miatt kétségtelen az áthallás az USA hírszerzı hivatalának elnevezésével, a CIA elv elnevezés elterjedt mind a külföldi, mind a hazai szakirodalomban.


15


környezetet a következı fejezet mutatja be. Más szervezetek, mint például kisvállalkozások számára ilyen jellegő elıírások nincsenek, azonban egyrészrıl bizonyos elemek átvehetıek, másrészrıl a biztonság kialakításának folyamata során – különösen a helyzetfelmérés és a kockázatelemzés során – ezek kialakíthatóak.

16



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.

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.


17


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ı 18



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 • • • •

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.


19


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

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

20



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 periodikusan 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 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 (gyakorlatilag 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 üzletmenet-


21


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 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. A 84/2007. (IV. 25.) Korm. rendelet a Központi Elektronikus Szolgáltató Rendszer és a kapcsolódó rendszerek biztonsági követelményeirıl további elıírásokat tartalmaz, kifejezetten a Központi Rendszerhez csatlakozó informatikai rendszerekkel kapcsolatban. Bár a rendelet a Központi rendszerrel kapcsolatos, tartalmilag általánosan is hasznosítható elıírásokat tartalmaz. Az 1. számú melléklet a vonatkozó szabályzatok tartalmi követelményeit vázolja. Ennek alapján a szabályozásnak a következıkre kell kitérnie:

22

•

Az informatikai biztonsággal kapcsolatos szerepkörök kiosztása

•

Külsı szolgáltatók igénybevétele

•

Informatikai vagyontárgyak kezelése: vagyonleltár, osztályozás, kezelés. Magyar Informatikai Biztonsági Ajánlás


•

Személyi

biztonság:

munkatársak

ellenırzése,

szerepkörök

és

felelıségek

meghatározás, változások kezelése. •

Fizikai biztonság: zónák kialakítása, belépés-ellenırzés, berendezések védelme, karbantartás, selejtezés.

•

Üzemeltetés és irányítás: változáskezelés, feladatkörök elhatárolása, fejlesztés, tesztelés, továbbfejlesztés, átvétel. Szolgáltatások nyújtása és igénybevétele. Védekezés rosszindulatú kódok ellen. Biztonsági mentés. Hálózat, szolgáltatások és adathordozók védelme és kezelése. Naplózás, auditálás.

•

Hozzáférés ellenırzés: felhasználók, jogosultságok kezelése. Hitelesítés, jelszavak kezelése. Távoli hozzáférés.

•

Adatok feldolgozása: ellenırzés, hitelesség, sértetlenség. Titkosítás. Szoftverek átvétele.

•

Informatikai biztonsági események kezelése: reagálási tervek. Katasztrófa-elhárítási terv.

•

Követelményeknek való megfelelés: szabályzatok, auditálás.

A 2. számú mellékelt az Informatikai Katasztrófa-elhárítási Terv kidolgozásához ad mintát. A két melléklet elıírásai abban az esetben is használható sorvezetıként, ha egyébként az adott szervezetre nem vonatkozik a rendelet. A harmadik melléklet vonatkozik a Központi rendszerhez való kapcsolódás feltételeire.


23


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, és ezek ciklikus ismétlése biztosítja a folyamatos mőködést. 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, szervezet határait, környezetét, az érintett információs és egyéb erıforrásokat, figyelembe véve a rendszer elemeit, 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 sérülékenysé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 elemezzük a kihasználhatóság valószínősége és a bekövetkezés esetén fellépı hatás súlyossága alapján. •

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

•

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 például alacsony, fokozott és kiemelt osztályokba sorolhatjuk.

•

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.

4. 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. 5. 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. Szükség esetén pontosítjuk a kockázatelemzést. 24



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

ALAPVETİ ELVEK Fontos tisztában lenni a biztonság kialakítása során néhány alapvetı elvvel. A lényeges pontok, amelyeket szem elıtt kell tartani: •

Ismerjük meg magunkat és a ránk leselkedı veszélyeket! 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 jó és rossz 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ıbbiekben 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


25


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

26



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

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. 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). Az információs vagyon felmérése nem egyszerő feladat. Különbözı feladatkörök különbözı információkat kezelnek és ezek értékét máshogy állapítják meg. Általában a célravezetı megoldás egy olyan kérdıív készítése, amelyet minden érintett kitölt. A kérdıív rákérdez az adott információra (megnevezés, adatgazda, célja, származási helye, tárolási helye, feldolgozási helye, mely folyamatban vesz részt) illetve az adott személy (munkakör, folyamat) számára képviselt értékére (az értéket lehet osztályozni. Egy jellegzetes, elsısorban közigazgatási környezetben használható osztályozás lehet a következı: •

Különlegesen érzékeny adatok, amelyekhez a belsı és külsı hozzáférést erısen korlátozni és szigorúan ellenırizni, dokumentálni kell.

•

Érzékeny adatok, amelyekhez a belsı és külsı hozzáférést korlátozni, a hozzáférést naplózni kell.

•

Belsı adatok, amelyekhez a külsı hozzáférés nem lehetséges, belsı hozzáférés korlátozása nem kritikus.

•

Nyilvános, közhiteles adatok, ahol a rendelkezésre állás és a megváltoztathatatlanság biztosítása kritikus.

•

Nem osztályozott adatok.


27


A beérkezett kérdıíveket összesítjük, és ez alapján felmérhetjük az adatainkra leselkedı veszélyeket. A veszélyek számbavételénél segít, ha kategóriákat alakítunk ki, és ezek alapján készítjük el a listát: •

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 helyzetfelmérés során elkészül egy lista, amely tartalmazza a szervezet által kezelt információkat, ezek fontosságát és az ıket fenyegetı veszélyeket. A következı lépés a kockázatok meghatározása.

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. A veszélyeztette információk vagy azok csoportjaira külön-külön meg kell állapítani a kockázatot, a teljes kép kialakítása céljából. 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:

28



•

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 a közigazgatási szervezet mőveleteire, vagy a szervezet eszközeire.

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 képes végrehajtani egy


29


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. Természetesen lehetséges, sıt célszerő a kategóriákat saját igényeinknek megfelelıen módosítani, ha más elıírás nincsen, 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

alacsony

fokozott

jelentıs

mérsékelt alacsony

kiemelt

kritikus

jelentıs

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



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 a kiszolgálóban

Jelentıs

Ritka

Mérsékelt

Vírus-támadás

Informatikai

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

Közepes

Állandó

Jelentıs

Közepes

Gyakori

Mérsékelt

rendszerbe Adathordozó

Humán

elvesztése …

Dolgozó

érzékeny

adatokat

tartalmazó adathordozót veszít el …

…

…

…

…

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: •

Megakadályozó (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.


31


•

Helyreállí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 (Preventive – megakadályozó, Detective – észlelı, Corrective – helyreállító) nevezni. 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ó 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 Pre

Hardver meghibásodása

Mérsékelt

…

Redundáns

Redundáns

Redundáns

rendszer,

rendszer,

megelızı karbantartás

megelızı -

megelızı Integritás

Rendszerfelügyelet

ellenırzı

mőködtetése

kriptográfiai Biztonsági mentés

Tartalék

rendszer,

rendszer,

biztonsági mentés Vírusszőrés,

Vírusszőrés,

Vírusszőrés,

tőzfal,

tőzfal,

felhasználók oktatása

felhasználók Víruskeresı

felhasználók Integritás

Rendszerfelügyelet,

ellenırzı

víruskeresı

kriptográfiai Biztonsági mentés

Tartalék

De Nem

Co …

A

-

Pre

Jelentıs

I

De

Co

Vírustámadás

C

védjük

/

biztosítás …

…

tőzfal,

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észetes, 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. 32



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.

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.


33


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. Célszerő, ha a szabályzatok egységes formátumot mutatnak, és legalább a következı azonosító adatokat tartalmazzák: •

Állapot: munkaanyag, ellenırzés alatt, végleges

•

Verzió

•

Készítık és jóváhagyó személy

•

Hatálybalépés és következı felülvizsgálat dátuma

•

Kapcsolódó dokumentumok

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.

34



AZ EMBERI TÉNYEZİ Az

információ

egyre

inkább

elektronikus

formában

jelenik

meg.

Ebbıl

arra

következtethetnénk, hogy 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 az 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. A rendszerek biztonsága tekintetében általában az emberi tényezı jelenti a leggyengébb láncszemet. 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, mivel nagyon szerteágazó a megnyilvánulási formája.

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ó


35


vagy feltörhetı. A jó jelszó kellıen bonyolult, nehezen kitalálható, ugyanakkor megjegyezhetı. 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 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.

ADATHALÁSZAT Az ún. phising, magyarul adathalászati támadás is az emberi tényezıt használja ki. 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. Rendszerint valamilyen ürüggyel, mint pl. a rendszer meghibásodása vagy fejlesztése ráveszik, hogy lépjen be jelszavával. Tipikusan az ilyen támadások az internetes banki szolgáltatásokat támadták. Ami a hitelesség látszatához kell, az e-mail cím, mely nagyon egyszerő eszközökkel hamisítható, pl. az adott bank ügyfélszolgálatának címére. Kell a levélbe 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 egy hamis weboldal jelenik meg. A megjelenı weboldal újfent hitelesnek tőnhet, hiszen nagyon hasonlít például az adott bank hivatalos oldalára (a támadó ezt egyszerően lemásolja). Az oldalon megjelenı szöveg megerısíti az e-mail 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 bank 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. 36



De észre kell venni a trükköket, amit a támadó használt. A böngészıben a hivatkozás nem a bank igazi oldalára, hanem egy arra nagyon hasonlító címre mutatott (például: www.bank.hu helyett a www.bank.hn-re, kihasználva a magyar hu és a hondurasi hn nevek közti hasonlóságot). 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. A felhasználó beírja jelszavát és az OK gombra kattint. Ekkor megjelenik az eredeti banki oldal, a támadó már birtokában van a felhasználó jelszavának. Ezzel a jelszóval az 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 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 (1.ábra)


37


1. á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 gyakran 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. 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

38



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!

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 környezettıl függetlenül (de annak messzemenı figyelembevételével!) képes a rendszer biztonságának növelésére. A legtöbb példa, ha nem is változatlanul, de alkalmazható más operációs rendszerek (pl.: más Unix variánsok, MacOS) esetében is.

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, Windows Vista, 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 Vista, 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 Vista jelenleg még nem elterjedt, így a példák során a Windows XP-t használjuk. A Windows komplex operációs rendszer, ráadásul nagyon különbözı környezetben használatos: •

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 megvé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 nem elfogadható.


39


•

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ásmenedzsment.

Mindazonáltal

az

egyes

gépek

ugyanazon

munkacsoportba

kapcsolhatóak, és bizonyos erıforrás-megosztá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 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.

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.

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: 40



•

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 megvalósításá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

rendszerkomponensek

során

külön

törekedjünk

a

felhasználói

partíción/lemezegységen

való

adatok

és

elhelyezésére.

a 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 és Vista 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 rendszeresen 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 é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 csomag érhetı el: Magyar Informatikai Biztonsági Ajánlás

41


•

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 a jelenleg legfrissebb, az SP2 telepítése, mivel az jelentıs biztonsági újításokat tartalmaz. A Service Packok kumulatí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.

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

Az automatikus frissítések a „Sajátgép” tulajdonságai, vagy a „vezérlıpult” megfelelı pontjából kapcsolható be. A Windows XP Service Pack 2 elsı indításkor felajánlja az

42



automatikus frissítések bekapcsolását, és ha ez nem történik meg, akkor rendszeres figyelmeztetéseket küld errıl a rendszer. A frissítések az Internet Explorer eszközök/Windows Update menüpontjából (3. ábra) 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.

3. á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


43


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.

•

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 licenszet 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 észlelé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 SP2tıl az operációs rendszer is rendelkezik beépített személyes tőzfallal, de nagyobb teljesítményő tőzfalak is kaphatóak, más gyártótól.

44



4. á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 (5. ábra). 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.

5. ábra: Windows tőzfal engedélyezése


45


„Speciális” fület 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ı.

6. á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 46



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.

7. ábra: Fájlrendszer típusának ellenırzése

A fájlrendszer típusát a meghajtó tulajdonságai között nézhetjük meg, az „Általános” fülön (7. ábra). Ha a fájlrendszer nem NTFS, akkor a convert parancssori programmal késıbb is NTFSsé 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.


47


8. á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, USB-drive) 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.

48



9. á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). A Windows rendelkezik saját titkosítással, de több ilyen feladatra alkalmas program kapható. Jól használható a Truecrypt (www.truecrypt.org) ingyenes program.


49


10. á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 (10. ábra), 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. 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.).

50



11. á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.)

•

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! Magyar Informatikai Biztonsági Ajánlás

51


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örnyezetben 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.

12. ábra: Megosztások megtekintése

A példában (12. ábra) 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.

52



Ü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: •

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 felhaszná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.


53


13. ábra: A 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.

•

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 ujjlenyomat-olvasó.

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



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.

14. á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 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.


55


15. á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 kis-kö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.

56



16. á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 500-1000 gigabájtos merevlemezek kaphatóak a kereskedelmi forgalomban, elérhetı áron. •

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

•

Hasonló módon mentési szerver is kialakítható, ilyenkor nem hordozható, lemezegységre, hanem központi helyen elhelyezett, nagykapacitású lemezegységgel ellátott számítógépre mentünk. Ekkor azonban ügyeljünk a rendszer fizikai biztonságára, mert például egy csıtörés, vagy tőz nem csak a mentendı, de a mentett eszközöket is megsemmisítheti.


57


•

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.

17. á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.

58



18. ábra: Házirendek kezelése

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 19. ábra). Természetesen ez csak NTFS fájlrendszer esetében mőködik.


59


19. á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ép-kezelé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ı, 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 60



használatához keressük fel a fenti oldalt, töltsük le és telepítsük a szoftvert. Windows Vista vizsgálatához a 2.1beta verzióra van szükség!

20. á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 MBSA-t ú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.


61


21. á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.

62



22. ábra: MBSA eredmények

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.


63


23. á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.

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 egyeduralkodók 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 tarjuk azonban azt, hogy Linux rendszerek jelenleg inkább kiszolgálói feladatkörökben szerepelnek, mint asztali

64



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.

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. 1. 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,


65


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óriamanagement, é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 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 LKM-tá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ó, 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 11es 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

66



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

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

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 Magyar Informatikai Biztonsági Ajánlás

67


különálló X-kiszolgá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 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. 2. 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.

68



1. VFS

A DOS rendszerben megszokott fájlrendszer logikáját követı Windows-felhaszná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.

•

/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,


69


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 Windows-felhasználók számára hasznos lehet az /etc könyvtárra egyfajta registry-ké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, Windowsterminoló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

70



nem támogatott, másként („kézzel”) telepített programokat ide célszerő 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 „blokk-speciá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.


71


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 és named socket) is, ezek felhasználási lehetıségei azonban nem képezik jelen dokumentum tárgyát. 2. 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,

72



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/GIDpá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.

•

G (Group): a fájlhoz rendelt GID-del azonos csoportazonosítójú processzre vonatkozó 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ó.


73


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égiumszint-növelési lehetıségrıl van szó. Emiatt a suid binárisok kezelése különleges 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ág-beá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.

74



3. 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. 4. 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. 3. 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 Windows 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, 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


75


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 IP-cí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ılemezre bizalomkeltı név került.

A Linux rendszer fıbb komponensei A rendszer fontos összetevıit a rendszerindítási folyamat áttekintı végigkövetésével mutatjuk be. 1. A számítógép BIOS-a a rendszer indításakor betölti a rendszer elsıdleges booteszkö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

billentyő

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 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 76



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

Á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!


77


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ó 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

78



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!

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 Magyar Informatikai Biztonsági Ajánlás

79


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

80


Informatikai Biztonsági Iránymutató Kis Szervezeteknek - IBIX 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 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


81


disztribúciónként teljesen eltérı lehet, emiatt továbbra is az univerzális parancssori beállításokkal foglalkozunk. 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ó 82



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


83


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:

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 disztribú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

84



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 elnevezé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 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

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. Magyar Informatikai Biztonsági Ajánlás

85


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

86



•

DROP: a csomag feldolgozása megszakad, az operációs rendszer 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ó.

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 internetkapcsolatá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őzfal-beá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ő


87


kimenetére adunk most egy magyarázatokkal ellátott példát, csak az alapvetı lehetıségek érzékeltetése végett: # 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 a 22-es, a 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ó.

88



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

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 IP-cí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 ftpszolgá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


89


A fentiekrıl bıvebb információt a man tcpd parancs által megjelenített dokumentációs oldalról kiindulva találhatunk.

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:

[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:

90


Informatikai Biztonsági Iránymutató Kis Szervezeteknek - IBIX [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 parancs általában elfogad egy --help paramétert, mely további konfigurációs opciók megadhatóságát fedheti fel. A parancs sikeres futásának eredménye egy Makefile nevő állomány az aktuális könyvtárban, mely alapján már a make parancs kiadásával elvégezhetı az alkalmazás fordítása: [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ód-ké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. 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ód-alapú 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


91


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:

92


Informatikai Biztonsági Iránymutató Kis Szervezeteknek - IBIX 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 csomaglista-frissí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.


93


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. 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 beé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ı

94



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 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 Internet-elé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és-vé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.


95


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 IPcí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 SMTP-kiszolgá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) 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

96



legitim levélforrások IP-cím szerinti meghatározása, fontos lehetıség a levé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. 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


97


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

98



csatlakozni kívánó felhasználót. Fontos, hogy az alábbihoz 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 egyátalán nem javasolt rendszergazdai (root) privilégiumokkal, a legtöbb esetben Magyar Informatikai Biztonsági Ajánlás

99


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 kiszolgáló megfelelı beállításai esetén a távoli internetes állomások is beleértendık.

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 ambició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 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: 100


Informatikai Biztonsági Iránymutató Kis Szervezeteknek - IBIX 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 CPUterhelé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 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ípus-meghatá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


101


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. 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 IP-cí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.

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.

102



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.

•

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.

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


103


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 internetDMZ, 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ég egy 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.

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

104



alapján a belsı hálózatunk szinte korlátlan mérető lehet, hiszen ezekben a tartományokban elegendı címtér á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. Magyar Informatikai Biztonsági Ajánlás

105


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 feladata, de nagy teljesítményigény esetén dedikált VPN eszközt lehet alkalmazni.

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

106



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.

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. 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 e-mailben 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. Magyar Informatikai Biztonsági Ajánlás

107


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.

24. á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.

108



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.

•

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


109


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.

TITKOSÍTÁS - REJTJELEZÉ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 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.

110



•

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


111


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

112



Korábban 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, pendrive-on vagy memóriakártyán. Ilyen esetben a szimmetrikus kulcsot használó Advanced Encryption Standard (AES) titkosító eljárás használata javasolt, 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.

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 Magyar Informatikai Biztonsági Ajánlás

113


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.

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: •

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 SSIDjő hálózathoz csatlakoznak.

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ı:

114



•

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.

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ő bizalmassá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 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 WPA2t. A WPA és a WPA2 gyakorlatilag megegyezik, a WPA2 képes a még erısebb AES titkosításra. 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


115


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 – kiterjeszthetı 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.

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 felkeltheti a támadó kíváncsiságát. A hálózat SSID-ját

116



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 SSID-jé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 (WPA2) 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


117


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 felállított „hamis” hálózathoz csatlakozzanak, majd megfigyelheti forgalmukat.

•

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,

Tájékozódjunk,

hogy

ha a

illetéktelen kliens

kézbe

program

kerül

hogyan

a

kliens

tárolja

az

számítógép. é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.

118



•

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.

PÉLDA WIFI 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 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éldában szereplı AP egy Linksys WRT54G WiFi router, a kliensek Microsoft Windows XP Service Pack 2 operációs rendszerrel rendelkeznek.

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 különösen népszerő otthoni és kis 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. Magyar Informatikai Biztonsági Ajánlás

119


Elsı lépésben az alapvetı WiFi jellemzıket kell beállítani. A 25. ábrán látszik, hogy a hálózatunk SSID-je „vezeteknelkuli” lesz. Az SSID hirdetését (SSID broadcast) kikapcsoljuk.

25. á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 hosszú és bonyolult jelszót adjunk meg, hogy a szótár alapú támadásokat megelızzük!

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

120



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

27. ábra: MAC szőrés engedélyezése


121


28. á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 29. ábra: Menedzsment hozzáférés beállításai

122



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

•

Kapcsoljuk be a WPA-t! Windows XP-n WPA2 használatához telepíteni kell a WPA2 kiegészítést, errıl további információ a következı oldalon található: http://support.microsoft.com/kb/893357

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

30. á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!


123


31. ábra: Telepítı varázsló új hálózathoz

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 kulcs-beállítást, és a WPA titkosítást.

32. á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 karakterek) 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.

124



33. á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.


125


34. á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 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.

35. ábra: Sikeres kapcsolat ellenırzése

126



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,

PDA-k

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

•

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

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)


127


•

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 laptopon 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, PDA-k 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!

128



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

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


129


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.

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.

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.

130



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.

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

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!


131


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

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.

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, felhasználók, stb. listája.

132



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: • • • • • • • •

2

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ól2 szerezhetık be.

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


133


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; •

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.

0 0110 1010 0100 0111 0100 0111 110

36. á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

134



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.

0

1

0110

1011

1010

0111

0100

1000

0111

0110

0100

1011

0111

1011

110

101

37. á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.


135


0

1

0110

1011

1010

0111

0100

1000

0111

0110

0100

1011

0111

1011

110

101

38. á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, 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.

136



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.

0

1

0110

1011

1010

0111

0100

1000

0111

0110

0100

1011

0111

1011

110

101

39. á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.


137


0110

1011

1010

0111

0100

1000

0111

0110

0100

1011

0111

1011

110

101

40. á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.

138



•

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.

0110

1011

1010

0111

0100

1000

0111

0110

0100

1011

0111

1011

110

101

0110 1010 0100 0111 0100 0111 110 0110

1011

1010

0111

0100

1000

0111

0110

0100

1011

0111

1011

110

101

41. á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


139


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és-szolgáltató tesz közzé. Tartalmazza azokat a tanúsítványokat, melyek idı elıtt é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.

140



0110

1011

1010

0111

0100

1000

0111

0110

0100

1011

0111

1011

110

101

0110 1010 0100 0111 0100 0111 110 0110

1011

1010

0111

0100

1000

0111

0110

0100

1011

0111

1011

110

101

42. á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áslétrehozó eszközön és az idıbélyegzı szolgáltatása.


141


0110

1011

1010

0111

0100

1000

0111

0110

0100

1011

0111

1011

110

101

0110 1010 0100 0111 0100 0111 110 0110

1011

1010

0111

0100

1000

0111

0110

0100

1011

0111

1011

110

101

43. á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. 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. 142



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 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áslé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 Magyar Informatikai Biztonsági Ajánlás

143


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.

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.

144



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.

Az olvasó újra pirosan villog. Ekkor készül el a kódolt lenyomat, ami

a

kártyaolvasón

visszajut

az

keresztül

aláírás-létrehozó

szoftverhez.


145


Amennyiben beállításaiban

a

szoftver

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.

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.

146



A fogadó a megkapott XML fájlt betölti az aláírás-ellenı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.

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


147


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

igényeknek.

Amennyiben

támasztott a

legfelsı szinten levı hitelesítésszolgáltató a vhr-ekben nevesített közigazgatási hitelesítésszolgáltató,

gyökéraz

aláírás

biztosan megfelel az elvárásoknak.

44. á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 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

148



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


149


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 ealáíráshoz kapcsolódó szakértelemre van szükség.

150



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

Az információ védelme adminisztratív eszközökkel. Pl.:

biztonság

jelszókezelési szabályzat.

Algoritmikus

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

biztonság

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

vezetéknélküli

Integrity

(sértetlenség),

összekapcsolására szolgáló technika. CIA

Confidentiality

(bizalmassá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.)


151


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

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.

Informatikai

Olyan elıírások és intézkedések végeredménye, amely

biztonság

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

152

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. Valamely szolgáltatást nyújtó informatikai 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ı

Olyan védelmi intézkedés, amely a veszélyes esemény

intézkedés

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ér-számítógép.

PKI

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

felek

hitelesítésére,

elektronikus

aláírásra,

rejtjelezésre. PreDeCo

A védelmi intézkedések fajtái. Preventive (megakadályozó), detective (észlelı), corrective (helyreállító).

Protokoll

Szabályrendszer,

amely

leírja

informatikai

eszközök

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.


153


SMTP

Simple Mail Transfer Protocol – elektronikus levelek továbbítására szolgáló protokoll

SSL

Secure Socket Layer – megoldás hálózati kapcsolatok (pl. web, email) hitelesített és titkosított létrehozására

SSH

Secure Shell – távoli bejelentkezést hitelesítetten és titkosítottan megvalósító protokoll

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

154



JOGSZABÁLYOK

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 Magyar Informatikai Biztonsági Ajánlás

155


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

156



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

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ú ajánlása az informatikai szerzıdések általános követelményeirıl 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)


157


HIVATKOZÁSOK

ÁLTALÁNOS IT BIZTONSÁG Cert-Hungary: http://www.cert-hungary.hu/ biztonsagosinternet.hu portál: http://www.biztonsagosinternet.hu/ Elektronikuskormányzat-központ: http://www.ekk.gov.hu/ 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

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) 84/2007. (IV. 25.) Korm. rendelet a Központi Elektronikus Szolgáltató Rendszer és a kapcsolódó rendszerek biztonsági követelményeirıl 158



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)

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

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

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/

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: Magyar Informatikai Biztonsági Ajánlás

159


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

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

aláírás

nyilvántartás:

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

160


KÖZIGAZGATÁSI INFORMATIKAI BIZOTTSÁG. 25. számú Ajánlása. Magyar Informatikai Biztonsági Ajánlások (MIBA)

Recommend Documents