On Thu, Oct 22, 2020 at 10:44:06PM -0700, Rich Wales wrote:
> I have removed permit_mynetworks from my smtpd_relay_restrictions. (I
> still have permit_mynetworks in the smtpd client, HELO, sender, and
> recipient restrictions.) In case this change might have broken
> something (which it doesn't appear to have done), I also enabled
> soft_bounce=yes.
This of course disables outbound submission on port 25, but that's
generally a good idea anyway.
> Shortly thereafter, I found one (and, so far, only one) incident in my
> log where an open relay message apparently originated from my server
> itself.
>
> Oct 21 20:22:33 memoryalpha postfix/postscreen[4751]: CONNECT from
> [193.169.253.190]:63634 to [10.0.229.197]:25
> [...]
The source IP is listed by multiple RBLs (perhaps a few too many
configured, but whatever...)
> Oct 21 20:22:33 memoryalpha postfix/postscreen[4751]: CONNECT from
> [127.0.0.1]:40434 to [127.0.0.1]:25
> Oct 21 20:22:33 memoryalpha postfix/postscreen[4751]: WHITELISTED
> [127.0.0.1]:40434
> Oct 21 20:22:33 memoryalpha postfix/smtpd[4764]: connect from
> localhost[127.0.0.1]
Fascinating, this would be a good time to post your master.cf settings,
i.e. verbatim, without refolding of lines output of:
$ postconf -Mf
and also your main.cf settings, i.e. verbatim, without refolding of
lines output of:
$ posconf -nf
> Oct 21 20:22:34 memoryalpha postfix/smtpd[4764]: NOQUEUE: reject: RCPT
> from localhost[127.0.0.1]: 454 4.7.1 <spam...@tiscali.it>: Relay access
> denied; from=<spam...@tiscali.it> to=<spam...@tiscali.it> proto=ESMTP
> helo=<WIN-NT9DHV1HPCJ>
Yes, the HELO name, sender and recipient above match the corresponding
information in the postscreen reject message below.
> Oct 21 20:22:39 memoryalpha dovecot: imap-login: Aborted login (no auth
> attempts in 0 secs): user=<>, rip=127.0.0.1, lip=127.0.0.1, secured,
> session=<Tvvn+TmyNq9/AAAB>
But note also "dovecot" showing up here. It looks like the spammer is
using some feature of Dovecot to originate a connection to the Postfix
SMTP server.
> Oct 21 20:22:39 memoryalpha postfix/postscreen[4751]: DNSBL rank 78 for
> [193.169.253.190]:63634
Impressive DNSBL score!
> Oct 21 20:22:40 memoryalpha postfix/postscreen[4751]: NOQUEUE: reject:
> RCPT from [193.169.253.190]:63634: 450 4.7.1 Service unavailable; client
> [193.169.253.190] blocked using zen.spamhaus.org;
> from=<spam...@tiscali.it>, to=<spam...@tiscali.it>, proto=ESMTP,
> helo=<WIN-NT9DHV1HPCJ>
Note the matching "helo". The two connections sure look related.
> The postscreen process (PID 4751) initially fielded a connection from
> 193.169.253.190 (port 63634) -- an IP address, btw and fwiw, which is
> assigned to a hosting service in Estonia. But before rejecting this
> connection (because the IP address was blacklisted), another connection
> sprang into life from 127.0.0.1 (port 40434).
Perhaps via some component of Dovecot? Is your Dovecot up to date and
patched?
> Basically, it looks to me
> as if the connection from 127.0.0.1 was somehow nested inside the
> connection from 193.169.253.190.
No, not nested inside, just concurrent.
> This could just be a coincidence, but
> the fact that all this activity happened within a single postscreen
> process (PID 4751) confuses me -- can anyone explain this?
There's only ever one postscreen process, it handles multiple concurrent
connections, that is its purpose in life. See POSTSCREEN_README.
> Correlating the above with other logs on my server, an inbound SMTP
> connection from 193.169.253.190 on remote port 63634 was accepted and
> logged by iptables. No connections from 193.169.253.190 show up in my
> server's Apache logs.
It looks more like connection proxying then a web server exploit.
> So, again, can anyone suggest an explanation for why a complete Postfix
> connection from 127.0.0.1 is seemingly embedded inside a complete
> Postfix connection from 193.169.253.190?
Your Postfix and Dovecot configurations would be useful at this point.
--
Viktor.
