On 04/12/2015 15:59, Hector Santos wrote:
I have seen tons of "auth-cracking/brute force" auth attempts done at
all the IP protocol servers. Generally, they do it all in one
connection session where a "Maximum Failed Login Attempt" count may is
used. I always knew it was possible, but I suppose there are now
increased distributed "botnet" forms of this where the Failed Login
Attempt Count would be reset at the connection. I have not seen the
need to do much because I am not seeing damage. Everything (robust
high scale servers) have been in place for many years, you know "Set
it and forget it."
We used to see things connect and try lots of logins until they got
blocked (they'd actually carry on for a bit after that because we don't
tell them they've been blocked)
Now, we see lots of IP addresses connecting and making one or two login
attempts then giving up. It's obviously a concerted 'attack' because
lots of IP addresses do it at the same time, but each individual IP
address doesn't try much. This does tend to defeat our software's
blocking system, and it's a bit tricky to get around given that our
software is on individual small business servers which might only see a
few hundred auth attempts every few days, rather than huge mail
providers which I guess see a lot more.
What I'm thinking of is having the option of the software reporting
failed login IPs 'home' to a central server here, which other
installations can query through a DNS lookup, but I'm still pondering
whether that would help or hinder (the extra load of reporting &
querying may override the load of dealing with the failed logins). If
two or more of our software installations receive failed login attempts
from the same IP address within a day or so of each other, the chances
are it's a bot.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp