Postfix UCE HOWTO
Postfix UCE HOWTO | |
Postfixban harom fajta korlatozas van:
Postfix a korlatozasi szakaszokat kovetkezo sorrendben dolgozza fel:
smtpd_client_restrictions
smtpd_helo_restrictions
smtpd_sender_restrictions
smtpd_recipient_restrictions
smtpd_data_restrictions
Ezeket roviden elmagyaraznam:
Biztos eszrevettetek, hogy nalam az osszes korlatozas az smtpd_recipient_restrictions -ben van. Ennek van egy oka. Postfix alapbol csak az "RCPT TO:" parancs utan hajtja vegre az UCE vizsgalatokat, mivel alapbol a smtpd_delay_reject=yes -re van allitva. Nem javasolom, hogy ezt a beallitast modositsatok, mivel nem biztos, hogy minden smtp kliens ezt szeretni fogja (ezzel semmifelekepp nem akarok az MS fajta kliensekre celozni ;-)
Ez az oka annak, hogy igy implementaltak Postfix-ba. Van sajnos nehany MS fajta smtp kliens (MUA), melyek hiaba kapnak mar a HELO/EHLO -nal REJECT-et, mert nem ertik meg es megis elkuldik az egesz emailt. Igy hiaba utasitjuk vissza, mert megis elkuldi az adatokat, persze nem jonnek be a Postfix-ba, de ezek altalaban sok adatot jelentenek. Ha valaki kuldene egy ilyen MS klienssel egy 3 MB-os attachment-ot, akkor hiaba kap REJECT-et a HELO/EHLO-nal, mert megis elkuldi az egeszet. Ezert alapbol Postfixban az smtpd_delay_reject=yes opcio be van kapcsolva.
Nagyon fontos, hogy a kulonbozo korlatozasokat jo sorrendbe rakjuk, mert aszerint donti el Postfix, hogy tovabbadja-e a process-t vagy megallitja.
Miutan megneztuk a korlatozasi szakaszokat, nezzuk milyen korlatozasok es engedelyezesek leteznek a kulonbozo szakaszokban:
smtpd_helo_required = yes
smtpd_client_restrictions =
smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_recipient_restrictions =
permit_mynetworks,
reject_unauth_destination,
reject_invalid_hostname,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_rbl_client relays.ordb.org,
reject_rbl_client proxies.relays.monkeys.com,
reject_rbl_client proxies.blackholes.easynet.nl,
reject_rbl_client zombie.dnsbl.sorbs.net,
reject_rbl_client cbl.abuseat.org,
Ez itt fent egy konfiguracio, amit egy probahoz fogunk felhasznalni.
Hogyan mukodik pontosan a korlatozas Postfix alatt? Mivel dolgozik kozben Postfix es honnan tudja, hogy mikor milyen korlatozast nezzen? Ehhez nezzunk meg a fenti konfiguracioval egy peldat.
Az smtp kliens tegyuk fel kuld egy ilyen headert: MAIL FROM:<user@nemletezek.hu>
Es tegyuk fel, hogy a nemletezek.hu domain tenyleg nem is letezik, akkor Postfix a korlatozasokat abban a sorrendben nezi meg, ahogy fent lathatjatok.
Erre akkor a pelda:
| Korlatozas | Valasz |
|---|---|
| permit_mynetworks | DUNNO |
| reject_unauth_destination | DUNNO |
| reject_invalid_hostname | DUNNO |
| reject_non_fqdn_sender | DUNNO |
| reject_unknown_sender_domain | REJECT |
| reject_non_fqdn_recipient | |
| [..] | |
Csatlakozik a kliens, ad egy EHLO -t a szervernek, ezzel azonositja magat. A fentiek szerint tobb korlatozas van, amit a szervernek ellenoriznie kell, tehat megteszi ezt sorrendben:
A permit_mynetworks -re nem matchel a tcp/ip kliens, tehat tovabbadja a kovetkezo korlatozasnak.
Ezutan jon a reject_invalid_hostname, mely megnezni az EHLO-ban hostname-t, hogy rossz szintakszisu-e. Mivel latja, hogy nem rossz szintakszisu, ezert ad egy DUNNO-t.
A reject_unauth_pipelining nem matchel, tehat tovabbadja.
A reject_non_fqdn_sender ugye nem matchel, mert FQDN formaju a user@nemletezek.hu es igy tovabbadja a kovetkezonek.
A kovetkezo korlatozas a reject_unknown_sender_domain. Megnezi tehat, hogy a MAIL FROM: -ban mit adott meg domainnek az smtp kliens es feloldja azt a nevet, hogy nezze meg van-e A tipusu DNS rekordja. Mivel nincs ilyen domain, igy ebben az esetben egy REJECT-tel valaszol. Az smtp szerver ezt a valaszt adna a kliensnek:
450 <user@nemletezek.hu>: Sender address rejected: Domain not found
Ezutan jon a reject_unknown_recipient_domain, de ezt ezesetben nem nezi mar meg, mert mar ugye REJECT-et kapott a kliens, ezennel visszautasitotta az egesz level-kuldesi folyamatot. A tobbi, ezutan kovetkezo korlatozas is kimarad, hisz mar eldontotte Postfix, hogy nem fogadja el a levelet.
Meg egy fontos dolog: A kulonbozo korlatozasi szakaszokon belul
altalaban van mindig egy korlatozas, melynek parameterkent megadhatunk
maptype:mapname -et. Ha felsorolunk tobb szabalyt, akkor azokban
a kovetkezo muveletek lehetnek: OK, DUNNO vagy REJECT. Ez esetben ha
valamelyik szabaly ervenyes es a target DUNNO, akkor az annyit jelent,
hogy Postfix meg nem tudja eldonteni, hogy mit tegyen, ezert befejezi az
ertelmezest es tovabbugrik a kovetkezo korlatozashoz.
Ehhez legyen egy pelda. Tegyuk fel a korlatozasok kozott van egy ilyen:
check_sender_access pcre:/etc/postfix/sender_checkA file tartalma pedig:
/domain\.hu$/ DUNNO /^mail\.domain\.hu$/ DUNNO /^spammer\.hu$/ REJECT
Ha jon egy email a mail.domain.hu-tol, akkor matchel az elso ket sorra, de a masodik sort mar nem nezi meg Postfix, mivel az elsonel kapott egy DUNNO muveletet, miszerint Postfix befejezi az adott file ertelmezeset es tovabbugrik az ezt kovetkezo korlatozashoz. Mindig ajanlott Regularis kifejezesek hasznalatakor egy "^" -vel kezdeni es egy "$" -vel befejezni a kifejezest, nehogy hibak tortenjenek. Mert ugye ebben az esetben a foodomain.hu es a bardomain.hu is matchel a /domain\.hu$/ -ra, ezt a fajta hibat pedig erdemes elkerulni. A fenti peldat ezert csak azert irtam le, hogy tudjuk megerteni a DUNNO lenyeget.
Nezzuk akkor hogy nezne ez ki smtp nyelven. Eloszor a parameterek:
SMTP Client:
Address: 111.111.111.111
Hostname: nemletezek.hu
Prefix: >>
SMTP Server:
Address: 111.111.111.112
Hostname: domain.tld
Prefix: <<
Most kovetkezzek az smtp kapcsolat:
<< 220 mail.domain.tld ESMTP
>> EHLO localhost -----
<< 250-domain.tld |
<< 250-PIPELINING | -> smtpd_delay_reject=yes
<< 250-SIZE 10240000 |
<< 250-ETRN | Itt meg semmi ellenorzes nem
<< 250 8BITMIME | hajtodik vegre, mivel a fenti
>> MAIL FROM:<user@nemletezek.hu> | opcio ervenyes.
<< 250 Ok |
>> RCPT TO:<user@domain.tld> ----- -> Itt jon az osszes ellenorzes
|
permit_mynetworks -> DUNNO
|
[...]
|
reject_non_fqdn_sender -> DUNNO
reject_unknown_sender_domain -> REJECT
|
-----
<< 450 <user@nemletezek.hu>: Sender address rejected: Domain not found
>> DATA
<< 554 Error: no valid recipients
>> QUIT
<< 221 Bye
Ha nem ertitek ezt a peldat, akkor olvassatok el a 821-es szamu RFC-t (Request for comments). Abban leirtak, hogy kell kinezzen egy smtp kapcsolat.
Amit meg tudni kell... Miutan az email atfutott az ellenorzeseken kap egy permit-et a vegen. Ez az alap, tehat ha nincs ott egy permit a korlatozasi lista vegen, akkor magatol "odarak" egyet, persze ezt a konfiguracioban nem lehet latni. Ha nem kivanjuk elfogadni az emailt miutan atfutott a korlatozasokon, akkor rakjunk egy reject-et a vegere. De ezt altalaban nem szoktak csinalni. Tehat a kliens vegig DUNNO-t kap, majd a vegere er a korlatozasok listajaban, aztan Postfix odarak egy permit-et es igy kapja meg az OK-t (ha elotte nem REJECT-elte semmi).
Most tehat jon az smtp kapcsolat DATA resze. Eddig csak a HELO/EHLO, MAIL FROM:, RCPT TO: -t neztuk.
A header_checks es body_checks a DATA utan kovetkezik, miutan megkapta Postfix a zaro "." -ot. A header_ es body_checks nem az smtpd_*_restrictions -hez tartozik, hanem maga egy korlatozasi szakasz. Altalaban ket modot szoktak hasznalni ezekre: pcre es regexp.
header_checks regexp:/etc/postfix/maps/header_checks.regexp
A header_checks.regexp file-ban elmeletileg igy nezne ki egy sor:
/^<HEADER>:.*tartalom_a_muvelethez/ MUVELET
Gyakorlatilag pedig:
/^From:.*abuser@domain.tld$/ REJECT
Azt, hogy milyen headerek vannak, meg lehet nezni egy email forrasaban, ott meg lehet talalni a kulonbozo headereket (fejleceket). A tartalmat is persze meg lehet adni kivansag szerint, a muveleteknek viszont van fix ertekuk:
REJECT: Ez a megszokott muvelet, ha el akarunk utasitani egy header-t.
Az email nem jon be a szerverre. A REJECT utan szoveget is meg
lehet adni, amit majd a logban lathatunk, illetve amit a kuldo
is megkap.
pelda: /^Subject:.*ingyen/ REJECT Inkabb fizetek erte.
Ez kiszuri minden emailt, melynek a Subject-ben az "ingyen" szo
szerepel es visszaadja a "Inkabb fizetek erte." mondatot.
IGNORE: Ez csak annyit csinal, hogy a megadott header-t kiveszi az
emailbol es folytatja a level tovabbitasat.
pelda: /^X-Mailer:/ IGNORE
Kivesszuk az "X-Mailer" headert az emailbol, mert nem erdekel
minket, hogy milyen MUA (=Mail User Agent) -el kuldtek az
emailt.
WARN: Nagyon hasznos lehet ha ki akarunk probalni uj
korlatozast/filtert. A mail log-ban kapunk egy sort, melyben
irja, hogy mit szurt volna ki. De mivel csak WARN, ezert
tovabbitja az emailt.
pelda: /^Subject:.*penz/ WARN
Megnezzuk hasznos-e ez a filter. Kapjuk a log file-ban a
figyelmezteteseket. De az emailt is egyarant megkapjuk.
HOLD: Bent tartja az emailt a queue-ban, majd az admin megmondhatja,
hogy mi tortenik azzal az emaillel. Hasznos lehet, ha nem
akarjuk visszautasitani az emailt, de azt sem, hogy rogton
megkapjak a felhasznalok, hanem majd mi eldontjuk.
pelda: /^Subject:.*felmondas/ HOLD
Minden email, melynek Subject-ja "felmondas"-t tartalmaz HOLD-ra
kerul, nem kapja meg senki, amig mi el nem dontjuk, hogy mi lesz
az emaillel.
DISCARD: Ez annyit csinal, hogy a kuldo szervernek szimulalja, hogy
elkuldte az emailt, mikozben torli. Ezt akkor erdemes
beallitani, ha nem akarjuk, hogy a szerver vagy a kuldo tudja,
hogy mi tortent az adott email-el.
pelda: /^Subject:.*szamla/ DISCARD
Minden emailt torol, melynek Subject-je tartalmazza a "szamla"
szot.
FILTER: Engedi, hogy megadjunk egy masik servert vagy filtert, melyet
ugy adunk meg mint a transport map-ben. Ez akkor hasznos, hogy
ha csak bizonyos emaileket akarunk filterezni kulso filterrel.
pelda: /^Subject:.*virus/ FILTER smtp:10025
Minden emailt, mely "virus" -t tartalmaz a Subject-ben atadja a
10025-os porton levo kulso filternek. Altalaban amavis szokott
azon a porton futni.
A header_checks-hez parameter:
header_checks = pcre:/etc/postfix/maps/header_check.pcre
Nezzuk meg a header_check.pcre file tartalmat:
/^Subject:.*100\% Free/ REJECT Woah! Free? /^From:.*spammer@domain.hu/ REJECT Takarodj innen, spammer. /^X-Mailer:.*Microsoft/ REJECT Get a _real_ MUA. /^Reply-To:.*sajatmagam@domain.hu/ REJECT Nem vagyok skizofren.
Fontos: A fenti peldak nem biztos, hogy hasznalhatok, csak peldanak vannak itt, tehat csak akkor hasznaljatok, ha ertitek mit csinalnak. Maskepp akkor inkabb hasznaljatok a WARN-t, REJECT helyett.
Postfix bovult egy uj opcioval, a mime_header_checks -el. Ez ugyanazt
csinalja mint a header_checks kiveve, hogy a csatolt file-okat
ellenorzi. Ehhez parameter:
mime_header_checks pcre:/etc/postfix/maps/mime_header_check.pcre
Nezzuk a mime_header_check.pcre file tartalmat:
/name=[^>]*\.exe/ REJECT Tartsd meg a .exe filet. /name=[^>]*\.bat/ REJECT Tartsd meg a .bat filet. /name=[^>](screensaver|movie)\.zip/ REJECT Sobig virusod van.
A body_checks ugyanigy mukodik, csak nem kell neki megadni az elejen semmit, mint a header_checks-nel. A parameter: body_checks = pcre:/etc/postfix/maps/body_check.pcre
Nezzuk a body_check.pcre file tartalmat:
/See the attached file for details/ REJECT Sobig virusod van. /Get your free/ REJECT Free? No, thanks.
Vegyuk figyelembe, hogy a header_checks, mime_header_checks es a body_checks-ben fontos a sorrend. Erre nezzunk egy peldat.
A header_check.pcre fileban tegyuk fel a kovetkezo sorok vannak:
/^Subject:.*szia/ REJECT Szia-szia. /^From:.*fonok@domain.hu/ OK
Es akkor nezzuk az smtp kapcsolat hogy nezne ki, ha a fonokunk akarna nekunk irni egy emailt "szia" Subject-tel:
<< 220 mail.domain.hu ESMTP
>> EHLO masikhost.domain.hu
<< 250-domain.hu
<< 250-PIPELINING
<< 250-SIZE 10240000
<< 250-ETRN
<< 250 8BITMIME
>> MAIL FROM:<fonok@domain.hu>
<< 250 Ok
>> RCPT TO:<user@domain.hu>
<< 250 Ok
>> DATA
<< 354 End data with <CR><LF>.<CR><LF>
>> To:fonok@domain.hu
>> Subject:szia
>> Szia
>> . -----
| Csak a vegzo "." utan ellenorzi
| Postfix a header-t meg body-t.
|
| -> header_checks
| -> mime_header_checks
| -> body_checks
|
-----
<< 550 Error: Szia-szia.
>> QUIT
<< 221 Bye
Itt latjuk, hogy biza nem jott at a level. Miert is? Hiaba van a header_check.pcre fileban, hogy fonok@domain.hu -tol fogadhatunk levelet, mert elotte van egy olyan, hogy minden "szia" Subject-es levelet utasitson vissza egy "Szia-szia." hibauzenettel, amit lathatunk meg is tett.
Tehat celszeru elore rakni azt a sort, melyet engedelyezunk.
http://www.securitysage.com/guides/postfix_uce.html
http://www.mengwong.com/misc/postfix-uce-guide.txt
http://jimsun.linxnet.com/misc/postfix-anti-UCE.txt
http://www.postfix.org/uce.html
http://www.postfix.org/docs.html
Copyright (c) 2003 Istvan Sebestyen <istvan@chains.ch> All rights reserved.
Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.
Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.
Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Author.