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.
Critiques or alternatives are welcomed.
--
Dean Brooks
dean@???
