Biztonságos E-mail Windows környezetben
Telbisz Ferenc
KFKI RMKI Számítógép Hálózati Központ és MATÁV PKI-FI
Az egyik legrégebbi és legelterjedtebb Internet szolgáltatás az elektronikus levelezés. Kedveltségét mutatja az is, hogy a böngészőkhöz hasonlóan számos ingyenes E-mail kliens van, sőt még ingyenes szerverek is léteznek. Ugyanakkor az E-mail gondatlan használata komoly veszélyforrás lehet. Manapság a vírusok és "férgek" (worms) leginkább elektronikus levelek útján terjednek. Ezért célszerű megvizsgálni az általánosan elterjedt Windows alatt használható ingyenes levelező klienseket (Eudora, Netscape és Mozilla, Outlook Express, PC-Pine, Pegasus, stb.), azok megfelelését az elvárható szolgáltatási és biztonsági követelményeknek, valamint a biztonságos használatukat.
Az elektronikus levelek számos fontos és megőrzendő dokumentációt, információt tartalmaznak, ezért az elolvasott levelek biztonságos tárolásáról is kell gondoskodni. Az asztali munkahelyeket (desktop workstation) általában a Windows operációs rendszer valamilyen változatával használják. A windows dominanciája világviszonylatban 90% felett van, ami ugyan egyetemi, kutatóintézeti környezetben valamivel alacsonyabb, de a Windows még ott is messze domináns rendszer. Mivel az asztali munkahelyekhez általában mások is hozzáférnek, és mivel a Windows file védelme nem tekinthető kielégítőnek, a leveleknek az asztali munkahelyen való tárolása semmiképpen sem tekinthető megfelelő megoldásnak. Ehelyett két megoldás kínálkozik. Az egyik megoldás a leveleknek valamilyen szerveren való tárolása, ahol a hozzáférés megfelelően ellenőrzött és biztonságos, a másik megoldás a laptop-on való tárolás, ami máig megőrizte a PC személyes jellegét. Ez utóbbinál azonban kockázatot jelent a gép lehetséges ellopása, amikor a rajta levő adatállományok illetéktelen kezekbe kerül(het)nek. Bár ez ellen is készítettek már védelmi rendszereket, amelyek ezt általában az adatok megsemmisítésével érik el, ezek azonban meglehetősen speciális megoldások és elterjedtségük is alacsony. Az első esetben hozzáférési protokolként IMAP-ot kell használni, a másik esetben a POP3 protokoll használata a célszerű.
Egy másik fontos szempont a mobilitás kérdése, az, hogy a levelekhez a tulajdonosuk bárhonnan hozzáférhessen. A fenti esetben ez az interneten keresztül az IMAP protokoll használatával lehetséges, a laptop használatánál pedig a levelek mindig "kéznél" vannak. Továbbbi szempont lehet még a több szerver, ill. a több személyiség lehetőségének a kívánalma. Végül általában az is szükséges, hogy telefonos "dial-up" územmódban is lehessen használni.
Az 1 Táblázatban feltűntettük az általánosan használt ingyenes levelező kliensek adatait. Látható, hogy ma már mindegyik korszerű változata eleget tesz a vázolt követelményeknek, tehát mindenki nyugodtan használhatja a "kedvenc" kliensét. A biztonsági követelmények teljesítésére később térünk vissza.
|
Levelező kliens |
IMAP |
POP3 |
Multipop |
Több IMAP szerver |
Több Személyiség |
Dial-Up |
|
Eudora V5.x Light [1] |
IMAP vagy POP3 |
- |
- |
- |
+ |
|
|
Eudora
Sponsored [1] |
+ |
+ |
+ |
+ |
+ |
+ |
|
Netscape V4.x [2] |
IMAP vagy POP3 |
- |
+ |
+ |
+ |
|
|
Netscape 7 [3] |
+ |
+ |
+ |
+ |
+ |
+ |
|
Outlook
Express V5.x [5] |
+ |
+ |
+ |
+ |
+ |
+ |
|
PC-Pine V4.4x |
+ |
+ |
+ |
+ |
+ |
+ (1) |
|
Pegasus 4.x |
+ |
+ |
+ |
+ |
+ |
+ |
(1) Csak helyi SMTP és IMAP/POP3 szerverrel
(pl. Mercury v3.32 [7])
A legalapvetőbb kockázati
tényező a jelszavak ellophatósága. A lokális hálózatok (LAN)
alapvetően "broadcast" jellegűek: minden üzenet eljut
minden csatlakoztatott géphez. Egy rosszindulatú programozó programmozhatja úgy
a hálózati csatlakozóját, hogy ezek az üzenetek a gép memóriájába is bejussanak
és olvashatók legyenek. Az egyes operációs rendszerek között csak annyi a
különbség, hogy ezt könnyebb vagy nehezebb-e megtenni.
Fokozott kockázatot jelent azonban a távoli bejelentkezés, amikor az üzenetek sok közbenső hálózaton haladnak át, ahol mindütt lehetnek rosszindulatú felhasználók is, de különösen veszélyes lehet a csatlakozási hálózat. Ez szintén lehet broadcast hálózat, különösen a szélessávú internet hozzáférésnél pl. egy kábel modemes csatlakozásnál. Mindez azért igen veszélyes, mert így rosszindulatú illetéktelenek is igen könnyen megszerezhetik a hálózaton nyíltan küldött felhasználói azonosítókat és jelszavakat. Ilyen módon pedig nemcsak a saját, egyébként talán semmi titkosat nem tartalmazó adatainkhoz férnek hozzá, hanem mások adataihoz, sőt esetleg a rendszerekhez is. Tehát a nem védett jelszavak mások számára is komoly koczkázatot jelenthetnek.
Az internet protokollok kialakulásakor az elsődleges szempont az volt, hogy az amerikai fegyveres erőknek hibatűrő adatátviteli rendszert biztosítson a hálózat komoly sérülései, pl. masszív atomcsapások esetén is. Az adatok biztonságát valószínűleg a hozzáférési helyek ellenőrzésével, a lehallgatás akadályozásával vélték megoldani. Később, amikor az internet protokollok a nyilvános használatba is bekerültek, az első felhasználói a kutatói, egyetemi szférából kerültek ki, viszonylag szűkkörű és jóindulatú felhasználók voltak. Azóta viszont sok minden megváltozott:
- Az interneten forgalmazott információ fontosabb, értékesebb és jobban védendő lett.
- Az eredeti felhasználáshoz képest az alkalmazások köre lényegesen kiterjedt, pénzügyi, üzleti, politikai, technikai, stb. információcserére is kiterjedten használják.
- A felhasználók köre is megváltozott, nemcsak kutatók, oktatók használják, hanem igen széles körben, és megjelentek a rosszindulatú felhasználók is
Az első hacker-ek talán elsősorban intellektuális játéknak tekintették a betörést az információs rendszerekbe, a következő fázisban talán valamiféle tüntetés volt a céljuk, felhívni az emberek figyelmét az Internet, az operációs rendszerek sebezhetőségére, napjainkban tevékenységük leginkább a terroristákéra emlékeztet, céljuk támadás, rombolás.
A kezdeti Internet óta megváltoztak a hálózati struktúrák, hálózati technológiák is. Valamikor lényegében csak dedikált pont-pont kapcsolatok voltak, Ezek is lehallgathatók, de nem egyszerűen, és nem észrevehetetlenül.
Nem ringathatjuk magunkat nyugalomba azon érv alapján, hogy a tűzfal mögött biztonságban vagyunk. A közelmúlt statisztikái szerint érdekes tény, hogy a Cisco adatai szerint vállalati körben a támadások 60 - 80% a szervezeten belülről történik. A támadók lehetnek rosszindulatú, sértődött munkatársak, vagy olyan korábbi behatolók, akik már valamilyen "hídfőállást" építettek ki, és egy darabig csak figyelnek és gyűjtik az információt annak érdekében, hogy minél pusztítóbb támadást tudjanak indítani.
Hogyan védekezhetünk ?
A védekezésre a fizikai hálózat megfelelő struktúrájának a kialakítása és titkosítási eszközök állnak rendelkezésre:
A repeater-ek és a bridge-k bármely csatlakozásukon kapott csomagot az összes többi csatlakozásukra továbbítják. A switch-ek portjához VLAN-okat (Virtuális LAN) rendelhetünk hozzá, és ekkor az üzeneteket csak azokra a portjaikra továbbítják, amelyhez rendelt VLAN-okhoz az üzenet küldője is tartozik. Ilyen módon az üzenetek nem terjednek korlátozatlanul egy lokális hálózatban.
A legalapvetőbb védekezés a jelszavak védelme. Egy ellopott jelszó segítségével nagyon sok mindenhez hozzá lehet férni. A jelszavak elrejtése az adatátvitel titkosításával történhet. A titkosításhoz két dolog szükséges, egyrészt egy titkosítási algoritmus, ami két függvényből áll, az egyik a kódolást, a másik - ennek inverze - a dekódolást végzi. Ezen kivűl szükséges még egy kulcs, amit az algoritmus használ. A mai korszerű titkosítási eljárásokban az algoritmus ismert, csak a kulcs a titkos. A kulcs ismeretében a dekódolás elvégezhető, kulcs nélkül a dekódolás gyakorlatilag lehetetlen. Vannak egy és kétkulcsos eljárások. A titkosításhoz egy rövid bevezető található a Netscape egyik weblapján [8].
Az egy kulcsos eljárásoknál problémát jelenthet a kulcsok kicserélése, különösen távoli partnereknél. A kétkulcsos eljárásoknál két kulcs van, egy titkos és egy nyilvános. A nyilvános kulccsal kódolt üzenetet csak a titkos kulccsal lehet dekódolni, így azt megfejteni csak a titkos kulcs birtokában lehet. Van értelme a fordított eljárásnak is. Ha a titkos kulccsal kódolt digitális aláírást a nyilvános kóddal dekódolva a küldő digitális aláírását kapjuk meg, bizonyosak lehetünk abban, hogy az üzenet attól származik, aki a titkos kód birtokában van. A Netscape esetében ilyen a célokra kidolgozták a két kulcsos SSL (Secure Socket Layer) eljárást, ill. protokollt, amit az IETF még kissé finomított és szabványosított. Ez a szabvány a TLS (Transport Layer Security) nevet kapta. (RFC 2246) [9]
A titkosítás és jelszó védelem használata a levelező klienseknél
Ma már szinte valamennyi ingyenes levelező program is ismeri a TLS/SSL eljárást. Az SSL/TLS protokollokat használó E-mail kliensek más "portokat" használnak, mint a hagyományos E-mail kliens programok. Ezt a 2 Táblázat mutatja
|
Hagyományos IMAP port |
143 |
|
IMAP TLS/SSL fölött |
993 |
|
Hagyományos POP3 port |
110 |
|
POP3 TLS/SSL fölött |
995 |
Az elterjedt E-mail kliensek közül csak a Pegasus program nem ismeri a jelszó és az adatvédelem titkosítását, azonban ez is védetté tehető a stunnel program [10] segítségével. A stunnel program egy "virtuális" mail szervert létesít a helyi gépen (localhost), és ezt továbbítja a szerver védett portjára. A stunnel program természetesen használható egyéb E-mail kliensek védelmére is.
A jelszó védelem használatáról részletes útmutatók találhatók több helyen is, magyarul pl. a KFKI RMKI Számítógéphálózati Központ web lapján is [11].
Természetesen a leveleinket úgy is megnézhetjük, hogy bejelentkezünk a szerverre és valamilyen Unix-Linux alatti levelező programmal (pl. Pine) nézzük meg a leveleket. A bejelentkezéshez ebben az esetben is mindig jelszó védett terminál emulátor programot használjunk. Erre kiválóan alkalmas a Putty program [12]. Ha a csatolt file-okat át akarjuk hozni egy Windows operációs rendszerrel működő PC-re, akkor az FTP kliens programok, mint a Total Commander (azelőtt Windows Commander), ws_ftp, stb helyett szintén használhatunk ingyenes jelszó védett programot, a Windows Safe Copy (WinSCP) programot [13], vagy a Secure iXplorer programot [14].
A jelszavak illetéktelenek által való megszerzése csak azon kockázatok egy részét jelenti, amelyek a saját és mások adatainak, ill. teljes rendszereknek a biztonságát is veszélyeztetik. Hasonló kockázatot jelentenek a virusok és férgek (worms) is, amelyek leggyakrabban E-mail-lel érkeznek, vagy attachmentekben, vagy akár a levél szövegében is scriptek, Visual BASIC (VBS) programok, vagy egyéb végrehajtható kódrészek formájában. Furcsa paradoxon, hogy míg egy gép erőforrásaihoz való hozzáférést, a programok végrehajtását általában jelszóval védett azonosítóval történő bejelentkezéshez kötjük, az E-mail-ben érkezett programok végrehajtásánál nincsen ilyen ellenőrzés, hiszen azokat a "megbízható", autentikált helyi felhasználó aktivizálja. A legveszélyesebb attachment tipusokat (exe, scr, vbs, stb.) a legtöbb intézmény virus védelme kiszűri, de marad számos olyan attachment, amelyek kiszűrése gyakorlatilag lehetetlenné, ill. értelmetlenné tenné a kommunikációt, mint a doc, html, jpg, stb kiterjesztésű csatolt file-oké, amelyekben azonban szintén lehetnek, vagy éppen vannak is végrehajtható kódrészek.
Alapvető biztonsági szabály, hogy ismeretlentől kapott attachmenteket nem szabad megnyitni, és az ismert és megbízható helyről érkezettet is csak akkor ajánlatos, ha ennek érkezését a küldő jelezte ill. a szándékot megerősítette. Az attachment-eknél zavaró lehet, hogy a Windows az alapbeállítás szerint nem mutatja az ismert típusú file-kiterjesztéseket. Ennek veszélyeiről és a beállítás megváltoztatásáról rövid leírás található a http://www.kfki.hu/(hu)/cnc/virext.html URL-en. Sajnos, a levél szövegében elhelyezett, alkalmasint rosszindulatú kódrészek ellen ez sem jelent védelmet. Igy veszélyes lehet a HTML formátumú levél is, amelyben szintén lehetnek rosszindulatú script-ek, program részek. Viszonylag védelmet jelent ezek ellen, ha a levelező kliens külön utasítás nélkül nem kezeli a HTML formátumú levelet, ill. text file-ként mutatja meg, mint a PC-Pine, vagy saját értelmezője van, ami nem értelmezi a HTML levélben levő script-eket, mint a Pegasus. Ugyanilyen értékű, ha a Netscape-ben, vagy a Mozillá-ban letiltjuk a script-ek végrehajtását az E‑mail-ben. Legveszélyeztetebbek a Microsoft Outlook Express-t használók, mert az automatikusan, figyelmeztetés nélkül végrehajtja a levelekben, sőt a subject-ben levő utasításokat is. Ezen kívül az Outlook Express-t használók veszélyeztetettsége azért is kiemelkedően magas, mivel elterjedtsége miatt szinte minden virus és féreggyártó ehhez a levelező programhoz készíti a "termékeit".
Az "E-mail roaming" probléma
E-mail roaming alatt azt értjük, hogy az utazó felhasználó utazása közben ugyanúgy folytathatja a levelezését, mintha a megszokott otthoni környezetében lenne. A levelek elolvasása esetén ez teljesen megoldott, de nem így a levelek küldésénél. Itt az lenne az alapvető követelmény, hogy ha valakinek az otthoni E-mail címe valaki@otthon.tld1, akkor tovbbra is ilyen feladóval szeretné a leveleit feladni, és nem akarki@valahol.tld2.
Ez több akadályba ütközik. Ismernie kell az utazása során Internet hozzáférést nyujtó szolgáltató (ISP) smtp szerverének domain nevét vagy IP címét. Ha smtp szervernek ezt jelöli meg és beirja feladóként (from mező) a valaki@otthon.tld1 címet, az ISP smtp szervere általában visszautasítja a levelet azon okkal, hogy idegen levelek továbbítását (mail relay) nem végzi el. Ha smtp szerverként (smart host) az otthoni ISP szerverét akarja használni, az általában szintén visszautasítja a levél továbbítását ismét csak azon okkal, hogy idegen levelek továbbítását (mail relay) nem végzi el, t.i. a feladó gép IP címe (amit DHCP-vel kapott), idegen hálózat címtartományában van. Megoldásként marad az, hogy a saját gépére telepít egy smtp szervert, ami közvetlenül a címzetthez továbbítja a levelet. Csakhogy az utazó gép domain nevének ilyen esetben általában nem szabályszerű regisztrálása miatt (reverse domain mapping) a címzettnél esetleg alkalmazott spam védelem miatt ez sem mindig működik.
További két megoldás lehetséges. Az egyik a terminál bejelentkezés valamelyik otthoni szerverre, ha ezt a különböző közbenső tűzfalak megengedik. A másik a WebMail [15] használata, amikor egy böngészőt használunk az IMAP vagy POP3 mail szerveren levő levelek elolvasására és levelek küldésére. Ez csak akkor működik, ha a WebMail telepítve van az otthoni E‑mail szerverre, ebben az esetben azonban biztosan használható. Sajnos, a WebMail felhasználói felülete az E‑mail klienseknél megszokottnál primitívebb ill. kényelmetlenebb.
A helyzet általános, minden helyzetben alkalmazható megoldása jelenleg nem létezik, az az utazó felhasználó ügyeskedésére van bízva.
Összefoglalásként megállapíthatjuk, hogy vannak megfelelő eljárások a jelszó védelmére és titkosításra, valamint körültekintő E-mail használat esetén az egyéb veszélyek is elfogadható szintre csökkenthetők.
[4] mozilla.org: http://www.mozilla.org/
[6] Pine Information Center: http://www.washington.edu/pine/
[7] Pegasus Mail: http://www.pmail.com/
[8] Introduction to Public-Key Cryptography: http://developer.netscape.com/docs/manuals/security/pkin/
[9] T. Dierks, C. Allen: RFC 2246, The TLS Protocol Version 1.0. January 1999.
[10] stunnel - multiplatform SSL tunneling proxy: http://www.stunnel.org/
[11] http://www.kfki.hu/(hu)/cnc/emailpw/E-mail.html
[12] PuTTY: a free Win32 telnet/ssh client: http://www.chiark.greenend.org.uk/~sgtatham/putty/
[13] WinSCP: http://winscp.vse.cz/eng/
[14] i-tree.org - Delphi Free Software: http://i-tree.org/
[15] WebMail: http://jwebmail.sourceforge.net/