Portál AbcLinuxu, 8. června 2024 03:46
MessageWall - kladivo nejen na spam
Články
-
MessageWall - kladivo nejen na spam
Jak konečně vyřešit problémy se spamem.
Úvod
Problematika nevyžádaných mailů, případně rovnou obsahujících nějaký typ
viru, neztrácí na aktuálnosti, spíše naopak. Dnes bych vás rád seznámil
s jednou z možností obrany. Jak poznáte dále, není to sice možnost ideální
(taková prostě neexistuje), leč z mnou prozkoumaných mě zaujala nejvíce, a
sám ji již několik měsíců úspěšně používám. Jde o projekt jménem
MessageWall, který je krátce
charakterizovatelný slovy 'SMTP proxy'.
Princip funkce
MessageWall se spustí jako démon, naslouchající na konkrétní síťové
adrese (konfigurační volba 'listen_ip'), a to na standardním SMTP portu 25.
Současně otevře několik spojení s cílovým MTA (dáno konfigurační volbou
'backend_ip'). Tento cílový MTA může běžet jak na libovolném dalším
dostupném stroji (například již v lokální síti), tak přímo na stroji
s MessageWallem. Stačí ho jen nakonfigurovat, aby naslouchal na příslušné
adrese a portu (v mém případě je to např. Postfix naslouchající pouze na
127.0.0.1:25). MessageWall sám není MTA a nedělá nic jiného, než že veškerá
spojení transparentně (téměř) přesměrovává na cílový (backend) MTA. Nároky
na kladené MTA nejsou nikterak velké a vyhoví jim prakticky každý
běžný/moderní MTA (Sendmail, Postfix, qmail).
Jak jsem již zmínil v závorce výše, ona zmíněná transparentnost není
zdaleka stoprocentní, ale to je právě to, co se od programu očekává. Každý
přicházející či procházející mail je kontrolován široce konfigurovatelnou
sadou pravidel. Pokud mail pravidlům z nějakého důvodu nevyhoví, je
odmítnut již na úrovni SMTP spojení, v případě nevhodné přílohy je možné
tuto odstranit. V ideálním případě se tedy u nevyžádaného mailu vlastně
nepřenese více, než úvodní sekvence SMTP povelů a odpovědí. Úplný seznam
dostupných kontrol je k dispozici na domovské stránce projektu, pro účely
tohoto článku vybírám následující:
- antivirová kontrola s použitím pattern souborů z programu Open
AntiVirus
- kontrola proti internetovým blacklistům
- kontrola MX/A záznamu zdrojové adresy
- kontrola zdrojové a cílové adresy
- kontrola jmen souborů MIME příloh
- kontrola MIME typu příloh, případně jejich odstranění
Pro doplnění: mezi další vlastnosti patří například podpora SMTP
autentizace a SSL/TLS spojení, a to jak ze strany klientů, tak s cílovým
(backend) serverem.
Instalace
Kompilace a instalace výjimečně není zcela triviální posloupností
./configure; make; make install, tím ale nechci říci, že je
složitá. Její podrobný popis je k dispozici na domovské stránce projektu,
zde provedu jen lehký nástin, abyste věděli, co vás čeká.
Nejprve je třeba zkompilovat a nainstalovat podpůrné knihovny
'firestring'a 'firedns'. Obě jsou dostupné rovněž na webu MessageWallu a v
jejich případě vystačíte s klasickou posloupností ./configure; make;
make install. Standardně se instalují do adresáře
/usr/local/lib, takže je vhodné zkontrolovat přítomnost tohoto
adresáře v /etc/ld.so.conf a poté spustit
ldconfig. Autoři ještě doporučují instalaci 'daemontools'
(slouží, jak název napovídá, pro usnadnění práce s démony - nepoužil jsem)
a knihovny 'OpenSSL'.
Nyní již k instalaci vlastního MessageWallu. Začnete opět klasickým
./configure; make; make install. Poté však musíte udělat
několik manuálních kroků. Konkrétně to znamená nakopírovat profily
(předpřipravené seznamy filtrovacích pravidel) do příslušného adresáře a
podobně nakopírovat soubor s virovými signaturami. V neposlední řadě je
třeba vytvořit dva uživatele a dvě skupiny a připravit jim jejich domovské
adresáře (MessageWall neběží pod rootem a běží v chroot prostředí). Tím je
instalace hotova.
Konfigurace
Hlavní konfigurační soubor MessageWallu je standardně
/usr/local/etc/messagewall.conf. Tento je dobře okomentován,
takže by s nastavením neměl být vážnější problém. V mém případě jsem musel
téměř všechny konfigurační položky odkomentovat, protože se MessageWall
odmítal spustit a tvářil se, že nezná default hodnoty. Důležité je
správně nastavit položky 'listen_ip' a 'domain', případně 'backed_ip', u
zbytku se dá vesměs vystačit s default nastavením.
Ve výše zmíněném konfiguračním souboru je, mimo jiné, definován výchozí
profil (seznam filtrovacích pravidel) a odkazy na další konfigurační
soubory, umístěné v rootu chroot prostředí. Konkrétně jsou to například
soubor 'special_users', kde jsou definovány adresy a profily uživatelů
s jiným než výchozím profilem a nebo soubor 'relay_ips' se seznamem IP
adres, které mají povolen relay.
Soubor profilu vypadá například takto (profil Medium, který je po
instalaci jako defaultní):
reject_score=1
dnsbl=1,list.dsbl.org
dnsbl=1,bl.spamcop.net
rmx_required=1,1
filename_reject=1,.exe
filename_reject=1,.pif
filename_reject=1,.scr
filename_reject=1,.vbs
filename_reject=1,.bat
filename_reject=1,.com
filename_reject=1,.shs
filename_reject=1,.wsc
header_rejecti=1,Precedence:junk
header_rejecti=1,X-Mailer:Microsoft CDO
header_rejecti=1,X-Mailer:eGroups Message Poster
header_rejecti=1,X-Mailer:Delphi Mailing System
header_rejecti=1,X-Mailer:diffondi
header_rejecti=1,X-Mailer:RoryMAILER
header_rejecti=1,X-Mailer:GreenRider
header_rejecti=1,X-Mailer:GoldMine
header_rejecti=1,X-Mailer:MailPro
header_rejecti=1,X-Mailer:charset(89)
header_rejecti=1,X-Mailer:MailWorkZ
header_rejecti=1,X-Mailer:bulk
virus_scan=1,virus.patterns
První řádek definuje celkové maximální 'skóre', při jehož dosažení bude
mail odmítnut, další řádky jsou pak již jednotlivá filtrační pravidla.
První parametr každého pravidla (za rovnítkem) je opět 'skóre', tentokrát
to, o které se celkové 'skóre' zvýší při 'pozitivním nálezu'. V konkrétním
případě to znamená, že bude odmítnut každý mail, který neprojde byť jen
jediným pravidlem.
Spuštění
Před spuštěním je nutné si uvědomit, že musíte mít volný SMTP port 25 na
'listen_ip' adrese, aby se na něj MessageWall mohl 'bindnout'. Prakticky to
znamená odsunout případný běžící MTA na jinou adresu. Prvotní spuštění je
pak vhodné udělat prostým zavoláním binárky z příkazové řádky, protože se
z probíhajícího výpisu okamžitě dozvíte, co se děje, a tedy i případné
problémy. Pokud se daří MessageWall spustit, stačí se již jen postarat o
jeho pravidelné spouštění při startu serveru. Autoři k tomu doporučují výše
zmíněné 'daemontools', já si do svých startovacích scriptů prostě
přidal:
/usr/local/bin/messagewall 2>&1 | logger -p local0.notice &
(předtím jsem ovšem patřičně upravil /etc/syslog.conf a
doplnil konfiguraci rotace logů).
Nevýhody
Jak jsem již zmínil na začátku, ideální tento systém není. Během
několikaměsíčního provozu jsem narazil na pár věcí, na které bych rád
případné zájemce o provoz upozornil.
První nepříjemností je, že MessageWall je ochoten přijmout jednotlivý
mail pouze pro jediného příjemce. Pokud je mail adresován více příjemcům,
musí se jeho přenos pro každého z nich znovu opakovat. Prakticky to vypadá
takto:
220 domena.cz MessageWall 1.0.8 (You may not relay)
MAIL FROM:<nekdo@nekde.cz>
250 MessageWall: OK
RCPT TO:<prvni@domena.cz>
250 MessageWall: OK
RCPT TO:<druhy@domena.cz>
452 MessageWall: SMTP/TEMPORARY: One recipient per message from external
hosts, please
Nyní záleží na odesílajícím serveru, jak se zachová. Naprostá většina
serverů zareaguje správně, dokončí přenos, a po chvíli vyvolá nové spojení
pro dalšího příjemce. Bohužel jsem však v logu našel i případ serveru,
který okamžitě po chybě '452' spojení ukončil a vyvolal nové. Toto nové
spojení však ihned znovu se stejnou chybou skončilo a tento kolotoč se
neustále opakoval mnoho hodin (nakonec jsem zmíněnému serveru zatnul tipec
díky iptables)...
Toto nepříjemné chování MessageWallu je jen zdánlivě nelogické. Důvodem
je to, že každý jednotlivý cílový adresát může mít zcela jiný soubor
filtračních pravidel. Pro některé z nich může být jeden konkrétní mail
'závadný', pro jiné naopak. Protože se však vyhodnocování děje již během
SMTP přenosu a ne až po jeho ukončení, zvolili autoři programu toto řešení.
Logickým důsledkem je prodloužení doby potřebné k doručení jednotlivého
mailu všem adresátům, a především pak navýšení zátěže linky.
Oblíbené 'odeslání pětimegabajtového filmečku všem lidem z adresáře' pak
může v případě více adresátů ve vaší doméně dramaticky zvýšit přenášený
objem dat. Je na každém z vás odhadnout nebo vysledovat, kolik takových
mailů chodí a jak moc je pro nás toto chování nepříjemné a podle toho
rozhodnout o (ne)nasazení MessageWallu.
Zatímco na předchozí nepříjemnost jsem narazil již při počátečním
testování, na druhou jsem narazil až během provozu. Jedná se o nastavení
omezení velikosti jednotlivého mailu. Při prvotní konfiguraci jsem tuto
velikost nastavil na standard používaný v naší společnosti, totiž 4MB.
Později jsem si při prohlížení MRTG grafu zátěže naší linky všiml náhle se
objevivších podivně pravidelných 'pahorků'. Po chvilce pátrání jsem viníka
našel v MessageWallu, konkrétně to vypadalo nějak takto:
220 domena.cz MessageWall 0.9.36 (You may not relay)
EHLO foo
250-MessageWall: Hello
250-PIPELINING
250-8BITMIME
250 SIZE 4194304
MAIL FROM:<nekdo@nekde.cz> SIZE=5000000
250 MessageWall: OK
RCPT TO:<nekdo@domena.cz>
250 MessageWall: OK
Přenos mailu se normálně spustil a po přenesení 4MB skončil s chybou. Po
asi čtvrthodinové odmlce vzdálený server znovu navázal spojení a situace
se opakovala. A to opět mnoho dlouhých hodin...
Logické by bylo, že pokud MessageWall v odpovědi na EHLO specifikuje
maximální velikost (zde 250 SIZE 4194304), vzdálený server
by v případě delšího mailu vůbec neměl pokračovat. Pokud už pokračuje, měl
by ho MessageWall odmítnout ihned poté, co nepřípustnou velikost sám
vyspecifikuje (zde MAIL FROM:<nekdo@nekde.cz>
SIZE=5000000). Bohužel toto se neděje a po důkladném pátrání v RFC
jsem zjistil, že se zmíněnou situací není vůbec počítáno. Po dotazu u
autorů MessageWallu mi byly mé závěry potvrzeny, leč bez náznaku řešení.
Situaci jsem dočasně vyřešil zvýšením limitu velikosti mailu, v případě
potřeby si však v budoucnu hodlám opravit zdrojový kód k obrazu svému.
Závěr
Nemám závěry rád, a proto nechť si z výše poskytnutých informací udělá
každý svůj závěr sám. Já osobně však MessageWall (kromě řešení dvou výše
zmíněných nepříjemností) používám k téměř plné spokojenosti...
Související články
Odkazy a zdroje
Další články z této rubriky
Diskuse k tomuto článku
2.1.2003 13:02
pet
Omezeni velikosti
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
3.1.2003 16:16