SPAM – greylisting ve firmě

21. 10. 2008 | Ondřej Valoušek

Články - SPAM – greylisting ve firmě  

Šéf mě požádal, abych zpracoval antispamové řešení pro naši firmu. Proč o to požádal právě mě, když na stole byl i návrh na zakoupení "černé antispamové krabice" od renomované firmy za 10 000 euro, která to vyřeší sama od sebe?

Počáteční stav

Nežli popíši počáteční stav naší firemní sítě, rád bych alespoň v kostce čtenáře AbcLinuxu.cz seznámil s tím, proč si myslím, že s problémem SPAMu musíme bojovat.

Proč tedy? Asi proto, že historie SMTP (tedy protokolu zodpovědného za přenos elektronické pošty), je stará přes 20 let, kdy nikdo ani nepomyslel, že by se e-mail mohl zneužít takovýmto způsobem. I otázky, proč to ti spammeři vlastně dělají, ztrácí smysl, když si uvědomíte, že poslat někomu e-mail je zdarma - pokud pošlu někomu neznámému mail s textem "Give me some money", pravděpodobně se zasměje a mail smaže. Pokud však tento mail zašlu pár milionům nic netušících lidí, vždycky se najde nějaký pitomec, který mi zaplatí. A pokud se najde, rád podobný mail zašlu lidem zas - vždyť je to přeci zdarma a zpáteční adresa se dá krásně zfalšovat, takže tisícovky rozzlobených lidí nemají, na kom si právem vylít svoji zlost.

A právě takovou zlost jsem měl i já, když jsem musel každý den mazat desítky nevyžádaných mailů. A tak jsem začal zkoumat, jak naši firemní síť "vylepšit", abych tento neustálý tok mailů zastavil.

Topologie firemní sítě

Jak je vidět z obrázku, konfigurace firemní sítě byla v podstatě standardní - maily z Internetu procházejí firewallem do MTA (Mail Transfer Agent - v podstatě mašina, která mail vezme, rámcově zkontroluje a pošle dál) v zóně DMZ. Tento stroj funguje jako relay agent - maily s vnitřní e-mailovou adresou tak přeposílá na vnitřní mail server na intranetu. Odtud jsou pak přímo dostupné koncovým uživatelům.

Jako MTA zde funguje osvědčený Sendmail a v interní síti MS Exchange (já tlačil Scalix, ale bohužel to neprošlo). Žádný z těchto dvou strojů problém spamu neřešil a filtrování pošty tedy zůstalo na konečných uživatelích (Thunderbird s Bayesovským filtrem).

Problém

Problémy jsme tehdy měli v podstatě dva:

• Nárůst spamu byl takový, že jej koncoví uživatelé dostupnými prostředky nebyli schopni zvládnout (člověk nedělal nic jiného, než mazal maily).
• Mail relay v DMZ nestíhala generovat bounce maily kvůli zfalšovaným adresám odesílatele, tvořily se fronty a odeslání legitimních mailů trvalo hodiny i dny.

Generování bounce-mailů

U problému s generováním bounce-mailů (hlášení o nedoručitelnosti) bych se rád pozastavil, protože si jej mnoho administrátorů MTA (a sítí podobných té naší) neuvědomuje. Představme si větší společnost s doménou @example.com, která má svůj firemní mailserver na lokální síti a maily do internetu posílá a přijímá přes proxy MTA server připojený v demilitarizované zóně - tedy něco jako naše síť na obrázku výše.

Na první pohled z hlediska bezpečnosti výborné řešení, protože vnější útočník se nikdy nemůže dostat přímo na firemní mailserver. Problém ale nastává právě s generováním mail bounces, protože proxy MTA v demilitarizované zóně bude pravděpodobně konfigurován jako RELAY pro celou doménu @example.com a o existenci uživatelských účtů na koncovém mailserveru nebude mít ani tušení.

Pokud tedy přijde spam pro neexistujícího uživatele jarda@example.com, relay MTA v demilitarizované zóně jej s radostí přijme a přepošle firemnímu mailserveru. Ten jej odmítne, protože žádný mailbox pro Jardu nemá, a relay MTA v DMZ tedy musí vygenerovat mail bounce.

V normálním případě by to bylo to v pořádku (mail bounce vygenerovaný proxy MTA by dostal odesílatel a zjistil, že Jarda neexistuje). Pokud by však byla adresa odesílatele podvržená (což je u SPAMu běžný jev), bounce je doručen někomu, kdo nic takového neposílal. V horším případě doručen být nemůže a mail bounce se nám hromadí ve frontě a zbytečně zatěžuje mailserver.

Řešení situace

Neutěšenou situaci ve firmě jsem monitoroval již dlouho a zamýšlel jsem se tedy nad možnostmi řešení - které by pokud možno neobsahovalo žádnou "černou krabici" za spousty peněz. Nejsem sice zapřísáhlým odpůrcem komerčních řešení, ale nerad se dávám všanc něčemu, do čeho nikdo nevidí. Problém jsem rozdělil na dvě části:

• Vyřešit otázku generováni bounce mailů
• Vyřešit otázku detekce spamu

1. Mail bounces

Problém jsem vyřešil pomocí perl skriptu, který je v pravidelných intervalech spouštěn na vnitřním mailserveru a generuje seznam platných firemních emailových adres. Tento seznam je pak pomocí TFTP stáhnut na MTA proxy stroj v zóně DMZ. MTA má pak možnost přímo v otevřeném SMTP spojení ověřit existenci adresy příjemce. Pokud neexistuje, spojení je ukončeno s chybou 550 Recipient not found. Za vygenerování mail bounce je pak zodpovědný vnější odesílatel (ať už pravý, nebo ne).

Jiným řešením by bylo zkonfigurovat LDAP podporu v Sendmailu, který by si sám mohl existenci příjemce ověřit zasláním dotazu přímo na vnitřní LDAP server, ovšem to by znamenalo jisté bezpečnostní riziko, a proto jsem zvolil cestu pomocí tftp.

2. detekce spamu

Jako administrátorovi mailového serveru mi bylo jasné, že neexistuje jediná jednoduchá metoda, jak spam potlačit, a proto se obvykle kombinuje metod více. Není proto ani cílem tohoto článku představit nějakou "zázračnou" novou metodu - spíše shrnout dostupné metody a doporučit nejúčinnější.

V zásadě můžeme antispamové metody rozdělit takto:

Klient (MUA)/server (MTA)

Podle toho, jestli pracují na koncovém mailovém klientovi (např. Thunderbird) nebo přímo na SMTP serveru (např. Sendmail). Obecně je řešení integrované v MTA efektivnější, protože jen MTA má přístup k obálce mailu a také má možnost mail odmítnout ihned a snížit tak zátěž lokální sítě.

Aktivní/pasivní

Podle toho, jestli nějakým způsobem komunikuje s externími zdroji, aby rozhodla, jestli jde o spam, či ham - např. externí blacklist nebo Bayesovský filtr vyžadující trénink od uživatele. Při výběru aktivního řešení musíme být vždy na pozoru, aby se nedalo použít k útoku DoS (např. při užití DNSBL útoku na DNS poskytovatele blacklistu).

SMTP real time/post processing

Podle toho, jestli je mail nejdřív přijat a poté vyhodnocen, nebo jestli umožňuje odmítnutí mailu už během otevřeného SMTP spojení (např. na základě neplatné hlavičky mailu) s odesílatelem. Realtime metody (dále RCPT fáze) samozřejmě šetří zdroje MTA a obecně se jeví jako nejvýhodnější.

Karanténa

Někteří správci volí metodu "karantény", do které přesunou maily "omarkované" podle nějaké metody jako spam. Výhodou je, že uživatel má možnost si čas od času ověřit, jestli v ní neskončil i nějaký "pravý" mail. Já to nevidím jako "to pravé ořechové", protože jak objem spamu narůstá, uživatel ztrácí chuť obsah karantény kontrolovat a pravý mail může být snadno ztracen/zapomenut. To už je lepší podezřelý mail rovnou odmítnout - odesílající strana má pak šanci se bránit (např. telefonicky).

Classic RFC/extension

Extrémně dobrých výsledků lze dnes docílit konfigurací MTA tak, aby vyžadoval přesnou kompatibilitu s RFC specifikací SMTP protokolu (např. dobře známý efektivní greylisting takto pracuje). Jisté je jen jedno, do budoucna bude zapotřebí SMTP protokol doplnit či vylepšit, aby se dosáhlo dobrých výsledků, které budou i trvale udržitelné - touto cestou jdou standardy SPF či DKIM.

3. Metody boje

Uveďme alespoň nejvíce užívané a nejúčinnější (dle mého názoru) metody boje s nevyžádanou poštou. Zde se omezím na řešení integrovatelné do MTA, protože koncového uživatele obtěžují nejméně. Z těchto technik jsou mi nejvíce sympatické RCPT fáze, a to ty, které pracují v úvodních fázích dialogu SMTP:

Blacklisty

Přijímající MTA mail odmítne, pokud se ocitne (podle nějakých pravidel) na veřejně/soukromě udržovaném blacklistu. Obecně nepovažuji jakoukoli formu blacklistu IP adres za bezpečnou a do budoucna udržitelnou. Vzhledem k možnosti podvrhu ani blacklist domén nepřipadá bez dalších opatření v úvahu. I ostatní formy blacklistů narážejí na omezení (někdo to musí udržovat, vysoké riziko omylů - false positives).

Reverse DNS

Hodně administrátorů MTA mail odmítne, pokud pochází z IP adresy, která nemá reverse IP záznam, nebo ho má nějaký "špatný". Toto musím také odmítnout, protože specifikace RFC protokolu SMTP o ničem takovém nehovoří a mnoho nevinných MTA serverů také nemá reverse IP. Jako pomocná pomůcka však ano, proč ne.

Greylisting

V současnosti hodně diskutovaná metoda. Metoda greylistingu [wikipedia, lupa.cz] patří bezesporu k těm nejúčinnějším zbraním, které může spam-aware MTA nabídnout - přesto bych však byl s jejím nasazením trochu opatrný - s ohledem na zpoždění, které vyvolává.

SpamAssassin

Nepracuje ve fázi RCPT, ale vzhledem k jeho oblíbenosti ho přesto zmíním. Je to komplexní antispamový nástroj, který v sobě zahrnuje celou řadu procedur, s jejichž pomocí mail na základě jeho obsahu ohodnotí. Pracuje s celým e-mailem (tedy post-processing metoda) a kvůli tomu (+ dosti vysokým nárokům na CPU a paměť při vysoké zátěži MTA) bych tuto metodu doporučil jen jako doplňkovou. Přeci jen většina filtrů SA počítá s jistou zvyklostí spammerů. Pokud spammeři vyberou jinou taktiku, donedávna účinná technika selže (např: s heuristikou na obrázkovém mailu mnoho nepořídíte).

Sender address verification

Kontroluje platnost MAIL FROM obálky mailu tím, že na ní zkusmo pošle bounce. Musím říci, že nejdříve jsem byl touto taktikou nadšený - pak mi došlo, že s tímto otravuji MTA nevinných a mnohdy podvržených příjemců (nejlepší cesta, jak se dostat na blacklist), a proto se spokojím s její "odlehčenou" verzí kontroly existence MX záznamu domény MAIL FROM případně EHLO.

Kontrola platnosti odesílatele a digitální podpis zprávy

O metodách SPF [wikipedia, lupa.cz] a DKIM [wikipedia, lupa.cz] si myslím, že ačkoli nejsou primárně určeny na boj proti spamu, nelze si do budoucna boj proti nevyžádané poště bez těchto technologií představit. Obě jsou mnohdy prezentovány jako konkurenční, já však SPF (verze 1; SenderID ponechme Microsoftu) a DKIM vidím jako dokonale se doplňující rozšíření SMTP.

Jak už jsem říkal, nejvíce sympatické jsou mi techniky, které pracují v úvodních fázích SMTP dialogu (dále RCPT fáze). V této fázi je již známa adresa odesílatele, příjemce a stroj, od kterého zpráva přichází, ale ne tělo zprávy. Proč mi tedy přijde zajímavá?

1. Tělo zprávy ještě nebylo přeneseno, takže pokud se rozhodneme mail odmítnout, ušetříme strojový čas a přenosové pásmo.
2. Pokud děláme greylisting ve fázi RCPT (mail tedy odmítneme s dočasnou chybou typu "451 You have been greylisted, try again later") šance na zopakování doručení je větší než ve fázi DATA (tedy když už bylo tělo zprávy přijato). Proč? Normální MTA mají tendenci brát dočasnou chybu v DATA fázi jako permanentní error.
3. Pokud se rozhodneme mail odmítnout, za vygenerování MAIL BOUNCE (zpráva o nedoručitelnosti) je zodpovědný odesílatel, ne my - a z toho plynou výhody - viz výše.

Jaké jsou nevýhody technik v RCPT fázi:

1. Samozřejmě nemůžeme nasadit antispamové taktiky pracující s tělem zprávy.
2. Nutná těsná integrace do MTA (např. prostřednictvím milter rozhraní, které je k dispozici pro dva nejrozšířenější MTA - Sendmail a Postfix).

Implementace

Naše firemní MTA je realizována na Linuxu a Sendmailu, proto jsem se rozhodl o nasazení greylistingu prostřednictvím skvělého démona milter-greylist, který běží na mail proxy stroji v DMZ a je tak nejblíže zdrojům SPAMu - a může tam fungovat nejefektivněji (pokud mluvíme o realtime technikách detekce spamu, tak ty je možno aplikovat pouze na tomto stroji - na vnitřním mailserveru to už nemá smysl). Jak název připomíná, základ tohoto démona je v implementaci greylistingu, který je v mém případě prominut odesílatelům s pravým SPF podpisem nebo, těm kteří alespoň disponují podporou TLS [wikipedia, IETF.org].

Závěr

Účinnost mého řešení přesahuje 90 % - a to v podstatě "zadarmo", protože nároky na CPU jsou nízké a dále není třeba nic updatovat a ani se o něco starat. Ano, nějaký spam i tak sem tam proleze, ale pořád je zde ještě možnost nasazení zmiňovaného SpamAssassinu (na který je možno démona milter-greylist také připojit), který by účinnost dále dramaticky zvýšil. Zároveň se rýsuje možnost nasazení dalších slibných technik jako P0f, DKIM a DNSRBL. Stabilita tohoto softwaru je rovněž příkladná, takže určitě mohu doporučit.

Přikládám prezentaci (ODP), kterou jsem vytvořil v rámci propagace greylistingu pro naši firmu.