postscreen crash course

a spammerek ellen smtp szinten is be lehet vetni par trukkot. Itt szoba kerult a 220-as banner kesleltetese 3 masodpercre, ami szepen megfog par zombi gepet. Ez amugy szep is, de nem igazan hatekony, mert a postfix smtpd processzek is igy pontosan 3 sec-cel tovabb lesznek farasztva.

Megoldas szerencsere van: a postscreen. Ez a postfix 2.8-as verziojatol kezdve talalhato meg benne. A celja roviden: 1 processz segitsegevel vegezzuk a kliensek teszteleset, farasztasat, igy az smtpd processzek a postscreen-en mar atjutott smtp klienseket epp olyan szelves szebesen tudjak kiszolgalni, mint azelott.

Reszletes leiras a postscreen doksijaban http://www.postfix.org/POSTSCREEN_README.html talalhato, itt egy gyakorlati felhasznalast osztok meg veletek.

!FONTOS! A postscreen nem a sajat klienseid ellen van, akiknek relay-zel.

Eloszor is nem akarjuk, hogy mindenkit farasszon a postscreen, igy megadhatjuk, hogy kiket kimeljunk meg tole, es amint lathato blokkolhatunk is cimeket, ill. cimtartomanyokat is:


postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr

/etc/postfix/postscreen_access.cidr:

1.2.3.4 permit
10.20.30.0/24 permit
173.230.154.240 reject # myzamana bajkeverok

A kovetkezo trukk azt hasznalja ki, hogy a zombik olyanok, mint a microsoft: nem kulonosebben torodnek az rfc-kkel. Igy amint meglatjak a 220-as bannert, mar sietosen is folytatjak az smtp parbeszedet. Ez ellen ved a greet teszt: a 220-as bannner 2 sorban adja ki, es a ketto kozott egy megadott ideig kesleltetes van, kb. igy:

220-Hello pajti, ne siess mar ugy...

220 ESMTP ....

Ha az smtp kliens nem varja ki, amig a "220 " resz (azaz a vege) is megjon, akkor rfc-t sert, azaz tuti spammer

A konfig reszlet:


postscreen_greet_action = enforce
postscreen_greet_wait = ${stress?2}${stress:4}s
postscreen_greet_banner = Hello pajti, ne siess mar ugy...

Erdemes a stress opciot is figyelni: normalis korulmenyek kozott 2 sec a kesleltetes, de nagy load (="stress") alatt mar 4 sec.

A postscreen tamogatja a feketelistakat, meghozza nagyon intelligens modon. Tudjuk, hogy az rbl-ek hasznalata veszelyes, mert mi van, ha "veletlenul" felkerul ra pl. egy artatlan? Megesik az ilyen (uceprotect, emlekszel ra?). Ezert a feketelistakhoz sulyt is lehet rendelni:


postscreen_dnsbl_action = enforce
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_sites = rbl.aaa.fu*1,rbl.bbb.org*1

A fonti peldaban csak akkor dobja el a kapcsolatot a postscreen, ha a kliens mindket rbl-en rajta van. A postscreen tamogatja a feherlistakat is (negativ suly), igy a baratsagos kuldoket fel lehet ra venni:


postscreen_dnsbl_threshold = 2
postscreen_dnsbl_sites = rbl.aaa.fu*1,rbl.bbb.org*1,whitelist.bribe.me*-1

Ebben az esetben hiaba listazza akar 2 rbl is a baratunkat, mi beengedjuk, mert feherlistan is szerepel. A sulyok okos varialasaval az is elerheto, hogy a feherlista csak 1 rbl-tol mentse meg a kuldot, es ha tenyleg elpofatlanodik, es spammelni kezd, mivel ekkor eleg sok rbl-re felkerul, akkor mar mi is eldobjuk a leveleit.

Az egesz egyutt, a vegen meg 2 kisebb hatekonysagu (=kevesebb spam akad fenn rajta) teszt:


postscreen_access_list = permit_mynetworks, cidr:/etc/postfix/postscreen_access.cidr

postscreen_greet_wait = ${stress?2}${stress:4}s
postscreen_greet_banner = Hello pajti, ne siess mar ugy...
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_sites = rbl.aaa.fu*1,rbl.bbb.org*1

postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce

postscreen_pipelining_enable = yes
postscreen_non_smtp_command_enable = yes

Meg egyeb melyteszteket is tud a postscreen, a tobbiert ld. a doksit. Szoval a postscreen szep, a postscreen jo, mert kis eroforrasigennyel megfog smtp szinten sok spammert. Nyilvan nem mindet, foleg, miota a spammerek egyre inkabb felfedezik a vps-eket, ahonnan smtp szerver kuldi ki a szemetet, igy elfer a postscreen mogott egy tartalomszuro*, amivel jol kiegeszitik egymast.

*: ha meg nincs ilyened, ajanlhatok neked egy tutit :-)

Hozzászólások

Es sajnos a spammerek egyre ugyesebbek is, vagyis ovatossan kell kezelni a SPF/DKIM rekordok megletet is, nem szabad tul nagy sullyal szambavenni oket.

Amit akartam meg kerdezni: ilyenkor erdemes lehet kivenni az smtpd_client_restrictions -bol a permit_mynetworks-ot is? Hiszen ahhoz a szinthez a postscreen mar elvegzi a validaciot...
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

vagyis ovatossan kell kezelni a SPF/DKIM rekordok megletet is, nem szabad tul nagy sullyal szambavenni oket.

igen, mar csak azert is, mert szerintem nem igazan terjedtek el olyan mertekben, mint ahogyan azt vartak az elejen. Ill. azt is jo eszben tartani, hogy ezek elsosorban a domain hamisitas ellen lettek kitalalva. Igy az semennyire nem jelzi, hogy spamrol van szo, ha hianyzik az spf/dkim.

Meg aztan az spf-nek van 1-2 flaw-ja is, amiert tobben nem is javasoljak, de a dkim mentes ezektol a hibaktol, azt inkabb, ha varhato, hogy hamisitanak a domainneved a From: cimben, pl. foleg penzintezetek. Mondjuk az foleg fun, hogy a spammerek voltak az elsok, akik korrekt spf es dkim rekordokat hasznaltak :-)

ilyenkor erdemes lehet kivenni az smtpd_client_restrictions -bol a permit_mynetworks-ot is? Hiszen ahhoz a szinthez a postscreen mar elvegzi a validaciot...

(meg nem probaltam), de azt nezd meg, hogy atjutnak-e a legitim klienseid (akiknek relay-zel) a megmaradt smtpd_client_restrictions felteteleken? Az smtpd ugyanis (imho) nem tud arrol, hogy mit muvelt a postscreen, hanem az smtpd processz csak azt latja, hogy jott egy kliens, akit vegigellenoriz pl. az smtpd_*_restrictions listakon.

Miert kell nekem sajnalnom a Klubradiot?

"rfc-t sert, azaz tuti spammer"
ezt ugye azert te se gondolod komolyan? ertem en, hogy 99,999999, de nem tuti.
Foleg, hogy kesobb meg pont azt magyarazod, hogy a spammerek voltak az elsok, akik korrekt spf es dkim rekordokat kezdtek hasznalni. Nyilvan kb ugyananyi esellyel, ha mindenki az rfc-sertes alapjan zarja ki a masikat, akkor a spammerek robotjai is szepen szabvanyosak lesznek. (En speciel csodalkozom, hogy meg nem azok.)
(nem nekemugrani, vedd sub-nak)

Azert nem szabvanyosak, mert meg mindig tobbmillio levelet kell kezbesiteni. Legalabbis, akik iparszeruen uzik ezt a.. khm... "szakmat". Egyszeruen tul sok idot venne igenybe a szabvanyos kezbesites. Az SPF meg pl. semmi idot nem vesz igenybe, hiszen az azt a cimzett feladatata ellenorizni.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal 

"Azert nem szabvanyosak, mert meg mindig tobbmillio levelet kell kezbesiteni. "
Erre elfelejtettem reagalni. Muti meg az RFC-ben, hogy nem-szabvanyos dolog tobbmillio levelet kezbesiteni.

Mast ne mondjak, cubieboard.org -on azt irjak, ha akarok a kovetkezo szallitmanybol rendelni (mert az elso mar el is fogyott), iratkozzak fel a hirlevelukre. Szerinted ha mondjuk a t-home haloozatabol csak par ezer user jelentkezik, akkor ok szabalyosan kuldenek-e levelet a par ezer usernek, vagy nem? Most csereljuk ki a t-home-ot gmail.com -ra, es lehet maris nem tobb ezer, hanem par millio (nyilvan en se hiszem, de elvben probaljuk egymast ervekkel meggyozni) usernek kell irniuk. Ha vegre lenne RFC arra, hogy hogy mennyi level elkuldese szamit spam-szeruen soknak, akkor ez nem lenne vita. Amig ilyen nincs, addig legfeljebb jol bevalt (vagy nem annyira jol bevalt), tapasztalati uton szerzett velemenye es beallitasa lehet mindenkinek - de nem jelentheto ki kategorikusan, hogy spammer, csak mert "sok" levelet kuld.

Erre elfelejtettem reagalni. Muti meg az RFC-ben, hogy nem-szabvanyos dolog tobbmillio levelet kezbesiteni.

felreertetted. Nem arrol van szo, hogy tobb millio levelet nem szabvanyos kuldeni, hanem mivel a spammerek sok millio levelet akarnak rovid ido alatt elkuldeni ezert nem torodnek az rfc-kompatibilis mukodessel (pl. vard meg a 220-as banner veget is)

Miert kell nekem sajnalnom a Klubradiot?

hrgy84 mar nagyjabol leirta, en meg annyit tennek hozza, hogy az spf/dkim egy dolog, az smtp parbeszed rfc-kompatibilis vegrejatasa meg egy masik. Az elobbi opcionalis (meg akkor is, ha esetleg ezekrol is van rfc, nem tudom), mig az utobbi kotelezo, mert csak igy biztositott, hogy a kulonbozo rendszerek egyutt tudnak egymassal mukodni. Ezert ma az MTA-k 100.00%-a teljesiti ezeket, es nem akadnak bele a pregreet tesztbe. A MUA-k pedig nem is erdekesek ez ugyben, mert azok ugyis a lokalis relay-t hasznaljak. Szoval en nehezen tudok elkepzelni olyan legitim szituaciot, hogy ezt a lecet ne lehessen megugrani...

Miert kell nekem sajnalnom a Klubradiot?

Majd kijavit az, aki szazas nagysagrendben uzemeltet mail-szervereket, de ugy remlik eleg sok helyen olvashato olyasmi (levelezoszerver doksijaban, FAQ-jaban, forrasaban, stb - nem emlekszem), hogy ezt vagy azt azert csinaljak igy, mert a nem-teljesen szabvanyos X / Y vagy Z szoftver miatt igy kell csinalni az egyuttmuodes mian. De hogy mondjak olyan konkret peldat is amit nyugodtan meg lehet cafolni:


ehlo 127.0.0.1

a 2821-ees RFC szerint - az en ertelmezesemben - teljesen szabalyos, de ennek ellenere hallottam mar embert k anyazni miatta. De mast mondok, remlik, hogy van par olyan antispam technika, ahol gyakorlatilag a szerencsetlen fogado fel az, aki nem-szabvanyos modon dolgozik. A fenti kiteteled alapjan ebben a pillanatban az adozat maris spammer :-)
Szoval kiemeles tolem: *szerintem* az nem igaz, hogy aki nem 100-ban szabvanyos, *az* 100%-ban spammer.

Ha a gépem neve a qtyuli.domainem.hu, és valaki a nagyvilág felől *.domainem.hu -val helózik, vagy a szerverem bármelyik ip-címével, vagy netán privát ip-vel, az alapból menjen a levesbe, mert hazudik. Ha nem oldható fel a helo/ehlo után küldött név, akkor meg célszerűen kap némi várakozást, meg spamszűréshez néhány rosszpontot.

mit csinalsz, ha en helo utan a gmail n+1-dik nevet adom vissza? Feloldhato? Igen. Rossz pontot adsz? Mi alapjan? Ha meg hazudik is (pl. privat IP, bar imho ez inkabb rossz beallitas), akkor is esznel kell lenni, nehogy jo levelet esz nelkul eldobjon az ember. En mondjuk pont ezert sem vegzek helo ellenorzest, inkabb a tartalmat nezem, ami viszont nem hazudik.

Miert kell nekem sajnalnom a Klubradiot?

Jogosan anyáztak, mert a 127.0.0.1 az a szerver, ahova kapcsolódsz saját címe _is_. Ráadásul a 4.1.3-as pontot megnézve az ip-címet szerintem szögletes zárójelbe kéne rakni.
Alapból nem kell elhajtani az ip-vel "beköszönő" küldőket, de a szerver saját címével köszönőket minden gond nélkül. És a 127.0.0.1 is beleértendő. Szerintem...

Megneztem a 4.1.3-t. Baromi ciki, de a szoveges formaban emlegeti a szogletes zarojelet, ellenben a BNF-szeru leirasban en mar nem latom (ellenben latom IPv6 eseten). Ennyit a preciz RFC-krol.
A masik, hogy noha gyakorlatilag egyetertek veled, hogy az en nevemel/cimemmel ne akarjon jonni, de mutasd ezt meg az RFC-ben. Foleg, hogy az az o cime *is* :-)
Mint ahogy az egyeb nem-routolhato cimekkel is az a helyzet, hogy mvel az RFC-ben nem szerepel ezek kizarasa, sot ha jol tudom semmilyen modon nem hivatkoznak ezekre a cimekre, jogosan hasznalom, ha p. a szolgaltatomtol ilyen cimet kapok, es az szolgaltati szerzodesunk szerint megengedett kifele, SMTP-szerver fele meno forgalom, onnantol en jogosan kuldok 172.16.1.1-et (hogy most zarojelezem-e, az egy masik dolog).

Azert nehogy mar ne tudjal kitalalni magadnak valami myorigin nevet, mert sirva fakadok. Legrosszabb esetbe mondd azt, hogy zahybox.local, de nehogy mar pont a privat ip-det nyomasd. Nem veletlen, hogy a legtobb mailserver defaultja a hostname --fqdn parancsk kimenetet felhasznalni helo nevnek.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal