On 2021-09-07 7:11 p.m., Bill Cole wrote:
On 2021-09-07 at 14:42:33 UTC-0400 (Tue, 7 Sep 2021 19:42:33 +0100)
Adam Weremczuk <ad...@matrixscience.com>
is rumored to have said:
Hi all,
It's postfix 3.1.6-0+deb9u1 on Debian 9.
Since enabling STARTTLS on port 25 I'm getting lots of traffic looking
like this (relay attempts?):
This does not actually have anything to do with STARTTLS.
Sep 6 09:17:42 localhost postfix/smtpd[14622]: connect from
unknown[77.247.110.240]
Sep 6 09:17:42 localhost postfix/smtpd[14622]: setting up TLS
connection from unknown[77.247.110.240]
Sep 6 09:17:42 localhost postfix/smtpd[14622]:
unknown[77.247.110.240]: TLS cipher list
"aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
Sep 6 09:17:42 localhost postfix/smtpd[14622]:
unknown[77.247.110.240]: Issuing session ticket, key expiration:
1630916885
Sep 6 09:17:42 localhost postfix/smtpd[14622]: Anonymous TLS
connection established from unknown[77.247.110.240]: TLSv1.2 with
cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Sep 6 09:17:42 localhost postfix/smtpd[14622]: lost connection after
AUTH from unknown[77.247.110.240]
Sep 6 09:17:42 localhost postfix/smtpd[14622]: disconnect from
unknown[77.247.110.240] ehlo=2 starttls=1 auth=0/1 commands=3/4
Sep 6 09:17:42 localhost postfix/smtpd[14592]: connect from
unknown[77.247.110.240]
Sep 6 09:17:42 localhost postfix/smtpd[14592]: setting up TLS
connection from unknown[77.247.110.240]
Sep 6 09:17:42 localhost postfix/smtpd[14592]:
unknown[77.247.110.240]: TLS cipher list
"aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
grep 77.247.110.240 /var/log/mail.log | wc -l
16735
That's AUTH probing. A bot on 77.247.110.240 has a big list of usernames
and password and is testing them one at a time.
It's a different IP(s) every day so banning them manually is not going
to work well.
If you only offer AUTH on submission services (ports 465 and 587) you
can safely block large chunks of network space from accessing those
ports. The networks were these sorts of bots are common are almost
certain to never have one of your legitimate users on them trying to
authenticate. In fact, for most mail systems, one can safely drop
packets headed to 465 and 587 for the overwhelming bulk of the Internet
and never cause trouble.
I've tried fail2ban but the postfix and postfix-rbl jails seem to be
based on sever error codes which are not produced here e.g:
As has been suggested, looking for 'auth=0/' in the log is a useful
pattern for fail2ban or other log-scanning tools.
Any idea how to effectively ban these abusers?
To start, disable AUTH on port 25. You may need to get users (and
devices that generate mail) to change their configs to use port 587
(with STARTTLS & AUTH) or 465 (with implicit TLS & AUTH) before making
that change.
With no legitimate users trying to authenticate on port 25 and no
advertisement of AUTH on port 25, you should see a huge reduction in
port 25 AUTH probing. You will still see probes on 465/587 but you can
block those either with something like fail2ban looking for 'auth=0/'
repeatedly from the same address and/or by manually finding those
addresses and passing your own judgment on whether the enclosing /24 (or
even /4!) can be safely blocked from those ports.
Hi,
In this case, is the botnet actually trying credentials ? It looks to
me that it is establishing a TLS connection and then dropping it (or am
I mistaken ?).
If it is just establishing TLS and is not actually trying credentials,
why would a botnet do that ?
Thanks,
- J
