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:

“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.

Leave a Reply

Your email address will not be published. Required fields are marked *