Napjainkban egyre több hír jelenik meg a különböző, "mindenremegoldástnyújtó" spamszűrő technológiákról, az egyszerű felhasználó már alig bírja kapkodni a fejét. A világ összes elektronikus levelének 60%-a tartozik a kéretlenek kategóriájába, ezért a probléma megoldására 2003 márciusában elindult – az IETF által támogatott – Anti-Spam Research Group (ASRG) tevékenysége, és részben ezen csoport munkájának köszönhetően 2003 őszére több cég is előrukkolt saját anti-spam megoldásával, amelyeket mostanság vizsgálnak.
A klasszikus: szűrés tartalom alapján
A régebbi megoldásoknál a szűrés alapja a beérkező levelek tartalma volt, azonban szakemberek szerint ez nem adott megfelelő bizonyosságot, ezért a legtöbb új megoldás az elektronikus levelek fejrészét (header) veszi már górcső alá, ezáltal a forrás, a feladó hitelessége alapján döntenek az alkalmazások arról, hogy besorolható-e az adott levél a spam levelek csoportjába. A tartalom alapján való szűrésnél született megoldások között van olyan is, amelyik a Bayes-tételt veszi alapul, egyszerű szabályokat meghatározva a döntéshez. A "click" szócska a spamek 79,7%-nál fordult elő, téves riasztást (false positive) 1,2%-nál okozott csak Paul Graham egyik felmérésénél, aki az említett tétel által leírtakat követve határozott meg szabályokat. A pontosításhoz a feltételes valószínűségen alapulva hozzá lehet még tenni, hogy pl. "ha a levélben van élénk piros (#F00000) színnel írt szócska is a 'click' szócska mellett, akkor már szinte biztos, hogy spammel van dolgunk."
A legújabb technológiák azonban már másról szólnak…
Hirdetés
Levelezési szokások mint szűrési szempont
A University of California (Los Angeles) két kutatója, P. Oscar Boykin és Vwani Roychowdhury által javasolt szűrés alapja az a feltételezés, hogy az emberek többnyire egy szűk társadalmi csoporttal állnak kapcsolatban, azaz van X darab cím, amiről kapnak és amire küldenek levelet, azaz e címek megbízhatónak tekinthetők és csak a többi, "idegen" címet kell megvizsgálni, esetlegesen szűrni. Sajnos ez a megoldás nem nyújt még védelmet a meghamisított címekről (spoofing) érkező levelek esetében – ahol a támadó ebből a bizonyos X darab cím egyikére cseréli le az általa írt levélben a fejrészt (header) –, azonban az is igaz, hogy a címek meghamisítása (spoofing) csak kis hányadát adják az összes spam levélnek.
Minősítés a feladó ellenőrzése alapján
A Microsoft "CallerID", az AOL "Sender Policy Framework" (régi nevén "Sender Permitted From"), a Pan-Am Internet Services "Designated Mailers Protocol", Hadmut Denisch "Reverse Mail Exchange" nevű technológiája nagyjából ugyanazt az ötletet építi be, amely szerint a legjobb megoldás a spam kiszűrésére az, ha a vevői oldal ellenőrzi, hogy a beérkező levélben feltüntetett feladó valójában kicsoda. Ehhez nem kell mást tenni, minthogy a vevő külön – a technológiától függő – bejegyzést (szabályt) ad hozzá a DNS-szerverben a saját levelező szerverének neve és IP-címe mellé, amelyben megadja, hogy az ellenőrzés során érvénytelennek tekintett beérkezett levelekkel mi legyen. Az ellenőrzéshez nyilvánvalóan szükség van tehát egy olyan procedúrára, amely során a vevői oldal megnézi a DNS-szerverben (domain és IP-cím párok között), hogy a beérkezett levél feladója és a kiírt IP-cím valóban összetartozó párt alkotnak-e. Ha ez nem áll fenn, akkor máris lehet tudni, hogy a címet a támadó, a spam küldője meghamisította. A szűrés akkor nem működik jól, ha a spam küldője nem lép fel támadóként, azaz nem cseréli le a feladó címét egy levélben (másnak kiadva magát), hanem létező domain és IP-cím felhasználásával ír levelet (van saját levelező szervere, ami be is van jegyezve pontosan a DNS-szerverbe). Erre az esetre azonban a már előzőleg említett technológia lehet a gyógyír, amely a felhasználó levelezési szokásait alapul véve (tehát megnézve, hogy többnyire kiktől kap és kiknek küld levelet) végez szűrést, de az ilyen fix címről érkező levelek ellen jó az egyszerű levelezési szabály szerkesztése is, ami révén ki lehet szűrni (filter) és automatikusan törölni lehet a beérkezett kéretlen leveleket.
A Yahoo! és a "DomainKeys"
A különböző technológiák közül a BME IK ITSec Csoport érdeklődését a Yahoo! "DomainKeys" nevű megoldása keltette fel – egyből felcsillant a szemünk, amikor megláttuk, hogy az nyilvános kulcsú kriptográfiát is használják. A Yahoo! oldalán talált vázlatos leírás alapján annyit lehet tudni, hogy szintén az elektronikus levél fejrésze (header) a célpont, amelyhez egy digitális aláírást rendel hozzá az elküldés pillanatában a feladó titkos kulcsa felhasználásával. A feladó titkos kulcsához tartozó nyilvános kulcsot a vevő a DNS-szerverből (a feladó adatainál megadott külön bejegyzésből) tudja majd lekérdezni a tervek szerint, és annak segítségével a vevő ellenőrizheti a digitális aláírást. Az ellenőrzés során talált hiba esetén a vevő levelező szerverén beállított szabály (policy) alapján rendelkezik a beérkezett levél további sorsáról. A jelenlegi vizsgálatok befejezése után a Yahoo! egy nyílt forráskódú (open source) alkalmazásként tenné elérhetővé a felhasználók számára az új technológiát a különböző levelezőrendszerekhez, amely képes lenne előállítani és kezelni a "DomainKeys" kriptográfiai műveleteihez szükséges adatokat.
Kérdéses pontok
A tartalom alapján szűrő alkalmazások megbízhatósága a mai megoldások alapján nagyjából ismert lehet a felhasználók számára. Az újabb technológiáknál viszont nem ismerünk éles üzemben készített statisztikai adatokat, így összehasonlítani még nem lehet a technológiákat, azonban már az eddigi leírások alapján is felmerül több kérdés. A könnyebb érthetőség kedvéért röviden szólni kell az elektronikus levelek felépítéséről, különös tekintettel a fejrészre (header) vonatkozólag.
Az IETF RFC 822 szabványában (az IETF RFC 2822 elődje) a következő áll:
Standard for ARPA Internet Text MessagesA.3. COMPLETE HEADERS
A.3.1. Minimum requiredDate: 26 Aug 76 1429 EDT
From: Jones@Registry.Org
Bcc:or
Date: 26 Aug 76 1429 EDT
From: Jones@Registry.Org
To: Smith@Registry.OrgNote that the "Bcc" field may be empty, while the "To" field is required to have at least one address.
Az IETF RFC 2822 szabványában (az IETF RFC 822 utódja) a következőt tartalmazza:
The only required header fields are the origination date field and the originator address field(s). All other header fields are syntactically optional.field: orig-date 1 (min number)
field: from 1 (min number)orig-date = "Date:" date-time CRLF
from = "From:" mailbox-list CRLF
Az elektronikus levelek fejrésze tehát legalább ezen adatokat (a Date: és a From: kezdetű sorokat) kell, hogy tartalmazza. Ezeket egyébként egy esetleges támadó saját kénye-kedve szerint meg tudja változtatni. A fejrész tartalmazhat ezeken kívül más adatokat is, sőt, ahogy a levél vándorol a hálózaton, úgy egyre több bejegyzés kerülhet még hozzá.
Egy levél fejrészének forráskódja a feladói oldalon:
From: "=?iso-8859-2?B?U3phYvMgwXJvbg==?=" aron@ik.bme.hu
To: baronsz@freemail.hu
Cc: aron@ik.bme.hu
Subject: Test
Date: Fri, 19 Mar 2004 09:29:21 +0100
[…]
Egy levél fejrészének forráskódja a vevői oldalon:
Return-Path: baronsz@freemail.hu
Delivered-To: aron@ik.bme.hu
Received: from fmx1.freemail.hu (fmx1.freemail.hu [195.228.242.221]) by hera.ik.bme.hu (Postfix) with SMTP id B2F201ED0D for; Fri, 19 Mar 2004 13:06:09 +0100 (CET)
Received: (qmail 75938 invoked from network); 19 Mar 2004 13:08:42 +0100
Received: from fm11.freemail.hu (195.228.242.211) by fmx1.freemail.hu with SMTP; 19 Mar 2004 13:08:42 +0100
Received: (qmail 27534 invoked by uid 3053231); 19 Mar 2004 13:07:05 +0100
Date: Fri, 19 Mar 2004 13:07:05 +0100 (CET)
From: =?ISO-8859-2?Q?Szab=F3_=C1ron?= baronsz@freemail.hu
Subject: Test
To: "Szabó" "Áron"
[…]
A beérkezett levél több Received: kezdetű sorral is bővülhet, amelyek közül a legelsőt (amihez a feladónak ténylegesen "köze van") kell ellenőrizni a DNS-szerverben a domain és IP-cím egyezése szempontjából. A digitális aláírás használatánál is – a "DomainKeys" esetében – a feladás pillanatában értelemszerűen nem szerepelnek még a levél fejrészében a Received: kezdetű sorok, ezért a digitális aláírásnál a lenyomat (hash) csak a Date:, From: kezdetű sorokra vonatkozhat (legalábbis nem valószínű, hogy a "DomainKeys" beleveszi a többi elemet, ha az RFC 2822 sem tekinti kötelezőnek a használatukat – bár biztosat még nem lehet tudni a működéséről, ezért ez csak feltételezés).
Kérdéses pont tehát a "DomainKeys" esetében, hogy pontosan mire is fut le a lenyomatképzés, milyen bemenő adatok alapján áll elő a digitális aláírás. Ez azért is érdekes, mert ilyen feltételek mellett – tehát csak a From: és a Date: a bemenő adat, amit a támadó is be tud állítani a levél fejrészében a digitális aláírás alapján – egy esetleges támadó, ha elkapja az üzenetet, akkor egyszerűen kiszedheti a digitális aláírást és a hozzá tartozó összes fontos sort a fejrészből (header), majd ezeket mind bele tudja pakolni egy teljesen más üzenet, levél fejrészébe (header) úgy, hogy a vevő a feladót hitelesnek ismeri fel. A cím meghamisítása (spoofing) tehát továbbra is gondot jelenthet és ezzel a kriptográfia alkalmazása teljesen feleslegessé válik.
Kérdéses az is, hogy kell-e külön technológia a nyilvános kulcsok eléréséhez, kell-e a DNS-szervert kiegészíteni és aztán mindenféle kéréssel "nyaggatni", ha egyszer már régen kitalálták az ITU-T X.500-as ajánlásnál a jól működő névtárakat, tanúsítványtárakat (directory), amelyekhez ráadásul van szabványos lekérdezési protokoll is (LDAP a 389-es porton keresztül).
Az is érdekes kérdés lehet, hogy pontosan milyen felhasználói tevékenység alapján állítódik elő a digitális aláírás a levélnél (pl. "intelligens kártya bedug + PIN kód beüt" kombináció), ugyanis ha a számítógépen tárolt titkos kulcsról van szó (ami ráadásul még nincs is jelszóval, PIN kóddal védve), akkor egy esetleges, a számítógépre feltelepült vírus, féreg (saját SMTP motorját használva) minden gond nélkül tovább tudja magát küldeni a címlistában szereplő személyeknek, akik pedig nyugodt szívvel fogják megnyitni a leveleket, ugyanis a fejrészben szereplő digitális aláírást az ellenőrzés során hitelesnek találták.
Van olyan kérdés is, ami arra irányul, hogy vajon mennyire terheli le az egész ellenőrzési procedúra a levelező szervert, mennyi ideig tart ez a folyamat. Egy átlagos levélnél a digitális aláírás ellenőrzése egy másodpercen belüli érték lehet (kulcs hosszától is függ), de mindenképpen érzékelhető a lassulás. Sok-sok levél esetében azonban ez túlzott mértékű leterhelődéshez vezethet, és könnyen DoS (Denial of Service) támadás célpontjaivá válhatnak a cégek levelező szerverei, a levelezés megbénulása pedig a külvilággal való kapcsolat elvesztését és áttételesen akár súlyos anyagi károkat is okozhat.
A vírusvédelem, a tűzfalak, a spam leveleket szűrő megoldások integrálódása miatt az anti-spam technológiák is egy komplex rendszer részét képezik majd, amelyek révén remélhetőleg – a szinergiákat, egymásra hatásokat kihasználva – egyre hatásosabb vírusirtók, megbízható spam-szűrők és a mostaninál biztonságosabb tűzfalak kerülhetnek a felhasználókhoz, elősegítve az Internet biztonságos használatát.
Szabó Áron (BME IK ITSec Csoport – IHM-együttműködés)
