Dean Brooks wrote:
> On Thu, Sep 27, 2007 at 09:39:14AM +1000, Ted Cooper wrote:
>> Phil (Medway Hosting) wrote:
>>> I am getting a lot of entries like these in my logs over the last few days:
>>>
>>> 2007-09-23 05:00:08 fixed_login authenticator failed for (windows) [64.62.22.218]:8204 I=[84.40.17.13]:25: 535 Incorrect authentication data (set_id=maxwell)
>> I've had a few of these too. I believe it's just a bot attempting an
>> automated attack as I've had them on try on sequential IP addresses.
>> They are usually also on zen.spamhaus.org. Pretty sure the aim is to
>> find correct login details so they can use your servers to spam the crap
>> out of everyone. Creating something in the smtp_auth_acl to temporarily
>> firewall these computers is on my TODO list.
>
> I dealt with this exact situation recently. I have a ratelimit
> implementation (below) that automatically begins dropping connections
> to sites that repeatedly fail authentications.
>
> It does require use of the quit and notquit ACL sections since the
> auth ACL section apears to run prior to authentication, not after.
> You also can't drop in the mail/rcpt/data ACLs since the session will
> likely end after the failed auth attempt. Hence, the quit and notquit
> ACLs are necessary.
>
> In my "connect" ACL:
>
> drop
> log_message = RATELIMIT BADAUTH: $sender_rate / $sender_rate_period
> message = Too many failed authentication attempts
> ratelimit = 50 / 2h / noupdate / badauth:$sender_host_address
> delay = 10s
>
> In both the "quit" and "notquit" ACLs:
>
> accept
> condition = ${if eq{$authentication_failed}{1}}
> ratelimit = 50 / 2h / badauth:$sender_host_address
>
> Obviously you can change the "50 / 2h" to any other period you want.
> Just make sure all three acl entries use the same values. The quit and
> notquit ACL entries are *both* needed since you don't know whether or
> not the session will be terminated gracefully by the sender or not.
>
> The only thing to watch out for here is locking on the ratelimit database.
> Every single connection will require an open and lock of the ratelimit
> database. If you have your db directory on ramdisk, or if you have a
> low volume server, you should be fine though. To be honest, I haven't
> noticed much of a problem even on a high volume server with db on
> regular disks though.
>
By the logs, the connections are directed to port 25. Couldn't you just
forbid authentication on port 25 and limit it to ports 587 and 465?
Using mandatory encryption for auth could also help in this case.
I guess it will take some more time for spammers to figure out auth is
only running on 587 or 465 or to encrypt connections.
