On 04/03/2013 02:30 PM, Eric Peabody wrote:
Frank,
I'll suggest doing the following:
1. Stop sendmail for a moment while you do the next two steps
2. Add a line in /etc/mail/access to block the outgoing email address
like, "From:bus...@sad.com REJECT". Then run make in /etc/mail.
That will stop any further outgoing messages while you work on the
problem.
I believe you need to run this when changing access
run makemap hash /etc/mail/access < /etc/mail/access
1. Clear the outgoing mail queue of spam from that sender. Run mailq
to get the stuff in the queue and delete the nasty files. Note
there are two files for each message, one starting with "df" and
one with "qf".
2. Start sendmail and watch the log to be sure that mail from that
account does not go out
3. Change the user name and password for the account. I suggest
changing the user name because the spammers are likely to continue
to try sending with that account and pam_abl will block the
account, preventing the valid user from accessing mail. Also
suggest picking a user name that is somewhat unusual and different
from the email address. For example, for "fr...@happyplace.com", a
user name of "happyfrank" would be much better than just "frank"
and makes guessing more difficult.
4. Remove the line from /etc/mail/access and run make and restart
sendmail
We too have seen a large increase in attacks through sendmail AUTH
recently. The accounts compromised did not use encrypted connections
and I recommend that you require users to use encrypted connections as
soon as possible. Of course, getting folks to change settings like
this is a challenge.
Since sendmail uses saslauthd for authentication and the API between
them does not include the IP address, error messages are limited.
I've been matching on the "did not issue MAIL/EXPN/VRFY/ETRN during
connection to MSA" message which sendmail produces when an
authentication fails and includes an IP address. Messages in
/var/log/secure are not especially helpful and there is some delay
between the logging in secure and maillog so matching the events is
difficult.
I also cranked down the number of allowed recipients to limit the
damage and wrote an informal script to send a text message to me if
that limit is exceeded. If I find the time to solidify it, I'll post
it. The spammers usually try to send to a fairly large number of
recipients, perhaps 25, and if that fails, reduce the number until
they get through. By monitoring for the "Too many" messages in
maillog, I get an early warning of a compromised account.
We installed fail2ban on our servers and continue to tweak the
configuration. It has been a lot of work but it has significantly
reduced the activity from the spammers since it blocks them pretty
quickly. However, the absence of any user interface and the need for
some programming skills makes it difficult to use.
We also use fail2ban to monitor for attacks against Wordpress sites
and have had a number of detections from that filter so this is good
for more than mail.
While fail2ban is a good tool, it needs some improvements such as
being able to restart it without loosing track of what it has done, a
way to remove a banned address and better status and reporting tools
in addition to an improved user interface. I guess if you like
iptables, you'll love fail2ban ;).
Eric
On 4/3/13 1:46 PM, Ken Marcus wrote:
On 4/3/2013 9:37 AM,fra...@iaw.on.ca wrote:
Hi,
I am running BlueOnyx 3.20110922 . We have had a lot of unauthorized
relaying only for a certain user. We even changed her password but it's
still doing it.
In the eMail section of Network services I have it checked off to Enable
SMTP Auth and POP Authenticated relaying.
It's only happening to the one user which is confusing me. What else can
i set to tighten up the relaying?
Thanks.
Here is a log entry:
Apr 3 10:58:56 raq2 sendmail[9296]: AUTH=server,
relay=ip-176.105.131.241.tvsat364.lodz.pl [176.105.131.241],
authid=mmagno, mech=LOGIN, bits=0
Apr 3 11:02:05 raq2 sendmail[12291]: AUTH=server,
relay=host-81-190-162-132.gorzow.mm.pl [81.190.162.132], authid=mmagno,
mech=LOGIN, bits=0
Apr 3 11:02:20 raq2 sendmail[12306]: AUTH=server,
relay=124-218-75-60.cm.dynamic.apol.com.tw [124.218.75.60] (may be
forged), authid=mmagno, mech=LOGIN, bits=0
Apr 3 11:03:14 raq2 sendmail[13029]: AUTH=server,
relay=triband-mum-59.183.21.118.mtnl.net.in [59.183.21.118],
authid=mmagno, mech=LOGIN, bits=0
Apr 3 11:06:20 raq2 sendmail[15029]: AUTH=server, relay=[212.5.32.239],
authid=mmagno, mech=LOGIN, bits=0
_______________________________________________
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
Spammers have the mmagno password.
It seems like restarting sendmail and dovecot would be enough. But for
some reason I have seen successful authids after doing that. Maybe they
are cached somewhere.
If you reboot the server after the password change. That will do it.
Ken Marcus
_______________________________________________
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
_______________________________________________
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
--
Gerald Waugh
Front Street Networks
(318) 734-4779
(318) 401-0428
_______________________________________________
Blueonyx mailing list
Blueonyx@mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
