On 12/4/2015 8:10 AM, Chris Lewis wrote:
On 12/03/2015 09:11 PM, Ted Lemon wrote:
Can you unpack "AUTH-cracking spambots" for the greenhorns? I have
no idea what this means, and google unfortunately was unable to help.
Primarily botnets that connect to MSAs and use stolen (or potentially
brute-forced) userid/password credentials in order to use the MSA/MTA
combo as an open relay.
...
AUTH-cracking to this extent is a relatively recent phenomena, and is
clearly being used as an attempt to bypass normal direct-2-MX botnet
blocking and hijack the reputation of the MTA instead of some random
cracked PC.
Hi, I'm surprise to read you say this is "relatively recent." Are you
mean in months, years or one to several decades?
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."
Overall, having robust 24x7x365 load balancing/control IP
tracking/blocking server(s) is par for the course, so this is more
about relaxing the STD10/RFC2821/RFC5321.Received SMTP receiver
protocol requirement to help avoid mitigate negative correlation
methods with ESMTP AUTH, right?
Incidentally, what I am seeing more of late, are single or "botnet" IP
connections that do nothing, i.e. they sit there idle and they don't
attempt to login. What is interesting is that if you (force)
close/drop it, they immediately reconnect with the same IP.
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp