Sziasztok!
Körülbelül 2-3 napja az egyik felhasználó napi szinten kap 20-25 "spam" hírlevél jellegű levelet, amely levélnek minden esetben más a feladója, illetve a feladó szerver domain neve.
A domain minden esetben .icu végződésű, a feladó pedig úgy tűnik mintha valós ember lenne, pl.: Kovács Péter, vagy Nagy Áron, stb...
A küldő szerver ip címe minden esetben ugyanaz, viszont rendelkezik DKIM kulccsal, így a spam szűrőn átmegy a levél.
Postfixben betettem a sender_checks fileba a küldő szerver ip címét, a /etc/postfix/main.cf-ben, pedig a smtpd_recipient_restrictions = check_sender_access cidr:/etc/postfix/sender_checks , első helyen áll, ami google találatok szerint lehetővé teszi, hogy a levelet feladó esetében , a fileban definiált ip címek tiltva legyenek.
A postmap /etc/postfix/sender_checks , illetve a /etc/init.d/postfix reload megvolt , de így is beengedi a "legálisnak" tűnő hírleveleket.
Ha a leiratkozásra klikkel a felhasználó, akkor kidobja a rendszer, hogy sikeres leiratkozás, de másnap dupla annyi levelet kap.
Írni nem tudunk kinek, mivel mindig más domainre mutat egy adott levélben taláható hivatkozás.
A levél fejlécében az alábbi adatok találhatóak:
A levélben ugyan semmilyen csatolmány nincs, de idegesítő, hogy napi 20-25 ilyen levelet küldenek.
Lehet, hogy rosszul próbálom a tiltást / szűrést eszközölni, de google találatok is a fent felvázolt megoldásra hivatkoznak.
Regex alkalmazásával próbáltam blokkolni a .icu domainről érkező leveleket, de nem tudja kezelni , mert invalid sytanx-ra hivatkozva mellőzi azt a sort a fileban, ahol a
regex szerepel.
Kliensen lefuttattam malware / spyware / antivírus szoftvert, egyik sem talált semmit, fake beépülők / bővitmények nincsenek, keresőmotor sincs átállítva, semmilyen toolbar nincs telepítve, így nagy eséllyel valamilyen weboldalon futott bele egy kamu linkbe, ahol bekerült egy spam adatbázisba.
Milyen módszerrel lehetne ezt a "legálisnak" tűnő hírlevélküldőt blokkolni?
A válaszokat és a segítségeteket előre is köszönöm!
Hozzászólások
Szia!
Neked check_client_access kell. A check_sender_access a MAIL FROM szakaszban megadottakat vizsgálja, ott nem valószínű, hogy IP cím van.
Azt is próbáltam már, de több fórumon írták, hogy ott azt az ip címet vizsgálja a postfix, hogy milyen ip címről csatlakozhatnak a szerverre, ezért módosítottam check_sender_access-re.
fogd meg HELOnal....
en ket helyen titom. egyik:
$ cat rejected_domains
/\.icu$/ REJECT Sorry
es main.cfban: smtpd_sender_restrictions = reject_unknown_sender_domain, pcre:/etc/postfix/data/rejected_domains
masik:
$ cat header_checks
/^List-Unsubscribe:.*icu/ REJECT Message rejected
/^List-Unsubscribe:.*ub.php/ REJECT Message rejected
es a main.cfben:
header_checks = regexp:/etc/postfix/data/header_checks
mivel icu domain vegzodes (ha jol kerestem ) akkor nem letezo, igy ez csak spam lehet, valid cim nem.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Köszönöm, ez kiválóan működik! :)
"mivel icu domain vegzodes (ha jol kerestem ) akkor nem letezo"
ez nem igaz, különben a DKIM se lenne sikeres (ami meg tudtommal DNS-re épül)
Amúgy pedig ott van az:
https://en.m.wikipedia.org/wiki/List_of_Internet_top-level_domains
ICANN-era generic top-level domains -> i betű
.icu - entrepreneurs and business owners - ShortDot SA
Míg ezt nem olvastam meg se néztem, hogy azok a spamek amiket kapok mostanság milyen tld-vel jönnek. Olyan sok nem jött hogy zavarjon, de így tiltottam.
Én ezt a spamet egy milterrel szűröm. Ez a spammer százával jegyzi be a domain neveket de jellemzően mindegyik névnek ugyanaz a névszervere. pl. nooracompany.icu SOA -> ns1.reg.ru. Ezek alapján minden "ns1.reg.ru", "ns2.reg.ru", "dns1.registrar-servers.com", "dns2.registrar-servers.com", stb-nél hostolt FROM domain az helyből reject.
Azon a weboldalon durva szöveg van azért :D
Erre a kamudumára gondolsz?:
We send permission-based emails. You have received this email because one of our clients has identified your email address as having "opt-in" status (i.e. the holder of your email address has voluntarily shared their address for the purpose of receiving offers and information. If you wish to no longer receive emails from this subscriber please reference the "unsubscribe" information at the bottom of the email you have received and you will be removed from their mailing list within 24 hours. The sending of unsolicited commercial email is not permitted using this system.
Szia!
Ez melyik milter, vagy Te írtad?
Nem postfixet használok (még). Postfixhez lentebb a megoldás.
Ebben az esetben a saját privát levelezésemről van szó. Egyébként január közepéig ez a spam a namecheap (registrar-servers.com) nevekről jött. Én ebbe a milterbe nyúltam bele, de ha kliensen szűrsz header alapján akkor nagyon piszkálni sem kell, legfeljebb annyit hogy akkor is írjon valamit a headerbe ha nem létezik a név (pl. NXDOMAIN) hogy lehessen kliensen szűrni. http://www.snertsoft.com/doc/milter-ns/ de a lent említett rspamd is tetszik így első ránézésre, vagy megnézem azt közelebbről vagy postfixre váltok. valamikor.
Ha jól értettem a doksit, akkor a check_sender_ns_access szűrés pont ezt csinálja, és úgy látom hogy működik is.
smtpd_sender_restrictions = warn_if_reject reject_non_fqdn_hostname, reject_invalid_hostname, reject_unknown_sender_domain, check_sender_ns_access hash:/etc/postfix/sender_ns_access
A sender_ns_access-be ezt írtam:
reg.ru REJECT
a registrar-servers.com ns a namecheap.com-nak a dns nevei. eleg sokan regelnek ott mert olcso. persze ha csak .hu domainnel levelezel akkor tuti nem dobsz ki senkit
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
úgy érted, hogy jó ötlet arra is szűrni, vagy inkább nem?
Nem. Ugy ertjuk, hogy egy teljes domain regisztratort a kb 4+ millio domainjevel egyutt nem feltetlenul jo otlet feketelistara tenni...
zen.spamhaus.org már blokkolja...állíts be RBL checket...
Én is megszívtam ezzel...a hétvégén...de ma már szépen pattannak a levesbe..
postfix main.cfbe ezt told be....
smtpd_recipient_restrictions =
......
reject_rbl_client zen.spamhaus.org
De ha valaki tud jobbat, akkor én is alkalmaznám..
Nekem eddig ez a legjobb (meg a client reverse DNS check), de azt tudni kell hozzá (nekem az elején újdonság volt, ezért írom most le), hogy a legtöbb jó RBL (így a Zen sem) nem szolgálja ki az ismert DNS cache-eket (8.8.8.8, 1.1.1.1, 9.9.9.9, 4.2.2.4, stb.) így saját (nem forward-oló) rekurzív DNS-t érdemes használni azon a levelező szerveren, amin ilyen RLB-ek vannak beállítva (mert egyébként mindig NXDOMAIN lesz, ergo a levelező azt hiszi, nincs az RBL listán a keresett név, és átengedi).
Jó egy hete az összes .icu domain megy a levesbe.
Lekopogom, de azóta a napi 80-150 spam áradat elmaradt.
(Tudom, hogy ez atombomba és nem a szép megoldás)
Nálam is feketelistán vannak mióta megnéztem, hogy egyetlen nem spam email nem jött tőlük viszont a spam több mint 20%-át ők küldik.
Főleg úgy nem szép megoldás, hogy legalább 2 megoldást is leírtak itt a hupon is a szűrésre.
Még nem láttam nem spam e-mailt a .icu domainről (a spamassasin más kritériumok alapján igen helyesen spamnek látta az összeset). A reg.ru nameszerverről viszont nem tudunk semmit. A neve eléggé rövid és kézenfekvő - valószínű valami nagyobb, de olcsó regisztrátoré lehet Oroszországban. Könnyen elképzelhető, hogy valamilyen orosz ügyfél domainje is ott van regisztrálva. Hasonló lehet a helyzet, mint a namecheap esetén.
Kisebbnek látom a falspozitív valószínűségét a .icu kidobásával.
Egy héttel azelőtt már beállítottam, minthogy itt az ötletek megjelentek. :)
Egyelőre nem látom okát, hogy szofisztikáltabb legyek.
+1 engem csak most ért el, de az egész .icu ment a REJECTED -be. :-)
Mivel nem ISP vagyok, és pontosan tudom hogy egyetlen egy ügyfelem se vár levelet .icu domain-ről ezért kb. ennyit tettem az ügyben.
ha spamassassint hasznalsz, akkor neked ez kell.
https://hup.hu/node/154794#comment-2129500
--
HUP te Zsiga !
Szia!
Köszi az ajánlást! :) Átköltöztettem a kódot egy publikus repóba, itt érhető el: https://github.com/szenti/spamassassin-from-domain-check/
Jöhetnek az issue-k és a pull requestek.
A megoldásom egy szimpla blacklist megvalósítás, SpamAssassin plugin formájában. A From: headerben található domain reverse DNS-ét IP címekre feloldva megvizsgálja, hogy benne van-e a szkriptben található blacklistben (a fenti spammer által küldött spamek 100%-a ellen jó, mert a reverse DNS-t ritkán frissíti a jómadár).
Ma kicsit refaktoroltam a kódot, és kapott egy új funkciót is: képes több feloldott IP cím vizsgálására is.
Üdv,
Szenti
köszönet a plugin-ért, hónapok óta használom. Az új verzió azonban nálam (Debian Stretch) nem működött, küldtem be egy issue-t javítási javaslattal.
Köszönöm, hogy jeleztél, már javítottam is.
Új ip: 178.128.76.93
De most valami trükközés lehet a névfeloldással, mert nem minden domain esetén kapok választ az NS-től.
Spamassassint használok, így: https://github.com/szepeviktor/debian-server-tools/tree/master/mail/spam
az aktuális IP csak egy RBL-en van fent: https://bgp.he.net/ip/104.248.39.95#_rbl
az élő RBL-em a spammer-ekről: https://github.com/szepeviktor/debian-server-tools/blob/master/mail/spa…
ismert csak-támadó hálózatok élő listája: https://github.com/szepeviktor/debian-server-tools/tree/master/security…
+1 sok spammer-nek a HELO string-hez tartozó SPF rekordja hibás
"Content Delivery Network, Boundary line team"
Ó! Hát őket úgy Hívják, hogy NOVUM IMPORT
katt https://github.com/szepeviktor/debian-server-tools/blob/master/mail/spa…
és katt https://github.com/szepeviktor/debian-server-tools/blob/master/security…
itt van több módszer (shell parancsok formájában) egy-egy IP tartományból kihámozni őket
az SMTP HELO SPF hibája alapján is meg lehet ismerni őket
nekem úgy tűnik, mintha nem is lenne rendes DomainKey a feladónál, csak az üzenetet írja alá valami kamu kulccsal, de a DNS-be nincs beállítva a publikus párja (azt hiszem a t=y az a teszt mód flag, de v= rész nélkül nem is szabványos szerintem...)
_domainkey.nooracompany.icu. 86400 IN TXT "t=y; o=~;"
nooracompany.icu. 86400 IN TXT "v=spf1 a mx ip4:104.248.39.95 ~all"
Szóval, ha már a levél alá van írva domainkey -el lehet érdemes forcolni a visszaellenőrzését is.... gyanús hogy a spammer valami bugra hajaz....
Nekem egyetlen gépre 103677 db spam érkezett icus domainről 7 nap alatt.
Bele-belenézve mind digitaloceanos IP-ről. DO-nál ezt nem tudnák megfékezni valahogy?
Nekem dec 14 óta majd 10000db, exim kapott új reject filtert, majd ez is elmúlik egyszer csak,
/OFF
piroskagyulatréningel mi lehet? :D
/ON
Kb. egy éve keresett meg, hogy kéne neki VPS.
Nem kapott :D
Nálam is jelentkezett a probléma. Én úgy oldottam meg, hogy az egy ideje már halogatott dspam szűrő bevezetését megtettem. Be is tanítottam a napokban fogott icu és info végű levelekkel. Azóta jónak tűnik.
Mondjuk érdemes szemezni az itt feldobott ötletek között, mert akkor át se kell vennem a levelet.
Zavard össze a világot: mosolyogj hétfőn.
Nem mai gyerek ez a DSPAM. 2012 áprilisa óta sok idő eltelt. :)
Csak kérdezem, hogy az ASSP-t nézted esetleg?
Nem, mert nem is ismertem. Úgy hogy köszi a tippet, megnézem valamikor.
Egyébként a dspam és a bogofilter volt versenyben (mivel sa-t kifejezetten nem akartam). A dspam (noha jóval öregebb és kevésbé karban tartott) a normális démonizált működése miatt nyert.
Zavard össze a világot: mosolyogj hétfőn.
Rspamd-n kergesd at milterrel, problema megoldva.
+1 szinte mindent megfog !!!
--
Debian Linux rulez... :D
RIP Ian Murdock
Kicsit régi, de nem nyitok ezért újat.
Nézegettem az rspamd-t, jól értem, hogy egymagában ki tudja váltani az alábbiakat?
- postfix smtpd_client_restrictions-ben az RBL-ek
- postgrey
- spamassassin
Thx.
az rspamd a spamassassint ki tudja valtani.
a postfix meg ugy el tudja dobni a levelet, hogy spamszuroig el se jut.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Értem, hogy más megközelítés, de az a kérdés, hogy fusson sok "felesleges" cucc (postgrey, spamassassin, postfix-ben RBL ellenőrzés), vagy elég az rspamd (+redis) és majd ő szól a postfix-nek, hogy dobja vissza a cuccot.
vess egy pillantast az ASSP-re.
--
HUP te Zsiga !
Ezt mintha már néztem volna, de megnézem újra.
viszont rendelkezik DKIM kulccsal, így a spam szűrőn átmegy a levél.
ke? Es ezt igy hogy? Mi koze egy valid dkim alairasnak ahhoz, hogy a level ham vagy spam? Semmi. Ezeket a technikakat legeloszor pont a spammerek kezdtek hasznalni, de meglep 10+ ev utan is sikert aratnak. Mar ahol persze...
--
O1G = orbanegygeci
A domain minden esetben .icu végződésű
Fel kell irni a *.club, *.download, *.website, *.party es kis baratkai utan a listara - nincs tobb problema :)
Azért elég érdekes helyen vannak tárolva e-mail címek: view-source:http://nooracompany.icu/
most, hogy a .icu -t mindenki blokkolja, lehet boviteni a listat :
.space
.fun
.host
--
HUP te Zsiga !
A .site is blokkolva, 24 óra alatt 1844 jött innen.
A reverse DNS ugyanaz, mint a .icu esetén. Mi észre se vettük.
már .com-ról küldi (reachtelugu.com), NS alla.ns.cloudflare.com; max.ns.cloudflare.com. :)
Kik nem szűrik ki ezeket a spameket 100%-ban, hogy még mindig megéri küldeni?
Ezt kérdezem én is!
És hogy lehet az, hogy más és más Digitaloceanos gépről jön? Nem tiltják ki az usert?? Vagy van 97 féle identitása?
Érthetetlen.
Egy ideje most cloudflaren hostolt .icu domainekről jön. pl.
walsongroup.icu; NS 21533 bayan.ns.cloudflare.com.; NS 21533 gwen.ns.cloudflare.com.
vajon miért nem jelentette fel őket még senki? vagy ez már megtörtént de nem találnak fogást rajtuk?Egy csomó helyen nincs 100%-os, de ha csak 98-99%-os van, a simán megéri nekik... Ugye ha 2000 emailt elküldenek per nap, akkor is 20-40 átjut.
mondjuk azt en se ertettem miert kuldenek ugyanarra a fiokra napi 20-50 levelet...
most megneztem kivancsisagbol, nalunk mi fogja meg oket, mert en nem varazsolok ilyen dns lookup ip listakkal, es megse jut at egy se:
ez 29 pontot kapott, ez a legkevesebb:
X-Spam-Report:
* 3.3 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
* [159.203.80.244 listed in zen.spamhaus.org]
* 6.1 BAYES_99 BODY: Bayes spam probability is 99 to 100%
* [score: 1.0000]
* 1.5 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
* [score: 1.0000]
* 2.0 DEEPSPAM_SPAM DeepSpam probability>98%
* 1.0 DEEPSPAM_MSPAM DeepSpam probability>90%
* 2.5 URIBL_DBL_SPAM Contains a spam URL listed in the Spamhaus DBL
* blocklist
* [URIs: mysorefarmhouse.icu]
* 1.3 RCVD_IN_RP_RNBL RBL: Relay in RNBL,
* https://senderscore.org/blacklistlookup/
* [159.203.80.244 listed in bl.score.senderscore.com]
* 0.1 URIBL_SBL_A Contains URL's A record listed in the Spamhaus SBL
* blocklist
* [URIs: mysorefarmhouse.icu]
* 1.6 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL
* blocklist
* [URIs: mysorefarmhouse.icu]
* 5.0 URIBL_ABUSE_SURBL Contains an URL listed in the ABUSE SURBL
* blocklist
* [URIs: mysorefarmhouse.icu]
* 5.0 URIBL_BLACK Contains an URL listed in the URIBL blacklist
* [URIs: mysorefarmhouse.icu]
* 0.0 HTML_IMAGE_ONLY_32 BODY: HTML: images with 2800-3200 bytes of words
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 0.2 SARE_SUB_ENC_UTF8 Message uses character set often used in spam
X-Grey-ng: delayed 1023 seconds (suspect=4, ip=159.203.80.244) reason: truncate.gbudb.net,zen.spamhaus.org,BLACKLIST(2)
ez a 36 pontos:
X-Spam-Report:
* 5.0 URIBL_ABUSE_SURBL Contains an URL listed in the ABUSE SURBL
* blocklist
* [URIs: primesacademy.icu]
* 5.0 URIBL_BLACK Contains an URL listed in the URIBL blacklist
* [URIs: primesacademy.icu]
* 2.5 URIBL_DBL_SPAM Contains a spam URL listed in the Spamhaus DBL
* blocklist
* [URIs: primesacademy.icu]
* 3.3 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
* [134.209.120.63 listed in zen.spamhaus.org]
* 0.1 URIBL_SBL_A Contains URL's A record listed in the Spamhaus SBL
* blocklist
* [URIs: q.primesacademy.icu]
* 1.6 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL
* blocklist
* [URIs: q.primesacademy.icu]
* 6.1 BAYES_99 BODY: Bayes spam probability is 99 to 100%
* [score: 1.0000]
* 1.5 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
* [score: 1.0000]
* 1.0 DCC_SPAM_FUZ2 DCC check fuz2 many
* 2.0 DEEPSPAM_SPAM DeepSpam probability>98%
* 1.0 DEEPSPAM_MSPAM DeepSpam probability>90%
* 0.5 FROM_LOCAL_NOVOWEL From: localpart has series of non-vowel letters
* 1.6 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date
* 2.1 HTML_IMAGE_ONLY_12 BODY: HTML: images with 800-1200 bytes of words
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 0.0 HTML_SHORT_LINK_IMG_2 HTML is very short with a linked image
* 0.2 SARE_SUB_ENC_UTF8 Message uses character set often used in spam
* 3.3 MIXED_ES Too many es are not es
Mostmár, de ha az IP nincs listán (akár többön), akkor könnyen átjut 1-1 belőlük. Akkora mennyiségben jön, hogy azaz 1-1 is elég sok.
A MIXED_ES-re azt vettük észre, hogy egy csomó normál email is matchel, tehát az a 3.3 pont ott kérdőjeles.
tartalom alapjan a bayes es a deepspam is jeloli mindet, az is eleg hogy megfogja. az elso par db utan a dcc is jelez ra.
Több gépen is rezetelnem kellett a bayes db-t a sok fals pozitiv miatt a napokban, szóval arra önmagában nem támaszkodnék.
en is most reseteltem (kb fel evente kell), de van eleg szep gyujtemenyem spammekbol (es ellenorzott ham-ekbol es fp-kbol) amivel rogton fel is tanitom, hogy ne 0-rol induljon.
Lehet, hogy nalad mas, de nalam amit az rspamd spamnek jelol, az a felhasznalonal a junk mappaba kerul.
Te elbol elveted a levelet smtp szinten? (aka. bontja a kapcsolatot a szerver).
Mert nalam van egy backlist (ha a domain nev elofordul kb. barhol az smtp kommunikacioban), akkor bontja a szerver a kapcsolatot.
A backlistet ami meguszta, azt szurom spamszurovel, valamint a userek meg sajat szabalyt is krealhatnak.
Egyebkent ugy nezem, hogyha kuld valaki neked egy listat, hogy ezek az emailek valahogy atjutottak a spamszurokon: a @ a.icu, b@ b.icu, akkor a levelet meg se kapod, mert aggatsz ra par URIBL_BLACK flaget, emailcimenkent 5 buntetoponttal... :)
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
15 pont folott megy a karantenba a szerveren, 5-15 kozott megkapja az user megjelolve a junk mappaba. nem smtp-nel szurok hanem after-queue.
es van direkt spam@domainnev email cimunk amire nincs szures, oda kuldheti az user ami szerinte atjutott a szuron.
kosz
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
En ezeket smtp kapcsolatnal szurom (helo, rdns, mail from, rcpt to):
.*\.icu
.*\.xyz
.*\.biz
.*\.space
.*\.fun
.*\.host
.*\.site
.*\.pw
.*\.club
.*\.company
.*\.bid
.*\.art
.*\.top
.*\.cn
[0-9a-z]\.com
[0-9a-z][0-9a-z]\.com
[0-9]+\.com
Ami ezen tovabbjut, azokra megy a spamszuro, meg az egyeni (felhasznaloi) szurok.
Tegnap neztem statisztikat. 1000 levelbol 750 levelet mar ez a par szabaly megfog.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
[0-9a-z]\.com
ez eleg tag!
t
egybetus domainek? Lehet vagy 50 belole.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
akkor hianyzik a ^
az anchorok (^$) automatikusan kerulnek minden sor elejere es vegere.
Igaz nem irtam, igy felreertheto volt. Bocs.
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
cn -t en is probaltam tiltani, de aztan jottek a panaszok, hogy a kinai bizniszeket nem tudjak letargyalni.
--
HUP te Zsiga !
es angolul vagy kinaiul targyaltak a bizniszt?
Nalam a spamek 98%-at kina adja.
(ha qq.com, 168.com-ot kiveszem, akkoris a 30%-at kb.)
---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Nálunk egy ügyfél jó ötletnek tartotta, hogy xyz domainról levelez.
Azért az utolsó előttin gondolkodj el. Most némi tűnődéssel 3 is eszembe jutott, ami teljesen valid:
hp.com - szerintem nem kell magyaráznom
ti.com - Texas Instruments
mi.com - ez meg ugye a Xiaomi-hoz tartozik
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Sziasztok!
Most az ünnepek közeledtével nagyon rákapcsoltak a magyar spamküldők, nekem a tegnapi napon több száz ment át úgy, hogy nem szűrte le a SpamAssassin. Először én is domain név végződéseket és egy csomó .com-os domaint leszűrtem, de ez már nem elég, sikerül nekik mindig új domaint használni. Viszont észrevettem a spamküldők rémálmát: egy pár karakteres ismétlődést, ami minden ilyen SPAM-ben benne van!
Ez egy Content-Type: multipart/alternative; header, annak is a boundary részében: b1_ a véletlen számsor előtt. Valószínűleg a spamküldő programja használja és mindig benne van a fejlécben és a levél további részében a body egyes részeit előzi meg.
Akinek eddig nem sikerült 100%-osan szűrni ezeket a kéretlen leveleket, állítsa be a szerveren használt szűrőt, én a SpamAssassint így állítottam be:
header HUN_SPAM Content-Type =~ /boundary=b1_/
score HUN_SPAM 20.0
Eddig mindegyiket megfogta. Természetesen ha változik a kód, akkor ez megint nem lesz elegendő, ezért jók azok az intézkedések, amiket már itt leírtatok. Visszanéztem pár hónapot és abban is benne van ez a pár karakteres ismétlődés, úgyhogy remélem az ünnepeket át lehet majd a fentebb taglalt spamszűréssel vészelni.
Üdv: m.gyorgy
Respect
Szemfüles vagy, hogy észrevetted! Szeptember óta 5500 spamet fogott volna meg. Remélem a küldő írója nem olvassa ezt a fórumot.
Hát, remélem nem :)
Köszönöm, ez nálam is benne van a spamban.
"https://hunvagyok.hu "
nincs mit!
Bingó!
Köszi, ezt is beépítem, bár én mostanában arra álltam rá, hogy komplett /24-eket blokkolok. Illetve első körben átirányítom valahova, hogy ömlik-e onnan az áldás, ha pedig igen, akkor megy rá a reject. Ha ugyanabból a /16-ból már tiltottam pár /24-et, azaz sanszosan egy spammerbarát szolgáltató tartománya, akkor ez az ellenőrző szakasz ki is maradhat. Ismert spammer másodszintű domain-eket is gyakok regexp-pel
A /24 blokkolása időnként overkill rászoktam keresni a logban, hogy hány mail jön a /24-ből és gyakran csak 16 vagy 32 cím érintett, ilyenkor kisebb tartományt dobok ki. Könnyen lehet, hogy valami VPS-ből küldözgeti a spammer és egy miatt nem akarom kidobni az ártatlan szomszédokat is. Finomítja a dolgot, hogy üzenettel dobom vissza a levelet, valami ilyesmit írok: REJECT Spam from your IP range x.y.z.0/25
Így ha felüti ott a fejét valaki akinek fontos, hogy átmenjen a levele tudja, hogy kit kell megrúgni.
Van egy eléggé publikus email cím is nálam, amire ömlenek a spam-ek, az erre levelet küldeni próbáló, reject-elt címeket átfutom legalább naponta. Nem találtam még köztük legitimet.
Sziasztok ismét!
Javítottam a kódon, észrevettem, hogy kettő levél átcsúszott a szűrőn, de csak azért, mert ott szabályos módon idézőjelben van a boundary-ban található szöveg:
header HUN_SPAM Content-Type =~ /boundary="?b1_/
Remélem nektek is úgy szűri, mint nálam, nekem két postafiókban a mai napon eddig 310 levelet fogott meg!
Egy kérdés: előző hozzászólásomban ki tudom javítani, vagy csak veteránok tudnak belejavítani a már elküldött hozzászólásaikba?
Üdv: m.gyorgy
Igen hatékony a szabály, de utánanéztem, hogy honnan származik a jelenség.
Úgy néz ki, hogy ezzel minden olyan levelet elkapunk, amit a PHPMailer osztállyal küldtek. (Google:"b1_" . $uniq_id;) A legújabb forrásban is benne van a https://github.com/PHPMailer címen.
Használja ezt valaki a spamküldésen kívül másra is? Ha igen akkor ki kellene találni legalább még egy ismérvet a magyar spamekre.
Mintha a Moodle azt használná, de azért ezt valaki megerősíthetné / cáfolhatná.
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Szia, igazad van, már nálam is elfogásra került hiteles levél így a mai nap folyamán :( ! Igaz csak egy.
A levelek forráskódjában észrevettem még egy egyedi vonást: minden linkben van kettőspont! Az általam vizsgált levelekben javarészt idézőjel nélkül szerepelt a boundary, úgyhogy kivettem, talán ez is segít felderíteni, hogy SPAM-el van-e dolgunk.
Az óvatosság kedvéért a következő meta szabályt készítettem a SpamAssassinben:
header __HUN_SPAM_HEADER Content-Type =~ /boundary=b1_/
uri __HUN_SPAM_URI /\:/
meta HUN_SPAM (__HUN_SPAM_HEADER && __HUN_SPAM_URI)
score HUN_SPAM 5.0
score URIBL_ABUSE_SURBL 5.0
Észrevettem, hogy általában már felkerült egy DNSBL-be az abuse link, amit használnak, úgyhogy erősítettem a pontozását az URIBL_ABUSE_SURBL-nek.
Még tesztelés alatt van, írok, hogy sikerült-e így elkapni a magyar SPAM-eket!
Üdv: m.gyorgy
Szia MGy! Sikeres, megfogta a leveleket a módosított szabály!
Üdv: m.gyorgy
Szuper.
Kipróbálom ezt is. Nálam az idézőjeles változat is nagyon sok spamben benne van - valószínű PHPMailer verziótól függ a mostani kiegészítéseddel szinte biztos, hogy nem fog meg valódi levelet.
A __HUN_SPAM_HEADER név lehet kissé félrevezető, én az idézőjeles változatodat raktam be __PHPMAILER_HEADER néven így egy esetleges olvasó jobban látja mi a helyzet. (Bár a local.cf egyelőre csak nekem érdekes olvasmány :-) )
Szia!
Azóta én is visszaraktam az idézőjelet :) úgyis két feltételnek kell teljesülnie, és ha van link, amiben kettőspont van, akkor mehet a levél SPAM-be.
Eddig elég jó hatékonysággal működik, amint van módosulás a SPAM kódjában, újra jelentkezem!
Üdv: m.gyorgy
Szia MGy!
Az általam leírt uri szűrő SPAM-nek jelöli a computerworld.hu-ról érkezett hírleveleket is, így a következőképpen finomítottam:
uri __HUN_SPAM_URI /\/[a-z]{3}\:/
Ez figyeli azt, hogy a / jel után három karakter következik és utána jön a kettőspont a linkekben, egyelőre így lehet a legjobban beazonosítani a magyar spameket.
Teszteltem és úgy néz eddig jól szűr.
Üdv: m.gyorgy
Szerintem baromi sok helyen használják a PHPMailer-t legitim célra is. De a kettőspontos mókával együtt remélhetőleg működni fog.
Köszönjük a konstruktív hozzászólást, spammer kollégáimmal javítottunk a hatékonyságon.
Puszi
a Viagra kommandó
:)
:D
:)
a From: domainjet kell megnezni mert az mindig ugyanarra az IP-re mutat ezeknel. en a sajat greylist szuronkben fogom meg ez alapjan, de itt a HUP-on valaki irt mar spamassassin plugint is erre...
szerk: asszem ez az: https://github.com/szenti/spamassassin-from-domain-check
Köszi, megnézem!
Én is ajánlom tartalom szűrés előtt kiszűrni ezeket, de a deepspam is kiszűri gyakorlatilag az összeset.
https://hup.hu/node/165957
Együtt a kettővel pedig biztosra lehet menni.
De örülök, hogy még mindig sokan megkapják azt a sok spamet, mert addig nem változtatnak a küldésen, minket meg nem zavar.
helo_access:
/\.info$/ REJECT 550 "Spammer domain!"
/\.icu$/ REJECT 550 "Spammer domain!"
/\.top$/ REJECT 550 "Spammer domain!"
/\.xyz$/ REJECT 550 "Spammer domain!"
/\.kim$/ REJECT 550 "Spammer domain!"
Egyébként egy jól tanított spamassassin db kell, nekünk nagyon jó hatékonysággal szűr.
"Sose a gép a hülye."
jon az .com es .co veggel is...
OK, de azt kiszűri nagyrészt a spamassassin. Viszont ezekről kizárólag spamek jönnek.
"Sose a gép a hülye."
Nem gyakori, de a .info-s címről szokott ham is érkezni.
nekem is volt olyan magyar ceg ugyfelem akiknek info-s domainjuk van... de ritka.
Nekünk van ügyfelünk az xyz domainből.
+ .ninja TLD
mit kepzeltek ezek?! :)
lol, köszi, felvettem.
"Sose a gép a hülye."
Rspamd a király, de a Neural network modult MINDNEKÉPPEN kapcsold ki, mert a jelenlegi verziókban 2.x vagy nem csinál semmi hasznosat, vagy összeomlasztja az rspamd szolgáltatást.
Ha már hiba, akkor nálam az R_MIXED_CHARSET értékét kellet 0-ra állítani, mert különben az összes ékezetes tárgyú levelet felpontozta...
Ez az 1.9-es branch óta van... Ha lesz kis időm a következő napokban, akkor be is fogom jelenteni hibára...
Debian Linux rulez... :D
RIP Ian Murdock
Ha már hiba, a multimappal kezelt fekete, fehér listákat néha nem veszi figyelembe. Még nem volt idő utánanézni részletesen, de gyanús, hogy tényleg hiba lehet.
erdekessegkeppen, az elmult 1 honap spam termese ugyanattol a bandatol (from domain ip-je szerint szurve), tokenizalva, sorbarendezve:
http://thot.banki.hu/deepspam/magyarspam201912.txt
171255 db jott eddig, ez deduplikalva lett 70128 sor... szoval elegge valtozatos a szovege, de elnezve ugy csinalhatjak, hogy mondatonkent/kifejezesenkent tobb variaciot adnak meg es ezt random permutalja a kuldo szoftveruk.
jol nez ki:)
Olyat is tud a programod, hogy egyertelmuen megmondja mi a level fo nyelve (kinai, angol,magyar)?
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
miert tudna? nekem nincs ra szuksegsegem. de amugy ez eleg jol mukodik:
https://fasttext.cc/docs/en/language-identification.html
köszönöm.
Peldaul azert johet jol, amikor biztos vagy benne, hogy egy account nem kaphat adott nyelven ham levelet (pl. kínai) igy azok 100%-kal mehetnek a spam trainingbe.
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
spamassassin nagyon reg tud ilyet... (ok_languages parameter user_prefs-ben ha jol emlexem)
de amugy semmi ertelme:
- egyszerubb kodlap, karakterkeszlet, forras IP cim (geoip) alapjan szurni ezeket
- a kinai spamek 99%-a ugyis angol nyelvu (bar elegge googletranslate-szeru), ha kinaiul irnak europai cimre annak altalaban oka van (pl. az ham)
- ha kiszurod a 126.com, 163.com es qq.com domaineket akkor a kinai spammek 99%-at kiszurted :)
- en nem szeretem a per-user beallitasokat, globalisan pedig egy tobb 1000 fos cegnel mindig van valaki aki kinaiakkal levelezik :)
- sok olyan levelet lattam, ahol a tartalom fele pl. magyar a masik fele angol, vagy tetszoleges masik 2 nyelv fele-fele aranyban. ezekkel mit kezdesz? a legtobb language detector is elverzik a kevert szovegen, bar a fentebb linkelt fasttext-es egesz jol megadja %-osan a nyelvek aranyat.
- egyre tobb idegen szot, kifejezest, idezetet hasznalunk, kulonosen a szaknyelvi levelezesben (legyen az IT, oktatasi, orvosi stb)