How to prevent the spread of backscatter emails by email servers of MU

Jak to funguje?

Útočník jednoduše nastaví e-mailovou adresu oběti nejen jako odesílatele, ale také jako příjemce e-mailu, čímž u uživatele vyvolává dojem, že byl e-mail opravdu odeslaný z jeho účtu sobě samému. Pomocí této manipulace se snaží útočník oběť přesvědčit, že má plnou kontrolu nad jeho zařízením a v rámci toho jej v diskrétní chvíli natočil při sledování pornografického obsahu.

Uživatel se může nechat takto zmanipulovat i v případě, kdy dostane notifikaci o nedoručení e-mailu. E-mail byl přeci zablokován e-mailovým serverem, který není infikován a udělal to, co měl. Narativ útočníka, že má pod kontrolou počítač, potažmo e-mailovou schránku oběti, tím tolik neztrácí na uvěřitelnosti. Jindy je zfalšovaná adresa odesílatele neplatná, ale i v tomto případě pokus o “odražení” e-mailu představuje zbytečnou komunikační a výpočetní zátěž.

Jak prvnímu scénáři zabránit?  

Velmi jednoduše – e-mailové servery je třeba překonfigurovat tak, aby e-maily, které jakýkoli filtr označí jako závadný, nezasílaly na adresu odesílatele až po jeho přijetí (bounce), ale odmítly (reject) je přímo při přijímaní. Toto odmítnutí e-mailový server provede během SMTP přenosu, dokud je spojení se skutečným odesílatelem závadného e-mailu stále otevřené – tedy ještě předtím, než vstoupí na e-mailový server. Toto odmítnutí může mít návratový kód 4xx pro dočasné odmítnutí (například „mailbox busy”) nebo 5xx pro trvalé odmítnutí (například „no such user”). [1] navrhuje návratový kód 554, [2] a [3] navrhují 550. Takto odmítnutí dostane pouze skutečně odesílající server, který by o tom měl upozornit svého lokálního odesílatele, obzvlášť jestli jde o legitimní e-mail. Spam často rozesílají boti, kteří ani neposlouchají.

Takhle elegantní řešení už po uzavření spojení se skutečně odesílajícím serverem není možné, a “odražení” (bounce) e-mailu je možné udělat pouze podle informací ve zfalšovaných hlavičkách e-mailu, co už problém pouze zhoršuje. Taktéž již poté není možné spolehlivě a bezpečně upozornit odesílatele na nedoručení e-mailu. I dle novějších RFC se nemají „odrážet” e-maily, u kterých není rozumná jistota, že “odražené” zprávy budou „užitečně doručeny” – samozřejmě, skutečnému odesílateli. Pro celý tento problém se stejně tak nedoporučuje používat automatické odpovědi na e-maily, nebo v případě nevyhnutelnosti jen za silným spamovým filtrem doplněným o kontrolu pověřenou osobou. To samé platí pro Challenge / Response – problém pouze přesouvají od příjemce na ty, kteří jsou falešně uvedeni jako odesílatelé závadných e-mailů, a navíc je lehké je zneužít a obejít. I používání těchto mechanizmů lehko může vést k tomu, že náš e-mailový server skončí na blacklistech.

Další detaily a rady, které považujeme za obzvlášť relevantní, naleznete v poslední sekci tohoto článku.

Jak zabránit druhému scénáři?

Jediný způsob, jak zabránit tomuto druhému scénáři, je být důsledný ve filtrování závadných e-mailů na našem serveru, abychom minimalizovali riziko, že závadný e-mail, který my přepošleme jinam, bude vrácený.

Další podrobnosti k řešení 

Mnohé závadné e-maily je možné odfiltrovat jednodušeji než pokročilým spamovým filtrem typu SpamAssasin. Jde zejména o prověření, zda adresa odesílatele není na blacklistu, a zda byl e-mail odeslaný běžným e-mailovým klientem, ale i spousty dalších věcí. Příklady takovéto konfigurace Postfixu jsou v [1] a [3]. [1] doporučuje začínat filtry méně náročnými na výpočty, a hlavně komunikaci s jinými servery, a postupně jít k náročnějším, pokročilé filtry typu SpamAssasin či Bayesovo filtrování pak ponechat úplně na konec. Zpráva je nakonec přijata pouze pokud projde všemi filtry. Takto je možno dosáhnout maximální efektivity filtrování. [3] radí, jak je alespoň v některých případech možné detekovat zfalšovanou adresu odesílatele, a v poslední řadě načrtává, jak filtrovat notifikace od antivirových skenerů. [4] popisuje specifický případ celého tohoto problému.