2010.01.07.
MPP vs. ‘open source’ spamszűrők
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
| TESZT1 | TESZT2 | |
| Cloudmark | 19.33* – 25.50** | 16.41* – 19.10** |
| clapf | 20.05 | 21.15 |
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:
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.
January 8th, 2010 at 3:08:13
Ezek szerint az MPP-nel a fals pozitivak szama (talan a legfontosabb tenyezo) az osszes hasznalt szuro kozul a legrosszabb (optimalis esetben). Worst case esetben meg a hasznalt szurok fals pozitivainak szamanak osszege.
Ha kulon-kulon hasznalt szurok eseten 1000 levelbol A szuro mondjuk 3 FP-ot ad, B szuro 10-et, C meg 15-ot, akkor ha mindet raeresztjuk, es A es B is csak olyan leveleknel hibazik, ahol C is, osszesen 15 FP-t kapunk. Ha mindegyik szuro mas-mas level eseten teveszt, akkor 28 lesz a fals pozitivok szama.
Gratulalok. Ennel egyszerubb lenne mindent a /dev/null-ba iranyitani, es meg gyorsabb is.
(A legjobb spamszuro tehat a /bin/true, kb. 50%-os hibaval dolgozik ugyan a fenti bemenet mellett, de sebessegben verhetetlen.)
January 8th, 2010 at 9:50:43
Igen, ez a levezetés helyesnek tűnik. Ha már több szűrőmotor, akkor (hangosan gondolkodom) a pontosság szempontjából jobb lenne az, ha a levelet minden modul egyszerre kapná meg, és azok eredményéből az MPP egy súlyozva kiszámolt aggregált értéket állítana elő. Viszont ez valóban nagyban megdobná a processzor, memória, i/o, … terhelést, tehát nem biztos, hogy ez járható út a gyakorlatban.
Egyébként a hivatkozott VB teszt azt mondta, hogy volt ugyan pár termék (nem derült ki, hogy melyekről van szó), amely nem vétett FP-t, csak éppen a spam felismerése sem volt túl rózsás. Ha ilyen termékeket válogatsz össze, akkor az FP marad nulla*, és a spam felismerés aránya szépen emelkedik.
A SpamAssassin-ról mindenesetre nem mondható el az FP mentesség. Amikor a könyvet írtam, kipróbáltam a Cloudmark Outlook pluginjét is. Néhány FP ott is előfordult.
Nem tudom, hogy az eladott termékekben jellemzően hány modul/plugin licencét veszik meg az ügyfelek a lehetséges felhozatalból (vagy hogy van-e egyáltalán ilyen választási lehetőség). De egy biztos: a kevesebb néha több.
*: definíció szerint nincs olyan termék (ok, most a /bin/true-t ne számoljuk), amely végig 0.00% FP-t produkál.
January 8th, 2010 at 11:28:08
SJ, köszönöm szépen a kimerítő tesztet! Szerintem mindent korrektül csináltál, ugyanakkor van még számos réteg, ami a való világban nagyon jól működik, de tesztelni gyakorlatilag lehetetlen.
Például, az MPP képes a zombi gépek csoportjait automatikusan kiszűrni, vagyis ha egy spamtámadás éri a levelezőrendszert, tipikusan 5-50 IP cím egyszerre támad le, akkor néhány levél után az összes ideiglenes blokkolásra kerül. Ha már láttatok üzemelni több milliós levélszűrő klasztereket, ott rendkívül látványos ez a dolog, hiszen az összes MPP megosztja egymás között az automatikus feketelistákat, és pár másodpercenként tilt ki IP cím csoportokat, látványosan csökkentve a terhelést és a spam arányt.
Továbbá, amit nyos ír, az a valóságban nem így működik,a több szűrőmotor éppen hogy az FP-k számának csökkenését eredményezi (amihez hozzájönnek az MPP automatikus fehérlistái is). A matematikai elméleted, teljesen helyes, de itt nem egyszerű halmazok uniójáról vagy metszetéről van szó. Az MPP lényege, hogy mindegyik szűrőmotor csak azokat a spameket jelöli meg, amiben 100%-ig biztos, így ha 3 független módszert használsz egyszerre, akkor jobb eredményt kapsz, mintha 1 szűrőmotort “járatnál csúcsra”. Biztosan tisztában vagy vele, hogy a szűrők nem binárisan működnek, nem azt mondják, hogy valami spam vagy sem, hanem egy valószínűséget rendelnek hozzá. Minél alacsonyabb határt húzol, várhatóan annál többet fog hibázni a szűrőd, igaz? Tehát 3 szűrő, nagyon magas határral használva várhatóan hasonlóan sok spamet jelöl meg (hiszen függetlenül működnek egymástól) és kevesebbet hibázik, mint ugyanez a 3 szűrő normál határral, vagy esetleg 1 szűrő alacsony határral. A cél az egyensúly megtalálása, ami a gyakorlatban nem is olyan nehéz.
Amivel viszont egyáltalán nem értek egyet, az az, hogy a kereskedelmi és az open source termékeket külön kell választani: egyik sem jobb mint a másik. Ahogy Hofi mondta: Tudsz úszni? Nem. És ha fizetünk érte?
Amiért az ügyfeleink minket választanak, az az, hogy jól teljesítő, jól működő, karbantartást nem igénylő rendszereket szállítunk immár 5 éve, és a legelső ügyfeleink is a mai napig ugyanúgy bíznak bennünk. Ez már egy üzleti kérdés, hogy komplett szolgáltatást, kész terméket hogyan lehet színvonalasan nyújtani. Nézzétek meg a Barracudát, akik – leegyszerűsítve – egy olcsó hardverre rakott SpamAssassint kezdtek el árulni, és amerikában piacvezető céggé nőttek. Ehhez képest az MPP sokkal szofisztikáltabb, és a Cloudmarkot is azért használják világszerte majd 1 milliárdan(!) mert jó technológiát kényelmesen, gyorsan és megbízhatóan szolgáltat. Elnézést az offért, a konklúzió: nincs opensource és kereskedelmi között egyértelműen jobb, ez attól függ, hogy kinek mi a megfelelő és a kényelmes. Szerencsések lehetünk, hogy léteznek ingyenes szoftverek, az élet más területén nem sok ingyenes alternatívánk van! 
January 8th, 2010 at 15:01:28
Ahogyan a végén rámutattál, nézőpont kérdése, hogy ki milyen szempontok alapján tekint “jónak” egy spamszűrőt. Az világosan látszik, hogy az ár/licence/terjesztés/stb. szempontoktól függetlenül vannak jó spamszűrők, és vannak a “futottak még” spamszűrők.
A teszt (eddig ki nem mondott) célja az is volt, hogy eloszlassa az “a kereskedelmi spamszűrő jobb, mint a nyílt forrású konkurensei” mítoszát.
Az MPP valóban sok szempontból felülmúlja a spamassassin (relatíve) szerény lehetőségeit (hacsak be nem kapcsoljuk az MPP-ben, hogy visszafogja a teljesítményt), de ne azt mondjuk, hogy ‘az MPP sokkal jobb (itt: sokkal gyorsabb és pontosabb) az open source megoldásoknál’, mert ez így ebben a formában egyszerűen nem igaz, hanem legyen korrekt az összevetés, konkrétan megnevezve, hogy minél gyorsabb és pontosabb. Mert olyan is van.
A teszt arra is rámutatott, hogy van azért a nyílt forrású táborban is pár olyan termék, amelyiknek nem kell szégyenkeznie az MPP-vel szemben, mert simán állja a versenyt. Ezért sem tartom tisztának, amikor azt olvasom, hogy az MPP ‘en block’ alázza az open source termékeket. Noha valóban jól hangzik, csak így nem egészen kóser.
Azért is fontos ez, mert amikor valaki spamszűrőt választ, nyilván megnéz pár weboldalt. Aztán ráakad egyre, ahol azt látja, hogy van egy kereskedelmi termék, amit “megveszel egy halom pénzért, de kapsz hozzá egy zsáknyi licencet, és ez egy tuti termék ám, ami nem igényel karbantartást, nagyon pontos, nagyon gyors. Ja igen, és az opensource termékekkel ne fáraszd magad, mert a miénk 100x gyorsabb, stb. …”
Van, aki azt mondja, hogy szakemberei ugyan vannak, de a költségkerete minimális. Ő nem fogja megbánni, ha az open source táborból választ.
De olyan is van, aki azt mondja, hogy nem akarok foglalkozni az egésszel, inkább kifizetek (ki tudja mennyi) pénzt egy kereskedelmi termék licenceire, hogy egy konyhakész megoldást kapjak, amit bekapcsolok, kattintok párat, aztán rá se kell néznem, ill. amiben van 1-2 prémium feature is, amitől könnyebb az életem.
Meg ahogy az általában lenni szokott, az ember felállít magában egy súlyozott szempont listát, és az alapján választja ki a számára legjobbat. Azonban a döntéshez a valósághoz hű információk kellenek, amelyek nem vezetik félre…
January 8th, 2010 at 22:17:57
Bevallom még talán soha senki nem jött hozzánk olyan kéréssel, hogy a spamszűrője túl lassú, adjunk gyorsabbat
A sebesség nem döntési szempont, a stabilitás, a terhelehtőség, a graceful degradation annál inkább. Olyan kéréssel nagyon sokan megkeresnek, hogy az X Y Z szűrő rossz, pontatlan, lefagy, kiakad, stb. de olyannal soha, hogy a 20% processzoridőt fogyaszt és ezt szeretné lecsökkenteni 2%-ra. Ráadásul talán többségben is vannak azok, akik más kereskedelmi megoldásokkal elégedetlenek, hiszen nyilván ők hajlandók egy másik kereskedelmi megoldásra váltani. Opensource rendszereket inkább akkor hagynak ott, amikor több feature-re van szükség, és egyszerűen nincs rá idő/ember ezt leprogramozni, beállítani, elkészíteni.
Az MPP-t már évek óta nem tartjuk elsősorban spamszűrőnek (még ha erre is fókuszál a jelenlegi honlapunk), a fejlesztőink már jó ideje az Email Stream Management nevű szolgáltatáscsomagra koncentrálnak, ami a különböző email alapú feldolgozó rendszerek gyűjtőnevét jelenti. A biztonság mellett az archiválás, az óriáscsatolmányok, szűrések, auditok, emailből RSS, ERP/CRM rendszerekkel való integráció (elsősorban SFDC), csatolmányok menedzselése, jelentések, tartalom alapú levélirányítás az olyan területek, amerre fejlődünk (Lásd: http://mpp.hu/images/mpp-felepites.png). A spamszűrést pedig rábízzuk a bevált és bizonyított partnereinkre, köztük a Cloudmarkra és Commtouchra, vagy bármely opensource megoldásra, ami így része lehet egy komplett levélfeldolgozó rendszernek.
January 8th, 2010 at 22:19:00
A linkbe becsúszott a zárójel, helyesen: http://mpp.hu/images/mpp-felepites.png
January 20th, 2010 at 22:57:18
Ez szep es jo, de nem reagaltal az eredeti feltevesre, miszerint az hazugsag, hogy az MPP nagysagrendekkel gyorsabb az opensource termekeknel.
A szakmai korrektseg kijar az egyes opensource termekeknek is. Foleg, hogy irod is, nagyreszt nem ugyanazt a piacot celozzak meg, igy nincs ertelme az allitasnak.
January 20th, 2010 at 23:57:01
A hozzászólásokból jól láthatod, hogy éppen arról beszéltünk, hogy nincs egyszerű “sebesség” tulajdonsága egy komplett szűrőrendszernek, senki nem állított, vagy hazudott erről semmit. Máskor mindössze az évek során gyűjtött tapasztalatainkat osztottam meg. Amikor azt írtam, hogy 10-100x-os áteresztő képesség növekedést tapasztaltunk számos helyen, ahol mi telepítettünk új szűrőrendszert (sebességről nem volt szó, nem autó ez). Értsd úgy, hogy 10 szerver helyett elég 1, vagy 1 levél/mp helyett 10 levél/mp-re nő ugyanazon hardver teljesítménye – a processzorterhelésből, levél darabszámból következtetve. Ez mindössze tapasztalat, nem általánosítás, ahogy korábban is leírtam, hogy nem lehet általánosságban beszélni sem az open sourceról, sem a zárt forráskódról, illetve SJ kolléga is alaposan körüljárta a kérdést – olvasd el a posztot és a hozzászólásokat!
January 26th, 2010 at 14:55:16
Bocsanat, akkor vmit biztosan felreertettem.
Igy visszaqolvasva egyebkent vadaskodasnak tunhetett, amit irtam, nem volt szandekomban:)
Arrol vitatkozni, hogy sebesseg, vagy teljesitmeny, szerintem felesleges, mivel nezopont kerdese, nalam aramlasi sebesseg, nalad teljesitmeny.
Csupan az ellen emeltem kifogast, hogy altalanossagban beszeltel az opensource-rol, ami ugy gondolom, nem fair, ill. nincs is ertelme. Persze ebben a postodban mar leirod te is, hogy ezt igy nem lehet.
A Janos altal toled idezett szoveg felreertesre adhat okot.
January 26th, 2010 at 15:27:50
Ezzel a cikkel meg akartam cáfolni – és azt hiszem, bőven sikerült is – azt a kicsit FUD-szagú állítást, miszerint ‘az opensource megoldások általában…’
Menet közben azonban kiderült, hogy a spamassassin-ról van szó valójában, ami mindjárt másként hangzik.