[es] - Postfix bounce attack

shadow-bg
Ciric Vukasin
Preduzetnik
Beograd

Član broj: 189835
Poruke: 313
*.dynamic.sbb.rs.

Sajt: www.bgwireless.net

+293 Profil

Postfix bounce attack

^{07.01.2012. u 19:34 - pre 149 meseci}

dakle danas sam u logovima primetio bounce napad

Jan 7 19:59:55 thinkcentre postfix/smtpd[5038]: connect from unknown[109.100.146.19]
Jan 7 19:59:55 thinkcentre postfix/smtpd[5038]: D6A789E059A: client=unknown[109.100.146.19]
Jan 7 19:59:58 thinkcentre spamd[2110]: spamd: connection from localhost [127.0.0.1] at port 43664
Jan 7 19:59:58 thinkcentre spamd[2110]: spamd: setuid to spamfilter succeeded
Jan 7 19:59:58 thinkcentre spamd[2110]: spamd: processing message <000d01cccd6e$836235d0$6479a8c0@NCA-MSI> for spamfilter:1001
Jan 7 19:59:58 thinkcentre postfix/smtpd[5038]: disconnect from unknown[109.100.146.19]
Jan 7 19:59:58 thinkcentre spamd[2110]: spamd: clean message (1.5/5.0) for spamfilter:1001 in 0.2 seconds, 56208 bytes.
Jan 7 19:59:58 thinkcentre spamd[2110]: spamd: result: . 1 - HTML_MESSAGE,MIME_QP_LONG_LINE,RDNS_NONE scantime=0.2,size=56208,user=spamfilter,uid=1001,required_score=5.0,rhost=localhost,raddr=127.0.0.1,rport=43664,mid=<000d01cccd6e$836235d0$6479a8c0@NCA-MSI>,autolearn=no
Jan 7 19:59:58 thinkcentre spamd[1053]: prefork: child states: II
Jan 7 19:59:58 thinkcentre postfix/pickup[16862]: 9B36D9E05A5: uid=1001 from=<[email protected]>
Jan 7 19:59:58 thinkcentre postfix/cleanup[5050]: 9B36D9E05A5: message-id=<000d01cccd6e$836235d0$6479a8c0@NCA-MSI>
Jan 7 19:59:58 thinkcentre postfix/qmgr[32603]: 9B36D9E05A5: from=<[email protected]>, size=57302, nrcpt=1 (queue active)
Jan 7 19:59:58 thinkcentre postfix/pickup[16862]: B24A19E05A4: uid=1001 from=<spamfilter>
Jan 7 19:59:58 thinkcentre postfix/cleanup[5050]: B24A19E05A4: message-id=<000d01cccd6e$836235d0$6479a8c0@NCA-MSI>
Jan 7 19:59:58 thinkcentre postfix/pipe[5055]: D6A789E059A: to=<[email protected]>, relay=spamfilter, delay=3, delays=2.5/0.01/0/0.47, dsn=2.0.0, status=sent (delivered via spamfilter service)
Jan 7 19:59:58 thinkcentre postfix/qmgr[32603]: D6A789E059A: removed
Jan 7 19:59:58 thinkcentre postfix/qmgr[32603]: B24A19E05A4: from=<[email protected]>, size=57302, nrcpt=1 (queue active)
Jan 7 19:59:58 thinkcentre postfix/virtual[5068]: 9B36D9E05A5: to=<[email protected]>, relay=virtual, delay=0.33, delays=0.21/0.04/0/0.09, dsn=5.1.1, status=bounced (unknown user: "[email protected]")
Jan 7 19:59:58 thinkcentre postfix/cleanup[5067]: D0F619E05A6: message-id=<[email protected]>
Jan 7 19:59:58 thinkcentre postfix/virtual[5068]: B24A19E05A4: to=<[email protected]>, relay=virtual, delay=0.29, delays=0.19/0.01/0/0.08, dsn=2.0.0, status=sent (delivered to maildir)
Jan 7 19:59:58 thinkcentre postfix/qmgr[32603]: B24A19E05A4: removed
Jan 7 19:59:58 thinkcentre postfix/qmgr[32603]: D0F619E05A6: from=<>, size=2892, nrcpt=1 (queue active)
Jan 7 19:59:58 thinkcentre postfix/bounce[5072]: 9B36D9E05A5: sender non-delivery notification: D0F619E05A6
Jan 7 19:59:58 thinkcentre postfix/qmgr[32603]: 9B36D9E05A5: removed
Jan 7 20:00:00 thinkcentre postfix/smtp[5077]: D0F619E05A6: to=<[email protected]>, relay=gk-w-mail.srvs.usps.gov[56.0.83.11]:25, delay=2.1, delays=0.08/0.01/1.3/0.7, dsn=5.7.1, status=bounced (host gk-w-mail.srvs.usps.gov[56.0.83.11] said: 550 5.7.1 Bounce attack signature verification failed. (in reply to RCPT TO command))
Jan 7 20:00:01 thinkcentre postfix/qmgr[32603]: D0F619E05A6: removed

Kako da podesim postfix da sprecim da ucestvujem u bounce napadima?

Odgovor na temu

Aleksandar Olujic
none

Član broj: 247504
Poruke: 127
194.8.63.*

+15 Profil

Re: Postfix bounce attack

^{09.01.2012. u 10:17 - pre 149 meseci}

Na zalost nemoguce je izbjeci mailove upucene na nepostojece adrese. Posao mail servera je da obavijesti posiljaoca o tome da primalac ne postoji. Uzimajuci te dvije stvari u obzir, prakticno je nemoguce izbjeci ucesece mail servera u bounce attacks. Moguce je jedino smanjiti izlozenost sopstvenog servera takvim napadima i to na dva nacina:

1. Silent discard za mailove upucene na adrese koje ne postoje
2. Prebaciti kreiranje non-delivery notification na sistem koji salje poruku nepostojecem korisniku

U prvom slucaju nece biti kreiran non-delivery notification i server se nece baviti slanjem istog. Mail ce biti obrisan. Ovakav postupak se smatra "losim ponasanjem" na Internetu i suprotno je RFC-ovima koji se bave slanjem mail-a. Ovaj sistem ne razlikuje falsifikovane poruke od onih pravih koje su slucajno poslate na nepostojecu adresu i za koje je bitno da posiljalac bude obavijesten o problemu.

U drugom slucaju cilj je odbiti poruku u toku SMTP konverzacije, cim se utvrdi da korisnik ne postoji. Mail server koji prima poruke (mail exchanger) obicno nije isti server na kome je baza korisnika te je u tom slucaju potrebno ukljuciti "Postfix address verification" http://www.postfix.org/ADDRESS_VERIFICATION_README.html#recipient
Kada server odgovori sa kodom 550 (sto ce sprijeciti ponovne pokusaje da se falsifikovani mail isporuci i tako ustediti na SMTP connections), konverzacija se prekida i posao je servera koji salje da kreira non-delivery report/notification. To na zalost ne pomaze falsifikovanom posiljaocu jer ce on svakako dobiti non-delivery notification - pod pretpostavkom da je server sa koga se salju falsifikovane poruke toliko lose konfigurisan da ce slati i non-delivery reports na adrese za koje nije relay.

Oba nacina sprjecavaju akumuliranje non-delivery notifications u mail queue.

Sve ovo je samo dio price o zastiti mail servera. Potrebno je imati i sve druge zastite koje server moze da "podnese". Na prvo mjesto bih stavio potrebu da se razdvoje server za slanje (relay) i server za primanje mail-a (exchanger). Prijem mail-a sa Interneta iz nepoznatih izvora i slanje maila iz poznatih izvora (lokalne mreze) ka nepoznatim destinacijama su dvije vrlo razlicite funkcije. Dok je moguce podesiti postfix da bezbjedno obavlja obije funkcije u okviru jednog sistema, takva konfiguracija se prije ili kasnije komplikuje ili vodi do nezeljenih efekata zbog te razlike u funkcijama koje server mora da obavlja. Ako se logicno razmislja o tome, server koji salje i prima treba da bude potpuno otvoren prema internetu (prima od svakog, salje svakom) i potpuno otvoren prema lokalnoj mrezi sto je nekako nespojivo sa sigurnoscu sistema.

Odgovor na temu