<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 04/03/2013 02:30 PM, Eric Peabody
wrote:<br>
</div>
<blockquote cite="mid:515C833C.7040306@bnserve.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Frank,<br>
<br>
I'll suggest doing the following:<br>
<ol>
<li>Stop sendmail for a moment while you do the next two steps<br>
</li>
<li>Add a line in /etc/mail/access to block the outgoing email
address like, <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:From:busted@sad.com%A0REJECT">"From:busted@sad.com
REJECT"</a>. Then run make in /etc/mail. That will stop
any further outgoing messages while you work on the problem.</li>
</ol>
</div>
</blockquote>
I believe you need to run this when changing access<br>
run makemap hash /etc/mail/access < /etc/mail/access <br>
<blockquote cite="mid:515C833C.7040306@bnserve.com" type="cite">
<div class="moz-cite-prefix">
<ol>
<li>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".<br>
</li>
<li>Start sendmail and watch the log to be sure that mail from
that account does not go out<br>
</li>
<li>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 <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:frank@happyplace.com">"frank@happyplace.com"</a>,
a user name of "happyfrank" would be much better than just
"frank" and makes guessing more difficult.<br>
</li>
<li>Remove the line from /etc/mail/access and run make and
restart sendmail</li>
</ol>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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 ;).<br>
<br>
Eric<br>
<br>
On 4/3/13 1:46 PM, Ken Marcus wrote:<br>
</div>
<blockquote cite="mid:515C7910.4030805@precisionweb.net"
type="cite">
<pre wrap="">On 4/3/2013 9:37 AM, <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:frankd@iaw.on.ca">frankd@iaw.on.ca</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Blueonyx@mail.blueonyx.it">Blueonyx@mail.blueonyx.it</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://mail.blueonyx.it/mailman/listinfo/blueonyx">http://mail.blueonyx.it/mailman/listinfo/blueonyx</a>
</pre>
</blockquote>
<pre wrap="">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
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Blueonyx@mail.blueonyx.it">Blueonyx@mail.blueonyx.it</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://mail.blueonyx.it/mailman/listinfo/blueonyx">http://mail.blueonyx.it/mailman/listinfo/blueonyx</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Blueonyx mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Blueonyx@mail.blueonyx.it">Blueonyx@mail.blueonyx.it</a>
<a class="moz-txt-link-freetext" href="http://mail.blueonyx.it/mailman/listinfo/blueonyx">http://mail.blueonyx.it/mailman/listinfo/blueonyx</a>
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
Gerald Waugh<br>
Front Street Networks<br>
(318) 734-4779<br>
(318) 401-0428
</div>
</body>
</html>