[SOLVED] -- postfix + kulso spamd szerver hogyan?

Linux-kezdő

Hello,

kinottunk egy olyan felallast, hogy postfix + spamd + amavis + clamav, mivel a spamd nagyon leterheli mar a szervert.
Talaltam valami olyan megoldast, hogy lehet allitolag kulso spamd szervert hasznalni, ha postfix-nek megadjuk a master.cf-ben, hogy:

smtp inet n - - - - smtpd
-o smtpd_proxy_filter=external_spamd_server_IP:PORT
-o smtpd_client_connection_count_limit=10

Tuloldalon megbeszeltem a spamd-vel, hogy figyeljen az adott interface-en es engedje kapcsolodni a szukseges host-ot.

Ez meg is felelne, a spamd kivetelevel a tobbit nem koltoztetnem szivem szerint.
Valamit csinal, de nem az igazi, sokat timeout-ol, recieving garbage hibakat is dob.

Mi lehet a hiba? Egyaltalan nagyon elszabott koncepcio ez?

Valakinek van ezzel tapasztalata? Nem igazan talalok errol jo leirast, sot leginkabb semmilyet nem talalok.

Koszi,

e0

  • 3889 megtekintés

( pero | 2008. 04. 14., h – 18:21 )

En a helyedben amavisra (feltetelezem ez amavisd-new) biznam a clamav es spamassassin hivogatast (igy nem kell spamd), es a teljes amavist attennem a masik gepre, igy nagyban egyszerusodik a problema
de ez csak tipp :)

( pero | 2008. 04. 14., h – 18:44 )

spamd-vel ugye csak a ~200kb-nal kisebb leveleket vizsgalod? ezzel sokat lehet sporolni...

( janoszen v | 2008. 04. 16., sze – 09:59 )

Ugye, nem csak spamd szűrést csináltok, hanem a bejövő kapcsolatoknál is szűrtök? Én ugyanis így szívtam meg, amikor rázuhant 30000 spam a szerverre, hirtelen hosszú lett a mailqueue és nem tudtam vele mit csinálni. Ezután betettem egy pár szűrést és hirtelen lecsökkent a queueban levő spamek száma.

Amit értemes szűrni:
- Aki nem képes rendes HELO-t küldeni, az ne akarjon levelezni.
- Akinek nincs reverse DNS-e az ne akarjon levelezni.
- Aki dinamikus IP-ről küld, az ne akarjon levelezni (á lá Spamhaus DNSBL).
Opcionálisan:
- Konkurens kapcsolatok max száma legyen megfelelően alacsony.
- Graylist, .hu domaineket whitelistelve
- fail2ban, aki spamet küldött, az pihen 10 percet.

Ezzel a setuppal nekem sikerül napi 20-30 ezer levelet röhögve feldolgozni, valszeg még sokkal több is menne, mert 5% a terhelés a vason.

az bonyolitja meg egy kicsit az eletet, hogy 'ateresztos uzemmodban' vagyunk:

transport_maps = hash:/etc/postfix/transport

abban pedig:

mydomain.hu smtp:[10.0.0.1]

valahogy meg a mailque-ba valo bekerules elott kene egy LDAP lekerdezes az AD fele es kapasbol rejectalni, a nemletezo cimzettek uzeneteit.

De mintha meg az AD-t is valahogy kulon heggeszteni kene, hogy engedjen ilyen lekerdezest. Vagy eleg ha bedelegalom valahogy a gepet az AD-be, mintha klines lenne?

a transportot nem indokolt hasznalni szerintem, egyszerubb ha a postfix "content_filter"-ben atadja amavisnek (integralt spamassassinnel + clamav), amavis meg az exchange-nek...

ha winbind-el kiszeded usereket AD-bol nsswitch-be akkor a postfix kapasbol fogja dobni unknown_user maileket
bar hogy pl. aliasokkal mi lesz azt nemtom, a windowsos reszt nem igazan vagom, talan mas jobban tud majd segiteni :)

meg valami LDAP-os lekerdezes sem artana, hogy csak a valos cimzettek uzeneteit szurogessuk...

Nem feltetlenul. Megoldhato a cim ellenorzes igy is:

main.cf 

reject_unverified_recipient

Es hogy ne forduljon minden esetben az exchange szerverhez:

main.cf 

address_verify_map = btree:/var/cache/postfix/address_verify_map

Ennek feltetele, hogy az exchange rendesen be legyen allitva. Vagyis ne vegye el a levelet csak akkor ha tudja kezbesiteni.

Ha mindez osszeall akkor a mail-frontend visszautasit minden olyan levelet amit a mail-backend szerver nem ismer.

--
maszili

Na igen, ha ezt megtalalnam az Exchange-ben, meg valahogy tudnam debug-olni, hogy akkor vegre csinal-e barmifele verifikaciot...

Beraktam ezt a smtpd_helo_restrictions-ba: reject_unauth_destination

ill megadtam neki, hogy:

address_verify_relayhost = 10.0.0.1
address_verify_default_transport = direct_smtp

ez alapjan: (merthogy ugye ez egy Exchnage elott gatekeeper Postfix)

http://www.postfix.org/ADDRESS_VERIFICATION_README.html

sajna ettol o meg vigan delivery-zi tovabb a nemletezo cimzetteknek a leveleket.

Az Exchg-be enddig egyedul ilyet talaltam:

Global Settings / Message delivery / Properties / Recipient Filtering / Filter Recipients who are not in the Directory

persze ha bepipalom, akkor valami uberbonyolult warning-ot dob, hogy hol kene inkabb kezzel beallitanom, amit sajnos meg csak nem is ertek...

A f.szomat, mingya kidobom az egesz Windows-t a p.csaba es megcsinalom Sambaval meg valami Exchange szimulacioval az egeszet....

utana olvastam az emlitett linken es ott valami verification re-routingot-ot javasoltak arra az esetre, ha mail server NAT mogott van.

A felallas ugyanis:

- van egy domain.hu,
- (annak az ns-jei vannak valahol)
- (a www-je van megint mashol)
- az mx mutat a NAT kulso interface-jere,
- az csinal egy kis postfix-es elo-filterezest, rejectalast, azan amavis-en keresztul clamav meg spamd,
- ha OK, akkor transporton keresztul betolja a mogotte levo Exchange-be, ami mar kb. barmit benyel.

Namost ha jol ertem azt irjak, hogy ebben az esetben meg kell magyarazni, hogy honnan vegye a recipient verification-t, ugyanis a ha postfix-et kerdezed, hogy na ki is a domain.hu, akkor nyilvan nem a belso halon ficego Exchange-et fogja mondani, ugyanis neki csak a transport mondja meg, hogy oda passzolja tovabb, de semmilyen opcio nem allitja (egyelore), hogy az a domain.hu, tehat ott verifikaljon.

Mar, ha jol ertettem az egeszet... (???)

Azert megsasolom a telnet-et is...!

Az en esetemben ez volt...

A domain (domain2.hu, domain3.hu) MX rekordja egy adott publikus IP-re mutat.(1.2.3.4)
Ott egy cisco router van ami a 25 portot forwardolja a dmz-ben levo mail-frontend-re.
Egy masik halozatban van egy exchange szerver (mail-backend) ami a tulajdonkeppeni levelezo szerver. 


domain.hu(1.2.3.4)<----->/mail-frontend(192.168.1.99)/<----->/mail-backend(172.16.2.1)/

A postfix config ide vonatkozo resze a kovetkezo:

/etc/postfix/map/main.cf 


...
relay_domains = $mydomain, domain2.hu, domain3.hu
...
transport_maps = hash:/etc/postfix/map/transport_map
address_verify_map = btree:/var/cache/postfix/address_verify_map
...
smtpd_recipient_restrictions = ... , reject_unverified_recipient, ...
...

/etc/postfix/map/transport_map 


domain.hu  smtp:172.16.21.1:25
domain2.hu smtp:172.16.21.1:25
domain3.hu smtp:172.16.21.1:25

Az exchange ugy lett beallitva, hogy csak akkor veszi el a levelet ha ismeri a cimzettet!
Sajnos alap beallitasokkal minden kreten cimzettet elvesz, aztan nem tudja kezbesiteni. Ezert kuldi a sikertelen kezbesitesrol szolo levelet... Spam eseten egy olyan cimre ami egy hamisitott felado cime.

Ha egy kulso szerverrol telnettel beprobalod a 25 portot akkor lathatod hogy csak a letezo cimzettek eseten veszi el a levelet. Ha nem igy van akkor valamit elrontottal vagy nem jok az exchange beallitasok. Erdemes kiprobalni az exchange szervert is telnettel, hogy leellenorizd a helyes mukodest...

--
maszili

.csaba...!

http://blogs.technet.com/dlemson/archive/2004/01/19/60388.aspx

...If you don't have this feature, and you get a lot of spam to random recipients, then your machine can spend a fair amount of effort generating Delivery Status Notifications (DSNs) aka Non-Delivery Reports (NDRs) that are sent to the sender of the spam. Of course, this sender is usually bogus, which results in the NDR “NDRing”, and when Exchange generates an NDR to an NDR, it has nowhere to put that NDR, so it puts it in the “badmail” directory.

Anyway, finally in Exchange 2003, we added this feature...

Jovan, vegulis aki 5.5-os Exchange-et hasznal 2008-ban az megerdemli...

de azert remenykedtem...

hat akkor most ket variacio all elottunk:

1. upgrade
2. kivaltani valami teljesen Exchange kompatibilis linuxos megoldassal, ami az adatoka tovabbra is az AD-bol veszi (belertve az Exchange fiokokat is) csak eppen a Linux-hoz kell kapcsolodni. Vegulis a felhasznalonak nem kell tudnia, hogy mihez kapcsolodik es az operatornak is megmaradna a megszokott AD-s abalakos felulet.

"Hat van ilyen, Csupi...?"

emlékeim szerint nem, a script-ben megadod a usert akivel az AD-t lekérdezed:

$user="cn=user,cn=Users,dc=example,dc=com";
$passwd="password";

itt a srác rövid leírása is a dologhoz, végtelenül egyszerű és jól működik, nálunk már úgy 3 éve:

http://www-personal.umich.edu/~malth/gaptuning/postfix/

Helló!

Ebben a cipőben járok én is, ezért bátorkodom felmelegíteni ezt a topicot, szóval nekem nem megy, ezt az üzenetet kapom a getadsmtp.pl futtatása után:
"error:49
error name: LDAP_INVALID_CREDENTIALS
error text: The wrong password was supplied or the SASL credentials could not be processed"

$user="cn=user,cn=Users,dc=example,dc=com";
ebből melyik user a felhasználó neve, és mi a másik user?

Előre is köszönöm a választ!

--
by Mikul@s

$user="cn=user,cn=Users,dc=example,dc=com";

ez hibas definicio, mert csak egy cn lehet benne.

Ha van egy "dc=aaaa,dc=fu"-d, es azalatt egy "o=szamlazas, dc=aaaa,dc=fu"-d, akkor
pl. "cn=joska,o=szamlazas, dc=aaaa,dc=fu" neven tudsz hivatkozni egy felhasznalora.

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

Lekérdezni és betolni nemhiszem, de a Postfixet rá lehet venni, hogy egy AD szervert megkérdezzen: létezik e az a cím?:
ad_recipient_maps:
server_host = ad.domain.hu
search_base = dc=infokt,dc=domain,dc=hu
query_filter = (&(|(objectClass=person)(objectClass=user))(proxyAddresses=smtp:%s))
result_attribute = proxyAddresses
bind_dn = cn=user,ou=szocs,dc=infokt,dc=domain,dc=hu
bind_pw = ********
version = 3

main.cf:
relay_recipient_maps =
proxy:ldap:/etc/postfix/recipient_maps/ad_recipient_maps

Így a Postfix megkérdezi az AD-t, hogy létezik ez a cím? Ha nem akkor visszadobja, ha igen akkor kézbesíti a levelet...

Mik

Az az exchange ami elott a postfix mail-frontend van az egy exchange 2003

A kerdeses beallitas elerheto itt:

* Exchange system manager
* Administrative groups
* First administrative group
* Servers
* (szerver neve)
* Protocols
* SMTP
* Default SMTP virtual server (jobbklikk)
* Tulajdonsag
* Advanced (gomb)
* 25 TCP port sorra (edit gomb)
* Apply recipient filter (kipipal)

* Exchange system manager
* Global settings
* Message delivery (jobbklikk)
* Tulajdonsag
* Sender filtering (ful)
* Drop connection if address watches filter (kipipal)

--
maszili

Apr 22 18:41:39 myhost postfix/smtp[14642]: 52B9992FA5: to=, relay=10.0.0.1[10.0.0.1]:25, delay=0.08, delays=0.02/0.02/0/0.05, dsn=5.1.1, status=undeliverable (host 10.0.0.1[10.0.0.1] said: 550 5.1.1 User unknown (in reply to RCPT TO command))
Apr 22 18:41:42 myhost postfix/smtpd[14313]: NOQUEUE: reject: RCPT from fg-out-1718.google.com[72.14.220.158]: 450 4.1.1 : Recipient address rejected: undeliverable address: host 10.0.0.1[10.0.0.1] said: 550 5.1.1 User unknown (in reply to RCPT TO command); from= to= proto=SMTP helo=

:)))))))

na lassuk, mit fog mindez a spamd-n! (ami spamc-vel van hivva termeszetesen)

igy van!
postfixre forditva minimum ezeket erdemes a smtpd_recipient_restrictions-be irni:

reject_invalid_hostname,
reject_unauth_destination,
reject_unknown_sender_domain,
reject_unauth_pipelining,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client spews.dnsbl.sorbs.net,
reject_rbl_client spews.dnsbl.sorbs.net,
reject_rbl_client dnsbl.sorbs.net,
reject_rbl_client dnsbl.ahbl.org,

nalunk napi 80-100ezer level bukik el ezen a szinten, ami jelentos resze a teljes level fogalomnak

( eyez00 | 2008. 04. 18., p – 09:54 )

Koszi a javaslatokat!
Beraktam az elso szerverbe a postfix-re adott tippeket es atmenetileg beraktam az Exchange es a Postfix koze egy ASSP-t, ha kiokosodik, akkor talan ki is kiveszem a postfix-et elole.

Nagyon powah! koszi mindenkinek! :)

egyelore az LDAP autentikacio reszevel nem boldogulok. (meg idonkent magatol visszallit dolgokat, de ezt figyelem a log folymatos tail-ezesevel es a ha kiszurom, akkor visszajavitom)

Ami bonyolitja a dolgot, az az, hogy az Exchange egy 'virtualis' domain-en van elhelyezve, tehat a domain igy nez ki az AD-ben: mydomain.hu.local, viszont a mydomain.hu vegu leveleket fogadja. Ez azert van igy, mert ez csak egy belso AD, nem akartam ongyilkos lenni, hogy kirakjam publikus IP-vel. Nem ertek ennyire a Windows-hoz. :(

Eddig a legtobb, amit sikerult belole csiholnom, az ilyen hiba:

LDAP search error: 89 -- check ignored

es igy siman at is engedi az Exchage fele a valotlan cimzetteknek szolo leveleket is.

azt mondja: recipient accepted unchecked

Amiben nem vagyok biztos:

LDAP Login

Ezt ilyen forman adtam meg: cn=Rendszergazda,cn=Users,DC=mydomain,DC=hu,DC=local

LDAP Root container

Ezt ilyen forman adtam meg: DC=DOMAIN (azt mondja, igy lehet helyettesiteni)

LDAP Filter for Local Domains

???

LDAP Filter for Local Addresses

proxyaddresses=smtp:EMAILADDRESS (itt probaltam a mintapeldaval elni)

Olvasgatom a zEsemenynaplot is, de abbol okosodjon ki az ember....

kozben utanaastam, az az ldap search error 89 elvileg a perl ldap moduljatol szarmazik, es azt irja az ujsag, hogy:
http://search.cpan.org/~gbarr/perl-ldap-0.33/lib/Net/LDAP/Constant.pm

azaz a 89-es hiba :
LDAP_PARAM_ERROR (89)

tehat valahol a parameterezes nem oke. ldap servert probald ip-vel megadni, mittomen esetleg nezzuk at megegyszer az ldap auth meg a tobbi beallitast.
windows szerverben nem vagyok otthon, nem lehetseges, hogy ott meg engedelyezni kell a lekerdezest az ad-n kivuli gepekre ? gondolom ahol az assp fut, az nincs beleptetve az ad-be.
esetleg meg annak kene utananezni, hogy a windowson nem-e lehet logolni a hibas ldap lekerdezeseket.

ja, itt akadtam el en is.
Sajnos a reszletes (es erteheto) LDAP loggolast meg nem birtam eloasni, amit meg dob, azt nem ertem.
A szervert mar alapbol is IP-vel adtam meg.
Egyszer olvastam valahol olyat, hogy ha anonymous AD lekerdezest akar az ember, AD-n kivulrol, azt kulon engedelyezni kell valahogy.
Amugz akar be is delegalhatom a gepet, de szerintem attol nem leszunk elorebb, mert ugy latom az ASSP ezzel nem foglalkozik.

Most kicsit megprobalom megintcsak a postfix vonalon, aztan elvalik.

f.szom spammerek.

( gna | 2008. 04. 21., h – 21:40 )

Postfix esetében a nagyobb forgalom esetén az amavis a perles hívogatással meg a lokálban futó spamd vel szörnyű.

A vírusok ellen ott a clamsmtpd, a spam pedig a proxsmtpd-vel hívott spamd.

Ha a spamd okozza a bajod akkor meg: spamc nek adjad meg a hostot .. és ne a spamd portját hívogasd közvetlenül, az a spamc dolga ... :)

Amúgy a postfix rbl es egyeb restriction-jai igazán nagy szolgálatot tesznek.

Gergő