Szürkelistázás PF-fel

Spam

A szürkelista (angolul greylisting vagy graylisting) egy módszer az e-mailben terjedő spamek ellen. A módszer lényege, hogy a szerver várólistára tesz minden olyan üzenetet, amelyet azonosítatlan címről küldtek. Ha a levél nem kéretlen reklámlevél, akkor a küldő szerver ismét megpróbálkozik majd a kézbesítésével, ekkor már megkapja a címzett az üzenetet, egyébként nem.

Dan Langile arról írt egy elsőre részletesnek tűnő cikket, hogy hogyan csökkenti spam-jainak számát az OpenBSD-s PF és spamd felhasználásával FreeBSD-n, szürkelistázás módszerrel. A cikk itt.

( iron v | 2007. 01. 23., k – 08:13 )

Annyit tennék csak hozzá, hogy nem "várólistára" teszi, hanem megjegyzi a levél adatait és visszadobja 450-es hibával. Normális mailszerver 10perc múlva újra próbálja, a spamküldők 90% -a nem. Naponta 4-5 spam esik át ezen a szűrőn csak (meg persze a normális levelek), ezt pedig sokkal egyszerűbb ellenőrizni egy spamszűrővel, mint a napi több10 vagy több100 levelet.

Nekem még ennél is rosszabb tapasztalataim voltak, amikor más cégek felsővezetői kezdtek el panaszkodni, hogy nem tudnak levelet küldeni, minden visszapattan. Nem védekezhetsz azzal, hogy szar a mailszerverük, mert másnap már nem kell bemenned dolgozni.

Szerintem ez a szürkelistázás alapvetően jó ötlet, de a szarul belőtt mailszerverek miatt használhatatlan, senkinek nem ajánlom.

;-(

Sztem mind a szurke mind a feketelistazas igen karos (lehet) a tapasztalatok szerint. Az elmelet szep meg aranyos de a nezzuk elso korben magyar szemszogbol a helyzetet. Mi egy kis orszag vagyunk kevesen ismernek minket(le sem sz..nak). Tapasztalataim szerint egy amerikai szolgaltatot piszkosul nem erdekli hogy a t-online.hu nevu domain-bol jon-e level 2 hetig vagy sem. Neki az az erdeke hogy szurjon, a mellekhatasokkal meg foglalkozzon az orvosunk meg a gyogyszereszunk. Ez az elmult evben kulonbozo magyar domain-ekkel a szolgaltatonkkal (sprintnet) kb 10x fordult elo. Azonfelul ha az interneten vki spam-et kuld a mi domainnevunkkel, mint felado akkor mi spammereknek szamitunk es egy listara kerulunk... Hogy ki es hol meg mi alapjan tartja karban azt a jo eg sem tudja. Legutobb magyar szolgaltatot kerdeztuk es milyen lista alapjan szur ki minket a valasza annyi volt "ooo nem tudjuk a levelezos rendszergazda kollega szabin van"... no comment! Vannak penzes listak is amik ugyanilyen gyermekbetegseggel kuzdenek... En inkabb erosebb vasat vennek de ez iszonyu mennyisegu rossz, fals talalatot ad...

Nalunk a minosegugy levelezese latta karat. A gyartas meg ugye allhat ami hal istennek "ingyen" van mert nem lehet kommunikalni...

Tudod, hogy mirol van szo a cikkben, mert en erosen ketlem.
Amugy mi is tapasztaltunk problemakat Novell GroupWise szerverrel, valamiert a 450-es hibaval visszameno leveleket elfelejti ujra kuldeni.

York.

------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."

Nálunk nemrég vezettem be. Nagyon hálásak voltak a felhasználók, mert a napi néhányszor tíz spam (ennyi csúszott át) helyett nullát kaptak. A greylisten pedig napi 6-8000 spam vérzik el.
Ha valaki panaszkodik, hogy nem jön át a levele (szerencsére nálunk ez az ügyfél érdeke is) szó nélköl fehérlistára teszem. Nem mondom, hogy nagyon rövid a lista, de egyre kevésbé növekszik.
A felhasználókat tanítani kell. Amikor bevezettem a greylistet írtam nekik kör e-mailt amiben elmagyaráztam, hogy ez mire jó és nagyjából azt, hogy hogyan működik és mi lesz a következménye. Beletelt egy kis időbe amíg megértették de most már nem ijednek meg és rutinosan telefonálnak, hogy fehérlista kellene.

Nálunk nemrég vezettem be. Nagyon hálásak voltak a felhasználók, mert a napi néhányszor tíz spam (ennyi csúszott át) helyett nullát kaptak.

Dettó! :)

A felhasználókat tanítani kell. Amikor bevezettem a greylistet írtam nekik kör e-mailt amiben elmagyaráztam, hogy ez mire jó és nagyjából azt, hogy hogyan működik és mi lesz a következménye.

Szintén. A felhasználók alapvetően nem hülyék, és elég konstruktívak, ha arról van szó, hogy az ember megszabadítja őket a spamtől. Mellesleg hozzám is szoktak jönni, hogy nézzem meg, mert szerintük fennakadt a levél a greylistingen, de 3-4 hónap alatt mindössze egyetlen szerver nem küldte újra a levelet, az whitelistre került, a többi esetben nem a greylisting volt a hibás, hanem máshol tűnt el a levél.

szerintem azért nem baj, ha van greylist, a sima spamassassin nem elég
összegyűjtöttük az összes ügyfelünket, illetve mail-szerverüket és whitelistre tettük
de még így is heti 70e-100e levelet dob vissza a postfix-gld
írtam egy scriptet ami végigrohan a mysql táblán és leellenőrzi, hogy a küldő email címe létezik-e a remote oldalon
persze közel sem tökéletes (pl otthonról küld céges emaillel levelet), de egész jó hatásfokkal le lehet redukálni azt a listát amit átnéz az ember, hogy fennakadt-e egy normális levél

meg mostanában egyre több kép alapú spam jön, lehet nem ártana hamarosan valami OCR spam filter is,
bár nemtom milyen hatásfokkal dolgoznak,
használ valaki olyat?

A képek kiszűrése már volt a SPAMvédelem középpontjában a hup-on: http://hup.hu/node/31827

Annyival egészíteném ki, hogy a 70_sare_stocks.cf fájlban a

score SARE_GIF_ATTACH 0.50-ből érdemes
score SARE_GIF_ATTACH 2.00-t csinálni.

Ragyogóan szűri a gif-es SPAM-eket.

Az OCR filterekkel meg az a baj, hogy az okos SPAMmerek már teleszemeteik a gifeket kis vonalkákkal, hogy az OCR ne tudja értelmezni. Meghát ahhoz elég erős vas is kell(ene).

Ezzel teljesen egyetertek. Nalaunk mar elofordult, hogy "nem kaptak meg a levelemet" mondaa a fonok..

nah gyorsan nezzuk kinek ment, ott valami contatct, vegre egy sysadminnal beszelek, yaaah, greylistunk van,
hozzaadlak titeket a whiteleisthez... de joooooo, inkabb allitottad volna be rendesen...

secret

Jajj, nemár!

És ha mondjuk az én mailszerveremet pár kedves spammer túlterheli, és ezért minden kapcsolatot valami resource exhausted üzenettel 4xx hibával visszadob?

Ha erre a más cégek felsővezetői panaszkodnak, mert az ő MTA-juk utána napokig nem próbálta meg kézbesíteni, akkor a hiba nem nálam van.

Egyébként én ugyan nem használok greylistet (de valószínűleg fogok), de az én MTA-m nem kezd el panaszkodni, nem pattan vissza a levelem. Hanem vár a queue-ban. Aztán ha nem tud elmenni mondjuk 24 óra alatt, akkor már szól, de akkor se visszapattan, csak warning, figyelmeztetés érkezik.

A greylist meg nem szokta 24 órára függőbe tenni a levelet.

Száz szónak is egy a vége: tök mindegy, hogy greylist, erőforrástúlterhelés, DDOS, tervezett karbantartás, félrekonfigurálás vagy mi az oka a kézbesítés sikertelenségének. Ha nem próbálja újraküldeni, akkor magára vessen.

G

( Hunger | 2007. 01. 23., k – 09:50 )

Az a baj, hogy az egész szürkelistázás mit sem ér, hogy ha valakinek átirányított levelei vannak (pl. mobilszolgáltató email címére érkező leveleket forwardoltatja a céges címére vagy a freemail-re érkező leveleit irányítja át, stb.), mert ott ha a küldő (mobilszolgáltató/freemail smtp-je) nem végez megfelelő szűrést és a spamet továbbítja, akkor az a 10 perces várakoztatás után újra megfogja próbálni és így megérkezik a spam.

Arról nem is beszélve, hogy ez is csak időleges védelem, míg a spammerek nem kezdenek rendes mail queue használatba, ahol már ők is újraküldik a levelet X idő múlva.

Sajnos ez igy van, de jelenleg nem ez a helyzet.
Kollega epp hetvegen tesztelte a SPAM szuresunket, (kellett a dolgozatahoz) az SA legalabb 10x annyi levelet fogot mint egyebkent szokott, es biztos vagyok benne hogy joval tobb ment at a szurojen mint maskor szokott.

York.

------
"Nyugi! Minden a legnagyobb rendben csúszik ki a kezeim közül..."

Szerencsére a spammereknek sokkal többe kerül, ha rendes mail szervert használnak, mert 10 percig emlékezniük kell arra, hogy hova is próbálkoztak. Ennél sokkal egyszerőbb nekik venni egy új címet és oda próbálkozni. Persze ha az áldozatok jelentős része greylitával védekezik meg fog változni a helyzet.

Nem kell a spammereknek rendes mail szervert használni, egyszerűen a trójai programjukat - amely a botnetekben lévő zombigépeken fut - kell csak kibővíteni úgy, hogy tudjon mail queue-t. Nem túl nagy munka leprogramozni és erőforrás szempontjából sem vészes a queue-ban várakozó levelek tárolása. Mivel több ezer gépből álló botnetekről van szó, ezért ha spammelés közben 10 percig várakoztatni kell egy levelet, az 10 kilobyte-os átlagmérettel számolva 1000 levél elküldését teszi lehetővé percenként (és gépenként), ha csak 100 megányi háttértárat használ fel queueinghoz. 100 megával kevesebb szabad hely pedig egyrészről nem tűnik fel egy átlag felhasználónak (főleg ha már annyira luzer user, hogy azt sem tudja a gépe egy botnet tagja ;), másrészről biztosan van ennyi szabad hely a háttértárán. 1000 levél percenként egy gépről pedig még mindig elég jó mennyiség, ha több ezer gépes botnetről beszélünk. Arról nem is beszélve, hogy kicsit több programozással megoldható, hogy ne a teljes leveleket tárolja le egyenként, hanem csak a különbségeket, amely szintén elég jó helymegtakarítást eredményezhet...

feltetelezve, hogy a spam generalt level, nem kell tarolni a levelet
csak a cimet es kuldeni ismet egyet. szinte 0 tobblet hattertar igeny.

Igazából nem feltétlenül, mert ha sok 100%-ban azonos tartalmú levelet küld ki a spammer, akkor az megfogható spam hasheléses módszerrel, ahol egy központi adatbázisban gyüjtik a spamek hasheit és ha bizonyos számnál többször érkezik rá találat, akkor az nagy valószínűséggel ilyen spam. Ezért a spammerek úgy szokták küldeni mostanság a leveleket, hogy a tartalmon mindig módosítanak kicsit (máshogy rendezik a modatokat, szavakat kicsit elírnak, több szóközt írnak, stb.), így az ilyen hashelés alapú megoldások nem szűrik ki ezeket a kéretlen leveleket. Ezért írtam, hogy vagy le kell tárolni a levelet is, vagy pedig csak a különbséget az eredetihez képest.

Az más téma, hogy a jelenlegi szürkelistázós megoldásoknál nincs letárolva a levelek tartalma, csak a feladó és a címzett (meg az időpont), pedig összehasonlításkor az is egyfajta szűrésre adhatna alkalmat, hogy második próbálkozáskor is ugyanazt a levelet küldi-e a túloldal vagy nem... (igaz false positive esélyt is növelné, hisz ha valakinek visszapattan a levél, hogy "szürkelistázás, küldje 10 perc múlva", majd utána elküldené mégegyszer úgy, hogy eléírná szövegtörzsben az "újra próbálom" üzenetet, akkor azt is kiszűrné a rendszer.

Hiába, a spam probléma nem egy egyszerű témakör. Ezért is élnek meg ilyen jól a harc szereplői mindkét oldalon... ;)

DCC, razor, pyzor... - ertem, sot hasznalom ;)

Igen, a nyílt forráskódúak közül az ismertebbek, de van még pár spam hashelésen alapuló megoldás ezeken kívül, meg fizetős termék is, amelyik ezt is kihasználja.

Ezert is tartom, hogy nem kell tarolni a body-t.
Ha nem tarolja, hanem ujrageneralja kisebb a veszely,
hogy azonos legyen.

Arra mondtam, hogy a spammereknek problémát okozhat, hogy ha nem ugyanazt küldik el másodjára és a szürkelistázás egy idő múlva kiterjed a levél törzsének ellenőrzésére is, nem csak a feladó+címzett párosra.

A greylist RFC-nélkülisége (tehát, hogy nincs rá szabvány) megengedi azt, hogy azok a szerverek amik élnek ezzel a szolgáltatással, saját maguk konfolják be a delay idejét. Egy-két szerveremen, ahol működik ilyen pl. majdnem fél órát kell várnia az újraküldéssel a sendernek. Megint másol elég 5 perc is. Persze tudom, hogy nem tart semeddig sem olyan sender queue-t csinálni a botnetes gépeken, ami mondjuk 5 órán át 15 percenként újra próbálkozik. Csak egy kis plusz előny addig is... :-)

( zamboriz v | 2007. 01. 23., k – 18:47 )

Most olvastam a slashdot-on ( http://it.slashdot.org/it/07/01/23/0220218.shtml ):

http://www.joreybump.com/code/howto/nolisting.html

"Nolisting fights spam by specifying a primary MX that is always unavailable."

http://www.joreybump.com/code/howto/unlisting.html

"Unlisting attempts to fight spam by using a packet filter to block all access to all MX hosts for a domain unless the sending host has attempted to connect to a single primary MX within a specified time period."

( meridian v | 2007. 02. 01., cs – 08:22 )

Nálunk január 1-től lett bevezetve a greylist, és szinte senki sem panaszkodik egy ügyfelünket kivéve.
Ezt a levelet kaptam tőlük:

"Tisztelt Szolgáltató!

Ezúton kérek Önöktől egy hivatalos leírást (külön dokumentumot) arról,
hogy hogyan kell konfigurálnia ügyfeleinknek saját internetes mail
szerverüket, hogy a tőlük érkező leveleket minél előbb megkapjuk. Ne a
spam szűrési megoldás miatt legyen kézbesítési késés."

Ilyen levélre mit válaszoljak neki szerintetek ?