On Sat, Feb 25, 2017 at 08:23:44AM +0000, Dominic Raferd wrote:
> On 25/02/2017 05:28, Noel Jones wrote:
> >On 2/24/2017 5:55 PM, James wrote:
> >>I was hoping there might be some setting that would cause log
> >>entries like:
> >>
> >>postfix/smtpd[12345]: NOQUEUE: AUTH rejected from
> >>client.example.com[0.1.2.3], sasl_method=PLAIN,
> >>sasl_username=spam_r_us
> >>
> >>As long as the sasl_username was obviously hopeless then I
> >>wouldn't worry... but if they started using something that
> >>I thought they shouldn't know about then I'd start getting
> >>worried.
A comment here: at any kind of scale it will not be easy (I am
tempted to say "not possible") to make such a determination of a
worrisome condition other than by manual reading of these logs.
> >I'm pretty sure the sasl_username part of the log (and probably
> >the method too) is supplied by the sasl library, which is never
> >called when sasl isn't offered.
> >
> >When sasl isn't offered but the client sends AUTH anyway, it
> >should be possible for postfix to log the (sanitized) AUTH
> >command the client sends, but it will be encoded. The
> >encoding as recorded in the log may be (I think likely)
> >broken by the log sanitizer.
On Sat, Feb 25, 2017 at 08:23:44AM +0000, Dominic Raferd wrote:
> If you use dovecot for SASL authentication with settings log_path =
> syslog, auth_verbose = yes, then you can see attempted logins and
> the reason for failure easily enough:
>
> # grep "dovecot: auth: " /var/log/mail.log
But we are talking here about a case in which AUTH is not offered.
Again, as Noel pointed out, smtpd is not going to pass that forbidden
AUTH command to Dovecot.
What the OP wants is perhaps most closely related to the
reject_unauth_pipelining restriction, but for a specific ESMTP
command. But pipelining is different, as although it is enabled also
by virtue of an EHLO keyword, it's not a specific command; it's the
method by which a client presents multiple commands at once.
So in this case I suspect the actual code path is in the area of
smtpd_{hard,soft}_error_limit. At this point does smtpd know
anything about AUTH, or is it just one of infinite possible protocol
errors? Would it be feasible to treat it specially?
I don't think the OP's request is entirely without merit. Anything
which gathers information on botnets is good. This looks like a
possible case for log parsing and fail2ban. But I bet we usually
already know we're looking at a zombie without this extra bit of
information, so I wouldn't consider it a high priority.
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
