Nový typ DDoS útoku na poštovní servery

Proti útoku, který zahltil poštovní server nejmenované české firmy, lze jen těžko najít obranu. Během páteční n...


Proti útoku, který zahltil poštovní server nejmenované české firmy, lze jen
těžko najít obranu.
Během páteční noci jsme zaznamenali několikerý výpadek na jednom z našich
webhostingových serverů. Naštěstí používáme elektronické hlídací agenty, kteří
pravidelně monitorují stav důležitých služeb (respektive jejich portů) na všech
serverech, a tak jsme se o výpadku dozvěděli prakticky okamžitě. Agenti totiž
při nedostupnosti nějakého portu automaticky příslušnou službu restartují a
informují o výpadku náš technický dohled.

Hledáme příčinu
Vzhledem k tomu, že během dvaceti minut přišlo najednou 8 takových zpráv,
začali se technici obávat závažnějšího problému. Na serveru z logu následně
zjistili, že výpadek se týká výhradně služby SMTP serveru a tento výpadek
nastal v důsledku naprostého přetížení poštovního serveru.
Při letmém pohledu na aktuálně otevřená spojení SMTP portu jsme začali tušit,
že před sebou máme problém větších rozměrů, než na jaké jsme při běžné správě
zvyklí. Na serveru bylo v jednu chvíli otevřeno několik stovek spojení na port
25, a to z různých IP adres. Na základě zkušeností víme, že průměrná zátěž na
tomto serveru je maximálně několik desítek současných požadavků na SMTP portu.
Protože tento server nebyl koncipován na tak obrovskou zátěž, služba SMTP
serveru v pravidelných intervalech kolabovala.
Jednalo se zjevně o útok zvenčí. Z logu bylo zjištěno, že je cílen pouze na
jednu z domén hostovaných na našem serveru. Jako adresát všech příchozích zpráv
byla totiž vždy uvedena neexistují schránka právě této domény. Název schránky
tvořily náhodné znaky, takže z hlediska systému se jednalo vždy o jinou (byť
neexistující) e-mailovou schránku.
Pro tuto doménu nebyl na serveru vytvořen takzvaný doménový koš (kdy se všechny
e-maily pro jednu doménu ukládají do jedné schránky), a proto poštovní server
všechny tyto zprávy automaticky vracel zpět jako nedoručitelné. Jedná se o
chybovou hlášku 550: "Email does not exist on the system" (Takový e-mail v
systému neexistuje).

Komunikace
Podívejme se, jak taková komunikace SMTP serveru na úrovni protokolu funguje.
Je realizována v několika krocích:
1.Nejprve je třeba sestavit TCP spojení na portu 25. Komunikaci zahajuje vždy
server, který chce zaslat nějakou zprávu.
2.Po připojení na cílový server se odesilatel představí (příkaz HELO či EHLO).
3.Následně odesilatel zprávy napíše e-mailovou adresu, ze které je zpráva
odesílána (příkaz MAIL FROM). Nutno podotknout, že toto je jedna z velkých a
veřejně známých slabin protokolu SMTP, neboť do adresy odesilatele si kdokoliv
může napsat jakoukoliv adresu. To, jak jsme ostatně zjistili, je celá podstata
tohoto útoku.
4.V dalším kroku je zadána adresa příjemce (příkaz RCPT TO) a vlastní obsah
(příkaz DATA).
Na tomto místě bych rád podotknul, že naše poštovní servery jsou z důvodu
ochrany před spammery nastaveny velmi restriktivně. Mimo jiné se vzdálenému
serveru kontrolují reverzní DNS záznamy, testuje se, zda jeho IP adresa není v
nějakém veřejném open-relay blacklistu, e-mail je analyzován bayesovskými
filtry a podobně. Těmito všemi testy však uvedené e-maily prošly zcela bez
problémů.

Virus, nebo útok?
Vše tak dosud nasvědčovalo tomu, že se jedná buď o šíření nějakého nového viru
nebo o cílený útok. Že by se mohlo jednat o spam, jsme prakticky ihned
vyloučili. Technici totiž z logu odfiltrovali za poslední tři hodiny provozu
všechny IP adresy, ze kterých byly realizovány pokusy o zaslání neexistujícího
e-mailu na tuto doménu. Bylo nalezeno 2 789 rozdílných IP adres, ze kterých
byly takové požadavky opakovaně zasílány. To již bylo stoprocentně jasné, že
jsme se stali (potažmo doména našeho zákazníka) terčem masivního DDoS útoku.
Okamžitě jsme z těchto adres zakázali přístup k našemu mailseveru. Doufali
jsme, že tak alespoň částečně omezíme rozsah útočících počítačů a postupně
budeme tento blacklist rozšiřovat. Bohužel jsme však zjistili, že tento postup
není příliš účinný. Náš mailserver totiž komunikaci z této IP adresy odmítl až
v okamžiku, kdy e-mailový server odesilatele zaslal hlášku HELO. I takto krátké
spojení samozřejmě zabírá určitou šířku přenosového pásma a kapacitu procesoru.
Zkusili jsme také prověřit část útočících IP adres přes veřejné open-relay
databáze www.ordb.org. Měli jsme sice možnost prověřit najednou pouze 100 IP
adres, ale výsledek byl velmi překvapivý. Pouze dvě adresy ze sta byly
vyhodnoceny jako open-relay (a byly okamžitě zařazeny na blacklist), u
ostatních byly testy negativní. Útok tak byl realizován pomocí poštovních
serverů, které se z hlediska bezpečnosti zdály být naprosto v pořádku.
Začali jsme tedy náhodně testovat některé e-mailové servery běžící na těchto
adresách s cílem zjistit, zda se například nejedná o zneužití nějaké slabiny
jednoho typu e-mailového serveru. Mailservery však byly různorodé nezávislé na
jednom operačním systému a prakticky všechny byly zahraniční (od Anglie až po
Čínu).

Útok ze serveru Nokie?
Nemohli jsme však uvěřit vlastním očím, když jsme zjistili, že jedna z IP adres
patří oficiálnímu SMTP serveru Nokie (mgw x1.nokia.com). Že by se někdo
naboural do mailserveru Nokie a zkoušel z něj na nás útočit? Musím přiznat, že
až v této chvíli nás začal zajímat obsah zpráv zasílaných na neexistující
uživatele.
Vytvořili jsme doménový koš a začali zachytávat všechny takové zprávy. Během
pěti minut byla schránka o velikosti 10 MB zaplněna. Celkem bylo přijato 3 202
zpráv o velikosti v rozmezí 1 až 12 KB.
Začali jsme tyto zprávy pročítat a zjistili jsme, že jsou to výhradně chybové
zprávy o neexistenci e-mailového účtu na serverech odesilatele (opět chyba
550). Poštovní servery, ze kterých jsme předpokládali útok, nám pouze zasílaly
informaci, že nějaký uživatel na serveru neexistuje. Ale proč? Jistě útočník
podvrhl na těchto serverech e-mailovou adresu odesilatele, a o útok na náš
server se tak vlastně postaraly zcela nevinné mailservery.

Princip útoku
Jedná se o velmi promyšlený typ nového distribuovaného útoku. Pro pochopení
předpokládejme, že náš poštovní server poslouchá na adrese smtp.domena.cz a
server zneužitý pro útok na adrese mgw.xdomena.com. Útok pak probíhá takto:
1.Útočník má k dispozici síť počítačů, ze kterých může být útok realizován.
Tyto počítače ovládá zřejmě pomocí trojského koně.
2.Útočník dá infikovaným počítačům pokyn k útoku na poštovní server
smtp.domena.cz. Trojský kůň však neútočí přímo, ale skrze SMTP servery třetích
stran. Trojský kůň buď obsahuje databázi veřejných SMTP serverů nebo například
použije výchozí SMTP server Outlooku.
3.Trojský kůň tedy začne vysílat náhodné zprávy. Připojí se k náhodně vybranému
poštovnímu serveru (například mgw.xdome na.com) a zašle zprávu v tomto formátu:
Od: earwormxawxb@domena.cz Komu: fkgxg1053@xdomena.com
Trojský kůň generuje před zavináčem zcela náhodné znaky, obě adresy jsou tak
podvržené a neexistují ani na jednom ze serverů.
4.Mail server mgw.xdomena.com sice takovou zprávu nejprve přijme, ale záhy
zjistí, že účet fkgxg1053@xdomena.com pod doménou xdomena.com neexistuje.
Reaguje na to tak, že zašle zpět zprávu o neexistenci adresáta. Tuto zprávu
ovšem nezašle zpět útočníkovi, ale na e-mailovou adresu uvedenou jako
odesilatele. Tedy na adresu earwormxawxb@domena.cz.
5.Na server smtp.domena.cz tak přichází tato zpráva o nedoručení. Ale protože
ani na tomto serveru neexistuje příjemce (ear wormxawxb@domena.cz), je zpráva
odmítnuta.
Nyní by se dalo čekat, že se vytvoří nekonečný cyklus chybových zpráv
zasílaných neexistujícím uživatelům mezi těmito dvěma servery. Naštěstí s tímto
problémem poštovní servery počítají a zprávu na druhou chybovou událost
mailserver neodešle.

Velké nebezpečí
Na první pohled nevypadá tento problém nikterak nebezpečně, ostatně na
podvržené hlavičky zpráv jsme si již zvykli například od různých typů
e-mailových virů. Ale když je takový útok realizován z desítek až stovek
poštovních serverů současně, nemáte moc šancí zabránit výpadkům. Velké
nebezpečí tohoto DDoS útoku spočívá v prakticky nulové šanci se mu jakkoliv
bránit.
Jak tento problém vyřešit? Upřímně řečeno, v tomto okamžiku nevím. My jsme
zatím přesměrovali MX záznamy pro uvedenou doménu na samostatný server. Ten
nyní slouží jako poštovní server výhradně pro tuto doménu a jeho případné
zahlcení neohrozí ostatní e-mailové účty. Pravda, systémové řešení to rozhodně
není, ale na nic lepšího jsme zatím nepřišli.
Autor je nezávislým konzultantem a specialistou v oblasti rozsáhlých datových
modelů. Zabývá se především problematikou síťových technologií, návrhem a
implementací multiplatformních informačních systémů, prototypových řešení a
obecných generátorů informačních systémů.
Řešíte podobné problémy jako autor tohoto textu Vít Vrba? Podělte se o svoje
zkušenosti s námi i se čtenáři Computerworldu. Můžete psát na adresu
bezpecnost@idg.cz.

Útok v kostce
Cílem útoku může být jakýkoliv poštovní server.
Jakýkoliv poštovní server může být zneužit pro distribuovaný útok.
To, že je daná zpráva součástí distribuovaného útoku, lze zjistit až po jejím
přijetí.
Poštovní servery zneužité k útoku není možné dát na blacklist (co kdyby vám
někdo z tohoto serveru posílal reálnou zprávu?).
Provozovatel zneužitého serveru neví, že byl jeho server zneužit pro útok.
Velmi obtížně se odhaluje útočník.
Proti tomuto druhu útoku neexistuje žádná záplata (a zřejmě nikdy existovat
nebude), neboť se v principu nejedná o chybu, ale o podstatu protokolu SMTP.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.