On 12 Jun 2015, at 11:05, Forrest wrote:
Since upgrading to Postfix, my system is seeing a lot of this
activity. My prior config was Sendmail 8 with Cyrus SASL which did
not.
This is a pure coincidence. I administer multiple mail servers running
Postfix. CommunigatePro, and Sendmail, and ALL have seen order of
magnitude (or 2) increases in AUTH brute force attacks from apparent
botnets in the past 3 months. I doubt your upgrade influenced the attack
rate against a CGP server in Switzerland handling an obscure set of
small business domains. :)
My favorite theory is that the growing stream of publicly available data
on password frequency and big sets of username+password combos (i.e.
breach dumps) being sold around the "dark" net has combined with steady
improvement in spam blocking to push botnet operators into this tactic
to find trusted mail submission paths. In my own case, well over half of
the spam aimed at my most-spammed address that Postfix has accepted for
delivery in 2015 shows solid evidence of being sent through a
compromised account on a legitimate mail system. That's a thin trickle
of messages (<1/day) because thousands of times every day Postfix tells
a spammer to keep his spam for that address.
My guess from this log is that AUTH is taking place unencrypted, which
may be the cause?
AUTH is being *attempted* unencrypted. Which isn't ever going to work
because...
My server advertises (EHLO):
250-PIPELINING
250-SIZE [ omitted ]
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 8BITMIME
Try sending an AUTH command after that. Note the response.
If Postfix doesn't advertise AUTH it is because you are in a state where
AUTH intentionally is disabled and cannot possibly work. It is generally
a bad idea to offer AUTH over unencrypted sessions anyway, so that's
good.
While I'm digging through the config (being somewhat a postfix
newbie), might someone comment on how I can discourage this type of
activity?
You really can't. All you can do is block it after you detect it.
Nothing will stop a bot that knows only how to do one thing from doing
it until its operator tells it to stop. The operators are not really
very bright to begin with, so they try really useless stuff, but they
aren't being stupid by being indiscriminate about targeting: hitting
everything with a SMTP listener isn't a waste of THEIR resources, it is
a waste of HIJACKED resources. Being selective about targets would just
run the risk of missing unexpected weaknesses. Historically there have
been MTAs that have optionally not advertised AUTH without actually
disabling it; as long as both banners and EHLO feature replies MIGHT be
lying about the nature of an MTA, a bot operator might as well assume
that it might have any of the weaknesses ever seen in any MTA ever.
Consider how this is consistent with the tactic of brute-force password
guessing.
I'm trying to understand what the bots and script kiddies are seeing,
that wasn't there before, that is advertising capability to do this.
You are assuming too much thinking on the part of the bots and their
operators. Remember, this is an industry where the most successful and
widespread spambot has been getting caught by greeting pauses for a
decade but still fast-talks with a perfectly-identifying invalid EHLO on
zombie hordes of simultaneous connections. 36 hours ago, a botbox on a
Ukraine DSL link tried opening 2 rounds of ~200 parallel connections to
my personal (<10 humans, 8 domains, untold bajillions of valid local
addresses...) mail server's submission port about a minute apart and
tried to do clear text AUTH on each one despite the fact that the first
6 in each batch got a "530 5.7.0 Must issue a STARTTLS command first"
reply and the rest all got whatever Postfix says to clients that it
reports as "Connection rate limit exceeded". This morning it was a
rather less aggressive Russian machine. In both cases no TLS was
attempted, they just spewed AUTH commands that failed plus 2 bogus
commands that Postfix only logged as "unknown". Postfix never asked
Dovecot about any of the AUTH attempts for the simple reason that
Postfix is configured not to allow AUTH without TLS:
"smtpd_tls_auth_only = yes"
For most of the past month, that overworked machine has been defending
itself from port 25 bot attacks by a fail2ban-like trick of feeding
syslog 'mail' messages into a script that blocks all further packets
from miscreant IPs. That tactic reduces the overall connection burden
and log noise of the port 25 attacks, but I'm still seeing as many new
sources per day as I was before I started that and many of the blocked
IPs keep coming back for weeks after their last successful connection.
Doing that on port 587 would be trickier (no postscreen, legitimate
reasons for humans doing AUTH there, etc.) but it might be worthwhile
given the recent boom in password-guessing attacks.
Such attacks are a part of the latest tactical refuge of purely criminal
spammers. They won't stop until it is generally not worthwhile for those
people to use password guessing to compromise accounts through which
they can send the worst sorts of spam. IMHO that means they will
continue until it is the norm for everyone to use a different and strong
password for each system they use online.
So, yeah: never gonna stop.
