On Mon, Apr 25, 2022 at 09:38:50PM -0700, Greg Earle wrote:
> >> All of the sending hostnames are of the form
> >>
> >> www-data@vNNN-NNN-NNN-NNN.*.static.cnode.io
> >
> > That's not a hostname, it is an email address, and not clear whether
> > the
> > envelope sender or the "From:" message header.
>
> I originally just typed "vNNN-NNN-NNN-NNN.*.static.cnode.io" and added
> the "www-data@" at the last second. (No need to be pedantic; you know
> what I meant.)
Computers are pedantic, they do what you said, not what you meant. And
I don't know what you meant, because domain names appear in helo names,
envelope sender addressses, and message headers, and you failed to make
it clear where you observed these names. Failure to block the unwanted
traffic with helo restrictions suggests the names were not helo names.
> Return-Path: <www-d...@v163-44-207-233.a006.g.han1.static.cnode.io>
That's the envelope sender address, which you could block with
"check_sender_access".
> Received: from v163-44-207-233.a006.g.han1.static.cnode.io (unknown
> [163.44.207.233])
Here we see the HELO name and IP address (which fails FCrDNS lookup)
$ dig +noall +ans +nocl +nottl -x 163.44.207.233
233.207.44.163.in-addr.arpa. PTR
v163-44-207-233.a006.g.han1.static.cnode.io.
There is a PTR record for the IP address, but no forward A or AAAA record:
$ dig +noall +ans +nocl +nottl -t a
v163-44-207-233.a006.g.han1.static.cnode.io
$ dig +noall +ans +nocl +nottl -t aaaa
v163-44-207-233.a006.g.han1.static.cnode.io
$
So another (conservative) way to block these is with:
main.cf:
indexed = ${default_database_type}:${config_directory}/
# Possibly merged into recipient restrictions
smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unknown_reverse_client_hostname,
check_reverse_client_hostname_access ${indexed}revclient,
...
revclient:
# "postmap" after changes
# Clients in this domain require FCrDNS names
.static.cnode.io reject_unknown_client_hostname
static.cnode.io reject_unknown_client_hostname
And finally, the same can be done with HELO checks, though botnet
clients can easily change their HELO names to any string of their
choice.
main.cf:
indexed = ${default_database_type}:${config_directory}/
# Possibly merged into recipient restrictions
smtpd_helo_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unknown_reverse_client_hostname,
check_helo_access ${indexed}helo-access,
...
helo-access:
# "postmap" after changes
# Clients in this domain require FCrDNS names
.static.cnode.io reject_unknown_client_hostname
static.cnode.io reject_unknown_client_hostname
> >> [root@isolar tmp]# cat /etc/postfix/helo.regexp
> >> /v[0-9]+-[0-9]+-[0-9]+-[0-9]+[.-@]/ REJECT
> >
> > This pattern is not properly anchored, possibly matching lots of other
> > sources. A more conservative pattern would be:
> >
> > /^v[0-9]+-[0-9]+-[0-9]+-[0-9]+[.].*[.]static[.]cnode[.]io$ REJECT
>
> Thanks. I'm not too worried about any other "v[0-9]*" senders.
Note, I had left out the closing "/".
> It sounds like you are saying that I should be putting the
>
> check_helo_access regexp:/etc/postfix/helo.regex
>
> entry into some form of "smtpd_*_restrictions" in main.cf, right?
Correct. And then overriding the same for the submission entries in
master.cf, which enforce minimal restrictions beyond authentication.
--
Viktor.
