České vysoké učení technické v Praze Fakulta elektrotechnická
Katedra počítačů
Diplomová práce
Spam a bezpečnost emailové komunikace Jan Tischler
Vedoucí diplomové práce: Ing. Jan Kubr leden 2007
Poděkování Chtěl bych na tomto místě poděkovat své mamce, bez jejíž podpory a pochopení bych se nedostal až sem. Rovněž bych rád poděkoval vedoucímu diplomové práce Ing. Janu Kubrovi za to, že se ujal vedení mé diplomové práce a za jeho rady a komentáře.
Prohlášení Prohlašuji, že jsem svou práci vypracoval samostatně, pouze s použitím literatury a zdrojů uvedených v seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
V Praze dne ……………………………
……………………………………………
Abstrakt Ve své diplomové práci se zabývám nevyžádanou elektronickou poštou a možnostmi jejího filtrování. Práce seznamuje s protokoly pro přenos elektronické pošty a strukturou emailu, jež jsou nutné pro pochopení principů a odhalení slabých míst. Dále nastiňuje původ nevyžádaných zpráv a jejich varianty. Hlavním těžištěm je analýza metod pro boj se spamem a z toho vycházející návrhy, doporučení a implementace vylepšení. Klíčová slova: email, spam, filtrování.
Abstract My diploma thesis deals with unsolicited electronic mail and its filtering possibilities. The thesis acquaints with protocols used to transfer and handle electronic mail which are necessary for the understanding of basic principles and revealing of weaknesses. Subsequently it outlines the origin of unsolicited messages and their variants. Emphasis of this work is on the analysis of methods for counteracting spam with suggestions and implementation for improvements. Keywords: email, spam, filtering.
Obsah 1 2
3
4
5 6
7 8
ÚVOD ..............................................................................................................3 EMAIL .............................................................................................................4 2.1 Historie...............................................................................................................................4 2.2 Emailová adresa.................................................................................................................4 2.3 Struktura emailu................................................................................................................6 2.3.1 Hlavička emailu..........................................................................................................6 2.3.2 Tělo zprávy................................................................................................................10 2.4 Protokoly pro správu pošty ............................................................................................. 12 2.4.1 SMTP (Simple Mail Transfer Protocol).................................................................. 13 2.4.2 POP3 (Post Office Protocol, verse 3) ..................................................................... 20 2.4.3 IMAP4 (Internet Message Access Protocol, verse 4) ........................................... 23 2.5 Zabezpečení protokolů ....................................................................................................27 2.5.1 SSL ........................................................................................................................... 28 2.5.2 TLS ........................................................................................................................... 29 2.5.3 Autentizační mechanismy ...................................................................................... 29 2.6 Podpisové certifikáty a šifrování ................................................................................... 29 SPAM ............................................................................................................34 3.1 Definice............................................................................................................................ 34 3.2 Podstata spamu............................................................................................................... 34 3.3 Proč jsem příjemcem spamu?........................................................................................ 36 3.4 Rozdělení spamu............................................................................................................. 38 3.4.1 Podle formy ............................................................................................................. 38 3.4.2 Podle obsahu sdělení .............................................................................................. 39 3.4.3 Podle charakteristických znaků (email) ................................................................ 40 3.5 Spam a zákon .................................................................................................................. 43 3.5.1 Zákony v Česku a EU – OPT-IN ............................................................................ 43 3.5.2 Zákon v USA – OPT-OUT....................................................................................... 43 3.5.3 Mezinárodní iniciativy............................................................................................ 44 FILTROVÁNÍ SPAMU ...................................................................................46 4.1 Prevence ze strany uživatele .......................................................................................... 46 4.2 Umístění filtru................................................................................................................. 46 4.3 Posouzení účinnosti a přesnosti .....................................................................................47 4.4 Konkrétní metody........................................................................................................... 48 4.4.1 Autorizace odesilatele............................................................................................. 48 4.4.2 Analýza obsahu textu............................................................................................... 51 4.4.3 Porovnávání signatur...............................................................................................54 4.4.4 Blacklist.....................................................................................................................55 4.4.5 Whitelist................................................................................................................... 58 4.4.6 Greylisting ................................................................................................................59 4.5 Alternativní způsoby....................................................................................................... 60 4.6 Komplexní řešení............................................................................................................ 62 4.7 Software........................................................................................................................... 64 VÝSLEDKY ANALÝZY A NÁVRHY ZLEPŠENÍ ..............................................65 IMPLEMENTACE .......................................................................................... 67 6.1 Implementační záměr .....................................................................................................67 6.2 Popis implementace ........................................................................................................67 6.3 Experimentální hodnocení ............................................................................................ 69 ZÁVĚR...........................................................................................................70 POUŽITÉ ZDROJE ........................................................................................ 71
Diplomová práce
Seznam obrázků Obrázek 2-1: Běžný přenos zprávy................................................................................................. 15 Obrázek 2-2: SMTP fáze MUA-MTA ............................................................................................. 16 Obrázek 2-3: MTA-MTA fáze ......................................................................................................... 17 Obrázek 2-4: Mailgate a Firewall...................................................................................................18 Obrázek 2-5: Relaying, Open relay ................................................................................................ 19 Obrázek 2-6: Stavový diagram protokolu POP3........................................................................... 21 Obrázek 2-7: Stavový diagram protokolu IMAP...........................................................................25 Obrázek 2-8: Šifrované spojení s SSL........................................................................................... 28 Obrázek 2-9: Symetrické šifrování ............................................................................................... 30 Obrázek 2-10: Podepsání a zašifrování zprávy asymetrickým šifrováním ................................ 30 Obrázek 3-1: Procento spamu v elektronické poště za poslední 4 roky......................................35 Obrázek 3-2: Globální intenzita spamu v rámci měsíce (12/2006)........................................... 36 Obrázek 3-3: Obrázek jako náhrada za text spamu...................................................................... 41 Obrázek 4-1: Sender-ID mechanismus......................................................................................... 49 Obrázek 4-2: Schéma použití Domain Keys................................................................................. 50 Obrázek 4-3: Učící se Bayesovský filtr ..........................................................................................53 Obrázek 4-4: Topologie sítě DNSBL serverů spamhaus.org ...................................................... 58 Obrázek 4-5: Diagram Greylistingu...............................................................................................59 Obrázek 4-6: Zapojení SMTP proxy zprostředkovatele ............................................................... 61 Obrázek 4-7: Kaskáda pro zpracování zpráv................................................................................ 63 Obrázek 4-8: Příklad prolnutí funkcí programů ......................................................................... 63 Obrázek 6-1: Volání externího modulu z Postfixu........................................................................67
Seznam tabulek Tabulka 3-1: Chyby při klasifikaci spamu .....................................................................................47 Tabulka 3-2: Bězně používané blacklisty ......................................................................................57 Tabulka 5-1: MySQL tabulka 'triplet'............................................................................................ 68
Seznam příloh Příloha A: Obsah přiloženého CD Příloha B: Tabulka antispamových produktů
-2-
Diplomová práce
1 ÚVOD Jako téma pro diplomovou práci jsem si zvolil analýzu metod filtrování nevyžádané pošty, tzv. spamu. V době, kdy jsem se nad tímto tématem zamýšlel poprvé (přelom roku 2004 a 2005), byl pro mne, stejně jako pro mnoho uživatelů osobních počítačů na celém světě, nezanedbatelným problémem příval komerčních sdělení, převážně směrujících do našich emailových schránek. Tento problém se stal hlavní myšlenkou mé práce a motivací pro hlubší porozumění věci. Pod označením email (nebo také e-mail) rozumím zprávu elektronické pošty. Email se stal za léta existence Internetu jedním z hlavních komunikačních prostředků, který používá stále více lidí. Masivní rozšíření spamu je pro většinu uživatelů elektronické pošty komplikací a je celosvětová snaha problém řešit. Mnoho uživatelů, mě nevyjímaje, má založenou emailovou schránku na některém z freemailových serverů1. Z počátku jsme všichni pocítili problém spamu velmi silně, avšak do této chvíle (rok 2006) se situace v této oblasti výrazně zlepšila. Bylo zdokonaleno množství existujících metod a další nové postupy byly zavedeny. Po jejich nasazení byl počet nevyžádaných zpráv snížen na minimum. Pokud se ale zaměříme na organizace a společnosti, jež poskytují svým zaměstnancům přístup na internet a email používají pro obchodní či jinou komunikaci, téměř vždy je třeba učinit opatření související s filtrováním nevyžádané pošty. Tato opatření je třeba učinit tak, aby byl přísun spamu k uživateli minimální a použít metody přímo na serveru příchozí pošty. Ve své práci se snažím v jednotlivých kapitolách shrnout procesy a protokoly související s přenosem a zpracováním emailových zpráv a charakterizovat rysy spamu jako nevyžádané pošty. Kapitola, která se zabývá analýzou metod filtrování, pak představuje komplexní souhrn nejpoužívanějších metod, jejich výhod a nedostatků. Z poznatků získaných v této kapitole pak vychází návrhy na zlepšení. Poznámka: U analyzovaných metod většinou uvádím příklady použití z kategorie opensource programů. Je to proto, že k těmto programům je poskytována sdílnější dokumentace (na rozdíl komerčních produktů, kde si firma chce uchovat svoje výrobní tajemství, nebo je program předmětem patentu). V některých příkladech uvádím existující názvy domén, validní IP adresy či existující emailové adresy. Činím tak čistě z ilustrativních důvodů, nikoliv s úmyslem kohokoliv poškodit.
1
Servery poskytující zdarma po zaregistrování emailovou schránku, z českých seznam.cz, centrum.cz, aj.
-3-
Diplomová práce
2 EMAIL 2.1 Historie Původ emailu jako komunikačního prostředku sahá přibližně do roku 1965, kdy byla jedna z jeho prvních variant použita pro komunikaci mezi uživateli sálových počítačů pracujících v režimu sdílení času. Mezi prvními takovými systémy byly Q32 ve firmě System Development Company a CTSS na univerzitě MIT. Omezením bylo, že komunikace mohla probíhat pouze mezi uživateli tohoto sálového počítače. Na začátku sedmdesátých let vytvořil Ray Tomlinson se svými kolegy první programy pro lokální posílání emailů SNDMSG a READMAIL pro operační systém TENEX, který společně vyvíjeli. Následně SNDMSG modifikoval pro použití na síti ARPANET1 tak, že ho rozšířil o program CPYNET, jenž umožňoval poslání souborů po síti. Tomlinson rovněž rozšířil systém adresace uživatelů o notaci „user@host“ a s pomocí znaku „@“ oddělil uživatele a systém, což se stalo později standardem pro zápis emailové adresy. S odstupem času došlo k mnoha rozšířením programů SNDMSG a READMAIL např. o možnost řazení a zpracování zpráv (program RD), integraci obou programů do jednoho programu, schopného odesílat i přijímat emaily (program WRD, později MSG). Prvním dokumentem, který sjednotil více formátů emailu v síti ARPANET do jedné ucelené specifikace, byl RFC2 733, jenž byl později nahrazen RFC 822. Na počátku osmdesátých let byl přenos emailů také prováděn prostřednictvím jednoduchého UUCP3 protokolu na univerzitě v Berkeley, kde byl vyvinut operační systém BSD Unix. Protokol umožňoval přenos dat mezi systémy typu Unix pomocí dočasného vytáčeného připojení nebo připojení po sériové lince. Pracoval na principu „ulož a pošli dál“ (store-and-forward), informace určené k odeslání se ukládaly do fronty, a po navázání spojení byly poslány na cílový počítač. Eric Allman později vytvořil program DELIVERMAIL, který spojoval dohromady více služeb pro přenos emailů a prakticky vytvořil přepínač (switch) namísto integrované schopnosti store-and-forward. Na tomto principu byl následně vytvořen program SENDMAIL, distribuovaný spolu s BSD Unixem, jenž se stal nejčastěji používaným SMTP serverem v Internetu. V srpnu roku 1982 byla uvedena v [RFC 821] první verze protokolu SMTP (Simple Mail Transfer Protocol) – základní standard pro přenos elektronické pošty tak, jak ji známe dnes. O něm pojednává kapitola 2.4.1. Více informací na [LIVING1]
2.2 Emailová adresa Stejně jako u normální pošty, je pro posílání elektronické pošty nutná existence adresy. Hlavním rozdílem mezi nimi je jejich zápis a také to, že pro odeslání emailu je třeba identifikovat příjemce i odesilatele. Emailová adresa byla v minulosti definována různě. Jednou z dřívějších podob, v systémech s protokolem UUCP, byla tzv. “bang!” notace, která udávala cestu zprávy přes jednotlivé počítače. Názvy jednotlivých počítačů, přes které zpráva do cíle putovala, byly oddělené znakem “!”. Zápis utzoo!decvax!harpo!eagle!mhtsa!ihnss!ihuxp!greg, čteno zprava doleva, pak znamená cestu z počítače greg přes ihuxp, ihnss, …, a decvax do cíle utzoo. Tento způsob adresace měl značnou nevýhodu v tom, že cestu musel vytyčit člověk a to bylo bez dostatečné znalosti topologie sítě obtížné. 1
První rozsáhlá síť s přepínáním paketů; předchůdce dnešního Internetu Request For Comments; doporučení pro standardy na Internetu 3 Unix-to-Unix Copy Protocol 2
-4-
2 EMAIL
Diplomová práce
Současná obecná podoba emailové adresy dle [RFC2822] je charakterizována zápisem kde • •
local-part@domain
local-part (lokální část) je obvykle uživatelské jméno adresáta, případně jeho alias domain (doménová část) značí doménové jméno počítače, na němž má uživatel emailovou schránku; musí odpovídat plně kvalifikovanému doménovému jménu, což je úplné a unikátní jméno systému. Pokud např. „pavilonopic“ je jméno hostitelského počítače, pak úplné jméno je např. „pavilonopic.zoo.cz.“. Tečka na konci se v adrese nevyskytuje a v zápisu pouze symbolizuje, že za jménem již nenásleduje žádná přípona. Více na [FQDN].
Skutečná adresa může vypadat např. jako
[email protected] Doporučená délka lokální části adresy je 64 znaků a doménového jména maximálně 255 znaků. Jeden znak v tomto případě znamená jeden oktet (8-bitů). Lokální část emailové adresy je citlivá na velikost písmen (case sensitive) a může se skládat pouze z následující podmnožiny ASCII znaků: 1. 2. 3. 4.
malá a velká písmena abecedy a-z A-Z čísla 0 – 9 znaky ! # $ % & ' * + - / = ? ^ _ ` { | } ~ znak . (tečka), pokud není na počátku ani na konci lokální části adresy
Navíc je povoleno jako lokální část adresy použít řetězec v uvozovkách (znak s hodnotou 34 v ASCII tabulce), který může obsahovat i zakázané znaky s předřazeným zpětným lomítkem. Např. “opice\@kotec1”@zoo.cz je platná emailová adresa, ale použití podobných variant není doporučeno [RFC 3696]. Ačkoliv je podle RFC použitelná množina znaků poměrně velká, v praxi je rozsah znaků omezen výrazněji. Většina poskytovatelů emailové schránky, stejně jako běžně používané SMTP servery, akceptuje znaky uvedené výše v bodech 1, 2 a 4. Z bodu 3. pouze podtržítko „_“, případně pomlčku „-“ (viz email.cz, atlas.cz, aol.com). Vzhledem k citlivosti na velikost písmen lokální části by měl SMTP server dbát na to, aby zachoval nezměněný tvar. V cílovém systému by totiž mohlo dojít k případu, že uživatel „opice“ a „Opice“ budou dvě osoby! K tomu může snadno dojít v jakémkoliv systému, kde každý uživatel má automaticky přiřazenou emailovou schránku, uživatelské jméno obsahuje velká písmena a lokální část jeho emailové adresy odpovídá uživatelskému jménu. Rozlišování velikosti písmen je díky tomuto jevu spíše komplikace. Poznámka: Po otestování několika SMTP serverů a poskytovatelů emailové schránky na rozlišování velikosti písmen v lokální části jsem došel k závěru, že je zcela ignorována. Uživateli je doručen email s adresou zapsanou v jakékoliv kombinaci malých a velkých písmen. Povolené znaky doménové části adresy, která je necitlivá na velikost písmen (case insensitive), jsou dle specifikace doménových jmen [RFC 1035]: 1. 2. 3. 4.
malá a velká písmena abecedy a-z, A-Z čísla 0 – 9 znak . (tečka), pouze jako oddělující znak mezi názvy subdomény a domény znak – (pomlčka), pokud není na začátku nebo na konci označení domény nebo subdomény -5-
2 EMAIL
Diplomová práce
Po srovnání reálné podoby lokální části a doménové části adresy je vidět, že se jedná takřka o stejný soubor znaků, pouze s několika výjimkami. Všechna výše uvedená omezení a zjednodušení jsou v podstatě výhodou a zápis emailové adresy se tím stává snazší a přehlednější.
2.3 Struktura emailu Aby bylo možno poznat email do detailu, je třeba se podívat důkladněji na jeho „anatomii“. Tato znalost poslouží k lepší orientaci v protokolech pro správu pošty a pozdějšímu pochopení principu funkce některých filtrů nevyžádané pošty. Emailová zpráva se skládá ve své podstatě ze dvou částí, hlavičky (header) a těla zprávy (body). Hlavička musí předcházet tělu (analogie ze života), a vzájemně je musí oddělovat jedna prázdná řádka (zakončená
).
2.3.1 Hlavička emailu Hlavička poskytuje běžnému uživateli informace, od koho email přišel, komu byl určen, jaký je předmět zprávy a kdy byla odeslána a tedy pro něj není příliš významná. Ve skutečnosti však jde o důležitou součást emailu a podle jejích údajů se řídí servery, přes které zpráva prochází, a ve větší míře nástroje pro filtrování nevyžádané pošty. Každá informace v hlavičce má své jméno a hodnotu a nachází se na samostatném řádku. Smí být reprezentována pouze jako tisknutelné znaky 7-bit ASCII1 kódu (decimálně 33 – 126 včetně), tedy k záznamu těchto znaků postačuje kódování do sedmi bitů. Obecně by měl být dle specifikace celý email přenášen pomocí SMTP protokolu v 7-bitovém kódování. To se velice brzy projevilo jako nedostačující, zejména pro informace obsažené v těle zprávy a proto byla vydána série RFC označená jako MIME (Multipurpose Internet Mail Extension), která tento nedostatek řeší. Syntaxe zápisu hlavičkové informace (záhlaví) je : kde název začíná velkým písmenem na začátku řádku, je následován dvojtečkou a od hodnoty je oddělen mezerou. Hodnota pak může být zalomena na více řádků, kde druhý a další začínají mezerou nebo tabulátorem (viz [RFC 2822], sekce 2.2). Poznámka.: V následujícím textu diplomové práce je označním hlavička (header) nebo hlavička emailu míněn celý blok, který předchází tělu, a pojem záhlaví (header field) označuje jeden konkrétní konkrétní údaj. Některá záhlaví jsou povinná (např. From:, To:, Date:), přidání jiných závisí na okolnostech. Během putování zprávy obvykle nejsou průchozími body (MTA2) údaje v záhlaví nijak měněny, MTA pouze přidá další záhlaví Received: (viz níže) a případně další, pokud je potřeba. Pokud MTA některé údaje v záhlaví nezná, posílá je dál v nezměněné podobě. Klasická záhlaví
1
American Standard Code for Information Interchange; standard pro reprezentaci znaků, čísel, symbolů a kontrolních znaků pro použití v komunikaci a uchovávání dat. 2 Mail Transfer Agent, viz Chyba! Nenalezen zdroj odkazů.
-6-
2 EMAIL
Diplomová práce
Následující seznam obsahuje běžně používaná záhlaví, s poukazem na případné bezpečnostní nesrovnalosti a chyby v jejich použití. Jako zdroj některých informací byl použit [STOPSPAM]. • Apparently-To: Zprávy s mnoha adresáty občas mají dlouhý seznam záhlaví ve formě „Apparently-To: [email protected]“ (jeden adresát na každé řádce). Tato záhlaví nejsou ve skutečném emailu běžná a obyčejně jsou příznakem použití většího seznamu adresátů (tzv. mailing listu). V současnosti jsou programy pro hromadné odesílání pošty dost chytré na to, aby negenerovaly hromadu těchto záhlaví. • Bcc: (Blind Carbon Copy - slepá průklepová kopie). Běžně je toto záhlaví používáno ve stejném smyslu, jako „Cc:“ (viz níže), ale nevyskytuje se v hlavičce při přenosu mezi servery. Kouzlo slepé kopie je totiž v tom, že ostatní příjemci nevidí, že zpráva byla určena i pro někoho jiného. Tuto vlastnost zprostředkovává odesílající MTA a na každou adresu v seznamu „Bcc:“ kopii zprávy a vyplní záhlaví „To:“. „Bcc:“ by tedy mělo existovat pouze ve zprávě odesílané z MUA1 k prvnímu MTA. Pokud je toto záhlaví vidět v příchozí zprávě, je to indikace, že je něco v nepořádku! Slepé kopie jsou populární mezi spammery, neboť často zmatou nezkušeného uživatele, který dostanoe dopis, jenž vypadá jako že mu není adresován. • Cc: (Carbon Copy) – průklepová kopie – analogie s psacím strojem. Tento údaj záhlaví je rozšířením záhlaví „To:“ a specifikuje další adresáty. Některé programy s nimi zacházejí různě při tvorbě odpovědi (např. při volbě Odpovědět všem – Outlook Express). • Comments: je nestandardní neformátované pole záhlaví. Je nejčastěji k vidění ve formě "Comments: autentizovaný odesilatel je ". Takové záhlaví je přidáno některými mailery (např. programem Pegasus Mail) k identifikaci odesilatele, ale je často také „ručně“ přidáno spammery (samozřejmě s nesprávnou informací). Je třeba s ním zacházet pozorně. • Date: Toto záhlaví obsahuje to, co by člověk normálně očekával. Specifikuje obyčejně datum napsání a odeslání zprávy. Pokud je toto záhlaví vynecháno, může být přidáno některým z mail serverů nebo jiným počítačem po cestě, kterou zpráva putuje. Mělo by se brát trochu s rezervou, neboť je na světě překvapivě mnoho počítačů se špatně nastaveným časem. • Errors-To: Specifikuje adresu pro chyby generované programem pro obsluhu emailů. Např. zprávy vrácené jako "neznámý adresát" jsou, místo na odesilatelovu, vráceny na tuto adresu. Není to příliš běžné záhlaví, protože odesilatel obvykle chce odvykle dostat chybová hlášení na svou adresu. Většina mail serverů to dělá automaticky. • From: udává adresu odesilatele. Tento údaj není příliš směrodatný, neboť může být snadno nahrazen falešnou hodnotou. • Message-Id: (také Message-id:, Message-ID:) by měl být unikátní identifikátor, který je přiřazen každé zprávě - obvykle prvním mailserverem, na který se dostane. Obecně je to ve formě "", hatmatilka může být absolutně cokoli a doména je jméno stroje, který ID vygeneroval a přiřadil. Nepříliš často obsahuje hatmatilka i uživatelské jméno odesilatele. Zpráva, jejíž ID je špatné (např. prázdný řetězec, nebo bez znaku „@“), nebo doména obsažená v Message-Id není doménou původu zprávy, je pravděpodobně falešná. • In-Reply-To: toto záhlaví přiřadí zprávě ID jiné předchozí zprávy, na kterou tato odpovídá. Umožňuje například MUA nebo na webovém rozhraní, poskládat zprávy do kaskády odeslaných zpráv a jejich odpovědí. To zvyšuje přehlednost v obsáhlejší komunikaci. • Newsgroups: Toto záhlaví se rovněž vyskytuje pouze v emailu, který má spojitost s Usenetem - kopie zpráv zaslaných do Usenetu, i odpovědi na ně. V prvním případě 1
Mail User Agent, viz Chyba! Nenalezen zdroj odkazů..
-7-
2 EMAIL
Diplomová práce
specifikuje diskusní skupiny, do kterých byla zpráva zaslána a v druhém případě diskusní skupiny do nichž byla poslána zpráva, na kterou je odpovídáno. Sémantika tohoto záhlaví je předmětem menší "svaté války", která zaručuje, že obě množiny sémantik budou v dohledné budoucnosti bez rozdílu používány. • Priority: Absolutně volně pojaté záhlaví, které přiřazuje emailu prioritu. Většina programů ho ignoruje. Je často používáno spammery, obvykle ve formě "Priority: urgent" (nebo něco podobného), ve snaze zvýšit šance na přečtení jejich zprávy. • Received: je jedno z nejdůležitějších záhlaví. Obsahuje totiž nejrelevantnější informace o tom, kudy zpráva po cestě k cíli prošla a odhaluje případné nesrovnalosti v jejím původu. Při každém předání zprávy mezi klientem a serverem provede MTA vytvoří své záhlaví Received: a přidá ho na začátek hlavičky před již existující záznamy. Syntaxe běžného záhlaví Received: je: Received: from <doména_klienta> by <doména_serveru> with <protokol> id [for <emailová_adresa_příjemce>] ;
Jako doména_klienta je většinou uvedena adresa předávajícího stroje ve jmenném tvaru a v závorce za ní převedená na číselnou IP adresu (viz [RFC 2821]), případně typ služby, která zprávu zpracovala. Doména_serveru je doménové jméno stroje, který záhlaví vygeneroval. Protokol může být SMTP nebo ESMTP, nebo například HTTP, pokud byla zpráva odeslána přes webové rozhraní. Datum_a_čas odpovídá momentu zpracování zprávy serverem a je v klasickému UNIX formátu. Další použití a informace k tomuto záhlaví jsou v sekci 2.4.1 o SMTP protokolu. • References: Toto záhlaví je, až na kopie příspěvků z Usenetu, v emailu celkem ojedinělé. Je používáno na Usenetu k identifikaci příspěvku "výše", na který zpráva odpovídá; pokud se objeví v emailu, je to obvykle jenom kopie záhlaví Usenetu. Může se také objevit v emailem poslané odpovědi na příspěvek Usenetu, které poskytuje ID příspěvku, na nějž je odpovídáno. • Reply-To: Specifikuje adresu pro odpovědi. Přestože má záhlaví mnoho legitimních užití (např. když váš software zkomolí adresu v záhlaví From: a vy chcete dostávat odpovědi na správnou adresu), je také často používáno spammery na odvrácení stížností. Často naivní spammer, který chce shromáždit odpovědi na svou zprávu, použije k tomuto účelu záhlaví Reply-To:. Častěji však adresa uvedená v tomto záhlaví u nevyžádané pošty je buď neplatná, nebo patří nevinné oběti. • Return-Path: Záhlaví je přidáno do emailu ve chvíli, kdy ji přijme cílový SMTP server. Je do něj přepsána adresa z obálky (viz SMTP protokol) poskytnutá serveru v příkazu MAIL TO:, aby byla zachována informace o původním odesilateli. V případě, že zpráva je chybové hlášení od místního serveru (odchozí zpráva nebyla doručena), obsahuje toto záhlaví prázdnou adresu „<>”. • Sender: V emailu neobvyklé záhlaví (často nahrazeno či doplněno záhlavím X-Sender:), se může vyskytovat v hlavičce v případě kopie příspěvku z Usenetu1. Mělo by obsahovat adresu původního odesilatele; v případě příspěvků Usenetu jde o spolehlivější identifikátor, než obsah řádky From:. • Subject: Naprosto volně pojaté pole, specifikované odesilatelem, jenž obsahuje předmět zprávy. • To: Obvykle obsahuje příjemce zprávy. Může být jeden, stejně jako jich může být více. Některé servery mají nastaven limit na určitý počet adres v záhlaví „To:“ spolu s „Cc:“ a „Bcc:“. Pokud je tento limit překročen, odmítnou zprávu odeslat, případně posuzují jako rozesílání spamu [YAHOO1]. Je dobré si uvědomit, že záhlaví nemusí obsahovat opravdovou adresu příjemce!
1
Sít diskusních skupin, kategoricky členěných podle tématu.
-8-
2 EMAIL
Diplomová práce
X- záhlaví Tento termín označuje záhlaví začínající velkým X a pomlčkou. Úmluva je taková, že Xzáhlaví jsou nestandardní a mají pouze informační charakter. Naopak jméno jakékoliv nestandardního záhlaví s informačním charakterem by mělo začínat prefixem "X-". Tato úmluva bývá však často porušována. X-záhlaví je hojně využíváno spam filtry a antivirovými programy pro označení výsledků testů, podle kterých se pak řídí program pro správu pošty, kterému jsou předřazeny. X-záhlaví je tedy bezpočet. Následuje ukázka těch běžnějších. • X-Confirm-Reading-To: odesilatel vyžaduje automatické potvrzení o přečtení nebo doručení na adresu uvedenou v záhlaví. Obvykle je ignorováno, ale některé programy ho berou v potaz (např. MS Outlook či Outlook Express, novější verze požádají o svolení informovat odesilatele). • X-Abuse: obsahuje informaci, kam oznámit zneužití emailové adresy, ze které zpráva přišla. • X-Antivirus:, X-Virus-Scanner, X-Virus-Scanned: používají antivirové programy běžně ke své identifikaci. Variace tohoto záhlaví je závislá na výrobci programu. • X-SpamDetected:, X-VirusDetected: indikují např. číselnou hodnotou, zda se jedná o virus či spam. Hodnota „0“ obvykle znamená negativní. • X-Distribution: V reakci na problémy se spammery, kteří užívali Pegasus Mail, autor tohoto programu přidal toto záhlaví. Jakákoliv zpráva odeslaná Pegasus mailem většímu počtu adresátů má přidáno záhlaví ve tvaru „X-Distribution: bulk“, které říká že jde o hromadnou zprávu. To má sloužit jako pomůcka pro filtrování pošty na straně příjemce. • X-Errors-To: stejně jako Errors-To: specifikuje adresu pro zasílání chybových hlášení. Pravděpodobně ale není tolik bráno v potaz. • X-Mailer: je volně pojaté záhlaví určené pro identifikaci programu, s jehož pomocí byla zpráva odeslána odesilatelem. Protože většina nevyžádané pošty je odesílána jednoúčelovými programy, je tento údaj určen jako informace pro filtry. • X-Priority: představuje další údaj o prioritě, jenž je používán např. Eudora mailerem k přiřazení priority zprávě (která je v programu zobrazena graficky). • X-Sender: je emailová analogie k záhlaví Sender: v Usenetu. Záhlaví údajně identifikuje odesilatele s větší spolehlivostí, než údaj From:. V podstatě je ale stejně „obtížně“ zfalšovatelné a tedy by mělo být bráno se stejnou rezervou, jako záhlaví From:. • X-UIDL: unikátní identifikátor používaný POP protokolem pro vybírání pošty ze serveru. Obyčejně je přidáno "po cestě" mezi emailovým klientem příjemce a jeho mail serverem. Pokud ale dorazí zpráva na server s vypněným X-UIDL: záhlavím, pravděpodobně je to nesmysl (není tu žádný zjevný důvod pro jeho existenci v tomto momentě, ale někdy je z neznámých příčin spammery přidáno). MIME záhlaví Tato záhlaví souvisí s rozšířeným MIME obsahem těla emailu a napomáhají při prohlížení zprávy ke správné interpretaci údajů. V této sekci jsou zmíněny typy MIME záhlaví a jejich hodnoty, zbytek je popsán v následující sekci. • Mime-Version: (také MIME-Version:) je záhlaví, které specifikuje jakou verzi MIME protokolu používá odesilatel. V současnosti je to verze 1.0. Klient, který není MIME kompatibilní záhlaví ignoruje, pro ostatní je to indikace, že zpráva obsahuje další MIME záhlaví udávající kódování, apod. • Content-Type: je další MIME záhlaví, sdělující MIME-kompatibilnímu programu, jaký typ obsahu má ve zprávě nebo její části očekávat. Obvykle je hodnota „text/plain“ nebo „text/html“ (prostý text nebo html) následována na další řádce dodatkem „charset=“, jenž udává znakovou sadu tohoto textu. Pokud je tělo zprávy složeno z více částí, typicky -9-
2 EMAIL
Diplomová práce
textu a příloh (hodnota „multipart/mixed“), je následně uvedeno „boundary=“, a jeho hodnota představuje řetězec oddělující jednotlivé části, který je v těle navíc předcházen dvěma pomlčkami (znak „-“). Každá taková část má potom uvedeny své vlastní hodnoty Content-Type: a Content-Transfer-Encoding:. Hodnot tohoto záhlaví je obecně velmi mnoho, 3 výše uvedené pokládám za nejpoužívanější, zbytek lze vidět pohromadě v [RFC 2046]. • Content-Transfer-Encoding: Toto záhlaví se vztahuje k MIME, standardnímu způsobu přiložení netextového obsahu k emailu. Nemá žádnou přímou souvislost s doručením emailu, ale ovlivňuje, jak MIME-kompatibilní program naloží s obsahem zprávy – resp. v jakém kódování jsou data přenášena. Výstupem všech níže zmíněných kódování je 7bit ASCII, vhodné pro přenos. Záhlaví může nabývat hodnot „7bit“ (klasické 7bitové USASCII), „quoted-printable“ (používané pro kódování textu, který obsahuje znaky mimo rozsah US-ASCII) a „base64“ (obvykle použito pro kódování binárních dat). Zvláštním případem jsou „8bit“ (možno použít pouze u SMTP serverů s podporou 8BITMIME přenosu [RFC 1652]) a „binary“ (není určeno pro elektronickou poštu). • Content-Description: doplňuje popisek části těla emailu, ve které se nachází. • Content-ID: přiřazuje části těla identifikátor, používaný při typu obsahu (content-type) „multipart/related” k odkazu na určitou část těla. • Content-Disposition: udává, jak má klient naložit s přílohou emailu. Implicitní hodnota je „inline“, která říká klientovi, že MIME část má být zobrazena automaticky při zobrazení zprávy, tedy hned po jejím zpracování. Druhou alternativou je hodnota „attachment“. Část tohoto typu je zobrazena jako ikonka, případně popisek a emailový klient nabídne po interakci s uživatelem uložení na disk nebo její zobrazení (viz [RFC 2183]).
2.3.2 Tělo zprávy V těle zprávy se nachází vlastní obsah emailu a jeho formální složení je dáno dvěma omezeními: • znaky a se v těle nesmí vyskytovat odděleně, ale pouze jako pár symbolizující konec řádku. • řádek nesmí být delší než 998 znaků (bez koncového symbolu) a měl by být 78 znaků. Omezení 78 znaků je zavedeno kvůli textovým terminálům, které obvykle zobrazují 80 znaků na řádek. Většinou dochází k zalomení delších řádků ještě na straně MUA. Realita je taková, že mnoho MUA ani MTA tyto délky nerespektují. Faktem ale zůstává, že tělo zprávy smí při přenosu obsahovat pouze znaky v 7-bit US-ASCII kódování – tedy omezený rozsah tisknutelných znaků, stejně jako hlavička. Pro anglicky mluvící uživatele to pro komunikaci dostačuje, ale např. v jazycích založených na latince se vyskytuje diakritika, která již pomocí 7 bitů zakódovat nelze. Rozšíření v tomto ohledu představuje rozšíření MIME (Multipurpose Internet Mail Extension, definované v sérii [RFC 2045 - 2048]). MIME Rozšíření dovoluje přenášet: • text v těle zpráv v jiné znakové sadě než US-ASCII, • rozšiřitelnou množinu různých formátů v těle zpráv netextového typu, • těla zpráv složená z více částí, • informace v záhlavích v jiné znakové sadě než US-ASCII.
- 10 -
2 EMAIL
Diplomová práce
Je tedy možné přenášet zprávy psané cizojazyčně a posílat ve zprávě přílohy jako obrázky, prezentace, video soubory, apod. MIME je zároveň významné i pro protokol HTTP1, kde pomocí Content-Type: záhlaví identifikuje server, jaká data klientovi posílá. Tělo MIME zprávy složené z více částí má strukturu stromu, jehož kořenem je část definovaná v hlavičce emailu a listy jsou vždy části „non-multipart“. To umožňuje vložení dalších složených (multipart) částí jako vnitřní uzly stromu. Typickým příkladem je zpráva obsahující výňatek webové stránky s obrázky, kterou je pak klient schopen zrekonstruovat do srozumitelné podoby. Nepovolené znaky v záhlaví jsou převedeny na tzv. kódované slovo (encoded word) ve tvaru “=?charset?encoding?encodedtext?=”, kde • charset je libovolná registrovaná znaková sada (obvykle stejná jako v těle zprávy), • encoding je buď “Q”, odpovídající kódování “quoted-printable” nebo “B” jako “base64”, • encodedtext je zakódovaný text. Typický předmět zprávy s diakritikou Subject: Půjdeme na oběd?
pak vypadá v hlavičce např. jako Subject: =?iso-8859-2?Q?P=F9jdeme_na_ob=ECd=3F?=
Množina MIME-multipart (tělo zprávy je rozdělena do více částí) má více kategorií, které specifikují vlastnosti částí zprávy a jejich vzájemné vazby. Základní kategorie jsou mixed, alternative, digest a parallel; minimální implementace vyžaduje alespoň mixed a digest. Ostatní jsou volitelné a jejich popis pokrývají samostatné RFC doporučení. Kategorie multipart/mixed je používána pro posílání souborů různých typů inline nebo jako příloh (v závislosti na záhlaví Content-Disposition:) a pokud není uvedeno jinak, implicitní typ jednotlivých částí je prostý text (text/plain). Naproti tomu kategorie multipart/digest slouží k posílání celých emailů jako příloh, kde jednotlivé části jsou implicitně typu „message/rfc822“. Toto uspořádání je vhodné, pokud chce uživatel odeslat podezřelý email/spam k analýze, protože přiložená zpráva je zachována v původní konzistenci, včetně jejích hlaviček. Při typickém přeposlání zprávy se totiž bere v potaz pouze tělo zprávy a pár základních informací ze záhlaví. Zajímavou kategorií je multipart/alternative, která říká MUA, že každá část zprávy je de facto stejná, pouze reprezentovaná v jiném formátu. Jednotlivé části jsou seřazeny podle jejich věrohodnosti (resp. přesnosti vůči originální informaci), od nejméně věrohodné až po nejvíce. MUA se při zpracování zprávy rozhodne podle podmínek a vhodnou část zobrazí. Typickým příkladem je zpráva ze dvou částí – jedné ve formátu prostý text a druhé v HTML s odstavci, obarvením a různou velikostí písmen. Pokud klient disponuje pouze zobrazením v textovém režimu (např. terminál) nebo má preferované zobrazení zprávy v textové podobě, použije část typu prostý text, v opačném případě zobrazí verzi v HTML. Toho je často využíváno v nevyžádané poště, kdy spammer2 do jedné části vloží „smysluplný“ prostý text a do druhé HTML části své reklamní sdělení. Spam filtr, který analyzuje pouze obsah typu prostý text pak nemusí poznat, že se jedná o spam. Některé další kategorie budou zmíněny v kontextu následujících sekcích. V následujícím příkladu je znázorněna zpráva s tělem složeným z více částí, konkrétně text s přiloženým obrázkem ve formátu JPG s názvem point.jpg. 1 2
HyperText Transfer Protocol Formální označení pro člověka rozesílajícího nevyžádanou poštu.
- 11 -
2 EMAIL
Diplomová práce
Hlavička obsahuje řádek Content-Type: multipart/mixed; boundary=zde-oddeleno
který vyznačuje zprávu rozdělenou na více částí s oddělovacím řetězcem „zde-odděleno“. Výběr oddělovacího řetězce je v režii klienta a nesmí kolidovat s obsahem zprávy. Obvykle je volen dostatečně dlouhý náhodný řetězec. Tělo zprávy má strukturu Sdeleni pro uzivatele MIME nekompatibilnich klientu... --zde-oddeleno Content-type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Jestli m=E1=9A hlad, tak dej v=ECd=ECt a m=F9=9Eeme vyrazit. Nav=EDc pos=ED= l=E1m jeden =E8en=FD bod. J. --zde-oddeleno Content-Type: image/jpeg; name=”point.jpg” Content-Transfer-Encoding: base64 Content-Description: obrazek jednoho pixelu /9j/4AAQSkZJRgABAQEBLAEsAAD/2wBDAAYEBQYFBAYGBQYHBwYIChAKCgkJChQODwwQFxQYGBcUFhYaHSUfG hsjHBYWICwgIyYnKSopGR8tMC0oMCUoKSj/2wBDAQcHBwoIChMKChMoGhYaKCgoKCgoKCgoKCgoKCgoKCgoKC goKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCj/wAARCAABAAEDASIAAhEBAxEB/8QAFQABAQAAAAAAAAA AAAAAAAAAAAP/xAAUEAEAAAAAAAAAAAAAAAAAAAAA/8QAFAEBAAAAAAAAAAAAAAAAAAAAAP/EABQRAQAAAAAA AAAAAAAAAAAAAAD/2gAMAwEAAhEDEQA/AKgA/9k= --zde-oddeleno--
Zde je dobře vidět oddělení jednotlivých částí a u každé z částí specifikované vlastnosti MIME obsahu. Textová část je zakódována jako quoted-printable, podřetězce začínající znakem “=” následovaným dvěma dalšími znaky jsou zakódované znaky s diakritikou. Poslední výskyt oddělovacího řetězce, zakončený dvěma pomlčkami navíc, indikuje konec MIME zprávy. Část před prvním výskytem oddělovače je ignorována a obvykle obsahuje informaci pro MIME nekompatibilní klienty. Tělo emailové zprávy může - vzhledem ke stromové struktuře a mnoha typům obsahu MIME - nabývat docela komplexních podob. Tomu je třeba přizpůsobit i jeho zpracování při diagnostice, zda se jedná o nevyžádanou poštu. Ve své podstatě ale stačí několik málo funkcí pro dekódování obsahu zakódovaných částí a např. rekurzivní procházení jednotlivých částí do určité hloubky.
2.4 Protokoly pro správu pošty Pro práci s elektronickou poštou jsou v podstatě zapotřebí dva, resp. tři aplikační protokoly na textové bázi nad TCP/IP spojením. Jsou to protokoly SMTP, který zajišťuje přenos zpráv mezi počítači, POP, který slouží pro stahování došlých zpráv ze serveru k uživateli a v poslední řadě protokol IMAP, jenž umožňuje práci s poštou přímo na serveru. Společným rysem těchto protokolů je mj. princip spojení typu klient-server. Komunikace probíhá tak, že klient na server vysílá žádosti (příkazy), resp. data, a server posílá zpět odpovědi. Příkazy klienta jsou většinou necitlivé na velikost písmen. Odpovědi serveru většinou obsahují na začátku řádku číslo, udávající stav nebo výsledek provedení příkazu s doplňujícím textem, nebo v případě protokolu POP3 pouze indikaci pozitivní a negativní odpovědi. Textová báze protokolů se vyznačuje tím, že všechny informace během komunikace putují jako text – tisknutelné znaky a každá řádka je ukončena párem znaků 1.
1
Carriage Return + Line Feed; typické ukončení řádky pro systémy typu DOS.
- 12 -
2 EMAIL
Diplomová práce
V dalším textu bude použito několik zkratek sloužící pro označení programů pracujících s poštou, které nyní vysvětlím. • • •
MUA (Mail User Agent) - poštovní program, ve kterém uživatel sestavuje zprávu a odesílá ji na server, případně umožňuje uživateli zprávy stahovat a číst (Outlook, The Bat, pine, apod.) MTA (Mail Transport Agent) - komplexní program (smtp/mail server) zajišťující doručení zprávy na cílovou adresu, případně . (Sendmail, Postfix, aj.) MDA (Mail Delivery Agent) – program, jenž přebírá zprávy od lokálního MTA, dále je třídí, přeposílá apod. (např. Procmail)
2.4.1 SMTP (Simple Mail Transfer Protocol) SMTP je relativně jednoduchý protokol a je v současnosti základním protokolem pro přenos elektronické pošty. V první specifikaci byl uveden v [RFC 821] a později doplněn v [RFC 2821]. Jeho důležitou vlastností je tzv. předávání emailů (mail relaying) v síti Internet, mezi vzájemně dostupnými počítači přes spojení TCP/IP v lokálních sítích, případně mezi jinými počítači, které nevyužívají protokoly postavené na transportní vrstvě TCP. V souvislosti s předáváním emailů je důležitý pojem obálka (envelope). Je to datová struktura, kterou uchovává server pro své potřeby po dobu zpracování zprávy a slouží k jejímu směrování. Skládá se z údaje odesilatel (reverse-path) a příjemci (forward-path). Odesilatel na obálce určuje opravdového odesilatele emailu, nezávisle na obsahu záhlaví „From:“ apod. Příjemci určují všechny adresy, na které bude zpráva odeslána. Obálka je generována v průběhu komunikace mezi klientem a serverem na základě příkazů MAIL, RCPT a RSET. Podle principu komunikace zmíněného výše musí server na všechny příkazy klienta odpovědět tříciferným kódem – status provedení příkazu - následovaným dalšími informacemi. Význam číselných odpovědí by se dal shrnout do tří kategorií: • přijetí – hodnota 200 – 399 • dočasné odmítnutí – hodnota 400 – 499 • permanentní odmítnutí – hodnota 500 – 599 Ne všechny hodnoty odpovědí jsou v rozsahu obsazeny. Chování v závislosti na odpovědích podrobně popisuje [RFC 2821] v sekci 4.2. Příkazy SMTP protokolu: HELO – HELO name Pozdrav Hello slouží k identifikaci klienta po připojení na server. Systém a klient se tímto způsobem „dohodnou“, že jsou oba v iniciálním stavu a teprve poté mohou pokračovat v ostatních transakcích. Jako argument name je předáváno úplné doménové jméno klienta. Pokud počítač žádné smysluplné jméno nemá (např. kvůli dynamicky přiřazené IP adrese), musí se identifikovat svojí numerickou IP adresou v hranatých závorkách. Server odpovídá odezvou (250) následovanou svým doménovým jménem. EHLO – EHLO name Pokud klient podporuje rozšířený SMTP protokol (ESMTP), pak se ohlásí pomocí EHLO a v případě negativní odpovědi by měl vyzkoušet původní HELO. Většina soudobých SMTP serverů podporuje obě varianty. Rozdíl spočívá v tom, že v odpovědi na EHLO vrací server seznam implementovaných příkazů z ESMTP protokolu a například také maximální velikost zprávy, kterou je schopen přijmout. - 13 -
2 EMAIL
Diplomová práce
V tomto stádiu je možné odhalit potencionální zneužití služby. Pokud se klient ohlásí jako někdo jiný než ve skutečnosti je, za pomoci DNS dotazu to lze snadno zjistit. Stejně tak pokud uvede neplatnou adresu. MAIL – MAIL FROM: [parametry] Příkaz začíná transakci zprávy. Reverse-path udává emailovou adresu (povinně ve špičatých závorkách), odkud zpráva přišla a MTA na jejím základě nastaví odesilatele na obálce. Za určitých okolností může být hodnota argumentu nulová („<>“), pokud se jedná o odmítnutou zprávu, aby nedošlo k zacyklení. Nepovinné parametry sdělují dodatečné informace o zprávě, např. že přenos bude probíhat v 8-bitovém kódování. Příkaz by měl být vyslán pouze tehdy, když není zpracovávána jiná zpráva, neboť maže údaje na obálce. RCPT – RCPT TO: [parametry] Zapisuje na obálku příjemce zprávy uvedeného v parametru forward-path. Pokud je příjemců více, posílá klient příkaz opakovaně. Volitelně je možné specifikovat i cestu, přes které hostitele bude zpráva předávána (viz [RFC 2821], sekce 4.1.1.3). DATA – DATA Po odeslání příkazu a pozitivní odpovědi (354) server považuje vše následující od klienta za data emailu (tedy hlavičku a tělo). Data by měla obsahovat pouze znaky v 7-bit ASCII kódování. Sekvence „.”, tedy samotná tečka na ukončeném řádku, indikuje konec dat. Poté co server tuto sekvenci obdrží, dochází ke zpracování celé zprávy. RSET – RSET Slouží ke zrušení aktuální transakce zprávy. Všechny informace z obálky musí být vymazány, vrácena pozitivní odpověď (250) a server se vrací do počátečního stavu jako po vyslání EHLO/HELO příkazu. Odeslání příkazu RSET bezprostředně po HELO má ve výsledku stejný efekt jako příkaz NOOP, neboť obálka ještě není naplněna. VRFY – VRFY string Tímto příkazem odesilatel ověřuje, je-li parametr string uživatelským jménem nebo názvem schránky na serveru. String má podobu „User Name “ nebo „local-part@domain“. Návratová hodnota je buď pozitivní (250) a obsahuje uživatelské jméno a adresu schránky nebo pouze adresu, případně negativní (55X) s vysvětlením nesrovnalosti. [BERN1] doporučuje odeslání „neutrální odpovědi“ (252) s obecným textem z bezpečnostních důvodů, neboť tento příkaz může být zneužit pro získání emailových adres ze serveru (příkaz „VRFY *“ by měl vyvolat odpověď se seznamem všech uživatelů serveru). EXPN – EXPN string Dotaz, zda je argument string mailing listem1. Jde o obdobu příkazu VRFY. Odpověď může být víceřádková, obsahující všechny osoby z dotazovaného seznamu. NOOP – NOOP [string] Příkaz se používá k udržení spojení při životě a nemá žádný vliv na ostatní operace. Volitelný parametr je serverem ignorován a pokaždé vrácena pozitivní odpověď. QUIT – QUIT Indikuje, že odesilatel končí přenos a protistrana (server) musí odeslat odpověď a následně uzavřít spojení. Klient musí počkat, dokud od serveru nepřijde odpověď. Příkaz může být použit kdykoliv a v souvislosti s ním jsou přerušeny všechny probíhající transakce. V minimální nutné implementaci jsou podporovány příkazy EHLO, HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT a VRFY. Pro celý mechanismus odeslání zprávy však více méně dostačují HELO, MAIL, RCPT, DATA a QUIT. Činnost protokolu by se dala v zásadě rozdělit do fáze MUA-MTA, kdy je odeslána pošta z počítače uživatele na SMTP server odchozí pošty, a fáze MTA-MTA, ve které dochází k vlastnímu směrování zprávy do cíle. Ve fázi MTA-MTA se vlastně jedná o spojení serveru se 1
Seznam uživatelů, resp. emailových adres, kteří spadají do konkrétní skupiny adresátů příchozí pošty.
- 14 -
2 EMAIL
Diplomová práce
serverem, ale jako klient se chová server, který předává email. Doplňující fázi MTA-MUA pokrývá následně zmíněný protokol POP3. Následující obrázek znázorňuje cestu zprávy v běžném případě. Uživatel dozorce pracuje v zoologické zahradě a jeho počítač má přiděleno jméno dozor.zoo.cz. Napsal email svému kolegovi, který je na stáži v Německu a má účet na serveru tier.de. Doména odesilatele a příjemce je barevně odlišena. Sekvence operací, které proběhnou během zaslání zprávy je popsána následujícími body: 1) Přenos zprávy pomocí protokolu SMTP od uživatele na server v doméně ZOO.CZ (MUA-MTA) 2) DNS dotaz typu MX, kde se SMTP server dotazuje na server pro výměnu pošty v doméně TIER.DE 3) v odpovědi je vrácen seznam MX serverů asociovaných s doménou TIER.DE 4) SMTP přenos zprávy mezi servery (MTA-MTA) 5) stažení zprávy pomocí protokolu POP3 ze serveru k uživateli.
Obrázek 2-1: Běžný přenos zprávy
Fáze MUA-MTA Uživatel napíše ve svém MUA zprávu a odesílá ji adresátovi. MUA se tedy naváže spojení se SMTP serverem naslouchajícím na TCP portu 25. Před vlastním odesláním MUA sestaví základní podobu hlavičky emailu a předá ho serveru. V momentě, kdy server úspěšně přijme zprávu, všechny další operace probíhají již mimo režii MUA. V závislosti na své konfiguraci provede MTA přepis adres a přidá další záznamy do hlavičky. Pošta pro lokální počítač (uživatele) se uloží do příslušného mailboxu a čeká na vyzvednutí adresátem. Zprávy adresované mimo doménu se zařadí do fronty pro odchozí poštu. Tato fronta je v pravidelných intervalech kontrolována a mailserver se pokouší zprávu odeslat. Po úspěšném pokusu je zpráva z fronty odstraněna, případně při odpovědi pokouší maily odeslat. Pokud se zprávu podaří odeslat, je z fronty odstraněna. V opačném případě je zaslána odesílateli zpráva o chybě a dle nastavení časové lhůty (obvykle v řádu desítek hodin až dnů) se server dále snaží zprávu odeslat. Pokud se to nepodaří, pošle server odesílateli zprávu o nedoručitelnosti a zprávu z fronty odstraní.
- 15 -
2 EMAIL
Diplomová práce
Obrázek 2-2: SMTP fáze MUA-MTA
Výpis komunikace mezi klientem (MUA) a SMTP serverem (MTA) může vypadat např. takto: S: C: S: C: S: C: S: C: S: C: C: C: C: C: C: C: C: C: S: C: S:
220 smtp.zoo.cz ESMTP Postfix HELO dozor.zoo.cz 250 Hello dozor MAIL FROM:<[email protected]> 250 Ok RCPT TO: 250 Ok DATA 354 End data with . From: [email protected] To: [email protected] Subject: pozdrav Date: Thu, 21 Nov 2006 11:10:07 +0100 Bud zdrav. Jenom jsem se chtel zeptat, jak se ti dari. Franta . 250 Ok: queued as 123472 QUIT 221 Bye
Nyní se zaměříme na hlavičku zprávy: From: [email protected] To: [email protected] Subject: pozdrav X-Mailer: The Bat v2.78
jsou záhlaví ve zprávě v momentě, kdy odchází z počítače dozor.zoo.cz; po přijetí serverem smtp.zoo.cz bude hlavička vypadat přibližně následovně: Received: from dozor.zoo.cz (dozor.zoo.cz [124.211.3.11]) by smtp.zoo.cz (8.8.5) id 004A21; Thu, 21 Nov 2006 11:10:08 +0100 From: [email protected] To: [email protected] Subject: pozdrav Date: Thu, 21 Nov 2006 11:10:07 +0100 Message-Id: <[email protected]> X-Mailer: The Bat v2.78
Fáze MTA-MTA Poté, co došlo k předání zprávy serveru smtp.zoo.cz, se server snaží doručit zprávu do cílové adresy. Z emailové adresy příjemce separuje doménovou část a provede DNS dotaz na name server v této doméně. Dotaz je typu MX (mail exchange) a v odpovědi jsou vráceny názvy všech serverů pro zpracování pošty, jako plně kvalifikovaná doménová jména, spolu s jejich prioritou. Viz ilustrační výpis získaný příkazem dig. Zvýrazněná část říká, že v cílovém systému jsou dva mail servery s prioritou 10 a 20. Čím nižší číslo, tím vyšší priorita. - 16 -
2 EMAIL
Diplomová práce tier.de. tier.de.
86400 86400
IN IN
MX MX
10 mx.tier.de. 20 mx2.tier.de.
Smtp.zoo.cz naváže spojení s cílovým serverem vyšší priority a pokusí se mu doručit zprávu. Pokud se mu to nepodaří, zkusí použít server s nižší prioritou. Pokud by v DNS tabulce nebyl žádný MX záznam, pokusí se MTA o doručení přímo na IP adresu počítače tier.de, která odpovídá tzv. A záznamu v tabulce DNS (viz [RFC 2821], sekce 5.). Komunikace mezi SMTP servery je pak obdobná situaci, kdy MUA posílá data svému lokálnímu MTA. Přijímající MTA na straně tier.de může být zároveň POP3 serverem, ze kterého může zprávy uživatel číst. Pokud se nejedná o tentýž počítač, dochází ještě k zapsání zprávy na POP3 server.
Obrázek 2-3: MTA-MTA fáze
Když mx.tier.de dokončí zpracování zprávy a uloží ji pro uživatele k vyzvednutí, hlavička došlé zprávy má následující tvar: Received: from smtp.zoo.cz (smtp.zoo.cz [124.211.3.78]) by mx.tier.de (8.8.5/8.7.2) with ESMTP id LAA20869 for ; Thu, 21 Nov 2006 11:12:18 +0100 Received: from dozor.zoo.cz (dozor.zoo.cz [124.211.3.11]) by smtp.zoo.cz (8.8.5) id 004A21; Thu, 21 Nov 2006 11:10:08 +0100 From: [email protected] To: [email protected] Date: Thu, 21 Nov 2006 11:10:07 +0100 Message-Id: <[email protected]> X-Mailer: The Bat v2.78 Subject: pozdrav
Tento poslední soubor hlaviček je ten, který vidí uživatel kollege ve zprávě, když si jí stáhne a přečte. Následuje podrobnější vysvětlení některých záhlaví: Received: from smtp.zoo.cz (smtp.zoo.cz [124.211.3.78])
Tento email byl přijat od počítače s názvem smtp.zoo.cz, který se ve skutečnosti jmenuje smtp.zoo.cz (tj. identifikoval se správně) a má IP adresu 124.211.3.78. by mx.tier.de (8.8.5/8.7.2) with ESMTP id LAA20869
Stroj, který zprávu přijal - mx.tier.de - použil pro zpracování pošty program Sendmail, verze 8.8.5/8.7.2. Zpráva byla přijata s pomocí ESMTP, server jí přiřadil ID (identifikační číslo) LAA20869. To slouží pro interní použití, aby mohl administrátor dohledat zprávu v logsouborech. for ;
- 17 -
2 EMAIL
Diplomová práce
Zpráva byla adresována [email protected]. Mějme na paměti, že tento hlavičkový údaj nemá spojitost s To: řádkou (viz sekce Whatever). Thu, 21 Nov 2006 11:12:18 +0100
Poštovní přenos se uskutečnil ve čtvrtek (Thursday), 21. listopadu (21 Nov) 2006, v 11:12:18 středoevropského času. Received: from dozor.zoo.cz (dozor.zoo.cz [124.211.3.11]) by smtp.zoo.cz (8.8.5) id 004A21; Thu, 21 Nov 2006 11:10:08 +0100 (PST)
Tento řádek dokumentuje předání emailu z dozor.zoo.cz (pracovní stanice dozorce) do smtp.zoo.cz; Stroj odesílající zprávu se ohlásil jako dozor.zoo.cz, což je pravdivá informace, a jeho IP adresa je 124.211.3.11. Na mail serveru běží program sendmail verze 8.8.5, a pro vnitřní použití přiřadil dopisu ID číslo 004A21. Message-Id: <[email protected]>
Zprávě bylo přiřazeno toto ID (strojem smtp.zoo.cz), aby jí bylo možno identifikovat. To se ovšem liší od SMTP a ESMTP ID čísel v položce Received:, protože je přiřazeno zprávě po celou dobu její existence, narozdíl od ostatních ID, které jsou asociované pouze se specifickou poštovní transakcí na konkrétním stroji a nemají žádný význam pro jakýkoliv jiný počítač. Mailgate a firewall Rád bych zmínil ještě několik nestandardních případů, kdy je cesta zprávy komplikovanější, doplněné pro názornost schématem. •
•
Mailgate – v případě větších podniků s rozsáhlejší sítí může existovat více lokálních serverů, které obsluhují elektronickou poštu pro pobočky v jednotlivých městech (v případě zoo.cz např. MTA1 v Praze a MTA2 v Brně) a veškerá pošta z podnikové sítě odchází přes jeden nadřazený server. Obdobně pro příchozí poštu provede tento server rozhodnutí, na který vnitřní server zpráva dále poputuje. Firewall – z bezpečnostních důvodů zprostředkovává komunikaci mezi lokální podnikovou sítí a Internetem stroj nazývaný firewall. Zvenku se všechny počítače ve vnitřní síti jeví jako by měly IP adresu firewallu. Na tomto stroji mohou také fungovat služby pro filtrování pošty a antivirovou kontrolu.
Obrázek 2-4: Mailgate a Firewall
- 18 -
2 EMAIL
Diplomová práce
V obou zmíněných případech – ať už se jedná pouze o bránu „mailgate“, nebo navíc předřazený firewall – přidá každý stupeň při průchodu zprávy do hlavičky další záhlaví Received: Běžně tak putuje zpráva přes 3-5 serverů. Relaying Dalším způsobem, kterým dochází k přenosu emailové zprávy je tzv. mail relaying (předávání pošty, dále budu používat nepřeložený tvar). O odeslání zprávy příjemci se stará „prostředník“ (relay). Takovým prostředníkem je poštovní server, pokud zpracuje mail, jehož odesílatel ani příjemce nejsou lokálními uživateli. Oba se v tomto případě nachází mimo lokální doménu (resp. mimo lokální rozsah IP adres), a poštovní server tak představuje nezúčastněnou třetí stranu celého přenosu. Pokud je relay server zabezpečen a přijímá poštu pouze od počítačů, pro které je určen, je vše v pořádku. Pokud ale relay přijímá k odeslání zprávu aniž by ověřoval identitu odesilatele, jedná se o tzv. „open relay“ a teoreticky by takto odesílaná zpráva neměla být serverem zpracována. Díky tomu, že relay server se nestará o odesilatele, může snadno dojít ke zfalšování zprávy a uvedení nesprávných údajů v hlavičce. Modelový případ pokrývá následující hlavička přijaté zprávy a obrázek 2-4. Received: from prostrednik.com (prostrednik.com [98.134.11.32]) by smtp.zoo.cz (8.8.5) id 004B32 for <[email protected]>; Wed, Nov 30 2006 16:39:50 +0100 (CET) Received: from hidden.com ([104.128.23.111]) by prostrednik.com (8.6.5/8.5.8) with SMTP id LAA12741; Wed, Nov 30 2006 9:16:28 -0500 (EST) From: Anonymous <[email protected]> To: (seznam prijemcu potlacen) Message-Id: <[email protected]> Subject: EASY MONEY!
Odesilatelem zprávy byl podle všeho někdo z domény hidden.com (na obrázku odesilatel z domény1), zpráva byla předána přes prostrednik.com (relay) zprávu cílovému serveru smtp.zoo.cz. To, jak relay naloží s údaji o odesilateli závisí na konkrétním případě. V určitých případech (např. počítač je spam zombií – viz dále) může dokonce vynechat celé záhlaví Received: a tím zcela skrýt pravou identitu odesilatele. Je také dobré si povšimnout, že ID zprávě nepřiřadil odesílající systém hidden.com (který může být MTA, stejně jako MUA), ale až relay.
Obrázek 2-5: Relaying, Open relay
V minulosti byly poštovní servery spadající do kategorie open relay určeny ke zjednodušení posílání pošty např. z domén bez asociovaného SMTP serveru, a řada domácích i zahraničních freemailů fungovala tímto způsobem. S rozmachem spamu byly ale zneužity pro masové rozesílání pošty tento přístup musel být změněn. V případě legitimních serverů bylo třeba zjednat nápravu zavedením nějaké formy autentizace, což je v dnešní době již
- 19 -
2 EMAIL
Diplomová práce
samozřejmost. Mnoho poskytovatelů připojení rovněž zakazuje odchozí komunikaci na portu 25, právě z důvodu použití vnějšího relay serveru serveru pro odchozí poštu. Neoprávněný relaying, zvláště ve větším měřítku, představuje ve své podstatě zneužití cizích prostředků ve svůj prospěch. Díky tomu existují databáze shromažďující IP adresy takto využívaných serverů a na jejich základě je příchozí pošta z těchto zdrojů odmítána. Padělání adresy odesilatele Na konec je třeba zmínit, jakým způsobem lze zfalšovat adresu odesilatele. Úsilí k tomu potřebné závisí na implementaci SMTP serveru a jeho mechanismů, jenž takovému počínání zabraňují. Nejsnadnějším způsobem ke zfalšování adresy je použití právě prostředníka, který se nestará o to, kdo je odesilatelem. Pokud je příjemcem legitimní server, obvykle se pokusí odesilatele identifikovat na základě reverzního DNS dotazu (z číselné IP adresy je získán název domény). Následuje částečně zdařilý pokus o padělání odesilatele jako SMTP relace. C: S: C: S: C: S: C: S: C: C: C: C: S:
HELO somedomain.org 250 smtp.zoo.cz Hello hidden.com [104.128.23.111] MAIL FROM: [email protected] 250 [email protected]. - Sender OK RCPT TO: [email protected] 250 [email protected]. - Recipient OK DATA 354 Enter mail, end with "." on a line by itself From: [email protected] To: (adresa prijemce potlacena) . 250 OAA08777 Message accepted for delivery
Z relace je vidět, že klient se ohlásil jako somedomain.org, ale byl identifikován jako hidden.com. Krom toho, že ohlásil falešnou adresu odesilatele, je v záhlaví „From:“ uvedena zcela jiná adresa. Záhlaví „From:“ obvykle zůstává nezměněno a v tomto případě se liší od hodnoty na obálce, která je generována při odeslání/doručení zprávy. Je v kompetenci serveru odhalit tuto nesrovnalost. Z části hlavičky přijaté zprávy je patrné, že jediná relevantní informace o odesilateli zprávy je v záhlaví Received:. Received: from somedomain.org (hidden.com [104.128.23.115]) by smtp.zoo.cz (8.8.5) for <[email protected]> ... From: [email protected] To: (adresa prijemce potlacena)
Pokud by přijímající server odesilatele dodatečně neidentifikoval a neuvedl jeho pravou adresu v závorce, nebylo by již možné pravou adresu vypátrat.
2.4.2 POP3 (Post Office Protocol, verse 3) Jak již bylo zmíněno, protokol POP3 je určen pro stažení pošty ze serveru do počítače uživatele, což z něj činí komplementární protokol k protokolu SMTP. Ve svojí první specifikaci byl uveden v RFC 918 v roce 1984. V současnosti je standardem verze 3, popsaná v [RFC 1939]. V tomto případě se pod pojmem klient rozumí počítač uživatele, nebo tzv. email klient, resp. MUA, což je program pro odesílání a výběr pošty na straně uživatele (Outlook Express, Mozilla Thunderbird, The Bat, apod.), server je počítač na straně poskytovatele připojení, nebo jednoduše počítač, na kterém běží program pro obsluhu POP3 spojení, naslouchající na portu 110. Účelem je poskytnout uživateli možnost, jak si přečíst svojí poštu na svém počítači. V minulosti díky nákladům na připojení, resp. telefonním poplatkům, nebylo možné udržovat počítač trvale připojen k Internetu. Motivací bylo omezit dobu spojení mezi klientem a - 20 -
2 EMAIL
Diplomová práce
serverem, na kterém se nacházela pošta, na nezbytné minimum. Díky protokolu POP bylo možno svoje zprávy jednoduše dopravit na lokální počítač, odpojit se od serveru, a následně je číst a dále s nimi pracovat ve stavu bez připojení (offline). Hlavní předností protokolu je jeho jednoduchost. Server neposkytuje mnoho komplexních operací s došlou poštou. Omezuje se na nutné minimum příkazů a obsluha „pokročilých operací“ je ponechána v režii klienta. Naopak nevýhodou oproti protokolu IMAP je fakt, že v jednu chvíli může být ke konkrétní schránce připojen pouze jeden klient. Během doby připojení je schránka exkluzivně uzamčena, aby nemohlo dojít k případu, že jiný současně připojený klient smaže zprávy, se kterými je zapotřebí ještě pracovat. Klient je v tomto případě označován jako autoritativní. Po navázání spojení mezi serverem a klientem pošle server pozdrav a poté pracuje protokol ve třech stavech, viz stavový diagram na obrázku 2-4. Příkazy odesílané klientem, které způsobí změnu stavu, jsou přiřazené k jednotlivým hranám.
Obrázek 2-6: Stavový diagram protokolu POP3
Na každý příkaz od klienta (viz níže), který může být velkými i malými písmeny, musí server odpovědět zprávou s prefixem buď „+OK“ nebo „-ERR“ (povinně velkým písmem), v závislosti na stavu provedené operace. Pokud není příkaz podporován, server musí odpovědět negativní zprávou. Jestliže je odpověď serveru na několik řádků, server je povinen ji zakončit znakem „.“ (tečka) na samostatné řádce. Minimální implementace protokolu musí pokrýt příkazy: STAT, LIST, RETR, DELE, NOOP, RSET a QUIT. Nepovinné příkazy jsou: TOP, UIDL, USER, PASS, APOP, AUTH. 1. AUTHORIZATION (stav autorizace) Trvá od navázání spojení klienta se serverem, až do okamžiku, kdy dojde k ověření uživatele. V tomto stavu může klient vyslat pouze určitou množinu příkazů, sloužící právě k jeho autentizaci. Implementace těchto příkazů je volitelná, ale musí být možný alespoň jeden způsob, jak se k serveru přihlásit. Příkazy: • USER name – argumentem name identifikuje uživatele. Při pozitivní odpovědi je očekáván očekáván příkaz PASS, nebo QUIT. • PASS passwd – za předpokladu zadání správného hesla je tímto příkazem dokončena jedna z možností přihlášení a protokol přechází do transakčního stavu. Příkaz očekává pouze jeden argument a v případě více slov oddělených mezerou se bere celý zbytek řádky jako heslo. Nevýhodou tohoto přístupu je, že heslo je v textové podobě a tedy při odposlechu komunikace snadno zneužitelné. • APOP mailbox digest – představuje alternativní formu přihlášení. Argument mailbox identifikuje konkrétní emailovou schránku (zpravidla se jedná opět o uživatelské jméno) a - 21 -
2 EMAIL
Diplomová práce
digest je MD5 hash1. Pokud server podporuje přihlášení tímto způsobem, pošle ve svém iniciálním pozdravu speciální řetězec – časovou značku. Tento řetězec, za který je klientem přidáno heslo, a výsledek je zpracován pomocí MD5 algoritmu, je pak použit jako argument digest. V symbolickém zápisu může mít časová známka tvar „<processid.clock@hostname>”, v konkrétním případě např. „<[email protected]>”. Detailněji bude znázorněno v příkladu níže. Při každém pozdravu po navázání spojení musí server vygenerovat novou časovou známku, která je vždy unikátní. Tímto způsobem je heslo chráněno proti odposlechu a zneužití. • AUTH mechanism - tento příkaz byl dodatečné definován pro zajištění vyššího zabezpečení a vychází z dodatku k protokolu IMAP [RFC 1731]. Jako argument mechanism je použit řetězec identifikující jeden z autentizačních mechanismů protokolu IMAP, např. „KERBEROS_V4“ nebo „SKEY“. Pokud server tento mechanismus podporuje, provede autentizační výměnu s klientem, aby ho identifikoval. Autentizační výměna, specifická pro každý mechanismus, spočívá v tom, že server vyšle řetězec zakódovaný pomocí BASE64 kódování s prefixem „+ “ a klient mu odpoví řetězcem zpracovaným stejným algoritmem. Jakmile dojde k úspěšné výměně a ověření uživatele, je na zbytek dat přenášených v rámci tohoto spojení aplikován vyjednaný ochranný mechanismus (viz [RFC 1734]) . • QUIT – relace mezi klientem a serverem je ukončena, aniž by došlo k přechodu do stavu UPDATE. 2. TRANSACTION (transakční stav) Po autorizaci je protokol v transakčním stavu. V tomto stavu může klient provádět jakékoliv podporované operace s emaily, dokud neodešle příkaz QUIT nebo nedojde k vypršení časového limitu po kterém server ukončí připojení. Příkazy: • STAT – server v pozitivní odpovědi vrací počet zpráv, které jsou na serveru k dispozici spolu s celkovou velikostí (v počtu oktetů). Pokročilejší implementace mohou vracet více informací. • LIST [msg] – výpis dostupných zpráv na serveru v řádcích obsahujících číslo zprávy a její velikost v oktetech. Nepovinný parametr msg umožňuje vypsat informace pouze o jedné konkrétní zprávě. V implementaci není doporučeno, aby odezva na tento příkaz obsahovala více informací. • RETR msg – pokud zpráva s číslem msg na serveru existuje, je odeslána klientovi v úplné podobě, včetně hlavičkových údajů. Zpráva je ukončena opět tečkou na samostatném řádku. Tento příkaz, společně s LIST a DELE, je stěžejním příkazem protokolu. • DELE msg – na základě tohoto příkazu označí POP3 server zprávu msg jako smazanou a nedovolí s ní již dále manipulovat. Ke skutečnému smazání dojde následně až ve stavu UPDATE. • NOOP – slouží pouze k udržování aktivního spojení a server by měl pokaždé vrátit pozitivní odpověď. • RSET – způsobí, že pokud byly některé zprávy označeny jako smazané, je jim tento příznak odstraněn. • QUIT – příkaz způsobí přechod do stavu UPDATE. Volitelně implementované příkazy: • TOP msg n – slouží k vypsání prvních n řádků ze zprávy msg. Řádkům samozřejmě předchází hlavička zprávy. Ačkoliv je ve skupině volitelně implementovaných příkazů, má dle mého názoru nezanedbatelný význam. Zejména proto, že umožňuje MUA stáhnout 1
Message Digest 5 algoritmus ze vstupního řetězce vygeneruje jeho otisk o délce 32 znaků.
- 22 -
2 EMAIL
Diplomová práce
k uživateli pouze hlavičku zprávy a poté ho nechat rozhodnout, zda je žádoucí zprávu přečíst celou nebo jí rovnou smazat1. To výrazně šetří přenosovou kapacitu. • UIDL [msg] – vrací pro všechny dostupné zprávy (případně jednu konkrétní, specifikovanou parametrem msg), unikátní identifikátor. Unikátní označení zprávy slouží k jednoznačnému rozlišení zpráv, protože při každém připojení mohou být zprávy na serveru z příkazu LIST očíslovány jinak (například pokud byly nějaké smazány). Pokud je klient nastaven tak, aby ponechával zprávy na serveru a stahoval jejich kopie, tento princip napomáhá k tomu, aby nestahoval jednu zprávu po smazání její lokální kopie vícekrát. 3. UPDATE (stav aktualizace) V tomto stavu dochází k uvolnění prostředků. Zprávy, které byly označeny jako smazané jsou na serveru odstraněny, mailbox je odemknut a relace je ukončena. Jednoduchá POP3 relace S: C: S:
<server poslouchá na portu 110> +OK xyPOP3 server ready <[email protected]>
Funkce MD5 je aplikována na řetězec "<[email protected]>makak" a výsledný otisk je použit při autentizaci C: S: C: S: C: S: S: S: S: S: C: S: S: S: C: S: S: C: S: C: S: C: S: C,S: S:
APOP dozorce 205d8b5a22db52039d07a3747a86c667 +OK dozorce - 3 messages (5300 octets) STAT +OK 3 5300 LIST +OK 2 messages (5300 octets) 1 780 2 2400 3 2120 . RETR 1 +OK 780 octets <server odesílá celou zprávu 1> . TOP 2 0 <server odesílá pouze hlavičku zprávy 2 (žádný řádek z těla)> . DELE 2 +OK message 2 deleted UIDL 3 +OK 3 000021fa QUIT +OK xyPOP3 server 'Bye!' <server naslouchá na portu 110>
Písmeno S označuje server a písmeno C klienta. Pozdější další rozšíření protokolu bylo specifikováno v [RFC 2449].
2.4.3 IMAP4 (Internet Message Access Protocol, verse 4) IMAP je relativně nový protokol definovaný v [RFC 2060] (jeho poslední revize v [RFC 3501]) a na rozdíl od dvou výše uvedených protokolů je komplikovanější. Popisuje metodu přístupu ke zprávám elektronické pošty, která je uchovávána na serveru a dovoluje, aby klient 1
Takovou vlastnost má například email klient The Bat, www.thebat.cz
- 23 -
2 EMAIL
Diplomová práce
přistupoval na vzdálené úložiště pošty tak, jako by bylo lokální – tedy bez potřeby přenášet zprávy tam a případně zpět. U protokolu POP3, kde pro práci se zprávou musela být tato ze serveru vždy stažena, bylo možno s ní pracovat pouze na konkrétním počítači. Díky absenci tohoto jevu IMAP umožňuje přístup ke zprávám prakticky odkudkoliv. Přispívá k tomu také fakt, že nemálo klientů existuje na bázi webového rozhraní (např. Squirrel Mail), což je v případě POP3 protokolu těžko představitelné. Ke správě poštovní schránky potom postačí libovolný počítač s připojením do Internetu a webový prohlížeč. Poznámka: V dalším textu je pod protokolem IMAP míněna vždy verse 4, revize 1. Spojení IMAP klienta se serverem je obvykle realizováno na portu 143 (v případě zabezpečené varianty přes SSL na portu 993). Protokol IMAP pracuje, stejně jako výše zmíněné protokoly, na systému příkazů (požadavků) a odpovědí. Každý příkaz vyslaný klientem je prefixován unikátním alfanumerickým řetězcem, obvykle v délce několika znaků (např. A0001), nazývaným „značka“ (tag). Tento způsob je aplikován kvůli párování příkazů a jim odpovídajících odpovědí ze strany serveru, neboť klient může vyslat několik příkazů za sebou, aniž by po každém musel čekat na odpověď. Jedinou podmínkou je bezkolizní sled příkazů. Odpovědi od serveru by se daly rozdělit na dvě kategorie jako „výsledek“ (result) a „odezva“ (response). Jsou buď značené (tagged), začínají identifikačním řetězcem a obsahují výsledek odpovídajícího příkazu, nebo jsou neznačené (untagged), začínají hvězdičkou (*), případně jinak, a mají informativní charakter. Kódy indikující stav výsledku: • OK: pozitivní výsledek operace, značený • NO: negativní výsledek; značený indikuje, která operace selhala, neznačený slouží jako obecné upozornění pro klienta o nastalé situaci • BAD: indikuje chybovou zprávu; značený pokud se chyba vztahuje k nějakému příkazu • PREAUTH: server posílá na začátku relace jako indikaci přechodu do autentizovaného stavu; vždy neznačený • BYE: indikuje ukončení relace ze strany serveru; vždy neznačený. Na rozdíl od výsledků, odezvy jsou použity pro sdělení širokého spektra informací klientovi. Odezvy běžně obsahují doplňující text a jsou odesílány bezprostředně jako odpověď na konkrétní příkaz, nebo osamoceně (příkladem budiž informace o příchodu zprávy do schránky během relace. Kódy příslušející odezvě: • ALERT: upozornění pro uživatele IMAP klienta s důležitým sdělením • BADCHARSET: upozornění o chybě při hledání v důsledku nepodporované znakové sady • CAPABILITY: seznam vlastností serveru, obvykle bývá poslán při iniciálním pozdravu. • PARSE: chyba při analýze MIME obsahu nebo těla zprávy • PERMANENTFLAGS: sděluje množinu značek (status flag), které klient může použít • READ-ONLY: schránka je přístupná pouze pro čtení • READ-WRITE: označuje režim schránky čtení-zápis • TRYCREATE: indikace selhání příkazu COPY nebo APPEND který odkazuje na neexistující schránku. • UIDNEXT: odesíláno společně s číselnou hodnotou, která specifikuje unikátní identifikátor pro následující operaci. Identifikátor dovoluje označení zprávy unikátním číslem. • UIDVALIDITY: číslo ve zprávě je použito k potvrzení unikátní identifikace zprávy • UNSEEN: následující číselný identifikátor označuje dosud nepřečtenou zprávu.
- 24 -
2 EMAIL
Diplomová práce
Po navázání spojení se server ohlásí, poté probíhá interakce mezi klientem a serverem. Jako u ostatních protokolů, v každém stavu (obrázek 2-6) může být použita pouze jemu příslušná podmnožina příkazů.
Obrázek 2-7: Stavový diagram protokolu IMAP
Číselným označením ve stavovém diagramu odpovídají akce: 1) Připojení bez předchozí autentizace (pozdrav od serveru OK) 2) Předem autentizované připojení (pozdrav PREAUTH) 3) Odmítnuté připojení (pozdrav BYE) 4) Úspěšné provedení příkazu LOGIN nebo AUTHENTICATE 5) Úspěšné provedení SELECT nebo EXAMINE (otevření schránky) 6) Provedení příkazu CLOSE (uzavření schránky) nebo selhání příkazů z bodu 5) 7) Příkaz LOGOUT, ukončení spojení. Na rozdíl od POP3, kde byly příkazy obvykle zkráceny na 3-4 písmena, IMAP používá jejich nezkrácenou podobu. Přehled některých příkazů protokolu IMAP (rozděleno podle stavů): - Libovolný stav • CAPABILITY: zjištění podporovaných příkazů a možností serveru • NOOP: žádná operace, pouze resetuje čas neaktivity • LOGOUT: konec interakce, ukončení spojení - Neautentizovaný stav • LOGIN: specifikuje uživatelské jméno a heslo použité k autentizaci • AUTHENTICATE: klient žádá server o specifický způsob autentizace • STARTTLS: sdělení pro server, že klient chce použít zabezpečenou variantu spojení. - Autentizovaný stav • SELECT: vybírá jednu ze schránek aby uživatel mohl pracovat se zprávami v ní obsaženými (přechod do stavu otevřené schránky); server v odpovědi doplní informace o stavu schránky (jinak explicitně vynucené příkazem STATUS). • EXAMINE: vybírá jednu ze schránek, ale otevírá ji v režimu pouze pro čtení • CREATE, DELETE, RENAME: příkazy pro vytvoření, smazání, nebo přejmenování schránky • LIST: očekává v odpovědi seznam dostupných schránek, v závislosti na hodnotě argumentu příkazu. • STATUS: požaduje informace o stavu schránky – celkový počet zpráv, počet nepřečtených a nově došlých zpráv. • APPEND: přidá do schránky zprávu - 25 -
2 EMAIL
Diplomová práce
- Schránka otevřena • CLOSE: uzavírá schránku a přechází do autentizovaného stavu. Zprávy ve schránce označené jako smazané jsou smazány. • EXPUNGE: explicitně vynucené smazání označených zpráv • SEARCH: server vyhledá ve schránce všechny zprávy dle zadaného kritéria • FETCH: získá ze schránky informace o zprávě či zprávách specifikovaných jako argument (jejich ID) • STORE: ukládá data asociované se zprávou (nebo zprávami) ve schránce. • COPY: zkopíruje množinu zpráv do specifikované schránky • UID: příkaz dovoluje jeden z příkazů pro operaci se zprávami použít na uvedenou množinu zpráv identifikovaných jejich unikátním číslem. Poznámka: Argumenty příkazů nejsou uvedeny. Pro názornost uvádím vzorovou IMAP relaci. S: C: S: C: S: S: S: S: S: S:
* OK IMAP4rev1 Service Ready a001 login uzivatel HeslO a001 OK LOGIN completed a002 select inbox * 18 EXISTS * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * 2 RECENT * OK [UNSEEN 17] Message 17 is the first unseen message * OK [UIDVALIDITY 3857529045] UIDs valid a002 OK [READ-WRITE] SELECT completed
Uživatel se nalogoval na server metodou jednoduchého přihlášení, vybral schránku „inbox“ a server mu v odpovědi poslal dostupné informace. C: S: S:
a003 SEARCH FLAGGED SINCE 1-Sep-2006 FROM "Makak" * SEARCH 7 10 12 a003 OK SEARCH completed
Dojde k vyhledání zpráv od odesilatele Makak odeslané po datu 1.9. 2006, v odpovědi jsou vrácena jejich čísla. C: S:
S: C: S: S: S: S: C: S: S:
a004 fetch 12 full * 12 FETCH ( ) a004 OK FETCH completed a005 fetch 12 body[header] * 12 FETCH (BODY[HEADER] {342} ) a005 a006 * 12 a006
OK FETCH completed store 12 +flags \deleted FETCH (FLAGS (\Seen \Deleted)) OK +FLAGS completed
Klient provedl dvě z několika možností načtení informací o zprávě, nejdříve v plném tvaru, posléze pouze hlavičky zprávy (viz [RFC 3501]) a následně uložil pro zprávu příznak indikující její smazání. C: S: S:
a007 logout * BYE IMAP4rev1 server terminating connection a007 OK LOGOUT completed
Následně ukončil relaci. - 26 -
2 EMAIL
Diplomová práce
Výhody protokolu POP3 klient je obvykle připojen pouze po dobu stahování nových zpráv ze serveru, naproti tomu IMAP klient udržuje spojení dokud je aktivní uživatelské rozhraní a zprávy jsou ze serveru stahovány na požádání, což je operativnější v případě mnoha nebo velkých nově příchozích zpráv. Zároveň IMAP podporuje model tzv. odpojené schránky (disconected mailbox), kdy je zpráva stažena lokálně, aby nemusel být uživatel permanentně připojen na server a podle změn a operací se zprávou pak dojde k synchronizaci. Protokol umožňuje v případě těla emailu ve formátu MIME složeného z více části stažení pouze jeho konkrétní části, tedy například umožní přečíst text zprávy, aniž by bylo nutné stahovat objemné přílohy. IMAP podporuje připojení více klientů zároveň k jedné schránce a umožňuje tak vytvořit sdílené úložiště zpráv. Zároveň disponuje mechanismem, který umožňuje všem současně připojeným klientům zjistit změny provedené někým jiným (na rozdíl od POP3, který vyžaduje exkluzivní připojení jednoho klienta ke schránce). Status zprávy – informace jestli byla zpráva přečtena, bylo na ni odpovězeno, nebo smazána – je uchováván rovněž na serveru, což opět umožňuje ostatním připojeným klientům zjistit, jaké operace byly se zprávou provedeny. Zároveň některé IMAP servery podporují systém klíčových slov, které je možné přiřadit jednotlivým zprávám pro lepší orientaci (např. Cyrus IMAP server, Courier-IMAP) . Uživatel může mít více „schránek“, které jsou na serveru reprezentované jako složky, a mezi nimi zprávy přesouvat, což vede k lepší orientaci, zjednodušení při třídění, apod. Velkou výhodou je také relativní bezpečnost informací v poště uložené na serveru. Uživatelská stanice je totiž dle mého názoru snáze napadnutelná – ať už chybou uživatele, který spustí škodlivý kód, nebo bezpečnostním nedostatkem – a může dojít k úniku informací, neboť většina virů a škodlivého softwaru používá nalezené lokální kopie emailů jako informační zdroje. Ve srovnání s tím je ve většině případů server „profesionálně“ spravován, zabezpečen, pravidelně zálohován a riziko úniku informací je zcela jistě nižší. Samozřejmě i zde existují výjimky. Další výhodou ve spojení s protokolem IMAP je práce s nevyžádanou poštou. Při prohlížení obsahu schránky nemusí uživatel stahovat spam na lokální počítač, ale může nechtěné zprávy smazat přímo na serveru, což šetří kapacitu síťové linky. Zároveň umožňuje nastavit efektivní zpětnou vazbu mezi serverem a nástrojem pro filtrování spamu, například tak, že uživatel přesune zprávu do vyhrazené složky na kterou je aplikován učící se filtr. Nevýhody Jak již bylo řečeno, v porovnání s protokolem POP3 je IMAP komplikovaný protokol. To vyžaduje více úsilí při implementaci jak aplikace typu klient, tak server. Už jenom proto, aby byl zaručen současný přístup několika klientů ke stejnému účtu. Pokud navíc server nedisponuje kvalitním algoritmem pro hledání zpráv, může to při prohledávání schránky s velkým počtem (objemných) zpráv vyústit v neúměrné zatížení serveru. Pokud je IMAP klient nastaven, aby navíc uchovával kopie odeslaných zpráv na serveru, bývá obvykle zapotřebí přenést tutéž zprávu 2x – jednu do úložiště na IMAP serveru, druhou pro odeslání pomocí SMTP serveru.
2.5 Zabezpečení protokolů Všechny z výše uvedených protokolů přenášejí v základním režimu uživatelské jméno i heslo, potažmo všechna data, v čistém tvaru (jako čitelný text) a to představuje bezpečnostní riziko. Některé routery, přes které se přenášejí pakety po cestě mezi dvěma počítači, totiž nemusí být důvěryhodné a hrozí nebezpečí odposlechu a zneužití protékajících informací třetí - 27 -
2 EMAIL
Diplomová práce
osobou. Proto bylo nutné učinit odpovídající opatření, ať už fáze přihlašování a autentizace, tak celé relace mezi klientem a serverem. Ke každému protokolu existuje několik rozšíření, které zabezpečují určitou část komunikace. Pro zabezpečení celé relace je nejčastěji použito jedno ze dvou řešení: • SSL (Secure Socket Layer) • TLS (Transport Layer Security) SSL je standard vyvinutý firmou Netscape a jeho poslední verze je SSL v3.0 z roku 1996. Z něj vychází jeho následník – TLS – vytvořený IETF1, současně ve verzi 1.1 [RFC 4346]. Vzhledem k tomu, že jsou si oba standardy velmi podobné, bývá jejich označení často zaměňováno. Obě řešení představují vrstvu vloženou mezi aplikační a transportní vrstvu, tedy pod vlastním protokolem, která zajišťuje šifrování dat a autentizační služby.
2.5.1 SSL SSL funguje na principu tzv. asymetrické šifry, kdy se k šifrování používá páru klíčů. Jeden - privátní klíč - slouží k zašifrování informací před jejich odesláním a druhý – veřejný – je použit k jejich dešifrování na straně příjemce. Existuje více algoritmů asymetrického šifrování, nejčastěji používané jsou DSA a RSA.
Obrázek 2-8: Šifrované spojení s SSL
Započetí SSL spojení probíhá na principu tzv. handshake: 1. Klient pošle serveru požadavek na SSL spojení s informacemi o podporovaném šifrování a verzi SSL na jeho straně. 2. Server v odpovědi sdělí jakou verzi a jaký způsob šifrování podporuje a zároveň pošle klientovi svůj certifikát (pokud certifikát nemá, tak svůj veřejný klíč). O výběru konkrétního šifrování rozhoduje klient. Pokud server potřebuje autentizovat klienta, pošle ještě navíc požadavek na jeho certifikát. 3. Pokud klient dostal certifikát (obsahuje veřejný klíč serveru), ověří totožnost serveru u certifikační autority (CA). 4. Za použití předchozích informací klient vytvoří základ šifrovacího klíče pro další komunikaci, zašifruje ho veřejným klíčem serveru a odešle ho na server. Pokud server vyžadoval autentizaci, klient posílá svůj certifikát, rovněž zašifrovaný. 5. Pokud server klienta neautentizoval, relace končí. 6. Server použije svůj soukromý klíč k dešifrování základu klíče od klienta a na obou stranách dojde k vygenerování úplného symetrického šifrovacího klíče, se kterým bude šifrována následující komunikace. 7. Klient posílá serveru informaci, že následující odesílané zprávy budou zašifrovány domluveným klíčem a následně šifrovanou zprávu že jeho handshake fáze je u konce. 8. Server odpovídá obdobným způsobem. 9. Všechna další komunikace je šifrována s použitím dohodnutého symetrického klíče. Podrobnější popis handshake mechanismu je uveden ve specifikaci [SSL].
1
Internet Engineering Task Force, organizace vydávající RFC doporučení.
- 28 -
2 EMAIL
Diplomová práce
V označení protokolu s použitím SSL zabezpečení se používá přípona „s“ a server naslouchá na jiném portu než obvykle (SMTPS port 465, POP3S port 995, IMAPS port 993). Pro plnou funkčnost je samozřejmě předpoklad, že tento způsob komunikace je na obou stranách podporována.
2.5.2 TLS Hlavním rozdílem mezi SSL a TLS je fakt, že TLS poskytuje zabezpečenou vrstvu jako definovanou nadstavbu jednotlivých protokolů. Není třeba rezervovat konkrétní porty pro zabezpečenou komunikaci. Spojení začíná jako nezabezpečené a pokud je TLS na obou stranách podporováno, použití zabezpečovacího mechanismu je vyvoláno konkrétním příkazem klienta („STARTTLS“ u protokolů SMTP a IMAP, „STLS“ u POP3), vyslaným v autentizační fázi. Následně dochází k obdobné „domluvě” mezi klientem a serverem jako v případě SSL, a po úspěšném vyjednání šifrovacího klíče je zbytek spojení je šifrovaný. Použití TLS v kombinaci s SMTP pokrývá [RFC 3207], POP3 a IMAP [RFC 2595]. V případě protokolu SMTP je třeba si uvědomit několik věcí: Zpráva obvykle prochází při cestě do cíle přes více bodů (serverů). To, že mezi dvěma body je používáno zabezpečené spojení, ještě nezaručuje, že bude použito po celé cestě zprávy. Některé MTA např. nemusí TLS mechanismus vůbec podporovat. Z toho důvodu není doporučeno, aby server naslouchající na portu 25 pro příjem zpráv z vnější sítě vyžadoval TLS zabezpečení.
2.5.3 Autentizační mechanismy Pro všechny tři protokoly byl definován autentizační postup, s jehož pomocí je možné se přihlásit na server bez použití hesla v čistém tvaru. Zabezpečené přihlášení může klient vyvolat vysláním příkazu AUTH (nebo AUTHENTICATE) v autentizační fázi, a následným použitím jednoho z podporovaných mechanismů SASL. SASL - Simple Autencitacion and Security Layer, abstraktní vrstva mezi protokoly a autentizačními mechanismy byla definována v RFC 2222, aktualizována v RFC 4422. Disponuje mechanismy PLAIN, LOGIN, CRAM-MD5, EXTERNAL, GSSAPI, SECURID, DIGEST-MD5, a dalšími. Pro každý protokol se podoba autentizace v detailech liší, obecný princip je: C: Požadavek na autentizační výměnu S: Počáteční výzva C: Počáteční odpověď S: Výsledek autentizační výměny
Následující data již jsou chráněna zvoleným mechanismem. U protokolu POP3 je navíc první bezpečnostní nadstavbou příkaz APOP (viz 2.4.2), který umožňuje přihlášení klienta k serveru alternativním způsobem, bez čitelného hesla. Uvedené možnosti zabezpečení mají také své slabiny a nedostatky, ale jejich popis již dle mého názoru nespadá do této práce a vyžádal by si rozsáhlejší analýzu.
2.6 Podpisové certifikáty a šifrování Kromě toho, že lze zabezpečit vlastní přenosy elektronické pošty, je možné zabezpečit i vlastní zprávu šifrováním, případně alespoň zajistit její důvěryhodnost formou digitálního podpisu. To nachází uplatnění hlavně u komunikace s citlivým obsahem, případně tam, kde je
- 29 -
2 EMAIL
Diplomová práce
nutno mít jistotu, že opravdu komunikuji s dotyčnou osobou. Pokud je třeba, jsou na zprávu aplikovány oba postupy tak, že je zpráva nejdříve digitálně podepsána a následně zašifrována. V následujících odstavcích popíši základní principy šifrování zpráv a poté některá použití v praxi. Kryptografické metody se, jak už bylo psáno výše, rozdělují z hlediska existence klíčů na symetrické a asymetrické. Symetrická metoda znamená, že stejný klíč, který byl použit k zašifrování zprávy je použit také k jejímu dešifrování. Z toho vyplývá nutnost předat před začátkem komunikace důvěryhodným způsobem klíč a údaje o použitých algoritmech druhé straně. V současné době je použití algoritmů jako např. DES, 3DES a IDEA na běžně dostupných počítačích takřka bez nároků na čas. Bezpečnost šifry stanovuje tzv. délka klíče udávaná v počtu bitů. Výpočetní doba nutná k rozluštění šifry roste neúměrně délce klíče (viz. [ICA]). Použití symetrického šifrování nese riziko, že při vyzrazení klíče není možné ověřit, že zpráva byla skutečně zašifrována jejím odesilatelem.
Obrázek 2-9: Symetrické šifrování
Naproti tomu asymetrická metoda předpokládá existenci dvou klíčů, z nichž soukromý je v držení uživatele a jemu odpovídající veřejný klíč je k dispozici, či jinak sdělen druhé straně. Přenos zprávy probíhá stejně jako na obrázku Obrázek 2-9, ale šifrovacím klíčem je privátní klíč odesilatele a dešifrování probíhá s pomocí jeho veřejného klíče. Pokud tedy známe vlastníka veřejného klíče, kterým jsme zprávu dešifrovali, známe i odesilatele zprávy. Takto odeslaná zpráva však může být pokládána pouze za podepsanou, nikoliv plně důvěrnou, protože veřejný klíč je znám všem. Pokud ale odesilatel zprávy, použije pro zašifrování zprávy veřejný klíč adresáta, má jistotu, že takto zašifrovanou zprávu si může přečíst pouze její příjemce s pomocí svého privátního klíče. Celý systém využití asymetrické kryptografie pro šifrování a podepisování zpráv funguje tak, že zpráva je nejprve na straně odesilatele podepsána (jeho privátním klíčem) a poté šifrována (veřejným klíčem příjemce). Na straně příjemce je pak nejprve dešifrována a privátním klíčem, čímž je zajištěna adresnost zprávy a poté pomocí veřejného klíče provedena identifikace odesilatele (viz. Obrázek 2-10) .
Obrázek 2-10: Podepsání a zašifrování zprávy asymetrickým šifrováním
V praxi je aplikace asymetrických metod ve srovnání se symetrickými časově náročnější díky své matematické podstatě. Proto obvykle při tvorbě podpisu není šifrována - 30 -
2 EMAIL
Diplomová práce
privátním klíčem zpráva celá, ale pouze její otisk spočtený pomocí funkce hash (např. MD5), která pro každý vstupní řetězec poskytuje otisk s jedinečnou hodnotou. Tento zašifrovaný otisk pak představuje podpis zprávy a je spolu se zprávou zašifrován veřejným klíčem adresáta a odeslán do cíle. Adresát dešifruje zprávu svým klíčem a z její čitelné formy dopočte hash hodnotu a porovná ji s dešifrovanou přijatou hodnotou. Tím dochází k ověření pravosti zprávy. Protože je nutné celou zprávu minimálně jednou zašifrovat asymetricky, pro urychlení výpočtu se používají ještě další principy kombinace se symetrickou metodou (viz. [ICA]). Tolik k obecným principům. Obrázek 2-9 a Obrázek 2-10 jsou upravenou verzí schémat z [ICA]. Praktické použití výše zmíněných metod v konkrétních implementacích popisuji stručně v následujících odstavcích. Hlavní odlišností mezi jednotlivými případy je mimo jiné způsob rozdělení informací ve zprávě. Odesílaná zpráva obsahuje informace o tom, že je zašifrována nebo podepsána buď: • ve svém těle – metody PEM a PGP, které navíc využívají vlastní oddělovací řetězce pro rozpoznání šifrovaných části a vlastní záhlaví obsažené na počátku šifrované části, nebo • v hlavičce zprávy – metody MOSS, S/MIME, kde je obsažena informace o typu šifrování v záhlaví MIME Content-Type:, a obvykle použity hodnoty multipart/encrypted nebo multipart/signed. Metoda PGP navíc umožňuje po svém rozšíření v RFC 2015 využít obou variant. PEM (Privacy Enhancement for Internet Electronic Mail) Jedná se o nejstarší navržený princip, který se v praxi neujal, neboť v době jeho vzniku nebyla pro něj rozšířena programová podpora a následně místo něj byly preferovány konkurenční řešení. Vytvoření šifrované zprávy ze zprávy v libovolném formátu (bez ohledu na kompresi dat a národní znakové sady) se v podstatě skládá ze tří kroků: 1) zpráva je převedena na kanonický tvar, který odpovídá formátu pro SMTP přenos dle RFC 822 (zakončení řádek , US-ASCII kódování, apod.). 2) zpráva je zašifrována a/nebo podepsána a 3) následně je použito kódování base64, aby bylo tělo opět v podobě prostého textu pro přenos. Obdobně, obrácenou aplikací těchto kroků, je v cíli zpráva opět uvedena do původního stavu. Výsledná přenášená zpráva může být několika druhů, v závislosti na tom, jestli je vynechána operace šifrování, kódování, případně zda se jedná o zprávu určenou pro seznam zneplatněných certifikátů (viz. [KOT], sekce PEM). Vlastní PEM zpráva je v těle emailu oddělena řetězci -----(BEGIN|END) PRIVACY-ENHANCED MESSAGE---- a za počátečním řetězcem následuje vlastní PEM hlavička se záhlavími, které specifikují použité certifikáty a podpis. K šifrování je použito náhodně vytvořeného DEK-klíče (generovaný pro každou zprávu zvlášť, symetrický) a tzv. IK-klíče (asymetrický), jehož veřejnou částí příslušející adresátovi je DEK-klíč šifrován. PEM podporuje jak symetrickou (DES, EDE), tak asymetrickou kryptografii (RSA), a je orientován na certifikáty vydané certifikační autoritou (obsahující IKklíč). Každý certifikát je identifikován jménem certifikační autority a sériovým číslem. PEM je definováno v RFC 1421 – 1424. Rozšíření MIME Velmi užitečné rozšíření dosavadních MIME typů v RFC 1847 představují typy obsahu multipart/encrypted a multipart/signed. Jak název napovídá, pro existenci šifrované nebo podepsané zprávy je nutná existence těla z více částí. Tělo se pak skládá z MIME části s vlastním textem zprávy (šifrovaným nebo čistým) a elektronického podpisu, který nese - 31 -
2 EMAIL
Diplomová práce
informace o algoritmech použitých pro výpočet kontrolního součtu a jeho zašifrování, a zároveň identitu odesilatele s jeho veřejným klíčem. Typické záhlaví Content-Type: obsažené v hlavičce emailu a identifikující podepsanou/šifrovanou zprávu vypadá následovně: • podepsaná zpráva Content-Type: multipart/signed; micalg=alg; protocol=type/subtype; boundary=delimiter
•
šifrovaná zpráva Content-Type: multipart/encrypted; protocol=type/subtype; boundary=delimiter
Hodnota alg parametru micalg udává použitý algoritmus pro výpočet kontrolního součtu pro elektronický podpis a type/subtype značí typ kryptografického protokolu (např. application/pkcs7-signature pro S/MIME). Jednotlivé části MIME těla pak mají typickou strukturu, s tím rozdílem, že u podepsané zprávy předchází textová část podpisu a u šifrované zprávy je naopak šifrovaný text na konci, předcházený informacemi o šifrovacích klíčích. Toto rozložení je logické a napomáhá v případě šifrované zprávy jejímu sekvenčnímu zpracování. U podepsané je podpis jako dodatek, proto umístěn na konec. V případě nutnosti zprávu zároveň podepsat i šifrovat se pouze použije hierarchické struktury MIME částí. S/MIME (Secure/Multipurpose Internet Mail Extensions) Toto rozšíření MIME umožňuje podepsání a zašifrování zprávy buď jako jeden celek podle normy PKCS#71, s jednotným typem application/pkcs7-mime. Před odesláním je výchozí zpráva zpracována podle normy PKCS#7, následně zakódována do base64, neboť výstup normy jsou i netisknutelné znaky, a po přidání MIME záhlaví je připravena k odeslání. Nevýhodou je, že pokud MUA adresáta nepodporuje S/MIME, zpráva je jako jeden blok nečitelná. Toto řeší rozdělení těla do dvou MIME částí podobným způsobem, jako bylo uvedeno výše, a použití protokolu application/pkcs7-signature. Podpis podle normy obvykle obsahuje veřejný klíč odesilatele, který je na straně příjemce verifikován (a případně uložen) a na základě toho je možno započít šifrovanou korespondenci. Bez znalosti veřejného klíče příjemce to není možné. Pro výpočet otisku zprávy používá algoritmy MD2, MD5, SHA-1, pro symetrické šifrování DES a 3DES, a pro asymetrické RSA s minimální délkou klíče 512bitů. Vzhledem k tomu, že S/MIME podporují programy z rodiny Mozilla, dá se předpokládat, že s jejich větším rozšířením a potřebou bezpečnosti má tato metoda perspektivu. S/MIME je definováno v RFC 2311 – 2312, PKCS v RFC 2312 – 2315. PGP (Pretty Good Privacy) Princip PGP vytvořil v roce 1991 Američan P. M. Zimmerman jako uživatelsky jednoduchý program dostupný nejširší veřejnosti. Postupně se na vývoji podílelo více lidí a vzhledem k jeho postupnému rozšíření bylo v roce 1998 přijato jako standard OpenPGP definovaný v RFC 2440. V současnosti z OpenPGP vychází mnoho různých implementací, např. opensource2 GnuPGP, nebo placená PGP od firmy PGP Corporation, kterou založila část členů původního vývojového týmu. Základem je program ovládaný z příkazové řádky, který obstarává uchovávání veřejných klíčů i soukromého klíče a vlastní šifrování a podepsání zprávy. Soukromý klíč uživatele je navíc chráněn heslem (passphrase), bez kterého ho nelze použít, což je částečnou ochranou proti jeho zneužití. Klíče nebo spíše certifikáty jsou spravovány v souborech na disku označovaných jako kroužky (rings). Pro soukromé klíče (pokud jich uživatel vygeneruje 1
Public Key Cryptography Standard #7 – kryptografický standard firmy RSA Data Security Inc.; nejpoužívanějším formátem pro ochranu elektronické pošty. Je podporován v poštovních klientech Microsoftu i Netscape a v dalších normách. 2 Zdrojové kódy jsou volně k dispozici pod licencí GPL (General Public License)
- 32 -
2 EMAIL
Diplomová práce
více) slouží jeden a pro veřejné klíče uživatele a ostatních slouží druhý soubor. K publikaci veřejných klíčů uživatelů slouží mimo jiné tzv. key servery, které jsou dostupné po celém světě a kde může uživatel svůj veřejný klíč dát k dispozici ostatním, stejně jako dohledat klíč člověka, se kterým chce komunikovat. Pro asymetrické šifrování je obvykle použit algoritmus RSA (délka klíče 1024bitů), pro symetrické IDEA (128bitů) a otisk zprávy je použita funkce MD5. Vlastní princip šifrování je obdobný jako u výše zmíněných metod. Vygenerovaný MD5 otisk zprávy je zašifrován algoritmem RSA s použitím privátního klíče odesilatele a slouží jako podpis. Ten je přidán ke zprávě a zpráva zkomprimována kompresním algoritmem ZIP. Komprese posiluje kryptografickou bezpečnost, neboť není možné použít slovní vzory v textu při luštění šifry a rovněž je ušetřena část přenosové kapacity. Z náhodně vygenerovaného čísla je vytvořen symetrický klíč pro alg. IDEA, se kterým je zašifrována komprimovaná zpráva. Tento klíč je pak zašifrován veřejným klíčem adresáta a přidán k zašifrované zprávě. Celek je kvůli přenosu přes SMTP převeden do 7bit ASCII a zpráva odeslána (schématické znázornění je k dispozici na [KOT]; podrobnější popis [PGPI]). Původně princip PGP nepoužíval MIME záhlaví a zpráva byla celá v 7bit ASCII, později byly zaregistrovány typy MIME obsahu application/pgp-*, které umožňují í toto použití. PGP je v současnosti jedno z nejpoužívanějších kryptografických rozšíření pro přenos pošty. Určitou nevýhodou je ale fakt, že je založen víceméně na důvěře uživatelů, neboť klíče si generuje každý sám. V případě všech zmíněných zabezpečení užívajících MIME je obvykle ještě do zprávy přidána ještě textová část s informací pro adresáta, jehož MUA nepodporuje šifrování nebo elektronický podpis. Obvykle jako ignorovaný komentář před prvním oddělením jednotlivých částí, nebo text předcházející vlastní zabezpečené tělo.
- 33 -
Diplomová práce
3 SPAM 3.1 Definice Když se řekne slovo „spam“, většina uživatelů, kteří používají elektronickou poštu si vybaví její nevyžádanou podobu. Existuje několik kriterií, co ještě za nevyžádanou poštu považovat a co nikoliv. Individuální přístup k problému se různí. To, co někteří pokládají za spam jsou pro jiné cenné informace. Slovo „spam“ ve spojení s emailem obvykle znamená nevyžádaný hromadný email (UBE – Unsolicited Bulk Email), obvykle komerčního charakteru, označovaný také jako UCE (Unsolicited Comercial Email). Pod pojmem „nevyžádaný“ se rozumí, že příjemce nedal ověřitelný souhlas k odeslání zprávy. „Hromadný“ znamená, že zpráva byla odeslána jako jedna z velkého množství zpráv se stejným obsahem. Definice na [SPAMHAUS] říká: Zpráva je spam, pokud je NEVYŽÁDANÁ a zároveň HROMADNÁ. Oproti tomu nevyžádaný email (první kontakt, dotaz na práci, zboží, apod.), stejně jako hromadný email (komunikace mezi společností a zákazníky, diskusní mailing listy, apod.), je považován za normální. [VIRUSLIST] navíc dodává, že: Spam je ANONYMNÍ nevyžádaný hromadný email. Anonymní v tomto případě znamená s podvrženou nebo nepravou adresou odesilatele, za účelem skrytí jeho identity. Druhá definice je výchozí pro antispamovou legislativu v Evropě i USA (legislativní otázky popisuje sekce 3.5). Nutno podotknout, že velká většina poskytovatelů připojení na světě v současnosti zakazuje a postihuje rozesílání nevyžádané hromadné pošty.
3.2 Podstata spamu Určitě každý, komu na jeho emailovou adresu chodí nějaký spam si v momentě znechucení položil otázku, co je vlastně motivací spammerů k jejich činnosti. Podstata tohoto jednání je velice prostá – finanční profit. Cena emailové kampaně, s cílem prodat určitý výrobek nebo službu, je v porovnání s tradičními prostředky zanedbatelná. Rychlost rozeslání milionů zpráv je vysoká (prakticky omezená pouze rychlostí připojení odesilatele), a i při několikaprocentní úspěšnosti reklamy avizovaného produktu je návratnost investic vysoká. Pro představu postačí srovnání počátečních nákladů - cen seznamů poštovních a emailových adres, které je možno objednat na Internetu: • 6.5 milionu poštovních adres lidí (18-35 let) žijící v USA (zdroj: infousa.com) 208 350 USD • 8.5 milionu emailových adres pracujících lidí (zdroj: buyoptins.com) 750 USD Ačkoliv se na první pohled zdá, že je porovnáváno neporovnatelné, řádový rozdíl těchto čísel již o něčem svědčí. Pokud navíc srovnáme cenu na vytištění a rozeslání dopisů poštou s cenou za internetové připojení + nástroje na hromadné rozesílání elektronické pošty, tento rozdíl ceny se ještě více prohloubí. - 34 -
3 SPAM
Diplomová práce
Pokud je úspěšnost kampaně dejme tomu 2% (což odpovídá počtu potenciálních zákazníků, kteří si produkt nakonec zakoupí), a spammer má za každý kus provizi např. 5$, pak jednoduchou matematikou dostaneme, že z 5 milionů rozeslaných emailů je výsledný profit 500 000$. A to už může být dostatečná motivace pro kohokoliv. Rovněž je třeba si uvědomit, že právě poptávka po nabízených produktech či službách živí tento fenomén. Pokud by lidé produkty nekupovali, snížila by se logicky i výnosnost tohoto druhu obchodu. Spam vlastně přesouvá většinu nákladů na poslání z odesilatele zprávy na jejího příjemce a jeho cílového ISP. Negativní účinek se projeví na příjemci, jeho ISP i páteřní síti. [IMC1] To, jakým způsobem přerostlo rozesílání spamu hranice únosnosti za poslední 4 roky dokládá graf na obrázku 3-1 ze [SPAMOM], který údajně čerpá informace z více zdrojů.
Obrázek 3-1: Procento spamu v elektronické poště za poslední 4 roky
Graf potvrzuje narůstající trend. Statistiky [MSGLABS] za rok 2006 uvádí průměrné procentuelní zastoupení spamu 58% (poměrně optimistická hodnota), statistiky [POSTINI] uvádí průměrnou denní hodnotu okolo 90%. Obvykle jsou jednotlivé statistiky zastoupení spamu v elektronické poště postavený získávány na základě hlášení programů, které tyto společnosti nabízejí jako komerční řešení. Někteří skeptici tvrdí, že v současnosti je podíl spamu v poště až 95%, což je alarmující počet. [POSTINI] zároveň uvádí, že jedno ze dvou SMTP spojení je vyplýtváno na ověření pravosti emailové adresy útočníkem (zhruba 30% prostředků serveru). Zajímavým zjištěním je i fakt, že objem spamu vzrůstá o víkendech (obrázek 3-2, zdroj [MSGLABS]). To může být vysvětleno z různě, například díky levnějším víkendovým tarifům pro připojení do internetu.
- 35 -
3 SPAM
Diplomová práce
Obrázek 3-2: Globální intenzita spamu v rámci měsíce (12/2006)
Největšími světovými rozesilateli spamu jsou podle [SPAMOM] USA a Asijské státy.
3.3 Proč jsem příjemcem spamu? „Jak to, že dostávám tolik spamu, když jsem to po nikom nežádal?“. To je otázka, kterou si klade zřejmě každý méně zkušený uživatel. Mnohdy je odpověď snadná po krátkém zamyšlení (uživatel si uvědomí, že udělal něco špatně), někdy je potřeba vysvětlení. Motivací pro spammery k získávání nových a nových emailových adres jsou samozřejmě opět „ekonomické důvody“, neboť čím více oslovených, tím více potenciálních zákazníků. Jakým způsobem se může emailová adresa octnout na „seznamu“ a jak se k ní dostane spammer popisují následující body. •
•
•
•
Velice jednoduše lze vylákat z netušícího uživatele jeho emailovou adresu pod záminkou, že může vyhrát to nebo ono (nejčastěji finanční sumu, hardware, automobil, apod.) a že mu budou po registraci, či uvedení jeho adresy zaslány další informace. Pro někoho je to lákadlo takové, že pro chvíli zapomene na všechny zásady bezpečnosti. Na některých stránkách je možnost přímo prostřednictvím formuláře zaslat upozornění na zajímavý odkaz, Vánoční pohlednici, apod. na email kamaráda či známého. Uživatel nemá žádnou jistotu, co se s takto zadanými informacemi bude dít po odeslání formuláře. Spammer si může za pár desítek dolarů koupit seznamy několika milionů emailových adres, připravených rovnou k použití v programech pro hromadné odesílání pošty. Při použití vyhledávače Google je možné najít bezpočet nabídek a dokonce i společnosti, které nabízejí mailing listy sestavené přesně na míru pro konkrétní inzerci. Dá se ovšem předpokládat, že ne všechny adresy budou platné. Stejně jako je možné zakoupit zmíněné seznamy, jsou snadno dostupné i programy k vyhledávání a sběru emailových adres. Tyto programy prohlížejí webové stránky a webová diskusní fóra a hledají odkazy typu „mailto:“ a podobné. Jsou schopné nashromáždit desetitisíce adres během hodiny. Pro jejich samočinný chod používají například internetové vyhledávače (Google, Yahoo, apod.) a jejich katalogové služby1, které poskytují takřka nevyčerpatelný zdroj potřebných informací – URL adres.
1
Katalog (directory) je v tomto případě kategorizovaný seznam webových stránek s určitým zaměřením. To usnadňuje hledání konkrétní služby nebo stránky s požadovaným tématem. Příkladem je český http://katalog.seznam.cz nebo zahraniční http://dir.google.net , http://dmoz.org
- 36 -
3 SPAM
•
Diplomová práce
Výsledkem je objemný seznam adres během relativně krátké doby. Program ještě mnohdy doplní seznam o URL adresu odkud byl email vytěžen, aby spammer mohl lépe zacílit kampaň na konkrétní potenciální zákazníky. Další možností je prohledávání veřejných diskusních skupin (newsgroups) založených na protokolu NNTP1. Přispěvovatelé mají mít uveden kontaktní email a pokud je program schopen prohledávat více diskusních skupin současně, je výtěžnost ještě vyšší, než ve výše uvedeném případě (např. 100 000 adres za hodinu) [SPAMSITE].
Jako příklad takových programů mohu uvést produkty „společnosti“ 123hiddensender2, které jsou určeny ke shromažďování emailových adres ze všech možných zdrojů a rovněž program určený k hromadnému rozesílání pošty. Dalších příkladů je mnoho, nabídka nástrojů a informace na stránkách stojí za pozornost, aby si čitatel udělal obrázek o pohledu z druhé strany. Následující dvě metody jsou souhrnně nazývány jako DHA (Directory Harvest Attack, volně přeloženo jako „adresářová těžba“). •
•
Alternativní, avšak místy velmi úspěšnou metodou, jak oslovit co nejvíce potenciálních zákazníků, je použití slovníku ke generování emailových adres. Je to svým způsobem obdoba slovníkového útoku na účty/hesla uživatelů v nějakém systému. Program dostane seznam doménových částí adres a k tomu slovník obvyklých jmen a slov. Spojením slov ze slovníku eventuelně čísel generuje lokální část adresy a na adresu vzniklou v kombinaci s doménovou části ze seznamu odešle email. Hodně z vygenerovaných adres nemusí existovat, ale ověření existence uživatele na cílovém SMTP serveru před odesláním nic nebrání (pomocí příkazu VRFY, pokud ho server podporuje, nebo podle odpovědi serveru na příkaz RCPT TO:). Dopad slovníkové metody je ten, že člověk s „běžnější“ emailovou adresou (s lokální částí obsahující např. „novak“ nebo „dvorak“, v případě zahraničí např. „smith“) dostává obvykle více nevyžádané pošty než ostatní. Tato metoda je úspěšnější u serverů s větším počtem emailových účtů (např. ty, jež poskytují schránku zdarma), neboť tím samozřejmě roste pravděpodobnost, že bude vygenerovaná adresa existovat. Pokud je použita jako doménová část adresy nějaká méně běžná nebo „nalezená“ doména, obvykle je nejúspěšnější omezený slovník obsahující nejběžnější slova typu „info, admin, webmaster,“ apod. Adresa „info@doména“ bývá často automaticky aktivována se zakoupenou doménou. Poslední technikou, která je také podobná útokům na uživatelské účty, je metoda hrubé síly. Lokální části emailové adresy jsou jednoduše generovány náhodně do nějaké omezené délky. Pro řetězce délky 3 nebo 4 znaky může dosahovat určitých výsledků, a mám za to, že spíše než velký záběr může odhalit netypickou emailovou adresu.
Velkým rizikem je stále častější propojení pisatelů virů se spammery. Virus nebo červ používá pro svoje šíření obvykle elektronickou poštu. Po napadení konkrétního počítače se většina z nich snaží získat co nejvíce emailových adres (z uživatelova adresáře, z databázových souborů, dokumentů, apod.) potřebných pro další šíření. Některé verze virů (např. Kebede.F) odesílaly tyto seznamy adres mimo počítač a díky rozšíření některých z nich mohla tímto způsobem vzniknout celkem rozsáhlá databáze emailových adres v nepovolaných rukách. 1 2
Network News Transfer Protocol; Protokol pro přenos zpráv na diskusní server http://www.123hiddensender.com/
- 37 -
3 SPAM
Diplomová práce
Postižený uživatel nemusel pak svou adresu nikde zveřejnit. Stačilo aby se v počítači někoho, s kým vedl korespondenci, dostala adresa do záběru některého z virů. Toto riziko je mnohdy ještě maximalizováno posíláním hromadných emailů mezi skupinou uživatelů. Většinou totiž odesilatel (nebo spíše přeposilatel) hromadného dopisu uvede všechny adresáty pohromadě a jejich adresy jsou zaznamenány v záhlaví zprávy To:. Pokud navíc ještě nevymaže z textu přeposlaného dopisu původní seznam adresátů, mezi kterými se sám nacházel, může se tímto způsobem nahromadit celkem snadno několik desítek adres. Spam zombie Dalším faktorem spolupráce pisatelů škodlivého softwaru (malware) a spammerů je fakt, že velká část virů a trojských koňů obsahuje mechanismy, jak zajistit přístup k napadenému počítači a převzít nad ním kontrolu. Často se tak děje aniž by o tom postižený uživatel věděl. Pokud je jeho počítač připojen k Internetu pevným připojením (a ještě lépe 24hodin denně) stává se tak ideálním prostředkem pro rozesílání spamu (obvykle nazývaným jako „spam zombie“) a zároveň závojem zakrývajícím pravou identitu spammera. Redukovaná verze SMTP serveru, která je na tomto počítači zprovozněna totiž zcela jistě do hlavičky nezaznamená, odkud email pochází a pokud ano, jde obvykle o falešnou adresu. Stopy pak vedou pouze k napadenému počítači. Síť zombií, nazývaná také „bot network“, která je používána mimo rozesílání spamu i k DDoS1 útokům, čítá podle odhadů odborníků celosvětově miliony napadených počítačů. Zajímavou úvahou v tomto směru je práce dvou pánů z univerzity v Calgary (CA), pojednávající o možném vývoji „spam zombií“ do budoucna o jejich důkladnějším zaměření při sběru informací o uživateli napadeného počítače, aby bylo možné na základě těchto informací spammerské techniky ještě více zdokonalit. Více v [ZOMBIES].
3.4 Rozdělení spamu Jelikož termín spam je poměrně obecný, rozhodl jsem se ho popsat z několika úhlů pohledu. Jeho rozdělení podle formy, obsahu a přítomnosti charakteristických prvků.
3.4.1 Podle formy V současnosti nepochybně existuje mnoho forem pro spam, vzhledem k tomu, jak běžným se tento termín stal. Zde zmiňuji ty, které pokládám za podstatné. Email Prvotní a zároveň nejpoužívanější formou nevyžádané pošty je klasický email. Spam v této formě začínal jako reklamní sdělení obvykle prostý text s uvedeným odkazem na stránku s produktem, který nabízel. Díky přirozeným tendencím oddělit tuto nevyžádanou poštu od legitimních (žádaných) zpráv postupně nabyl velmi sofistikovaných podob. Jejich důkladnější popis uvádím níže. Příspěvek v diskusi / návštěvní knize / blogu Od určité doby se začal objevovat spam i v jiných podobách, než jenom jako email. Spammeři propagovali své produkty pomocí automatizovaných skriptů na návštěvních knihách (guestbook) umístěných na různých stránkách, což často vytvořilo knihu nepoužitelnou k původnímu účelu. Cílem takové kampaně ovšem nebyli přímo lidé, jak by se na první pohled mohlo zdát, ale roboti zpracovávající informace pro internetové vyhledávače (např. Google, Yahoo, apod.). Vyhledávače totiž určují pozici stránky ve výsledcích hledání podle faktoru zvaného „page rank“, který je přímo úměrný počtu odkazů z ostatních stránek, 1
Distributed Denial of Service - distribuovaná verze útoku typu „odepření služby“, v praxi realizovaná způsobem, kdy mnoho počítačů vysílá naráz velké množství požadavků na cílový server za účelem jeho přetížení a vyřazení z provozu.
- 38 -
3 SPAM
Diplomová práce
jenž na konkrétní stránku odkazují. Tento faktor lze zvýšit právě automatizovaným odesíláním příspěvků do diskusí, návštěvních knih a blogů. Cílem je co největší počet linků a klíčových slov, odkazujících na propagovanou stránku. Jako opatření proti tomuto počínání byly vyvinuty technologie, které mají za účel co nejvíce znemožnit automatizované odesílání formulářů. Obvykle je přidán nějaký kontrolní prvek. Největšího využití nalezly náhodně generované obrázky s textem, který bylo třeba opsat, aby mohl být formulář odeslán. Příkladem je systém Captcha1, který je právě na tomto principu postaven. Protože však jednoduchý text bylo poměrně snadno rozpoznat technologií OCR, která je neustále zlepšována a vyvíjena, dosáhly podoby obrázků s textem velmi komplexních podob. Do obrázku byl přidán šum, různobarevné pozadí, písmena různě zvlněna, zkroucena a přepsána přes sebe a podobně. Výsledek tohoto „boje“ je ten, že mnoho takto ochráněných služeb spíše komplikuje život jejich uživateli. Prolomitelnost této ochrany i přes její relativně velkou komplexitu dokazuje projekt Breaking visual Captcha2. Někdy je tento systém nahrazen textovou otázkou (například matematického charakteru), která je pro člověka snadno řešitelná. Vyšší spolehlivosti je možné dosáhnout kombinací různých metod na úrovni interakce klient-server, například přidáním timeoutu po odeslání první zprávy, testy na obsah podezřelých slov, přítomnost IP adresy odesilatele formuláře v blacklistu apod. Instant Messaging Poslední forma, kterou je možné zmínit je spam šířící se v rámci služeb pro instant messaging (IM) typu ICQ, MSN Messenger, AOL apod. Principielně jde o to, že robot posílá uživatelům této služby zprávy, které obsahují text a odkaz na webovou stránku. Provozovatelé těchto služeb poskytují uživatelům adresář s možností hledání nových kontaktů na základě kriterií (dle lokality, jazyka, věku …) a díky tomu může být IM spam dobře zacílen. Tato forma byla používána velmi často pro propagaci různých stránek s pornografickým materiálem. Stejně tak dochází pomocí IM k šíření virů (zejména případ ICQ), které posílají odkaz na svou kopii uloženou na Internetu a připravenou ke stažení a spuštění. V současnosti většina klientů umožňuje blokovat posílané odkazy od neznámých uživatelů, což opět místy komplikuje situaci normálním lidem.
3.4.2 Podle obsahu sdělení • • • • •
Vlastní obsah sdělení obsaženého ve spamu lze rozdělit do nejběžnějších kategorií: Stránky pro dospělé – propaguje stránky s pornografickou tématikou Zdraví a léky – obsahuje nabídky různých léků a podpůrných prostředků IT / Software – nabídky softwarových produktů za nízké ceny Finance – nabídky různých finančních služeb, hypoték, dědictví, rychlého zbohatnutí, obchodování na burze apod. Vzdělání – nákup univerzitních diplomů, osvědčení o způsobilosti, aj.
Další možnosti nelze zcela pokládat za spam, i když s ním úzce souvisí: • Phishing – email vydávající se za oznámení instituce, souvisejících s jejími službami, jenž po klientovi žádá sdělení důvěrných informací (číslo účtu, kreditní karty, aj.). Ačkoliv se nejedná o klasický spam, jde o velmi nebezpečnou záležitost, neboť uživatel po kliknutí na odkaz často nevěnuje sdělení dostatečnou pozornost, a že vyzradil osobní informace třetí osobě si uvědomí až v momentě, kdy odeslal vyplněný formulář. • Hoax – šíří poplašnou zprávu, která varuje před nějakým nebezpečím, je „zaručeně pravdou“ a vyzývá k upozornění co největšího počtu dalších uživatelů. O šíření zpráv tohoto typu se starají hlavně sami důvěřiví uživatelé. 1 2
http://www.captcha.net http://www.cs.sfu.ca/~mori/research/gimpy/
- 39 -
3 SPAM
Diplomová práce
Ke každé výše zmíněné kategorii se váže určitá charakteristická množina klíčových slov. Na tomto základě pracuje typ filtrů založených na regulárních výrazech a statistické filtry.
3.4.3 Podle charakteristických znaků (email) Jelikož od dob prvních masových emailů došlo k vývoji na straně antispamových řešení, musí spammeři vynaložit větší úsilí na úspěšný průchod svých zpráv k příjemci. Jako součást analýzy je třeba sledovat i charakteristické znaky u obsahu emailů, potažmo jejich hlaviček. V následujícím popisu charakteristických znaků vycházím ve většině případů ze vzorku několika tisíc emailů, které přišly na mou adresu v posledním roce. Obsah hlavičky emailu Z počátku byl spam odesílán z emailových schránek vytvořených automatickým procesem na nějakém freemailovém serveru, a pak jednorázově použitých pro hromadné odeslání určitého počtu zpráv. Na základě toho přijali provozovatelé určité restrikce při registraci i ve formě omezení počtu odeslaných zpráv za časový úsek a to spammerům situaci ztížilo. V současnosti je většina spamu odesílána buď za pomoci zneužití nezabezpečených SMTP serverů, nebo pomocí spam zombií. Tendence k utajení odesilatele vede zejména v druhém případě k anomáliím v hlavičkových údajích emailu. Na základě těchto příznaků lze s jistou mírou určit, že se jedná o spam. Například zpráva, jejíž jedno záhlaví Received: a Message-ID: vypadá jako Received: from btmx4.sun.com (port=21790 helo=fthkookpukwbl) by cpe-65-24-21-152.columbus.res.rr.com with smtp ... Message-ID: <000901c72e1a$6fae9bd0$012daa3c@fthkookpukwbl>
je pravděpodobně odeslána přes open relay. Dalšími faktory může být např. záhlaví neodpovídající specifikaci, mnoho příjemců s podobnou adresou v záhlaví To:, aj. Program Spamassassin definuje celou sérii testů, které jsou aplikovány na záhlaví 1 zprávy . URL Aby se uživatel mohl avizovaný produkt zakoupit, ve většině případů zpráva obsahuje URL adresu odkazující na konkrétní stránku. V této adrese je síla a slabost zároveň. Na jednu stranu je to jedna z mála cest, jak naplnit podstatu spamu, na stranu druhou identifikátor, který může být použit jako klíč k filtrování nevyžádané pošty. Typický tvar odkazu je přibližně následující: http://[subdoména.]doména.tld/[adresáře/][?unikátní_identifikátor]
Volitelná subdoména je obvykle vygenerovaný řetězec, který je periodicky měněn při odesílání zprávy. Jednotlivé varianty řetězce mají pouze zmást spam filtr, a navodit dojem, že se jedná o jinou adresu. Obsah webové stránky, na kterou takový odkaz směruje, je však stejný. Unikátní identifikátor slouží jako zpětná vazba a může mít 2 významy. Jedna z možností je identifikace emailové schránky, na kterou byl odeslán spam, a která je tímto na reklamním serveru potvrzena jako užívaná. Druhá možnost je identifikace spammera v rámci stránky (internetového obchodu), aby mohl dostat svou provizi. Doména je pak označení nějaké domény a .tld je obecné označení domény nejvyššího řádu (top level domain - .cz, .com, apod.). Na principu porovnání odkazu v těle dokumentu s databází adres, které ukazují na spammerské URL pracují filtry typu Blacklist a budou zmíněny později. 1
http://spamassassin.apache.org/tests_3_1_x.html
- 40 -
3 SPAM
Diplomová práce
Obrázek Prvotním účelem obrázku v těle zprávy bylo oslovit uživatele vizuálně působivou reklamou a přesvědčit k návštěvě stránky. Posléze obrazové přílohy začali spammeři využívat jako prostředku ke zmatení antispamových filtrů. Obrázek je většinou typu GIF nebo PNG a je vložen inline příloha zprávy typu MIME-multipart. Obrázky jsou obvykle velikosti řádově několik kilobytů (kB). Spammeři využívají faktu, že: • text v obrázku je pro filtry pracující na bázi porovnávání textu nečitelný, stejně jako URL adresa zapsaná v emailu jako obrazová informace, • jednoduchým způsobem záměny barevných odstínů nebo přidáním náhodných barevných bodů lze docílit jedinečnosti každé kopie obrázku a tudíž nemožné použití filtrů na bázi signatur (v principu stačí změnit jeden byte aby unikátní signatura nabyla jiných hodnot), • při nasazení filtrů schopných zpracovat obrazové informace je přidání šumu a různobarevných přechodů obrázek stal těžko čitelný, ale pro člověka ještě rozpoznatelný. Inspirací pro znečitelnění obrázků byly metody používané jako ochrana před komentářovým spamem. Takový typ představuje obrázek 3-3.
Obrázek 3-3: Obrázek jako náhrada za text spamu
Během roku 2006 došlo k masivnímu nárůstu odesílání obrázkového spamu (image spam) a v současnosti tvoří podle [MARSHAL] přibližně třetinu veškerých nevyžádaných zpráv. Obrázkový spam představuje zvýšení velikosti zprávy z průměrných 5kB pro text na 1250kB. To se promítá jako zvýšená zátěž na přenosových linkách i serverech. HTML formát Část nebo celý email v HTML formátu je určena MIME záhlavím Content-Type: text/html. Pokud navíc obsahuje obrázky nebo jiné přílohy, je použit typ multipart (viz sekce 2.3.2). Pokud není program pro čtení pošty nastaven jinak a zobrazování HTML povoluje, pak je vždy preferována tato část. Jazyk HTML za normálních okolností použit pro psaní webových stránek a prezentací. V emailu dovoluje použít grafické prvky (vložení obrázků na konkrétní místa, změna barvy pozadí) a zobrazit text jako kurzívu, tučně nebo změněné velikosti. Vzhledem k jeho možnostem a rozšířením není problémem vytvořit složitější návrh konceptu, což činí email - 41 -
3 SPAM
Diplomová práce
více atraktivní pro jeho čtenáře. Není proto divu, že spam se velmi často vyskytuje v tomto formátu. HTML formát je také složitější při zpracování spam filtry a text, který se uživateli jeví při zobrazení zprávy jako smysluplný je v HTML zápisu pro filtr nečitelný. Klasickým případem je použití textu v barvě pozadí a vlastností pro určení pozice textu na stránce. Použití demonstrují následující příklady. Pro názornost je použito nadstavby CSS1. Ve fragmentu HTML zápisu je definováno: <style> BODY { background-color: white; color: black } /* černý text, bílé pozadí */ B { float: left } /* tučné plovoucí vlevo */ I { float: right } /* kurziva plovoucí vpravo */ CAhreG a@p1!V
Uživatel vidí v jednom řádku: Cheap!
V1@GrA
A po převedení těla HTML dokumentu na prostý text vypadá výsledek jako “CAhreGa@p1!V”. Jak je vidět, rozpoznání klíčových slov v tomto textu je velmi obtížné. Rizikem emailu v HTML formátu je potenciální přítomnost skriptů v dokumentu a objektů umístěných mimo zprávu (na Internetu), na které je ve zprávě odkazováno. V minulosti byly objeveny chyby v Internet Exploreru, který používají produkty společnosti Microsoft k renderování HTML obsahu emailu, umožňující spuštění takového kódu na počítači příjemce2. Odkazovaným objektem v dokumentu může být dynamicky generovaný obrázek na stránce spammera, který slouží jako zpětná vazba pro odesilatele, že email byl přečten. Pokud je v prohlížeči pošty povolena funkce náhled, může k zobrazení takto odkazovaných obrázků dojít automaticky. Zobrazování těchto obrázků bývá však obvykle z bezpečnostních důvodů potlačeno. Příklad linkovaného obrázku mimo tělo emailu: 
Obecně lze říci, že používání HTML podoby v emailu je spíše přítěží než užitkem a kromě grafické podoby žádný přínos nepředstavuje. Jako iniciativa odmítnutí emailů v HTML formátu vznikla kampaň s ASCII stuhou3. Tělo emailu z více částí Jedním z dalších triků, jakým se spammer snaží zmást filtr pošty, je vytvoření více MIME částí s různým obsahem s nadějí, že tak bude rozředěn obsah zprávy, případně bude kontrolována pouze jedna z nich. Příkladem může být vložení textu v cizím jazyce (ve smyslu neanglickém) do jedné z částí. V současnosti však většina antispamových filtrů bere v úvahu všechny textové části těla a při výrazné neshodě zprávu penalizuje
1
Cascading Style Sheets – kaskádové styly; rozšíření HTML, které dovoluje odděleně definovat grafickou podobu dokumentu. 2 Chyba zpracování elementu IFRAME - http://www.microsoft.com/technet/security/bulletin/MS01-020.mspx 3 Ascii Ribbon Campaign - http://arc.pasp.de/
- 42 -
3 SPAM
Diplomová práce
3.5 Spam a zákon V momentě, kdy problém spamu přerostl přes určitou mez a přestal být zanedbatelný, objevily se snahy, řešit tuto otázku právní cestou. Došlo k přijetí zákonů, které v zásadě využívají 2 odlišné přístupy k posouzení spamu – OPT-OUT (USA) a OPT-IN (země EU) .
3.5.1 Zákony v Česku a EU – OPT-IN Řešit problém spamu zákonem je poměrně obtížné. Český stát se příliš rozhodovat nemohl - EU se už před naším vstupem bojem se spamem zabývala, a v souvislosti s tím byly vydány následující směrnice: • 1995/46/EC – „Directive on the protection of personal data“ - na ochranu jednotlivců v souvislosti se zpracováním osobních údajů, která byla převzata většinou členských zemí již v roce 1998 a prosazovala dvě základní pravidla – získání osobních údajů korektním způsobem a jejich použití pro předem stanovený účel, k němuž byla data poskytnuta • 2000/31/ES – „Directive on electronic commerce“ - o elektronickém obchodu, jež upravuje určité aspekty služeb informační společnosti a • 2002/58/ES – „Directive on privacy and electronic communications“ - o soukromí a elektronických komunikacích, která určuje pravidla pro zpracování osobních údajů a ochranu soukromí v elektronické komunikaci. Mimo jiné EU uzákonila jediný funkční model OPT-IN, který zavedla většina jejích členských zemí. Celoevropský záměr nakonec přinesl ovoce i v České republice a v roce 2004 byl u nás vydán zákon č. 480/2004 Sb. o některých službách informační společnosti a o změně některých zákonů (zákon o službách informační společnosti), který je často nazýván „antispamovým zákonem“. Úřad pro ochranu osobních údajů (ÚOOÚ), který je pověřen dozorem nad dodržováním příslušných paragrafů zákona, má určitou volnost v rozhodování a může ji využít k postihování obchodních sdělení, která jsou spamem, adresáta obtěžují a způsobují mu zbytečné náklady. Zákon vychází z direktiv EU a jeho dopad byl po jeho vydání u nás o něco přísnější. EU měla dokonce výhrady k aplikaci principu OPT-IN v situaci, kdy někdo už je zákazníkem nějakého podnikatelského subjektu. Model OPT-IN znamená, že nejprve musí adresát vyjádřit svůj souhlas, a teprve na základě toho mu někdo může posílat emaily. Jinými slovy, uživatel má právo „rozhodnout se někam vstoupit“ (proto OPT-IN). Opakem je princip OPT-OUT, kdy má uživatel právo vystoupit – druhá strana může zasílat nevyžádané nabídky a adresát má právo následně korespondenci odmítnout (a druhá strana musí s zasíláním přestat). Náš zákon č. 480/2004 ale aplikoval princip OPT-IN i v případě, že už uživatel něčím zákazníkem je. I v takovém případě musela dotyčná firma získat jeho souhlas. Takže vlastně nezáleželo na tom, zda uživatel je či není zákazníkem - tak jako tak bylo nutné explicitně získat jeho souhlas. A právě zde byla česká úprava přísnější, zatímco EU v tomto ohledu požadovala benevolentnější princip OPT-IN. Z tohoto důvodu byla provedena změna, která se týká právě situace, kdy uživatel je zákazníkem firmy. Pak není nutno aplikovat princip OPT-IN, ale je uplatňován již jen princip OPT-OUT. Formálně jde o změnu zákona č. 480/2004 Sb., vloženou jako vsuvka do novely zákona č. 455/1991 Sb. „o živnostenském podnikání“, která nabyla účinnosti k 1. srpnu 2006. V oblasti nevyžádané pošty se u nás také uplatňují i jiné legislativní normy, jako je např. zákon č. 138/2002 Sb. o regulaci reklamy.
3.5.2 Zákon v USA – OPT-OUT USA jsou typickým zástupcem přístupu OPT-OUT, který je deklarován zákonem CANSPAM neboli „Controlling the Assault of Non-Solicited Pornography and Marketing Act of 2003“ a jenž vstoupil v platnost 1.1.2004. Na rozdíl od legislativy EU tento zákon neřeší - 43 -
3 SPAM
Diplomová práce
paušálně všechny formy šíření spamu, ale je zaměřen pouze na nevyžádanou komerční poštu. Implementace dalších legislativních norem proti spamu se údajně teprve připravuje. Před přijetím tohoto zákona upravovaly jednotlivé státy problematiku spamu individuálně a nebo vůbec. Zákon CAN-SPAM je založen na principu OPT-OUT, což znamená, že nevyžádané obchodní emaily je tedy možné zasílat i bez souhlasu adresáta. V každém takovém emailu mu však musí být dána možnost další zasílání odmítnout. Zákon stanovuje náležitosti reklamního emailu, který musí: • být jasně a zřetelně označen • obsahovat jednoduchý návod pro odhlášení z reklamy • zajistit přijmutí odhlášení nejpozději do 30 dnů od jeho odeslání a nejpozději do 10 dnů po obdržení jej zpracovat a žádné další zprávy nezasílat • uvádět svoji platnou poštovní adresu • nepoužívat falešnou adresu odesilatele, atd. CAN-SPAM také postihuje některé typy podvodného jednání spojené se spamem jako např.: • neautorizované použití chráněného počítače k hromadnému rozesílání komerčních emailů • zneužití chráněného počítače pro přenos hromadných emailů s cílem určit jej jako původce spamu • falšování informací v hlavičce hromadných komerčních emailů a jejich zasílání dál • registrace pěti a více účtů nebo dvou doménových jmen s cílem falšování identity registrujícího a úmyslné použití kombinace těchto účtů k šíření spamu, atd. Nad prováděním a dodržováním zákona dohlíží Federal Trade Commision (FTC). Rozesilateli spamu hrozí pokuta až do výše 11 000 USD a v případě prokázání vícenásobného porušení zákona se přičítají další pokuty a tresty. Přesto, že uvedený zákon řeší problematiku spamu do větších detailů než evropské zákony, které se ji snaží postihnout komplexněji, výskyt odesilatelů spamu je v USA mnohonásobně vyšší než v ostatních zemích světa. Podle informací z www.itu.int/spam z roku 2005, pochází více než 60% spamu z USA, zatímco země EU se na šíření spamu v globálním měřítku podílejí zanedbatelně. Důvodem mohou být právě rozdíly v právní úpravě šíření spamu, kdy se přístup OPT-IN jeví daleko účinnější než OPTOUT používaný v USA.
3.5.3 Mezinárodní iniciativy Ačkoli se většina zemí snaží pomocí vhodných zákonů šíření spamu omezit a potlačit, je globální postih v rámci Internetu velmi složitý. Jde totiž o fenomén bez hranic a ne náhodou se vyskytuje mnoho spamerů právě v zemích, kde na ně tamní zákony nepamatují. Jedinou účinnější metodou jak čelit spamu, je postupovat jednotně v mezinárodním měřítku. Díky této myšlence vzniká řada nadnárodních iniciativ, které se bojem proti spamu intenzívně zabývají. Příkladem jsou: London Action Plan – mezinárodní skupina asi třiceti vládních organizací a dvaceti skupin soukromého sektoru založená v říjnu 2004, jejímž cílem je posílit spolupráci organizací zaměřených na potírání spamu v globálním měřítku. Operation Spam Zombie – mezinárodní iniciativa FTC sdružující 35 vládních organizací z dvaceti zemí za účelem zamezit zneužívání tzv. „zombie“ počítačů k šíření spamu. EU Contact Network of Spam Enforcement Authorities (CNSA) - kontaktní síť úřadů ze třinácti členských zemí EU, usilující o zlepšení spolupráce při potírání „přeshraničního“ spamu v oblasti legislativní i v každodenní praxi. Konkrétním projektem tohoto uskupení je projekt SpotSpam, jež vznikl v roce 2005 a je vyvíjen ve spolupráci Německé asociace - 44 -
3 SPAM
Diplomová práce
poskytovatelů internetových služeb a polské technologické firmy NASK za finanční podpory Evropské komise v rámci programu Safe Internet a také s přispěním programu EMEA firmy Microsoft. Cílem je snadnější uplatnění právních postupů vůči rozesilatelům spamu na mezinárodní úrovni na základě existence databáze a vytvoření vhodného komunikačního nástroje mezi soukromými a veřejnými subjekty v různých zemích za účelem efektivního sběru důkazního materiálu pro zahájení řízení proti spamerům. Jinak řečeno, jde o vhodný nástroj podporující potírání nekalých praktik původců nevyžádané elektronické pošty právní cestou. Existence výše zmíněných a dalších iniciativ, které vyvíjejí společné mezinárodní úsilí s úmyslem potlačit spam, je velmi žádoucí. Je však zcela zřejmé, že bez celosvětového konsensu, který by dokázal sjednotit legislativní i jiná pravidla, je naděje na úspěch ve větším měřítku mizivá.
- 45 -
Diplomová práce
4 FILTROVÁNÍ SPAMU 4.1 Prevence ze strany uživatele Jedním z kroků, jak snížit objem došlého spamu na adresu uživatele je přijetí určitých zásad nakládání s emailovou adresou a zároveň postoj k došlému spamu. Tyto zásady, nebo spíše doporučení, částečně vyplývají z povědomí o způsobu, jakým spammeři adresy získávají. Postup bych z hlediska uživatele označil jako AKTIVNÍ a v následujících bodech je shrnuto, jaké návyky by měl uživatel dodržovat (viz také [RICK1]). Zásady nakládání s emailovou adresou: • Osobní emailovou adresu sdělovat pouze důvěryhodným zdrojům a pro kontakt s ostatními a registrace do různých diskusí používat jinou (sekundární, obětní) schránku. Není problém dodatečně přejít s komunikací na primární adresu, pokud se druhá strana projeví jako důvěryhodná, nebo poštu přeposílat jinam či filtrovat. • Pokud je emailová adresa zveřejněna jako kontaktní informace na webové stránce, je doporučeno ji ochránit před roboty, kteří adresy sbírají. Jistou ochranu představuje zveřejnění v „netypickém“ tvaru, například jako obrázek, nahrazení znaků jinými (opice(zavinac)zoo.cz), přidání řetězců navíc ([email protected]), zakódování adresy pomocí Javascriptu a podobně. Nejlépe v kombinaci s vynecháním aktivního odkazu typu „mailto:“. Techniky jsou podrobněji popsány na [RICK2]. Otázkou zůstává, na kolik jsou autoři nástrojů pro shromažďování adres schopni se tomuto trendu přizpůsobit. • Jako ochranu před adresářovým útokem je třeba zvolit název emailové schránky, který není snadno odhadnutelný, není kombinací běžných slov a případně použít vhodné znaky k jejímu odlišení. Toto doporučení je mírně v kontrastu s požadavkem, aby emailová adresa byla dobře zapamatovatelná. Postoj k došlému spamu: • Brát s rezervou sdělení v došlých zprávách od neznámých odesilatelů. • Nikdy neodpovídat na spam. Adresa bývá obvykle zfalšovaná a pokud nikoliv, pro spammera je to indikace, že je schránka aktivní. • Nereagovat na výzvy ke kliknutí na odkaz slibující odstranění z mailing listu (optout). • Nekupovat avizované výrobky, neboť profit je hnacím motorem spamu. • Nastavit v programu pro čtení pošty bezpečnostní opatření. • Pokud je toho uživatel schopen, měl by po zjištění zdrojové adresy nahlásit ISP její zneužití. To ovšem většina uživatelů z logických důvodů nečiní, neboť to znamená další ztracený čas při konfrontaci se spamem. Vzhledem k tomu, že taková politika ochrany proti spamu není příliš efektivní, hlavní úlohu plní metody z hlediska uživatele PASIVNÍ, kdy ochranné funkce plní software. O tom pojednává zbytek kapitoly 4.
4.2 Umístění filtru Programy sloužící k filtrování spamu, můžeme v zásadě rozdělit na dvě kategorie, v závislosti na místě jejich aplikace. Jedná se o umístění na straně SERVERU a na straně KLIENTA, a v obou případech jsou použité obdobné metody pro identifikaci spamu. Umístění straně serveru - 46 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
Tento přístup znamená integraci antispamových metod do systému pro odchozí a příchozí poštu. Řešení takového typu představuje několik zásadních výhod: • Snižuje zátěž (lokální) sítě, neboť odchycená zpráva již neputuje ze serveru k adresátovi (klientovi). • Dovoluje použití některých metod přímo v procesu přijímání zprávy v rámci SMTP relace, které nejsou na straně klienta aplikovatelné (Greylisting, SPF). Jedinou možnou nevýhodou tohoto přístupu je, že jeho zavedení je zcela závislé na ISP, který poskytuje server pro příchozí / odchozí poštu. Pokud ISP antispamová opatření nepřijme, je třeba k omezení spamu použít druhou variantu. Umístění na straně klienta Použití antispamových filtrů na straně klienta (uživatele) je třeba použít, pokud ISP příchozí poštu nefiltruje, nebo neposkytuje dostatečně účinné řešení. Obvykle je filtrování na straně klienta řešeno pomocí zásuvných modulů (plugins) do MUA, případně jako mezistupeň mezi MUA a MTA na počítači uživatele. Nevýhodou je fakt, že email musí putovat ze serveru ke klientovi a až tam je označen jako spam a zahozen. Toto lokální řešení má prospěch pouze pro jednotlivce a neposkytuje obvykle žádnou zpětnou vazbu pro ostatní uživatele. Díky individuálnímu nastavení snáze vyhoví konkrétním podmínkám uživatele.
4.3 Posouzení účinnosti a přesnosti Před vlastní analýzou jednotlivých metod filtrování spamu je potřeba zmínit, jakým způsobem je posuzována jejich úspěšnost. Klasifikace (rozpoznání) emailu jako spam nebo jako „nespam“ (ham) je doprovázena v obou případech chybou – viz tabulka 4-1.
Tabulka 4-1: Chyby při klasifikaci spamu
Termíny false positive a false negative, normálně označované jako chyba prvního a druhého druhu, vycházejí ze statistické analýzy. Obvykle byly zmiňovány v souvislosti se statistickými filtry (typu Bayes), postupně tento tyto termíny zobecněly pro posouzení úspěšnosti jednotlivých antispamových řešení. Z předchozích termínu vycházejí dvě kriteria pro posouzení filtru: • účinnost – je schopnost filtru detekovat spam, vyčíslená ze vzorku zpráv jako počet false negative klasifikací 1− počet spamu ve vzorku • přesnost – schopnost spolehlivě identifikovat a propustit legitimní zprávu, obdobně počet false positive klasifikací 1− počet legitimních zpráv (hamu ) V obou případech zlomek charakterizuje poměr pro false positive nebo false negative výskyty. U filtrů je pak většinou specifikována účinnost a poměr false positive (obojí po vynásobení 100 v procentech). Správná identifikace legitimní zprávy je totiž mnohdy důležitější, než bezchybné rozpoznání spamu. Je tedy tendence minimalizovat poměr false positive a maximalizovat účinnost.
- 47 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
4.4 Konkrétní metody 4.4.1 Autorizace odesilatele Jedním z přístupů, jak oddělit spam od legitimní pošty, je ověření skutečné identity odesilatele zprávy. S tímto záměrem byly vytvořeny technologie, jejichž cílem je umožnit ověření, že email byl skutečně odeslán tím (uživatelem nebo počítačem), kdo je k tomu oprávněn. Pokud se při tomto ověření neprokáže, že zpráva pochází z předpokládaného zdroje, příjemce na základě této informace může rozhodnout, jak s ní naložit. Např. je považována za podezřelou, zahozena, nebo podrobena dalším testům. Některá z těchto řešení byla založena na komerční bázi, kdy si rozesilatel reklamní pošty zakoupil „licenci“ na identifikační prvek zprávy. Např. firma Habeas1 umožňuje zakoupení práva na vložení haiku do hlavičky zprávy, která ověřuje její pravost a snaží se postihovat neoprávněné uživatele; nebo řešení Sender Score Certified (dříve Bonded Sender), které za peníze nabízí záznam ve svém DNS whitelistu, vůdči kterému dochází k ověření2. S podrobnějším popisem se zaměřím na nekomerční řešení, zejména dve nejznámější – SPF a Domain Keys. V tomto směru si všechny technologie kladou za cíl minimální nároky na změny straně uživatele a jednoduchou možnost ověření na základě komunikace mezi servery, obvykle formou DNS dotazu. SPF a Sender-ID Technologie SPF (Sender Policy Framework, viz [SPF]), stejně jako Sender-ID je nadstavba protokolu SMTP, která umožňuje identifikovat a odmítnout email s falešným odesilatelem. SPF se dostalo do širšího povědomí díky firmě Microsoft, která se snažila prosadit svojí upravenou verzi (známou jako Sender-ID) jako standard. Tento pokus však nevyšel a SPF je ve formě draftu IETF (koncept). Technologie se na základě tohoto kroku rozdělila na dvě i když jde s drobnými odlišnostmi o totéž. Microsoft integruje Sender-ID do svých produktů a stejně jako SPF má řadu zastánců, kteří tuto strategii zavedli. Jedná se mj. o firmy AOL, Google, Hotmail, a další. Identifikace odesilatele probíhá na principu znázorněném na Obrázek 4-1, který je popsán níže. Odesilatel obdobně jako MX záznam o serverech pro příjem pošty zveřejní na svém DNS i záznam SPF, který je v TXT formátu a obsahuje seznam serverů, ze kterých může být v rámci domény odesílána pošta. Oznamuje tak, že pošta, která přichází z jeho domény smí přicházet pouze z těchto zdrojů, jinak se jedná o podvrh. Pro to, aby mohl takový princip úspěšně fungovat je samozřejmě třeba aby přijímající strana byla schopna informaci ověřit. DNS záznam může mít podobu example.org. IN TXT "v=spf1 a mx -all"
kde v= definuje verzi SPF, povolené servery pro odchozí poštu v doméně example.org jsou pouze ty, které odpovídají A a MX záznamům v DNS, a -all znamená, že pokud zpráva nesplňuje předchozí podmínky, měla by být odmítnuta. Alternativou je tzv. softfail (značené jako ~all), který je při nesplnění podmínek vyhodnocen jako podezření a zpráva by měla být podrobena dalším testům. SPF mechanismus umožňuje definovat váhy jednotlivých pravidel s pomocí prefixu + propustit - PASS, může být vynecháno, odmítnout - FAIL, ? neaplikovat žádná omezení - NEUTRAL, nebo ~ tzv. SOFTFAIL jako mezistupeň mezi FAIL a NEUTRAL, 1 2
http://www.habeas.com http://www.bondedsender.org/senderscorecertified/index.php
- 48 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
viz příklad výše a dovoluje ještě větší parametrizaci. Na stránkách projektu je k dispozici generátor SPF záznamů1.
Obrázek 4-1: Sender-ID mechanismus
Schéma na obrázku z [AOT] se vztahuje k Sender-ID, ale vzhledem k podobnosti s SPF je princip takřka totožný. Hlavním rozdílem je fakt, že SPF kontroluje shodu s DNS záznamem vzhledem k doméně nahlášené v příkazu HELO nebo v MAIL FROM:, naproti tomu Sender-ID kontroluje shodu s tzv. PRA (Purported Responsible Address). PRA adresa je výsledkem výběru ze záhlaví Resent-Sender:, Resent-From:, From:, Sender: (přesně v uvedeném pořadí, dokud není nalezena první smysluplná informace). Kroky očíslované na obrázku odpovídají jednotlivým akcím: 1) Odesilatel posílá zprávu příjemci. 2) Příjemce obdrží zprávu. 3) Server pro příchozí poštu ověří, z jaké domény byla odeslána zpráva a zda existuje DNS záznam obsahující SPF informace pro tuto doménu. Pak rozhodne, zda IP adresa souhlasí s povolenými v rámci SPF. 4) Pokud IP adresa souhlasí, zpráva je autentizována a přijata (obdrží pozitivní ohodnocení), v opačném případě je zpráva odmítnuta nebo obdrží negativní ohodnocení, které se uplatní při dalším posuzování zprávy. Výhody • stačí pouze záznam do DNS tabulky • dovoluje odmítnout zprávu již po příkazu MAIL FROM: v rámci SMTP relace Nevýhody • vyšší počet DNS dotazů na zdrojovou doménu (dotaz na SPF, a pak v závislosti na parametrech další dotazy) - může představovat zpomalení • použití DNS záznamu typu TXT, což není úplně čisté řešení. Od roku 2005 sice IANA2 rezervovala pro SPF záznam typu 99, ale bude otázkou delší doby, než se to projeví v implementacích DNS serverů. • všichni uživatelé musí pro odesílání používat pouze některý z oficiálních odesílacích SMTP serverů domény.
1 2
http://old.openspf.org/wizard.html Internet Assigned Numbers Authority – autorita pro přidělování čísel a systémových identifikátorů na internetu
- 49 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
Domain Key Identified Message V tomto případě – zkráceně nazvaném DKIM – se jedná o spojení technologií Domain Keys (vytvořila spol. Yahoo!, [DKEYS]) a Internet Identified Message1 (Cisco) a na rozdíl od SPF jsou předmětem kontroly položky v hlavičce zprávy. Základní charakteristikou je zavedení elektronické signatury, která je uložená jako hodnota v záhlaví DomainKey-Signature: u DK, DKIM-Signature: u DKIM. Signatura obsahuje kryptografická data šifrovaná asymetrickou kryptografií (standardně je použit algoritmus RSA a výsledek pak zakódován metodou BASE64).
Obrázek 4-2: Schéma použití Domain Keys
Mechanismus Domain Keys se skládá z následujících kroků na odesílající a přijímající straně: Na straně odesilatele 1) Setup (nastavení): Vlastník domény vygeneruje pár klíčů (soukromý a veřejný) určených pro podpis všech odchozích zpráv, přičemž je povoleno i více párů klíčů. Veřejný klíč je publikován jako DNS záznam a soukromý klíč je k dispozici pro servery odchozí pošty, které tento mechanismus podporují (na obrázku krok A). 2) Podepsání: Pro každou zprávu odeslanou autorizovaným uživatelem z domény je k vygenerování digitální signatury použit soukromý klíč na serveru odchozí pošty. Tato signatura je přidána jako další záhlaví a zpráva odeslána (krok B). Na straně příjemce 1) Příprava: Systém který přijímá zprávu (za předpokladu podpory Domain Keys) přečte z hlavičky signaturu a adresu ze záhlaví From:. Následně načte veřejný klíč příslušející doméně ze záhlaví From: pomocí DNS dotazu (krok C). 2) Ověření: Veřejný klíč z DNS záznamu je použit k ověření zda byla signatura vygenerována za pomoci odpovídajícího soukromého klíče. To dokazuje, že zpráva skutečně pochází ze systému uvedeného z záhlaví From: a že obsah zprávy nebyl změněn během jejího přenosu. 3) Doručení: Na základě výsledku ověření aplikuje lokální systém odpovídající kroky. Tedy buď zprávu doručí, zahodí, nebo jí podrobí dalšímu zkoumání (krok D).
1
http://www.identifiedmail.com/
- 50 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
Veřejný klíč z kroku 1) na straně odesilatele je uchováván jako DNS záznam typu TXT nikoliv pro celou doménu, ale pro subdoménu _domainkey, navíc doplněnou selektorem. Selektor dovoluje použít pro jednu doménu více veřejných klíčů. Záznam pro doménu zoo.cz pak vypadá jako <selektor>._domainkey.zoo.cz, přičemž selektor je uveden v záhlaví odchozí zprávy. Mechanismus DKIM (viz [DKIM]) je – jak již bylo uvedeno – rozšířením Domain Keys ve veřejné licenci, která byla firmou Yahoo! pro tyto účely uvolněna a má tendenci se stát standardem IETF. Výhody • umožňuje spolehlivěji detekovat doménu, ze které email pochází a tím zabránit úspěchu taktik jako je phishing (pokud domény u kterých hrozí zneužití používají Domain Keys). • snáze lze nalézt vlastníka domény, která byla zneužita a ten se pak může snáze dopátrat počítače, jenž je zdrojem falešné zprávy (nesouhlasí DomainKeys signatura). • zfalšovaná zpráva neputuje dále k adresátovi a je zastavena už na serveru (bohužel, rozhodování je činěno až po jejím převzetí). • metoda je zpětně kompatibilní s existující infrastrukturou pro přenos emailů, a to představuje malé nároky na změny v systému. Nevýhody • vyšší hardwarová náročnost – signatura musí být spočtena pro každou odchozí zprávu • u serverů které modifikují záhlaví From: (např. mailing listy) a tím způsobí její zneplatnění je třeba počítat signaturu ze záhlaví Sender:. • metoda nebere v potaz údaje obálky zprávy (viz 2.4.1) a je díky tomu náchylná na zneužití pomocí tzv. „replay“ útoku (pokud pošlu zprávu sám sobě, vytvořím validní DK a pak ji mohu pomocí opětovného odeslání s jinými údaji na obálce odeslat kamkoliv). Dalšími technologiemi na obdobných principech jako výše uvedené jsou např. HashCash1, Teos2 nebo Tripoli3. Technologie založené na principu identifikace odesilatele jsou bezesporu přínosem při ochraně proti podvrženým emailům a filtrování spamu. Konkrétní řešení však může být úspěšné jenom v té míře, která odpovídá jeho rozšíření. Jinými slovy: Zejména SPF a Domain Keys mají naději na úspěch právě díky široké podpoře, jak na straně internetových společností, které je využívají, tak na straně výrobců software (mailservery, antispamové filtry jako SpamAssassin). Použití SPF a DKI je tedy jistou zárukou pravosti zprávy.
4.4.2 Analýza obsahu textu Jedna z prvních variant filtrů spamu byl filtr, který analyzoval obsah těla emailu na výskyt určitých klíčových slov v textu. Ve spamu se totiž obvykle vyskytovala slova, která odpovídala charakteru komerčního sdělení. Např. pokud obvyklým sdělením je nabídka různých léků, pak email, který obsahuje převahu názvů některých z nich je pravděpodobně spamem. Tento základní princip dal vzniknout více variantám filtrů, založených na analýze textu emailu. 1
http://www.hashcash.org/ http://www.cobb.com/spam/teos/ 3 http://www.pfir.org/tripoli-overview 2
- 51 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
Počáteční obranou spammerů proti detekci klíčových slov ve zprávě bylo použití jejich zkomolených variant, tedy např. místo Viagra výraz V/@GR@. To zachovává čitelnost slova pro člověka, avšak pro program je situace složitější. Regulární výrazy Filtr, který je schopen posoudit více variant slova může být založen na použití regulárních výrazů. Regulární výraz (regular expression) je řetězec, který popisuje množinu odpovídajících řetězců – regulární jazyk. Pojem regulární výraz je úzce spjat s operačním systémem typu Unix, a představuje mocný nástroj k hledání v textu a jeho záměny a je důležitým prvkem pro nástroje v tomto sytému (grep, sed, aj.) stejně jako pro některé programovací jazyky (Perl, Python). Praktické ukázky užití lze najít např. na serveru root.cz1. Pro představu: Pokud bych chtěl detekovat v textu výskyt názvu jednoho ze tří nejběžněji nabízených léků, výraz (viagra|cialis|xanax) nahlásí shodu, pokud tomu tak bude. Výraz sloužící pro vyhledávající několika různých mutací slova „viagra“ může vypadat jako (v[i1/|]{1}(a|@|4)gr(a|@|4)). Celý systém filtru pak může být založen na velkém souboru regulárních výrazů s přiřazenou váhou a po jejich aplikaci na tělo zprávy jsou tyto váhy sečteny a na základě porovnání s mezní hodnotou je rozhodnuto, zda se jedná o spam či nikoliv. Takové vyhodnocení je v tomto případě velmi obecné (pro názornost) a v praxi by nemuselo vždy fungovat. Regulární výrazy mohou být nápomocné při nalezení klíčových slov, ale samy o sobě nestačí. Proto je třeba použít sofistikovanější systém vyhodnocení výskytu určitých slov, jaký nabízí filtry na Bayesovské bázi. Bayesovský filtr Bayesovský filtr je založen na statistickém přístupu. Přístup spočívá v tom, že většina událostí je závislá a pravděpodobnost, že se událost stane v budoucnosti, může být odvozena z jejích předchozích výskytů. Tohoto přístupu je využito pro klasifikaci spamu. Pokud se nějaká část textu vyskytuje často ve spamu a nikoliv v legitimní poště, jedná se s největší pravděpodobností o spam. Jako paměť slouží filtru databáze slov s jejich ohodnocením a tato paměť je dále rozšiřována procesem „učení“. Předpokládejme, že při inicializaci filtru máme k dispozici dvě složky se zprávami. V jedné je pouze spam, ve druhé ham (legitimní pošta). Filtr obě složky zpracuje, z každého emailu vyextrahuje slova, a vypočte pro každé slovo pravděpodobnost, že email obsahující toho slovo je spamem (pspam). množství spamu se slovem X p spam = počet všech zpráv se slovem X Obdobně je spočtena i pravděpodobnost, že slovo obsahuje ham (pham). Na základě obsahu složek, které mu pro naučení předložíme, dojde k zaznamenání pravděpodobností výskytu jednotlivých slov do databáze. Při zpracování příchozího emailu je proveden opět rozbor slov a zjištění jejich pravděpodobností v databázi. Na základě geometrického průměru jednotlivých hodnot pak dojde ke klasifikaci, zda se jedná o spam či nikoliv. Toto je jeden z naivních přístupů. Pro optimalizaci výsledku jsou k posouzení zprávy uvažována pouze slova, jejichž hodnota spamovosti (pravděpodobnosti, že se jedná o spam) se blíží k nule nebo k jedné – tedy vyhraněná slova – a ostatní slova jsou vynechána. Po spočtení celkové pravděpodobnosti je podle nastaveného prahu (např. 0,9) rozhodnuto, že se jedná o spam. Slova jsou posuzována jako co největší souvislé části textu a také obvykle s citlivostí na velikost písmen, neboť např. slovo „money“ napíše i běžný uživatel, zatímco „MONEY!!!” je téměř výhradně doménou spammera. To umožňuje ještě přesnější klasifikaci. 1
http://www.root.cz/serialy/regularni-vyrazy/
- 52 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
Učení filtru probíhá tak, že předložená zpráva která je přímo označená jako spam nebo ham je znovu rozdělena na slova a poté jsou upraveny pravděpodobnosti pro jednotlivá slova za pomoci Bayesova vzorce (viz [WIKI2]). Zpětná vazba, která slouží k učení filtru může být realizována několika způsoby: • na základě vlastního rozhodnutí: filtr se sám naučí na zprávách příchozí pošty, které sám rozpoznal. Vzhledem k tomu, že se může dopustit omylu, je dobré tuto možnost použít pouze v určitých případech. Např. když Bayesovský filtr byl v nejistotě a doplňující filtry rozhodly, že se jedná o spam. • na základě rozhodnutí uživatele: pokud se stane, že spam, který se dostal do schránky mezi legitimní poštu jako false negative, uživatel by měl mít možnost zprávu označit jako spam. A naopak zprávy špatně označené jako spam a separované do zvláštní složky by mělo být možno překlasifikovat za pomoci uživatele – vlastníka schránky. K tomuto účelu skvěle napomáhá protokol IMAP, díky práci se zprávami přímo na serveru. Zprávu je pak možné jednoduše vyjmout/přesunout do složky „spam“ a pak např. periodicky provádět učení filtru na nově přesunutých zprávách. Další možností je zpětnou vazbu od uživatele zajistit zřízením emailových schránek pro tento účel. • pomocí odchozí pošty: samostatné učení na odchozí poště zaručuje, že filtr se adaptuje na komunikaci (množinu slov) příslušnou konkrétnímu uživateli nebo organizaci a tím lze efektivně snížit počet false positive klasifikací. Např. v bankovním sektoru se bude vyskytovat slovo „money“ častěji, než u jiných organizací.
Obrázek 4-3: Učící se Bayesovský filtr
Dosud byla řeč pouze o slovech a jejich pravděpodobnostech. Záběr filtru je však obvykle rozšířen i na ostatní části emailu - záhlaví (Subject:, From:), charakteristické znaky (HTML formát, přítomnost obrázku, URL v těle), apod. a pro každý tento znak rovněž evidovat pravděpodobnost jeho výskytu ve spamu nebo hamu. Obecně bayesovké filtry dosahují účinnosti přes 99% při nízkém počtu false positive klasifikací (pod 0,1%), pokud mají dostatečnou bázi znalostí.
- 53 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
Výhody • posuzování zprávy jako celku z pohledu spamu, tak i z pohledu legitimní pošty, nikoliv na pouze na základě klíčových slov, • pokud se spammer bude chtít vyhnout kritickým klíčovým slovům a použije jejich alternativu (např. „p1ll$” místo „pills“), filtr se přizpůsobí přidáním slova do databáze, • filtr je nezávislý na použitém jazyku, • pokud je filtr použit na straně uživatele, je velmi efektivní, neboť uživatel. Nevýhody • vyžaduje pozornost zejména při iniciálním učení, neboť nenaučený filtr nemá dostatek dat pro přesnou klasifikaci, a dosažení požadované účinnosti je při absenci většího vzorku spamu a hamu dlouhodobější proces. Otrava filtru (Bayesian poisoning) Jednou z možností, jak se spammeři snaží obejít bayesovské filtry je spam „zředěný“ nesouvisejícím běžným textem, který má navodit dojem, že se jedná o legitimní email. Pokud je tento email složen z obrázku a textu, je úspěšnost ještě o něco vyšší. Byly identifikovány dva typy tohoto útoku: • pasivní – o úspěšnosti přidávaných slov neměl spammer žádné informace, • aktivní – emaily obsahovaly zpětnou vazbu v podobě obrázku mimo tělo emailu, který indikoval přečtení emailu. Při přidání náhodného textu k obrázku je zhoršení účinnosti filtru zanedbatelné, avšak při cíleně volených běžných slovech (anglického jazyka) může dojít k jisté degradaci filtru (viz. [WIWU]), obzvláště v kombinaci s aktivním typem útoku. Vzhledem k tomu, že obrázek odkazovaný mimo tělo zprávy je dnes ve většině programů potlačen, snaží se spammeři odhadnout slovník adresáta, aby spam byl klasifikován jako ham, a to je velmi složité. Doplňující informace o problematice poskytuje [VBTN]. CRM114 Jako jedno z doplňujících řešení, které pracuje se statistickým modelem klasifikace dat, zmíním CRM114 (Controllable Regex Mutilator, [CRM]). Ve své podstatě jde o programovací jazyk optimalizovaný pro psaní filtrů na „složité problémy“ jako klasifikace textu. Na rozdíl od Bayesovského přístupu se zaměřuje mimo jednotlivých slov také na fráze o délce až 5 slov a pro zpracování těchto frází používá skrytý Markovův model (HMM1) a rychlejší metody učení. Zmiňuji ho, neboť autor uvádí 99,9% účinnost při použití pro klasifikaci spamu a testy ukazují, že jde o plnohodnotnou alternativu k Bayesovskému filtru. Zároveň je imunní vůči pokusům o „otravu“ filtru2.
4.4.3 Porovnávání signatur Na rozdíl od filtrů s textovou analýzou obsahu detekují tyto filtry spam na základě spočtení kontrolních součtů (signatur) zprávy a dotazu na distribuovanou databázi, ve které jsou tyto součty uloženy. Pokud byla příchozí zpráva již spatřena více ostatními servery, pravděpodobně to bude spam. Tento přístup je však třeba používat opatrně. Princip počítání signatur je např. takový, že je zpráva rozdělena na určité bloky, z bloků je případně odfiltrován proměnlivý obsah (např. URL), a následně spočteny jejich kontrolní součty. V minulosti, kdy většina spamu ještě nevykazovala proměnlivé příznaky 1 2
Hidden Markov Model – statistický model, kde modelovaný systém http://www.virusbtn.com/spambulletin/archive/2006/02/sb200602-poison
- 54 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
v každé jednotlivé zprávě, bylo možné použít jednodušší metody. Obecně je princip výběru bloků pro výpočet kontrolních hodnot různý a konkrétní způsob závisí na implementaci. Jako konkrétní příklad zmíním implementace DCC (Distributed Checksum Clearinghouse) a Virpul’s Razor. DCC generuje množství kontrolních součtů z různých částí příchozích zpráv a lokální DCC klient (umístěný např. na serveru příchozí pošty) odesílá množinu těchto součtů na server, který v odpovědi vrací četnost nahlášení jednotlivých součtů ostatními klienty. Zprávy, jenž byly ohlášeny mnoha zúčastněnými systémy mají nepoměrně vyšší tyto četnosti. Z toho je pak vyvozeno celkové pravděpodobnostní ohodnocení zprávy. DDC vlastně sleduje pouze frekvenci výskytů jednotlivých zpráv a proto může dojít k postihu legitimních hromadných zpráv (např. mailing listy, konference), nikoliv jenom spamu. Aby tomu bylo možno předejít, odesilatel musí být uveden na whitelistu (postih se ho netýká), viz. sekce 4.4.5. Na [DCC] je uvedeno, že vzdálený dotaz na databázi kontrolních součtů představuje výměnu dvou UDP paketů o přibližné velikosti 100B, což je méně než klasický DNS dotaz. I tak ale platí, že DCC klient by měl komunikovat s nejbližším DCC serverem kvůli minimalizaci nákladů (času a síťové zátěže). Virpul’s Razor funguje na podobném principu jako DDC, avšak poskytuje navíc mechanismus k nahlášení zprávy, která není spamem, autorizovaným přispěvovatelem. Váhy spolehlivosti každého přispěvovatele jsou spojeny se zprávami o četnosti výskytu a označení od přispěvovatelů je bráno s větší vahou než jednorázové nahlášení výskytu. Tato vlastnost může být místy nepraktická, neboť nahlášení spamu může představovat určité zpoždění. Nevýhodou těchto metod je, že musí existovat skupina „obětních beránků“, tedy uživatelů, kterým spam přijde do schránky. Pokud je adresa na malém spam-listu (tedy zprávy se stejným obsahem jsou adresovány „malému“ počtu adresátů), nebo na počátku seznamu příjemců (dejme tomu [email protected] - a tedy nějakou dobu trvá, než si zpráva vybuduje negativní reputaci), mohou tyto metody fungovat nedostatečně. Vždy ale trvá jistou dobu, než začne metoda pro konkrétní zprávu účinkovat. K minimalizaci počtu těchto obětních beránků a rychlejšímu náběhu účinnosti se používá systému tzv. návnad (decoy boxes, honeypots), což jsou v podstatě emailové schránky přitahující spammery. Schránka má „atraktivní“ název (např. [email protected]), je zveřejněna na různých pochybných místech a podobně, avšak namísto lidského majitele je součástí rozsáhlé sítě schránek, která zásobuje systém pro analýzu spamu. Takovou technologii používá mnoho komerčních i neplacených sítí pro získání náskoku před spammery. Systém dává možnost analyzovat zprávu ještě dříve, než se dostane do legitimní emailové schránky a předejít tomu přidáním jejích signatur, pravidel, či uložení do blacklistu (viz. níže). Posunutí systému návnad do vyšší úrovně je zřízení přímo „falešné open relay“, jak je popsáno v [DECOY]. Článek je sice staršího data, ale kompletně popisuje nastavení takové relay, která ve skutečnosti zprávy nepřeposílá a místo toho shromažduje informace o jejích zneuživatelích. Tento způsob je velmi efektivní jak při detekci IP adres jako zdrojů spamu, tak při analýze přijímaných zpráv a tato data obvykle přispívají k aktualizacím některých blacklistů.
4.4.4 Blacklist Blacklist, jak už název napovídá představuje černou listinu (seznam) IP adres či doménových jmen – nebo obecně „zdrojů“ – odkud pochází spam. Na základě existujícího záznamu v tomto seznamu je se zprávou naloženo odpovídajícím způsobem a je odmítnuta nebo zahozena. Tyto seznamy jsou stejně jako v předchozím případě distribuované a existuje celá řada jejich provozovatelů a poskytovatelů (komerční i neplacené). - 55 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
Naproti tomu kdokoliv může mít vlastní lokální blacklist nežádaných příjemců. Na principu lokálního (nebo spíše uživatelského) blacklistu bylo založeno v prvotní fázi filtrování pošty na největších českých freemailech, kdy měl uživatel možnost přidávat adresy, ze kterých spam chodil na svůj seznam. To se ale velmi brzy projevilo jako neúčinné, neboť obvykle z jedné zdrojové adresy vícekrát do uživatelovy schránky email nepřišel. V dnešní době je většina blacklistů obecně nazývána RBL (Realtime Blackhole Lists) nebo DNSBL (DNS blacklist), zkratky názvů jsou interpretovány různě. Předpona DNS vypovídá o způsobu dotazu na existenci záznamu v nich. Princip dotazu je ve většině případů přibližně následující: 1) MTA vezme IP adresu připojeného klienta, např. 192.168.12.34, a obrátí pořadí bytů adresy, z čehož vznikne 34.12.168.192. 2) Vzniklá adresa je přidána jako předpona k názvu DNS blacklistu 34.12.168.192.reliable.blacklist.org 3) MTA vysílá DNS dotaz na toto doménové jméno (záznam typu „A“). Návratová hodnota je buď „NXDOMAIN“, když doména v záznamu neexistuje, nebo je vrácena IP adresa. V případě kombinovaného blacklistu na serveru spamhaus.org obvykle ve tvaru 127.0.0.X, kde X indikuje zdrojový seznam, ze kterého adresa pochází. Základní kategorie blacklistů rozlišuji podle výskytu IP adresy v rámci SMTP relace na dvě kategorie, které dále popíšu. IP adresa je zdrojem zprávy Počítač s IP adresou obsaženou na konkrétním blacklistu je přímým odesilatelem (ten, který navazuje spojení se serverem pro příchozí poštu) nebo původcem zprávy (je uveden v hlavičce Received:). V prvním případě je možné ze strany serveru odmítnout na základě přítomnosti adresy v blacklistu ještě před obdržením celé zprávy a ušetřit tím zátěž. Ve druhém případě dochází k detekci až po přijetí celé zprávy a pak je možno zprávu zahodit nebo přesunout do složky pro spam. Takovýchto blacklistů je více druhů, podle toho, do jaké skupiny počítačů uvedená IP adresa spadá. Pro představu uvádím několik typů: • Open proxy (HTTP, SMTP) – seznam otevřených proxy serverů, • Spam zombies – počítače identifikované jako spam zombies, • Direct sources of spam – přímé zdroje spamu • RFC ignorant – seznam serverů, které nerespektují doporučení RFC pro posílání pošty, • Policy block list – domény, ze kterých dle jejich vlastníků není odesílána pošta. Běžný přístup je sjednotit informace z dílčích blacklistů do jednoho kombinovaného, aby MTA nemusel posílat zbytečně mnoho dotazů. Poskytovatelů takovýchto blacklistů je více. V minulosti byla existence blacklistů s IP adresami zdrojů spamu spojena s komplikacemi a vysokou mírou false-positive detekcí při jejich použití. Hlavním důvodem byla dle mého soudu pomalá celosvětová adaptace na striktní antispamovou politiku, kdy se mnoho významnějších serverů projevilo jako nedostatečně zabezpečených proti neoprávněnému posílání pošty (z domácích například seznam.cz1) a díky tomu se dostaly na některé z blacklistů. Nyní je situace o mnoho lepší, blacklisty se snaží zachovávat co nejvyšší spolehlivost, ale i přesto je v určitých případech vhodné brát záznam v blacklistu jako doplňující informaci při celkové klasifikaci zprávy. Adresa je uvedena v těle zprávy 1
http://www.lupa.cz/clanky/seznam-idealni-pro-spammery/
- 56 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
Druhou kategorií je seznam adres, které jsou obsaženy v těle zprávy (většinou jako aktivní odkaz), nazývaný jako URIBL (Uniform Resource Indentifier blocklist). Adresy v něm uvedené náleží serverům, které poskytují služby se spamem spojené – tedy hlavně prodej inzerovaného zboží nebo nabídku služeb. Tyto adresy bývají ve většině případů uvedeny ve jmenném tvaru a jsou nazývány jako „spamvertised domains“ (od slova advertised, tedy domény inzerované ve spamu). Jak již bylo řečeno v sekci o charakteristice spamu, existence takových odkazů ve zprávě je hlavním indikátorem, že se jedná o spam. Z toho důvodu jsou blacklisty tohoto typu velmi užitečné. DNS dotaz na blacklist probíhá stejným způsobem jako v předchozím případě, s jediným rozdílem, že místo číselné IP adresy je většinou uveden její upravený jmenný tvar (rovněž uvedený „pozpátku“, nebo v normální podobě). Vzhledem k tomu, že spammeři používají pro odlišení URL náhodné předpony adres třetího řádu a také náhodné adresáře, úprava doménového jména spočívá v jeho redukci na tvar „domain.tld“ (tedy např. belovedspam.com). Jelikož spammeři obvykle používají nově zaregistrovanou doménu poměrně krátkou dobu po její registraci (právě díky blacklistům) a pak přecházejí na další, bývá v seznamech obvykle zohledněno i stáří adresy, dohledané v databázi registrátora. V případech, že se na blacklist dostane adresa omylem, má její vlastník nebo provozovatel – pokud se dostatečně důvěryhodně prokáže – obvykle možnost požádat o její odstranění. Ostatní záznamy jsou z blacklistu odstraňovány vždy po určité expirační době. Protože v minulosti bylo podniknuto mnoho útoků typu DoS (Denial of Service) na servery provozující blacklisty, a v několika případech došlo na jejich základě k ukončení provozu, je cílem poskytnout rozsáhlejší celosvětovou síť DNS serverů tohoto typu (Obrázek 4-4). To zamezí úplnému výpadku služby při takovém útoku a rovněž i zkrácení doby dotazu, který je směrován na geograficky nejbližší mirror-server (server s tímtéž obsahem, pouze na jiném stroji). Některé blacklisty poskytují také možnost vzdálené synchronizace pomocí systému rsync, pro případ, že by někdo chtěl provozovat vlastní mirror, nebo pro větší organizace, pro něž by díky nadměrnému počtu průchozích zpráv představovaly DNS dotazy přílišné zpomalení. Tato služba pro větší organizace bývá na rozdíl od jiných placená.
Tabulka 4-2: Bězně používané blacklisty
Velmi obsáhlý seznam blacklistů je k dispozici na [DECLUDE].
- 57 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
Obrázek 4-4: Topologie sítě DNSBL serverů spamhaus.org
Výhodou blacklistů je možnost odmítnutí zprávy ještě před jejím převzetím a díky tomu ušetřit prostředky serveru. Naopak nevýhodou je při použití méně spolehlivého zdroje vyšší náchylnost k false positive detekcím.
4.4.5 Whitelist Systém na bázi whitelistů je opakem k blacklistu, jak sám název napovídá. Oproti distribuovaným blacklistům se ale v tomto případě jedná o lokální databázi (seznam) adres, na které nejsou aplikována pravidla pro filtrování příchozí pošty. Důvodů k udržování těchto seznamů může být mnoho, ale největší uplatnění vidím ve vypuštění korespondujících osob ze známých domén z antispamových testů. Zároveň lze tímto způsobem zohlednit hromadné emaily z konferencí, které by mohly být pokládány jinak za spam. Dle statistik je většina zpráv, které odesílající uživatel napíše je adresována osobám, se kterými udržuje komunikaci. Je zde určitá motivace zprávy od těchto osob z filtrování vyjmout. Proto je whitelist obvykle koncipován jako „per-user“ (pro každého uživatele zvlášť), neboť co jednomu může připadat jako spam, někdo jiný si rád přečte a sám o to projeví zájem přihlášením do nějakého mailing listu. Chalenge-Response Tato metoda, název přeložen jako „výzva a odpověď“, je založena na principu uvedení odesilatele na whitelist na základě jeho dodatečného potvrzení. Téměř žádný spam totiž není odeslán člověkem sedícím za počítačem, ale odesílání probíhá automatizovaně. Metoda využívá nedokonalosti těchto automatizovaných postupů a jejich neschopnosti vygenerovat dodatečnou odezvu. Pokud má uživatel aktivovaná challenge response mechanismus, je odesílateli vždy zaslána zpráva vyžadující na webové stránce přepsání unikátního řetězce z obrázku do formuláře. Pokud se tak stane, zpráva je doručena a uživatel dočasně, případně trvale přidán na whitelist. Pokud ne, je uchována v izolované části systému1. Takový přístup je však nepříliš šetrný, i když může nést své ovoce, neboť téměř vždy se u spamu jedná o falešnou adresu odesilatele. Výzvu k potvrzení pak dostane někdo úplně jiný, případně pokud adresa v cílovém systému neexistuje, je email odmítnut a to představuje další zprávu navíc. Navíc pokud uživatel obdrží automatizovanou zprávu
1
Taková vlastnost je integrována například u produktu Merak Mail Serveru; viz. http://www.icewarp.cz
- 58 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
např. z elektronického obchodu, odesílající systém nemá jak odpovědět. Tímto způsobem je zbytečně generován provoz mimo lokální síť. Hlavním přínosem whitelistů je díky vynechání filtrů šetření prostředků serveru a zároveň minimalizace false positive detekcí zpráv, které z nějakého důvodu dostávají vyšší pravděpodobnost spamovosti, i když by neměly. Jistou formu whitelistu dnes většina dostupných řešení.
4.4.6 Greylisting Alternativním přístupem, který se nachází na pomezí mezi white- a black-listy, je tzv. greylisting. Jedná se o metodu navrženou Evanem Harrisem, která je určena k nasazení na straně serveru a aplikaci ještě v rámci SMTP relace. Ke svojí funkci využívá právě vlastnost (či spíše stav) SMTP protokolu zvaný „dočasné odmítnutí“ (temporary reject) z množiny dočasných chyb serveru s kódem 45X (X je decimální cifra). Za normálních okolností, pokud odesílající počítač obdrží od přijímajícího MTA zprávu s tímto kódem např.: 450 Mailbox unavailable, try again later.
snaží se opakovaně, vždy po uplynutí určitého časového limitu tuto zprávu znovu doručit. Velká většina programů pro posílání spamu je psána s ohledem na rychlost a efektivitu, obsahuje pouze minimální nutnou podmnožinu SMTP mechanismů, a tuto výjimku nedokáže korektně ošetřit – k opětovnému odeslání zprávy již nedojde. Stejně tak je tomu u SMTP motorů různých virů a červů, redukovaných ze zcela zřejmého důvodu – snížení velikosti kódu. Pro funkčnost systému je třeba evidovat základní trojici informací (triplet): 1) IP adresu klienta (stroje, který se pokouší o doručení), 2) odesilatele z SMTP obálky, 3) příjemce z STMP obálky. V momentě, kdy odesílající stroj oznámí potřebné informace, a triplet nebyl dosud evidován (není nalezen v databázi), dojde k odmítnutí s dočasnou chybou a záznam do greylistu. Následné další žádosti o doručení jsou po stanovený čas odmítány. Pokud se po této době odesilatel pokusí znovu zprávu doručit, je jeho triplet přeřazen do whitelistu, kde zůstává po určitou dobu (řádově desítky dnů) a nadále se na něj již omezení nevztahuje. Po příchodu emailu z již evidované adresy, je obvykle obnovena expirační doba záznamu (viz. [GREY]).
Obrázek 4-5: Diagram Greylistingu
V praxi se může stát, že odesilatel disponuje několika MX servery a ty se budou střídavě pokoušet o odeslání. To je možné zohlednit a nevyžadovat přímou shodu IP adresy ale pouze její části (např. 24 nejdůležitějších bitů). Stejně tak u mailing listů, které
- 59 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
používají metodu VERP1 pro zjištění existence cílové adresy by se měla brát v potaz pouze doménová část adresy odesilatele na obálce. Díky tomu, že jsem se obdobný princip tohoto systému pokusil implementovat, některé podrobnosti ohledně funkčnosti a nastavení parametrů budou probrány později. Výhody a nevýhody Vzhledem k tomu, že rozesílání spamu probíhá nárazově ve velkých množstvích, obvykle je poměrně brzo uvedena IP adresa odesilatele na některém z blacklistů. Úvodní zdržení metodou greylistingu je výhodou v těchto případech. Po opětovném doručení po určité době sice email skrz greylisting projde, avšak již je zachycen pomocí blacklistu, nebo pokud je dotaz na blacklist greylistu předřazen, je odesilatel odmítnut ještě dříve. Počáteční zdržení se projeví pouze při přijetí prvního emailu od konkrétního odesilatele, následná komunikace již zpožděná není. Greylisting výrazně šetří zátěž serveru, neboť dovoluje většinu nevyžádané pošty odmítnout ještě před převzetím vlastního těla zprávy, pouze za cenu nákladů na udržování databáze. Nevýhodou může být fakt, že i určité množství legitimních serverů nemusí důsledně dodržovat doporučení RFC a mohou považovat dočasné odmítnutí za trvalou chybu, nebo jednoduše není v určitých případech možnost doručit zprávu znovu. To lze vyřešit selektivním whitelistingem. Tato metoda by měla být použita jako doplněk, resp. předřazení ostatním metodám pro filtrování pošty, neboť může dojít k tomu, že spammeři přehodnotí svou taktiku a i za cenu zdržení se pokusí techniku obejít.
4.5 Alternativní způsoby Na závěr této sekce bych rád jako doplnění zmínil v krátkosti několik alternativních řešení, z nichž každé pokrývá určitou fázi filtrování pošty. Blue Frog Jedná se o projekt Izraelské společnosti Blue Security. Přístup tohoto projektu je ten, že je nejlepší ubít spammery jejich vlastní zbraní. Aplikace Blue Frog, dostupná jako plugin (zásuvný modul) do aplikace Firefox, dovolovala adresátovi spamu odeslat Opt-Out výzvu k vyřazení ze seznamu adresátů spamu. Odeslání probíhalo automatizovaně pomocí formulářů dostupných právě na stánkách, které byly ve spamu inzerovány. To ve své podstatě představovalo distribuovaný DoS útok na stránky spammerů. Autoři sázeli na to, že s rozšířením svého programu budou stránky spammerů bombardovány větším počtem žádostí a na základě toho zruší nebo omezí svoje obchody. Kontroverzní služba byla však díky odvetnému DDoS útoku ze strany spammerů a výhrůžkám na adresu autorů i uživatelů zastavena a v současnosti je webová stránka Blue Security mimo provoz2. Spam Gourmet3 Webová služba Spam Gourmet nabízí pro zaregistrované uživatele jednoúčelové emailové schránky jako bariéru mezi spamem a jejich skutečnou emailovou adresou. Po ověření uživatele jsou všechny zprávy posílané na jednoúčelové adresy konkrétního uživatele přeposlány na chráněnou adresu. Tyto adresy však mají jednu charakteristickou vlastnost – na každou smí přijít pouze definovaný počet zpráv a další nad limit jsou zahozeny. Adresa je vytvořena ze vzoru „[email protected]“, a 1
Variable envelope return path – systém variabilního odesilatele uváděného pro každou cílovou adresu mailing listu údaj na obálce, viz. http://en.wikipedia.org/wiki/Variable_envelope_return_path 2 http://news.bbc.co.uk/2/hi/technology/4990622.stm 3 http://www.spamgourmet.com
- 60 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
po jejím prvním použití je aktivována. X odpovídá počtu zpráv, username je uživatelské jméno v rámci systému a someword je unikátní slovo o délce maximálně 20 znaků. Služba je poskytována bezplatně a v rozšířeném režimu umožňuje nastavit další užitečné parametry, jako přepsání hlavičky To: aby zpráva vypadala jako přímo odeslaná na chráněnou adresu, přídavný filtr na slovo v předmětu zprávy a podobně. Dle mého názoru představuje efektivní nástroj v rámci aktivní prevence ze strany uživatele. Red Condor1 Společnost Red Condor jsem vybral jako příklad typického zprostředkovatele antispamových služeb (tzv. outsourcing). Ještě v polovině minulého roku se společnost pyšnila, že filtr na jejich SMTP bráně zachytí veškerý spam a zároveň je společnost chráněna před útokem z vnější sítě. Jejich systém detekce spamu spočívá pravděpodobně v dříve zmíněné testovací síti „obětních počítačů“ (viz. 4.4.3), a přijaté zprávy v této síti jsou údajně podrobeny manuální analýze. Jediné, co je zapotřebí je nastavit je bezpečnostní politika firmy a přesměrovat MX záznam na přidělený stroj v doméně společnosti Red Condor. O zbytek se postará zprostředkovatel. Princip přesměrování provozu na zprostředkovatele je znázorněn na obrázku s použitím příkladu z dřívějších kapitol. Nejdříve je provede odesilatel DNS dotaz a ten ho nasměruje na MX server od prostředníka. Pošta pak proudí ve směru bílých šipek.
Obrázek 4-6: Zapojení SMTP proxy zprostředkovatele
Cena v době průzkumu činila 2USD a emailovou schránku měsíčně s nabídkou slev pro vyšší množství spravovaných schránek. Rozhodnutí, zda použít jako antispamové řešení outsourcing, nebo aplikovat metody na své straně pak už závisí na ekonomických výpočtech. Geobyte’s ‘m…2 Firma Geobyte přišla s několika vylepšeními, která jsou aplikovány na straně uživatele. Jejich program ‘m… funguje jako prostředník mezi MUA uživatelem a POP3 serverem (tzv. POP3 proxy), tedy nezávisle na typu MUA. Unikátní technologie spočívá ve dvou funkcích nazývaných jako CaseKey a Spamborder. CaseKey je založena na principu transformace emailové adresy v její unikátní, složený z kombinace malých a velkých písmen (např. [email protected] -> [email protected]). To by samo o sobě nic neznamenalo, avšak program pokládá každou unikátní kombinaci za specifický klíč s určitou (volitelnou) dobou platnosti. V praxi se jedná o to, že pro každého, nebo pro skupinu korespondentů je vygenerován unikátní klíč a na základě jeho používání 1 2
http://www.redcondor.com http://m.geobytes.com
- 61 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
je pošta propuštěna. Pokud odesilatel použije normální tvar adresy, je podroben procesu Chalenge-Response. Ve chvíli, kdy dojde ke zneužití některého klíče, uživatel ho jednoduše zneplatní. Doplňující funkcí je Spamborder. Jedná se o jistou formu whitelistingu a tato funkce byla vyvinuta s předpokladem, že uživatel převážně komunikuje s ostatními v jeho geografické oblasti, dejme tomu v Čechách. Pak je veškerá pošta z definované oblasti doručena. Pokud uživatel potřebuje komunikovat s někým mimo oblast, musí přidat další zónu. Jedná se o celkem zajímavý přístup, avšak používání CaseKey vyžaduje od osoby se kterou komunikuji dodržování tohoto klíče. To si v praxi dovedu představit jako mírnou komplikaci. Navíc v kombinaci se systémem Challenge-Response, který probíhá formou emailu – tedy minimálně dvou nadbytečných zpráv.
4.6 Komplexní řešení Jak vyplývá z analýzy jednotlivých metod výše, není možné spoléhat pouze na jednu konkrétní metodu filtrování. Pokud ano, nese to s sebou jisté obtíže, neboť každá metoda má přednosti i nedostatky. Ideálním řešením je kombinace metod v logickém pořadí na jejímž výstupu je minimum nevyžádané pošty a pokud možno nulový počet zadržených legitimních zpráv. Pro spammera je mnohem složitější vymyslet postup, jak se vyhnout celému souboru testů v porovnání s jednotlivými metodami. Zároveň je třeba připomenout dosud nezmíněnou potřebu antivirové kontroly příchozí pošty a rovněž její integraci do kaskády procesních nástrojů příchozí pošty. Emailové viry jsou totiž ve chvílích svého akutního rozšíření velkým zdrojem nevyžádaných zpráv, rozesílaných na všechny dostupné adresy. Takové komplexní řešení bývá obvykle k dispozici jako komerční produkt (zejména u operačního systému Windows), jehož výrobce integroval sadu metod do jednoho celku. Tento celek je po nastavení připraven k použití na serveru příchozí pošty, nebo ve formě separátního serveru. Pro představu lze jmenovat z české produkce např. Trusport® Intenet Gateway1 společnosti AEC nebo Merak Instant Antispam2 od Icewarp. Ze zahraničních pak například produkty firmy Symantec3. Zmíněné produkty od českých výrobců představují kombinaci některých metod z předchozích kapitol spolu se specifickými rozšířeními jednotlivých firem. Zároveň jsou i prvkem v ještě komplexnějším řešení kompletního poštovního serveru a podobně. Takový systém (když zanedbám počáteční náklady ze strany zákazníka) je dobrý pro obě strany – zákazník za svoje peníze dostane podporu a relativně snadnou administraci, a firma získá další zpětnou vazbu a stroje pro statistickou analýzu úspěšnosti svých metod. V případě systémů typu Unix je situace odlišná a i když existují placené verze kompletních řešení, je zde k dispozici mnoho různých variant, ať už se to týká filtrů spamu nebo programů pro správu příchozí a odchozí pošty. Administrátor poštovního serveru má úplnou kontrolu nad nastavením systému a může vyladit systém podle konkrétních potřeb. Obrázek 4-7: Kaskáda pro zpracování zpráv znázorňuje logické uspořádání kaskády pro zpracování vstupní pošty a nasazení jednotlivých bloků po dokončení příkazů klienta v rámci SMTP relace a po ní (obdobné uspořádání používají i komerční produkty).
1
http://www.aec.cz/index.php?id=83,0,0,1,0,0 http://www.icewarp.cz/Products/Merak_Instant_AntiSpam/ 3 http://symantec.cz 2
- 62 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
Obrázek 4-7: Kaskáda pro zpracování zpráv
Ve stupni 1 je akce zcela zřejmá – dochází k dočasnému odmítnutí nebo jasnému rozpoznání a odmítnutí spamu. Pokud je ve stupni 2 rozpoznán virus v těle emailu, je zpráva zahozena. V opačném případě se nabízí otázka: Jak objektivně rozhodnout, zda je email spamem? Za účelem dosažení objektivity je používán tzv. score system (systém ohodnocení). Systém sdružuje sadu testů, které jsou aplikovány na zprávu. Výsledek každého testu má svou váhu (číselné ohodnocení) a na základě váženého součtu umožňuje vyvodit závěr, že se s určitou pravděpodobností jedná o spam. Typickým příkladem je program Spamassassin, který představuje rozhraní pro integraci různých druhů filtrů a zároveň velice efektivní heuristický nástroj. Dovoluje integrovat jak lokální testy zprávy, tak i vzdálené dotazy na blacklisty a servery spravující databáze signatur (viz. [SA]). Výsledné skóre po aplikaci testů je porovnáno s prahovou hodnotou indikující spam, na základě toho je rozhodnuto, a email je označen jako spam nebo ham přidáním údajů do hlavičky emailu. Ve stupni 3 je již se zprávou naloženo podle nastavení MTA, je uložena do konkrétní schránky, zahozena na základě hodnocení filtrů, nebo podniknuta jiná akce. Program Spamassassin je třeba zmínit z několika důvodů, přestože jeho detailnější popis je už nad rámec práce. Jedná se totiž o velice dobře škálovatelný nástroj, který je použitelný jak na straně serveru, tak i na straně klienta. Jeho heuristické posuzování a ohodnocování zpráv umožňuje při správném nastavení dosáhnout velmi dobrých výsledků. Počet testů, které Spamassassin může na zprávu aplikovat zahrnuje kompletní analýzu hlavičky a těla z různých aspektů1 (např. falešné hodnoty v záhlaví, podezřelá slova v předmětu zprávy, datum z budoucnosti, přítomnost odesilatele na blacklistu, html formát zprávy, aj.). Jeho funkcionalita dovoluje také doplnit další pravidla pro testy.
Obrázek 4-8: Příklad prolnutí funkcí programů
1
Kompletní seznam testů v poslední verzi: http://spamassassin.apache.org/tests_3_1_x.html
- 63 -
4 FILTROVÁNÍ SPAMU
Diplomová práce
Díky tomu, že se autoři různých volně šiřitelných filtrů, snaží učinit své řešení samostatně použitelné, často se spojuje několik funkcí v jednom programu a tak dochází k prolnutí funkcí. Například program pro testování signatur disponuje jistou formou greylistingu nebo MTA umožňuje používat distribuované blacklisty. Pokud se některý z programů nechová jako proxy (prostředník), hlavní složkou je ale téměř vždy MTA, který volá jednotlivé metody a využívá jejich výsledků. Názorně jsem se to pokusil přiblížit na Obrázek 4-8: Příklad prolnutí funkcí programů.
4.7 Software V oblasti softwarových produktů spojených s elektronickou poštou panuje dvojí přístup, jak bylo zmíněno výše – produkty pro operační systém Windows jsou k dispozici buď jako komplexní serverové řešení, nebo jako zásuvný modul do MUA. Ve většině případů je užívání těchto produktů zpoplatněno. Oproti tomu v Linuxovém prostředí je obvykle většina produktů opensource pod GPL licencí (tedy zdarma) a uživatel nebo administrátor má úplnou svobodu výběru. Mezi těmito dvěma „světy“ je malý společný průnik. Obecně lze říci, že produktů pro boj se spamem je k dnes dispozici nepřeberné množství1, stejně jako emailových klientů a serverů. Jak jsem již naznačil v úvodu, nesoustředím se ve své práci na testování produktů a proto uvedu pouze seznam nejčastějších implementací (servery, klienti) pro různé operační systémy s odkazy na externí zdroje, které postkytují podrobnější informace v případě zájmu čtenáře. Servery Linux – Postfix, Sendmail, Qmail, Exim, Courier MTA Windows/Mac X – Microsoft Exchange Server, Eudora Internet Mailserver, Merak Mailserver, Kerio Mailserver Více na [REV-SERVER]. Klienti Linux – grafické Mozilla Thunderbird, Kmail, textové Pine, Mutt Windows – Outlook, Thunderbird, The Bat!, Eudora, a mnoho dalších. Více na [REV-CLIENT] Filtry a antispamová řešení Seznam v podobě tabulky spolu se stručnou charakteristikou je obsažen v příloze B.
1
Velmi obsáhlý seznam převážně komerčních produktů je uveden na: http://www.spamhelp.org/software/
- 64 -
Diplomová práce
5 VÝSLEDKY ANALÝZY A NÁVRHY ZLEPŠENÍ Během psaní práce a při důkladnějším průzkumu antispamových metod jsem došel ke zjištění, že nalezení zcela bezchybného a přesného řešení je netriviální problém, ale lze se mu za určitou cenu přiblížit. Optimální obranu proti nevyžádané poště (spamu, virům) většinou nemůže poskytnout jedno konkrétní řešení nebo metoda. Výjimkou jsou statistické filtry Bayesovského typu (SpamBayes, Spamassasin a jemu podobné), které v případě kvalitní databáze vzorků podávají velmi dobré výsledky i při samostatném použití. Kvalitní databáze odpovídá dle poznatků řádově stovkám zpracovaných vzorků hamu i spamu. Při aplikaci straně uživatele to vyžaduje delší časový úsek pro naučení, než začne filtr korektně fungovat. Poté však dosahuje nejlepších výsledků ze všech dostupných metod. Z pohledu organizace – tedy provozovatele serveru pro obsluhu pošty – mohu své poznatky shrnout do několika bodů: 1. Důsledně aplikovat antispamovou politiku To znamená přesně nadefinovat, jaké emaily a za jakých okolností přijmout a jaké odmítat nebo zahazovat a dle toho nastavit všechny prostředky. Posouzení autentičnosti emailu na základě SPF a DKIM politiky má bezesporu budoucnost v případě, že dojde k většímu rozšíření těchto metod identifikace odesilatele. V rámci této politiky je třeba zajistit také zabezpečení poštovního serveru a zamezit odesílání pošty neoprávněnými osobami. 2. Zvolit vhodné metody a správně sestavit filtrovací schéma Obecně platí, že kvalitních opensource produktů je dostatek, důležitý je jejich výběr a jejich aplikace ve správném pořadí naznačeném na Obrázek 4-7. Použití následujících metod by dle mého názoru nemělo být opomenuto: • Greylisting – odfiltrování nelegitimních odesilatelů, šetření zátěže serveru za cenu mírného zdržení, doplněno whitelistem pro výjimky. • URI Blacklist – url adresa, inzerovaná v těle emailu je jedním ze stěžejních identifikátorů spamu, těžko se na blacklist dostane nevinná doména. Z mých testů, které jsem aplikoval na příchozí spam obsahující v těle URL adresu vyplynulo, že v době doručení již byla adresa obsažena minimálně v jednom ze třech testovaných blacklistů. • Filtry Bayesovského typu – po počátečních nárocích na učení dosahují velmi dobrých výsledků. • Antivirus – nezbytná pomůcka pro ochranu před viry. 3. Dát uživatelům možnost identifikovat špatně klasifikované zprávy To platí zejména při použití filtrů Bayesovského typu na straně serveru. Je to krok, který přispívá ke zlepšení výsledků. 4. Udržovat v rámci možností aktuální verze produktů To se týká zejména virových databází, a antispamových řešení, která mohou v novějších verzích poskytovat rozšířené funkce, a opravy předchozích chyb. Ze získaných poznatků o charakteru spamu jsem vyvodil závěry: • Pro místní podmínky (Česko) je možné při posuzování spamovosti zvýhodnit odesilatele z místní domény (.cz), a pokud je filtr schopen identifikovat jazyk textu, tak zvýhodnit i česky psané zprávy. Naprostá většina spamu je totiž až na zářné výjimky - 65 -
5 VÝSLEDKY ANALÝZY
•
Diplomová práce
vždy v anglickém nebo jiném jazyce, a Českou republiku jsem jako zdroj spamu v žádných statistikách nenalezl. Jelikož velikost jednoho obrázkového emailu se spamem nepřekračuje dle statistik1 2040kB a formát obrázku je .GIF, je vhodné v této oblasti nastavit přísnější restrikce. Naopak větší emaily – řádově nad 100kB – obvykle pochází z legitimního zdroje (uživatel, obázky ve formátu JPG), neboť spammer potřebuje email odeslat co nejrychleji a tudíž velikost zprávy je omezena na nutné minimum.
Do budoucna je třeba věnovat pozornost metodám pro detekci obrázkového spamu, který je v současnosti největším problémem a zastupuje přibližně 20%-35% z celkového počtu spamu, což však představuje v porovnání s textovým spamem cca 70% celkového objemu (viz. [COMTOUCH]). Pro tuto problematiku již existuje několik metod, které byly implementovány u komerčních produktů2, ale jejich úspěšnost a výsledky se mi nepodařilo zjistit. Poznámka: Řešení pro filtrování obrázků a zvýhodnění místních (českých) domén je k dipozici v rámci konfiguračního souboru serveru Postfix a je obsaženo na přiloženém CD.
1 2
[MARSHAL], [COMTOUCH], http://www.messagingnews.com/newswire/email_security_2006-12-15.html Např. Image Checker, součást řešení Trusport Internet Gateway - http://www.aec.cz/index.php?id=24,717,0,0,1,0
- 66 -
Diplomová práce
6 IMPLEMENTACE 6.1 Implementační záměr Jelikož bydlím již několik let na stejné koleji (Sinkuleho kolej, ČVUT) a používám místní emailovou schránku, na kterou chodí pravidelně nevyžádaná pošta, začal jsem se zajímat o to, jak situaci zlepšit. Byl mi přidělen účet na místním serveru (operační systém Linux Gentoo), prozatím bez administrátorských práv na kterém je centralizována většina síťových služeb, mimo jiné také SMTP server. Aplikované řešení na serveru se skládá z programů Postfix 2.1.5 (MTA), Clamav 0.80 (antivirus), Spamassassin 3.0.2-r1 (antispam filtr) a rozhraní Amavisd-new 2.2.1. Žádné jiné metody, kromě využití některých blacklistů nebyly aplikovány. Vzhledem k efektu Greylistingu jsem se rozhodl napsat experimentální implementaci této metody, ještě v době, kdy jsem do problematiky neměl úplný vhled. Během postupného studia problematiky jsem zjistil, že již existuje několik opensource implementací, na které jsem do té chvíle nenarazil. Jako testovací prostředí jsem nainstaloval na svůj počítač operační systém Linux (distribuce Kororaa, což je nadstavba Gentoo distribuce), a identické programy jako na poštovním serveru, nainstalované z depozitáře portage v posledních stabilních verzích.
6.2 Popis implementace Jazyk implementace Jazyk Common Lisp, konkrétně „dialekt“ CLISP (verze 2.38). Má minimální paměťové nároky, malou velikost a je k dispozici pro různé platformy pod GPL licencí. Zároveň jsem měl motivaci vyzkoušet, vhodnost tohoto jazyka pro implementaci takového úkolu. Začlenění do systému Greylisting lze realizovat ve dvou podobách: • SMTP proxy - program, který naslouchá na portu pro příchozí poštu (port 25), zpracovává prvotní komunikaci a posílá data dále na server (je předřazený MTA). • rozšíření MTA – pokud je to umožněno, modul pro greylisting je volán v rámci SMTP relace programem pro zpracování pošty. Zvolil jsem druhou verzi, neboť program Postfix disponuje od verze 2.1 funkcí Access Policy Delegation ([POSTAPD]), kdy na základě nastavení odešle údaje o relaci externímu programu a ten pak rozhodne o dalším zpracování zprávy.
Obrázek 6-1: Volání externího modulu z Postfixu
Aby nemusel být program pro každou zprávu znovu spouštěn, běží spuštěn jako služba (démon) a očekává příchozí spojení na adrese localhost na zvoleném portu (implicitně - 67 -
6 IMPLEMENTACE
Diplomová práce
nastaven na 10111) . Ze serveru Postfix jsou informace předávány přes TCP spojení, dle nastavení v souboru /etc/postfix/main.cf: smtpd_recipient_restrictions = … check_policy_service inet:127.0.0.1:10111
Datové struktury Pro uchování tripletu ip_adresa, odesilatel, příjemce slouží tabulka triplet na uložená na MySQL serveru. To má výhodu, pokud by bylo řešení používáno více servery pro příchozí poštu, může být použito stejné databáze. Nevýhodou je nutnost instalace dalšího balíku software. Pro připojení k databázi je použita knihovna CL-SQL.
Tabulka 6-1: MySQL tabulka 'triplet'
Nad tabulkou je rovněž vytvořen index nad hodnotami ip_adresa, odesilatel, příjemce, pro urychlení hledání v databázi. Datové položky passc a updated mají informativní hodnotu a nejsou z hlediska funkčnosti nepostradatelné. Program také uchovává v textovém souboru IP whitelist legitimních odesilatelů, kteří jsou greylist-nekompatibilní a je třeba na ně greylisting neaplikovat (převzato z [GREY]). Cyklus programu Po spuštění v podobě démona startovacím skriptem /etc/init.d/greylisp je načten soubor s nastavením, vytvořen soubor s PID procesu (create-pid-file), aby nedošlo k několika kolizním spuštěním a načten seznam IP adres whitelistu read-whitelist-file, a a spuštěna hlavní smyčka programu voláním funkce server-main-loop. V této funkci je inicializováno rozhraní serveru a program naslouchá na zvoleném portu, který musí korespondovat s nastavením Postfixu. Po spojení v rámci Access policy delegation je volána funkce fetch-delegated-info, která načítá parametry odeslané serverem ve formátu název=hodnota, kde newline značí přechod na nový řádek a parametr request musí obsahovat hodnotu smtpd_access_policy. Postfix ukončí výpis informací prázdným řádkem. Informace jsou vráceny ve formě seznamu a dále zpracovány funkcí separate-values a předány applypolicy, která obsahuje hlavní rozhodovací strom se greylistingu a volá další funkce pro operace nad databází (triplet-info, change-triplet-state, refresh-expiration a další) a dotazy na načtený permanentní whitelist (permanently-whitelisted?) Rozhodovací proces principielně odpovídá Obrázek 4-5: Diagram Greylistingu, jediným rozdílem je, že program není zapojen do přímé interakce s klientem.
- 68 -
6 IMPLEMENTACE
Diplomová práce
Po svém dokončení funkce apply-policy vrací jednu z hodnot: • 450 <string> – indikace dočasného odmítnutí s řetězcem <string> - greylisting; • OK – odesilatel je na permanentním whitelistu, nebo splnil podmínky pro to, aby jeho triplet byl přeřazen z blokujícího do propustného stavu. • DUNNO – pokud nesouhlasí některý z parametrů, které server předal, nebo program nebyl schopen z důvodu chyby rozhodnout. K navrácené hodnotě je přidána předpona „action=“ a prázdný řádek, a výsledek odeslán zpět serveru Postfix (reply-selected-action). Ten na základě toho učiní odpovídající akce. Odstranění nepotřebných tripletů s prošlou expirací je řešeno pomocí naplánované úlohy programu cron, kdy je jednou za den spuštěn čistící SQL skript. Nastavení programu Iniciální nastavení a zkopírování důležitých souborů provede skript install. Parametry programu je uchováváno v souboru /etc/greylisp/config.lisp. Ten obsahuje hodnoty časových intervalů, určující doby dočasného odmítání zprávy, přijetí a expirace záznamu, paramety serveru a další hodnoty. Poznámka: Kompletní popis instalace a zprovoznění programu je včetně zdrojových kódů k dispozici v příloze na CD.
6.3 Experimentální hodnocení Mým cílem bylo nasazení implementované metody do experimentálního provozu na Sinkuleho koleji. Kvůli komplikacím v testovacím systému se mi však nepodařilo program dostatečně odladit pro použití v ostrém provozu. Navíc jsem po prozkoumání logů a nastavení cílového systému na kolejním serveru objevil několik závažnějších nedostatků, které si vyžádají odbornější zásah administrátorů, ke kterému nejsem oprávněn. Jednalo se zejména o starší verze programů Clamav a Spamassassin. Výsledky jsem tedy bohužel v době odevzdání diplomové práce nemohl získat. Nicméně hodlám dostát svým závazkům a řešení v dohledné době zprovoznit.
- 69 -
Diplomová práce
7 ZÁVĚR Ve své diplomové práci jsem provedl rozbor a posouzení vhodných prostředků pro boj proti spamu. Věnoval jsem se ve větší míře analytické části a snažil jsem se získané informace sjednotit do srozumitelného a logického celku. Popisem problematiky elektronické pošty a jejích protokolů, spolu s rozborem spamu, poskytuje čtenáři informace pro porozumění další problematice. Při analýze antispamových řešení jsem zjistil, že existuje nepřeberné množství různých variací, které však až na výjimky využívají omezeného množství konkrétních a zavedených metod. Zárověň jsem došel k názoru, že úspěch nestojí na prostém použití těchto metod, ale na jejich důsledném a přesném nastavení a vzájemné kombinaci. Své závěry a návrhy jsem zhodnotil v kapitole 5. V implementační části práce jsem se pokusil o konstrukci jedné z metod (greylistingu) a její zavedení do reálného provozu, které však bohužel nedopadlo dle mých představ, avšak i přes to myslím, že má práce, zejména v analytické části bude přínosem pro případné čtenáře. Vzhledem k tomu, že postupy a metody odesilatelů spamu se stále snaží nacházet nové cesty, jako možné pokračování práce vidím implementaci metod přispívajících k identifikaci obrázkového spamu. Tato forma spamu rozmohla se během druhé poloviny roku 2006, a dosud neexistuje mnoho přístupů, jak se proti ní bránit bez oběti v podobě odmítnutých legitimních zpráv. V implementaci by se dalo uvažovat o heuristickém porovnávání částí obrázků například s použitím knihovny ImageMagick, která je k dispozici i pro jazyk LISP.
- 70 -
Diplomová práce
8 POUŽITÉ ZDROJE Publikace [DSM0604] Nádeníček, Vystavělová, Chromá - Spam a legislativa u nás i v zahraničí Časopis DSM 04/2006 [DSM0606] J. Formánek - SpotSpam – Evropský příspěvek Časopis DSM 06/2006 [POSTFIX] R. Hildebrandt, P. Koetter - The book of Postfix, ISBN 1-59327-001-1 Odkazy na Internet http://www.livinginternet.com/e/e.htm http://en.wikipedia.org/wiki/Email http://en.wikipedia.org/wiki/Bayesian_statistics http://en.wikipedia.org/wiki/Bayesian_poisoning Plně kvalifikované doménové jméno http://en.wikipedia.org/wiki/FQDN [BERN1] Komentáře k protokolu SMTP – Bernstein, D. J. http://cr.yp.to/smtp/ [SSL] Specifikace SSL 3.0 http://wp.netscape.com/eng/ssl3/draft302.txt [YAHOO1] Omezení počtu adresátů http://help.yahoo.com/help/uk/mail/send/send-12.html [IANA1] Souhrn příkazů a služeb ESMTP http://www.iana.org/assignments/mail-parameters [SPAMSITE] Stránka věnovaná tématu spam http://www.spam-site.com [STOPSPAM] Understanding email headers http://www.stopspam.org/email/headers.html [ZOMBIES] Spam Zombies from Outer Space http://pages.cpsc.ucalgary.ca/~aycock/papers/sz.pdf [SPAMOM] Spam-O-Meter - statistiky http://www.spam-o-meter.com [MSGLABS] Messagelabs - statistiky http://www.messagelabs.co.uk/Threat_Watch/Threat_Statistics [POSTINI] Postini - statistiky http://www.postini.com/stats/ [IMC1] Internet Mail Consorcium - Definice UBE (spamu) http://www.imc.org/ube-def.html [MARSHAL] Rise of Image Spam, 08/2006 http://www.marshal.com/newsimages/trace/RiseofImageSpam.pdf [RICK1] Rick’s spam digest – Spam rules http://www.rickconner.net/spamweb/spamrules.html [RICK2] Rick’s spam digest – Avoiding spam http://www.rickconner.net/spamweb/avoiding.html [AOT] Authentication and Online Trust Alliance http://www.aotalliance.org/docs/SIDF_Overview_Brochure_v3.1.pdf [SPF] Sender Framework Policy http://www.openspf.org/ [DKEYS] Domain Keys http://antispam.yahoo.com/domainkeys [LIVING1] [WIKI1] [WIKI2] [WIKI3] [FQDN]
- 71 -
6 IMPLEMENTACE
Diplomová práce
[DKIM]
Domain Key Identified Mail http://www.dkim.org/info/ [LUPA1] Jiří Peterka - Boj proti spamu v praxi http://www.lupa.cz/clanky/boj-proti-spamu-v-praxi/ [LUPA2] Ján Matejka - Spamming a jeho právní úprava http://www.lupa.cz/clanky/spamming-a-jeho-pravni-uprava/ [CRM114] http://crm114.sourceforge.net/ [WIWU] On Attacking Statistical Spam Filters, 2004 http://www.ceas.cc/papers-2004/slides/170.pdf [VBTN] Virus Bulletin, Does Bayesian poisoning exist? http://www.virusbtn.com/spambulletin/archive/2006/02/sb200602-poison [KOT] Martin Kot - Bezpečnost elektronické pošty http://www.cs.vsb.cz/kot/Reports/Bit/ [ICA] I.CA - Teorie symetrické a asymetrické kryptografie http://www.ica.cz/home_cs/?acc=teorie_a_principy [PGPI] http://www.pgpi.org/doc/pgpintro/ [DCC] http://www.rhyolite.com/anti-spam/dcc/ [DECOY] http://fightrelayspam.homestead.com/files/antispam06132002.htm [SA] http://www.spamassassin.org/ [DECLUDE] http://shopping.declude.com/Articles.asp?ID=97 [COMTOUCH] http://www.commtouch.com/downloads/Commtouch_2006_Spam_Trends_Year _of_the_Zombies.pdf [GREY] http://projects.puremagic.com/greylisting/whitepaper.html [POSTAPD] http://www.postfix.org/SMTPD_POLICY_README.html [REV-SERVER] http://www.geocities.com/mailsoftware42/ http://email.about.com/od/windowsmailservers/Windows_Mail_Servers.htm [REV-CLIENT] http://en.wikipedia.org/wiki/Comparison_of_e-mail_clients RFC dokumenty [RFC 1035] Domain Names – Implementation and specification [RFC 1734] POP3 AUTHentization command [RFC 1939] Post Office Protocol, ver. 3 [RFC 2045-2048] MIME: Multipurpose Internet Mail Extensions (série) [RFC 2060] Internet Message Access Protocol, ver. 4, rev. 1 [RFC 2183] Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field [RFC 2821] Simple Mail Transfer Protocol [RFC 2822] Internet Message Format [RFC 3696] Application Techniques for Checking and Transformation of Names [RFC 4648] The Base16, Base32, and Base64 Data Encodings Software Kororaa Lispbox
Operační systém na bázi Gentoo Linux http://kororaa.org Vývojové prostředí pro psaní aplikací v jazyce LISP, složené z editoru Emacs, SLIME serveru, komunikující s instancí CLISPu. - 72 -
6 IMPLEMENTACE
Diplomová práce
http://www.gigamonkeys.com/lispbox/ CLISP Implementace jazyka LISP http://clisp.cons.org Postfix Kvalitní a spolehlivý mailserver http://postfix.org Spamassassin Nástroj pro filtrování pošty http://spamassassin.apache.org/ ClamAV Antivirový nástroj pro operační systém Linux http://clamav.net MySQL Opensource databázový systém http://www.mysql.com
- 73 -
Diplomová práce
A Obsah přiloženého CD info.txt Informace o programu a diplomové práci /config/ Konfiguračními soubory a příklady nastavení serveru Postfix /greylisp/ install.txt Popis instalace install Instalační shell skript /greylisp/packages/ Potřebné balíčky pro běh programu /greylisp/sources/ Zdrojové kódy programu /text Textová část práce ve formátu .DOC a .PDF včetně přílohy
- 74 -
Příloha B - Tabulka antispamových produktů Program
Výrobce
Operační systém
Typ řešení
Popis
Odkaz na Internet
SpamAssassin
Apache
Linux
Rozšiřitelné rozhraní pro klasifikaci spamu
Heuristický filtr s možností využití dalších modulů
http://spamassassin.apache.org
GPL lic.
POPfile
J. Graham-Cumming
Filtr
Klasifikátor opět na bázi Bayesovského přístupu
http://popfile.sourceforge.net
GPL lic.
BogoFilter
Eric S. Raymond
Filtr
Bayesovský filtr
http://www.icewalkers.com/Linux/Software/5 17630/Bogofilter.html
GPL lic.
InterScan Messaging Security Suite + Spam Prevention Solution
TrendMicro
Linux, Solaris, Windows
Komplexní zabezpečení sítě na úrovni brány s filtrací zpráv
Antivirus, antiphishing, antispamové řešení
http://www.trendmicro.cz/
placený
Linux, Solaris, Windows
Komplexní serverové řešení
Symantec Brightmail AntiSpam Symantec Corporation
Linux, Windows, OS X Linux, Solaris, OS X
http://www.symantec.com/cs/cz/small_busi Antispam + antivirová ochrana ness/products/overview.jsp?pcid=ms&pvid= malé podnikové sítě sbas
TrustPort Internet Gateway SMTP AntiSpam
AEC
Windows
Antispamová ochrana sítě na úrovni Internetové brány
SpamKiller
MCAfee
Windows
AntiSpam filter pro MSExchange 2000,2003 server a Lotus Domino 5+, 6+
Intelligent Message Filter (IMF)
Microsoft
Windows
TrustPort Internet Gateway (AntiSpam+AntiVirus)
AEC
Windows
komplexní ochrana sítě na úrovni Ibrány před spamem, viry a spyware
white+blacklisty,graylisting,filtr regulárních výrazů, Bayes filter
Qurb
Qurb
Windows
Pro Outlook/Outlook Express
efektivní antispam s whitelist filtrem
SpamBully 3
SpamBully
Windows
Pro Outlook/Outlook Express
Bayesovský filtr, blocklist
Hexamail Guard
Hexamail Ltd.
Windows
modulární produkt pro všechny SMTP servery, snadná integrace do MSExch.
Bayesovská analýza, whitelist, antiphishing
Astaro Security Gateway-Email Security
Astaro
Windows
Modulární systém
GFI MailEssentials for Exchange/SMTP
GFI Software Ltd.
Windows
Rozšíření Exchange a SMTP servery
NoSpamToday!
Byteplant GmbH
Windows, Linux
Dostupnost-cena
placený
white+blacklisty,graylisting,filtr http://www.aec.cz/index.php?id=83,0,0,1,0, 11 až 25 lic/rok 411 Kč + podpora regulárních výrazů, Bayes filter 0 164 Kč/další rok
6 úrovní detekce spamu
Integrován v MS Exchange 2003 server uživatelské hodnocení spamů a SP2 jejich příští filtrace
http://www.mcafee.com/us/smb/products/e mail_web_security/spamkiller_mail_servers .html
148 $/ 5 licencí
http://www.microsoft.com/exchange/imf/
součástí licence pro MS Exchange 2003 server
http://www.aec.cz/
11 až 25 lic./rok 846 Kč + podpora 345 Kč/další rok
http://www.whichspamfilter.com/Reviews/Q urb.htm http://www.whichspamfilter.com/Reviews/S pamBully.htm http://www.hexamail.com/hexamailguard/
detekce a blokace spamu, virů, http://www.astaro.com/solutions/e_mail_se phishingu a spyware curity Antispam-rozšířená detekce, antiphishing
http://www.gfi.com/mes/
29.95 $/licence 29.95 $/licence 70 - 342$ dle volby modulů/10 uživatelů placený placený
Komplexní řešení pro SMTP i POP3 Freeware pro nekomerční použití White+Black Lists, Bayes filtry, http://www.nospamtoday.com/server/index. servery - MS Exchange, Lotus Domino (do 10 uživatelů), jinak 149 $ a antiphishing, antivirus html a Imail více
