Spamszűrőre javaslat

Spam, Adathalászat

Szeretnék javaslatot kérni Tőletek. Van a cégünknél több levelező szerver. Az e-mail-ek egy linux-os mail gateway-re érkeznek meg, és onnét mennek ki, ami elvégzi a spam és vírusszűrést. Domain-től függően, van ahol csak jelöli a spam-et a subject-ban és továbbítja, de van olyan domain, ahol eldobja.

A napi forgalmunk 2-300 ezer e-mail. Amit eddig használtunk: Virusbuster meg voltunk vele elégedve, de a cég megszűnt, átvette Sophos. Sophos egy fokkal gyengébb volt, de a licensz politikájuk olyan, hogy nem tudjuk megfizetni.

Kaspersky Security 8.0 for Linux Mail Server. Nem lehetséges a tanítása. A support-tól azt a választ kaptuk, hogy mivel sokan használják pár napon belül úgy is észreveszi a spam-et.

Itt tartunk most. A kérdésem, hogy másnak F-Secure, Symantec van hasonló szoftvere? Esetleg valami open source?

Az amavis spamassassin sajnos nem játszik, mert próbáltuk és nagyon nagy volt az erőforrás igénye.

  • 14036 megtekintés

( Proci85 v | 2014. 02. 04., k – 10:53 )

Az amavisnak tényleg nagy az erőforrás igénye, de simán a spamassassinnak is? Mint tudjuk, önállóan is alkamazható, amavis nélkül.
Lehet, hogy érdemes volna egy kört futni így is. Az előnyeit ismerjük, több topikban is tárgyaltuk, kész megoldásokkal.

( tompos v | 2014. 02. 04., k – 10:55 )

clapf

A Kaspersky, Trendpoint is tarsai megkozelitese sem rossz, ha megtehetiotek, akkor igazabol a ketto modszernek kell kiegeszitenie egymast.

( trey | 2014. 02. 04., k – 10:59 )

Opció lehet még a Barracuda, akár hardver appliance-ként, akár virtuális gépként is, vagy ha még kevesebbet akarsz vele foglalkozni, akkor bérelheted is felhőben futó szolgáltatásként. Attól függ, hogy mennyit akarsz vele szívni.

--
trey @ gépház

( hokuszpk | 2014. 02. 04., k – 12:08 )

"Az amavis spamassassin sajnos nem játszik, mert próbáltuk és nagyon nagy volt az erőforrás igénye."

mekkora eroforraskeretbe kellene beferni ?

Hogy nekik mekkorába kellene, azt nem tudom, de...
Egyszer próbáltam alapbeállításokkal, mert kíváncsi voltam, hogy a freemail spamszűrője rossz vagy a sok szemét tényleg meg tudja kerülni a szűrőket és azt láttam, hogy valami iszonyat lassú. :(
(ha jól rémlik, 5-10mp/levél volt a sebessége és nem egy őskori gépen)

( PtY | 2014. 02. 04., k – 12:52 )

"Az amavis spamassassin sajnos nem játszik, mert próbáltuk és nagyon nagy volt az erőforrás igénye."

Ha nem használsz RBL-t, és a világ összes spam-jét tartalomellenőrizni akarod, akkor nyilván...
--
PtY - www.onlinedemo.hu

( zxyxy | 2014. 02. 04., k – 12:56 )

Bármit is választasz en egy graylistet is tennék, elég sokmindent kiszűr

csak rbl alapjan nem utasitok el semmit. anno mindig panaszkodtak az upcrol jovo illetve ize, az rbl miatt meg nem jovo levelek miatt.
osztok ra pontot. igy nincs panaszkodas. a lancban kesobb jovo whitelist valamelyest kompenzalja, ha valami miatt egy szolgaltato eppen sarokban terdepel.

greylist hasznalhato, bar nemelyik 'azonnal ujrakuldom' tipusu mailszerver miatt abbol is volt gondom, nem jott meg a varva-vart level, mert a minimalidon belul kuldte ujra. a masik veglet meg az, ami a triplet lejarta utan kuldi ujra. ha kulon nem kerik, inkabb nem kapcsolom be.

viszont az assp remek egyeb lehetosegeket ad, ezert idonkent visszajonnek az egyeb okbol elvandorolt ugyfelek, akik megszoktak, hogy nemnagyon kapnak spamot :D)

Ezt hívják exepsön hendlingnek :)
UPC, freemail, gmail IP címek alapján -> fehérlista az RBL elé -> örülünkvincent

User idióta, minden elképzelhetetlen helyre odabiggyeszti az email címét, nem beszélve a generált címekről, ill a postmaster/info/domain@domain.tld jellegű címekről, ahová default ömlik a spam ha nem akarsz RBL-t és amellett kivétellistát kezelni, akkor legyen sok pénzed, sok erőforrásod, nagy sávszélességed, és sok-sok türelmed, ha egy falspozitívot ki kell halászni a karanténból.
--
PtY - www.onlinedemo.hu

"UPC, freemail, gmail IP címek alapján -> fehérlista az RBL elé -> örülünkvincent"

az assp ezt is tudja, gyarilag eloregyartott listaja van ilyen aol/gmail/hotmail/amazon/facebook/yahoo bejegyzesekkel, de vagyok annyira lusta, hogy nincs kedvem (ujra) hozzaszoktatni a nepeket, hogy naponta zaklathatnak az eppen feltunt es divatbajott szolgaltatas feherlistazasanak igenyevel :D)
rbl nelkul sem veszes az eroforrasigenye, igaz csak 2500 mailbox korul van a legnagyobb levelezoszerver, amin futtatom.
false pozitivot meg mar nem is emlexem, mikor halasztam utoljara.

Nem kell nagyon előregyártani a listát, jobb helyeken már használnak spf rekordot, és le lehet kérdezni dns-ből az összes tartományt. Google, Microsoft (outlook.com), meg aki nem lusta, beállítja magának, és könnyebben karbantartható a lista.
Van azonban, akik tojnak erre, azokat manuálisan kell karban tartani.
--
PtY - www.onlinedemo.hu

Milyen filterre gondolsz?
Az usernek két céges fiókja van - de két külön cég két külön mail serverén. Tehát "A" serveren a fióknál semmilyen filter nincs, hanem az van beállítva, hogy feltétel nélkül toljon minden levelet a másik cégnél lévő másik fiókba. Ott van filter, ami címzett alapján (is) szűr, meg van alias is, így onnan mindkét címmel tud küldeni - de oda a továbbított levél nem akar beesni.
Jön a levél, az "A" szerver ellenőriz, minden szép és jó, tehát átveszi a levelet - majd a beállítot egyetlen szabály alapján azonnal tovább is küldené azt a másik fiókba, de az ugye már másik MTA. Mivel ekkor a levélen semmi változtatás nem történik, marad az eredeti feladó, csak a címzett változik (protokoll szinten), hogy esen be a levél a másik szerveren a másik fiókba. Viszont amikor a másik szerver ellenőrzi az eredeti feladót, akkor pillanatok alatt beidegesedik, hogy miért onnan jön a levél, ha egyszer világosan le van írva, hogy nem onnan kéne jönnie. Tehát eldobódik.
Persze értem én: a 2. szerveren tegyem fehér listára az elsőt.

Tök nem érted.

A levél küldője nem az, aki a From mezőben van, hanem az, aki a Return-Path-ban. A levelet ténylegesen az küldi, nem az, aki a from-ban van. Az NDR-t is az kapja.
Namármost, ha ez alapján a filter a From mezőhöz tartozó spf alapján hibásnak nyilvánít bármit is, akkor a filter szar!
Azaz: az a szar, aki egy átirányított levélre azt állítja, hogy szar.
--
PtY - www.onlinedemo.hu

A filter a retun-path/envelope-from domainjának kérdezi le DNS-ből az SPV vagy TXT rekordot, ha az link (mint pl. a google-nál), akkor azokat szépen kibontogatja, és megnézi, hogy a kapott IP tartományokból jön-e az az MTA, ami a levelet küldte. Ha igen vagy nem, akkor eszerint pontoz.

A levelezőprogramnak ehhez már sok köze nincsen.

Pl. egy levlistára ha írok, akkor visszakapom a levelem, amit én adtam fel - én is vagyok a feladóban -, de az MTA az a levlista szerver, mégsem osztok a levélre spf sértés miatt pontokat.
--
PtY - www.onlinedemo.hu

A válasz abban a postban van, amire reagáltál :)

1. A forwarder MTA semmit sem cserél ki.
2. Van egy HELO/EHLO, amit egy 'mail from:' követ. Ez az eredeti címzett, vagyis az átirányító emberke email címe per def.
3. Ennek van egy @ utáni része, amihez tartozik egy zóna, abban van SPF rekord (vagy TXT, ami evvel egyenértékű), vagy nincs.
4. Ha van, akkor a fogadó MTA kibontja, és kap egy/több IP/CIDR értéket.
5. Ha ebben szerepel a forwarder MTA IP címe, akkor nem adunk neki büntit, ha nem, akkor bünti van.

Tök egyszerű az algoritmus, fentebb ugyanezt írtam le. A küldő MTA mindig az, aki közvetlenül kapcsolódik a fogadó MTA-ra, és irreleváns, hogy az eredeti MTA mi volt.
Az más kérdés már, hogy többszörös átirányítás esetén a közbülső MTA-kat is lehet validáltatni a spamassassinnal, és ha RBL-en szerepel, akkor felpontozni jól - de ennek az SPF-hez nincs köze.

Egyes filterek még azt is nézik, hogy a láncban szereplő MTA-k a From mezőben lévő címnek SPF szerint legális MTA-jai-e, és ha igen, akkor nem pontoz fel. Azt hiszem ez a soft/hard típusú SPF pontozást befolyásolja, meg kell nézni a vonatkozó RFC-t (4408).
--
PtY - www.onlinedemo.hu

2. Van egy HELO/EHLO, amit egy 'mail from:' követ. Ez az eredeti címzett, vagyis az átirányító emberke email címe per def.

A 'mail from:' az eredeti levélben az eredeti feladó, ami nem a címzett (azaz az átirányító). Ha a forwarder semmit nem cserél (én is pont így gondoltam a dolgot), akkor ez marad is az eredeti feladó, aki tehát nem a címzett, ergó az ehhez a mailcímhez tartozó domain SPF rekordja kurvára nem fog matchelni a forwarder MTA IP címére, hiszen neki semmi köze a levél eredeti feladójához.

Szóval ezért nem értettem már elsőre se.

A levél küldője szerintem meg az, aki a protokol szerint küldő, azaz aki a "mail from:" után áll a protokollban - szóval erről ezen a ponton ne vitatkozzunk.
Egyébként az SPF Wiki - http://en.wikipedia.org/wiki/Sender_Policy_Framework#FAIL_and_forwarding - viszonylag hamar, az 1.2 pontban leírja a jelenséget, tehát nem egyedül én futok bele. Az alap probléma az, hogy az SPF rekord a használata során elvárja, hogy vagy minden MTA kezelje az SPF rekordot, vagy egyik se. Ez viszont a heterogén MTA-k miatt még hosszú-hosszú ideig csak vágyálom marad. Mert szép az, meg jó az, hogy az első MTA a továbbításkor vágja bele a Return-Path-ba a megfelelő értéket és miegymás, de ha az egy "buta" MTA, ami képes ugyan a továbbításra, de ilyesmit nem csinál, akkor ezen a ponton a hajamra kenhetem a dolgot. Illetve korrigálhatok ott, hogy white-listre teszem azt az MTA-t. Ezen a ponton a DKIM jobb, mert nem érzékeny arra, hogy a továbbítás során esetleg annyira buta MTA is jelen van a láncban, hogy már az EHLO-t sem érti.

"A levél küldője szerintem meg az, aki a protokol szerint küldő, azaz aki a "mail from:" után áll a protokollban"
Igen, és ez kerül a return-path-ba, tehát egyről beszélünk.

Értem, amit a wiki ír, és a jelenség létezik is, csak erre oda lehet figyelni, és úgy csinálni az átirányítást, hogy kompatibilis legyen.
Irányíts át egy levelet google-ról, és jó lesz. Levlistaszerverek is jól csinálják (mailman biztosan).
--
PtY - www.onlinedemo.hu

Mit érek azzal, ha ellenőrzöm amit mondtál, azaz hogy a google esetén működik, ha egyébként:
- a feladó külföldi cég, ott a mail serverre nincs ráhatásom
- a forwardot végző mail server a partner cég MTA-ja, saját rendszergazdával - ráhatásom erre sincs
- az utolsó mail szerver az, amellyel bármit is tudok csinálni, de mire ide ér a levél, addigra a whitelist-en kívül nem nagyon van lehetőségem
Ezért mondom, hogy a DKIM jobb: ott az első mail szervert jól kell bekonfigurálni, hogy működjön, utána meg a többi konfigjától nem függ az, hogy az utolsó MTA ideges lesz-e vagy sem.

"Mit érek azzal, ha ellenőrzöm amit mondtál, azaz hogy a google esetén működik"
Sokat nem érsz vele, csak Számodra is egyértelművé válik, hogy átirányítani lehet értelmesen is, hogy a sender policy ne sérüljön.
Tehát igen, az átirányítás okozhat problémát, de van rá mód, hogy ne okozzon - csak használni/beállítani kéne ott, ahol erre lehetőség van.
--
PtY - www.onlinedemo.hu

Na.... :D

Azzal kezdtem, hogy "csak SPF ne legyen" és a végére megírtad, hogy mi a baj vele...
Te beállíthatod a DNS-edbe, de valószínű, hogy ha olyan e-mail-el találkozol, ami továbbított (ÉS NINCS SRS a továbbítónál, ami kb 99%), akkor az SPF ellenőrzése nem sok jóval (plusszal) jár...

Ugyanis ha az SPF azt mondja, hogy hibás a levél, akkor lehet hogy csak SRS nélkül továbbított levélről van szó...
Ha pedig az SPF azt mondja, hogy ok a levél, akkor is csak azt tudjuk, hogy megfelelő helyről jött... DE AZT NEM, HOGY SPAM KÜLDŐ HELYRŐL-E!!!!!

http://www.openspf.org/SRS

--
Debian Linux rulez... :D

Jól van na, nem mindenki tud magyarul. :)
Persze, hogy azt nem tudjuk kiszűrni. Csak annyit tudunk, hogy nem hamisított a feladó. Ha fw-olt levél, és nincs átírva a return-path, de az útvonalban szerepel az spf szerint hiteles szerver, ettől még lehet softfail - ez tény.
--
PtY - www.onlinedemo.hu

az spf nem egeszen a spam ellen lett kitalalva, hanem a domainhamisitas ellen. Arra kb. jo, de esetenkent eltori a dolgot. Ha mar ilyen feature kell, akkor a dkim-et jobbnak mondjak, az azokat az eseteket is helyesen kezeli, amelyeknel elbukik az spf.

Hogy pedig mennyire nem igazan ved a spamek ellen, arrol csak annyit, hogy elsokent a spammerek kezdtek el spf rekordokat publikalni.

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

+1

Pont a napokban _újítottam_ meg vírusirtó-előfizetést (tehát már ismert a cég, de idén először nem azt a kártyát használtam, amit eddig náluk mindig), és napokig visszatartották a licenckulcs kiadását, pedig a kártyámról már lekerült az összeg. Ezalatt a pár nap alatt bekérték a bankszámlakivonatot, egy igazolványmásolatot és a POS auth kódot.

Nekem pl. UPC-m van, és simán kilátok a 25-ös portra. Igaz, ehhez egyszer be kellett jelentkeznem egy webes felületen, és kattintani egyet. De olyan helyet aztán pláne nem sokat ismerek, ahol a 465-ös portot szűrnék.

Az egyetlen reális indok az lehet, ha annyira gyatra az igazi mail szerver drótja, hogy a plusz be-ki átküldése nagyobb leveleknek nem igazán kívánatos. De erre az a megoldás, hogy nem egy gyatra drót végére kell rakni a fontos mail szervert.

ez nem gyenge drot, a problema az, hogy a lentebb emlitett szerver 2500 felhasznalojahoz nem tudok mindegyikhez szemelyesen kimenni beallitani a mailklienst. -- mert akkor lenne mindenfele big 'S' ize, ami mint az utobbi idoben kiderult, nemsokat er, de legalabb nem szurik. --
telefonba meg neha az smtp auth pipa bepippantasanak elmagyarazasa is nehezkes, ( idonkent az rgnek kinevezett helyi ero sem erti ) mert az egyik outlook2k3-at hasznal, a masik outlook expresst, a harmadik meg outlook 2k10 -et. de amikor rakerdezek, akkor ez mind 'outlook'.
// "sajatgep.
- igen az enyem !" //

amig meg nincs beallitva a kliens, addig nemigazan tudok nekik szep kepekkel illusztralt mailt vagy linket kuldeni emailben :D)

az assp tud spf-et is ellenorizni, hasznalom is, egy ujabb +- pontszam a spamscoreban.
azt a faturet még egyelore nem lattam sehol, hogy az spf check egyben karbantartja valamilyen uton-modon az rbl kivetellistat. biztos van ilyen is, de nekem manualisan tovabbra sincs kedvem erre idot/energiat pazarolni, foleg azert, mert a filter evek ota igy is eleg hatekonyan szu:r.

( freeoli v | 2014. 02. 04., k – 13:17 )

ASSP-t használjuk a V1-et, hamarosan V2-re váltok, csak hogy nagyobb legyen a számláló de indoka még nincs, mert nem kell a többszálú szűrés. Remekül testre szabható, egyszerű telepíteni és az alap config is egész jó, de állítani kell rajta, nem is keveset. Főleg, hogy alapból a magyart a klasszikus kínai/orosz spam gyanús nyelvek közé sorolja.

A vas egy virtualizált kiszolgáló, 2 core2 kategóriájú mag és 1Gb ram társaságában.

Ebből 1 évig ki volt kapcsolva!

ASSP Proxy Uptime: 1 day 2 hours 5 mins 26 secs 1020 days 2 hours 12 mins
Messages Processed: 1901 (1748.7 per day) 414869 (406.7 per day)
Non-Local Mail Blocked: 79.6% 85.1%
CPU Usage: 1.32% (16.01% avg) 5.63% avg
Concurrent SMTP Sessions: 0 (23 high / 64 max) 64 high

Message OK: 61 31544
Whitelisted: 274 23996
Local: 0 0
Passing without Processing: 52 6345
Spamlover Spams Passed: 0 0
Bayesian Spams: 0 10
Blacklisted Domains: 7 4650
Invalid HELO: 0 70
Missing MX and A Record: 0 0
Missing PTR Record: 0 0
Invalid PTR Record: 0 0
Collect/Trap Messages: 0 0
Bad Attachments: 0 0
Viruses Detected: 1 215
Black/Bomb Regex: 0 0
IPs blocked: 0 0
IPs blocked (strict): 0 0
CountryCode blocked: 0 0
Message Scoring: 0 202
Invalid Local Sender: 0 0
Invalid Internal Mail: 0 0
RBL Failures: 147 11563
URIBL Failures: 7 3035
Max Errors Exceeded: 0 849
MSGverify : 0 488
Local Frequency: 0 0
Early (Pre)Header: 0 197
Delayed/Greylisted: 1352 331530
Empty Recipient: 0 75

( andrej_ v | 2014. 02. 04., k – 21:29 )

Ennyi mailnél eleve úgy indulnék neki a dolgoknak, hogy két VPS-en szűrnék, ha nagyobb a cluster akkor két külön vasra téve. A konfigot egy helybe replikált SQL adatbázisból szedném és az írások mennének a masterre (támogat több SQL szerveres funkciót az SA és az exim is emlékeim szerint). Feldobnám szürkelistával, ez akár központilag is mehet a master SQL mellett is (létezik memcached alapú szürkelista is már).

( janoszen v | 2014. 02. 07., p – 00:59 )

Figyelem, nem dobozos szoftver. Ha nem erdekel a sajat epitesu megoldas, akkor ne is olvass tovabb.

En atalltam spamszures tekinteteben egy olyan megoldasra, hogy a bejovo spameket analizalom es a benne szereplo domain neveket indokolt esetben egy DNS szerverbe felveszem. Ez alapjan jelenleg az Eximem envelope sender domainre, kuldo szerver reversere es HELO nevre illesztve tesztel. Ha rajta van valamenylik, nem jon be a level. Most jon a kovetkezo lepes, ami kereteben a komplett MIME fat elemezni akarom es abbol a tartalomban levo domaineket is kiszedni es ellenorizni.

Ez a megoldas nekem tobb felhasznalo osszegzett tapasztalata szerint kb 95%-kal vagta vissza a spameket, beleertve a Magyar kuldoket is, amiket a kurrens spamszurok nem nagyon szoktak megfogni. Ezen teljesitmeny miatt nem volt false positive. (Ez valszeg a lista gondos osszeallitasanak is koszonheto.) Emellett termeszetesen a klasszikus modszerek, mint pl reverse DNS szures is be vannak allitva.

A modszer azert hatekony, mert uj IP cimet szerezni nem nagy kunszt, egyszeruen keres egy uj szolgaltatot, ahol kap ket hetre egy ingyen VPS-t, viszont domaint venni penzbe kerul.

Backendnek egyebkent az Amazon AWS-t hasznalom, ez kb havi 150 forintomba kerul, cserebe van admin felulet a zonahoz.

Ha erdekel a megoldas reszleteiben, keress meg, szivesen elmondom, hogy tudsz magadnak ilyet epiteni.

Szen alapu technologia. En (humanoid) megnezem a levelet, megnezem a domaineken talalhato weboldalt, megnezem a whoist, stb. Tekintve hogy a sajat mailfiokomat hasznalom erre, pontosan tudom hogy mire iratkoztam fel es mire nem. Nem tudom milyen jol skalazodik, de nekem szemely szerint nagyon bejott.

ja aszittem van ra valami automata.
amikor eppen raerek, en is szoktam ilyet csinalni, csak ahhoz nem kell dns szerver, egyszeruen beirom az assp megfelelo listajaba oszt kesz. ip -t az ip blocking listaba, helo -t a suspicious helo listaba, a domaineket meg a blackdomain listaba.
csak az a baj, hogy hiaba hasznalnam erre a sajat fiokomat nem jonnek a spamok :D)

( bekeny | 2014. 02. 10., h – 12:58 )

Az egyik szerverünkön hasonló napi forgalom mellett és az említett erőforrásoktól kevesebb erőforrással (kb fele) simán elvan egy greylist + MailScanner (azon belül spamassassin és clamav meg csomó felhasználónál/domainnél egyénileg felvett blacklistek és whitelistek). Nem hiszem, hogy a MailScanner erőforrás-kezelése lényegesen jobb lenne az amavisétól, ezért gondolom inkább a greylist az, ami sokat számít, hisz az minimális erőforrással szűr ki csomó levelet (bár egyre kevesebbet). A lényeg, hogy a MailScanner is megér egy próbát szerintem.
Ha szolgáltatás is szóba jöhet, akkor érdemes megnézni a spamhero.com-ot. Elég olcsók és egész jól szűrnek, de azért időnként, főleg magyarra fordított spamek átmennek, ilyenkor tanítani kell (sajnos nem is keveset) és utána már elkapja őket. Egy másik szolgáltatás a magicspam.com, de velük gyakorlati tapasztalatom még nincs, csak tervben van a tesztelésük. Esetleg ha valakinek van tapasztalata, azt szívesen veszem én is.

Ami még rajta van a todo listámon, mint tesztelendő antispam software, az a frams.bitdefender.com. Ez már fel van telepítve egy szerverünkön és tesztből egy domaint át fogunk terhelni hamarosan, aztán meglátjuk. Sok reményt nem fűzök hozzá, de hátha mégis jó valamire.

( szollosiimre | 2014. 02. 10., h – 13:08 )

Mind dobozos, mind cloud megoldásban tudok neked segíteni, ha érdekel.