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 fo 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 utóellenőrzést nevesebb archívumok, disztribúciós helyek esetén nem tartjuk elengedhetetlennek. A vérfertő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ó).

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

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

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.

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.

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 nagy-gé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). Lehetoleg 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 lehetoségekkel gyakran ‘élnek is’ a (kevésbé képzett) rendszergazdák.

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 észszerű 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!

Másolás védelem

A másolás védelem a szoftver gyártók klasszikus eszköze az illegális (pontosabban az o é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).

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