Valami normális spam-szűrő linux boxra

Spam, Adathalászat

hali mind,

2014 van, és a szerverünk kezdi megadni magát a spam-forgalom alatt. arról nem is szólva, hogy elég sok FN van, és időnként történik pár FP is. per pill sendmail+spamassassin+spamass-milter kombó fut a gépen.

a kérdés az, hogy létezik-e olyan megoldás, ami:
- lehetőleg nem perlben van (ekkora forgalomnál a perl interpreteres dolgok már nem elegendőek, az a tapasztalat),
- tud RBL-eket használni,
- betanítás nélkül is már normális, alapszintű szűrést tud végezni,
- esetleg közösség-alapú szűrőbázisa van, amit gyorsan és könnyen tud update-elni,
- sendmailben milterként használható (igen, sendmailt használunk, szeretünk szívni),
- lehet hozzá valami thunderbirdös (és esetleg outlookos) plugint találni, amivel a FP/FN visszajelzést könnyen, gombnyomással meg lehet oldani (rosszabb esetben forwardolással spéci címekre).

nem kell:
- cpanel integráció,
- fizetős megoldás (nem zárkóznánk el elvileg, de gyakorlatilag a domainek száma és maga a mail volumen megfizethetetlenül drága megoldással járna).

amiket eddig találtam:
- ASSP: ez is perl alapú, de sok helyen javasolják. viszont állítólag a konfigurálásába beleőszül az ember, és nem tudom, kb mekkora volumen az, amit a perl miatt kibír;
- dspam: c-ben írták, nagy teljesítményű, de gyakorlatilag nulla alapkészlettel jön, a nulláról kell betanítani, ami a jelenlegi mail volumenünk mellett a szakrális öngyilkosság egyik különleges, és módfelett fájdalamas megoldásának tűnik. ráadásul 2012 óta nem frissítették, ami nem jó jel;
- rspamd: ez alapvetően jónak tűnik, a core-ja C-ben van, de nem láttam, hogy túl sok helyen implementálták volna, nem teljesen világos a FP/FN kezelése, a lua-s részek teljesítményéről nincs adat, és a fene se tudja;
- postgrey: hátsajnaizé de nem postfixet használunk, emiatt meg nem fogunk áttérni;
- clapf: ez valami magyar cucc, de hiába mutat 2013-at a copyright notice, az utolsó twitteres hír 2010-es, totál döglöttnek tűnik, és az, hogy mysql-t használ a működéséhez, teljesítménybeli rémálmokat vetít előre.

ki mit próbált eddig? mik a tapasztalatok?

köszi,
a

  • 7520 megtekintés

( agostonl | 2014. 01. 17., p – 10:26 )

Hát (amivel nem kezdünk mondatot :) ).
Én nagyon meg vagyok elégedve az exim4-heavy+sa-exim+spamassassin combóval, sikerült összeheggelnem, hogy megy a globális és user szintű spam-szűrés is, nem zabál sokat.
Nálam a felhasználói adatok és a userprefs is mysql-ben van, de nincs komolyabb terhelése.
Mostanság nálunk is vannak bejövő szépségek, de rögtön az exim-nél elpukkannak.
Elsődlegesen az exim-et lőttem be - illetve úgy is alapbeállítás volt, hogy ellenőrzi, hogy létező-e a küldő címe, szervere, stb., ha nem eldobja.
Ezután megy be a spamassassin-nak elemzésre, ha nincs whitelist-ben.
Mivel voltak belső próbálkozások, a belső hálónk se trusted_network :), úgyhogy oda, vissza ellenőrzők jelenleg, mert vannak pop3 eléréseink. Ha sikerülne tisztán webes levelezésre áttérni (tárhely és tárhely, ja meg némi tárhely), sokkal szebb lenne az élet.
A spamassassin whitelist és blacklist már szöveges, de úgy olvastam, hogy az sa-compile parancs beforgat minden szabályt binárisba (ha nem jól értem, javítsatok ki!).
A whitelist tartalmazza a kiemelt domaineket és címeket küldő és fogadó oldalról egyaránt.

A szerverünk egy 2 magos IntelXeon 3Ghz-es 2 GB-al rakott gép.

"Értem én, hogy villanyos autó, de mi hajtja?"

( sj | 2014. 01. 20., h – 09:42 )

a clapf ugyeben szolnek. Ez egy statisztikai spamszuro, amit tanitani kell a megfelelo mukodeshez. A twitter egy kiserlet volt a changelog vezetesere, amit aztan hanyagoltam (persze Changelog van, csak mar nem a twitteren).

A legutolso release 2012-es lehet, ami azert nem frissult azota, mert nem talaltam olyan antispam technologiat, amivel tovabb lehetett volna javitani a pontossagat. Kb. hasonlo all a dspam-re is.

A kozeljovoben a clapf GUI-jat tervezem feltuningolni, hogy jobban hasonlitson a piler bootstrap alapu gui-jara. Meg van azert hatra par simitas, amig az kesz lesz.

A mysql kapcsan nem kell aggodni. Megfelelo tuningolassal, az innodb adatbazis megfelelo beallitasaval nem lesz vele gond. Meg jo par eves benchmarkjaim alapjan egy 2010 elotti desktop pc-vel napi millio leveleket lehet vele kategorizalni, szoval nem lesz vele teljesitmeny problema. Az SA-val osszevetve a kategorizalast kb. 60x gyorsabban vegzi kisebb eroforrasigeny mellett.

- lehetőleg nem perlben van: C-ben van
- tud RBL-eket használni: tud, akar URL BL-eket is.
- betanítás nélkül is már normális, alapszintű szűrést tud végezni: egy statisztikai szurot muszaj tanitani
- esetleg közösség-alapú szűrőbázisa van, amit gyorsan és könnyen tud update-elni: N/A
- sendmailben milterként használható: N/A
- lehet hozzá valami thunderbirdös (és esetleg outlookos) plugint találni, amivel a FP/FN visszajelzést könnyen, gombnyomással meg lehet oldani (rosszabb esetben forwardolással spéci címekre): speci cimre forwardolassal mukodik

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

huh, jó tudni, hogy akkor az még mindig megy.

azon nem gondolkoztál, hogy jó lenne valami közösségi alapú szűrést is csinálni? mert bár az igaz, hogy accountról accountra kicsit más eltérések lehetnek a spam és ham dolgában, viszont egy csomó mail egyértelműen mindenkinek spam, és jó eséllyel nem csak egy szerveren csapódik le ugyanúgy egy nagyobb spam roham.

így pedig, ha létezne valami mód arra, hogy egy közös adatbázist is használva a spam filter sokkal gyorsabban tanulná be a szabályokat, és az eléggé nagy plusz lenne a sysadminok szemében.

jol hangzo dolog a kozossegi alapu szures, de nem trivialis osszedobni egy ilyet.

Elso gondolatkent a spamsum projekt jut eszembe, ami minden levelhez egy checksum-ot keszit, es a commtouch zero protection mintajara a vilag minden pontjan (ahol ezt hasznaljak) lehetne ezeket a checksum-okat gyujteni, es az alapjan egy kb. real-time frissulo adatbazist fenntartani.

A commtouch-nak amugy "egyszeru" dolga van, mert minden szerver, ahol az o cuccuk fut, az egy szenzor is egyben, ami adatokat tovabbit a kozpontjuk fele.

De ez csak nagy meretben hatekony, amire ki tudja, mennyi eselye van egy kozossegi probalkozasnak, masreszt a nyiltsaga miatt nem trivialis ennek az adatbazisnak a tisztasagat fenntartani (pl. egy nyilt API eseten barmelyik spammer teleszorhatna fals rekordokkal, igy hasznalhatatlanna teve azt). Lehet ezekre is (valamilyen) megoldast talalni, de nem egyszeru.

De gondolkodjunk egyutt, hogy lehetne egy ilyet mondjuk hazai meretekben osszehozni...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

( zrubi v | 2014. 01. 20., h – 12:00 )

"(ekkora forgalomnál a perl interpreteres dolgok már nem elegendőek, az a tapasztalat)"

Mekkora az az ekkora forgalom?
- db levél/sec
- db levél/nap
- IP conncetion/sec

Betanítás nélkül szvsz egyik sem működik jól.

--
zrubi.hu

csak a bejövő leveleket nézve:
- átlagban 4 levél/perc, csúcsidőben 12 körül
- viszont 65M elutasított levél (sejtésem szerint ezt a rohamot a sendmail állja, ezek el sem jutnak a spamass-milterig, mert az alapból nem utasít vissza, csak flaggel).

kiderült, hogy a nagy terhelést nem a spamassassin maga okozta, hanem az, hogy az egyik ügyfelünk website-ját hagyta megtörni (régi joomla installáció, valami felesleges forum/feedback pluginnal), és ott beindult egy h@xx0r php script, ami spammelt, faxa.

úgyhogy per pill úgy néz ki, hogy a kisebb ellenállás útját választva marad a spamassassin. :)

12 level/perc komolytalan, arra teljesen jo az assp 1.x -es szeriaja.
mondjuk 65M level/(nap|ora|perc)-re még sosem teszteltem, ott mar valoszinuleg megfekszik :D)

a sendmail configban emlekeim szerint a RefuseLa sort nezd meg, ottan van megadva, mekkora load felett mondjon temporary rejectet.

( gee v | 2014. 01. 20., h – 12:24 )

spamassassin helyett spamd és spamc?
Spamc C-ben van megírva, és talán a spamd is, de ebben nem vagyok biztos.
Mindenesetre spamc+spamd jobb teljesítményt ad, mint a sima spamassassin.

csak a spamc van C-ben, de nem ez zavar sok vizet, mert az kb. csak atpasszolja a levelet a spamd-nek, majd olvassa a valaszt. Hanem a logic a spamd-ben van, ami viszont perl-ben van megirva.

De szerintem odaig a kerdezo is eljutott, hogy demonkent hasznalja az SA-t...

--
"A politikat, gazdasagot es a tobbi felsorolt faszsagot leszarom, amig engem nem erint (nem erint)" (bviktor)

( hokuszpk | 2014. 01. 20., h – 15:36 )

en assp -t hasznalok, nagy levelforgalomhoz a v2 illik, de erre a szerverre nem ajanlom, mert ugy kezdi, hogy kell neki 1GB memoria.
mondjuk az 1.x is eleg sokat levellel megkuzd, esetleg egy probat megerhet, eleg gyorsan vissza lehet allni az eredeti allapotra ha nem jon be.
konfiguralni webes megfejtessel lehet, mar az alap is eleg hatekony, ha meg tanitasz neki par spam/hammintat, akkor nagyon kiraly.

viszont hogy konstruktiv legyek, a postgrey helyett van a sendmailhoz holmi milter-greylist, ugyan sosem hasznaltam, de amig megtalalod a vegleges megfejtest, addig is talan segithet csokkenteni az SA terheleset.

( pdx | 2014. 01. 20., h – 15:59 )

köszi a konstruktív hozzászólásokat! :)

egyelőre maradunk a spamassassinnál, mert az így vagy úgy, de működik, és a nagy terhelést az okozta, hogy egy ügyfelünk xaros websiteja hagyta magát megtörni, így ment egy spammer php script belőle, az okozta a szokásosnál sokkal, de sokkal nagyobb email volument. a problémát elhárítottuk, a felelősöknek felmondtunk, és óriási költségvetéssel, láma zutolsó pillanatban... ja bocs, az egy másik film. :)

viszont ha már spamassassin, még egy találós kérdés: van-e valami rendszer, amin keresztül egyszerűbben taníthatóvá válna? valami, ami tényleg olyan, hogy thunderbirdös pluginon keresztül használható, és egyszerű FP/FN megjelölésre lenne jó.

mivel nem jött azóta válasz, kicsit beleástam magam a témába:

a trükk az sa-learn parancs, amivel lehet tanítani a spamassassin-t. viszont az alapjáraton arra készült, hogy teljes mailboxokat nyálazzon át, ami nem feltétlen működik jól a mindennapos használatban. nekem valami olyan interface kellett, amivel thunderbird-ön keresztül egy gomb megnyomásával FP vagy FN jelentést lehet tenni a spamassassin számára.

a spamassassin-nél van is egy erre dedikált plugin, az viszont közvetlenül a spamd-vel akarná felvenni a kapcsolatot, én viszont nem vagyok annyira harakiris kedvemben, hogy csak úgy megnyissam a spamd portját a világ számára. szóval ez az opció kiesett.

maradt az sa-learn, meg az önálló tanulás engedélyezése (mindössze a /var/lib/spamassassin könyvtárnál kellett sa-milt:sa-milt-re beállítanom a jogokat).

találtam egy thunderbird plugint, ahol meg lehet adni, hogy milyen URL-en jelentsen FN és FP maileket. aztán írtam egy kis rendszert, ami végpontként használható a pluginhoz, és ami egy másik komponensen keresztül pedig meghívja az sa-learn-t a megfelelő üzenetekkel.

a webes rész egy db-be pakolja be a bejövő spam/ham jelentéseket.

a CLI rész (amit érdemes cronból, óránként hívni, sa-milt userként) pedig lehívja a tárolt üziket, bedobja megfelelő megjelöléssel az sa-learn-nek, és aztán törli a queue-t.

akit érdekel, itt a cucc: http://www.pdx.hu/devel/sa-trainer.zip

a forrásban a kommentekben ott van minden lényeges.

( rts | 2014. 01. 20., h – 16:08 )

Esetben a fent már említett exim4-heavy + spamd kombónak nincs alternatívája. Btw exim4 szűr tetszőleges RBL alapján, smtp connect és helo után rögtön. ezért nem kell eltolni a spamdnek a mailt.

( PtY | 2014. 01. 22., sze – 18:44 )

Sendmail alapból kuka, postfix tud szépen RBL-t kezelni, plusz postgrey, és már 90%-kal csökkentetted is a bejövő forgalmad. A maradékon mehet az assassin - mint eddig.
--
PtY - www.onlinedemo.hu