Masarykova univerzita Fakulta informatiky
Detekce spamu Diplomová práce
Jaroslav Kortus 2006
Kopie listu zadání práce
Prohlášení
Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
............................................................
Poděkování Rád bych na tomto místě poděkoval vedoucímu práce, Ing. Mgr. Zdeňku Říhovi, za jeho připomínky při tvorbě práce. Dále bych chtěl velmi poděkovat rodičům, jejichž obětavá podpora mě provázela po celou dobu studií.
Shrnutí a klíčová slova Práce pojednává o metodách prevence a detekce spamu, představuje jejich hlavní myšlenky a ukazuje nejčastěji používané metody a příklady jejich použití. Klíčková slova: SPAM, HAM, filtr, email, detekce spamu, prevence.
Obsah 1 Úvod.......................................................................................................................................6 1.1 Definice SPAMu.............................................................................................................6 1.2 Motivace k boji proti spamu...........................................................................................6 1.3 Přehled............................................................................................................................6 2 Vývoj spamu...........................................................................................................................7 3 Prevence..................................................................................................................................9 3.1 Greylisting.......................................................................................................................9 3.2 SPF..................................................................................................................................9 3.2.1 Zhodnocení SPF....................................................................................................13 3.3 SenderID.......................................................................................................................13 3.4 DomainKeys.................................................................................................................13 3.4.1 Ověření DomainKey podpisu................................................................................14 3.4.2 DomainKey policy................................................................................................14 3.4.3 Vytvoření DomainKey podpisu............................................................................15 3.4.4 Zhodnocení DomainKeys......................................................................................16 3.5 DNS seznamy (Blacklist)..............................................................................................17 3.5.1 Detekce zdroje spamu pomocí seznamů v DNS...................................................17 3.5.2 Zhodnocení DNS seznamů....................................................................................18 3.6 URL seznamy................................................................................................................18 3.6.1 SURBL..................................................................................................................19 3.7 Ostatní způsoby.............................................................................................................20 3.7.1 HashCash (www.hashcash.org).............................................................................20 3.8 Právní ochrana..............................................................................................................22 4 Detekce spamu......................................................................................................................23 4.1 Black&White seznamy.................................................................................................23 4.2 Vyhledávání řetězců......................................................................................................23 4.2.1 Regulární výrazy...................................................................................................23 4.2.1.1 SpamAssassin................................................................................................24 4.2.1.1.1 Postup hodnocení emailu (verze 3.0.5)..................................................26 4.3 Statistické filtry.............................................................................................................27 4.3.1 CRM114................................................................................................................27 4.3.1.1 Třídění...........................................................................................................27 4.3.1.2 Učení.............................................................................................................29 4.3.1.3 Další třídící algoritmy...................................................................................30 4.3.2 DSpam...................................................................................................................31 4.3.3 Bogofilter..............................................................................................................31 4.4 Kontrolní součty zpráv..................................................................................................32 4.4.1 Pyzor a Razor........................................................................................................32 4.4.2 DCC.......................................................................................................................33 5 Praktické testy.......................................................................................................................34 5.1 Zhodnocení praktických testů.......................................................................................35 6 Aplikace................................................................................................................................37 6.1 Motivace.......................................................................................................................37 6.2 Praktické poznatky........................................................................................................37 6.3 Obecný popis řešení......................................................................................................38 6.4 Praktická implementace................................................................................................42 7 Závěr.....................................................................................................................................45 8 Rejstřík..................................................................................................................................46 9 Použitá literatura...................................................................................................................47
1
Úvod
1.1
Definice SPAMu
SPAM je původně označení pro masovou konzervu (populární hlavně v USA). Ve světě elektronických komunikací se tento pojem vžil pro obtěžující emailovou komunikaci. Spam se většinou definuje jako hromadný a nevyžádaný email. Obě podmínky jsou důležité, protože nevyžádaný nemusí být hned obtěžující (např. poptávka po zboží), hromadný mohou být běžné emailové konference [1]. V dalším textu zmíníme i definici z právní úpravy České republiky, která se mírně liší. Obecně se dá říci, že lidé označují jako spam všechno, co je obtěžuje nebo nezajímá. Pro užitečné emaily se vžilo označení HAM.
1.2
Motivace k boji proti spamu
Na škodlivosti spamu se nepodílí jen to, že koncového uživatele může zbytečně obtěžovat. I když ani to není zanedbatelný faktor. Čas, který uživatel stráví s rozpoznáváním a čtením spamu, se dá vyjádřit v penězích. Pokud tyto náklady sečteme za všechny zaměstnance ve společnosti za rok, dostaneme nemalé náklady, které byly vynaloženy na zcela neproduktivní činnost. Navíc je ekonomicky nevýhodné, pokud uživatelé řeší spam každý na svém vlastním pracovním stroji. Studie uvádí, že náklady na takové řešení oproti řešení spamu na serverech jsou skoro dvakrát vyšší (217 oproti 132 amerických dolarů, ručně bez použití softwaru až 718 USD ročně)[2]. Na ztrátách způsobených spamem se však podílí i další náklady. Především náklady na výpočetní techniku, ukládací a přenosové kapacity. Rovněž se sem promítají investice do softwarového vybavení určeného pro detekci a odstraňování spamu. Takové náklady se odhadují na 50 miliard amerických dolarů ročně. Navíc stále stoupají. V USA stál spam v roce 2003 10 miliard dolarů, zatímco v roce 2005 už to bylo 17 miliard [2]. Návratnost investic do softwaru na filtrování spamu se odhaduje na 30 až 220 % v závislosti na velikosti firmy a množství přijímaného spamu [3]. Avšak spam není jen nebezpečí toho, že koncový uživatel se dozví o zvýhodněné půjčce a promrhá tak čas placený zaměstnavatelem. Existují i další formy škodlivého emailu, který také chceme odfiltrovat. Jsou to například různé podvodné emaily, které se snaží uživatele přesvědčit, že musí ihned začít klikat na nabízené odkazy. Ty pak mohou simulovat třeba firemní intranet a od uživatele získávat cenné informace.
1.3
Přehled
V následujících kapitolách si ukážeme, jaké prostředky máme dnes k dispozici k tomu, abychom mohli se spamem bojovat. Představíme si metody, které nám umožní spamu předcházet tím, že se snažíme rozesílatelům spamu znesnadnit práci a chránit se tak už před samotným příjmem spamu. Dále si ukážeme metody, které v současnosti pomáhají odhalovat spam v našich poštovních schránkách a představíme nejčastěji používané programy, které zmíněné metody využívají.
Úvod
6
2
Vývoj spamu
Spam je ve své podstatě reklama. Tuto reklamu je potřeba vhodným komunikačním kanálem doručit co možná nejvíce příjemcům. Komunikačním kanálem je v tomto případě Internet a zejména služby elektronické pošty založené na SMTP protokolu. Návrh tohoto protokolu [4] měl v době svého vzniku za cíl přenášet elektronickou poštu spolehlivě a efektivně. Nebyly do něj zahrnuté žádné bezpečnostní prvky, autentizace uživatelů, žádné ověřování. Klient i server si navzájem důvěřovali. Z toho se vyvinuly i implementace tohoto protokolu na poštovních serverech ve stejném duchu. Když chtěl uživatel poslat email přes síť jinému uživateli, stačilo najít libovolný poštovní server (třeba úplně cizí), ohlásit mu svou identitu (tj. kam vracet chybové zprávy a co doplnit do hlaviček) a požádat o doručení emailu na určenou adresu (nebo několik adres). Poštovní server takovou zprávu převzal a v případě, že zpráva nebyla pro uživatele v jeho síti, zprávu předal dalšímu příslušnému poštovnímu serveru. Ten zjistil ze svých vnitřních směrovacích tabulek pro email nebo pomocí MX záznamů v DNS. Rozesílání spamu bylo v této době velice snadné, ale základna příjemců velmi omezená (tzn. méně peněz). Možnost připojení k Internetu nebyly zdaleka tak rozšířené jako dnes. Elektronickou poštu bylo možné odeslat a také přijmout na zlomku strojů, na kterých je to možné dnes. Bylo velmi snadné spam ve schránce poznat a pokud jej chodí více, zařadit si adresu odesílatele na černou listinu. Rozesílatelé spamu se tenkrát ještě nenamáhali falšovat adresu odesílatele. Pokud ani to nepomohlo, šlo snadno zakázat jeho IP adresu. Uživatelů elektronické pošty přibývalo a s nimi i příliv peněz pro distribuci nevyžádané reklamy. Rozesílatelé hledali nové způsoby, jak obejít blokace na poštovních serverech, začali falšovat svou identitu (falšovat adresy v SMTP příkazech). Pro rozesílání používali druhy připojení s dynamicky přidělovanou IP adresou (typicky využili nabídky poskytovatelů nabízejících připojení přes vytáčené linky). Protože ostatní servery je častěji odmítali, využili poštovní server poskytovatele připojení, který svým klientům umožňuje odesílání elektronické pošty mimo síť. Poskytovatelé reagovali zavedením limitů na počet emailů poslaných při jednom připojení. Ujednání zakazující (mimo jiné) takové chování je dnes u všech větších poskytovatelů připojení. Uživatelů přibývalo ještě více. Rozšiřovaly se i možnosti připojení k Internetu. Rostl počet IP adres a i objem spamu. Přestalo být nadále možné udržovat si černé listiny na všech serverech a poštovní servery byly z benevoletního režimu (všechno pro všechny, tzv. open relay) přepnuty do režimu, kdy od ostatních přijímají poštu pouze pro své klienty (typicky klienti ve stejné doméně, zákazníci). Začalo ubývat možností, kdy bylo možné říci libovolnému poštovnímu severu, aby doručil poštu od cizích lidí cizím lidem. Dnes je stav, kdy je poštovní server nakonfigurován v „open relay“ režimu, považován za vážné pochybení správce takového serveru. Rovněž software pro poštovní servery je dnes psán podle hesla „secure by default“, čili volně přeloženo zabezpečený hned po instalaci. S dalším rozšířením dostupnosti připojení přibylo hodně klientů na silnějších spojích typu ADSL a kabelových přípojkách. Uživatelé s žádným nebo jen mizivým ponětím o rizicích spojených s připojením počítače do globální sítě se začali stávat terčem (nejen) rozesílatelů spamů. Pokud běžné poštovní servery jejich poštu odmítaly předávat nebo je servery poskytovatele limitovaly, bylo na čase
Vývoj spamu
7
si nové servery nějak „vyrobit“. Nechráněné počítače domácích uživatelů pro ně představuje přímo ráj. Z takto úspěšně napadených počítačů si vytváří vetší celky, sítě (botnets). Tyto sítě pak využívají k distribuci svých spamů, dokonce s nimi i obchodují. Jedna taková sít může mít běžně kolem 50 tisíc počítačů [5]. Tato síť rozesílatelům spamu umožňuje rozesílat velké množství emailů s prakticky mizivými náklady. Jediné, co musí aktivně sami dělat, je řízení takové sítě. Náklady na konektivitu pro rozesílání přenáší na své oběti. To si vynutilo vznik černých listin i pro tyto počítače, resp. jejich IP adresy. S rostoucím objemem spamu, který uživatelé dostávali do svých schránek, vyvstala potřeba automatické detekce takových zpráv na základě obsahu emailu. Uživatelé a i poskytovatelé začali používat detekční a filtrační mechanizmy, nejdříve založené na regulárních výrazech a černých listinách. Rozesílatelé spamu ale nikdy nespí a sledují vývoj softwaru, který proti nim bojuje. Vědí, která pravidla proti nim budou nejčastěji použita a volí takové tvary slov, aby se jim vyhnuli. Prokládají písmena ve slovech tečkami (v.i.a.g.r.a), nahrazují písmena jinými podobného tvaru (vlagra), provádí dělení slov (via gra), nahrazují písmena číslicemi (l0an) a podobně. Reakcí na to byly statistické filtry. Pracují na základě pravděpodobnosti výskytu jednotlivých slov v užitečných emailech a spamu. Použitím těchto filtrů se velmi zvýšila úspěšnost detekce spamu. To si samozřejmě vyžádalo reakci druhého tábora a začaly se objevovat spamy, ke kterým rozesílatelé přidávají neškodný běžný text (např. úryvek novinové zprávy) nebo množinu vybraných slov, která jsou většinou ve statistických filtrech považována za slova patřící do užitečných emailů. Tímto postupem filtr „otráví“ (filter poisoning), úspěšnost filtrování touto metodou se sníží. Vylepšení této metody se nabízí při použití HTML emailů. HTML umožňuje volit barvu, velikost a pozadí písma. Rozesílatelé spamu napíší své reklamní sdělení (uživatel ho uvidí, filtr ho zpracuje), ke kterému nakonec přidají opět množinu neškodných slov, tentokrát však v barvě shodné s pozadím (uživatel nic neuvidí, filtr to ale taktéž zpracuje). Obdobných metod skrytí v HTML existuje samozřejmě více. Existují filtry, které dokáží podobná barevná kouzla odhalovat (např. SpamAssassin). V poslední době (2005-2006) s postupným masovým nasazováním statistických filtrů přešli rozesílači spamu k jiné formě vyjádření. Celou svou reklamu posílají jako jeden malý obrázek (velikost kolem 8 kB). Podobný email jen na základě analýzy jeho textu nevyhovuje typickému vzorku spamu, statistický filtr jej tedy raději za spam neoznačí. Je patrné, že náklady na detekci spamu stále více převyšují náklady na jeho rozesílání. Je to důsledek toho, že původní velmi liberální (co se bezpečnosti a autentizace týká) návrh protokolu je tak široce implementován, že přechod na jiný bezpečnější je dnes již v praxi nerealizovatelný. Stále se tedy musíme potýkat s tím, že kdokoliv se může vydávat za kohokoliv a snažit se nám poslat email a to prakticky zdarma (žádná platba za jednotlivou zprávu). Právě na fakt, že email je prakticky zdarma, se snaží zaútočit systémy využívající určitého druhu „platby“. Platbou v tomto smyslu se nemyslí pouze peníze (tam by to bylo velmi problematické), ale hlavně obětování výpočetního výkonu nebo času (nutnost přečíst si vygenerovaný email a odpovědět na něj dle instrukcí). Uživatel může takto ke svému emailu připojit důkaz toho, že obětoval určitý prostředek za to, aby byl jeho email doručen a přečten.
Vývoj spamu
8
3
Prevence
S rozvojem elektronické komunikace a narůstajícím počtem nevyžádaných sdělení se lidé naučili, že není nejvhodnější veřejně vystavovat svoji emailovou adresu. Automatičtí roboti takové adresy vyhledávají a ukládají do spamerských databází. Nezveřejňovat vůbec také není řešení. Proto se lidé dnes uchylují ke změnám ve tvaru emailových adres tak, aby je člověk poznal a mohl na ně odeslat email (byť nemůže na takovou adresu přímo klikat). Často je takový tvar adres vidět na diskuzních fórech - např. uživatel (at) doména (tečka) cz. Hlavně u jazykově specifických náhrad mají automatizovaní roboti smůlu. Spoléhat se však jen na takovouto „ochranu“ by určitě nestačilo. Další typ ochrany využívá skutečnosti, že takový běžný rozesílatel spamu musí poslat veliké množství zpráv v co nejkratším čase. Prodloužením doby, kterou potřebuje k rozeslání spamu, můžeme příjmu takové zprávy zabránit.
3.1
Greylisting
První způsob je zpoždění již na transportní vrstvě. Při navazování spojení na SMTP port první spojení odmítneme (nepotvrdíme). To si vyžádá v běžné implementaci a u všech „normálních“ poštovních serverů opakování pokusu o spojení. Pokud máme zaznamenáno, že jeden takový pokus již proběhl, spojení necháme běžným způsobem navázat. Druhou možností je zpoždění až na úrovni poštovního serveru. Spočívá v tom, že zprávu odmítneme jako dočasně nedoručitelnou s chybovým kódem 4xx ([6], např. 450 - Try again later). Učiníme tak co nejdříve, typicky po příkazu RCPT TO:. Běžné poštovní servery takto nedoručenou zprávu doručí později, zpravidla za několik minut. Takové zpoždění je ale pro hromadného rozesílatele nevyžádaných zpráv příliš velké a rozesílací software se opakovaným doručováním nezabývá. Můžeme dokonce zajít ještě dál a zvolit způsob, který vyžaduje, aby odesílatel svým způsobem potvrdil, že se jedná o člověka a ne o automat. Přijatý email nedoručíme, ale pouze uložíme a vygenerujeme automatickou odpověď, ve které odesílatele žádáme, aby na tento email odpověděl. Pokud odpoví, zařadíme ho na seznam ověřených odesílatelů (typicky dvojici IP adresa - odesílatel) a email doručíme. Při dalším kontaktu již zprávy mezi těmito dvěma subjekty prochází bez zdržení. Projekty, které se takovým řešením zabývají lze nalézt například na http://mimo.gn.apc.org/gps/, http://isg.ee.ethz.ch/tools/postgrey/, http://projects.puremagic.com/greylisting/.
3.2
SPF
SPF je zkratka pro Sender Policy Framework. Tento systém zavádí několik mechanizmů pro kontrolu, zda server posílající zprávu s odesílatelem (SMTP obálka) z dané domény je k tomu oprávněn. Takové oprávnění zjišťuje za pomoci DNS systému. Existují dvě možnosti záznamu SPF informací v DNS. První a do budoucna preferovaný je způsob zápisu pomocí SPF záznamu, který má syntaxi jako dnes používaný TXT záznam. Bohužel ne všechny DNS servery a knihovny takový záznam dokáží zpracovávat. Proto je zaveden i náhradní způsob -
Prevence
9
zaznamenání SPF informací do TXT záznamů. Pokud existují oba dva typy záznamů (SPF i TXT), musí být shodné. Pokud se neshodují, jedná se o chybu a zpracovávání končí. Ukažme si, jak vypadá SPF informace v TXT záznamu. Použijeme příkaz dig a získáme informace z domény gmail.com. $ dig txt gmail.com gmail.com. 300 IN TXT "v=spf1 ip4:216.239.56.0/23 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ?all"
Co nám získaná data sdělují: ➢
v=spf1 určuje použitou verzi SPF zápisu
➢
ip4:x.y.u.v/zz určuje z jakých rozsahů IPv4 adres mohou pocházet zdroje pro rozesílání emailů z účtů končících „@gmail.com“
➢
?all říká, že u ostatních IP adres není jednoznačně určeno, zda mohou email z této domény posílat
Vyhodnocení těchto dat bude probíhat takto: ➢
Vyhodnocení probíhá vždy zleva doprava. Pokud je TXT záznamů více, spojí se za sebe bez (!) mezer mezi nimi. Výsledek vyhodnocení je první vyhovující volba.
➢
Zkontrolujeme zda verze odpovídá přesně verzi, kterou „umíme“. V současnosti je v návrhu pouze první verze.
➢
Následují další tzv. mechanizmy a modifikátory . Zápis mechanizmu má dvě části - nepovinný prefix (+, -, ?, ~), mechanizmus (all, include, A, MX, PTR, IP4, IP6, exists). Většina mechanizmů dovoluje ještě rozšíření za dvojtečkou a upřesnění pomocí lomítka. Modifikátory existují dva (redirect, explanation) a rozšíření pro definici maker (ukážeme dále). Modifikátor je standardně „+“.
Významy modifikátorů: ➢
+ = specifikované záznamy jsou oprávněné posílat poštu z této domény
➢
- = specifikované záznamy určitě nejsou oprávněné posílat poštu z této domény
➢
? = o specifikovaných záznamech neříkáme žádný verdikt (zůstáváme neutrální)
➢
~ = o specifikovaných záznamech neříkáme nic jistého, ale spíše se „tváříme“ negativně
Popis mechanizmů:
Prevence
10
Název mechanizmu
Popis
příklad
all
vždycky vyhoví. Měl by se používat jako poslední
+all
include
umožňuje zahrnout zpracování pravidel uvedených v jiné doméně
+include:_spf.example.com
A
překlad domény na IP adresu (vyhledání A záznamu) souhlasí s doménou zaslanou odesílatelem
+A +A:example.com/24
MX
IP adresa odesílatele je uvedena jako poštovní +MX server pro doménu +MX:example.com
PTR
Zpětný překlad IP adresy odesílatele na jméno, provná se, zda končí stejně
+PTR
IP4
umožňuje zadat přesně IP adresu, případně doplnit CIDR notací
+IP4:10.0.0.0/16
IP6
totéž jako IP4 akorát pro IPv6 adresy
+IP6:2001:DB8::CD30
exists
ověření existence záznamu s využitím maker
-exists :%{ir}.sbl.spamhaus.example.o rg
Tabulka 3.1: Mechanizmy SPF
Zvolený identifikátor předurčuje výsledek vyhodnocení takového mechanizmu. Zatím není příliš zřejmý rozdíl mezi vyhodnocením mechanizmu s otazníkem a s vlnkou. Vysvětlíme si to na stavech, do kterých se můžeme vyhodnocením dostat. Výsledkem vyhodnocení mohou být následující stavy: ➢
„None“ - software nemůže vyhodnotit žádné SPF údaje, pravděpodobně proto, že nejsou publikované v DNS
➢
„Neutral“ - správce domény buď nemůže anebo nechce uvádět, zda daná IP je autorizována pro rozesílání emailů. Výsledek je shodný s výsledkem „None“ a software jej musí zpracovat naprosto shodně. Rozlišení je zde pouze pro informaci.
➢
„Pass“ - záznamy potvrzují, že daná identita je autorizována pro rozesílání emailů z domény
➢
„Fail“ - záznamy explicitně říkají, že daná identita není autorizována pro rozesílání emailů z domény. Další zpracování může pouze takovýto email označkovat (např. SPF hlavičkou) nebo přímo v SMTP sezení odmítnout. V případě odmítnutí je doporučené odmítnout s kódem 550 a doplňujícím vysvětlením (může být uvedeno jako explain mechanizmus).
➢
„SofFail“ - tento stav je definován jako „něco mezi“ stavy Neutral a Fail. Správce domény si nemyslí, že by taková identita (např. IP adresa) měla posílat email z této domény, avšak nechce to takto explicitně zakázat. V tomto případě by se další zpracování zprávy nemělo odmítat jako v případě Fail, ale mělo by pokračovat běžným způsobem s přihlédnutím k tomu, že zpráva nemusí být z autorizovaného zdroje (např. nasazení přísnějších filtrů dále).
Prevence
11
➢
„TempError“ - při vyhodnocování SPF došlo k dočasné chybě softwaru. Zprávu bychom měli přijmout nebo odmítnout a nechat doručení na později.
➢
„PermError“ - došlo k chybě při vyhodnocování SPF záznamů (např. syntakticky špatný záznam). Nemusí se jednat přímo o záznamy pro danou doménu, ale třeba odkazované záznamy pomocí include mechanizmů.
Na popisu stavů je o něco jasnější rozdělení mezi modifikátory „?“ a „~“. Mohli bychom třeba stanovit, že z naší domény (použijme opět gmail.com), bude možné rozesílat emaily ze všech serverů, které jsou vedeny jako doručovací servery do domény (MX záznamy). gmail.com.
300
IN
TXT
"v=spf1 mx ?all"
Všechny SPF záznamy by měly končit mechanizmem all, aby bylo explicitně zřejmé, že zpracování končí (all je vždy vyhovující mechanizmus a určí výsledný stav, pokud jej neurčí nic před ním).
Problém ale může nastat, pokud jsme velká organizace s mnoha poštovními servery a více pravidly, než se vejde do jednoho TXT záznamu (limit 512 bytů). V takovém případě musíme záznamy zveřejnit v DNS jako několik TXT záznamů (při zpracování se musí všechny spojit bez mezer za sebe) nebo použít include či redirect mechanizmy. MECHANIZMUS INCLUDE Tento mechanizmus nám umožňuje vkládat do záznamů jedné domény údaje z jiné domény. Zvlášť se to může hodit u poddomén naší domény. Záznamy SPF totiž platí vždy právě pro doménu, u které jsou uvedené a ne rekurzivně nahoru či dolů. V takovém případě můžeme použít include mechanizmus a usnadnit si tak správu takových záznamů. Zvolený název include však přímo nereflektuje způsob zpracování. Zamýšlené chování není, jak by člověk čekal, takové, že se vezmou všechny záznamy obsažené v odkazovaném záznamu a nahradí se jimi direktiva include v záznamu (typická substituce). Může se totiž stát, že by takový odkazovaný záznam mohl končit například mechanizmem „-all“ a u nás by zpracování končilo předčasně negativně. Návrh definuje chování tohoto mechanizmu následovně:
Vyhodnocení odkazovaného include záznamu
Výsledek include mechanizmu v našem záznamu
Pass
shoda
Fail
není shoda
SoftFail
není shoda
Neutral
není shoda
TempError
TempError
PermError
PermError
None
PermError Tabulka 3.2: Vyhodnocení vnořených mechanizmů
Prevence
12
Tabulka zjednodušeně říká, že pokud nedojde k chybě, nelze pomocí include nikdy dosáhnout zamítavého postoje (Fail) a identitu odmítnout. Možný je pouze pozitivní výsledek. Zde bych zdůraznil, že se nejedná o shodu typu akceptace v rámci vyhodnocení našeho SPF dotazu na autorizaci odesílatele, ale pouze o shodu v dílčím vyhodnocení mechanizmu. Uveďme příklad: gmail.com. 300 IN TXT :_spf.example.com +ip4:1.2.3.4 mx -all"
"v=spf1 -include
_spf.example.com.
"v=spf1 +ip4:1.2.3.4 -all"
300
IN
TXT
Po ověření shody na verzi vyhodnotíme rekurzivně include mechanizmus. Ten nás odkazuje na SPF záznam pro doménu _spf.example.com. Rekurzivní vyhodnocení tohoto záznamu říká, že pro IPv4 adresu 1.2.3.4 vrací Pass, pro ostatní Fail. Pokud tedy klient je z IP adresy 1.2.3.4, bude podle tabulky výsledek shoda. To znamená že na výrazu „-include:_spf.example.com“ máme shodu. Prefix „-“ říká, že shoda na tomto mechanizmu se vyhodnotí jako Fail. Klientovi z IPv4 adresy 1.2.3.4 bude autorizace odmítnuta celkovým výsledkem Fail.
3.2.1
Zhodnocení SPF
SPF je poměrně jednoduchý a efektivní mechanizmus jak poznat, že nám odesílatel s velkou pravděpodobností o své identitě (resp. doméně) nelže. Jeho úspěšnost je přímo závislá na rychlosti, jakou se mechanizmus rozšíří a kolik poskytovatelů poštovních služeb jej bude aktivně využívat. Výhodou i nevýhodou současně je, že SPF pracuje již na SMTP vrstvě. Umožňuje nám tedy odmítnout zprávu ještě před jejím přenesením přímo z SMTP příkazů (jmenovitě HELO/EHLO a MAIL FROM). To ale zároveň znamená, že nemůže zpracovávat další hlavičky, které se přenášejí v těle zprávy. Problematická je zejména hlavička From, kterou i přes SPF je velmi snadné zfalšovat. Bylo by tedy velmi vhodné při praktickém nasazení přidat ke kontrole autentičnosti zprávy i porovnání SMTP hlaviček a hlaviček emailové zprávy. Je však třeba zvážit i legitimní důvody, kdy se tyto údaje mohou lišit, zejména v případě emailových konferencí.
3.3
SenderID
SenderID je technologie velmi podobná SPF, jedná se v podstatě o nadmnožinu či rozšíření SPF. Syntaxe je úplně shodná kromě čísla verze (SenderID zavádí verze typu spf2.0/*). Problematické je, že se k ní váží patenty, které drží společnost Microsoft a jejichž uvolnění není kompatibilní s dnes velmi hojně používanými licencemi na vývoj otevřeného softwaru (GNU/GPL například). SenderID se vzdává výhody kontroly pouze na SMTP vrstvě a porovnává i hlavičky v emailech právě proto, aby předešel jejich podvržení. To s sebou nese hned několik nevýhod. Jednu představuje nutnost transportovat celou zprávu. Druhou představuje problém při přepisování hlaviček v případě emailových konferencí. Více o SenderID na http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx.
3.4
DomainKeys
S principem DomainKeys přišla společnost Yahoo. Svůj systém postavila na asymetrické kryptografii, konkrétně na digitálním podepisování heše emailu. Prvním základním kamenem je asymetrická šifra, druhým je opět systém DNS.
Prevence
13
Stejně jako u SPF či SenderID je i u DomainKeys třeba zveřejnit informace nutné k ověření autentičnosti do systému DNS. I zde se tvůrci návrhu přiklonili k dočasnému uvádění těchto informací pomocí TXT záznamů. U SPF jsme ale neměli nijak omezeno, v jakých názvech DNS záznamů musíme takové údaje uvádět. DomainKeys nás nutí použít tvar selector._domainkey.doména. Ukažme si, jak takový záznam v případě samotné společnosti Yahoo vypadá. Nejsnazší bude si poslat z yahoo email a inspekcí hlaviček zjistit, jak se zeptat DNS systému.
3.4.1
Ověření DomainKey podpisu
Návrh říká, že bychom se měli podívat na hlavičku „DomainKey-Signature“. DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To: MIME-Version:ContentType:Content-Transfer-Encoding; b=3KgdkQhQR2j6JsqbidC2lGmbrX0EtZJO/4o66EQmtaQh0rhYXWdegnznc0+HGbrER/3A tHD3yzqrj5zIfTUGpMUlHht3nqcd7Q8BhxjZpuUff2+3WadA7Ljm8VqXPh7rHq69o zbPlN3t+FMQzA0ds7rLA3pwfQLzf4lZKMPofGo=;
Pro dokončení příkladu postačí části hlavičky „s=s1024“ a „d=yahoo.com“. Bližší vysvětlení pojmů si uvedeme v popisu generování DomainKey-Signature hlavičky. Podle popsaného schématu vezmeme selektor (prefix „s=“), připojíme ho za „_domainkey“ a doménu uvedenou v hlavičce (prefix „d=“). Nyní se můžeme dotázat DNS systému, jak vypadá veřejný klíč pro uvedený digitální podpis: $ dig txt s1024._domainkey.yahoo.com s1024._domainkey.yahoo.com. 47510 IN TXT "k=rsa\; t=y\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDrEee0Ri4Juz+QfiWYui/E9UGSXau/2 P8LjnTD8V4Unn+2FAZVGE3kL23bzeoULYv4PeleB3gfm" "JiDJOKU3Ns5L4KJAUUHjFwDebt0NP+sBK0VKeTATL2Yr/S3bT/xhy+1xtj4RkdV7fVxTn5 6Lb4udUnwuxK4V5b5PdOKj/+XcwIDAQAB\; n=A 1024 bit key\;"
Pomocí tohoto klíče můžeme ověřit pravost podpisu. Za povšimnutí stojí, že údaj o doméně, která disponuje adekvátním veřejným klíčem se uvádí přímo v hlavičce emailu. To by šlo ovšem velmi snadno změnit a email podepsat podvrženým klíčem. Proto každý program, který takovou hlavičku vyhodnocuje, musí ověřit shodu domény uvedenou v DomainKey-Signature hlavičce a domény uvedené v Sender nebo From hlavičce. Pokud shodu nenalezne, nesmí takový podpis vyhodnotit jako správný. Pokud při ověřování digitálního podpisu dojdeme do stavu, ve kterém vyhodnotíme digitální podpis jako neplatný, je nutné konzultovat DomainKey politiku pro příslušnou doménu, která napoví, jak s takovým emailem naložit.
3.4.2
DomainKey policy
Jako DomainKey policy označujeme politiku, kterou organizace zvolila pro podepisování emailů systémem DomainKeys. Syntaxe je velmi jednoduchá, ukážeme si ji na příkladu yahoo.com politiky. Politika pro DomainKeys je definována pro každou doménu v TXT záznamu poddomény _domainkey (tentokrát bez selektoru). Pro získání politiky z yahoo.com provedeme následující: $ dig txt _domainkey.yahoo.com _domainkey.yahoo.com. 4168 IN TXT n=http://antispam.yahoo.com/domainkeys"
Prevence
"t=y\; o=~\;
14
Vysvětlíme si získaná data:
Obsah hlavičky
Význam
t=y
Doména je v testovacím režimu. Jedná se o nepovinnou hlavičku s právě jednou možnou hodnotou
o=~
Doména podepisuje některé emaily. Druhou možností je „o=-“, která by říkala, že všechny emaily z domény se podepisují.
n=http://antispam.yahoo.com/domainkeys
Komentář
[email protected]
(neuvedená hlavička) Emailová adresa pro hlášení nezdařených ověření podpisu (vhodné při testování). Tabulka 3.3: Součásti DomainKey-Signature hlavičky
Všechny hlavičky jsou nepovinné a v případě, že není definována žádná politika, předpokládá se jako by byla tvaru „o=~“. Zatím jediný praktický význam DomainKey politiky je ten, že správce může určit, že z domény se podepisují všechny emaily. Získáme-li pak email z domény, který není podepsaný, můžeme jej považovat za více než podezřelý.
3.4.3
Vytvoření DomainKey podpisu
Jak jsme si již uvedli, DomainKey mechanizmus je založen na asymetrické kryptografii. Budeme tedy potřebovat jeden pár klíčů - veřejný a soukromý klíč. Můžeme je vygenerovat například pomocí OpenSSL knihoven následujícím postupem: $ openssl genrsa -out rsa.private 1024 $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM
Tím do souboru rsa.private vytvoříme soukromý klíč a do rsa.public veřejný 1024bitový klíč. Soukromý klíč musíme nahrát na server, který bude podepisovat odchozí emaily, veřejný klíč musíme zveřejnit v DNS. Návrh DomainKeys (ve verzi 3) říká, že musí být podporované klíče délky 512, 768, 1024, 1536 a 2048 bitů. S rostoucí délkou klíče však samozřejmě roste i délka výsledného TXT záznamu v DNS. Při větších délkách (nad 512 bytů) můžeme narazit na problémy (ať už u přenosu nebo i v kešování velkých TXT záznamů nadřazenými DNS). Největší klíč, který je schopný se vejít do 512 bytů, je klíč délky 2048 bitů. Samozřejmě čím delší klíč, tím větší výpočetní náročnost jak na generování, tak ověření podpisu. Pro vygenerování správného podpisu pro konkrétní emailovou zprávu potřebujeme provést následující kroky: ➢
Zvolit si šifrovací a hešovací mechanizmus
➢
Převést celou zprávu do kanonického tvaru
➢
Vygenerovat heš zprávy a podepsat jej soukromým klíčem
Prevence
15
➢
Poskládat hlavičku DomainKey-Signature a doplnit nezbytné údaje
My jsme si již při generování klíčů zvolili šifrovací mechanizmus RSA. Jako hešovací mechanizmus využijeme SHA-1, jakožto zatím jediný v návrhu uvedený standard. Naší volbu uvedeme ve výsledné DomainKey-Signature hlavičce ve tvaru „a=rsa-sha1;“. Před vygenerováním heše musíme zprávu převést do jednoho ze standardních (kanonických) tvarů, které návrh definuje. Existují pro to dva postupy označené jako „simple“ a „nofws“. Děje se tak z důvodu, že zpráva může projít přes několik poštovních serverů, které podporují různé typy přenosů. Může tak dojít k transformaci emailu do jiného tvaru, přidávání hlaviček a dalším úpravám. Jakákoliv úprava nám ale zneplatní digitální podpis. Tento nový kanonický tvar však slouží pouze pro potřeby podepsání emailu a nemění podobu, ve které bude následně odeslán. Obě metody se mírně liší v zacházení s daty, ale zaměřme se na to, co mají společné. Můžeme podepisovat celý email (hlavičky i tělo) a nebo podepsat jen vybrané hlavičky (např. jen ty důležité, které se nebudou měnit) a tělo emailu. Pokud podepisujeme jen vybrané hlavičky, při kanonizaci emailu „nechtěné“ hlavičky musíme vynechat. Aby i příjemce věděl, které hlavičky jsou relevantní, uvedeme naši volbu hlaviček oddělenými dvojtečkou do DomainKey-Signature hlavičky ve tvaru „h=hlavička1:hlavička2:...:hlavičkaN;“. Mezi takto vybranými hlavičkami musí být alespoň jedna taková, podle které server určil autentičnost odesílatele (From nebo Sender hlavička). Pokud takovou volbu neučiníme, bude mít příjemce za to, že jsme podepsali všechno pod DomainKey-Signature hlavičkou. Z takto upravených dat vygenerujeme heš zvolenou metodou a tento následně podepíšeme soukromým klíčem. Výsledek připojíme do DomainKey-Signature ve tvaru „b=vygenerovanýPodpis“. K DomainKey-Signature hlavičce ještě musíme doplnit mechanizmus pro získání klíče (zatím jediný definovaný) ve tvaru „q=dns;“, selektor (v podstatě poddoména pod _domainkey.doména) ve tvaru „s=selektor;“ a doménu, ve které lze získat veřejný klíč ve tvaru „d=doména;“. Výslednou hlavičku vložíme do původního emailu na první místo a zprávu předáme doručovacímu systému.
3.4.4
Zhodnocení DomainKeys
DomainKeys jsou poměrně silný nástroj pro překonání z pohledu někoho, kdo rozesílá velké množství spamu. Jako ne příliš šťastné lze označit umisťování klíčů do TXT záznamů, čímž dochází k jejich dalšímu „znásilňování“. Autoři naštěstí umístili přímo v návrhu takové záznamy mimo již používané názvy domén vhodně zvoleným rozšířením „_domainkey“. Sníží se tak množství možných kolizí s již existujícími TXT záznamy. Stejně jako u SPF i zde bude záležet na tom, jak rychle a jak široce budou stávající správci poštovních serverů toto řešení implementovat. Nepříjemná je zejména vyšší režie při zpracování emailů způsobená jednak získáváním klíčů z DNS a navíc ještě zvýšením výpočetních nároků pro zpracování emailu. Generování hešů pro všechny příchozí emaily (vč. příloh) si může u větších organizací vyžádat nemalé nároky na hardware. Na druhou stranu nemusí ověřování DomainKey dělat přímo doručující poštovní server, ale až přímo klientská stanice. To ale klade vyšší nároky na správu takových stanic a zajištění správné funkčnosti použitého softwaru. Další slabina spočívá ve snadném způsobu DoS (Denial of Service) útoku. Potenciální rozesílatel spamu nemusí generovat správné digitální podpisy, postačí si vymyslet jeden vhodný. Na ověření
Prevence
16
neplatnosti takového podpisu bude třeba stejná režie jako u platného podpisu. I tak může být tato daň menší než pozdější analýza statistickými nástroji na obsahu emailu.
3.5
DNS seznamy (Blacklist)
Pokud se podíváme na zdroje spamu, zjistíme, že valná většina z nich pochází ze strojů připojených na ADSL a podobných „domácích“ připojeních. Jedná se jak o nedostatečné zkonfigurované stroje, tak stroje infikované trojskými koni, o nichž uživatelé ani nevědí. Jako zdroj spamu poslouží také takzvané open relay poštovní servery (pošlou email od kohokoliv komukoliv, tedy nejen uživatelům své sítě). Rovněž je možné využít špatně nastavené HTTP proxy (přístupové brány) a další. Každopádně se vždy jedná o stroj, který má nějakou IP adresu. Pokud zakážeme přístupy z výše zmíněných strojů, pravděpodobnost příjmu spamu velmi klesne. A právě o to se snaží seznamy založené (opět) na systému DNS. V praxi se označují jako „dnsbl“ a i v konfiguračních pravidlech tuto zkratku často najdeme. DNS blacklist (černá listina) samozřejmě neexistuje jen jeden, ale je jich celá řada. Liší se tím, kdo smí na takový seznam přispívat, politikou vyřazení stroje ze seznamu, parametry přístupu (např. placené seznamy) a dalšími parametry. Nejlepší je tedy si vybrat nějaký známý a pro nás důvěryhodný seznam, který se často obnovuje. Náš výběr ovlivní efektivitu odmítání spamu ještě před tím, než nám dotyčný pošle jakákoliv data, ale zároveň ovlivňuje i pravděpodobnost, že odmítneme někoho, kdo je na takovém seznamu omylem (např. nekalý konkurenční boj).
3.5.1
Detekce zdroje spamu pomocí seznamů v DNS
Jako první si zvolíme pro nás dostatečně důvěryhodný seznam, kterého se budeme dotazovat, zda má o strojích, které se nám snaží doručit poštu, nějaké informace. Mějme například odesílatele s IP adresou 1.2.3.4 a používejme jako seznam bl.spamcop.net. Princip je u všech ostatních DNS seznamů stejný. Pokud zjistíme takové spojení, vezmeme IP adresu odesílatele a její čísla „přeskládáme“ odzadu, podobně jako při vyhledávání PTR záznamu. Z adresy 1.2.3.4 tedy uděláme 4.3.2.1 a toto použijeme jako prefix před námi vybraný seznam. Celkem tedy dostaneme „4.3.2.1.bl.spamcop.net“. A nyní přijde ke slovu DNS. K takto vytvořené „adrese“ se pokusíme vyhledat A záznam (klasický překlad jména na IP adresu). Použijme opět oblíbený příkaz dig: $ dig 4.3.2.1.bl.spamcop.net ; <<>> DiG 9.2.2 <<>> 4.3.2.1.bl.spamcop.net ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34867 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
Obdrželi jsme odpověď „NXDOMAIN“, takže požadovaný záznam neexistuje. Adresa není v seznamu evidována a jeví se jako bezpečnější pro příjem emailu. Zkusme vyhledání s adresou, která se momentálně na tomto seznamu nachází - 58.140.105.139. Provedeme opět popsané otočení adresy a pokusíme se vyhledat A záznam (zkráceno):
Prevence
17
$ dig 139.105.140.58.bl.spamcop.net 139.105.140.58.bl.spamcop.net. 2100 IN
A
127.0.0.2
Vidíme, že pro adresu existuje A záznam ukazující na 127.0.0.2. Existence tohoto záznamu signalizuje, že adresa se na seznamu nachází. DNS seznamy většinou registrovanou adresu přeloží do segmentu 127.0.0.0-127.0.0.255. Tyto adresy (127.x.y.z) slouží pro odkazování na sebe sama, je tedy velmi nepravděpodobné, že by nám něco takového přišlo z Internetu. Politika dotyčného seznamu může rozhodovat o tom, jakou adresu z tohoto segmentu danému jménu přiřadí. Můžeme tak jen na základě výsledku překladu zjistit, proč se daná adresa na seznamu nachází. Může tam být proto, že posílá sama spam nebo i jen proto, že je dostatečně blízko někoho, kdo tak činí (např. ve stejné síti poskytovatele). Například SORBS (www.sorbs.net) má následující rozlišení:
http.dnsbl.sorbs.net
127.0.0.2
socks.dnsbl.sorbs.net
127.0.0.3
misc.dnsbl.sorbs.net
127.0.0.4
smtp.dnsbl.sorbs.net
127.0.0.5
spam.dnsbl.sorbs.net
127.0.0.6
web.dnsbl.sorbs.net
127.0.0.7
Tabulka 3.4: Mapování seznamů na IP adresy
Na základě zjištění registrace adresy na seznamu můžeme email rovnou odmítat (typicky 5xx kódy) nebo alespoň pozdržet doručení (4xx kódy). Konfigurace do běžných poštovních serverů bývá poměrně snadná.
3.5.2
Zhodnocení DNS seznamů
DNS seznamy jsou poměrně efektivní cestou jak odmítat spam ještě před jakýmkoliv přenosem dat. Problém představuje výběr dostatečně věrohodného seznamu, abychom minimalizovali počet omylů. Konfigurace poštovního serveru pro používání DNS seznamu bývá snadná. Problematická je konfigurace whitelistu (seznamu neškodných adres, které si v žádném případě nepřejeme zakazovat). Pokud se například náš sekundární poštovní server dostane do takového seznamu, primární server může od něj emaily odmítat, což si jistě nepřejeme. Konfigurace takového seznamu neškodných adres pak většinou spočívá v drobném „hacku“ tak, aby se takový záznam z DNS nevracel ani když existuje.
3.6
URL seznamy
Pokud se podíváme na spamy v naší schránce, zjistíme, že velmi mnoho z nich nás láká k tomu, abychom klikali na nabízené odkazy s vidinou levných léků či extra výhodné půjčky. Důležité je, že každý takový email obsahuje nějaké URL. Toto se pak stává dalším důležitým znakem spamu.
Prevence
18
Tohoto znaku si všimli autoři systémů, které pracují podobně jako seznamy u DNS, akorát využívají URL z emailů. Pokud email rozpoznají jako spam, URL z něj v systému zaregistrují, a tak umožní ostatním automaticky rozpoznat, že se jedná o spam.
3.6.1
SURBL
SURBL (www.surbl.org) je zkratka pro Spam URI Realtime Blocklists. Jedná se o soubor seznamů, přičemž každý má svou politiku zařazování a vyřazování záznamů. V současné době obsahuje tyto seznamy: ➢
sc.surbl.org - SpamCop message-body URI domains
➢
ws.surbl.org - sa-blacklist domains as a SURBL
➢
ob.surbl.org - Outblaze spamvertised sites
➢
ab.surbl.org - AbuseButler spamvertised sites
➢
multi.surbl.org - Combined SURBL list
SC těží z doručených spamů, z nichž byla nahlášena URL. Aby se takové URL dostalo do seznamu, musí ho nahlásit větší počet lidí. Do seznamu se z pochopitelných důvodů nedostávají předem vyloučená jména - např. servery poskytující prostor pro web zdarma, velcí ISP a další. WS je seznam domén, které se objevují ve spamech, ale i domén, na které odkazy z emailu přesměrovávají. Některé firmy totiž využívají registrace dočasné domény pro emailovou kampaň a odkazy z ní směrují na své domovské stránky. V tomto seznamu bude jak dočasné URL pro kampaň, tak současně i domovská stránka takové firmy. Ani do tohoto seznamu se nedostávají adresy velkých ISP, webhostingových služeb atd. OB používá svoje SpamTraps, což jsou pasti na spammery - emailové schránky, které slouží pouze pro příjem spamu. Jsou to třeba adresy uvedené na webu, u kterých je napsáno, abyste na ně nic neposílali, což automatický robot samozřejmě nepozná. V každém doručeném emailu se podívá na URL, získá z nich doménu „druhé významné“ úrovně (např. yahoo.com, ale news.co.jp) a pokud je dostatečně nová (registrovaná v posledních 90 dnech), do seznamu ji uvede. Využívá faktu, že většina „spamovaných“ domén je používána velmi krátce a poté zůstává ladem (registrace je poměrně levná záležitost). AB je seznam URL nejvíce propagovaných za posledních 7 dní MULTI je kombinací všech uvedených. Pokud se adresa nachází alespoň v jednom ze seznamů, je
Prevence
19
uvedena i tady. Pokud se nachází na více seznamech, je možné z výsledku vyhledávání odvodit, na kterých je uvedena. Vyhledávání ve všech těchto seznamech se provádí pomocí systému DNS. Nejdříve se z emailu získá „druhá významná“ doména - např. z „www33.yahoo.com“ by bylo „yahoo.com“, z „web123.bbc.co.uk“ by bylo „bbc.co.uk“. Takto získaná doména se připojí jako poddoména k názvu seznamu - např. pro SC list a doménu yahoo.com by výsledek byl „yahoo.com.sc.surbl.org“. K takto získané doméně se pomocí DNS vyhledá A záznam a opět platí stejně jako v případě DNSBL, že existence záznamu znamená přítomnost na seznamu. A záznam směřuje opět do rozsahu pro lokální adresy (127.0.0.2). V případě seznamu MULTI je výsledkem vyhledávání adresa podle následující tabulky: 2
je v sc.surbl.org
4
je v ws.surbl.org
8
je uvedena jako adresa využívaná pro „phishing“
16
je v ob.surbl.org
32
je v ab.surbl.org
64
pochází z „jp“ zdroje (viz www.surbl.org) Tabulka 3.5: Rozlišení výsledku z MULTI seznamu
Pokud je URL uvedené v prvních dvou seznamech, výsledná adresa bude 127.0.0.6 (2 + 4 = 6).
3.7 3.7.1
Ostatní způsoby HashCash (www.hashcash.org)
Tvůrci metody HashCash se nechali inspirovat situací v klasické papírové poště. Pokud chceme, aby pošta dopis doručila, musíme za službu zaplatit. Důkaz zaplacení služby je pak poštovní známka, jejíž existenci na dopise každý snadno ověří. Zabývali se myšlenkou, jak donutit uživatele, aby za svůj email také zaplatili. Platit penězi jako v běžné poště by bylo velmi náročné jak na implementaci, tak i na správu takového systému. Myšlenka tedy směřovala k alternativnímu způsobu placení. Nakonec dospěli k tomu, že by bylo dobré nechat odesílatele zprávy zaplatit výpočetním výkonem svého stroje, tj. vyřešením nějaké výpočetně náročné operace. Výsledek takové operace potom přidají k emailu jako důkaz toho, že provedli netriviální úlohu a „zaslouží“ si tedy, aby takový email dostal pozornost adresáta. Taková úloha musí být předně složitá, ale zároveň musí být do jisté míry variabilní, aby jeden výsledek nešel použít několikrát za sebou a už vůbec ne pro různé adresáty.
Prevence
20
V HashCash jako takovou metodu zvolili dosažení kolize na SHA-1 heši (160 bitů). Aby dosáhli i kýžené jednoznačnosti, generuje se heš z emailové adresy adresáta, aktuálního data (nebo i času) a náhodného 16bitového řetězce. Tyto údaje se (spolu s několika dalšími) oddělí dvojtečkou a vygeneruje se SHA-1 heš. Takto vygenerovaný otisk se poté hrubou silou doplňuje, dokud nedosáhneme na prvních pozicích otisku nuly. Podle počtu bitů, na kterých chceme dosáhnout nulových hodnot, stoupá výpočetní náročnost, a tím i relativní cena takového otisku. Jako příklad otisku si uveďme přímo hlavičku, která se uvádí v emailu. Na ní si popíšeme i význam jednotlivých částí. X-Hashcash: 1:20:060325:
[email protected]::oYK0dggGg9z0zLEn:0000000000000000000000 00000000000000000000010xX
Význam jednotlivých políček je následující: 1
číslo verze HashCash (existuje verze 0 a současná 1)
20
počet bitů, na kterých jsme dosáhli v SHA-1 nul
[email protected]
adresa příjemce
prázdné
zde je místo pro další uživatelské rozšíření, žádné ale nepoužíváme
oYK0dggGg9z0zLEn
náhodný řetězec
0000000000000000000000000000000000000000 počitadlo 00010xX Tabulka 3.6: Význam částí X-HashCash hlavičky
Kontrola takového otisku se dá snadno provést i z příkazové řádky. Stačí spočítat otisk celého obsahu hlavičky: $ echo -n\ 1:20:060325:
[email protected]::oYK0dggGg9z0zLEn:0000000000000000\ 0000000000000000000000000010xX | sha1sum 000006b7c372b2274a05faef61481ea3cbbeeb6c
-
$
Podtržené nuly je právě shoda na 20 bitech SHA-1 heše, takže otisk je validní. Pro srovnání náročnosti generování otisku uveďme ještě tabulku časové náročnosti výpočtu na 2 GHz Pentium 4 (skompilováno pro x86 a standardní distribuci verze 1.21):
Prevence
21
$ ./hashcash -sv Best minter: AMD64/x86 MMX Standard 1x2-pipe (2276646 hashes/sec) Projected average times to mint: 8 bits: 0.000 seconds (112.4 microseconds) 10 bits: 0.000 seconds (449.8 microseconds) 16 bits: 0.029 seconds 20 bits: 0.461 seconds 22 bits: 1.842 seconds 24 bits: 7.369 seconds 26 bits: 29.477 seconds 28 bits: 117.908 seconds (2.0 minutes) 30 bits: 471.633 seconds (7.9 minutes)
Aby nebylo možné vygenerovat si pro dané datum jeden otisk a s ním pak odesílat všechny emaily, měl by každý klient u sebe udržovat databázi přijatých otisků. Pokud přijatý otisk již v databázi nalezne, měl by nový odmítnout nebo se chovat tak, jako by tam nebyl. Tuto databázi je samozřejmě nutné pravidelně čistit.
3.8
Právní ochrana
V České republice upravuje rozesílání nevyžádaných obchodních sdělení zákon č. 480/2004 Sb. o některých službách informační společnosti. Tento zákon nabyl účinnosti 7. září 2004. Je vypracován v souladu se směrnicemi Evropského parlamentu a Rady 2000/31/ES ze dne 8. června 2000 (o určitých aspektech služby informační společnosti, zejména elektronického obchodního styku v rámci vnitřního trhu) a 2002/58/ES ze dne 12. července 2002 (o zpracování osobních údajů a ochraně soukromí v odvětví elektronických komunikací). Konkrétně v paragrafu 7 upravuje, za jakých podmínek je možné rozesílat obchodní sdělení. Uvádí i podmínky, které musí takové sdělení splňovat. Zejména je zde zmíněna nutnost mít předchozí souhlas adresáta se zasíláním obchodních sdělení (takzvaný OPT-IN přístup). Dále musí být takové sdělení řádně označeno jako obchodní sdělení. Rovněž sdělení nesmí skrývat identitu odesílatele a musí adresátovi umožnit taková sdělení odmítnout (jednoduchým způsobem a zdarma nebo na účet odesílatele). Obchodním sdělením se rozumí všechny formy sdělení určeného k přímé či nepřímé podpoře zboží či služeb nebo image podniku fyzické či právnické osoby. Dohled nad dodržováním paragrafu 7 je tímto zákonem svěřen Úřadu pro ochranu osobních údajů. Ten může právnické i fyzické osobě, která se proviní proti ustanovení tohoto zákona uložit pokutu až do výše 10 milionů korun. Podle webu Ministerstva informatiky se zákon nevztahuje na sdělení, která nemají obchodní povahu, jako jsou např. sdělení náboženského a politického charakteru [7]. Na druhou stranu se vztahuje nejen na sdělení pomocí elektronické pošty, ale i pomocí telefonu (nevyžádané reklamní SMS, telemarketing).
Prevence
22
4
Detekce spamu
4.1
Black&White seznamy
Velmi snadnou metodou na intuitivní rozpoznání spamu je se podívat na odesílatele zprávy. Pokud jej známe, jeho adresu si uložíme a poštovní klient to podruhé pozná sám (bílá listina - whitelist). Pokud jej neznáme, prohlédneme si letmo obsah nebo přemýšlíme, odkud se o nás dozvěděl. Je-li zpráva jen obyčejné nevyžádané sdělení, odesílatele si uložíme do seznamu „těch špatných“, tedy na takzvanou černou listinu, anglicky blacklist. Tento postup je však dnes velice neefektivní a ještě k tomu velmi pracný. Objem spamu mnohonásobně přesahuje objem legitimních a užitečných zpráv. Identita odesílatele je navíc skoro u všech emailových zpráv nejistá, ruční kontrola každé takové by byla časově náročná a údržba seznamu „špatných“ odesílatelů pracná a navíc zbytečná, protože odesílatelé těchto emailů ji generují ze jmen náhodně. Sama o sobě je tedy tato metoda skoro nepoužitelná, avšak ve spojení s ostatními se jeví jako vhodný doplněk.
4.2
Vyhledávání řetězců
Dalším evolučním krokem v rozpoznávání spamu je analýza obsahu emailu. Pokud objevíme slova, která nás určitě nezajímají (např. viagra, loan,...), můžeme důvodně takovou zprávu označit za nevyžádanou a nechat na poštovním klientovi, ať takovou zprávu smaže nebo přeřadí do jiné složky. Tento postup funguje velmi dobře, pokud komunikujeme v jiném jazyce, než jsou slova užívaná ve spamech. Rovněž rozesílatelé spamu se musí držet stále námi již evidovaných slov. Každý email, který by obsahoval jen slova mimo náš seznam, by nebyl automaticky rozpoznatelný. To je zvláště nevhodné, pokud se v emailu objeví porůznu „zakódovaná“ slova (například v1gra, viagr4,v.i.a.g.r.a,...). Evidovat každé takové slovo je čím dál náročnější na ukládání, prohledávání i údržbu. Taktéž při takto jednoduchém porovnávání dostává hodně regulérních emailů otisk spamu. Například pokud komunikujeme se zahraniční bankou o půjčce, musíme tuto komunikaci lovit ze spamové složky. Proto je tato metoda rovněž samostatně velmi obtížně použitelná, ale opět může posloužit jako vhodný doplněk.
4.2.1
Regulární výrazy
O něco chytřejším řešením je použití regulárních výrazů. V nich se nemusíme omezovat jen na jednotlivá slova, ale můžeme postihnout i jejich určité modifikace a kombinace. Zkusme třeba vytvořit regulární výraz, který by nám odchytal všechny napodobeniny slova „viagra“ utvořené zdvojením některých jeho znaků: v+i+a+g+r+a+
Detekce spamu
23
To bylo ještě vcelku jednoduché. Použití oproti uvedení slova do jednoduchého slovníku to ale moc nezlepšilo. Zkusme ještě složitější výraz, který v současné době používá SpamAssassin pro identifikaci emailu nabízejícího dietu: /\b(?:(?:without|no) (?:exercis(?:e|ing)|dieting)|weight.?loss|(?:extra| lose|lost|losing).{0,10}(?:pounds|weight|inches|lbs)| burn.{1,10}fat)\b/i
Hned je vidět, že podobný výraz si moc uživatelů emailů samo nenapíše. Navíc i při využití regulárních výrazů nemizí nutnost stále přidávat nové a nové. Čím více jich je, tím větší pravděpodobnost, že označíme legitimní email za spam. Navíc čím jednodušší výraz, tím spíše mu bude vyhovovat více emailů. Čím složitější bude, tím méně spamu zachytí a tím také snazší bude pro rozesílatele spamu adaptace na takové pravidlo. Ačkoliv se jedná o pokročilejší variantu analýzy textu než pouhý seznam slov, stále je použitelnost takového systému malá a bude spíše sloužit jako doplněk ostatním.
4.2.1.1
SpamAssassin
Dnes velmi používaný program na detekci spamu používající ve velké míře regulární výrazy se nazývá SpamAssassin. Program je napsán modulárně. Výkonné jádro programu doplňují konfigurační soubory se sadou pravidel. Tato pravidla obyčejně tvoří regulární výrazy a každé z nich hledá určitou známku spamu. Například slova se sexuální tématikou, různé zkomoleniny názvů léků a některé fráze (typicky nabídky na půjčku, levná léčiva, software), ale i různé identifikace softwaru používaného k distribuci spamu (např. známé MessageID hlavičky, špatné verze Outlooku a další). Takových pravidel má v současnosti SpamAssassin přes 600. Kromě těchto testů nabízí SpamAssassin další testy, které už na regulárních výrazech založené nejsou, ale byly do něj v průběhu vývoje doplněné. Jedná se především o síťové testy. Obsahují testy na distribuované databáze kontrolních součtů (Razor, Pyzor, DCC a další), testování DNS blacklistů, a URL blacklisty. Jako další zásuvné moduly je možné používat SPF, HashCash i DomainKeys. Nechybí ani podpora pro statistický bayesovský filtr. Každé pravidlo má definovanou svou bodovou hodnotu. Pokud pravidlo vyhoví, přičítá se jeho hodnota (může být i záporná) ke konečnému vyhodnocení. Uživatel si zvolí, kolik bodů musí email dostat, aby byl označen za spam. Pokud je tato hranice překročena, doplní SpamAssassin do hlaviček emailu zprávu o tom, že se jedná o spam. Naprostá většina pravidel má kladné bodové ohodnocení. Pravidla se záporným ohodnocením byla přidávána hlavně na zamezení tzv. „false positives“, což jsou užitečné emaily omylem považované za spam. Bodová hodnota pravidel se mění s každou novou verzí SpamAssassinu. Stanovuje se pomocí kontroly velkého korpusu užitečných emailů a spamu. Tento korpus se pravidelně doplňuje a podle toho, která pravidla vyhovují ve spamu a v užitečných emailech se poté stanovuje jejich hodnota [8]. Může se jednat i o několik hodnot, které pak SpamAssassin používá v závislosti na podmínkách (dostupnosti sítě, aktivaci bayesovského filtru). Celý SpamAssassin je napsaný v jazyce Perl. To má negativní důsledek na jeho rychlost (hlavně na čas inicializace těsně po spuštění). Aby byl tento jev minimalizován, přichází se SpamAssassinem i jeho doprovod ve formě démona spamd. Tento démon vytvoří jednu (nebo několik) instanci SpamAssassinu, které může potom klientská část posílat emaily k vyhodnocení, a předkompiluje si
Detekce spamu
24
všechny moduly a regulární výrazy. Odpadá tak nejdelší část zpracování a dále probíhá jen načítání uživatelské konfigurace a vyhodnocování pravidel. email
SpamD hlavní démon
SpamD démon
SpamD démon
SpamD démon
Změna uživatele
Načtení konfigurace
Spuštění testů
Testy celého emailu
DNS testy
Zásuvné moduly Bayesianský test AWL
Sloučení výsledků
Učení
Bayes
Modifikace emailu
výsledek Obrázek 4.1: Schéma zpracování emailu SpamAssassinem
Detekce spamu
25
SpamAssassin představuje jeden kompaktní celek, ve kterém najdeme všechny nové metody použitelné pro detekci spamu. Díky zvolenému jazyku je velmi snadno rozšiřitelný. Hlavní devizou je snadnost nasazení a uživatelský komfort. Uživatelé mohou pomocí jednoduchých textových konfiguračních souborů upravovat chování filtru. Zejména mohou přidávat adresy, ze kterých si přejí dostávat všechny emaily.
4.2.1.1.1
Postup hodnocení emailu (verze 3.0.5)
Email přichází na rozhraní SpamD démona. Ten v typické situaci udržuje několik svých potomků. Jednomu z nich tento email předá. Algoritmus předávání emailů na potomky se změnil ve třetí verzi produktu z round-robin na algoritmus používaný ve webovém serveru Apache, který se snaží maximálně vytížit minimální počet potomků. Potomek má omezenou životnost na standardních 200 emailů. Poté je ukončen a nastartován nový. Předchází se tak vlivu chyb, které mohly být zaneseny do vyhodnocovacích pravidel a zpomalovat běh aplikace (např. nevracením alokované paměti). Pokud nevyužijeme služeb démona SpamD, probíhá zpracování zcela stejně kromě předávání emailů potomkům. Potomek email převezme a změní svou identitu na identitu uživatele, který byl předán jako parametr z klientské části (spamc, napsaný v jazyce C). Načte uživatelskou konfiguraci, pokud to není zakázáno. Konfiguraci umí načítat z konfiguračních souborů v domovském adresáři, ale i z LDAP serveru nebo z SQL databáze. Poté vybere vhodné ohodnocení pravidel (sadu v závislosti na podmínkách) a spustí provádění testů. To se děje ve dvou paralelních částech. Jedna zpracovává testy v podobě regulárních pravidel a druhá provádí nezávisle na ní získávání dat z DNS (ověří dostupnost sítě a provede několik testů funkčnosti DNS). V průběhu zpracovávání se pravidla vyhodnocují v pořadí, jakou mají přiřazenou prioritu (nastavena je v konfiguračních souborech). Zpracovávají se nejdříve hlavičky a poté obsah samotného sdělení. U každé takové části je metoda, která upozorní zaregistrované zásuvné moduly, že došlo ke změně uživatele, začala kontrola emailu, zpracovávají se hlavičky atd. Zásuvné moduly mohou takovou událost využít dle libosti. Nakonec (pokud je zapnutý) přijde ke slovu bayesovský statistický filtr a AWL. AWL je zkratka pro Automatic White List. Jedná se o seznam „hodných“ adres. Do tohoto seznamu se adresa dostane, pokud z ní přichází emaily, které nejsou hodnoceny jako spam. V případě, že by nám uživatel na tomto seznamu poslal něco velmi podobného spamu, AWL upraví bodové hodnocení takového emailu v závislosti na historii tohoto uživatele směrem dolů. Zároveň s tím mu sníží reputaci. S klesající reputací klesá i hodnota bodové úpravy, kterou AWL provede. Pokud se uživatel v AWL rozhodne nás zásobovat spamem, brzy jeho zvýhodňující postavení pomine. Výsledky z těchto částí se nakonec sečtou a podle uživatelem nastavené hranice se určí, zda získané body nasvědčují tomu, že se jedná o spam. Podle toho o kolik tuto hranici překročil nebo na kolik se jí vzdálil SpamAssassin dále usuzuje, jak moc si může tímto zjištěním být. Zkontroluje proto kolik znevýhodňujících pravidel vyhovělo v hlavičkách a kolik v těle dokumentu. Pokud přesáhnou definovanou hranici (standardně 3 pro každou část), pokusí se sám sebe z tohoto emailu poučit. Poučí se tak, že adresy z emailu vloží volitelně na černou nebo bílou listinu (blacklist/whitelist) a provede naučení bayesovského filtru. Pro užitečné emaily stačí, aby měly skóre nižší než je uživatelem požadovaná hranice. Tímto postupem se SpamAssassin sám průběžně zlepšuje. Žádnou jinou dynamickou úpravu neprovádí.
Detekce spamu
26
Jako výstup jsem úmyslně označil výsledek takového vyhodnocení. Nemusí se totiž jednat přímo o email, ale třeba jen o zprávu, zda email byl nebo nebyl spam. Jako výsledek můžeme brát i návratový kód klientské části, který je na takovém hodnocení závislý.
4.3
Statistické filtry
Statistické filtry se zabývají analýzou obsahu celého emailu. Zpravidla takový email rozdělí na kousky, tzv. tokeny. První implementace těchto filtrů rozdělovaly email pouze na celá slova. Novější už umí tvořit takové kousky s větší kontextovou závislostí. Například pokud se v hlavičce Subject objeví slovo „FREE“, výsledek bude vypadat třeba „S*FREE“, kde „S“ značí jeho výskyt ve zmíněné hlavičce. Pro statistické filtry jsou důležité celé emaily včetně hlaviček. Na základě výskytu takových rozpoznaných kousků pak odhadují, zda se jedná o poštu užitečnou nebo spam. Většinou se nerozhodují na všech slovech současně, ale jen na určitém počtu statisticky nejvýznamnějších (s pravděpodobností spamu blízkou 0 nebo 1). Pravděpodobnost zařazení do spamu určují podle podílu počtu spamů, ve kterých se slovo vyskytuje, a počtu všech emailů, ve kterých se slovo vyskytuje. Většina filtrů vyžaduje před svou plnou funkčností období tréninku. V tomto období se „krmí“ jak spamem, tak i užitečnými zprávami. Filtr se tímto adaptuje na každého uživatele zvlášť a pozná, které zprávy si typicky přeje a které naopak nechce. Existují další a někdy vhodnější učící metody, o nichž se zmíním později. Po učící fázi je efektivita takových filtrů obecně velmi vysoká (většinou přes 99 %). Algoritmy využívané k analýze obsahu (resp. ke statistické analýze výskytu jednotlivých kousků emailu) jsou založené z velké většiny na bayesovských vzorcích.
4.3.1 4.3.1.1
CRM114 Třídění
CRM114 není jen samostatný program, ale také programovací jazyk. Tento jazyk slouží ke snazší klasifikaci textů pomocí statistických metod a filtrů do (i několika) různých tříd. Pro naše potřeby bude postačovat klasifikace pouze do dvou tříd a filtr pro přidávání hlaviček do emailů (je obsažen v instalačním balíčku). Emailovou zprávu rozdělí pomocí regulárních výrazů na slova. Nad těmito slovy v pořadí, v jakém je nalezl pohybuje takzvaným oknem. Toto okno má standardně velikost 5 a vejde se do něj tedy až 5 slov současně. Tímto oknem pak posouvá nad všemi nalezenými slovy vždy o jedno dál (po každém posunu jsou v okně 4 předchozí slova). Nad obsahem okna se poté spustí takzvaný třídič (classifier). Jeho úkolem je vytvořit ze slov v okně fráze. Standardně používaný třídič v CRM114 se nazývá Markovův třídič (Markovian classifier). Ten z obsahu okna vygeneruje všechny možné kombinace jeho částí. Na příkladu z dokumentace [9] ze slov „Houston, we've got a problem“ vytvoří tyto fráze:
Detekce spamu
27
Houston Houston Houston Houston Houston Houston Houston Houston Houston Houston Houston Houston Houston Houston Houston Houston
we've <skip> got we've got <skip> <skip> a we've <skip> a <skip> got a we've got a <skip> <skip> <skip> problem we've <skip> <skip> problem <skip> got <skip> problem we've got <skip> problem <skip> <skip> a problem we've <skip> a problem <skip> got a problem we've got a problem
Pokud by dokument pokračoval, samozřejmě bude frází z těchto slov ještě více s postupem okna k dalším částem dokumentu. Celkem se tak vzhledem k velikosti dokumentu v počtu slov můžeme dostat až k 2 n−1 , kde n je počet slov [10]. Tento postup se nazývá Sparse Binary Polynomial Hashing (SBPH) a je použit i v jiných softwarových produktech. Místo SBPH můžeme použít i další metody (více na straně 30). Kvůli takovému možnému exponenciálnímu růstu frází je ve standardním filtru pro email ukončeno zpracování po nejvýše 4096 zpracovaných bytech emailu. Pro každou takovou frázi vyhledá ve statistickém souboru pravděpodobnost, že patří do dané kategorie. Následně pomocí bayesovského řetězce a vah jednotlivých frází spočte výslednou pravděpodobnost. Protože ale bayesovské vzorce předpokládají nezávislost jednotlivých jevů, je tato výsledná pravděpodobnost silně zkreslena. Nelze ji proto vydávat jako měřítko pro konečný verdikt, zda třídit dokument do určité třídy. Váha pro každou frázi se určí podle toho, kolik v ní je zastoupeno slov a kolik je jich vynechaných. Váha roste s počtem slov ve frázi a každým nevynechaným slovem exponenciálně tak, že každou frází je velmi snížen efekt všech „podfrází“. Bayesovský řetězec pro výpočet pravděpodobnosti, že dokument se zadanými frázemi F spadá do kategorie C vypadá takto:
P Ci∣F =
P F∣Ci⋅P Ci ∑ P F∣Ci ⋅P Ci i
Pokud si za C zvolíme třídu spamu, pak nová pravděpodobnost, že fráze je spam se rovná pravděpodobnosti, že fráze je spam krát předchozí pravděpodobnost spamu, to celé děleno součtem pravděpodobnosti toho, že fráze je spam krát pravděpodobnosti spamu plus pravděpodobnost, že fráze není spam krát pravděpodobnost ne-spamu. Na začátku předpokládá předchozí pravděpodobnost spamu jako 50 % (0,5). Tímto se získá výsledná pravděpodobnost příslušnosti do třídy.
CRM114 pro konečný třídící verdikt používá hodnotu označovanou jako pR. Ta je pro případ Markovianského třídícího algoritmu definována jako:
pR=log 10 pravděpodobnost přislušnosti do třídy - log 10 pravděp. příslušnosti mimo třídu.
Detekce spamu
28
Nastavení třídících algoritmů je takové, aby hodnoty pR spadaly do následujících rozmezí:
pR
Význam
100 a více
velmi vysoká pravděpodobnost příslušnosti do třídy
od 100 do 10
vysoká pravděpodobnost příslušnosti do třídy
od 10 do -10
zařazení je nejisté
od -10 do -100
vysoká pravděpodobnost nepříslušnosti do třídy
-100 a méně
velmi vysoká pravděpodobnost nepříslušnosti do třídy Tabulka 4.1: Význam pR hodnot
Výslednou třídu nakonec určuje nejvyšší pR. Hodnoty pR se typicky pohybují od -320 do +320 bodů.
4.3.1.2
Učení
CRM114 však nezačne fungovat hned po nainstalování. Jako každý statistický filtr je třeba jej naučit, co do které třídy patří, aby mohl správně vyhodnocovat pravděpodobnost zařazení do každé z nich. K dispozici máme hned několik možných metod, jak CRM114 učit. Přehled ukazuje následující tabulka:
Zkratka
Celý název učící metody
TET
Train Every Thing
TOE
Train Only Errors
SSTTT Single Sided Thick Threshold Training DSTTT Double Sided Thick Threshold Training TTE
Train Till Exhaustion
TUNE
Train Until No Errors Tabulka 4.2: Učící metody
TET Metoda, kdy učíme filtr na všech dokumentech (všechny spamy i všechny užitečné emaily). Tato metoda se obecně nedoporučuje. Ze všech učících metod dosahuje u všech třídících algoritmů nejhorších výsledků. Je to způsobené tím, že se touto metodou naučí mnoho nadbytečných dat, která pro rozhodování nejsou potřeba, a tím zároveň sníží váhu těch, která by to rozhodla mnohem přesněji. TOE Metoda učení na chybách. Její princip spočívá v tom, že necháme třídící algoritmus pracovat do doby, než udělá chybu. Na této chybě ho pak naučíme správné zařazení. Při tomto
Detekce spamu
29
postupu se zvyšuje pravděpodobnost výskytu frází v cílové třídě (tj. v té správné). Statistiky v ostatních třídách se nemění. Také je dobré upozornit na to, že pokud tímto způsobem naučíme filtr na jednom dokumentu, změní se statistika vůči ostatním třídám. To následně může způsobit špatné třídění doposud správně tříděných dokumentů. Tato metoda však vykazuje velmi dobré výsledky. SSTTT Pracuje stejně jako TOE, avšak neučí se pouze na chybách v určení správné třídy. I pokud byl dokument zatříděn správně, zjišťujeme o kolik se výsledek lišil od ostatních tříd (jak jistí jsme si zařazením byli). Pokud taková míra jistoty není dostatečná, naučíme dokument do správné třídy ještě jednou stejně jako v TOE. DSTTT Pracuje stejně jako SSTTT, ale kromě toho, že naučí správnou třídu „být si jistější“ na určitém dokumentu (resp. frázích v něm), odnaučí všechny ostatní třídy, které si „byly dostatečně jisté“ zařazením tohoto dokumentu v nich. TTE Učící metoda, která spočívá v opakovaném učení jednoho vzorku tak dlouho, dokud jeho zatřídění není správné. Správnost zatřídění se porovnává výše zmíněnými metodami SSTTT a DSTTT. Po každém učícím kroku následuje nové třídění dokumentu tak dlouho, dokud není dokument tříděn dostatečně správně. To může někdy zabrat velmi dlouhý čas nebo také vůbec neskončit. Proto je nutné počet cyklů hlídat a včas zastavit na rozumné mezi. TUNE Další metoda, která je jen kombinací ostatních. Na rozdíl od TTE se ale neučí jen na jednom dokumentu, který byl špatně zatříděn, ale vždy na celé množině dokumentů (většinou korpus spamu a užitečných emailů). Učí se tak dlouho, dokud nejsou všechny dokumenty zatříděné správně. K určení dostatečné „správnosti“ znalostí lze využít opět SSTTT nebo DSTTT případně i TTE. Je zřejmé, že tuto metodu není dobré používat na průběžný trénink, protože je značně časově náročnější. Určení optimální tréninkové metody je vždy závislé na použitém třídícím algoritmu. Použití vyloženě nevhodné metody může účinnost takového algoritmu velmi snížit. CRM114 používá jako databázi pro své statistiky „.css“ soubory. Při jejich vytváření je třeba mít na paměti, že jsou při běhu programu nahrané celé v operační paměti. CRM114 používá při vyhledávání statistických dat pro jednotlivé fráze jejich heš (modulo velikost souboru, s přetokovými oblastmi) jako index do těchto souborů. Pokud jsou v paměti, je toto velmi rychlé. Při malé velikosti souboru se může stát, že nebude schopen pojmout dostatečné množství statistických dat pro fráze (program v tom případě uživatele upozorní, že se soubor naplnil). V případě zbytečně velkého souboru hrozí plýtvání systémovými prostředky.
4.3.1.3
Další třídící algoritmy
Kromě Markovova třídícího algoritmu nabízí CRM114 ještě několik dalších. Popíšeme stručně jejich důležité vlastnosti.
Detekce spamu
30
OSB Zkratka z Orthogonal Sparse Bigram. Algoritmus pracuje na stejném okně jako Markovův třídící algoritmus, ale vybírá si z něj pouze dvojice. Z 16 frází uvedených v příkladu pro „Houston, we've got a problem“, které vytvořil Markovův algoritmus by zbyly 4 (Houston we've; Houston <skip 1 word> got; Houston <skip 2 words> a; Houston <skip 3 words> problem). Jeho paměťová i výpočetní náročnost jsou výrazně menší, ale dokáže být dokonce přesnější. Nejlepší výsledky pro učení dosáhneme pomocí TOE nebo SSTTT, horších s DSTTT. OSBF Stejné jako OSB, avšak vylepšené o „matematické voo-doo“ (slova autora programu). Ačkoliv dává zatím zdá se nejlepší výsledky, je v experimentálním vývoji. WINNOW Tento algoritmus nepoužívá vůbec statistické vzorce, ale u každé fráze si uchovává hodnotu, kterou buď zvyšuje nebo snižuje v závislosti na tom, zda dokument byl zatříděn dobře nebo špatně. Stejně jako OSB používá jako fráze dvojice. Na konci vyhraje ta třída, která má nejvyšší součet ze všech frází. Jako učící algoritmus je třeba vybrat pouze DSTTT. HYPERSPACE Algoritmus na rozdíl od ostatních nepoužívá jednotlivé fráze jako určovací kritérium, ale z každého zpracovaného dokumentu vytvoří jeden bod v 32rozměrném prostoru. Při třídění dalších textů porovnává vzdálenost v tomto prostoru od všech známých textů. Vyhraje ten, který má vzdálenost nejmenší. V dokumentaci je tato metoda přirovnána k hvězdám a galaxiím. Každý dokument vytvoří novou hvězdu a zařadí se do té galaxie, odkud na něj dopadá nejvíce světla. Nejlepší učební metodou pro tento třídící algoritmus je SSTTT.
4.3.2
DSpam
DSpam je statistický filtr založený na bayesovských vzorcích. Je navržený pro větší prostředí a multiuživatelský provoz. Je možné ho nasadit s různými poštovními servery, ale i jako předsunutou SMTP bránu. Rovněž je možné ho použít až jako výstupní filtr pro emaily stahované přes POP3 nebo IMAP rozhraní. Kromě použití s mnoha ostatními službami se pyšní i samostatným webovým rozhraním, které umožňuje uživatelům grafický přehled, které zprávy byly označeny jako spam a skončily v karanténě. Uživatelé následně mohou provést kontrolu a v případě, že nesouhlasí se závěry filtru, nechat si zprávu doručit a filtr na ní naučit.
4.3.3
Bogofilter
Bogofilter je další statistický filtr založený na bayesovských vzorcích. Původní verze (do roku 2002) má na svědomí Eric S. Raymond, známá postava ze světa svobodného softwaru. Je určen pouze pro klasifikaci emailů do dvou skupin (spam, nespam). Nepodporuje sice tolik možností jako například CRM114, ale zato je na třídění emailů velice rychlý.
Detekce spamu
31
4.4
Kontrolní součty zpráv
Pokud někdo rozesílá nevyžádanou poštu, posílá typicky stejný text na mnoho adres. Pokud by tedy jeden z příjemců takovou zprávu označil jako spam, mohli by se ostatní příjemci z jeho zjištění poučit a takové zprávy také zahazovat nebo alespoň označovat jako spam. Bylo ale třeba nalézt efektivní cestu, jak si takovou skutečnost sdělit. Udržovat databázi emailových spamů by bylo velmi náročné, posílání celých zpráv na porovnání by bylo zbytečně neefektivní a porovnávání fulltextem na celé zprávě by zabralo příliš mnoho času. Pokud je zpráva všude stejná, stačilo by vytvořit její (dostatečně) jednoznačný otisk a ten porovnat.
4.4.1
Pyzor a Razor
Pyzor a Razor používají oba tentýž princip. Porovnávají otisk (heš) zprávy se svou interní databází. Popišme si, jak Pyzor takový otisk vytváří. Jako první nás určitě napadne vzít celý email a předat ho hešovací funkci - například SHA-1. Takový otisk by však měl jen velmi omezenou platnost. V každém doručeném emailu se mění hlavičky (hlavně received, to), data a další údaje. Každá taková změna by měla za následek úplně jiný otisk takového emailu a v praxi by tedy dva obsahově stejné emaily byly pomocí otisků neporovnatelné. Pyzor proto provádí „normalizaci“ takové zprávy. Ta probíhá v následujících krocích: ➢
Odstranění všech hlaviček
➢
Rozdělení na MIME části (například přílohy, HTML verze atd...)
➢
Odstranění nežádoucích slov/znaků Tím se má na mysli odstranění emailů a URL vyskytujících se v textu, vynechání zbytečných bílých znaků (mezery, tabulátory, prázdné řádky), odstranění dlouhých slov (delší jak 10 znaků, má se za to, že taková slova jsou většinou nějaké identifikátory) Tyto změny se samozřejmě provádějí, pokud to typ obsahu umožňuje (např. u binárních příloh nebudeme odstraňovat řetězce delší než 10 znaků)
➢
Vygenerování SHA-1 otisku z výsledku předchozích kroků
S vygenerovaným otiskem se obrátí do databáze a výsledkem je buď shoda nebo nenalezení odpovídajícího vzorku v databázi. Takový otisk a porovnání se provádí zvlášť pro každou část emailu (přílohu, HTML a textovou verzi...). Razor postupuje obdobně, akorát neprovádí takové agresivní zásahy do textu (mazání emailů, URL a mezer). Na generování otisků zpráv ale používá (ve standardní distribuci) své dvě metody označované jako VR4 a VR8. Obě dvě jsou založené na funkci SHA-1. VR4 generuje plnou SHA-1 signaturu z vybraných částí (normalizovaného) emailu (vyjma hlaviček) a hlavičky Subject. VR8 generuje signatury pouze z nalezených URL. Z těchto URL vyřízne název serveru (hostname). Z tohoto názvu vygeneruje SHA1 heš, ze kterého si vezme prvních 20 hexadecimálních znaků. Toto provede pro každý nalezený název serveru. Ve výsledku je tedy několik VR4 signatur a až několik VR8 signatur. Email je u Pyzoru i Razoru považován za spam, pokud alespoň jedna vygenerovaná signatura je v databázi nalezena. U Razoru tedy stačí, pokud se v emailu vyskytuje název serveru, který je evidovaný v databázi jako URL ze spamu.
Detekce spamu
32
Oba systémy vycházejí při hodnocení signatur ze svých databází. Do těchto databází přispívají sami uživatelé. Politika zařazování a vyřazování se u obou liší. Pyzor nevyžaduje registraci pro hlášení zpráv jako spam. Dovolí zprávu nahlásit jako spam komukoliv, dokonce opakovaně (každé takové opakované nahlášení se počítá). Umožňuje hlásit zprávy jako smysluplné emaily (global whitelist). Na dotaz ohledně signatury obdrží uživatel dvě čísla - počet hlášení jako spamu a počet hlášení jako smysluplných emailů. Z poměru těchto dvou si sám může odvodit jak se k emailu zachovat. Výhodou Pyzoru je, že dostaneme k dispozici i serverovou část systému, kterou můžeme sami samostatně provozovat. V plánu je vývoj verze, která by dokázala mezi takovými instancemi provádět rozumnou replikaci získaných dat. Razor vyžaduje pro hlášení zpráv jako spam registraci uživatele (zdarma online). Všem umožňuje hlásit jako zprávy a rovněž používat systém zneplatnění takového hlášení (revoke). Ke každému uživateli si vede statistiky, kolik emailů nahlásil jako spam a kolik takových hlášení zneplatnil (ne nutně sobě). Pokud uživatel správně hlásí emaily jako spam (nechodí k nim zneplatňující požadavky) a zneplatňuje hlášení nahlášená omylem (např. různé mailinglisty), stoupá v hodnocení Razoru výš. Jeho hodnocení emailu má pak větší váhu než např. hodnocení nově registrovaného uživatele. Razor tento systém nazývá Web-Of-Trust. Parametry postupu v tomto sytému a vyhodnocovací algoritmus nejsou veřejné. Serverová část systému Razor není veřejně dostupná. Bohužel je poměrně snadné oba tyto systémy zmást vhodnou náhodnou úpravou textu, řekněme třeba náhodným 6 znakovým řetězcem. U Razoru je šance na zmatení trošku menší (vybírá náhodné části v závislosti na velikosti emailu a počtu jeho řádků), ale stále dosti vysoká.
4.4.2
DCC
DCC je zkratka pro Distributed Checksum Clearinghouse. Již z názvu je patrné, že se opět zabýváme kontrolami otisků zpráv. DCC umí vytvářet tyto otisky z různých hlaviček zvlášť, z těla emailu a dva tzv. fuzzy otisky. Fuzzy zde znamená totéž, o co se snažil Razor výběrem (víceméně) náhodných částí emailů pro generování otisku. DCC vytváří tyto otisky dva a označuje je ve výsledcích jako fuzz1 a fuzz2. Dotazování na veřejné DCC servery (seznam je obsažen v distribuci zdrojových kódů) je zdarma a možné anonymně v rozumné míře (240 000 dotazů denně). Pro větší objemy se doporučuje provozovat vlastní DCC server (dostupný rovněž zdarma) a používat výměnu otisků s ostatními servery. Hlášení nových zpráv do databáze je rovněž možné provádět anonymně (bez vytváření přihlašovacího jména). Na komerční bázi je možné používat systém využívajícího princip reputace podobný jako u Razoru.
Detekce spamu
33
5
Praktické testy
Testy byly provedeny na 2,6 GHz procesoru AMD, 512 MB RAM. Provedeny byly tak, že na přeskáčku byly filtru posílány jak spamy, tak soubory s běžnými emaily (označené jako Ham). Pokud se filtr spletl, bylo mu hned obratem posláno totéž na doučení. Pro váženou úspěšnost byla chybně klasifikované nespamové zprávě přiřazena 10krát větší váha. V praxi většinou považujeme za horši situaci, kdy ztratíme užitečný email než tu, když najdeme ve schránce spam. CRM114 Markovian
Běh Spam správně Spam chybně Ham správně Ham chybně Čas (minuty) Úspěšnost Vážená úspěšnost
1 7087 26 4179 19 16,18 99,60% 98,09%
2 7092 21 4172 26 16,35 99,58% 97,52%
3 7101 12 4182 16 15,92 99,75% 98,48%
4 7109 4 4189 9 15,5 99,89% 99,17%
5 7111 2 4192 6 15,33 99,93% 99,45%
6 7111 2 4192 6 15,27 99,93% 99,45%
Tabulka 5.1: Výsledek testu CRM114 - Markovian
CRM114 Hyperspace
Běh Spam správně Spam chybně Ham správně Ham chybně Čas (minuty) Úspěšnost Vážená úspěšnost
1 7095 18 4182 16 15,83 99,70% 98,43%
2 7102 11 4184 14 15,8 99,78% 98,67%
3 7108 5 4189 9 15,83 99,88% 99,16%
4 7109 4 4187 11 15,95 99,87% 98,99%
5 7108 5 4191 7 15,95 99,89% 99,34%
6 7109 4 4191 7 15,95 99,90% 99,35%
Tabulka 5.2: Výsledek testu CRM114 - Hyperspace
Praktické testy
34
CRM114 OSB
Běh Spam správně Spam chybně Ham správně Ham chybně Čas (minuty) Úspěšnost Vážená úspěšnost
1
2
7075 38 4177 21 8,2 99,48% 97,81%
7085 28 4173 25 8,33 99,53% 97,54%
3 7092 21 4184 14 8,42 99,69% 98,58%
4 7108 5 4193 5 8,33 99,91% 99,51%
5 7112 1 4194 4 8,18 99,96% 99,64%
6 7113 0 4194 4 8,3 99,96% 99,65%
Tabulka 5.3: Výsledek testu CRM114 - OSB
CRM114 Unigram
Běh Spam správně Spam chybně Ham správně Ham chybně Čas (minuty) Úspěšnost Vážená úspěšnost
1
2
7068 45 4162 36 14,25 99,28% 96,42%
7092 21 4172 26 13,78 99,58% 97,52%
3 7105 8 4184 14 13,67 99,81% 98,69%
4 7112 1 4191 7 13,47 99,93% 99,37%
5 7112 1 4193 5 13,5 99,95% 99,55%
6 7112 1 4193 5 13,43 99,95% 99,55%
Tabulka 5.4: Výsledek testu CRM114 - Unigram
Bogofilter
Běh Spam správně Spam chybně Ham správně Ham chybně Čas (minuty) Úspěšnost Vážená úspěšnost
1
2
5627 1486 4089 109 11,52 85,90% 77,23%
6337 776 4178 20 9,33 92,96% 91,37%
3 7041 72 4194 4 4,85 99,33% 99,01%
4 7085 28 4196 2 4,7 99,73% 99,58%
5 7098 15 4198 0 4,83 99,87% 99,87%
6 7102 11 4197 1 4,78 99,89% 99,81%
Tabulka 5.5: Výsledek testu Bogofilter
Praktické testy
35
SpamAssassin (spamd)
Bayesovský filtr Spam správně Spam chybně Ham správně Ham chybně Čas (minuty) Úspěšnost Vážená úspěšnost
Ano 4765 2348 4198 0 36,92 79,24% 79,24%
Ne 2500 4611 4154 2 22,97 59,06% 58,90%
Tabulka 5.6: Výsledky SpamAssassinu
5.1
Zhodnocení praktických testů
Testy ukázaly, že většina testovaných konfigurací si poradí s testovaným vzorkem dat přibližně za 15 minut. Z tohoto času výrazně vybočují akorát dvě metody. První je CRM114 s použitím OSB třídiče. Ten se sice kvůli své nižší přesnosti na začátku musí chvíli učit, ale za 5 průchodů již vykazoval srovnatelnou účinnost za mnohem kratší čas (8 minut). Druhý je Bogofilter. V prvních průchodech to sice ještě nevypadá, ale v dalších se ukáže, že jedinou brzdou mu bylo učení. Učí se tedy co do procesorového času pomaleji než konkurenti, za to však po naučení je v rychlosti výrazně převyšuje (2-4krát). Navíc se z testovaných konfigurací ukázal jako nepřesnější ve vážené úspěšnosti, která je v testu nejlepším vypovídajícím faktorem. To vše za necelých pět minut. U SpamAssassinu nemá smysl provádět několik běhů, protože by dopadly stejně. Testy byly provedeny bez přístupu na síť, takže odráží jen schopnosti vyhodnocovacích regulárních výrazů a bayesovského filtru. Tento filtr ve SpamAssassinu se dá dobře srovnat jak s Bogofilterem, tak s CRM114 s Unigram třídičem (jako fráze bere jen jedno slovo). Nižší přesnost filtru u SpamAssassinu mohla způsobit i učící metoda. SpamAssassin byl naučen na celém korpusu, tedy ne jen na chybách. Tuto metodu jsem zvolil proto, že je v praxi u SpamAssassinu běžnější a SpamAssassin sám ji za běhu provádí pomocí samoučícího mechanizmu.
Praktické testy
36
6
Aplikace
6.1
Motivace
Rozhodl jsem se napsat vylepšení pro detekčních schopností programu SpamAssassin. Jeho vyhodnocovací postup jsem popsal v samostatné kapitole. Zmíním tedy jen stručně, o co jsem se při úvahách opíral. SpamAssassin prověřuje stovky pravidel, zda vyhoví na určité části emailu (hlavička, tělo). Výsledkem takového kladného vyhodnocení je přidání bodů, které se k takovému pravidlu váží. Pokud součet všech takto přiznaných hodnot přesáhne definovanou hranici, je email označen jako spam. Jeho „povědomí“ o povaze emailu je tedy omezené jen do oblasti vyhoví/nevyhoví pro každé jednotlivé pravidlo zvlášť. Stává se, že emaily vyhoví jen několika málo pravidlům. Vlastně to je přesně to, o co se rozesílatelé spamu systematicky snaží. Představme si fiktivní příklad s člověkem. Zavedeme si tři pravidla a) být v bance, b) mít zbraň a c) říkat si o peníze. Každé z nich je samo o sobě skoro neškodné. Mnoho lidí chodí do banky, někteří lidé mají zbraň a většinou chtějí peníze. Každé pravidlo samo o sobě by vyhovělo na mnoha lidech. Proto pokud na jejich základě rozhodujeme o špatném chování člověka, musíme jim přiřazovat jen velmi malou váhu. Pokud se ale vyskytnou všechny tři pohromadě, je zřejmé, že se člověk chová špatně. Na základě prostého součtu (malých hodnot) z určených pravidel bychom těžko mohli odvodit, že se chová špatně. Pokud ale vezmeme v potaz, že se vyskytují všechny tři současně (což je mnohem méně pravděpodobné), můžeme na špatné chování usuzovat mnohem přesněji. Právě z kombinace pravidel lze mnohem snáze určit i povahu emailu.
6.2
Praktické poznatky
Ve SpamAssassinu jsou pravidla navržena převážně na rozpoznávání spamu, pro užitečné emaily je pravidel jen velmi málo. Negativní pravidla (pravidla se záporným hodnocením) jsou určena hlavně pro zamezení špatnému označení jako spam. Většinou se jedná o uživatele na bílé listině (whitelist) nebo emaily, které šly jen po vnitřní síti. Z toho plyne, že spam bude mít mnohem více pravidel, která na něj vyhoví. Ukazuje to i následující graf:
Aplikace
37
Počet vyhovujících pravidel 70,00
procento emailů
65,00 60,00 55,00 50,00 45,00 40,00 35,00 30,00
SPAM HAM
25,00 20,00 15,00 10,00 5,00 0,00 0 1 2 3
4 5 6 7 8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 30
počet vyhovujících pravidel
Obrázek 6.1: Počet vyhovujících pravidel na jeden email
Poznámka ke grafu: testy byly provedené se SpamAssassinem verze 3.0.5 na vzorku 7000 spamů a 4000 užitečných emailů (poměr české/anglické 3:1). Testy byly provedené s vypnutým statistickým filtrem a nedostupnou sítí. Vidíme, že většina užitečných emailů se vešla do jednoho pravidla, zatímco některé spamy se dostaly až na 30. Kombinací více pravidel s největší pravděpodobností ovlivníme spam.
6.3
Obecný popis řešení
Pravidla, která SpamAssassin používá, můžeme rozdělit na několik množin. Zvolil jsem rozdělení podle jména pravidla, které napovídá, která ostatní pravidla jsou mu podobná. Taková pravidla pak postihují podobnou oblast (např. prohřešky v hlavičkách, zvláštnosti v HTML...). Necháme SpamAssassin ohodnotit email a z výsledné množiny pravidel, která vyhověla poskládáme všechny možné dvojice. Každou takovou dvojici ohodnotíme součtem bodů, které přísluší každému z obou pravidel. Na množině všech pravidel pak vytvoříme graf, kde každé pravidlo představuje jeden uzel. Pokud se pravidlo řadí do množiny vyhovujících pravidel, vytvoříme hranu mezi ním a ostatními vyhovujícími pravidly. V průběhu jejich vytváření sledujeme, zda vytvářená hrana spojí dvě různé komponenty, které představují různé množiny pravidel. Vycházíme z toho, že pokud vyhoví jedno pravidlo v množině, je pravděpodobné, že vyhoví i některé jemu podobné. Pokud však vyhoví i pravidlo mimo tuto množinu, je to důležitější znak toho, že email může být spam. K bodovému ohodnocení emailu přidáme ohodnocení všech kombinací s takovou váhou, kterou odvodíme z počtu hran, které spojují různé komponenty. Situaci dobře nastíní následující schéma:
Aplikace
38
Obrázek 6.2: Schéma grafu vyhovujících pravidel
Pokud bychom uvažovali jen bodové ohodnocení pravidel bez dalších omezení, zvyšovali bychom poměrně hodně možnost, že označíme za spam nevinný email. Stačilo by několik pravidel a bodové ohodnocení by dramaticky stoupalo. Abychom tomuto jevu předešli, budeme sledovat historii průchozích emailů. Vycházíme z předpokladu, že kladná pravidla (pravidla se záporným bodovým ohodnocením) slouží k identifikaci významného znaku, který svědčí pro nevinnost emailu. Pokud tedy v nalezených pravidlech objevíme kladné pravidlo, snížíme význam všem záporným, které se s ním vyskytují. Tuto hodnotu však snižujeme pouze pro naše kombinační výpočty a ne přímo v ohodnocující sadě SpamAssassinu. Zamezíme tak vlivu pravidel, která nemají pro určení možnosti spamu žádný praktický význam, v ovlivňování našich výpočtů. Další praktické pozorování ukázalo, že dvojice s nejvyšším výskytem v emailech, se vyskytují jen v 10-15 % průchozích emailů. Dvojic s tímto výskytem je navíc velmi málo a jen zlomek (přibližně 100 dvojic ze 4000) má výskyt častější než v 1 % emailů. Pro ukázku poslouží následující tabulka:
Aplikace
39
Dvojice
Procento výskytu
HTML_MESSAGE+MIME_HTML_ONLY
9.16
HTML_90_100+HTML_MESSAGE
7.53
MIME_BASE64_NO_NAME+MIME_BASE64_TEXT
7.28
HTML_MESSAGE+HTML_TAG_EXIST_TBODY
6.97
HTML_MESSAGE+MPART_ALT_DIFF
6.34
RCVD_HELO_IP_MISMATCH+RCVD_NUMERIC_HELO
6.09
HTML_MESSAGE+LOTS_OF_STUFF
4.72
HTML_40_50+HTML_MESSAGE
4.31
HTML_60_70+HTML_MESSAGE
4.25
HTML_MESSAGE+LONGWORDS
4.22
HTML_MESSAGE+MIME_HTML_MOSTLY
4.19
HTML_90_100+HTML_TAG_EXIST_TBODY
4.16
HTML_80_90+HTML_MESSAGE
4.03
HTML_90_100+LOTS_OF_STUFF
4.00
HTML_TAG_EXIST_TBODY+LOTS_OF_STUFF
4.00
HTML_20_30+HTML_MESSAGE
3.94
MIME_HTML_MOSTLY+MPART_ALT_DIFF
3.72
HTML_30_40+HTML_MESSAGE
3.53
HTML_70_80+HTML_MESSAGE
3.50
HTML_50_60+HTML_MESSAGE
3.12
HTML_MESSAGE+INFO_TLD
3.09
LONGWORDS+MPART_ALT_DIFF
2.97
HTML_10_20+HTML_MESSAGE
2.72
HTML_IMAGE_ONLY_12+HTML_MESSAGE
2.72
HTML_MESSAGE+MSGID_FROM_MTA_HEADER
2.69
MSGID_FROM_MTA_HEADER+SUBJ_ALL_CAPS
2.53
Tabulka 6.1: Výskyt kombinací pravidel ve spamu
Aplikace
40
Také by bylo dobré sledovat historii emailů pro každého uživatele, abychom mohli přisuzovat častějším kombinacím větší váhu. Počet všech možných dvojic kombinací z 600 pravidel je 179700. To je poměrně velké číslo, uvědomíme-li si, že pro každý email bychom vyhledávali historii kombinace mezi téměř 180 tisíci ostatních. U testovaného vzorku emailů (10000 emailů, 7000 spamů) vyhovělo u všech v součtu kolem 300 různých pravidel. Již jsme si řekli, že výskyt různých kombinací je poměrně malý, většina z nich by tedy měla mizivou váhu v našem rozhodování a zcela zbytečně by nás stála výpočetní výkon. To můžeme snadno vyřešit tak, že budeme sledovat historii za posledních například 1000 emailů. Data, která nebudou po této době statisticky významná, z databáze odstraníme. Pokud bychom sledovali historii příliš dlouhou, budeme v první řadě skladovat mnoho nadbytečných dat, v řadě druhé pak velmi zpomalíme efekt nové vlny spamu (tj. vlny vyhovující jiným pravidlům), protože váha výskytu kombinací se vypočítá jako podíl počtu jejich výskytů ku počtu všech emailů. Jako vhodné řešení se jeví jednou za zvolený interval (např. již zmíněných 1000 emailů) vedle pročištění databáze provést i poměrné snížení váhy všech kombinací a počtu emailů v databázi. Tento postup nám zachová aktuální váhu kombinace, zároveň však umožní rychlejší nástup nových a k tomu navíc postupně vytlačí ty kombinace, které se již neobjevují a jen zbytečně zabírají místo v databázi. Tímto postupem lze dosahnout omezení celého prostoru dvojic ze 170 tisíc do řádově desetitisíců. Zbytečné množení nadbytečných dat je také jeden z důvodů, proč nepoužít při vyhodnocovaní také trojice pravidel. Už výskyt dvojic je v emailech v řádu procent, výskyt trojic je pak ještě menší. Navíc počet trojic dramatickz roste s počtem pravidel, kterým email vyhoví. Do databáze bychom ukládali mnoho hodnot, které by následně podlehly výše popsanému vyčištění. Mezi tím by zpomalovaly vyhledávání. Například pro 22 pravidel bychom vytvořili 1540 trojic, zatímco dvojic bude jen 231. Sitaci zachycuje následující graf:
Počet kombinací vzhledem k počtu pravidel 3000 2750
počet kombinací
2500 2250 2000 1750
Dvojic Trojic Součet
1500 1250 1000 750 500 250 0 3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
počet pravidel
Obrázek 6.3: Vývoj počtu kombinací
Důvodem pro nepoužití trojic je zejména možnost velmi snadného útoku na systém, který by se jimi zabýval. Rozesílatelé spamu samozřejmě mají pravidla k dispozici a není problém napsat email, který vyhoví mnoha z nich. V případě, že by byl schopný vyhovět 600 pravidlům, zpracujeme řádově 170 tisíc dvojic, zatímco trojic bychom museli zpracovat přes 35 milionů (a následně uložit historii a posléze vymazat).
Aplikace
41
6.4
Praktická implementace
Bylo třeba dosáhnout stavu, kdy s rostoucím počtem kombinací vzrůstá bodová hodnota, kterou k emailu přidáme. Zároveň ale musíme zabránit nekontrolovatelnému hromadění bodů, pokud se pravidel vyskytne více. Umožnilo by to přebít kladná pravidla (se zápornou bodovou hodnotou) postupným přibýváním kombinací. Navíc je bezvýznamné, jestli místo 40 bodů přidáme 400, pokud hranice pro označení za spam je bodů 5. Celý systém je usazen na křivku:
Obrázek 6.4: Graf vyhodnocující funkce
Křivka je definována předpisem, který pro počet vypočtených bodů z kombinací (x) přiřadí konečné hodnocení (y):
y=ln x1 pro x0 y=−ln∣ x ∣1 pro x0 y=0 pro x=0
Aplikace
42
Pokud logaritmus navíc vynásobíme vhodným číslem, můžeme určovat „přísnost“ k počtu vypočtených bodů. Vynásobením větším číslem způsobí vyšší nárůst i pro nižší hodnoty.
Obrázek 6.5: Modifikace vyhodnocovací křivky násobením n*y pro n=1,2,3,4.
Postup výpočtu je následující: 1. vygenerování všech možných dvojic z vyhovujících pravidel 2. přiřazení hodnoty každé takové dvojici pravidel (a,b) hodnotu vypočteme jako součet bodového hodnocení pravidla a součet bodového hodnocení pravidla b. Pokud ohodnocení libovolného pravidla je záporné (tj. je to kladné pravidlo), je možnost ji vynásobit zvolenou konstantou 3. úprava hodnoty podle jejího výskytu v historii na základě zaznamenané historie vynásobíme bodové hodnocení zjištěným koeficientem (počet výskytů / počet zpracovaných emailů) 4. přičtení hodnoty ke konečnému bodovému ohodnocení 5. zjištění, zda kombinace zasahuje do dvou různých množin pokud zasahuje, tuto informaci zaznamenat 6. vypočítat konečné bodové ohodnocení to vypočteme jako logaritmus součtu bodů za všechny kombinace a vynásobíme počtem zjištěných „spojů“ mezi množinami pravidel, případně upravíme zvoleným koeficientem
Celý program je napsán jako modul pro SpamAssassin. Proto je napsán kompletně v PERLu a používá standardní perlovská rozhraní. Celá implementace je rozdělena do 3 částí v duchu objektového programování.
Aplikace
43
Hlavní celek se nazývá Combo.pm a obsahuje hlavní vyhodnocovací část. Zpracovává výstupy ze samotného SpamAssassinovského filtru a doplňuje potřebné další hlavičky. Ke své činnosti používá dva další moduly, které po implementaci jednoduchého API mohou být nahrazeny libovolnou jinou třídou. Pro oba dva moduly jsem vypracoval dvě varianty. První využívá pouze textových souborů, což nese sice vyšší režii při zpracování databází na textových souborech, na druhou stranu nevyžaduje žádné další rozšíření. Druhá využívá perlovské rozhraní DBI pro přístup k databázi a její MySQL modul pro komunikaci s MySQL databází. První z modulu se nazývá ComboStore.pm a obstarává vyhodnocování vah jednotlivých kombinací a jejich historii. Implementuje i čištění databáze. Druhý modul se nazývá ComboScore.pm a zabývá se uložením bodových hodnot pro jednotlivá pravidla. Děje se tak proto, aby vyhodnocení kombinací bylo nezávislé na ohodnocení samotného SpamAssassinu. Umožňuje to tak provádět snazší učení na průchozích kombinacích s možností kombinační modul kdykoliv jako celek vypnout a vrátit se tak přímo na původní hodnoty SpamAssassinu.
Aplikace
44
7
Závěr
V práci jsem shrnul nejčastěji používané metody pro boj se spamem. Metody byly jak z oblasti prevence spamu, tj. zabránění pokusům o jeho doručení, tak i z oblasti detekce spamu, tj. rozeznání, že nám byl doručen spam. Zdůvodnil jsem potřebu boje proti spamu. Spam nejen že příjemce obtěžuje, ale má přímé ekonomické důsledky. Na každý takový email musíme vynaložit prostředky na jeho přenos, uložení a přečtení. Ve spamu se navíc nemusí objevit pouze nechtěné reklamní sdělení, ale také různý škodlivý obsah, který má uživatele uvést v omyl a vylákat z něho osobní nebo firemní údaje. Rovněž počítačové viry využívají možností emailů a „přibalují“ se k nim. Ukázalo se, že z hlediska nákladů na správu je nejefektivnější filtrování spamu z uživatelských schránek přímo na poštovním serveru. K tomuto úkolu se nám dnes nabízí celá řada metod. Bohužel rozesílatelé spamu o metodách také vědí a přizpůsobují se. Pružnost rozesílatelů spamu a fakt, že rozesílání velkých množství nevyžádaných zpráv je skoro nic nestojí (náklady na připojení k Internetu), jsou pro boj se spamem velkou překážkou. Nutí nás využívat více metod současně, vynakládat více práce a prostředků na detekci spamu. Více používaných metod detekce klade větší nároky na správce poštovních systémů. Ti si mohou málokdy dovolit hazardovat s uživatelskými emaily, zvlášť v době, kdy se přes email běžně posílají například obchodní smlouvy. V důsledku toho stojí před dvěma problémy. První je odstranění co největšího množství spamu z uživatelských schránek, druhý je potřeba vyvarovat se odstraňování legitimních emailů. Rozesílatelé spamu to vědí a zneužívají toho útokem na slabá místa metod detekce, aby tak vyvolali snížení jejich úspěšnosti rozlišení spamu a legitimních emailů. Velkou nevýhodou nových detekčních metod je pomalá rychlost zavádění na poštovních serverech. Výhodou by bylo, pokud by se nová metoda dala nasadit hned a všude. Bohužel praxi je toto samozřejmě nereálné a v době většího rozšíření jsou již rozesílatelé spamu s metodou obeznámeni a přizpůsobili se. Navíc kořeny snadnosti rozesílání spamu jsou až v samotném návrhu SMTP protokolu používaného pro emailovou komunikaci. O zastavení přívalu spamu se snaží i naši zákonodárci. Vypátrání samotného zdroje spamu ale bývá obtížné, spamy běžně přeposílají uživatelé s počítači infikovanými trojskými koni. Navíc se zdroj často nachází v zahraničí. Ale čím více překážek rozesílatelům spamu postavíme, tím lépe. Naprogramoval jsem aplikační vylepšení schopností SpamAssassinu, které umožňuje vyhodnocování širších kontextových souvislostí než pouhý výčet pravidel. Získaná data umožňují dynamické přizpůsobení pro jednotlivé uživatele v závislosti na historii a do budoucna by mohly umožnit i dynamickou úpravu bodového ohodnocení pravidel přímo ve SpamAssassinu. Umožňuje napsání více pravidel, která sama o sobě nemají velkou vypovídací schopnost, a zvyšovat bodové hodnocení až na základě výskytu jejich kombinací. Použitím těchto metod lze dosáhnout významného zvýšení úspěšnosti detekce v dosud nerozpoznaných spamech v závislosti na jejich druhu.
Závěr
45
8
Rejstřík
AWL......................................................26 Bayes.....................................................24 Bigram...................................................30 Blacklist.................................................17 Botnet......................................................8 Classifier...............................................27 CRM114................................................27 DNS.......................................................17 DomainKeys.........................13pp., 24, 47 Fráze......................................................27 Greylisting...............................................9 HAM.......................................................6 HashCash.........................................20, 24 Klasifikace.............................................27 Obchodní sdělení...................................22 Okno......................................................27 Open relay...............................................7
Rejstřík
OPT-IN..................................................22 PR..........................................................28 SBPH.....................................................28 SenderID................................................13 SMTP..................................................7, 9 Sorbs......................................................18 SPAM................................................6, 22 SpamAssassin........................................24 Spamcop................................................17 SPF..........................................................9 SURBL..................................................19 Tréninkové metody...............................30 Třídění...................................................27 Třídič.....................................................27 URL.......................................................18 Zákon.....................................................22
46
9
Použitá literatura
[1]
The Definition of Spam [online], Aug 11, 2004,
(květen 2006).
[2]
Keizer, Gregg, Spam Costs World Businesses $50 Billion [online], February 23, 2005, (květen 2006).
[3]
Goodwin, Bill, Spam costs UK business L1.3bn a year, says study. Computer Weekly, Mar 8, 2005, ISSN: 00104787.
[4]
Postel, Jonathan B., SIMPLE MAIL TRANSFER PROTOCOL [online], August 1982, (květen 2006).
[5]
Dagon, David, Botnet Detection and Response, OARC Workshop, 2005, (květen 2006).
[6]
Klesin, J. Simple Mail Transfer Protocol (květen 2006).
[7]
Často kladené otázky k zákonu č. 480/2004 Sb., o některých službách informační společnosti [online], [2005], (květen 2006).
[8]
How Scores Are Assigned, (květen 2006).
[9]
Yerazunis, William S., The CRM114 Discriminator Revealed! (květen 2006).
[10]
Christian Siefkes, aj., Combining Winnow and Orthogonal Sparse Bigrams for Incremental Spam Filtering [online], (květen 2006).
[11]
Wong, M., Schlitt, W., Sender Policy Framework (SPF) for Authorizing Use of Domains in EMAIL, version 1 [online], June 6, 2005, (květen 2006).
[12]
Allman, E., aj., DomainKeys Identified Mail Signatures (DKIM) [online], April 13, 2006, (květen 2006).
[13]
The Evolution of Spam [online],
[14]
Graham, Paul, A Plan for Spam [online], August 2002, (květen 2006).
Použitá literatura
[online],
April
2001,
[online],
47
