LINUXZONE






 >> Hlavní stránka

(1751/28.09.2010)


 >> Administrace

(161/05.08.2010)


 >> Literatura

(312/14.09.2010)


 >> Bezpečnost

(347/17.09.2010)


 >> Programování

(307/19.04.2010)


 >> Distribuce

(98/16.09.2010)


 >> Síťování

(86/03.06.2010)


 >> Lokalizace

(10/15.09.2004)


 >> Aplikace

(176/12.08.2010)


 >> Multimedia

(32/31.03.2006)


 >> Hardware

(45/02.03.2007)


 >> Začínáme

(229/09.09.2010)


 >> Aktuálně

(564/20.09.2010)


 >> RELAX

(213/28.09.2010)


 >> Jinde vyšlo

přehled ostatních serverů




 Coolhousing




Coolhousing - Vas poskytovatel dedikovanych serveru




 Přihlášení




Login:
Heslo:
 uložit v prohlížeči


Nejste-li ješte zaregistrováni, můžete tak učinit zde.





 Vyhledávání




Hledaný výraz:
v klíčových slovech
v titulku
v anotaci
v textu








 Reklama









 Servis




*   Vaše náměty a připomínky
Máte k Linuxzone.cz nějaké připomínky nebo náměty? Našli jste na stránkách chybu? Dejte nám o tom vědět pomocí formuláře nebo v diskuzi.
Komentářů: 60
*   Podpořte Linuxzone.cz
Chcete podpořit náš server umístěním odkazu nebo zveřejněním backendu? Zde najdete vše potřebné.
*   Pište pro Linuxzone.cz
Máte zájem podílet se na obsahu Linuxzone.cz ať už jako redaktoři nebo i jinak? Dejte nám o sobě vědět!





 Aktuálně z bezpečnosti




-- 
6.12.2005, 19:01
Na serveru informit.com vyšla ukázková kapitola týkající se práce s řetězci z knihy Secure Coding in C and C++. (lz)

-- 
3.12.2005, 12:34
Bugtraq: Format String Vulnerabilities in Perl Programs. (lz)

-- 
3.12.2005, 12:32
Linux Advisory Watch December 2nd 2005. (lz)

-- 
23.10.2005, 13:28
Rozhovor na téma klasické zálohování versus CDP. (lz)

-- 
23.10.2005, 13:24
Linux Advisory Watch October 21st 2005. (lz)

další >>





 Aktuálně o software




-- 
6.12.2005, 19:07
Potřebujete-li pod linuxem rozchodit bezdrát založený na čipsetech Broadcom 43xx, konečně existuje linuxový ovladač. (lz)

-- 
6.12.2005, 19:04
Byla uvolněna verze Xen 3.0.0 virtualizační technologie XEN. (lz)

-- 
6.12.2005, 18:59
Byla uvolněna verze X11R6.9/X11R7 RC 3 grafickérho rozhraní X Window System. (lz)

-- 
3.12.2005, 12:45
Co je nového okolo projektu Amanda (open source zálohovací software)? Více na osnews.com. (lz)

-- 
3.12.2005, 12:40
Jak to akuálně v linuxu vypadá s podporou SATA.. (lz)

další >>





 Aktuálně z IT




-- 
3.12.2005, 12:51
Novellu se daří prodej linuxových produktů, oproti loňskému roku se Novell dočkal výrazného nárůstu. (lz)

-- 
3.12.2005, 12:48
Třetí verzi licence GPL by měla být publikována během jara 2007. (lz)

-- 
23.10.2005, 13:20
V Peru nyní mají zákon, který umožňuje nasazení open source software ve vládní správě. (lz)

-- 
23.10.2005, 13:14
Proč se Microsoft bojí Google? (lz)

-- 
27.9.2005, 22:01
Peru má zákon podporující free software. (lz)

další >>





 Nejčtenější články









 Nejlepší články









 Anketa




Používáte nějaké rozšíření bezpečnostního modelu linuxového jádra?

Openwall (17%)

LIDS (11%)

Pax/Grsecurity (3%)

SELinux (6%)

RSBAC (1%)

jiné (1%)

používám standardní jádro (62%)







Linuxzone.cz - server o Linuxu pro programátory, administrátory a fanoušky.
Provozuje společnost Impossible.
ISSN: 1213-8738





Filtrování spamu

Neprovozuje-li uživatel elektronické pošty vlastní mail server, může být pro něj jednou z mála možností obrany proti spamu filtrování zpráv podle obsahu. Jak v takovém případě účinně postupovat a přitom neriskovat ztrátu legitimních zpráv?

Univerzální návod asi neexistuje. Mohu se však s vámi podělit o své zkušenosti se systémem filtrování, který již nějakou dobu celkem úspěšně používám.

Prvním opatřením je nepoužívat e-mail zbytečně. Typickým příkladem zbytečného používání e-mailu jsou veřejné e-mailové diskusní skupiny s mnoha přihlášenými čtenáři. Obecně efektivnějším mechanismem hromadné distribuce zpráv tohoto typu je používání news (NNTP) serverů, který také umožňuje efektivnější odfiltrování spamu. Z tohoto přístupu vychází server Gmane, který slouží k mapování e-mailových konferencí na news. Gmane všechny přicházející zprávy automaticky klasifikuje na legitimní zprávy (ham) a nevyžádané zprávy různého druhu (spam). Odhalí-li na Gmane kterýkoliv čtenář chybně klasifikovanou zprávu, může ji velmi snadno nahlásit administrátorům a ti zajistí nápravu. Díky spolupráci čtenářů tak Gmane umožňuje, mimo jiné, číst e-mailové konference zbavené velké většiny spamu.

I po vyloučení e-mailových konferencí však ještě stále zůstává dost spamu ke zpracování. Kupříkladu na mé osobní e-mailové adresy přichází bezmála 200 kusů junk mailu různého druhu denně. Co s tím? Nelze-li poštu filtrovat na úrovni mail serveru, kde lze velmi účinně a kooperativně používat metody jako kontrolu odesílatele, greylisting nebo různé spamové databáze jako je například Razor, lze alespoň celkem úspěšně používat filtrování zpráv podle jejich obsahu. Filtrování podle obsahu je použitelné téměř vždy a všude, a proto stojí za to se jím podrobněji zabývat.

Doby, kdy bylo možno většinu spamu poměrně snadno identifikovat podle několika jednoduchých a jasných kritérií, jsou nenávratně pryč. Spammeři své metody zdokonalují a snaží se spam co nejvíce maskovat, aby nebyl snadno rozeznatelný od hamu. Jak tedy může i za takových okolností počítač spam automaticky rozpoznat?

Od chvíle, kdy vyhlášený lispový guru Paul Graham dosáhl vynikajících úspěchů s bayesovským statistickým filtrem, stala se velmi populární klasifikace zpráv podle automaticky natrénované databáze slov a řetězců. I sebelépe maskovaný spam musí obsahovat nějakou nabídku a různé jiné příznaky, podle kterých jej pilný klasifikátor v podobě počítače obvykle rozezná.

Metody filtrování založené na principu automatické analýzy obsahu mají pro uživatele na rozdíl od jiných metod zkoumání obsahu zpráv velkou výhodu v tom, že člověk při jejich používání není nucen prohrabovat se hromadami nechutností. Na druhou stranu nevýhodou těchto metod je, že nejsou neomylné. Dojde-li k občasnému propuštění spamu mezi ham, ještě se tak moc neděje, horší je, je-li ham označen jako spam. Uživatel tak má na výběr mezi rizikem ztráty e-mailových zpráv a pravidelným kontrolováním hromady spamu na přítomnost chybně klasifikovaného hamu. Ani jedno z toho není ideální.

Řešení, které se mi osvědčilo, je použití dvou nezávislých statistických filtrů, jednoho s velmi vysokou přesností a jednoho konzervativního, který se snaží být velmi opatrný a zprávy raději klasifikovat jako ham než jako spam.

Jako primární filtr používám CRM114. CRM114 je zcela symetrický klasifikátor, který žádný typ zpráv neprotěžuje. Jeho dalšími charakteristickými uživatelskými vlastnostmi jsou vysoká přesnost klasifikace a rychlé učení se. Autor CRM114 o svém klasifikátoru tvrdí, že při jeho používání dosahuje velmi vysoké přesnosti klasifikace, významně přesahující 99,9%. Vysoká přesnost CRM114 je umožněna tím, že CRM114 používá nejen prosté vyhodnocování přítomnosti slov z databáze, nýbrž srovnává i celé skupiny slov a novější verze CRM114 obsahují i rafinovanější (avšak zatím nepříliš odladěné a přesvědčivé) metody. CRM114 navíc umožňuje zprávy klasifikovat do více skupin, můžete si je tedy rozdělit například na ham, nevyžádané komerční zprávy, viry, oznámení o nedoručených mailech, spam od tzv. antivirových programů a ostatní junk mail. A díky vlastnosti rychlého učení se nemusíte skladovat tisíce zpráv jenom pro případ, kdybyste si náhodou svoji naučenou databázi nějakým způsobem poškodili a potřebovali ji natrénovat znovu.

Zkušenosti s přesností CRM114 jsou různé. Někteří uživatelé potvrzují vynikající výsledky kolem 99,98%, jiní zase takové přesnosti zdaleka nedosahují. Já s pomocí CRM114 klasifikuji veškeré příchozí e-mailové zprávy a dělím je na dvě skupiny: ham (legitimní zprávy) a spam (všechen junk mail). Po natrénování asi třemi tisíci zprávami u mě CRM114 dosáhlo přesnosti klasifikace 99,3%. Od té doby již přesnost CRM114 neměřím, odhaduji, že se ještě o něco zvýšila a dosahuje 99,6-99,8%.

Uvedené 99,3% přesnosti jsem dosáhl až po mnoha pokusech, kdy jsem se dopouštěl různých chyb a dosahoval přesnosti výrazně nižší. Mohu uvést několik doporučení, jak se v případě CRM114 degradaci přesnosti vyhnout.

V první řadě je třeba respektovat jisté vlastnosti učení CRM114, které lze shrnout do následujících bodů:

  • Při prvním učení je dobré CRM114 předkládat střídavě ham a spam, ne tedy třeba napřed všechen ham a pak teprve všechen spam. Osobně používám metodu, kdy všechny zprávy setřídím podle jejich MD5 součtů a v tomto pořadí jimi CRM114 krmím.
  • CRM114 dosahuje mnohem lepších výsledků, když se neučí všechny zprávy, nýbrž jen zprávy, které klasifikuje špatně. Jedná se o tzv. metodu TOE (Train Only Errors).
  • Po naučení se nové (předtím chybně klasifikované) zprávy je dobré nechat CRM114 opakovaně klasifikovat větší množství předchozích, již jednou klasifikovaných zpráv a opravovat omyly tak dlouho, až jsou všechny tyto zprávy klasifikovány správně. Jedná se o tzv. metodu TUNE (Train Until No Error).

I při dodržení tohoto postupu se mi nějakou dobu nedařilo s CRM114 dosáhnout vyšší přesnosti než jen něco okolo 98%. Po čase jsem zjistil, že dva problémy způsoboval lidský faktor:

  • V trénovacích sadách zpráv byly chyby: v hamu se občas omylem vyskytoval spam a ve spamu ham. Ukázalo se, že pro člověka je poměrně pracné několik tisíc zpráv roztřídit zcela správně. Problém jsem nakonec vyřešil tak, že v případě všech zpráv, které CRM114 klasifikovalo chybně, jsem zkontroloval, zda se jedná opravdu o chybu klasifikace CRM114 nebo o chybu moji. Tato spolupráce člověka a stroje vedla velmi rychle k opravě chyb v mé databázi zpráv a tím pádem ke zvýšení přesnosti klasifikace.
  • Množina hamu předkládaného k učení nebyla kompletní. CRM114 tak neznalo určité druhy legitimních zpráv a dělalo pak na jim podobných zprávách chyby. Zejména je (pochopitelně) háklivé na zprávy v nových jazycích nebo jej může zmást, jsou-li zprávy nově stahované z jiného serveru nebo na jiný počítač (což se projeví v hlavičkách).

Přesnost 99,3% je z hlediska odfiltrování spamu v současné době dostačující. Není však postačující z hlediska rizika smazání legitimního mailu. Navíc přestože omyly CRM114 jsou obvykle klasifikovány se skóre blízkým hranici mezi hamem a spamem, někdy se stává, že CRM114 klasifikuje legitimní zprávu s vysokým spamovým skóre. Proto jsem se rozhodl CRM114 zkombinovat s konvenčním filtrem, který má v duchu Grahamova řešení tendenci zprávy klasifikovat spíše jako ham než jako spam, čímž snižuje riziko ztráty legitimní zprávy, ovšem za cenu méně účinného filtrování spamu. Dochází tak ke kombinaci nezaujatého filtru (CRM114), jehož omyly jsou zřídkavé, ale dochází k nim v obou směrech, a konzervativního filtru (konvenční grahamovský filtr), který jen zcela výjimečně označí ham za spam, zato ale poměrně často nerozpozná spam.

Za doplňující filtr jsem si z velkého množství dostupných možností vybral bogofilter. Byla to volba víceméně náhodná, mohl bych použít asi kterýkoliv jiný podobný. Na bogofilteru mi bylo sympatické, že před klasifikací odfiltrovává některé nepodstatné (opravdu nepodstatné) matoucí informace z hlaviček a že zprávy klasifikuje do tří skupin "ham", "spam" a "nejisté", přičemž v případě zpráv klasifikovaných jako ham nebo spam je jistota správného výsledku poměrně vysoká. Cenou za to je, že ve skupině "nejisté" končí poměrně značné množství zpráv, v mém případě při spíše konzervativní konfiguraci zpočátku takových zpráv bylo asi 10%, po delší době používání je jich o něco méně.

Bogofilter učím zcela odlišným způsobem, než jakým učím CRM114. Zatímco CRM114 trénuji jen na omylech, bogofilteru předkládám k učení všechny přijaté zprávy, klasické bayesovské filtry by takto měly fungovat lépe. Algoritmy klasifikace i způsob učení jsou tedy v případě těchto klasifikátorů natolik odlišné, že je jen velmi málo pravděpodobné, že se na nějaké zprávě zmýlí oba klasifikátory současně.

Používám následující strategii rozdělení klasifikovaných mailů:

  • Pokud se oba klasifikátory shodnou, považuji toto rozhodnutí za definitivní, zprávy označené jako ham uložím a zprávy označené jako spam smažu.
  • Pokud bogofilter neoznačí zprávu za nejistou a jeho klasifikace je odlišná od CRM114, zařadím tuto zprávu do zvláštní skupiny chyb (jeden z klasifikátorů se nutně musel zmýlit), kterou při nejbližší příležitosti prověřím a zajistím nápravu. K této situaci nedochází často, v průměru asi tak jednou za dva dny, není to tedy příliš obtěžující.
  • Pokud bogofilter označí mail jako nejistý a CRM114 jej označí za spam, jedná se pravděpodobně o spam, který zařadím do skupiny bogofilterem nerozpoznaných spamů. Tuto skupinu jednou za čas kontroluji, zda neobsahuje vinou CRM114 chybně klasifikovaný ham.
  • Pokud bogofilter označí zprávu jako nejistou a CRM114 ji označí za ham, zařadím ji do častěji kontrolované skupiny bogofilterem nerozpoznaných zpráv. Protože bogofilter má tendenci stranit hamu, je většina zpráv klasifikovaných jako "nejisté" ve skutečnosti spam. Pokud tedy CRM114 o některé z takových zpráv tvrdí, že je to ham, je dost možné, že se mýlí.

~/.procmailrc by tento postup mohl být zapsán například následovně (pozor, každý své mailové schránky strůjce, za chyby neručím!!):

DEFAULT=$HOME/Mailbox

# Užitečné při ladění...
:0c:
$DEFAULT-backup

# Necháme bogofilter, aby se sám sebou klasifikovaný mail naučil dříve, než
# jsou vloženy hlavičky CRM114:
:0fw: .procmail.lock
| bogofilter -e -p -u | grep -v '^X-Bogosity:'

# Klasifikace CRM114
:0fw
| /usr/bin/crm -u $HOME/crm mailfilter.crm

# Klasifikace bogofilter
:0fw
| bogofilter -e -p

# Oba klasifikátory mail označily za spam
:0
* X-CRM114-Status: SPAM
* X-Bogosity: Yes
{
  # Zprávy z automatických systémů rovnou zahodíme
  :0
  * ^FROM_DAEMON
  /dev/null

  # Stejně tak nejběžnější virus
  :0B
  * filename="_*warn\.txt"
  /dev/null
  
  # Ostatní uložíme do spamu, kdyby někdy náhodou...
  :0c:
  $DEFAULT-spam

  # A zalogujeme:
  :0i:$HOME/.procmail-spam.lock
  | formail -c -X from: -X subject >> $HOME/.procmail-spam.log
}

# Oba klasifikátory mail označily za ham
:0:
* X-CRM114-Status: Good
* X-Bogosity: No
$DEFAULT

# Neshody
:0:
* X-CRM114-Status: Good
* X-Bogosity: Yes
$DEFAULT-misclassified

:0:
* X-CRM114-Status: SPAM
* X-Bogosity: No
$DEFAULT-misclassified

# Nejistota bogofilteru
:0:
* X-CRM114-Status: Good
$DEFAULT-maybe-crm-failure

:0:
$DEFAULT-probably-spam

Zprávy vyhodnocené jako spam je nejlepší rovnou mazat a není dobré posílat automatické upozornění odesílateli. Spam a viry totiž často obsahují falešné adresy odesílatele a nelze-li zprávu odmítnout již na úrovni SMTP relace, vrací se pak taková upozornění jako bumerang. A co je horší, dochází k obtěžování nic netušících uživatelů, jejichž adresy jsou podvodně uvedeny v hlavičce From:. Právě kvůli eliminaci automatických upozornění používám systém dvou filtrů, s upozorněním odesílateli by stačil jediný filtr s dostatečnou přesností a na všechny privátní zprávy klasifikované jako spam by bylo možno automaticky posílat upozornění jejich odesílatelům. E-mail je bohužel zneužíván natolik nevybíravými způsoby, že takový postup není dobře možný.

U dvěma rozdílnými filtry zpracovaných zpráv je riziko ztráty legitimní zprávy velmi nízké a únosné. E-mail je ze své podstaty služba nespolehlivá a ke ztrátám zpráv z různých důvodů dochází. Je-li tedy legitimní zpráva zcela výjimečně chybně smazána antispamovými filtry (zatím mi není v případě mého filtru znám žádný takový případ), lze to v rámci celkové nespolehlivosti e-mailu zanedbat. Důležité je, že není nutné dodatečně prohledávat hromady spamu, zda náhodou neobsahují ham. Stačí to provádět pouze s malou částí příchozího spamu, který bogofilter klasifikuje jako "nejistý".

Závěr

Uvedeným způsobem lze poměrně účinně odfiltrovávat veškerý junk mail -- nevyžádané obchodní nabídky, viry, spam generovaný antivirovými programy a jiné automatické odpovědi na zprávy, které jste ve skutečnosti nikdy neodeslali. Jeho účinnost obecně nelze garantovat, může být velmi individuální, ale v mém případě je velmi vysoká, takže se na něj zcela spoléhám a nepoužívám žádné další filtrovací metody. Filtrujete-li svůj příchozí e-mail a nedosahujete dostatečně dobrých výsledků, můžete zkusit podobný postup. A nemusíte uvedené řešení přesně kopírovat, neboť silnou antispamovou zbraní je různost, takže zvolíte-li vlastní cestu, může být o to účinnější.

Další části seriálu:

Autor: Milan Zamazal, 08. 09. 2004, 00:00
Sekce Aktuálně, Komentářů: 2
Průměrné hodnocení: 0,07

o Poslat e-mailem
o Tisk článku
o Uložit do profilu


 Přispějte nám




Líbil se Vám tento článek? Můžete ho ocenit zavoláním na tel. číslo 906 460 134.
Cena hovoru za 1 minutu je 46 Kč.





 Hodnocení článku




Článek hodnotím jako:  [1] výborný   [2] dobrý   [3] průměr   [4] špatný   [5] hrůza  





 Komentáře




--

Milan Zamazal,
Deprecated: Function ereg_replace() is deprecated in /home/www.linuxzone.cz/modules/detail_clanku-komentare.phtml on line 198
08. 09. 2004 11:40
Re: poradi aplikace












--

Eagle,
Deprecated: Function ereg_replace() is deprecated in /home/www.linuxzone.cz/modules/detail_clanku-komentare.phtml on line 198
08. 09. 2004 11:15
poradi aplikace















PŘIDAT KOMENTÁŘ ZOBRAZ VŠE >>










2002 © Impossible, s.r.o.   >> Kontaktujte redakci >> Právní upozornění >> Reklama