Postfix spam szűrés - smtp_melyik_restrictions

Linux-haladó

Sziasztok!

Spam szűrésnél postfix esetében az smtpd_xxx_restrictions közül melyiket érdemes használni a leghatékonyabb eredmény elérése érdekében?

Itt pl.: http://www.akadia.com/services/postfix_uce.html azt javasolják, hogy rakjuk a megszorításokat az ellenőrzés során minél hátrébb, azaz az smtpd_recipient_restrictions részhez, hogy minél több infót tudjunk beszerezni/eltárolni a levélről.

Elvileg sorrendben így jönnek egymás után:

smtpd_client_restrictions =
smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_recipient_restrictions =

Bár a leírásból számomra pont az nem derül ki pontosan, hogy mit is tárolunk el és hogyan, amitől nekünk végül jobb lesz.

Vélemények? Melyikhez érdemes pakolni és miért?

  • 2585 megtekintés

( eyez00 | 2010. 01. 17., v – 22:04 )

Ott a tuti, ennek a végén: http://www.posluns.com/guides/maincf.html

Note: The RBL and RHSBL checks have been removed from the end of this list, as they should all be performed by SpamAssassin. You may choose to reject all emails that are listed in an RBL or RHSBL, though weighted scoring systems have proven to reduce the number of false positive rejections. Note that using SpamAssassin instead of rejecting directly in main.cf will increase your system load as the full email will need to be accepted and analyzed instead of simply rejecting the email as soon as a matching header (IP or domain name) is caught.

Kérdés, hogy azért, hogy legyen jó okos spam szűrőm, terheljem is sz.rrá?

Egy nem is túl nagy forgalmú rendszerrel, kapok átlagosan 2 másodpercenként egy-egy újabb kapcsolatot, az elemzés viszont jóval tovább tart, ez alapján lassan, de biztosan kifeküdne az egyre növekvő számú process-ektől.

Esetleg attól, hogy okosodik, gyorsabbá válik az elemzés is?

( ilkb | 2010. 01. 18., h – 00:10 )

subscribe
--
Bazsi
Ma is holnap fekszünk le, mint tegnap...

( dragi v | 2010. 01. 18., h – 08:27 )

Nekem igy van a sorrend es eddig jól müködik.
Ha megnézzük, a client restriction azért kell előre, mert ha sasl-el authentikál vagy egyéb módon beengedem, akkor már nem kell a többi ellenőrzés. Illetve ott már a küldő címe fentakadhat a rbl listeken.
A helo meg azért jó ez után, mert ha már a behelozó domain nem jó akkor szintén el lehet dobni, és a helo az első lépés. Így a végére marad a recipient, illetve oda jön még a postgrey, ami a követkető kapu a spam szürő előtt.

smtpd_delay_reject = yes

smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_client_access hash:/etc/postfix/maps/client,
reject_unauth_pipelining,
reject_unknown_client,
reject_unknown_client_hostname,
reject_rbl_client bl.spamcop.net,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client list.dsbl.org,
reject_rhsbl_sender dsn.rfc-ignorant.org,
permit

smtpd_helo_required = yes
smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_helo_access hash:/etc/postfix/maps/helo,
reject_invalid_hostname,
reject_non_fqdn_hostname,
reject_unauth_pipelining,
permit

smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unauth_destination,
reject_unauth_pipelining,
reject_invalid_hostname,
reject_unknown_recipient_domain,
check_sender_access hash:/etc/postfix/maps/sender,
check_recipient_access hash:/etc/postfix/maps/recipient,
check_policy_service inet:127.0.0.1:60000,
permit

Szerintem max 1-2 listat erdemes hasznalni (pl zen-nel en nagyon megvagyok elegedve).
Greylist-ezni szerintem bizonyos levelmennyiseg felett nem erdemes mivel szerintem jobban megfogja a gepet, mint 1-2 listat lekerdezni.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Nincs mérési eredmény a zsebemben, de a greylist miért fogná meg?
Első körben visszapattintja és ha már elégszer látta, akkor beengedi.
Semmi elemzést nem is csinál, csak (gondolom) valami adatbázisból előkotorja az eredményt.

RBL listából sztem érdemes többet is használni.

Nálam egy szürke hétköznapon ilyesmi statisztika szokott összeállni:

Connections: 41921
Rejected: 33490
Helo command rejected: 11276
Helo rej - non-fqdn: 4843
Helo rej - not found: 4187
Helo rej - SMTP pipelining: 5
Blacklisted: 22201
Bl - sorbs.net: 4950
Bl - spamcop.net: 14462
Bl - abuseat.org: 2729
Bl - rfc-ignorant.org: 60
Bl - ahbl.org: 0
Greylisted: 24435
Passed greylisting: 491

(Itt valahogy a spamhaus nem akar működni, bár megfelelünk a free use feltételeinek, mégis RBL lookup error-t dob)

Szerintem a greylist adatbazisat valahol tarolni kell. Ha megnovekedik ez az adatbazis nagyon nagyra (mondjuk 40k szerintem eleg sok), akkor szerintem tobb eroforras kell neki, mint egy rbl lekerdezesnek.

-------------------------------
“The 0 in Raid 0 stands for how many files you’re going to get back if something goes wrong” :)

Mar miert lenne sok 40k rekord? Jo implementacionak ez nem problema. Ha en irnek most egyet, akkor az vagy sql-ben tartana, vagy memcached-ben + lenne egy text file azokkal, akiket semmikeppen nem farasztunk 'temp fail'-lel.

Tesztelgettem feketelistakat (foleg surbl, uribl), es ha volt a levelben 3-5 url, akkor fajdalmas masodpercekig kellett varnom, mire minden valasz visszaert.

Masfelol, magyarazza mar el valaki, hogy mit kezd az rbl-ek okozta fals pozitiv hibakkal? Mert jo latni azokat a gyonyoru statisztikakat, hogy hany levelet dobtunk el egy 3rd party utasitasara, de attol tartok, arrol senkinek sincs otlete, hogy hany legitim level veszett igy el...

Greylisting + szabvanyos smtp kliens eseten ilyen nem fordulhat elo.

SPAMtelenül - MX spamszűrő szolgáltatás, ahogyan még sosem próbálta

Nekem a client részhez lenne kérdésem! Ha permit_mynetworks és permit_sasl_authenticated el indítok, valamint felveszek pár reject_rbl_client bejegyzést, akkor is sorban történik a feldolgozás? Másképp feltéve a kérdést. Kifilterelt IP-ről lehetséges-e sasl auth, avagy nem?

Mindig sorban történik a feldolgozás. Ha a permit előbb van mint a reject akkor a permit fog érvényesülni.
Kifilterelt IP-ről lehetséges-e sasl auth, avagy nem?
Is-is. Bizonyos fajta szűrésekből lehet több is. Pl. regexp-el meg tudod szűrni a problémás klienst még azelőtt, hogy bármi történne vele... Vagy fordítva, átengedni is át tudod annak ellenére, hogy mondjuk valami rbl listán szerepel.
Ha ezt:
http://hup.hu/node/81673#comment-934249
megnézed check_recipient_access kétszer is szerepel, nem véletlenül...

Mik

( 3xtati | 2010. 01. 18., h – 08:44 )

+subscribe
____________________
Ha igen akkor miért nem...
Linux 2.6.30-gentoo-r4 i686 Intel(R) Core(TM)2 Duo CPU E6550 @ 2.33GHz GenuineIntel GNU/Linux

( Mik v | 2010. 01. 18., h – 09:34 )

smtpd_client_restrictions =
smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_recipient_restrictions =

ez mondjuk egyértelmű, mivel ha küldesz egy levelet, akkor az információk ebben a sorrendben érkeznek.
Az, hogy ezeken belül mit-hová teszel már rendszerfüggő, testreszabást igényel.
Nálunk így néz ki: 


smtpd_client_restrictions =
smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_recipient_restrictions =
 check_recipient_access hash:/etc/postfix/access/recipient_access_geza,
 check_client_access hash:/etc/postfix/access/client_access,
 permit_sasl_authenticated,
 reject_unauth_destination,
 check_helo_access hash:/etc/postfix/access/helo_access,
 check_sender_access hash:/etc/postfix/access/sender_access,
 check_recipient_access hash:/etc/postfix/access/recipient_access,
 reject_unlisted_recipient,
 reject_unknown_client,
 reject_multi_recipient_bounce,
 reject_rbl_client bl.spamcop.net,
 reject_rbl_client dnsbl.sorbs.net,
 reject_rbl_client sbl.spamhaus.org,
 reject_rbl_client sbl-xbl.spamhaus.org,
 reject_rbl_client zen.spamhaus.org
 reject_rbl_client dnsbl.dronebl.org
 reject_rbl_client combined.njabl.org,
 reject_rhsbl_client rhsbl.sorbs.net,
 reject_rhsbl_sender rhsbl.sorbs.net,
 reject_non_fqdn_hostname,
 reject_unknown_hostname,
 reject_invalid_hostname,
 reject_non_fqdn_sender,
 reject_unknown_sender_domain,
 reject_non_fqdn_recipient,
 reject_unknown_recipient_domain,
 reject_unauth_pipelining,
 check_policy_service inet:127.0.0.1:60000,
 permit

Hogy miért pont így? Az évek alatt ez vált be. Az elején ottvannak a megengedő szabályok, aztán a szűrések. A problémás ügyfeleknek meg ott a könnyített szabály: 


permit_spam =
 permit_mynetworks,
 permit_sasl_authenticated,
 reject_unauth_destination,
 reject_unlisted_recipient,
 check_helo_access hash:/etc/postfix/access/helo_access,
 reject_multi_recipient_bounce,
 reject_unknown_sender_domain,
 reject_non_fqdn_sender,
 reject_unauth_pipelining,
 check_policy_service inet:127.0.0.1:60000,
 permit

Szóval ezzel lehet és kell is játszani. Lognézés, felhasználok meghallgatása, lonézés, felhasználok meghallgatása, lognézés...

Visszatérve a fenti linkhez, mely szerint:

While it can be a good idea to restrict / reject specific types of messages as early as possible (a helo based restriction in the smtpd_helo_restrictions section), by placing all of the restrictions into the smtpd_recipient_restrictions, you will be able to accumulate as much information about the attempted spam as possible, as well as order all of the restrictions to better allow you to prevent spam - therefore we suggest to leave the client, helo and sender rstriction level empty.

amely alapján

The RBL and RHSBL checks have been removed from the end of this list, as they should all be performed by SpamAssassin. You may choose to reject all emails that are listed in an RBL or RHSBL, though weighted scoring systems have proven to reduce the number of false positive rejections. Note that using SpamAssassin instead of rejecting directly in main.cf will increase your system load as the full email will need to be accepted and analyzed instead of simply rejecting the email as soon as a matching header (IP or domain name) is caught.

Esetleg működik valakinél ilyen rendszer is?

Mert végülis valóban lehet azzal sakkozni, hogy melyik restriction-hoz rakom, de végülis bármelyikhez rakom is, (ha jól tudom) mindegyik a Spamassassin _előtti_ ponton utasítja vissza a levelet.

És azt a bizonyos fennt is kiemelt 'eltárolás' részt végülis csak az SA tudja megvalósítani, nem? Én legalábbis ezt tippelem az 'accumlate' lehetőségnek, de pont ezért dobtam fel a témát, hátha valaki már gyakorlatban is csinált már ilyet.

Tehát ha jól értem, akkor RBL-t Postfix-be pakolni kérdéses, hogy tényleg jó-e.

- Előnye: nincs a gép halálra terhelve olyan processálással, ami elkerülhető HELO, RBL, Greylist, ill. egyéb finomságokkal
- Hátránya: Egy csomó megtanulható spam-mal nem is találkozik az SA, mert el sem jutnak hozzá (nem lesz annyira okos, mint lehetne)

De a többi smtp_xxx_restrictions prioritást még mindig nem értem. Miért jobb úgy, ahogy pl a fenti példában mindent a recipient_restrictions-hoz raksz? Mit nyerünk vele, hogy hátrébb van?

Nem értettél meg. Nálam a smtpd_*_restrictions = után nem szerepel semmi, vagy ha úgy jobban tetszik nincs lezárva. Azért mert azt látod, hogy a smtpd_recipient_restrictions = után vannak felsorolva, az nem azt jelenti, hogy ott is futnak le! Mindegyik a maga helyén kerül elemzésre és az elemzésnek akkor lesz vége amikor a permit -hez ér. Ha megfigyeled a smtpd_*_restrictions = után és a permit után nincs vessző, a többi után van. Miért jobb így? Mert jobban átlátható és nem kell minden egyes új szabály esetén megnéznem, hogy akkor ez most melyik restrictions-hoz is lenne való, melyikbe tegyem bele?
Postfix is tud tárolni, lásd hold státuszú levelek, de amire te gondolsz az a spamassassin vagy amavis vagy valami hasonló lesz. És igen a Postfix az SMTP kapcsolat során szűr a Spamassassin meg utána. Vagyishát ez sem teljesen igaz, mert szűrhet akár before-queue is, de ez már odafigyelést igényel...
Szóval olvasgass még, meg próbálgasd :)

OK, ez mondjuk nekem új volt, hogy szétdobálja értelemszerűen, de jobban megnézve a különböző restriction-ok lehetséges értékeit, elvileg valóban meg van, hogy melyik mit kajál meg --> valószínűleg tényleg mindegyiket ott értelmezi, ahova való, különben feltűne, hogy nem működik :-)

Nyított kérdés maradt ez az accumlate dolog, de akkor méregetek egy kicsit, hogy mennyire jó dolog keresztüldarálni mindent az SA-n és csak aztán visszarúgni.

Végülis a spamszűrő szerver kizárólagos célja a spam szűrés, és nem baj, ha folyamatosan ki van terhelve, _HA_ nem zuhan ettől össze _ÉS_ van értelme is a sok számolásnak (értsd: sokat tanul és nagyon okos lesz)

( eyez00 | 2010. 01. 19., k – 00:47 )

Az eredeti topic-ból kiindulva, gondoltam karanténozzunk amavisd-new-val.

Benyomtam ezeket a /etc/amavis/conf.d/50-user -be, de nem akar menni.

$final_spam_destiny = D_DISCARD;
$spam_quarantine_to = 'spam@';
$sa_tag_level_deflt = undef;
$sa_tag2_level_deflt = 5.0;
$sa_kill_level_deflt = 5.1;
$sa_quarantine_cutoff_level = undef;

Bár spam szűrő szerver az akarmi.com-ra nézve (értsd: transport_maps) + a local delivery a mail.akarmi.com-ra működik (kívülről-belülről) mégsem forward-olódik a spam@mail.akarmi.com címre a spam, akarhogy adom meg neki.

Doksi szerint:

#$virus_quarantine_to = 'infected@'; # forward to MTA for delivery
#$virus_quarantine_to = "virus-quarantine\@$mydomain"; # similar
#$virus_quarantine_to = 'virus-quarantine@example.com'; # similar

(most hogy virus vagy spam az mindegy, a szintaxis ua.)

Letiltom psotfix-ból az RBL-eket és a greylist-et, szépen kiszámolja a score-t az SA, aztán gyönyörűen továbbítja a spam-ot a címzettnek a transport alapján, mintha a falnak beszélnék a fenti opciókkal.

Mit rontok el?