SZÁMÍTÓGÉPES
ADATVÉDELEM
1. Bevezetés
A számítógépek és a számítógépes adatok
védelme egyre növekvő jelentőséggel bír, ennek megfelelően egyre nagyobb
érdeklődés mutatkozik a számítógép-biztonság iránt. A védelem jelentősége
lényegesen megnőtt a hálózatok megjelenésével, a védekezés összetettebbé
és bonyolultabbá vált, s a felhasználóknak ugyanakkor eddig nem ismert
veszélyforrásokkal kell szembenézniük. Tévhitek terjedtek el mind a
veszélyforrásokról, mind a védekezési módokról.
Rögtön itt a bevezetőben nyomatékosan
felhívjuk a figyelmet arra, hogy a biztonság alapja a jó menedzsment, a
megbízható és kellően integrált hardver és szoftver, a szakképzettség és a
kulturált használat.
2. Alapfogalmak
2.1 Számítógép-biztonság
Számítógép-biztonság (computer security)
alatt szűkebb értelemben az adatok illetéktelenek hozzáférésétől való
védelmét, elsősorban a titkosságot (secrecy, confidentiality) értik.
Tágabb értelemben az alábbi hármast értjük
rajta:
- titkosság és hozzáférési kontroll (access
control);
- integritás (sértetlenség - integrity,
pontosság - accuracy, hitelesség - authenticity);
- elérhetőség (availability);
és gyakran még egy negyedik szempontot:
- megbízhatóság (reliability), melyen a
hardver, a szoftver s a szolgáltatások üzembiztonságát értjük, azaz, hogy
rendszerünk azt és úgy végzi-e, amint az elvárható/elvárt, elfogadható
karbantartási igény és meghibásodásszám mellett. Ez több, mint a rendszer
elérhetősége.
2.2 Megbízhatóság
A megbízhatóságon egy más fogalmat is
értünk: azt, hogy mennyire lehetünk biztosak rendszerünk megbízható
működésében, védettségében - mennyire tesztelt, igazolt annak védelme
(trustiness).
A fenti fogalmakba beleértjük, hogy
megfelelő kontrollal rendelkezünk rendszerünk felett, hitelesen nyomon
tudjuk követni a biztonsági eseményeket.
Előtérbe került - bár közvetlenül nem tárgya
a fentieknek - az ember és a környezet védelme is. A nem megfelelő
környezet természetesen veszélyt jelent a számítógépes rendszerekre és a
számítógépes munkavégzésre nézve is, de ennél is fontosabb az ember és
környezete védelme.
2.3 Mit védünk? Sebezhetőség
Nagyon fontos tudnunk: mit és miért
védjünk/védünk, mennyit ér meg a védelem? Ehhez a sebezhetőségünket
(vulnerability), a kockázatot (risk) és a védekezés módját, a választható
óvintézkedéseket (counter-measures) kell ismernünk.
A sebezhetőség főbb típusai:
- fizikai sebezhetőség;
- hardver, szoftver, média (adathordozó)
sebezhetőség;
- kommunikációs sebezhetőség;
- humán sebezhetőség.
A megfelelő óvintézkedésekhez tudnunk kell a
támadási lehetőségekről, a veszélyforrásokról (threats). A veszélyforrások
és a sebezhetőség egyes típusai között egyszerűen leírható kapcsolatok
vannak. A főbb veszélyforrások a következők:
- fizikai veszélyek;
- gondatlan (nem szándékos) károkozás;
- szándékos támadás (alkalmi rosszakarók,
számítógép-betörők - crackerek, hackerek);
- programozott kórokozók (közismert példa a
számítógép-vírus);
- program és konfigurációs hibák, hardver
hibák;
- házon belüli és házon kívüli támadók
(insiders és outsiders).
A megfelelő védelem az arányos védelem, ahol
a védendő érték, a potenciális veszély, a védekezés által okozott
kellemetlenség ésszerű arányban áll a védelemre fordított költségekkel és
erőfeszítésekkel. Általában az adatok jelentik a legnagyobb értéket, egyes
helyeken pedig a folyamatos üzem elengedhetetlen. Az akadémiai szférában
és az otthoni felhasználóknál az adatok értéke relatíve kisebb, az
üzembiztonság szintén csekélyebb jelentőségű, ennek megfelelő a felelősség
is. Amíg az adatvesztés egy cég életébe kerülhet, itt csak múló fájdalmat
jelent - azonban ez lehet igen kellemetlen is, akár évek munkája is
veszendőbe mehet. A privát szférával szemben azonban a védekezés itt sem
könnyebb. Nyílt, eleve nem biztonságos környezetben kell megfelelő
védelmet biztosítani. (Természetesen nem az erőforrások elzárásával
fokozandó a biztonság!) Oktatási intézményekben pedig inkább jó, mint
rossz példát kellene mutatni.
3. Biztonsági menedzsment és adminisztráció
A megfelelő menedzsment a védelem alapja. Ez
igaz mind az egyfelhasználós környezetre (otthoni felhasználóra), mind a
többfelhasználós (intézményi, vállalati) környezetre, de az utóbbi sokkal
összetettebb, a vezetőség által elrendelt szabályzatokon és a kialakult
szokásokon nyugszik. Nélkülözhetetlen, hogy írott szabályok rögzítsék az
alapvető illetékességi, felelősségi, hierarchikus viszonyokat. Szintén
nélkülözhetetlen, hogy világosan és pontosan megfogalmazott és kihirdetett
felhasználási politika, üzemeltetési szabályzatok legyenek.
A menedzsment része a biztonsági
menedzsment, a felhasználási politika részben magában foglalja a
biztonsági politikát. Követelmény, hogy a biztonsági politika szintén
írásos alapon nyugodjon, nyílt legyen, azaz nyilvánosan hozzáférhető, s ne
tartalmazzon bizalmas elemeket. Természetesen a biztonsági politikát be
kell tartani és tartatni. Emiatt fontos, hogy az ésszerűség határai között
legyen csak szigorú (tartalmazzon kötelező és ajánlott elemeket).
A biztonsági politika
legfontosabb elemei, a legfontosabb kívánalmak:
- világos, pontos, körülhatárolt, előre meg-
és kihirdetett, mindent lefedő legyen;
- jelölje meg az illetékességi viszonyokat,
határozza meg a felelősségeket és a felelősöket, a felelős személyek
valóban felelősök legyenek;
- hálózatok, fontosabb berendezések
(routerek, domain név szolgáltatás, hálózatmenedzsment eszközök és
hasonlóak) és nagyobb szerverek rendelkezzenek egyértelműen meghatározott
felelős üzemeltetőkkel, s önálló szabályzattal;
- a fejlesztési tervek és a fejlesztések
biztonsági szempontból is legyenek átgondoltak;
- biztosított legyen a rendszeres
tájékoztatás, oktatás és gyakorlás;
- átgondolt, következetes és gondosan
végrehajtott mentési rend kell;
- legyen terv a rendkívüli eseményekre
(katasztrófa terv);
- vezessünk gépkönyveket, naplózzunk minden
privilegizált accounttal kapcsolatos és rendkívüli eseményt (itt részben
automatikus (online), részben manuális naplózást kell végeznünk);
- gépkönyveket, naplófile-okat gondosan
archiváljuk, rendszergazda váltás esetén fordítsunk figyelmet az átadásra.
Alapvető, hogy egy intézményen belül főbb
vonalakban egységes biztonsági politika érvényesüljön, ez legyen
összhangban a társintézményekével, partnerekével, s legyen összhangban a
használt globális hálózatokéval is.
Az informatikai menedzsment biztonsági
feladatai nem közömbösek a felhasználók számára, így némi betekintés
kívánatos e területre.
Példák a menedzsment
feladataiból (a teljesség igénye nélkül):
- napi, heti, havi mentés, visszaállítási
gyakorlat (utóbbi persze nem napi rutinfeladat);
- logfile-ok, rekordok ellenőrzése;
- naplózás;
- nem használt felhasználói bejegyzések
(dormant account) felülvizsgálata, törlése;
- rendkívüli események kivizsgálása;
- jelszó menedzsment (jelszó nélküli
accountok felszámolása);
- felhasználók figyelmeztetése rossz jelszó
használat stb. esetén;
- vírusellenőrzés;
- rutin és szúrópróbaszerű ellenőrzések;
- hibák elhárítása, kiküszöbölése;
- hálózatbejárás;
- szünetmentes tápegységek ellenőrzése;
- tájékoztatás, figyelmeztetés, riasztás
stb.
Időszakonként a rendszer teljes átvilágítása
válhat szükségessé, ez mindig megteendő súlyosabb biztonsági események
után.
Meg kell jegyezni, hogy a fenti
követelményeket sehol sem teljesítik maradéktalanul, de ez inkább
sajnálatos, mind követendő. Az ésszerű biztonsági politika nem teszi
lehetetlenné a működést, betartása több előnnyel jár, mint hátránnyal.
ISMERI SAJÁT MUNKAHELYE INFORMATIKAI
FELHASZNÁLÁSI ÉS BIZTONSÁGI POLITIKÁJÁT?
2. Fizikai biztonság
A számítógépek, adathordozók, hálózatok és
ezek környezete sebezhető.
A veszélyforrások igen sokrétűek:
- lopás, szándékos rongálás;
- fizikai veszélyforrások, mint:
- tűz;
- víz, nedvesség (csőrepedés, billentyűzetre
ömlő almalé, páralecsapódás);
- napsütés, hideg-meleg;
- por, füst, agresszív gőzök (dohányzás);
- rengések (földrengés, járműforgalom);
- villámlás, elektromos kisülések;
- elektromos hálózat zavarai (rossz
földelés, áramingadozás, áramkimaradás);
- statikus elektromosság;
- mechanikai sérülések;
- rágcsálók, ízeltlábúak (vezetékek
átrágása, érintkezési zavarok, rövidzárlat);
- . . .
Valószínűleg a fizikai veszélyforrások
okozzák a legtöbb üzemzavart, kárt (eltekintve a hardver és szoftver
hibáktól), s a legnagyobbakat is. A védekezés a fizikai károk ellen a
legnehezebb és a legköltségesebb. Emellett minden védelem alapja a
számítógépes eszközök és környezet fizikai védelme. Pl. hiába mentünk, ha
a mentési média károsodik.
A fizikai védelemnek nyilván sok közismert
módja van, valamint a védekezés nagyon helyspecifikus, s terjedelmi
okokból is elnagyoljuk e kérdés tárgyalását. Csak néhány dologra
szeretnénk felhívni a figyelmet:
- illetékteleneket ne engedjünk szervereink,
fontosabb berendezéseink közelébe, védjük eszközeinket és az
adathordozókat lopás és szándékos károkozás ellen;
- a mentést (ill. a hordozó médiát)
biztonságos helyen (esetleg több példányban), ne a számítógép mellett
tároljuk;
- a mentést, archivált anyagainkat fizikai
hatásoktól védett helyen tároljuk és/vagy rendszeresen ellenőrizzük, hogy
nem érte-e őket károsodás;
- a különlegesen fontos berendezéseinket
mindig zárt helyen, ne ablakok, fűtőtestek, vízvezeték szerelvények
közelében üzemeltessük, tároljuk;
- a hálózat fizikai védelmére hívjuk fel a
figyelmet, különös tekintettel az új dolgozókra és a takarító személyzetre
(a költözködés, tatarozás gyakran okozza a hálózat sérüléseit);
- robusztus megoldásokat alkalmazzunk (pl. a
vékony Ethernet igen sérülékeny, de megfelelő fali csatlakozók hatékonyan
növelhetik a biztonságot);
- dohányzást ne engedjünk meg számítógépes
környezetben;
- tartsuk tisztán, pormentesen
környezetünket, védjük floppy és CD lemezeinket portól, piszkolódástól;
- adathordózókat le- (és el)zárva tartsunk;
- adatok mozgatására (kellő sávszélesség
esetén) még mindig a hálózat a legpraktikusabb;
- működő gépbe ne nyúljunk, ne
csatlakoztassunk hozzá berendezéseket (nyomtatót, szalagos egységet stb.);
- a száraz levegő, a műszálas anyagok
elektromos kisüléseket okozhatnak (egy műszálas padlószőnyeg állandó bajok
forrása lehet);
- a földelésekre mindig nagy gondot
fordítsunk;
- használjunk megbízható szünetmentes és
áramkondicionáló, túlfeszültség ellen védő berendezéseket, s ezek
karbantartásáról, ellenőrzéséről ne feledkezzünk el (általában 2-5 évente
telepcserére szorulnak);
- a vezetékeket (mind kommunikációs, mind
erősáramú) úgy vezessük, hogy ne legyenek a közlekedési utakban, kerüljük
a feleslegesen hosszú vezetékeket;
- gondosan dokumentáljuk, vezessük térképre
vezetékeinket;
- a fizikai védelmet rendszeresen
ellenőrizzék a hálózatüzemeltetők és mi magunk is;
- mindig ismerjük meg új berendezéseink
karbantartásának módját, s az ésszerűség határán belül törekedjünk annak
betartására;
- ipari környezetben ne irodai, hanem ilyen
környezetre tervezett berendezéseket használjunk (pl. ipari PC-ket);
- biztonsági (behatolás, lopás, betörés,
füst, tűz) érzékelőket általában célszerű a számítógép-hálózattal együtt
telepíteni;
- alkalmazzunk beléptető/hozzáférési
rendszereket (pl. smart card alapú megoldásokat), számítóközpontok,
szerverszobák, számítógépes laborok stb. esetében kövessük nyomon ki,
mikor, meddig, mit, mire használt;
- hasonlóan biztosíthatunk szervereket,
nyomtatókat stb. (a használatot is mérve);
- hálózatunk WAN, GAN kapcsolatai
rendelkezzenek tartalék (backup) vonallal, ill. legalább két független
kapcsolatunk legyen (melyek pl. az Internet felé különböző nyomvonalon
haladnak és különböző elérési pontokkal rendelkeznek). Az Internet esetén
rendszerint az egyetlen kritikus szolgáltatás a levelezés. Erre backup
vonalként akár analóg kapcsolt telefonvonal is szolgálhat (csak a rövid
üzeneteket - pl. 10000 byte határig - átengedve hatékony és nem is túl
költséges).
3. Megbízhatóság
A megbízhatóság alatt a hardver, a
perifériák és a szoftver elvárható szintű üzemképességét,
használhatóságát, ill. hibátlan működését értjük. Tapasztalataink szerint
a legtöbb hibát, problémát nem a szigorúan vett biztonsági hiányosságok,
vírusok, ellopott jelszavak okozzák, hanem a hardver és a szoftver hibák,
hibás installálás, véletlen törlés, nem kielégítő karbantartás, rosszul
tervezett, toldott-foldott hálózat. Más biztonsági eseményeket is
kiváltanak, vagy ilyenekben közrejátszanak a fent említettek. A biztonság
alapja a megbízható hardver és szoftver. A megbízhatóság szorosan
összefügg a menedzsment és a fizikai biztonság helyzetével. E kérdéskör
annyira szerteágazó és helyspecifikus, hogy az alábbiakban csak pontokba
szedve emelünk ki néhány kérdést, ill. útmutatást adunk:í
3.1 A megbízhatóság alapja:
- a képzettség és gondosság, mind a
menedzsment, mind a felhasználók részéről;
- a gondosan kiépített, dokumentált,
menedzsment és kontroll eszközökkel ellátott hálózat;
- a megbízható szervizháttér, egységes, jól
integrált rendszerek;
- a fizikai biztonság megteremtése alapvető,
enélkül biztonságot nem remélhetünk;
- dedikált berendezések,
feladatok/szolgáltatások szétosztása növeli a biztonságot, bár
nehézségeket is teremt, ugyanis több berendezést kell ellátnunk;
- törekedjünk az egyszerűen kezelhető,
karbantartható, jól dokumentált (szükség esetén magyar dokumentációval
rendelkező) termékek használatára;
- automatizáljuk a mentési, áram-kimaradási,
menedzsment stb. funkciókat;
- robusztus technológiát alkalmazzunk;
- vezessünk gépkönyveket a javításokról,
fontosabb változtatásokról;
- dokumentáljuk, hogy a konfigurációs
file-okban és hasonlókban ki, mit, mikor és miért változtatott.
3.2 A hardver megbízhatóságának alapja:
- vállalati környezetben szinte mindig
kifizetődőbb egységes brandname márkák alkalmazása a noname-ekkel szemben,
így ezeket részesítsük előnyben;
- szerver feladatokra szerver
kiépítésű/rendeltetésű berendezéseket célszerű alkalmazni;
- kellő tartalékot (skálázhatóságot)
biztosítsunk a méretezésnél;
- állítsunk be tartalék eszközöket
(elsősorban 'meleg' tartalék javasolt, azaz folyamatosan elérhető,
használt, de adott kiesett funkciók átvételére képes gép);
- technikában nem kifutó, hanem már érett,
de még terjedő, felfutóban lévő, de már széles körben elterjedt technikát
alkalmazzunk.
Számos hardver és szoftver technika
használatos fokozott hibatűrés biztosítására (redundáns adattárolástól
szerver tükrözésig), a hibák figyelésére és előrejelzésére, az egyszerű
(esetleg működés közbeni) javíthatóság biztosítására.
A szoftverek biztonsága
sokkal összetettebb kérdés. E tárgykört nem igazán lehet lefedni néhány
tanáccsal. Inkább csak példaként néhány megjegyzés:
- házilag összetákolt szoftverek kétes
értékűek állandó, folyamatosan jelentkező igények teljesítésére;
- márkás vagy közismert szabad szoftvereket
alkalmazzunk;
- ha lehet adaptáljunk és ne fejlesszünk;
- csak jól dokumentált szoftvert
használjunk;
Az alkalmazott szoftverek esetében szintén
fontos azok gondos összehangoltsága, itt is törekednünk kell az
egységesítésre, összhangra. A szoftverek kiválasztása, installálása,
konfigurálása, update-je és upgrade-je jelentős támogatási igényt követel,
mind a felhasználók, mind a menedzsment részéről.
A hálózatok megbízhatósága
majdnem olyan összetett kérdés, mint a szoftvereké. De vannak egyszerű
ökölszabályok (itt csak a fizikai szint kérdéseire kitérve):
- 'strukturált' hálózatot, árnyékolatlan
sodrott érpárt, részben üvegszálat alkalmazzunk;
- külső hálózatban vagy üvegszálat, optikai,
mikrohullámú átvitelt részesítsünk előnyben, vagy kisebb sebességű
technikát alkalmazzunk;
- mindig komoly (neves, referált)
hálózatépítő céggel dolgoztassunk, adott esetben rendszerintegrátort
alkalmazzunk;
- korszerű hubokat alkalmazzunk, ilyenekre
térjünk át;
- alkalmazzunk túlfeszültség (pl. villám)
elleni berendezéseket;
- a földelésekre nagy gondot fordítsunk, a
földeléseket szakember vizsgálja felül;
- a hálózat nyomvonal vezetése, méretezése
kritikus kérdés;
- a hálózati vezetékek védett csatornákban
fussanak, zárható kábelrendezőket alkalmazzunk;
- a hálózati berendezések mindig a lehető
legegységesebb típusúak, márkájúak legyenek, mindig kiváló minőségűek;
A kábeleink, a csatlakozóink, a berendezések
portjai, a lengőkábelek áttekinthetően és közérthetően legyenek címkékkel
ellátva. Mindig tüntessük fel, hogy egy helyiségbe, kábelcsatornába belépő
kábel merre halad, merre hagyja el a helyiséget, honnan érkezik.
Persze ez többe kerül, mint a legolcsóbb út.
A kapott funkcionalitás, bővíthetőség, fejlesztési lehetőség és a
biztonság arányban áll az ebből adódó többletköltséggel.
4. A mentés
A mentés a tárolt információról történő
biztonsági másolat, vagy másolatok készítése. Rokon fogalom az
archiválással, bár a mentés fogalma ennél általánosabb, mert ekkor a még
használatban lévő adatokról is készítünk biztonsági másolatot, sőt inkább
ezen van a hangsúly. Az archiválás esetén szinte kivétel nélkül relatíve
olcsó, off-line (kivehető) adathordozóra készül másolat. Archiválás esetén
a cél az esetleges visszakeresés, míg a mentés esetén az elveszett sérült
adatok helyreállításán van a hangsúly. Az alábbiakban csak a mentéssel
foglalkozunk, de az elmondottak nagy része alkalmazható az archiválásra is
(a két fogalmat gyakran nem is különítik el, szinonimként alkalmazzák).
A mentés mind a felhasználók, mind a
rendszergazdák fontos tennivalója, de az utóbbiak egyik legfontosabb
kötelessége is. Mind a felhasználóknak, mind a rendszergazdáknak
mentési-visszaállítási stratégiával kell rendelkezniük, s a
többfelhasználós rendszerek esetében írásban rögzített (és az érintettek
előtt ismert) mentési-visszaállítási politikával is. A visszaállítás
reális esélye nélkül a mentésnek sok értelme nem lehet, ezért a
következőkben több esetben a mentés és visszaállítás helyett csak a
mentést említjük.
Normális esetben a számítóközpontok
rendszeresen mentik az általuk üzemeltetett szerverek, nagygépek adatait,
sok esetben a felhasználók munkaállomásaiét is. A rendszergazdák, ill.
nagyobb helyeken az ún. backup operátorok felelősek az adatok
helyreállíthatóságáért. A felhasználók mindig tájékozódjanak a helyi
mentési politikáról, de legfontosabb adataikat maguk is mentsék.
A visszaállítás kulcskérdés, méghozzá olyan
feladat, amit tesztelni/gyakorolni kell (számítógép-központokban az ilyen
gyakorlatot 'katasztrófa gyakorlatnak' nevezik, s végrehajtása része a
mentési politikának). Sok kellemetlenség adódhat, ha csak akkor derül ki
valamely adat visszaállíthatatlansága, amikor az eredetije már elveszett.
4.1 Néhány fontos fogalom:
Full backup (teljes backup) - a rendszer
minden adatának (azaz felhasználói adatok, rendszer, hozzáférés stb.)
mentése. Hetenként, de legalább havonként illendő egy teljes mentést
végezni.
Incremental backup - az előző backup után
bekövetkezett változások mentése. Rendszerint napi feladat.
Partial backup (részleges backup) - egyes
adatok, adatcsoportok teljes mentése.
Zero day backup - a rendszer induló
állapotának mentése.
4.2 Útmutatók és tanácsok:
- Rendszeresen mentsünk, legyen havi, heti,
szükség esetén napi mentésünk. A napi, heti, havi stb. mentéseket
egymástól függetlenül végezzük.
- Az egymást követő napi, heti, ... mentések
rendszerint inkrementális mentések, de hetenként, havonként végezzünk
független teljes mentést. A mentést addig őrizzük meg, amíg szükség lehet
rá (ennek idejét nem könnyű felmérni: egy újabb mentés nem teszi
szükségtelenné a korábbiak megőrzését!).
- A teljes mentést legalább két példányban
végezzük.
- Legalább két fizikailag különböző helyen
tároljuk mentéseinket (lehetőleg ne egy épületben).
- Olyan médiára mentsünk, ami szokásos s a
jövőben is elérhető, hogy adatainkat később is visszaállíthassuk. Új
médiára csak nagy körültekintéssel térjünk át.
- A mentési kapacitást méretezzük túl.
- Bizalmas információról készíthetünk
titkosított (kódolt) mentést is. Vigyázzunk, hogy ez esetben is garantált
legyen a visszaállítás lehetősége. Csak különösen indokolt esetben éljünk
ezzel a lehetőséggel, s ne a teljes mentést, hanem annak kritikus részeit
titkosítsuk.
- Biztonságos helyen tároljuk a mentéseinket
(tűztől, víztől, erős elektromágneses hatásoktól, lopástól stb. védve).
- Mindig gondosan adminisztráljuk a mentést
(mikor, mit, mire stb. mentettünk).
- Legyen két független eszköz a
visszaállításhoz (vagy ha csak egy van, legalább tudjuk, hogy honnan
kérjünk kölcsön, ha az az egyetlen meghibásodott).
- Ahol csak lehet automatizáljuk a mentést,
többszintű mentési politikát alkalmazzunk.
- Ne idegenkedjünk az ún. hardcopy
mentésről, azaz fontos adatainkat, a rendszer visszaállításhoz szükséges
információkat (pl. konfigurációs file-ok tartalmát) nyomtatott formában is
őrizzük.
- Vigyázzunk, ne használjunk elhasználódott
médiát mentésre, fordítsunk gondot a mentő eszköz megbízható működésének
ellenőrzésére. A szalagokat nem szabad túl sokszor felhasználni. Egyes
helyeken egyáltalán nem használják mentésre kétszer ugyanazt a szalagot,
de ez túl drága megoldás. A márkás szalagok több százszori teljes
újraírást is kibírnak (a szalagos meghajtótól, tárolási körülményektől
függően), de a magunk részéről ennél gyakoribb selejtezést javaslunk.
- Az adataink értéke szerint mentsünk.
4.3 Mentési médiák:
Az átlagos felhasználó számára a
hajlékonylemezek megfelelnek (archiválásra már nem, de a legfontosabb
adatok mentésére igen). Egy második merevlemezes egység, vagy központi
erőforrások (szerverek) általában szintén használhatók, de kritikus
anyagainkat mentsük off-line médiára is.
A szerverekre töltést azonban a helyi
rendszergazda ellenezheti, különös tekintettel arra, hogy nagy diskquoták
(tárkorlátozások) esetén vagy quoták hiányában sokan előszeretettel
kukásedénynek tekintik a szervereket. A fileszerverek használata
mindemellett igen kényelmes (megbízhatóságuk is általában nagyságrenddel
vagy többször nagyobb a munkaállomásokénál), valamint az itt tárolt
anyagokról amúgy is rendszeresen mentésnek kell készülnie. Néhány fős
munkacsoportnak is érdemes file-szervert üzemeltetni, már csak
háttértárolónak és mentőeszköznek is. Szerverekről történhet
munkaállomások mentése is (bár ez DOS/Windows környezetben nem mindig
oldható meg kényelmesen).
A nagyobb tömegű mentési feladatokra ma a
szalagos egységek a legmegfelelőbbek. A szalagok olcsók, többször
felhasználhatók, egyszerűen kezelhetők, léteznek kellően nagy
kapacitásúak. Gondosan érdemes kiválasztani az egység típusát (a különféle
DAT kazettás egységek a legáltalánosabbak). Nincs ok hinni azoknak, akik a
szalagokra mentés hibáit hangoztatják. Ma még ár/teljesítmény és kényelem
terén mindenképpen felülmúlják az optikai, magneto-optikai technikákat, de
archiváló egységnek a CD-R ígéretes.
A különféle cserélhető merevlemezes, vagy
nagy kapacitású floppy meghajtó egységek és hasonlók ma általában nem
kifizetődőek, mellesleg nem is elterjedtek.
A mentési médiák és berendezések ügyében
forduljunk szakemberhez.
4.4 Mentés a gyakorlatban,
tapasztalatok:
El kell mondanom azonban, hogy lényegesen
kevesebb intézményben találkoztam mentési politikával és kielégítő
mentéssel, mint ahol ilyenről egyáltalán nem is beszélhettünk. Kielégítő
gyakorlat ritka mint a fehér holló, túlzásba vitt mentési gyakorlattal még
nem találkoztam. Általában senki sem veszi komolyan a mentést, amíg keserű
tapasztalatokat nem szerez - sokaknak nem elég az egyszeri rossz
tapasztalat sem.
Még egyszer megjegyezzük:
A LEGTÖBB BAJ MEGELŐZHETŐ MEGFELELŐ
MENTÉSSEL!
5. A jelszó
Szinte minden többfelhasználós rendszer
jelszót kér bejelentkezéskor (login) ill. kapcsolatfelvételkor. A jelszó
használata számos más esetben is szokásos: képernyővédő, setup
beállítások, rendszerindítás, partíciók, könyvtárak, file-ok, adatbázisok
elérésénél, programok indításánál stb.
Gyakran többszintű jelszavas védelmet
alkalmaznak, azaz egymás után több jelszó kérést kell kielégítenünk. Pl.
belépünk egy többfelhasználós rendszerbe: először a rendszer, utána az
adatbázis menedzsment rendszer kér jelszót. A jelszavas védelem más
módszerekkel kombinálható (pl. PIN kártya, ujjlenyomat ellenőrzés), ez az
ún. többfaktoros védelem.
A jelszavas védelem olcsó, könnyen
kivitelezhető, egyszerű, jól bevált és széles körben elterjedt módszer,
számos gyengeséggel. Más védekezési módokkal kombinálva (pl. többfaktoros
védelem) rendkívül hatásos.
Gyengesége elsősorban a felhasználók
hanyagságában, tájékozatlanságában rejlik, másrészt rendszerint a teljes
védelem egyetlen jelszóra alapozott, így ellopása, kitudódása
katasztrófához vezethet. A legtöbb betörést a rossz jelszavak használata
(lásd alább), vagy a jelszavak hiánya okozza. Egyes becslések szerint a
behatolások több mint 80 %-ánál ez az ok. Másrészről a jelszavak sokszor
nem biztonságos módon tárolódnak a rendszerekben, haladnak át a számítógép
vonalakon, hálózatokon. 'Nem biztonságos'-on értjük a titkosítatlan
jelszavak használatát, azaz ha a jelszó lehallgatható vagy kinyerhető a
rendszerből.
Fontos tudni, hogy a(z operációs) rendszerek
a jelszavakat általában nem tárolják, hanem egyutas módon titkosítják, s a
titkosított jelszavakat hasonlítják össze.
A fentiek alapján kijelenthetjük, hogy a
jelszavak használata kulcsfontosságú biztonsági kérdés. A csekély
biztonsági igényt követelő rendszerek (pl. az akadémiai szféra rendszerei)
és az Internet védelme alapvetően az egyszerű (egyfaktoros, egyszintű)
védelemre és nem biztonságos utakra (biztonságos úton olyan kommunikációs
csatornát és adatforgalmat értünk, mely kellően biztonságos - azaz nehezen
hallgatható le, az adatok módosíthatóságának esélye csekély, s az
illetéktelen hozzáférés észlelhető stb.) alapozódik, ilyen rendszerek
esetében ez tekinthető arányos védelemnek. Azonban az Internet túlnőtt az
akadémiai felhasználáson, így a biztonságos utak ill. az ún. egyszer
használatos jelszavak előtérbe kerültek.
A problémák zöme mégis az
alábbiakból fakad:
- a felhasználó nem érti, miért kell neki
jelszavakat használnia;
- miért nem oszthatja meg másokkal a
jelszavait;
- nem gondol arra, vagy nem gondos eléggé
ahhoz, hogy nehezen kitalálható jelszavakat használjon;
- és ha már nem triviális jelszavakat
használ, akkor elfelejti a jelszavait;
- ezek után legközelebb felírja jelszavait
(nem mindig tekinthető ez rossz megoldásnak, de ha egy nyilvánosan
elérhető titkosítatlan file-ba teszi ôket, az már nem az igazi).
Sok esetben a felhasználó nem ismeri a file
engedélyek megadásának módját, s csak a jelszó átadásával tudja más
részére átadni a hozzáférést.
Mint mindig, most is megjegyezzük, hogy a
rendszeres mentés a legfontosabb kiegészítő védelem. Így legalább adataink
elvesztésétől megóvhatjuk magunkat.
Az alábbiakban pontokba szedve rövid
útmutatót adunk néhány, jelszavakkal kapcsolatos kérdésben.
5.1 Útmutató a helyes jelszó
használathoz:
- Ún. 'jó' jelszavakat használjunk (lásd
alább).
- Minden rendszerhez különböző jelszót
használjunk (legalább néhány karakterben különbözzenek a jelszavak),
többszintű védelemben ne használjunk egyező jelszavakat.
- Csak titkosított formában tároljunk
jelszavakat.
- Legyünk tisztában vele, hogy rendszereink
hogyan tárolják, továbbítják jelszavainkat.
- Ha több jelszót használunk, akkor
dolgozzunk ki magunknak jelszó használati, képzési politikát.
- Rendszeresen változtassuk jelszavainkat
(de nem érdemes gyakran).
- Ne osszuk meg mással az accountunkat, ne
adjuk át másnak jelszavunkat, ne használjunk közösen accountokat (ennek
használatára még nem találkoztunk elfogadható indokkal).
5.2 Útmutató helyes jelszó
választáshoz:
A jó jelszó
- nehezen kitalálható,
- könnyen begépelhető,
- könnyen megjegyezhető,
- igény szerint 5-10 karakter hosszú,
- tartalmaz betűket, számokat és/vagy
írásjel karaktereket.
Azt hiszem nem kell sok képzeleterő jó
jelszavak kitalálásához.
5.3 Egyéb problémák,
kérdések:
Számos esetben találkozunk program generálta
jelszavakkal, melyek megjegyezhetetlenek, esetlenek. Néhány esetben az
ilyen jelszavak megváltoztatását a rendszer nem engedélyezi. A
megváltoztathatatlan jelszavak csak többszintű jelszavas védelem egyes
szintjein fogadhatók el - legalábbis e sorok írója szerint.
Tisztában kell lennünk azzal, hogy
rendszereink gyakran úgy konfiguráltak, hogy bizonyos időközönként meg
kell változtatnunk jelszavainkat, s jelszavaink nem lehetnek a korábban
használtak. A rendszer nem engedi meg bármilyen jelszó megadását
(minimális hossz, megkövetel kis és nagybetűt stb.). Számos rendszer
megengedi hosszabb jelszó használatát is, mint amit figyelembe vesz (azaz
pl. csak az első 8 karaktert veszi figyelembe).
Ritkán előfordul, hogy jelszavunkat a
rendszer visszaírja a monitorra. Ennek okaira itt nem térünk ki, de ilyen
esetben feltétlenül forduljunk az illetékesekhez segítségért.
A lehallgatásról külön fejezetben
foglalkozunk.
Fontos megemlítenünk, hogy egyes rendszerek
(pl. Unix) megkülönböztetik a kis és nagybetűt. Ilyenkor a 'Caps Lock'
gomb véletlen lenyomása megtéveszthet bennünket és nem tudjuk begépelni a
jelszavunkat. Még gyakoribb, hogy a billentyűzetvezérlőnk magyar ékezetre
van állítva, s emiatt vagyunk sikertelenek.
Érdemes arról is szólni, hogy a jelszó
lopások (itt nem valódi lopásról van szó, a tolvaj nem tudja meg a
jelszavunkat, csak megváltoztatja, inkább account lopásnak nevezhetjük az
ilyen eseteket) jelentős része az őrizetlenül hagyott terminálok, az
elfelejtett kijelentkezések miatt következik be.
5.4 Jelszavak és az Internet
Az Internet biztonságát érintő legtöbb
kritika a titkosítatlan jelszavak elterjedt és részben elkerülhetetlen
alkalmazását illeti*. A titkosítatlan jelszavak inkább a helyi hálózatokon
okoznak gondot, a lehallgatás itt a legkönnyebb és leggyakoribb. Az
Internet biztonsága mindig és most is lépést tartott/tart a felmerülő
igényekkel. Természetesen a kereskedelmi forgalom megjelenése hatalmas és
hirtelen jelentkező igényeket támaszt.
* Vegyük azonban figyelembe, hogy egyrészről
az TCP/IP protokollok (alsó réteg, azaz a hálózati IP, és transzport TCP
és UDP) nem zárják ki, hogy a felső hálózati rétegek ill. az alkalmazások
titkosítást alkalmazzanak (pl. HTTP helyett SHTTP-t), másrészt más
rendszereken a titkosítatlan jelszavak használata épp így szokásos (pl.
BBS-ek esetében - igaz, hogy a kapcsolt telefonvonalak lehallgatásának
kisebb a veszélye).
VÉDI ACCOUNTJÁT JELSZÓVAL? JÓ JELSZAVAKAT
HASZNÁL?
6. Hitelesség és
hitelesítés
Üzenetek, levelek, osztott dokumentumok és
adatbázisok használata esetén fontos, hogy valóban a vélt személy küldte-e
az üzenetet, végezte-e a módosítást, valamint illetéktelenek nem
'piszkáltak-e' bele az adatokba. Emellett fontos, hogy az adatok
hitelességét ellenőrizni tudjuk, vagy kellő alapunk legyen abban megbízni.
A hitelességet legtöbbször az biztosítja,
hogy csak az illetékes személy jogosult az adott művelet végrehajtására,
pl. csak neki van hozzá elérési joga. Mindazonáltal a hitelesség nehezen
igazolható csak ilyen módon, különösen ha többen is (esetleg
illetéktelenül is) rendelkeznek az adott hozzáférési joggal.
Az operációs rendszerek, adatbázis-kezelők,
levelező rendszerek jegyezhetik, hogy ki, mit, mikor csinált, de egyrészt
ezeket sokszor be lehet csapni, másrészt nem mindig könnyű a
visszaellenőrzés.
Ha elektronikus üzenetek hitelessége
esetében gyanúnk merül fel, akkor telefonon vagy más módon rákérdezhetünk
az üzenet szerzőjére, ellenőrizhetjük, hogy létező accountról érkezett-e
az üzenet. A dokumentumok, üzenetek formája is árulkodhat.
A hitelesítésnek más, biztosabb - szinte
tökéletes - módjai vannak. A megoldás kriptográfiai módszerek alkalmazása.
A titkosított üzenetet megfelelő kódolás esetén csak a kulcs ismerője
készíthette, a dokumentumról készült ellenőrző összeget kódolva a
visszafejtés (kellő) nagy valószínűséggel csak a kódolt üzenet
változatlansága esetén tehető meg. Sőt, elég csak az ellenőrző összeget
kódolnunk, ezzel a hitelesítés (mind az aláírás, mind a belepiszkálás
elleni védelem) megoldott. A keltezést az ellenőrző összegbe foglalva
annak hitelességét is igazolhatjuk.
Az utóbbi időben a World-Wide Web
terjedésével előtérbe került az ún. Internet cache-ek alkalmazása, azaz a
már egyszer lehívott információk ideiglenes tárolóba történő helyezése, a
rákövetkező esetleges lekérések gyorsabb megválaszolása céljából. Ilyen
esetekben a dokumentum hitelességégének és aktualitásának kérdése élesen
jelentkezik. E kérdéskörre a megoldások még nem teljesek. Tudnunk kell,
mikor kell kikerülnünk a cache-eket.
A hitelességnek egy másik értelme is van: az
Interneten elérhető dokumentumokat, programokat mikor fogadhatjuk el
hitelesnek? valódi és helyes információkat tartalmaznak-e? a programok
elvárásaink szerint viselkednek-e? Ez azonban már nemcsak
számítógép-biztonsági kérdés.
6.1 A számítógépes versus hagyományos
aláírás és dokumentum hitelesítés
Megdöbbentő, hogy milyen kétkedéssel
fogadják az elektronikus levelek hitelességét, míg pl. fénymásolt (faxolt)
aláírásokat azonnal hitelesnek fogadnak el. Emellett számítógépes és/vagy
pénzügyi szakemberek azt hiszik, hogy az elektronikus aláírás
Magyarországon nem fogadható el jogi korlátozások miatt, de a faxolt
aláírást el lehet fogadni. Valóban van számos ésszerűtlen jogi megkötés,
de a pénzügyi világban általában nálunk is alkalmazható a digitális
aláírás (az más kérdés, hogy partnereink azt sem tudják, hogy eszik ezt
vagy isszák). (Lásd alábbi kis írásunkat: "Mi az a digitális aláírás".)
A digitális aláírás gyakorlatilag az
egyetlen jól bevált mód, mellyel egy teljes dokumentumról igazolni lehet
nem csak annak hiteles aláírását, de a teljes dokumentum változatlanságát,
azaz, hogy azt nem módosították az aláírása óta, valóban a keltezés
idejében állították ki, stb. (s mellékesen a titkosságot is
biztosítottuk).
Kódok, jelszavak, hitelkártya számok
átküldésére a megfelelően titkosított, digitális aláírással ellátott
üzenetek nyilván alkalmasabbak, mint a telefon, a fax vagy a csigaposta.
Sőt, ez utóbbiak titkosítás nélkül nem is tekinthetők alkalmasnak.
Bár üzleti, vállalati rendszerek
biztonságával nem kívánunk itt foglalkozni, fontos megjegyeznünk, hogy az
- üzleti és hivatalos - elektronikus adatcserére (Electronic Data
Interchange - EDI) nemzetközi (ENSZ) és US szabványok széles körben
elfogadottak.
6.2 Mi az a digitális
aláírás?
Rögtön előrebocsátjuk, hogy nem a közönséges
aláírásunk digitalizált változata. A digitális aláírás egy olyan
titkosított karaktersorozat (vagy más információ), melyet igen nagy
valószínűséggel csak a küldő ('aláíró') kódolhatott, s ez magából a
kódolásból következik. Keltezést (dátumot, pontos időpontot), sorszámot (a
visszajátszás megakadályozására), a küldött üzenetből készült ellenőrző
összeget stb. tartalmazhat. A részletek iránt érdeklődőknek
Pretty Good Privacy (PGP) és
Privacy-Enchanced Mail (PEM)
A PGP és PEM programok a titkos és hiteles
hálózati kommunikációt szolgálják, nyilvános kulcsú kriptográfiára
támaszkodva.
A számítógépes üzenetek titkosításának de
facto szabványa ma a PGP. Bővebb információt az alábbi URL alatt kaphatunk
róla:
http://draco.centerline.com:8080/~fran1/pgp/
Lásd még:
http://www.cs.indiana.edu/ripem/dir.html
http://www.rsa.com
http://www.ifi.uio.no/~staalesc/PGP/home.html
http://www.cisc.ohio-state.edu/txt/faq/usener/pgp-faq.html
7. Névtelen levelek és
üzenetek
A következőkben hamis leveleknek nevezzük a
szakirodalom által 'pseudonym'-nak (angolul 'fake mail', ill. 'forged
mail'-nek) ismert leveleket, melyeket hamis címzéssel (nem létező címmel
vagy más nevében) adtak fel, s a névtelen leveleket is ide értjük.
Sok levelezőrendszerben (pl. az Internet
alapvető levelezőrendszerében) könnyű, vagy legalábbis lehetséges hamis
levelet küldeni. A levelező rendszerek átjárói is lehetővé teszik, hogy
olyan rendszerből kapjunk üzenetet, mely gyenge kontrollal rendelkezik a
feladó hitelesítésére.
A névtelen levelek egy része gyalázkodó, sok
vizet nem zavar, de bosszúságot okozhat. A névtelen levelek más részénél a
feladó csak az anonimitását akarja megőrizni, rossz szándék nélkül.
Mindenesetre a névtelen levélküldés nem tekinthető kedvező jelenségnek, de
más nevében hamis levelet küldeni megengedhetetlen. Ilyenkor érdemes erre
felhívni az illetékes postamester vagy rendszergazda figyelmét és
segítségét kérni - ez közérdek.
Nagyobb gondot okoznak a mások nevében
küldött üzenetek: ilyenkor az üzenetek tartalma, stílusa stb. árulkodhat.
Sok esetben a levél header vagy boríték (RFC 822 terminológia szerint)
árulja el a feladás rendellenes voltát.
Nyilvánvaló mód a feladó hitelességének
ellenőrzésére a rákérdezés, ill. a levél visszaküldése a feladónak.
Lehetőleg persze ne e-mailen, hanem más csatornán tegyük ezt, e-mailen
legfeljebb akkor, ha a feladó címe létezik, s tudjuk vagy ellenőriztük,
hogy azt a jogos tulajdonosa használja.
A hamis levelek problémáját az üzleti, ill.
bizalmas levelezésben legjobban a digitális aláírással küszöbölhetjük ki.
Az Internet levelezésre is megjelentek szabványok a titkosság és a feladó
hitelesítés biztosítására.
A névtelen és hamis üzenetek kérdése
alapjában véve egyezik a hamis levelekével.
Rokon probléma a véletlen levélküldés téves
címre vagy címekre. Némileg kellemetlen érzése lehetett annak a hölgynek,
kinek szerelmes levelét vállalatának kétszázötven dolgozója megkapta. Az
esetlen Compuserve és más hasonló címeknél nem ritka, hogy rossz
gépeléssel valódi címet találunk el. Levelező szoftverek (saját magunk
által írt) makrói szintén okozhatnak tréfákat.
8. Hálózatok lehallgatása
A hálózatokon, kapcsolt vonalakon haladó
adatforgalom többé-kevésbe könnyen lehallgatható. Különösen a helyi
hálózatok adatforgalma hallgatható le könnyen, az itt szokásos
üzenetszórásos technika jóvoltából (egy hálózati szegmens* minden egyes
munkaállomásához a többi munkaállomás minden üzenete eljut). Az
átlagfelhasználó rendszerint nem is sejti, hogy a helyi hálózatok milyen
könnyen lehallgathatók. E védtelenség a helyi hálózatok eredeti
rendeltetéséből is származik, hiszen ezeket csoportmunkára szánták, ahol a
lehallgatás nem jelent komoly rizikó faktort. Az analóg kapcsolt (telefon)
vonalak lehallgathatósága közismert, de csak a központokban lehet
nagyszámú vonalat egyszerre lehallgatni, így itt a veszély a helyi
hálózatokénál sokkal kisebb - de fennáll.
Számos adatátviteli mód nehezen hallgatható
le (ISDN, GSM, optikai átvitel, vagy a szinte lehallgathatatlan szórt
spektrumú átvitel), de a tökéletes megoldást csak a teljes adatforgalom
titkosítása jelentheti. Akadémiai célú felhasználás ezt nem indokolhatja.
Azonban a legfontosabb adatok (jelszavak, bizalmas üzenetek)
titkosíthatók. Több operációs rendszer és hálózati alkalmazás vagy eleve
titkosított formában küldi át a jelszavakat, vagy ún. titkosított, egyszer
használatos ('one-time password') jelszavakat használ.
A jelszavak titkosítása önmagában még nem
megoldás, hiszen a titkosított jelszót elfogva, azt újra lejátszva
beléphetünk egy rendszerbe anélkül, hogy a jelszót tudnánk. A mai
rendszerek, ha már titkosított jelszavakat használnak, akkor alkalmaznak
módszereket a titkosított jelszó újrafelhasználásának megakadályozására
is. Itt nem akarunk ennek a technikai részleteibe bonyolódni.
Technikailag könnyű kivitelezhetőségének
köszönhetően az utóbbi időkben a helyi hálózatok lehallgatása elterjedt.
Szabadon elérhető, BBS-ekről, anonymous FTP helyekről letölthető
szoftverek alkalmasak lehallgatásra, melyeket egyébként a hálózati
menedzserek hálózatmonitorozására, a forgalom analizálására fejlesztettek
ki. E szoftverek használata meglehetősen erőforrás-igényesnek számított,
de ez már nem áll fenn, az utóbbi idők átlagos PC-i már képesek futtatni
ilyen programokat. Így a lehallgatás széles körben elérhetővé vált. A
hálózat kivitelezése, topológiája nagyban befolyásolja a lehallgatás
lehetőségeit, azonban ez idáig a lehallgatás elleni védelem nemigen volt
szempont a hálózattervezéskor. Szerencsére korunk új technikái, melyeket a
nagyobb hálózati teljesítményigények miatt alkalmaznak, nagyban nehezítik
a lehallgatást (pl. a switching hub-ok).
A hálózatok lehallgatása rendkívül jelentős,
ez úton tömegével lehet jelszavakat illetéktelenül megszerezni. A
védekezés nehéz, nagyon is nehéz lehet. Elvben vannak megoldások, de
alkalmazásuk a gyakorlatban körülményes. A legfontosabb, hogy
szarvashibákat ne kövessünk el:
- ne jelentkezzünk be távolról superuser
vagy más kritikus jelszóval,
- ne küldjünk e-mailen, ne tároljunk
file-ban titkosítatlan jelszavakat.
Sokat segíthet:
- a környezetünk, a hálózat gépeinek
ellenőrzése, figyelemmel kísérése;
- már magának a problémának az ismerete is.
Alapvető megoldást a hálózatok megfelelő
kialakítása, adott esetekben átszervezése, valamint bizonyos
hálózatmenedzsment megoldások jelentenek. A probléma összetett, s csak
összetett, önmagában nem teljesen hatékony eszközökkel védekezhetünk,
melyek együttesen már hatásosak.
A jelszavak illetéktelen megszerzése
munkaállomásokon elhelyezett ún. 'jelszó lopó' programokkal is könnyen
megvalósítható. Ez lehet egy 'ál-login' program, mely először lejegyzi a
jelszót, majd végrehajtja a valódi login procedúrát. Tökéletlen
programoknál feléledhet a gyanúnk, de nyilván az ilyen program
illetéktelen gépre kerü-lését kell elkerülni, ill. legalább kritikus
accountokat (pl. superuser) potenciális támadásoktól védett gépről
használjunk. Természetes a jelszavak leleshetők, rejtett kamerával is
felvehetők, s a trükkök sorát folytathatnánk, sőt a fent említetteknél még
rafináltabb lehallgató eljárások is ismeretesek.
* Szegmens alatt routereket, bridge-eket,
switcheket csak a határain tartalmazó hálózatrészt értünk.
9. Vírusok, férgek,
trójai falovak és egyéb programozott kórokozók
Az alábbiakban olyan programokkal,
programkódokkal foglalkozunk, melyet ártó szándékkal (beleértve az
illetéktelen elérést is) hoztak létre, vagy kísérletezésből, játékból
születettek, de veszélyt jelentenek és kárt okozhatnak. Az ilyen kódokat
'vandalware' szóval is illetik, mely roppant találó, bár nem elterjedt. E
programok sajátos csoportját alkotják a vírusok és a férgek (worms),
melyek sajátsága, hogy aktivizálódva reprodukálódhatnak, s egy rendszerben
vagy számítógépek közt terjedhetnek. Bár számos más csoport is
idetartozik, ezek közül csak a trójai falovakat (Trojan Horses)
tárgyaljuk. Említjük a bombákat (bombs) és a csapóajtókat (hátsó ajtó -
trap door, back door), melyek, mint az előzőek 'alkatrészei' érdekesek. Az
egyéb csoportok jelentősége nem kicsiny, de nem a nyílt hálózatok
(Internet, BBS-ek) esetében, vagy túl speciális kérdés lenne tárgyalásuk.
A vírusokban, férgekben és trójai falovakban még két közös vonás van, ami
a közös tárgyalásukat indokolja:
- a hasonló károkozás;
- az ellenük történő védekezés hasonlósága,
mely a terjesztés- és terjedésbeli rokon vonásokból fakad.
9.1 Vírusok
A vírusokra több definíció használatos.
Szűkebb értelemben (mi mindig így használjuk) a vírus egy programkód, mely
önállóan működésképtelen, melyet program vagy program információs file
tartalmazhat, a program végrehajtásával aktivizálódik és replikálja magát,
hozzáfűzi vagy beleírja magát más programokba.
A vírusokat rendszerint ártó szándékkal
hozzák létre (bár kísérleti vagy játék célból is születtek). Általában az
észrevétlen terjedés érdekében rejtettek, károkozásukon kívül nehezen
vehetők észre (segédeszközök nélkül). Gyakran bombákat tartalmaznak,
egyesek képesek más vírusokkal interakcióba lépni.
A vírusok nem hatásosak, ha nem kerülnek
végrehajtásra. Ezért a másolás s minden más, végrehajtás nélküli
tevékenység veszélytelen velük. Adatfile-t nyugodtan beolvashatunk
rendszerünkbe (feltéve, ha nem tartalmaz program információt valamely
végrehajtandó program számára). Léteznek vírusok ill. vírusszerű
kreálmányok, melyek bootlemezről a bootkóddal aktivizálódhatnak, így
fertőzött lemezről a bootolás veszélyes.
Hasznos tudnunk, hogy csak az
egyfelhasználós rendszerek ellen bocsátottak szabadon vírusokat (PC-s DOS
és Windows, Macintosh System, Amiga és Atari OS , ...). Unix-ra írtak, de
csak kísérleti célból, VMS-re, mainframe-re nem ismeretes vírus (bár a
szakirodalom említ ilyeneket, ezek nem vírusok a mi definíciónk
értelmében). NetWare alatt futót soha senki nem írt. OS/2-re létezik.
NT-re tudtommal nincs, a Windows 95 terén a szerző sajnos tájékozatlan.
Olyan vírus sem ismeretes, amely több operációs rendszer alatt is
működőképes lenne. Bár többfelhasználós rendszerekre lényegében nincsenek
vírusok, ez nem zárja ki, hogy DOS vagy Windows emuláció alatt vírusok nem
aktivizálódhatnak, replikálódhatnak, sőt akár károkat is okozhatnak - pl.
a Word makró vírusok -, de ezek operációs rendszer szinten már nem
veszélyesek.
9.2 Férgek
A férgek - ellentétben a vírusokkal - önálló
programok. Máskülönben hasonlóak a vírusokhoz. Férget sokkal kevesebbet
írtak mint vírust, s mivel ezek hálózaton át terjednek elsősorban, ezért a
többfelhasználós rendszerek az elsődleges célpontjaik. Híres példa az
Internet 1988-as féregfertőzése (az Internet Worm).
Az első férgeket kísérleti jelleggel,
hasznos célra hozták létre. Céljuk az akkor szűkösen elérhető számítógépes
erőforrások feltárása és kihasználása lett volna. A gondolat azóta is
kísért, bár nem erőforrás, inkább információgyűjtés (pl. WWW-n - vigyázat
a WWWWorm nem féreg!), hibaelhárítás és hálózatmenedzsment célból. Számos
DOS-os féreg van, amit rendszerint vírusként emlegetnek.
A férgek potenciálisan nagyobb veszélyt
jelentenek. Az ismert vírusok elterjedése hamar korlátokba ütközik, s a
terjedési sebesség is kisebb annál, hogy ne lehetne hatékony riasztást és
védelmet alkotni. Persze elvben egy féreg terjeszthet vírust is, s így már
egy vírus is kemény dió lehet, de ezt az ötletet a vírusírók még nem
használták ki. Mindazonáltal a mondottak a jelen pillanatban érvényesek, s
nem elvi korlátok. Meglepő lehet, hogy az 1988-as Internet Worm eset óta
nem következett be súlyos féregfertőzés az Interneten. Ez részben az
1988-as intézkedéseknek köszönhető, részben a szerencsének. Talán az
Internet globális biztonsága lépést tart a támadókkal.
9.3 A trójai falovak
A trójai falovak olyan kódok, programok,
melyeket más programba rejtettek. Ilyen értelemben a vírusok is trójai
falovak, de a trójai falovak nem feltétlenül vírusok. A trójai falovon
inkább olyan programot szokás érteni, mely hasznos programnak látszik,
vagy valamely más hasznos/ismert program preparált változata. Sokkal
könnyebb trójai programot készíteni, mint vírust vagy férget, sokkal
jobban is lehet álcázni, inkább a terjesztése nehézkes.
9.4 Bombák
A bomba egy programkód, melyet valamely más
program tartalmaz, s valamely feltétel (idő, esemény, vagy ezek
kombinációja) hatására, vagy távvezérléssel 'robbannak', 'robbanthatók'. A
fenti programozott kórokozók sokszor tartalmaznak ilyeneket, emellett
szoftver másolásvédelemben, (shareware, bérelt stb.) szoftver
hatástalanítására alkalmazzák. Ez utóbbi bombák csak az aktuális szoftver
hatástalanítására szolgálnak.
9.5 Csapóajtók
A angol nyelvű biztonsági irodalom a 'trap
door' és a 'back door' kifejezéseket használja rejtett kiskapuk
meghagyására, létrehozására, melyen az illegális behatoló bejuthat vagy
újra visszatérhet a rendszerbe. Az angol 'trap door' egyik hétköznapi
magyar megfelelője a 'csapóajtó', a 'back door'-é pedig a 'hátsó ajtó'.
(Utóbbi félrevezető lehet, a 'hátsó ajtó' kifejezést a magyar nem ismeri.
Talán a 'kiskapu' jó lenne, de ez érzelmi töltéssel bír. Így jobb híján
maradunk itt is a csapóajtónál).
Csapóajtót hagyhat maga után a korábban
legális eléréssel rendelkező felhasználó, egyszer illegálisan hozzáférést
szerző személy, de csapóajtók telepíthetők trójai falovakkal, férgekkel és
más módokon is. Sőt, programhiba, konfigurálási hiba folytán rendszerünkön
eleve lehet csapóajtó. Értelemszerűen a rendszerek ellenőrzésének ki kell
terjedni az esetleges csapóajtók feltárására is. Ilyen célra számos
szoftvert írtak, de kényszerű okokból ezek operációs rendszer és
alkalmazás specifikusak, valamint használatuk szakértelmet igényel.
9.6 Védekezés
Az alábbiakban csak a vírusok elleni
védekezéssel foglalkozunk, de nem azért mert a vírusok általunk
kitüntettek lennének, hanem mert a védekezés más jószágok ellen is nagyban
hasonló. Sőt, a vírusok a legártalmatlanabbak a fent említett lények
közül. A mai napig nem írtak jelentős veszélyt jelentő vírusokat (a
vírusírás messze elmarad a technikai lehetőségek mögött - nincs
számítógépes megfelelője az AIDS-nek, az Ebolának és az influenzának).
Mindemellett könnyen átláthatók és kivitelezhetők a védekezés módjai.
A védekezés alapja, hogy tudnunk kell, mi
ellen védekezünk, milyen veszélyekkel nézünk szembe. A vírusnak valamely
módon be kell kerülnie rendszerünkbe, így az izoláció teljes védelmet
jelent, persze ilyen árat nem akarunk fizetni a hatásos védelemért. A
következőkben a vírusvédelem legfontosabb teendőit pontokba szedtük.
Először az egyéni (pl. otthoni) gépek, majd a helyi hálózatok
felhasználóinak védelmével foglalkozunk. Megjegyezzük: tökéletes védelem
nincs, de hatásos igen.
9.7 (Helyi) hálózatba nem kapcsolt gépek
esete
1. A vírusok adatvesztést, ill. a szoftver
károsodását okozhatják. A szoftver károsodása is kellemetlen, hiszen sok
esetben újra kell installálni rendszerünket, s ez pl. floppy-ról
bosszantóan időigényes lehet, vagy önerőből nem is tudjuk végrehajtani.
Adatainkat nagy baj nem érheti, ha rendszeresen mentettünk, s mentésünk
nem vírusfertőzött. Elvben (volt rá példa a gyakorlatban is) vírus hardver
károsodást is okozhat, de ennek veszélye rendkívül csekély. A szoftvereink
visszatelepítése újrafertőzés nélkül lehetséges, hiszen installáló
lemezeink írásvédettek (bár az írásvédelem esetleges hardver hiba miatt
nem garantált). Adataink vírusmentességét az biztosíthatja, hogy
végrehajtható kód kell a vírusfertőzéshez, s ha ilyen nincs a lemezünkön,
akkor fertőzöttek sem lehetnek adatállományaink. A kritikus
adatállományainkat tartalmazó floppy lemezeinket - pl. egy Unixos gépen -
átmásolva érintetlen lemezekre, azok vírusmentessége már garantált (igaz,
hogy ez esetleg önerőből nem megy).
2. Víruskereső szoftverrel rendszeresen
ellenőrizzük állományainkat, a kapott új állományokat is. A víruskereső
szoftver legyen naprakész. Esetleg használhatunk ún. rendszerintegritást
ellenőrző szoftvereket, de ez nem kötelezô.
3. Legyünk óvatosak, ellenőrzött és ismert
helyről szerezzünk be szoftvert (persze a kereskedelmi forgalmazás nem
garancia).
4. Fogadjuk fenntartással, ha valaki pénzes
vírusvédelmet, vírusvédelmi kártyát akar ránk sózni. Ezek önmagukban
nemigen hatásosak, valamint vakriasztásokat okozhatnak.
5. Az OS/2 HPFS vagy az NT file-rendszer
meglehetősen védett, Unix, VMS, NetWare ellen még nem került forgalomba
vírus. Természetesen DOS-os (Mac stb.) vírusok előfordulhatnak ilyen
file-rendszerekben is, csak nem képesek aktivizálódni a számukra idegen
operációs rendszer alatt.
6. Ismételt vírusfertőzéseket a lemezeinken
elfekvő vírusok okozhatnak.
7. Ha megtehetjük, a lemezeknél hatékonyabb
mentő/archiváló berendezést szerez-zünk be.
9.8 Védekezés helyi hálózatokon
Helyi hálózatokon a fentiek közül minden
eszközt alkalmaznunk kell, de ezeknél többet is, valamint a lehetőségeink
is szélesebbek. Itt a fő cél a vírusbekerülés potenciális útjainak
ellenőrzése, valamint a központi ellenőrzés. A tennivalók és lehetőségek:
1. Legyen vírusvédelmi politika, kapjanak
vírusvédelmi útmutatást a felhasználók. Valósuljon meg együttműködés az
érintettek között a vírusvédelemben (riasztás, tájékoztatás stb.).
2. Korlátozzuk a fertőzés útjait. Egyes
helyekről kiszerelhetjük a floppy meghajtókat, sőt remote boot-tal
diszknélküli üzemmódot használhatunk.
3. Szerverekről futtassuk alkalmazásainkat.
4. Használjunk központi file-szervereket és
központi mentést, a mentéseket és a file-szerverek állományait
ellenőrizzük, a file-szerverre másolt vagy módosított program azonnal
kerüljön ellenőrzésre.
5. Ne DOS/Windows környezetet alkalmazzunk,
ha lehetőségünk van másra.
Ha a fentiek alapján megfelelő gondossággal
járunk el, a vírusfertőzéseket gyakorlatilag kiküszöböljük. Ha nincsenek
kritikus alkalmazásaink (nem lehet munkaidő kiesés), akkor a helyi
hálózatokon annyi baj sem lehet, mint az otthoni felhasználóknál, hiszen a
visszaállítás a file-szerverekről pillanatok műve. (Persze rosszul
menedzselt rendszerekre ez nem áll!!!).
A tapasztalat azt mutatja, hogy az áttérés a
helyi hálózatra az egyedi PC felhasználásról, lényegesen csökkentheti a
vírusfertőzések számát. Ez annak köszönhető, hogy nem fekszenek el vírusok
hajlékonylemezeken, az ellenőrzés kiterjed a felhasználók állományaira, a
file-ok nagy része megfordul a központi file-szervereken, a vírusvédelmi
szoftver szétosztása és frissítése gyorsabb és szélesebb körű, a
szoftverek telepítése tiszta forrásból történik. Bár a hálózat bevezetése
számos új biztonsági probléma forrása, itt egy példa arra, hogy a
biztonsági problémák megoldásában is lehet szerepe.
10. BBS-ek és anonymous
FTP helyek
Mind az üzemeltetők, mind a felhasználók
számára sok biztonsági problémát vetnek fel a szabad (nyilvános) elérésű
archívumok, mint pl. BBS-ek és anonymous FTP helyek. A gondok nagy része
csak az üzemeltetőket érinti közvetlenül, ezekkel itt nem foglalkozunk.
A problémák egyik fô forrása, hogy e helyek
vírusok és más programozott kórokozók terjesztői lehetnek. A nevesebb FTP
helyek archívumai, cégek support FTP helyei nagyon jól ellenőrzöttek,
gondosan megválogatják, hogy honnan kerülhetnek ide programok, valamint az
üzemeltetők minden tőlük telhetőt megtesznek az ellenőrzésre. Tökéletes
védelem azonban nincs, a vírusok ellen a szigorú ellenőrzés még csak
hatásos, de trójai falovak időnként felbukkannak.
A felhasználó részéről a védekezés a
következő lehet:
- nem tölt le programot;
- a programokat izolált környezetben
teszteli (karantén);
- gondosan tesztel vírus azonosító
szoftverekkel;
- szoftvert csak hivatalos disztribúciós
helyéről vagy ennek hivatalos (vagy más szempontok miatt biztonságosnak
tekintett) tükör (mirror) helyeiről tölt le.
Látható, hogy csak az utolsó pont az, amit
igazán követhetünk. Megjegyezzük, hogy a vírusellenőrzést nevesebb
archívumok, disztribúciós helyek esetén nem tartjuk elengedhetetlennek. A
vírusfertőzések elenyésző töredéke vezethető vissza anonymous FTP-ről
letöltött file-okra.
A nyilvános elérésű helyekhez hasonló a
helyzet a különféle helyi archívumokkal. Sajnos általános útmutatót nem
lehet adni arra, hogy mely archívumok tekinthetők biztonságosnak, s melyek
nem.
Egyes archívumokba bárki tölthet fel
file-okat. Ha ezek az állományok azonnal nyilvánosan elérhetők, akkor ezek
biztonsága kétes (a beérkező file-on legfeljebb azonnali automatikus
vírusellenőrzés futtatható).
11. A World-Wide Web
A World-Wide Web megjelenésével az Internet
átalakult, akadémiai hálózatból általános világhálózattá vált, melyen
üzleti tranzakciók folynak, üzleti információk áramlanak.
Hitelkártyaszámok haladhatnak titkosítatlanul, ellenőrizetlen lehet mind a
fogadó, mind a küldő hitelessége. A Web üzleti alkalmazása töretlenül
hódit, ezen akarnak vásárolni, kereskedni, pénzátutalást teljesíteni,
bizalmas üzleti információkat lehívni az emberek.
Lássuk milyen kérdések,
biztonsági problémák merülnek fel:
- felhasználó (kliens) azonosítás;
- szerver azonosítás;
- biztonságos út titkos információk számára
(jelszavak, hitelkártya információk);
- információk hitelességének ellenőrzése és
hitelesítés;
- kulcs menedzsment;
- lehallgatás elleni védelem;
- kompatibilitás (felülről kompatibilitás a
régebbi kliens szoftverekkel és kompatibilitás a különböző védelmi és
titkosítási módokat alkalmazó rendszerek között);
- a kliensek védelme;
- a szerverek támadás elleni védelme;
- a szerverek szándékos és akaratlan
túlterhelése (pl. robotok 'támadásai');
- garantált szolgáltatás elérhetőség,
sávszélesség, ismert korlátú válaszidők.
Itt több, egymást átfedő
kérdéskört soroltunk fel: pl. a lehallgatás elleni védelem miatt fontos a
biztonságos út biztosítása. A fentiek mellett nem elég a Web-szintű
védelem: pl. hálózati fizetések esetén a biztonság függ attól, hogy a
háttérben milyen pénztranszfer rendszer működik.
A Weben nemcsak dokumentumok, hanem
programkódok és program információ is haladhat, mely a kliensen vagy
szerveren alkalmazásokat indíthat el (helper alkalmazások, PostScript
megjelenítés, Java scriptek stb.). Ez egy forrongásban lévő terület, még
nem gyűlhetett össze elég tapasztalat. Itt valójában nem kész termékek,
hanem köztes fejlesztések kerültek alkalmazásra.
A titkosság és hitelesítés kérdéseire
napjaink megoldásai közül talán a Netscape Co. Secure Socket Layer (SSL)
szabvány tervezete és implementációi Hiba! A könyvjelző nem létezik. a
legfontosabbak, de nem egyedülállóak. Alább pár szóban ismertetjük ezt és
egy másik szabványjavaslatot a Secure-HTTP-t a példa és a fentiek
szemléltetésének kedvéért.
Felhasználó azonosítást, jelszókat, csoport
jelszókat, IP cím- és névazonosítást (letiltást vagy engedélyezést) számos
HTTP szerver támogat (a legtöbb szerver még titkosítatlan jelszavakat
használ).
A szervizek elérhetőségére a hierarchikus
cache-rendszerek nyújthatnak hatékony megoldást (azonban itt újabb
kérdések is felmerülnek, pl. a cache-beli információ érvényessége,
naprakészsége).
S-HTTP néven is ismert. Draft Internet
szabvány, léteznek megvalósításai, gyakorlati alkalmazásai. Az S-HTTP nem
önálló protokoll, hanem a szabványos HTTP kiterjesztése. Az S-HTTP képes
az adatforgalom mindkét irányú titkosítását, digitális aláírás
alkalmazását és hitelesítést biztosítani a kliens és szerver között. A
válaszható titkosítási eljárásokra nem ad megkötést (támogatja a nyilvános
kulcsok használatát is), megengedi nem-S-HTTP tudatú kliensek alkalmazását
is (sőt kényesebb igényeknek is eleget tesz).
11.1 Secure Socket Layer (SSL)
A Netscape által kifejlesztett és támogatott
SSL nem a HTTP kiterjesztése, nem is kizárólag Web-specifikus, más
Internet alkalmazásokhoz is használható (így az S-HTTP-vel is
kompatibilis). Az SSL a HTTP-nél alacsonyabb szintű protokoll, biztonságos
csatornát képes létrehozni két végrendszer között: end-to-end titkosítást,
digitális aláírást, kliens és szerver azonosítást stb. támogat. Az SSL
külön URL használatát követeli meg ún. biztonságos szerverek esetén
('https://' kezdetűt a 'http://' helyett). A Netscape és számos más kliens
program képes kezelni az SSL-t, s a kliens grafikus felülete jelzi, hogy
biztonságos, vagy nem biztonságos szerverhez csatlakoztunk.
12. A dial-up kapcsolat
Napjainkban a dial-up kapcsolat mind az
Internet használatában, mind a távmunkában jelentős szerephez jutott. A
dial-up felhasználás problematikája sokban különbözik a helyi hálózatokról
történő eléréstől. Itt a felhasználók általában egy kereskedelmi
szolgáltatón keresztül érik el az Internetet, vagy munkahelyükre
csatlakoznak modemen (esetleg terminál adapteren) keresztül.
Klasszikusan biztonsági megoldásként
alkalmazták a dial-back-et, azaz a felhasználó visszahívását. Ekkor a
felhasználó bejelentkezik, majd bont a kapcsolat és a hívott gép
visszahívja (esetleg egy másik vonalon) a felhasználót. Ezzel a
felhasználó telefonszámának azonosítása megoldódott. Ma a visszahívás
inkább a hívó pénztárcájának kímélése érdekében történik. A visszahívás
sok visszaélésre ad alkalmat a nem rendeltetésnek megfelelő használat
esetén (pl. a munkáltató számláján keresztül magán-internetezünk, faxolunk
stb.). Megjegyezzük, hogy az ISDN sokkal több biztonsági szolgáltatást
nyújt, mint az analóg vonal.
Bár kapcsolt telefonvonali hívásnál is lehet
alkalmazni titkosított vagy egyszerhasználatos jelszavakat, vagy a vonal
forgalmának titkosítását, de ez nem szokásos. Így dial-up jelszavaink
titkosítatlanul haladnak az Internet szolgáltatókhoz vagy az egyéb online
szolgáltatókhoz. Ez gyakorlatilag nem vált ki aggódást a felhasználókból.
(Pillanatnyilag a dial-up Internet szolgáltatóknál a titkosítatlan
jelszavak használata a szokásos).
A dial-up Internet szolgáltatók esetében
érdemes tájékozódni, hogy milyen biztonsági politikát követ a szolgáltató,
s milyen megoldások vehetők igénybe. Egyes szolgáltatók nyílt biztonsági
politikát követnek, azaz biztonsági megoldásaik nyilvánosak, mások
titkolódznak. A nem nyílt biztonsági politika semmiképpen nem tekinthető
modernek, talán tisztességesnek sem.
13. Tűzfal
A tűzfal (firewall) találó elnevezés, a
közönséges megfelelőjéhez hasonló szerepet tölt be, célja nem a támadás
lehetőségének kiküszöbölése (a tűz megakadályozása), hanem akadályt
állítani a támadás elé, a sikeres behatolás valószínűségének csökkentése
(a tűz tovaterjedésének megakadályozása). Azaz: a tűzfal nem a védelem
alapeszköze, inkább fontos kiegészítője.
Alkalmazásuk egyre inkább terjed. A routerek
nagy része számos tűzfal funkciót képes ellátni. A tűzfal egyik típusa az
ún. 'külső tűzfal' a teljes helyi hálózatot részben izolálja az
Internettől, míg az ún. 'belső tűzfal' a helyi hálózat egy különösen
védendő részét zárja el annak többi részétől (és így az Internettől is). A
tűzfal használata titkos, érzékeny (sensitive) adatok védelme, vagy nagy
üzembiztonságot kívánó hálózatok esetén elengedhetetlen.
Manapság, amikor cégek, intézmények nagy
számban csatlakoztatják hálózataikat az Internetre, a tűzfalak - melyek
védelmi falként funkcionálnak a saját hálózat és az Internet között -
rendkívül fontossá váltak, használatuk igencsak terjed. Azonban nemcsak a
hálózat üzemeltetőinek kell tudniuk a tűzfalakról, hanem a felhasználóknak
is, akik tűzfal mögül érik el az Internetet ill. csatlakoznak rá, t.i. a
tűzfal nem teljesen transzparens a felhasználók számára, azaz tisztában
kell lenni a korlátozásokkal. Ezek a korlátozások helyről helyre
változnak.
A tűzfal - hasonlóan a hétköznapi szerepéhez
- akadályt jelent a helyi és a külső hálózat között, melyen bizonyos
forgalom egyik vagy mindkét irányban nem mehet keresztül, ill. valamilyen
további ellenőrzésen megy keresztül. Azaz a tűzfal bizonyos mértékig
izolálja a belső hálózatot. Az itt megadott leírás a 'külső tűzfalra'
(external firewall) vonatkozik, ugyanis használnak tűzfalat (internal
firewall) a belső hálózatok szegmentálására, egyes védett részek
izolálására is.
A tűzfal szerepét játszhatja egy intelligens
router, megfelelő konfigurációjú Unix gép, vagy több is ezek közül.
Internet tűzfalnak egy PC-n futó szoftver is kiválóan megfelelhet.
A tűzfal bizonyos protokollokat átenged (ún.
'biztonságos protokollok'), míg másokat nem (ismeretlen vagy ún.
'veszélyes protokollok', pl. tftp, r-protokollok). Bizonyos protokollokat
nem enged be: pl. a finger-re válaszolhat, de nem a finger-rel kérdezett
gép, hanem helyette maga a tűzfal. Más esetben (pl. News) magán a tűzfal
gépen lehet elérni a newsgroup-okat, vagy más szolgáltatásokat.
A tűzfal egyes protokollokat csak egyik
irányban engedhet át: pl. kifelé lehet telnet-ezni, befelé nem. Ez
kellemetlen csalódást okozhat egy külföldre utazott alkalmazottnak, amikor
azt veszi észre, hogy saját gépébe nem tud bejelentkezni, nem éri el
leveleit, stb.
Más módon is védhet egy tűzfal, korlátozva
bizonyos portok elérését, további azonosítókat, jelszavat kérhet, s még
számtalan módon szűrheti az információt.
A tűzfalak rendszerint folyamatosan jegyzik
a forgalom bizonyos adatait, a bejelentkező gépek, felhasználók
azonosítóit, rendkívüli és kétes eseményeket, továbbá riasztásokat is
adhatnak.
Fontos megjegyezni, hogy a tűzfalak
megfelelő konfigurálása nehéz feladat, s a tűzfal - hasonlóan a valódi
tűzfalhoz - nem biztosít tökéletes védelmet, de a 'tűz' továbbterjedését
gátolja.
14. Egyfelhasználós rendszerek védelme
A legtöbb felhasználó PC-s DOS-t vagy MS
Windows-t használ. Ezek egyfelhasználós rendszerek, eredendően legfeljebb
helyi hálózati használatra tervezettek, ahol a hálózat legfontosabb
feladata az állománymegosztás és a háttértárolás. Ma ilyen operációs
rendszerek (és hasonlóan a Macintosh, Amiga stb. gépek alapértelmezésű
operációs rendszerei) alatt teljes Internet kiszolgálót, FTP szervert stb.
futtathatunk. Számos ilyen program konfigurálható úgy is (sőt
alapértelmezésben ilyen vagy csak így futtatható), hogy pl. az FTP szerver
futása alatt bárki bejelentkezhet a PC-nkre, s akár az egész állományunkat
törölheti. A veszély ugyan kicsi, mert csekély a valószínűsége, hogy
valaki a PC-nkre vadásszon a szerver futási ideje alatt, de fennáll.
Emiatt ajánlatos az adott szoftver dokumentációját védelmi szempontból is
áttekinteni, s ha ilyen téren a dokumentáció vagy a védelem hiányos, akkor
más szoftver után érdemes nézni.
A mai egyfelhasználós rendszerek már
igazából nem egyfelhasználósak, peer to peer kapcsolatot,
állomány-kiszolgálást stb. biztosíthatunk rajtuk. Ezekre végül is a
többfelhasználós rendszerekre mondottak irányadók, annak
figyelembevételével, hogy lehetőségeink (kontroll, auditálás)
korlátozottabbak. Az erőforrás megosztás terén is szűkek a kontroll
lehetőségei (pl. az MS Windows kooperatív multitasking-ja miatt).
15. Speciális veszélyforrások, kérdések
Néhány nagyon gyakori, elterjedt biztonsági
problémát külön is szeretnénk kiemelni, melyek bár némileg
alkalmazás-specifikusak, de általánosan elterjedtek, s jellegüknél fogva
állandó biztonsági problémák okozói.
15.1 Az X Window
Az X Window a legelterjedtebb osztott
grafikus (ikonos/ablakos) felhasználói felület (rendkívüli előnye, hogy
platform-független). Alkalmazása esetén a felhasználó gépén fut egy ún.
terminál (X) szerver, melyet alkalmazás-szerveren futó alkalmazások, mint
kliensek szolgálnak ki. A X felület rendkívül rugalmas, könnyen kezelhető,
hatékony és sokoldalú, de használata veszélyeket rejt, különösen, ha nincs
megfelelően konfigurálva. Itt részletesen nem kívánjuk az X Window
biztonsági kérdéseit tárgyalni, csak a biztonsági hiányosságra mutatunk
példát:
Az ún. 'xhost +' parancs engedélyezi, hogy
bármely hostról kliens csatlakozzon az X szerverünkhöz. Kevésbé veszélyes,
ha tréfából kollégáink X ablakokat jelenítenek meg terminálunkon, de
nyilvánvaló, hogy ennél több is megtehető. Egyébként az 'xhost +' parancs
sokszor az X szerver alapértelmezésű beállítása.
Az X Window számos régebbi implementációja
súlyos hibákat tartalmazott.
15.2 Az 'r' parancsok
Az 'r' parancsok ('rlogin' és hasonlók) a
Berkeley Unix-ból származnak, ma már szinte minden Unix rendszer és számos
nem Unix alatti TCP/IP csomag részei. Az 'r' parancsok lehetővé tehetik
egy adott hostra bizonyos hostokról (ún. biztonságosnak tekintett
hostokról) felhasználói név vagy jelszó kérés nélküli csatlakozást. Így
hostok láncolata jöhet létre, melybe bárhol behatolva a láncon végig lehet
haladni.
15.3 Az NFS
A Sun Microsystem által kifejlesztett TCP/IP
feletti (heterogén) rendszerek közti transzparens file elérést biztosító
Network File System (NFS) használata hasonló rendszereknél
nagyságrendekkel elterjedtebb. Eredetileg Unix (SunOS) alá fejlesztették,
de ma már mikroszámítógépes operációs rendszerektől a nagygépekig széles
körben elérhető és használt. Az alapváltozat védelme gyenge (nem
biztonsági hibákból miatt, hanem magából a konstrukcióból fakadóan: az
NFS-t használó gépek kölcsönösen biztonságosnak tekintettek), illetéktelen
hozzáféréstől távolról sem védtelen (számos újabb implementációja már
védettebb, pl. az Sun Secure NFS-e).
A fő problémák mégsem a gyenge védelemből
fakadnak, hanem a rossz konfigurálásból. Az egyik leggyakoribb hiba:
írásjogot megadni minden hostnak (a `kiexportált filesystem'-re), mely nem
szerencsés módon általában - szinte kivétel nélkül - az alapértelmezés (ez
tekinthető úgy is, mint egyfajta biztonsági hiba). Lehetőleg a `rw'
(olvasás-írás) jogokat írjuk át `ro'-ra (`read only'), és ha mégis írás
jogot kell biztosítanunk, akkor korlátozzuk le a `rw' elérést hostokra
(sőt ennél többet is kellene tennünk ...).
Fontos megjegyeznünk, hogy az NFS-t számos
más módon is lehet rosszul konfigurálni! - és sajnos ezekkel a
lehetőségekkel gyakran 'élnek is' a (kevésbé képzett) rendszergazdák.
15.4 Törlés, felülírás, csoportmunka
Az operációs rendszerek, adatbázis-kezelők,
egyéb alkalmazások rendszerint lehetővé teszik az adatok, rekordok,
file-ok stb. törlését, felülírását. Mivel folyamatos mentés ritkán oldható
meg (pl. napi mentés van), ezért bizonyos helyreállításra,
újrafeldolgozásra, azaz plusz munkára van szükség véletlen törlés vagy
hiba által bekövetkezett adatvesztés esetén.
A véletlen törlés ellen védekezhetünk a file
írásvédetté tételével, bár ekkor pont módosítani, dolgozni nem tudunk a
file-on. Számos operációs rendszer biztosít lehetőséget a file-rendszerek
egyes elemeinek visszaállítására, ilyen esetekben a file-ok lényegében
csak törlésre jelölődnek ki, de fizikailag nem törlődnek. Azonban vannak
esetek, amikor egy operációs rendszer nem így működik, éppen biztonsági
okok miatt (a titkosság érdekében) azonnal töröl, más esetekben pedig
felülírás következhet be. A felülírás esélye az idő múlásával növekszik.
Bizonyos grafikus felhasználói felületek ill. operációs rendszerek vagy
segédalkalmazások lehetővé teszik, hogy a törlendőket átmeneti tárolóba
tegyük (pl. a Macintosh System 'kukásedényébe'), és onnan visszanyerhessük
azokat. Más rendszerek biztosítják, hogy verziószámokkal mentsünk, vagy
folyamatosan készítenek biztonsági másolatokat, esetleg pl. egy dokumentum
vagy CAD rajz minden szerkesztési műveletét mentik, így a visszaállítás a
szerkesztés minden fázisában lehetséges.
Alapjában véve itt minden egyszerű és
világos. A helyzet akkor kezd bonyolódni, amikor csoportmunkát végzünk,
ugyanazt a dokumentumot, adatbázist többen szerkeszthetik, módosíthatják,
törölhetnek benne. Ez esetben körültekintőbben kell eljárni, már az
alkalmazott eszközök (szoftver) megválasztásánál. Egyfelhasználós
szoftverek nem támogatják a csoportmunkát, ilyenkor csoportmunkát
(méghozzá jól) támogató szoftvereket kell alkalmazni. Emellett ki kell
alakítani a csoportmunka rendjét. A csoportmunka esetén a dokumentumok
különböző változatai jöhetnek létre, problémák adódhatnak, ha egyidejűleg
többen szerkesztenek egy dokumentumot.
A csoportmunka szoftvereknek
támogatnia kell:
- a finoman beállított jogosítványokat;
- a pontos könyvelést (ki, mit, mikor
végzett, módosított);
- az integritást és hitelességet általában.
Itt a szoftver gondos kiválasztására hívjuk
fel még egyszer a figyelmet. A szoftver jó megválasztása mellett persze
annak ésszerű használata is elengedhetetlen.
Bár már az előző fejezetekben említettük,
itt megismételjük, hogy minden felhasználó egyedi azonosítóval férjen
hozzá minden rendszerhez! Ne alkalmazzunk csoport accountokat, nyilvános
accountokat és jelszavakat!
15.5 Másolás védelem
A másolás védelem a szoftver gyártók
klasszikus eszköze az illegális (pontosabban az ő érdekeiket sértő)
másolás ellen. Vannak mind szoftveres, mind hardveres (és hálózati)
eszközei. Itt a védelem feltörhetetlensége és a védelem által okozott
esetleges károk, kellemetlenségek jelentik a biztonsági kérdéseket.
Lehetőség van a hálózatba kötött gépünk szoftvereibe gyárilag beépíteni
olyan programrészeket, melyek pl. az Interneten keresztül - akár a tudtunk
nélkül - értesítik a gyártót az illegális szoftverhasználatról. Egyes
esetekben a szoftvert hálózaton vagy modemes telefonkapcsolaton keresztül
(első) használat előtt regisztráltatni kell (e nélkül nem indul vagy nem
működik megfelelően).
A másolás elleni védelem érzékenyen
jelentkezik WWW oldalak (és más online publikációk) esetében, amikor a
szerző megtekinthetővé akarja tenni a dokumentumát, de nem másolhatóvá.
Megjelentek e téren az első termékek, de tökéletes megoldás nemigen
várható, hiszen, ha adatokat megtekinthetünk, akkor le is másolhatjuk őket
(bár érhetnek meglepetések). Mindenesetre a másolás, nyomtatás útjába
akadályok gördíthetők. A kérdés fontos, időszerű, de nem tudjuk mélyebben
tárgyalni a kérdéskört, mivel még gyerekcipőben járnak a megoldások (bár
egyszerű trükkök ismeretesek, melyekkel az átlagfelhasználó eszén túl
lehet járni).
15.6 Kiszolgáltatottság
Köd veszi körül, hogy a rendszergazdákat,
hálózatmenedzsereket stb. milyen felelősség terheli és milyen hatalom van
a kezükben. Végrendszerek esetében ez jobban átlátható, de a kommunikáció
útjai kifürkészhetetlenebbek. A rendszerek nagy részénél (pl. az Internet,
a legtöbb helyi hálózat) elvben minden adatforgalmat figyelhetnek,
manipulálhatnak, egyedül önnön becsületük a korlát. Természetesen ez így
nincs jól. A megoldás kulcsa azonban elsősorban nem a technikán, hanem az
informatikai menedzsment - vezetés - és a helyi informatika hármasának
viszonyában van. S persze az általunk elért külső hálózatok (pl. IP
szolgáltatónk) menedzsmentje is alapvető biztonsági tényező. Érdemes
felmérni, hogy kinek milyen manipulatív lehetőségei vannak egy hálózatos
rendszeren (a biztonsági politika kidolgozásának ez része). E kérdések ma
Magyarországon meglehetősen időszerűek: nyugati technikát használunk
alacsonyabb informatikai kultúrával.
16. Hibák, történetek, érdekességek
Ebben a fejezetben részben ismétlésként,
részben hiánypótlásként rámutatunk néhány fontosabb vagy érdekes hibára,
veszélyre. Megtörtént esetek ihlették egyik-másik bekezdést.
16.1 Alapértelmezésű jelszó
Korábban számos operációs rendszert
alapértelmezés szerint installálva bizonyos (fiktív) felhasználói nevek
alapértelmezésű jelszóval jöttek létre. Ma is számos alkalmazásnál
felbukkannak az alapértelmezésű jelszavak, az ilyeneket változatlanul
hagyva rendszerünket veszélynek tehetjük ki.
16.2 'C2 security'
Számítógép-biztonság kapcsán gyakran hangzik
el a misztikus 'C2' kifejezés. Misztikus, mert félreértik, helytelenül, de
legalábbis pongyolán használják és köd lengi körül (természetesen nem a
biztonsági szakemberekre gondoltunk). Valójában olvasóinknak elég azt
megjegyezni, hogy ha C2-t emlegetnek, akkor tudják, hogy számukra
érdektelen dologról van szó. Mi is az a C2? Az amerikai hadügyminisztérium
egy (1985-ös) szabványa automatikus adatfeldolgozó rendszerek biztonsági
kérdéseire létrehozott egy szabványt, népszerű nevén az Orange Book-ot. Ez
osztályokba sorolta a rendszereket biztonsági kritérium szerint, s egy
ilyen osztály a C2. Csak C2 osztályba sorolt rendszert szabad az Egyesült
Államokban bizonyos állami hivatalokban adott feladatokra alkalmazni. Noha
a szabvány tanulságos lehet egy szakembernek, nemigen lehet módunk
eldönteni, hogy egy rendszer eleget tesz-e a C2 követelménynek, vagy sem.
Az a gyakran alkalmazott reklám, hogy X.Y. operációs rendszer eleget tesz
a C2 követelményeknek, értelmetlen az Orange Book szerinti nézőpontból.
Kellően rosszul installálva, nem biztonságos hálózatba kötve egy rendszer
nemhogy C2, de semmilyen követelménynek nem tesz eleget (ill. a
bizonytalan rendszer követelményének eleget tesz). Még egy gondolat: az
Orange Book-nak egész sor kiegészítése született (Rainbow Series), ezek
egyes környezetekre éppen olyan jelentősek, mint az alapmű (pl. hálózatot
explicite nem említ az Orange Book, ezt egy másik színes könyv tárgyalja).
16.3 Dohányzás
A dohányzás legalább annyira káros
számítógépes rendszereinkre, mint az emberekre. A hamu eltömi a
hűtőberendezéseket, lerakódása zavarja a hőleadást. A dohányfüst korróziós
hatása is jelentős, lerakódása kisüléseket okozhat a mikroáramkörökön.
Kívül-belül összemocskolja a berendezéseket (dohányzás miatt
elpiszkolódott berendezésre nem vonatkozik garancia). Számos speciális kár
okozásáért is felelős vagy felelős lehet. Egyértelműen kimutatott, hogy
sok hardver (merevlemezes egységek, hajlékonylemezes meghajtók, egerek
stb.) élettartamát lényegesen (10-30 %-kal) csökkenti. Nehéz megérteni,
hogy egyes munkahelyek még csak nem is korlátozzák vagy szankcionálják a
dohányzást.
16.4 Domain Name System
Ha DNS szerverünk először egy másik géphez
irányítja a levelet (pontosabban a másik gép preferáltabb az MX bejegyzés
szerint, azaz kisebb a preferencia indexe), csak utána a rendeltetési
helyhez, a két gép ráadásul egy hálózaton helyezkedik el, valamint teljes
Internet eléréssel és mail transport agent-tel rendelkezik, ez ekkor már
gyanús: valami különleges ok áll fenn, esetleg tévedés történt, netalán
csak leveleinket akarják tanulmányozni.
16.5 Elektronikus levélcímünk változása
Levélcím változás esetén, ha lehet azonnal
ne szüntessük/szüntettessük meg régi címünket, onnan átirányítást
biztosítsunk vagy kérjünk. Rengeteg levél megy ismert, de nem működő
címekre, ahol gyűlnek az olvasatlan levelek, bosszankodnak a feladók.
Közismert példa az Ella rendszer (ráadásul itt sok felhasználó soha sem
tudta, hogy ő felhasználó).
16.6 Elfelejtett rendszeradminisztrátori
jelszó
A rendszeradminisztrátori jelszó sem
elfelejthetetlen, valamint más okokból is elveszhet. Bár az operációs
rendszerek jelentős része a jelszó visszaállítását nem teszi lehetővé, egy
kerülő út áll rendelkezésre a superuser jelszó megváltoztatására. Számos
Unix, a Novell NetWare 2.x és 3.x esetén ez rutinfeladat (elég csak a
géphez vagy a konzolhoz hozzáférnünk). Azonban több újabb operációs
rendszer már védettebb (pl. a NetWare 4.x), ezeknél súlyos baj lehet a
rendszeradminisztrátori jelszó elvesztése.
16.7 Írható távoli file-rendszer vagy annak
írható könyvtára
A veszélyek sora szemben a praktikummal. Ne
engedjünk meg véletlenül több jogot az olvasásnál! Ne engedjünk nyilvános
írásjogot! Ne azt határozzuk meg, hogy ki, mihez nem férhet hozzá, hanem
adjuk meg a szükséges jogokat, és azon kívül tiltsunk meg minden mást!
Többfelhasználós rendszerek lokális file-rendszerein is elkél az
óvatosság.
16.8 A jelszógyűjtés egy sajátos módja
Ha egy kellően érdekes, vonzó szolgáltatást
hozunk létre saját rendszerünkön, ami csak a felhasználó által szabadon,
de kötelezően választandó jelszóval érhető el, akkor a választott
jelszavakat összegyűjthetjük. Mivel a felhasználók részben megszokott
jelszavaikat használják, így ezekkel jó eséllyel kezdhetjük meg
behatolásunkat más rendszerekbe. Konklúzió: nem szabad különböző
(logikailag nem összefüggő) rendszereken azonos jelszavakat használni!
16.9 Jelszó nélküli accountok
A tapasztalat azt mutatja, hogy a
felhasználók 10-30 %-a - ha teheti - jelszó nélkül használja accountját,
teljes jogot engedve másoknak levelezéséhez, adataihoz. Ahol a személyes
adatok kevésbé értékesek, ott az arány még magasabb. Sokfelhasználós
rendszerek esetén a helyes jelszófelhasználás gyakran csak retorziókkal
érhető el.
16.10 Hálózati erőforrások indokolatlan
terhelése
Ez inkább etikai, mintsem biztonsági kérdés,
azonban a szolgáltatások elérhetetlenségét, használhatatlanságát
okozhatja, így nem lehet csak etikai kérdésként hozzáállni. Bár követni,
illetve (főleg szúrópróbaszerűen) ellenőrizni lehet, hogy a felhasználók
mit csinálnak, ez a személyiségi jogokat sértheti és etikai szempontból
sem elfogadható. Így csak a tájékoztatás, oktatás, nevelés és propaganda
segít.
16.11 A hálózati dokumentáció hiányossága
Egy hálózati hiba (pl. vezeték sérülés)
megtalálása rendkívüli feladat lehet, ha nem tudjuk, hogy merre haladnak a
vezetékek.
16.12 Hardver kulcs
A hardver kulcs általában másolás, ritkábban
hozzáférés elleni védelmet szolgál. Egy szoftver felhasználójának ritkán
érdeke az ilyen másolásvédelem, emellett ez kellemetlenségekhez vezethet
(a hardver kulcs zavarhatja a normális működést vagy üzemeltetést, a
kulcsok elveszthetők, ellophatók, megsérülhetnek). Érdemes tudni, hogy
számos hardver kulcsos terméknek van kulcs nélkül működő változata is,
vagy forgalomban van olyan szoftver, amely inaktiválja a kulcsot.
16.13 Közös jelszó, jelszó átadása
Azért szokás ilyen eszközökhöz folyamodni,
mert valamely adatot szeretne valaki mással megosztani. Ehhez a
megoldáshoz nyilván azért fordul a felhasználó, mert más, jobb utat nem
ismer. Pedig van! File/könyvtár hozzáférési jogok megadása,
levélátirányítás stb. Csak egy kis fáradságot kell venni rendszereink
megismeréséhez.
16.14 Levélben kért jelszó
Sok rendszergazda hajlandó (elektronikus)
levél, telefon/fax stb. kérésre megváltoztatni egy felhasználó jelszavát.
Vagy letörli a jelszót (az account jelszó nélkül marad), vagy
titkosítatlanul elküldi. Természetesen privilegizált account esetében
ilyet senki nem tesz. Ez az utóbbi időkig talán rendjén is volt, de nem
lehet így a hálózati vásárlások korában.
16.15 Maximált file-méret
Számos rendszerben (a legtöbb Unix alatt)
szokás a maximális file-méret alkalmazása. Az aktuális korlát ismerete
hiányában a felhasználó többször nekirugaszkodik letölteni egy 120 MB-os
file-t, s 100 MB-nál rendszeresen elakad. Ezzel alapos nem kívánatos
hálózati forgalmat generál.
16.16 Quoták hiánya
Az elérhető maximális tárterületekre nézve
számos rendszernél nem alkalmaznak korlátozásokat, vagy a rendszer
ideiglenes felhasználásra tárterületet biztosít. Ekkor pl. egy felhasználó
által kiadott Unix parancs, 'cat * > valami' pillanatok alatt betöltheti a
rendszer teljes kapacitását.
16.17 RAID technológia
A technológia eredetileg olcsó, relatíve kis
kapacitású diszkek együttes használatát jelentette a teljesítmény és a
megbízhatóság (hibatűrés) fokozására. Az idevonatkozó szabvány RAID 1, 2,
... 5 kategóriát (ma 7-ig, ill. egyes kombinációk definiáltak 10, 53, stb.
néven is) határoz meg (a szintek más-más teljesítményt és hibatűrést
biztosítanak). A diszkekre/ről egyszerre történhet írás, olvasás,
ellenőrző összegek és/vagy redundáns adatfelvitel révén. A technológia
általánosan alkalmazott szerverek esetében, de munkaállomások és PC-k
esetében is (nagygépeknél más módszereket találunk). Rendszerint speciális
RAID kontroller kártyát használnak, ritkábban tisztán szoftveres
megoldást. Az SCSI diszkek használata az általános, de IDE RAID csatolók
is forgalomban vannak. Egyes esetekben a (meghibásodott) diszkek leállás
nélkül cserélhetők (hotplugable disks). A módszer ma már sok esetben
azonos vagy nagyobb hibatűrés és teljesítmény mellett is olcsóbb, mint a
diszktükrözés (azaz minden adat két független diszkre történő írása).
16.18 Rendszeradminisztrátori account
A rendszeradminisztrátori (supervisori) és
más privilégizált accountot csak akkor és arra használjuk, amit máshogy
nem lehet megoldani, és csak arra az időre jelentkezzünk be így, amíg az
adott feladatot elvégezzük. Nyilvánosan elérhető gépről ne használjunk
ilyen accountokat (sőt hálózatról sem). Az előbbiek igazak nemcsak az
ilyen accountok használatára, hanem minden privilegizált hozzáférésre (pl.
a Unix 'su' parancs használatára). Ne írjunk és fogadjunk levelet
privilegizált accountról/ra (használjunk ún. mail alias-t), s ez érvényes
talk, IRC és egyéb konferencia programokra, s természetesen minden
játékprogramra is.
16.19 A rendszer erőforrásainak terhelése
Önön szórakoztatásunkra elindítunk néhány
dekoratív X alkalmazást ('X szemet') és a rendszer erőforrásainak nagy
részét ezzel lekötöttük. Majd kiadunk egy keresést (find parancsot Unix
alatt), s a rendszer majdhogynem megáll. A példákat sorolhatnánk.
16.20 Reset gomb
Többfelhasználós rendszert nyugodt szívvel
kapcsolhat ki vagy indíthat újra egy átlagfelhasználó, ha lefagy a
terminálja. Persze ezt nem teszi, ha erre nincs módja, vagy csak különös
nehézségek árán kivitelezhető. Egyesek nem tudnak ellenállni a
szünetmentes tápegység kikapcsológombjának. Az igazi megoldás a fizikai
védelem - eltávolítani, beragasztani minden nyomógombot :-). Persze
elárulhatjuk a felhasználóknak az alternatív lehetőségeket is (pl. keresse
a rendszergazdát, vagy hogy mely billentyűkombinációval próbálkozzon
ilyenkor).
16.21 Rossz jelszavak
A felhasználók előszeretettel alkalmazzák
(ha csak tehetik) az alábbi típusú jelszavakat:
- saját login név, név, becenév, családtag,
barátnő neve;
- saját telefonszám, gépkocsi rendszám;
- munkakörre, munkahelyre, hobbira vonatkozó
szó.
Vannak népszerű jelszavak. Egyes felmérések
szerint kevesebb mint ezer jelszó lefedi a világon számítógép eléréshez
használt jelszavak több mint felét.
16.22 Single user üzemmód, magára hagyott
szerver
Mint fent említettük az elveszett jelszó
ürügyén: a magára hagyott gépek jelszavai nagyon sok esetben feltörhetők
(a PC-k setup jelszava általában - közismert módon - feltörhető, sok Unix
esetében az ún. single user mód nem kellően védett). Itt adott esetben
csak az operációs rendszer upgrade-je, cseréje, a hardver le- vagy
elzárása esetleg cseréje szolgáltathat megoldást - vagy a biztonsági rés
tudatával kell együtt élnünk.
16.23 Szoftver upgrade
Rengeteg hiba forrása mind az upgrade, mind
annak hiánya. Példák az upgrade lehetséges problémáiból (nem csak
operációs rendszerre, de elsősorban arra gondolunk):
- számos bevált alkalmazásunk nem működik;
- interoperábilitási, kompatibilitási
problémák bukkanhatnak fel;
- meg kell tanulnunk használni az új
rendszert;
- ismeretlen jelenségek léphetnek fel, hibák
bukkanhatnak elő;
- mentésünk visszaállításánál problémák
léphetnek fel.
Az operációs rendszerek és az összetettebb
alkalmazások biztonsági szempontból sohasem tökéletesek. Számos hibát
észlelnek a fejlesztők, melyekre vagy javításokat (patch) adnak ki, vagy
az újabb változatokból már kiiktatják a hibákat. Az újabb változatok is
tartalmazhatnak persze biztonsági lyukakat, de ezek még nem kerültek
napvilágra, így a támadók is kisebb eséllyel használják ki ezeket.
16.24 Superuser account megszerzése
Az illetéktelen machinációk elsődleges célja
a superuser jogosítvány megszerzése. Innen már minden elérhető.
16.25 Szalámi technika
Egy pénzügyi program kerekítési szabályainak
s hasonlóknak apró megváltoztatása, majd a töredékösszegek folyamatos
átirányítása, állandó bevételhez juttathatja a címzettet. Klasszikus
eljárás a pénzforgalom megcsapolására.
16.26 A visszaállítás nehézségei
Gyakori eset, hogy a mentés akkurátus
pontossággal végrehajtott, széfben őrzik a mentést, ... Azonban amikor
(akár évek múltával) először következik be adatvesztés, a visszaállítás
nem sikerül. Ritka, hogy ilyen esetben a visszaállítást valahogy ne
lehetne végül is megoldani, de megoldhatatlan esetekre is számos példa
volt.
17. Az Internet
biztonságáról, speciális biztonsági kérdéseiről
Az Internet központi menedzsment nélküli
heterogén hálózat. Elvben bárki vagy bármely szervezet csatlakozhat hozzá.
Nincs az egész Internetre nézve kötelező elv, felhasználási és biztonsági
politika. Az Internet és számos még lazább, szabadabb szervezetű hálózat
(UUCP, Fidonet stb.) között átjárók vannak. Az Internethez szervezetek,
cégek, magánszemélyek csatlakoznak, nagy számú szabadon elérhető
dokumentumot, programot, adatot helyeznek el rajta.
Azonban az Internet nem menedzseletlen,
valamint korlátozott központi adminisztráció működik: menedzselt
hálózatok, menedzselt elérési pontok, egymással együttműködő
menedzsmentek, szervezetek vannak. Egyes részein többé-kevésbé szigorú
felhasználási politika van érvényben, s vannak általánosan elfogadott
normák, szokások.
Cégek csatlakozásánál a legelőször felmerülő
kérdések egyike a biztonság. Azonban a nyilvánvaló előnyökkel szemben a
biztonsági okokból való elzárkózásnak nemigen lehet realitása. Egyrészt
lehet az Internet felett virtuális privát hálózatot, vagy az Internet
elérést mint multiprotokoll hálózat részét biztosítani, ill.
magánhálózaton az Internet elérést virtuális hálózatként biztosítani. A
biztonság bár fontos, az aktuális és potenciális Internet forgalom igen
kis része követelne nagyobb biztonságot.
Az Internet sajátos jelenség a
számítógép-biztonság számára, azonban nem rendelkezik egyedi, máshol nem
fellelhető problémákkal. A tipikus gondok:
- nagy számú, egyfelhasználós PC
csatlakozása;
- növekvő számú dial-up kapcsolat;
- gyenge védelemmel és laza menedzsment
alatt működő szerverek;
- az általánosan terjedő lehallgatás.
A problémák egy része ún. 'a végfelhasználó
vessen magára, ha' jellegű, de az ilyenek jelenthetnek szélesebb körű
veszélyt is. Pl. nem biztonságos node-ok 'r' láncolata (lásd az előző
fejezetet), ellenőrizetlen szoftverek terjesztése.
A problémák másik része a kialakulatlan
üzleti tranzakció-mechanizmusokra vezethető vissza, bár itt nagyon gyors a
fejlődés.
Egy sajátos gond - melynek jelentőségét
messze eltúlozzák -, az ún. unreliable tranzakciók, azaz nem garantáltan
eredményes, nem garantáltan nyugtázott, nem garantált idejű tranzakciók. A
túlzás abban van, hogy az Internet alternatívák sem mindig teljesítik az
igényeket sokkal jobban. Egy tőről fakadó probléma az elérhetőség
garantálása: a garantált válaszidők, a sávszélesség, a rendelkezésre állás
biztosítása (availability, denial of service).
Egy másik sajátosság, hogy az Internet
forgalma monitorozható, nincs mód a packet header információk
titkosítására. Így nyomonkövethetők az adott helyen áthaladó hálózati
csomagok: melyik host mely hosttal állt kapcsolatban? Más módon, de a
levelezés is részben figyelhető: ki, mikor, kivel levelezett? Bár az
üzenetek és csomagok tartalma titkosítható, jelentős információszivárgás
van e tekintetben. Ez alapvetően zavarja a magán és az üzleti élet
titkosságát, sérthetők személyes szabadságjogok és üzleti titkok (az
előzőekre az angol a 'privacy' kifejezést alkalmazza, megfelelő magyar szó
nem ismeretes). Megállapítható ill. valószínűsíthető, hogy pl. ki, milyen
hálózati boltokkal lépett kapcsolatba, milyen hálózati magazinokat
olvasott stb. Ma még e kérdésekre nincs gyakorlati megoldás (az Internet
hálózati protokolljának, az IP jelen verziójának felváltása szükséges).
Mondják, hogy az Interneten nincs mód arra,
hogy választ kapjunk levelünk megérkezésére. Ez így nem igaz, bár vannak
korlátok. Ellenben más hálózaton esetleg arra sincs mód, hogy a
potenciális címzettnek e-mail-t küldjünk - ugyanis az adott hálózaton
nincs az illetőnek címe.
Az Interneten több igen gyenge pont van,
ilyenek a névszervizek, a route-olás és a menedzsment, az utóbbi kettő
technikailag túlmegy az átlag felhasználó érdeklődésén, de a
névszervizeket nem hagyhatjuk szó nélkül. Az Internet két
leghasználatosabb névszerviz szolgáltatása a Domain Name Service (DNS) és
az X.500. Az X.500 meglehetősen erős biztonsági elvárásoknak is eleget
tesz, de a DNS nem. Míg az X.500 nem kritikus szerviz az Interneten (más
hálózaton gyakran az), addig a DNS igen. Míg a route-olás problémái
elsősorban a szerverek elérhetetlenségében jelentkeznek a DNS-é nemcsak
abban. A DNS-sel könnyen visszaélhet üzemeltetője: levelezésünket
megfigyelheti, leveleinket elfoghatja, illetéktelen helyre átirányíthatja
(bár ezt gyakorlatilag a levelezőrendszerek üzemeltetői is megtehetik,
nagyipari méretben a DNS-t elkonfigurálva lehet a levelezést figyelni). A
DNS egy jó példa arra, hogy az Interneten a titkosság (privacy) mennyire
függ a rendszer- és hálózatmenedzserektôl (ill. elvben e menedzserek
tevékenységének ellenőrzésétôl).
Az új Internet szabványok a biztonság minden
terén kielégítővé teszik az Internetet - sajnos az implementációk még nem
érhetők el a gyakorlatban. Új szabványok vannak az Internet alsó
szintjének (az IP szintnek) biztonságossá tételére, s új ajánlások,
javaslatok, részben szabványok a magasabb szintekre.
Az Internet speciális biztonsági
problematikája kevésbé érinti a felhasználókat, mint a hálózati
menedzsereket és rendszergazdákat. A problémák elenyészően kis része fakad
magából az Internet biztonsági gyengeségeiből, zömük a felhasználók
tudatlanságából, elemi szinten elkövetett hanyagságaiból származik. A nem
reális üzenettovábbítás nagy része menedzsmentbeli hiba.
Már korábban is mondtuk, hogy az Internet
globális biztonsága lépést tartott és tart az igényekkel; sok mindent nem
teljesít, de a felhasználás céljai és a biztonság kellő arányban állt és
áll. Manapság viszont a felhasználás új területeire tevődik a hangsúly.
Mindazonáltal nem hiszem, hogy az Internet fejlődésének biztonsági
problémák gátat vethetnének. Az Internet fejlődése biztonsági szempontból
a motorizációhoz hasonlítható: a balesetek ellenére nem fogunk lemondani
sem a motorizáció, sem az Internet áldásairól.
18. Jogi és etikai
kérdések
A biztonság számos ponton kapcsolódik a
joghoz és az etikához: gondatlanság, szándékos rongálás, illetéktelen
elérés, számítógépes bűnözés, elektronikus adatcsere, aláírás hitelessége,
szerzői érdekek stb. Néhány gondolat, megjegyzés:
1. Általában nem igaz, hogy ne lenne - a
magyar jog szerint - büntetőjogi felelősség és szankcionálási lehetőség a
számítógépes visszaélések, illetéktelen behatolás, vírus terjesztés és más
hasonló cselekedetek ellen. Az más kérdés, hogyha a felelősségrevonás
elmarad.
2. A szerzői jogvédelem területén más
hangzik el az illetékes hatóságok, hivatalok (pl. Szerzői Jogvédő Hivatal)
és érdekvédelmi szervezetek részéről (pl. BSA), mint ami a jogszabályokban
áll. Azt lehet mondani, hogy a jog és a gyakorlat nincs összhangban. Itt
inkább az etikára kell hagyatkoznunk, mint a jogra, valamint más fejlett
országok jogi szokásait követni.
3. Számos érdeksértés fog bekövetkezni a
viszonylag ellenőrizetlen média, az Internet jóvoltából. Látnunk kell
azonban, hogy a jelenségek alapvetően nem térnek el más médiában (pl. a
sajtóban) megszokottaktól. Számos kérdés jogilag szabályozatlan, de talán
nem a jogi szabályozásnak kell élen járni. Érdemes megjegyezni, hogy az
Internet nemzetközi hálózat, melyre az USA-nak alapvető befolyása van.
4. Megjegyezzük, hogy az Egyesült Államok
export szabályozása nagyban gátolja a titkosítási eljárások és az ezeket
alkalmazó hardver és szoftver nemzetközi elterjedését, exportját.
5. A digitális aláírás sokkal elfogadhatóbb,
mint azt banki, vállalati és államigazgatási szakemberek általában
gondolják. A terjedését azonban tévhitek is gátolják.
6. A felhasználási és biztonsági politikák
hiányoznak, vagy nincsenek, vagy nem nyilvánosak (egy kirívó eset: a
HBONE).
7. A felhasználási politikákban vagy azok
mellett célszerű 'etikai szabályzatokat' is megfogalmazni és közzétenni.
8. A hálózati etikett (bár ilyen nem igazán
létezik, hanem vannak illemszabályok elektronikus fórumok használatára és
üzemeltetésére, Web publikálásra, 'ftp-zésre', elektronikus levelezésre
stb.) nálunk még nem közismert. Az Internet vagy az elektronikus levelezés
használata nyilván megelőzi a rájuk vonatkozó etikai normák
megismerésesét. Az oktatás, tájékoztatás alapvető és állandó feladat.
9. Legyünk toleránsak, még a normák
megszegőivel is! Legyünk óvatosak, ne hozzunk elhamarkodott ítéleteket! A
normák megszegőit érdemes figyelmeztetni, de ha van erre illetékes személy
(az illetékes postamester, hálózatgazda) akkor bízzuk arra. A
figyelmeztetés a helyes út: ez jobb lehetőségek meg/bemutatásából álljon.
10. Az erőforrások illegális használata
leginkább fiatalokra jellemző, az Internet betörési kísérleteinek nagy
részét egyetemisták követik el. Úgy érzem, hogy a sértettek, az adott
rendszerek üzemeltetőinek felelőssége ilyen esetekben nagyobb, mint a
játékból/tudásvágyból próbálkozóké.
11. Mindig nyílt biztonsági politikát
folytassunk! Ne kezeljünk titkosan semmit, ami valójában nem titkos,
személyiségi jogokat nem sért. Az oktatásban se titkoljuk el a rendszerek
gyengeségeit, az ismert biztonsági lyukakat. A lyukakat felszámolni kell,
nem eltitkolni.
12. A biztonsági eseményekről mindig
értesítsük az illetékeseket (sajnos ez - bár kivételesen - sértődésekhez
vezethet).
13. A rosszul szervezett menedzsment, a
kellő szabályozás hiánya az illetékességek terén állandó problémák forrása
lehet. A célok meghatározásánál és a menedzsment kereteinél kell kezdeni
minden szabályozást. Minden szempontból jól felépített rendszer jó
menedzsment mellett minimálisra csökkenti a problémák számát.
14. Az egészség és a környezet védelmében is
fontos feladatok vannak. Itt kiemelkedő hiányosságok tapasztalhatók.
forrás: Fellner Jakab
Szakközépiskola és Szakiskola
|