[BlueOnyx:12769] Re: Unauthorized Relaying
Gerald Waugh
gwaugh at frontstreetnetworks.com
Wed Apr 3 14:47:15 -05 2013
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:busted at 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 "frank at 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,frankd at 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 at 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 at mail.blueonyx.it
>> http://mail.blueonyx.it/mailman/listinfo/blueonyx
>
>
>
> _______________________________________________
> Blueonyx mailing list
> Blueonyx at mail.blueonyx.it
> http://mail.blueonyx.it/mailman/listinfo/blueonyx
--
Gerald Waugh
Front Street Networks
(318) 734-4779
(318) 401-0428
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20130403/07b1a360/attachment.html>
More information about the Blueonyx
mailing list