Még a nyáron láttam egy spamszűrő szolgáltatásról szóló előadást, és annyira nem volt meggyőző, hogy elhatároztam, csinálok egy annál sokkal jobbat.

Az eredményt feltettem a slideshare-re is, íme:

Hogy itt is meglegyen :

Streaming and recording video

To stream video with luvcview (plenty of options to experiment with):

luvcview -f yuv -s 320×240 -d /dev/video0

Open up the camera’s video stream in MPlayer:

mplayer -tv driver=v4l2:device=/dev/video0 tv://

Open in VLC:

vlc v4l2:///dev/video0

To make a recording I use ffmpeg… a ‘swiss army knife’ of video hackery on Linux:

ffmpeg -f oss -i /dev/dsp -f video4linux2 -s 640×480 -i /dev/video0 output.mpg

*Note: the netbook’s internal microphone is ‘/dev/dsp’

Save and open output.mpg in MPlayer or VLC. The quality of the video is rather low. When ffmpeg is running it displays the quality of the capture as q=[value] with value being a scale between 1 (best) to 31 (worst).

Some options that can quickly be modified to improve video capture are:

* increase bitrate… ‘-b’ option
* decrease frame rate… ‘-r’ option
* decrease frame size… ‘-s’ option

The -qscale option is useful. It allows setting a constant quality value with a variable bitrate. Running the previous command with a few modifications produces a decent output:

ffmpeg -f oss -i /dev/dsp -f video4linux2 -qscale 1 -r 24 -s 320×240 -i /dev/video0 output2.mpg

Now that the camera is up and working it is ready and well-suited for tasks such as video chatting and VOIP using Pidgin, Ekiga, Skype, etc.

Az idei ITBN-en előadóként (is) vettem részt. Íme a video:

A PDF anyag pedig innen tölthető le.

A HUP egyik blogjában láttam, és rögtön meg is tetszett:

If you use Firefox, there’s a way to write cached files to RAM instead of the hard disk. This is not only faster, but will significantly reduce writes to the SSD while using the browser.
Instructions: Open Firefox -> Type about:config into the address bar -> Enter -> double-click browser.cache.disk.enable to set the value to False -> Right-Click anywhere -> New -> Integer -> Preference Name “disk.cache.memory.capacity” -> value memory size in KB. Enter 32768 for 32MB, 65536 for 64MB, 131072 for 128MB, etc. -> restart Firefox

Idén is megrendezik az SFD-t Szegeden. Több szekcióban majdnem 50 előadás ill. workshop várja az érdeklődőket. Regisztráció.

A “Raid5″ fantázianevű formáció Végső búcsú a megbízhatatlan SPAM szűrőktől! akciós cikkében olvastam érdekeseket a spamszűrő szolgáltatás(uk)ról.

Már az első mondat megdobogtatta a kicsi szívemet:

“Talán már azt is megtapasztalta, hogy az ingyenes spam szűrő rendszerek egyike sem véd megbízhatóan a kéretlen levelek ellen.”

Hasonló csúsztatásokkal találkoztunk már, és nyilván a Raid5 számára is világos a cél: ráhangolni az olvasót a Symantec Mail Security megvásárlására, ugyanis ez a cég az említett termékre építi a saját dobozát.

Azt is megtudjuk, hogy “a kéretlen leveleket késő akkor kiszűrni, amikor azokat a levelező szerverünk már letöltötte, kézbesítette! Hiszen így a kár nagy részét óhatatlanul elszenvedjük:

• felesleges terhelést és lassulást okozunk a levelezőszerveren,
• a vírusokat és kémprogramokat is átengedjük a vállalati kommunikációs rendszeren, egészen a végfelhasználók számítógépéig,
• minden kéretlen email annyi példányban tárolódik az asztali számítógépek karanténjaiban, ahány számítógépen a spam szűrő telepítve van,
• a gépek számával megszokszorozott többlet adattárolási és adattovábbítási költséget is állnunk kell.

Ezekben van igazság, azonban ezeket a számokat pl. a spam miatti költségek kalkulátoraiban hajlamosak eltúlozni a kereskedelmi megoldások szállítói, akik nyilván abban érdekeltek, hogy egy jó nagy összeg jöjjön ki a spam miatti károkra.

A múlt havi jó leveleim mérete ~29 MB volt, míg a spam mappa ~11 MB. Ha ehhez hozzáveszem a csapda email címre érkezett ~27 MB levelet (ami egy “normális” felhasználó esetén nincs), csak akkor lesz nagyobb a spamek összmérete. Ha a kéretlen leveleket az asztali PC-ken szűrjük, akkor a fenti kifogások (pl. többlet adattárolás) nem valódiak, hiszen manapság (több) száz GB-os diszkekkel érkeznek a PC-k(, ill. a felismert spamet nem kell a központi gépeken archiválni). Egy átlag felhasználónak ~7.5 év kell ahhoz, hogy 1 GB spamet kapjon, és még akkor is csak a merevlemez 1%-t foglalják el a kéretlen levelek. A spam okozta probléma máshol van.

Az valóban reális aggodalom, hogy ne engedjük a vírusokat, kémprogramokat a felhasználó gépéig. Azonban egy működőnek nevezhető levelező infrastruktúra már a szervereken biztosít vírusvédelmet, amit jól kiegészíthet a PC-ken futó, másik gyártó antivírus szoftvere.

“Egy olyan megoldást ajánlunk, melynek spam szűrő motorja már több mint százezer email postafiók spam és vírus védelmét látja el magyarországon.”

Fúúú, de jó! Bár az ilyen számok kapcsán mindig kissé olyan érzésem van, mint a Jézus keresztjéből származó fadarabokkal. Ha azokat mind összeraknánk, nem hogy egy kereszt, de Kolumbusz teljes flottája kitelne. Hasonlóan: az egyik termék ennyi millió postafiókot véd, a másik annyit. Még százezer itt, még százezer ott, és kiderül, hogy annyi email cím nincs is Magyarországon.

Még szerencse, hogy itt van nekünk a RAID 500 ANTISPAM+ANTIVIRUS SERVER, amely több mint 20 féle levélszemét-szűrési technológiát kombinál.

• több mint 97 százalékos találati arányt nyújt a spam levelek felismerésében, de ami még fontosabb:
• Kevesebb mint 1 : 1000000 alatti a hamis riasztások aránya. Azaz kevesebb mint egy a millióhoz azoknak az emailek-nek a száma, amelyek tévesen spam-nek minősítve a karanténba vagy törlésre kerülnek.
• A levélszemét-felismerés szabályai automatikusan, minden 5-10 percben frissülnek, nem igényelnek adminisztrálást, és biztosítják, hogy mindig az új fenyegetések elleni leghatékonyabb védelmet élvezze.
• A szűrés még azelőtt megtörténik, hogy a spam és vírus gyanús levelek elérnék a vállalati levelezőszervert.

Tehát arról van szó, hogy a RAID 500 fantázianevű dobozt leteszik a cégednél. A rendszergazdád ráirányítja az Internet felől érkező leveleket, az pedig a jó email-eket továbbadja az Exchange-nek (vagy amit használtok). Van azonban néhány apróság, ami mellett ne menjünk el szó nélkül.

Ahhoz képest, hogy a termék 20 féle technológiát kombinál, meglehetősen közepes (hogy ne a gyenge/karesz/… szavakat kelljen használnom) spam felismerést biztosít. Ez egy kissé távol van attól, hogy “ha örökre megszabadulna a kéretlen levelektől,”. Bár az is lehet, hogy ez csak egy költői merengés volt, hogy ‘az jó lenne, ha?’, de sajnos, mi sem tudjuk, hogyan. Úgy tűnik, hogy hiába az 5-10 percenkénti frissítés, ez sem elég egy 99% feletti spam felismeréshez. Ez alatt nem tartok megfelelőnek egyetlen antispam megoldást sem.

A rendkívül impozáns fals pozitív arány semmitmondó, és jó, ha a szokásos PR-cikkek adatainak megfelelően kezeljük. Egy bizonyos kereskedelmi termék hasonló adatokat reklámozott, de ehhez képest néhány jó levelet is spamként értékelt. Mondanom sem kell, meg se közelítette a gyakorlati érték a hirdetett 1:1000000-t.

Végül hiába történik meg a szűrés a vállalati levelezőszerver előtt, a spamek már lejöttek a cég bérelt vonalán. Ebben a tekintetben a ‘RAID 500′ nem jobb az asztali szűrőprogramoknál. De mondom, egy cég számára elsősorban nem a spamek letöltéséhez szükséges extra sávszélességigény okoz problémát.

Értékelés

Nem állítom, hogy a Symantec termékre épített RAID 500 nevű doboz teljességgel megbízhatatlan lenne, de azt igen, hogy az a brigád, akik a heurisztikus szűrőket egy kalapba teszik a statisztikai szűrőkkel, és kijelentik, hogy “A vállalati szférában az ingyenes termékek használata nem jelenthet megoldást.“, nos azok egyszerűen nem kompetensek a témában.

Több teszt eredményem alapján ki merem jelenteni, hogy egy jó statisztikai spamszűrő bármelyik kereskedelmi termékkel felveszi a versenyt teljesítmény és pontosság terén is. A Raid 500 akciós áránál sokkal kevesebb pénzből (legyen mondjuk a fele) egy olyan rendszert építek neked, ami lazán alázza az említett terméket.

A Virus Bulletin: a spamszűrők együtt jobbak, ill. a Hány licence kell neked? írások alapján felbuzdúlva végeztem egy gyors tesztet az MPP-vel ill. egy ‘open source’ spamszűrővel.

Hogy a teszt eredmények valóban összevethetőek legyenek, végül mégsem az MPP VMware appliance-ot használtam, mert abban rengeteg egyéb funkció is megtalálható (pl. karantén, archiválás, …), ami megnehezítené az összehasonlítást.

Ezért letöltöttem az MPP ver. 4.20.0, rc1, Tue Aug 25 13:39:17 EDT 2009 [Linux 2.6.12-1.1381_FC3 i686] verziójú linuxos verzióját, és azt használtam. Nem telepítettem viszont az mppmanager-t, mivel nem volt most szükségem a szolgáltatásaira, és a MySQL szervert sem használta az MPP.

A teszt környezet egy WMware-ben futtatott CentOS 5.4 volt, ami 768 MB RAM-mal gazdálkodhatott. A teszt során összesen 9.6k levelet küldtem a rendszerre 10 szálon (=SMTP kapcsolaton) át, kb. fele-fele arányban jó ill. spam leveleket.

A tesztnek két célja volt. Az első, bizonyítani azt, hogy az MPP esetében nem igaz az a tétel, hogy ha több szűrőmotort használunk, akkor a szűrőmotorok számával egyenes arányban csökkenne az áteresztőképesség, azaz pl. 10 szűrőmotor tizedakkora teljesítményt eredményez. A másik pedig az, hogy képet kapjak a Cloudmark teljesítményéről. Azt is szeretném már az elején megjegyezni, hogy a teszt nem tért ki az egyes spamszűrő megoldások pontosságára.

A leveleket – privacy rulez – minden esetben ssh tunnel-en keresztül küldtem a VMware-ben futó programoknak, és minden levelet – függetlenül attól, hogy spam vagy sem – a /dev/null-ba irányítottam.

Két fajta tesztet végeztem. A TESZT1 során közvetlenül a 127.0.0.1:10025/tcp-re (azaz a spamszűrőre) irányítottam a leveleket, amelyek utána a 127.0.0.1:10026/tcp-n futó postfix példányhoz kerültek, ami a /dev/null-ba írta mindet.

A TESZT2 során pedig a szokásos módon a postfix kapta meg a leveleket a 127.0.0.1:25/tcp-n, amelyeket átadott a spamszűrőnek, az pedig visszaadta a postfix-nek, végül ebben az esetben is a /dev/null volt a végállomás.

TESZT1 / MPP:

Két kört is mentem. Először a <scan_engines>cloudmark, clamav</scan_engines> beállítással. Ebben az esetben a teszt időtartama 08:41 perc volt (15:25:40 – 15:34:21). A második körben kihagytam a clamav-ot, és csak a cloudmark eredményére voltam kiváncsi: <scan_engines>cloudmark</scan_engines>. Ebben az esetben rövidebb ideig tartott a teszt: 08:20 percig (16:27:16 – 16:35:36).

TESZT2 / MPP:

Itt már csak a cloudmark-ra koncentráltam, és a 9.6k levél /dev/null-ba továbbításához 09:49 percre (16:05:28 – 16:15:17) volt szükség.

Fontosnak tartom megjegyezni, hogy az mppd.conf konfigurációjában a használt szűrőmotorok felsorolásán kívül semmit nem módosítottam. Az MPP alapesetben debug módban loggolt. Ha ezt lejjebb vettem volna, (valamennyivel) biztosan nőtt volna a teljesítmény.

Az mppd.conf.xml tekerése közben észrevettem, hogy csak 2 szálon dolgozta fel az MPP a leveleket (processing_threads=2). Ezért, ha már itt voltam, ezt felemeltem 10-re, ill. csak a hibákat naplózta az MPP (logging=ERROR). A TESZT2 feladatot ebben az esetben tehát 08:26 perc (22:27:44 – 22:36:10) alatt végezte el az MPP.

A kihívó

Az álruhás versenyző pedig a clapf legutolsó (0.4.3.1) verziója volt az alábbi konfiggal, ill. fordítási paraméretekkel:

clapf_header_field=X-Clapf-spamicity:
clapf_spam_header_field=X-Clapf-spamicity: Yes
group_type=0
hostid=av-engine.localhost
locale=
mysqlsocket=/tmp/mysql.sock
mysqluser=clapf
mysqlpwd=*********
mysqldb=clapf
mysql_connect_timeout=2
penalize_embed_images=1
penalize_images=1
penalize_octet_stream=1
possible_spam_limit=0.8000
possible_spam_subject_prefix=[spam???]
quarantine_dir=/var/lib/clapf/quarantine
spam_overall_limit=0.92
spaminess_oblivion_limit=1.01
store_metadata=0
store_only_spam=0
training_mode=0
update_tokens=0
use_antispam=1
verbosity=1

./configure --localstatedir=/var \
--with-userdb=mysql \
--enable-rbl \
--enable-policy \
--enable-whitelist \
--with-tokendb=mysql \
--enable-static-build \
--with-store=fs \
--enable-lmtp

A clapf nem használta a clamd-t, nem frissítette a tokeneket, és minden adatot MySQL 5.4.3-beta tárolt.

TESZT1 / clapf:

08:02 perc (15:54:00 – 16:02:02) alatt végzett a ~9.6k levéllel.

TESZT2 / clapf:

07:37 percig (16:16:58 – 16:24:35) tartott, amíg elintézte a leveleket.

Az eredmények táblázatban

1. táblázat: Az MPP és a clapf levéláteresztő képessége [levél/sec]

*: processing_threads=2, logging=DEBUG
**: processing_threads=10, logging=ERROR

Következtetések/értékelés/magyarázkodás/….

Az eredmények megcáfolják azt a korábbi kijelentést, miszerint “az MPP-re váltáskor nem ritkán tapasztalunk 10-100x-os teljesítmény (áteresztő képesség) növekedést a korábbi opensource megoldásokhoz képest, a számos szűrőmotor ellenére.”

Noha a TESZT1-ben az MPP/Cloudmark kombó ~25%-ot rávert a clapf-ra, azonban relevánsabb a TESZT2 eredménye (mert a gyakorlatban sosem a spamszűrő fogadja a leveleket, hanem egy MTA), ahol a clapf egy szerényebb 10%-kal ért el nagyobb teljesítményt az MPP/Cloudmark duónál.

Tehát az előbbi állítás helyesen így hangzik: “Ha az MPP csak a Cloudmark szűrőmotort használja, akkor a teljesítménye nem marad el sokkal a clapf-tól”.

Figyelemre méltó, hogy amíg az MPP teljesítménye csökken, ha a levelet a postfix fogadja (és nem az MPP), addig a clapf esetében jobban jártunk. Utóbbinak az a magyarázata, hogy a clapf a TESZT1 esetén minden levél esetén fork()-olt egyet. Viszont a postfix, ha nő a terhelés, akkor ugyanazt az s/lmtp kapcsolatot a tartalomszűrő felé több levél esetében is fel tudja használni. Így amit veszítünk a 25/tcp-n hallgató postfix beiktatásával, azt bőven megnyerjük a clapf kevesebb fork()-olásával. Az MPP viszont nem használja a postfix lmtp connection cache-t – az MPP telepítője egészen konkrétan kikapcsolja.

A TESZT2 során egy érdekes jelenségre is felfigyeltem. A működés során a postfix fogadja a leveleket SMTP protokollon, elkezdi gyűjteni a queue-jába, majd érzés szerint tovább adja a tartalomszűrőnek. Az MPP esetében a postfix rövidebb idő átvette a leveleket az SMTP klienstől, viszont amikor elment az utolsó levél is a kliensről, azaz a postfix nem vett át több levelet a hálózatról, akkor a queue mérete ~4k levél volt. A clapf esetén tovább tartott, amíg a 9.6k levelet átvette, viszont a queue mérete nem ment 100 levél fölé, és összességében rövidebb idő alatt elért az utolsó levél is a /dev/null-ba.

A történeti hűség kedvéért meg kell jegyezni, hogy a load magasabb volt, amikor a clapf vizsgálta a leveleket, ill. amikor 10 MPP szál végezte a feldolgozást, akkor a queue mérete kb. akkora volt (n*10), mint a clapf esetében, viszont az MPP esetében is megnőtt a load.

A legfontosabb viszont még csak most jön. Az MPP tesztben mindössze egyetlen szűrőmotort használtam. Az MPP viszont használni képes még sok más szűrőmotort is, pl. Commtouch, mailshell, … és a jó öreg SpamAssassin démon változatát (spamd) is. Az admin felületen be lehet állítani, hogy milyen vírus-, ill. spamszűrő modulokat használjon az MPP, és azt is, hogy milyen sorrendben. A működés a következő. Ha az első spamszűrő modul spamként azonosítja a levelet, akkor készen vagyunk. Ha nem, akkor átadja a sorban következőnek. Ha az spamként azonosítja, akkor készen vagyunk, ha nem, akkor megyünk a következő spamszűrő motorra, és így tovább. Az antivírus szoftverek esetében hasonlóképpen jár el az MPP. Tehát az egyes motorok sorban egymás után következnek, ami a logfile-ból is látható, és nem párhuzamosan egyszerre kapják meg a levelet.

Ez azért lényeges, mert a korábbi, az MPP ‘majdnem olyan gyors, mint a clapf’, következtetésünk csak akkor igaz, ha csak gyors spamszűrő motorokat használunk, és ha a levelek zöme spam, amelyek nagy részét már az első helyen álló spamszűrő is felismeri.

Azonban a spam ill. a jó levelek aránya manapság kb. fele-fele, és ez azzal jár, hogy a levelek ~50%-a esetében az összes spamszűrőn végigmegy a levél. Ha az ingyenesen elérhető SpamAssassin is a spamszűrő motorok között van, akkor ez katasztrofális hatással lesz a teljesítményre, vö. az Általában amavis/maia/spamassassin kombinációkra gondolok open source alatt. állítással, ill. az fentebb említett ezekhez képest 10-100x teljesítmény növekedéssel.

A végső konklúzió

Az nem vitás, hogy az MPP magasan veri a SpamAssassin-t (hacsak nincs bekapcsolva az SpamAssassin az MPP-ben), de a végső konklúzió mégis az, amit Zdziarski is mond:

“they [commercial products] are certainly not more scalable than what’s freely available. Many open source projects have been deployed on systems with several hundred thousand users – there’s no justification to suggest that a commercial application could do any better”.

Azaz: a kereskedelmi spamszűrők biztosan nem skálázódnak jobban az open source termékeknél. Sok nyílt forrású termék szolgál ki több százezenyi felhasználóval rendelkező rendszereket – semmi sem támasztja alá, hogy egy kereskedelmi termék jobban teljesítene.

A SpamAssassin 3.2.0 – 3.2.5 verzióiban egy bug van, amely minden – amúgy legitim – 2010 01.01-jétől íródott levélhez egy durva a 3.6 pontot ad. Ez a spamek esetében ugyan nem probléma, de a jó levelek egy részét megharaphatja.

Ezért ajánlott azonnal upgrade-elni, vagy a local.cf fájlba az alábbi szabályt beleírni:

score FH_DATE_PAST_20XX 0

A spamblog PR cikkei között olvastam egy érdekes írást Virus Bulletin: a spamszűrők együtt jobbak címmel, amiben a egy érdekes elmélet szerepel:

“A Virus Bulletin kb. 200.000 valódi email felhasználásával 14 gyártó termékét tesztelte párhuzamosan, az egyes spamszűrők válogatták külön a levelezést levélszemétre és jó levelekre. [...] 4 megoldás is volt, ami egyetlen jó levelet sem jelölt meg, ugyanakkor a szűrési pontosságuk hagyott még kívánni valót maguk után. [...] ha elméletben megvalósítanának egy olyan szűrőt, ami mind a 14 tesztelt megoldást tartalmazza, de csak akkor jelöl meg egy levelet spamnek, ha legalább 5 termék szerint az, akkor egy lényegesen jobb szűrőt kaphatnának.

Az elméletben felállított többmotoros szűrő így 99.89%-os pontossággal azonosítaná a levélszemetet (ami minden termék eredményénél jobb), míg továbbra sem jelölne meg egyetlen jó levelet sem.”

A Virus Bulletin teóriája helytálló, de egy apróságról azért jó, ha tudunk. Ha minden levelet 14 szűrőn vezetünk át (vagy amíg legalább 5 szűrő nem sikít, hogy spam), az drasztikusan megnöveli a rendszer költségét.

A szükséges teljesítményigény (processzor, memória, i/o, …) (átlag) 14x-esére nő, vagy ha jobban tetszik, a rendszer áteresztőképessége az 1/14-édre csökken. És ha mindez nem lenne elég, akkor – mivel kereskedelmi termékekről van szó – 14 db termék licencét kell megvenni, frissíteni, stb.

Tehát az a termék, amely 14 kereskedelmi megoldást aggregál, az (átlagosan) 14x többe kerül, és a teljesítménye (átlagosan) 1/14-e annak, mintha csak 1 termékre bíztuk volna a spamszűrést. A hivatkozott PR-cikkben szó van az MPP termékről, amely 3-10 antispam megoldást képes kombinálni. Kész szerencse, hogy az MPP esetén legrosszabb esetben is csak egy 10-es szorzóval ill. osztóval kell számolni.

Azonban spamet szűrni nem csak kereskedelmi termékekkel lehet. Jonathan Zdziarski a Justifying Statistical Filtering (and Open Source Technology) című írásában megjegyzi, hogy “Well-written open-source filters have achieved rates of 99.5% to 99.9% and beyond with little effort.”, azaz szabad fordításban: a jól megírt nyílt forrású [spam]szűrők könnyedén elérik a 99.5-99.9%-os pontosságot, vagy még jobbat.

Ha tehát extrém pontosságra van szükség, akkor a) veszünk egy terméket, ami valójában akár 10-15 termék összegyúrva, vagy b) keresünk egy nyílt forrású, statisztikai szűrőt, ami egymaga képes az előbbi produkcióra.

A FLOSSzine magazin jóvoltából az október végi FSF.hu konferencia előadásai (közül több) kikerültek a http://videos.flosszine.org/ oldalra.

A zombi támadás ellen …. véd!

A te szűrőd tuti nem dolgozza fel a leveleket ~70 ms alatt.

Videók letöltése: ftp://ftp.fsn.hu/contrib/flosszine/szszk2k9_fsf.hu/