Le 25/12/2010 19:55, ASAI a écrit :
> Greetings,
>
> In the logs I have been seeing many attempts made to send messages to
> gmail which seem like there's spam being sent from my server. In the
> logs I see this:
>
> Dec 24 00:05:11 triata amavis[29729]: (29729-06) Passed CLEAN,
> <apa...@triata.globalchangemultimedia.net> -> <ickovjulee...@gmail.com>,
> Message-ID:
> <20101224070510.bf7acfd8...@triata.globalchangemultimedia.net>, mail_id:
> s69xqJA1Kuer, Hits: -2.6, size: 669, queued_as: 9F457FD80A9, 898 ms
> Dec 24 00:05:11 triata postfix/smtp[1065]: BF7ACFD8063:
> to=<ickovjulee...@gmail.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=1,
> delays=0.09/0.01/0/0.9, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
> 9F457FD80A9)
>
next time, show logs of postfix/smtpd (with a trailing 'd') and/or
postfix/pickup. This will tell if the message was received via smtp or
with the sendmail command.
> What is a problem is that there is no user named apa...@triata... and
> this user is sending hundreds of emails out to Gmail. So it looks like
> there's been a compromise. My question is, how do I begin to plug this
> hole?
>
>
1) create /etc/postfix/hold_sender and edit it to add:
apa...@triata.globalchangemultimedia.net HOLD
2) edit main.cf and add
postfilter_sender_restrictions =
check_sender_access pcre:/etc/postfix/hold_sender.pcre
3) edit master.cf, find the line that defines the 10024 smtpd listener,
and there set
-o smtpd_sender_restrictions=${postfilter_sender_restrictions}
4) run 'postfix reload'
now, mail from apa...@*.globalchangemultimedia.net will be held in
postfix queue. you can then use postcat to look inside. This should help
getting more infos. things to look for are
- if the message is a mailing list confirmation/notification, with no
"spam text", then either the list is very successfull or it is abused.
if it is abused from a single IP or an IP range, you can block that
range in your Apache configuration. or you may use something like
mod_doesevasive...
- if the message contains spam text, then you will need to find which
script was used to send it. the script may be vulnerable to one of the
so many web application attacks. most probably an injection attack.
- check all your web scripts that send mail. writing scripts that send
mail from a web page is not simple. do not invent yours unless you are
well versed in web application security (and as a corollary: do not hire
a newbie to write one).
