Növekszik a backscatter-ek száma

Spam

A postafiókodba csorognak be az NDR-ek (Non-Delivery Report) arról, hogy egyes címekre nem volt kézbesíthető az a "Viagra" tárgyú levél, amelyen a feladó te vagy. Csodálkozol, mert te életedben nem küldtél ilyen levelet. Felmerülhet benned, hogy meghackelték a gépedet, vagy egy bekapott kártékony program küldözgeti a nevedben a spamet. Valószínű, hogy egyik sem, inkább az történt, hogy backscatter áldozata lettél. A backscatter olyan visszapattanó e-mail üzenet, amelyet spammerek által becsapott, legitim mailszerverek küldenek vissza.

A spammerek szeretik meghamisítani az általuk elküldött kéretlen levelek feladóját annak érdekében, hogy üzenetük átcsússzon a spamszűrőkön. Mivel a spamszűrők, mailszerverek legtöbbje eldob minden olyan levelet, amely nem létező domain-ből érkezik, a spammerek előszeretettel állítják be úgy leveleiket, mintha azok valós e-mail címről érkeznének. Ez azt jelenti, hogy ha az e-mail címed valahol publikálásra került az interneten, akkor jó esélyed van arra, hogy backscatter áldozata legyél. A spammer megtalálja valahol az e-mail címedet, azt beleteszi a spamként kikülött levél feladó mezejébe, majd kiküldi több százezer címre. Ha a spam olyan címre jut, amely már nem létezik (megtelt a postafiók, stb.), akkor a levél visszapattanhat... hozzád.

Az egyik vírusirtókkal foglalkozó cég szerint az utobbi időben növekszik a backscatter-ek száma. A ComputerWorld cikke itt.

Apropó, mielőtt még el nem felejtem, 30 éves a spam. Nem boldog születésnapot!

( maszili | 2008. 05. 05., h – 14:27 )

Ha pl. az exchange alapertelmezetten nem venne el a levelet ugy hogy nem tudja kezbesiteni akkor valoszinuleg kevesebb ilyen tortenne... de redmondban ugy gondoljak hogy egyszerubb egy levelet kuldeni a hamisitott feladonak a sikertelen kezbesitesrol.

--
maszili

Most akkor vegye el a nem letezo cimzettel kuldott levelet mert mas oka is lehet egy sikertelen kezbesitesnek?... ez igy eleg viccesen hangzik.

Ha csak sajat magaval szur ki az exchange uzemelteto az senkit nem erdekel. Megerdemli! De nekem ne kuldozgesse a sok szemetet azert mert egy kaplap szamocat nem er az egesz szervere.

--
maszili

Nem tudod eldonteni mikor atveszed, (ha valid destination vagy erre a domainra) hogy kezbesitheto, vagy sem a 2, vagy a tizedik hop utan, ha mailhubot uzemeltetsz. Ne induljunk mar ki a pistike2 -bol.

Annyi penzert amennyibe kerul az exchange mar nem fert bele az, hogy "valamilyen hasznalhato" ellenorzest vegezzen a mogotte levo szerverre vagy szerverekre?

--
maszili

Nem lehet pl. egy VRFY-t vagy valamit beprobalni a "kovetkezo hopra?"

Volt szerencsem smtp frontendet (mail hubot) beallitani exchange es linux MTA ele... ott megoldhato volt az, hogy tovabbitas elott ellenorizze majd egy sajat cache-be tarolja a helyes cimzetteket. Emigyen elutasitva azokat a leveleket amelyek cimzettje nem szerepel az adott domainben.

Persze az exchange nemi beallitast igenyelt mert minden vacak levelet elvett alapertelmezetten. Legalabb a sajat domainjeit (amit nem kuld tovabb) ellenorizne le...

--
maszili

( styg v | 2008. 05. 05., h – 14:42 )

"Ez azt jelenti, hogy ha az e-mail címed valahol publikálásra került az interneten, akkor..."

Még ennyi sem kell. Elég, ha levelet küldesz valakinek, aki zombi-gépen olvassa el azt. A háttérben futó "minialkalmazás" (értsd: spambot) az emailcímedet már küldi is haza a gazdinak az emailcím-adatbázisba.

( insight | 2008. 05. 05., h – 14:48 )

És van valami használható védekezési mód?

Én például ennek beüzemelésén gonfolkozom: http://spamassassin.apache.org/index.html . Van több frontendje, valamint backscatter szűrője. (Ameddig a szolgáltatóm használta addig viszonylag kevés spam jutott be, szóval meg voltam elégedve a termékkel, sajna a szolgáltató áttért másféle megoldásra.)

Ha adsz ehhez elerhetoseget (ki, mikor, hogyan vegezte, ill. hol lehet megnezni az eredmenyeket), ill. hogy melyik termekrol van szo, akkor meg tudom mondani...

Ah, kozben megtalaltam. Nem csoda, hogy ismerosen csengett a neve, hiszen en is hivatkozom ra - elrettento peldakent. Szoval nem, a konyvben szereplo tesztek nem ilyenek. Ha egy konyvesbolt kornyeken jarsz, akkor lapozz bele, hogy en hogy teszteltem. Sajna nem ez a resz lett a "sample chapter"...

ASK Me No Questions, I'll Tell You No Lies

Én a következőt találtam ki erre:
- a usereim csak az én mailszerveremen küldhetnek levelet, ha más úton küldik, nem kapnak visszapattanókat
- a saját mailszerverem a kimenő levelekben lecseréli a MAIL FROM paraméterét valami random cuccra. A random cuccot beletolom memcached-be mondjuk 5 napos lejárati idővel
- az MX-en ha jön levél erre a random címre, elveszem, kézbesítem a valódi feladónak, a memcached-ből pedig törlöm a címet, így több nem jöhet be. Esetleg az idióta címvisszaellenőrző MTA-k miatt ezt a számot (hányszor használható) lehet emelni.

Lehet beletenni kriptót is, elkódolni vele az érvényességi időt (ezesetben az állapot tartására nem feltétlenül van szükség, cserébe amíg az érvényesség le nem jár, több levél is bejöhet).

- igaz, be lehet vezetni egy számlálót (szerintem 10-20-nál nem érdemes nagyobbra állítani)
- az eddigi tapasztalataim szerint a userek 99%-a jobb, ha egyáltalán nem kap bounce-ot, mert nem érti, így lehet, hogy ez annyira nem izgat (memcached helyett lehet valami állapottartót is használni, ha úgy tartja a kedved :)

az auto-whitelist funkcióról nem is beszélve, amikor ha rendszeresen érkezik egy feladóról valahova levél, akkor beteszi auto-whitelistbe, és nincs késleltetés. így gyk. minden levél késni fog x percet, akkor is, ha rendszeresen levelezik valakivel (ha nincs egyéb módon pl. domain/ip szinten beengedve egyébként). nem jó.

mi lenne akkor, ha "statikus" kulcs lenne, valami kripto módszerrel, és 2 hétig lenne érvényes (de 2 hétig ugyanarról a címről menne ki levél minden esetben). Így nem válna értelmetlenné az auto white list a címzetteknél.

Ha ez után (2 hét) érkezik egy levél az /dev/null. Szerintem ezzel egy jó % -ot kiiktattál.

Ez alatt érkező leveleknél megnézed, hogy az előző 5-7 napban a feladó küldött-e levelet oda, ahonnan a <> érkezik. Ha nem, /dev/null. Ezt célszerű mondjuk IP blokk alapján ellenőrizni egyrészt mert az smtp fázisban ez az információ rendelkezésre áll másrészt mert más nem is nagyon áll rendelkezésre, a feladó az <> a headerekben meg többnyire egy ISP cím fog szerepelni. Szóval amikor küldi a mailt a felhasználód akkor az envelope sender átírása mellett töltesz egy listát a címzettek lehetséges MX-einek IP adataival. Mondjuk C vagy B blokk szinten. Befele meg ehhez hasonlítasz. Ha a címzett forwardolt valahova máshova, és onnan jön vissza non-delivery, azzal ez nem tud mit kezdeni, de ennyi belefér. Jobb kevesebbet kapni, mint többet.

Na ja. Bar ... nem tudom, hogyan kapcsolodsz a memcached-hez (gondolom, tcp-n). Kivancsi vagyok, mennyi idobe telik, mire valaszt kapsz a kerdesedre, ill. vajon meddig tart egy kb. 2kB-os file beolvasasa mmap()-pal, majd egy strstr() eredmenye. Btw. en amugy is parse-olom az egesz levelet (statisztikai szuro), igy ez relative nem tul sok extra melo.

ASK Me No Questions, I'll Tell You No Lies

Sosem mértem, most összedobtam egy három soros perl scriptet, szerinte kb. 0,2 ms alatt jön válasz (már nyitott TCP csatornán).
De akármit is mondasz, az RCPT TO-t ellenőrizni mindenképpen gyorsabb lesz, mint átvenni a levelet, fájlba írni, mmap-olni, keresni benne, majd válaszolni. :)

"ha rendszeresen érkezik egy feladóról valahova levél, akkor beteszi auto-whitelistbe, és nincs késleltetés. így gyk. minden levél késni fog x percet, akkor is, ha rendszeresen levelezik valakivel"

a) "nincs kesleltetes"
b) "minden level kesni fog x percet"

A ketto logikailag kizarja egymast...

A szurkelista imho full jo, ha valaki mar egyszer bizonyitotta, hogy nem spambot, akkor aztan mar nem farasztja tovabb...

ASK Me No Questions, I'll Tell You No Lies

Be lehet állítani nagyon rosszul is - az egyik egyetem mail szervere például az én szolgáltatóméval nem tud együttműködni, tekintve, hogy utasítani próbálja, hogy mikor küldje újra a levelet - de a szolgáltató mail szervere meg magától terheltség alapján dönt, hogy mikor próbálkozzon újra, ekkor megint a szürkelista, küldje újra... Az eredmény az, hogy 5 nap után visszakapom a levelet.

Az ures feladoval erkezok ellen most ezt a negysorost probalgatom (exim, az acl_check_rcpt-ben):

deny senders = :
condition = ${if ! eq{$recipients_count}{1}{1}}
message = Bounces must have only a single recipient
log_message = Another denied due to backscatter check

Aztan ha bevalik, es nem dob el olyasmit, amit nem kene, marad.. Esetleg valaki nalam okosabb megmondja, miert rossz nekem :)

Valaki felvetette egy masik topikban, hogy az IronPort pl. ugy lezeli le a jelenseget, hogy tesz a kimeno levelek fejlecebe egy extra header line-t. Ha bounce jon vissza, akkor megnezi, hogy szerepel-e benne ez az extra header. Ha nem, akkor egyertelmuen backscatter, igy az adott level eldobhato, megjelolheto, stb..

ASK Me No Questions, I'll Tell You No Lies

Én is ugyanezt használom erre. El lehetne bonyolítani, de ennek is van kb. 70-80%-os hatékonysága, ha valami miatt a túloldal kivágja a fejlécemet, akkor legfeljebb nem kap visszapattanó levelet a userem. Ha fontos a levél, előbb-utóbb kiderül, hogy nem érkezett meg, telefonon leegyeztetik újra a mailcímet stb. és ha eléjük teszem a statisztikát, hogy különben hány spammel kéne küzdeniük naponta, akkor ők is megértik. Bra módszere sokkal jobbnak hangzik, de bonyolultabb is.
---
;-(

Adnék három példát ki hogy használja:
t-online: sehogy
invitel: ha a saját levelező szervere küldi, azt engedélyezi. Ha más küldi, akkor puhán elutasítja.
g-mail: ha a saját levelező szervere küldi, azt engedélyezi. Ha más küldi, akkor nem mond rá semmit.

Ha a fogadó mail szerver kezeli az SPF-et, akkor elutasítás esetén elutasítja a levelet, egyébként a domaintől kapott infót beteszi a levél fejlécébe és a spam szűrők további infót tudnak kapni arról, hogy a levél tényleg onnan jött-e, mint ahonnan kellett volna.

Tettem egy próbát. gmail-es levelet küldettem az inviteles levelező szerverrel.
A mi levelező szerverünk kezeli az SPF-et, ezért a következő került a fejlécbe:
Received-SPF: Neutral (access neither permitted nor denied)
Ugyanaz gmail-lel küldetve:
Received-SPF: Pass (sender SPF authorized)

ez ugy ved, hogy meghatarozhatom, honnan kuldhetnek a nevemben levelet.
es ha en egy ceg vagyok, akkor a dolgozo hasznalja csak a ceges mailszervert, ha meg otthonrol akar, akkor vpn-en keresztul vagy TLS -es smtp auth utan szinten hasznalja csak a ceges mailszervert, a kinabol a nevemben levelezoket meg a celszerver elutasithatja azon info alapjan, hogy onnan nem kuldhetnek a nevemben, azaz nemkeletkezik bounce.
de szerintem ezt te is jol tudod, csak hat emberek lustak beirni a dns szerverbe azt a plusz sort, meg hasznalni a fogado oldalon az spf miltert vagy ami az adott szerverhez eppen van.

Ahogy lentebb irtak, az SPF volt az a "vedelmi technika", amit a spammerek elobb implementaltak. Magyarul szepen elkezdtek az altalunk hasznalt domainek TXT rekordjaiba beirni az SPF-et, igy egy pontozos szuron maris rengeteg minusz pontot kap az adott level, meg ha televan viagraval is...

Itt nincs semmi probléma. Az SPF közvetlenül nem arra való, hogy kiszűrje a spam-et, hanem arra, hogy azonosítsa a levelet. Ha a spammer használja az SPF-et, akkor biztos lehetsz benne, hogy a spam tényleg tőle jött. Ha nem használja, akkor nem lehetsz biztos benne. Ez arra való, hogy a nevedben ne küldjenek levelet (akár spamet, akár mást).

Nagyobb problema, hogy ha valakinek van 5 emailcime, es egy hatodikra gyujti a leveleit, rosszul beallitott levelezo eseten a forward elbukik az spf-en. X kuld y-nak, y forwardol z-nek. Ket eset lehetseges. Y atirja a sender-t, akkor z azt latja, h a level y-tol jott, minden szep. Y nem irja at a sender-t, z azt latja, h a level x domainbol jott, y cimerol. SPF ellenorzes, x listajan y valszin nincs rajta. Level bukta..

Nem lehet rakenyszeriteni ezt a vilagra (en pl. spf nelkul is vigan szortirozom kulon a levelszemetet), arrol nem is szolva, hogy van nemi problema az spf-fel, ami miatt tobben nem ajanljak (akkor mar inkabb a domainkeys-t). Azt meg csak a vegen mondom, hogy az spf nem a spam ellen lett kitalalva, hanem a domainnev hamisitas ellen.

ASK Me No Questions, I'll Tell You No Lies

valoban nem a spam ellen, de itt eppen hamisitasrol beszelunk, es az spf erre a visszapattintott szarra tok jo lenne, mert ha en aszondom, hogy nemkuldhet a nevemben; akkor az a mailszerver ahova allitolag kuldtem, eldobhatja a levelet mindenfele bounce es szivfajdalom nelkul, megaztan ha letezo cimre ment a cucc,a bayes elemzesre sem kell eroforrast pazarolni...

( siposa v | 2008. 05. 05., h – 23:17 )

A leírtakon felbuzdulva bekapcsoltam egy Exim-en a BATV-ot (valahogy így), erre kiderül, hogy a saját szolgáltatóm szervere nem eszi meg a "/" jelet a "mail from"-ban.

Mennyire tipikus probléma ez? Hagyjam bekapcsolva és írjak nekik, vagy felejtsem el a BATV-ot?

Nem az, és ezért értetlenül is állok előtte, miért így kellett implementálni. De azért a legtöbb szerver megeszi. Használni szeretném, sajátot gányolni meg nem akarok.

Update: az rfc szerint szerepelhetne "/" is...

Választok egy másik karaktert (pl. "#") és majd replace-elem.

Update 2: Beüzemeltem, működik, egyelőre minden frankó :)

( Tyra3l | 2008. 05. 06., k – 19:10 )

Bennem az ilyen levelek eseten mindig felmerul, hogy mi van akkor, ha nem az en nevemben spammeltek azt a szervert, ahonnan latszolag visszapattant a level, hanem en vagyok az eredeti celpont, es csak visszapattano levelbe bujtatjak a szemetet.

Tyrael

Sokszor ez is a cél, mert rengeteg a rosszul bekonfigurált MTA. Én pl. hasonló okok miatt nem engedélyezem még azt sem, hogy a userek "Out of Office" üzenetet állítsanak be, amely automatikusan küld válaszlevelet minden egyes beérkező levélre... Nem kevésbé veszélyes, hogy ezzel terheléses támadást is kezdeményezni lehet. Mindig szörnyülködöm, hogy a nagy security levlistákra küldött levelemre hány ilyen visszapattanó válasz érkezik, magukat biztonsági szakértőnek kikiáltó adminoktól. Sok évvel ezelőtt meg is vicceltem jópár ilyen arcot, mert elég volt csak egyik nevében küldeni egy levelet a másiknak és pattogott ide-oda az automatikusan generált válaszlevél, telítve a sávszélességet és a drága szagértők postaládáját. >;D

Bennem is bújkál egy ilyen vicces gondolat. Ezért a következőt gondoltam ki (a megvalósítása folyamatban van, csak lassan megy mert keveset tudok vele foglalkozni)

- Minden a serveremen hostolt domain minden userének a levelét átadom egy (Perl) scriptnek,
- Ami minden levélben a feladó e-mail címeből képez egy md5sum -ot és beírja egy X-Checksum: nevű mezőbe
- A bejövő leveleket, ha az "MAILER-DAEMON", "Mail Delivery System", stb... feladóval jön megkapja szintén a script és ha nincs benne az X-Checksum (természetesen itt az egész levelet végig kell keresni), akkor vagy egy mások mappába kerül (Maildir!), vagy az X-Spam-Level -t megnövelem, mondjuk 2.0 pontal
- Ezután a procmail teszi a dolgát és rakja a levelet az őt megillető helyre

----
Nyicc-egy-csört?
Esetleg nézd meg itt: http://kayapo.dyn.hu/

( msandor v | 2008. 06. 29., v – 16:17 )

A backscatter eddig szinte minden ügyfelem életét megkeserítette 10-20-100 levéllel, aztán elmúlt...
De tegnap éjszaka egyetlen címre ~4200 db backscatter levél érkezett, aztán ahogy jött, el is tűnt...

--
by Mikul@s