On Fri, Oct 23, 2020 at 02:14:58AM -0400, Viktor Dukhovni wrote:
> On Thu, Oct 22, 2020 at 10:44:06PM -0700, Rich Wales wrote:
> > 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.
Of course that could just be smtpd enabling Dovecot auth, though you
should probably not enable SASL on port 25. In which case "Dovecot"
may be a distraction.
>
> > 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.
One interesting question is whether you somehow have TCP fast open
enabled by default. If the purpose of the first connection is to obtain
a TFO cookie, and somehow the second connection is able to use this
cookie (weak validation?) to send an entire SMTP transaction along with
the SYN packet, but this time with 127.0.0.1 as the source address, then
the use of two connections for the attack starts to make sense.
Of course TFO is supposed to provide some cryptographic protection
against spoofing the source address. So something odd is happening
if that's the actual story.
Do you have any non-default network kernel parameter settings that
might be related to TCP fastopen?
Perhaps a previously implanted backdoor makes this form of attack
possible.
--
Viktor.
