John Fawcett:
> Hi
>
> I'd like to make two suggestions for additional logging.
>
> The first one is to leave an explicit trace in the log when starttls is
> enforced (for example on the submission port) but the client does not
> issue STARTTLS.
There is no code in Postfix to log something that did not happen
just like header_checks etc. have no code to trigger on non-existent
information.
However the Postfix SMTP server logs all commands that are issued in a
session. For example, to find dictionary attacks, look for sessions
with unsuccessful AUTH commands:
$ bzgrep 'auth=[0-9]*/' /var/log/maillog.201812*
/var/log/maillog.20181212.bz2:Dec 12 23:03:45 spike
postfix/smtpd[76684]: disconnect from unknown[203.2.114.149]
ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
[and many more from that client]
Or simply grep for "auth=0" for the common case of unsuccessful
dictionary attacks.
> The second one is to explicitly log that a protocol error has occurred.
> Currently I get protocol errors via email to postmaster with
> notify_classes = protocol setting, but I'd like to switch that off and
> get an informational message in the mail log. I would find logged
> messages easier to handle with automated tools.
You may not like the email, but it is the only way to find out
what needs fixing. Postfix just knows the client screwed up but
is not always smart enough to figure out why.
Wietse
> The most frequent situations I see STARTTLS not being used on the
> submission port is dictionary attacks via scripts that connect to the
> submission port and blindly issue AUTH LOGIN. The same goes for protocol
> errors on port 25 where AUTH is not enabled, but scripts blindly issue
> AUTH LOGIN that results in the protocol error to the postmaster email.
>
> For the second message I did think of a more general alternative, which
> would be to have a "log_classes" parameter which mirrors
> "notify_classes", though clearly that would be a bit more work to do and
> much of what notify classes does is already logged in some way, but not
> the protocol errors.
>
> John
>
> --- smtpd/smtpd.c.orig??? 2018-12-28 13:18:55.427162049 +0100
> +++ smtpd/smtpd.c??? 2018-12-29 11:25:49.294927986 +0100
> @@ -5677,6 +5677,8 @@
> ???? ??? if (var_smtpd_enforce_tls &&
> ???? ??? !state->tls_context &&
> ???? ??? (cmdp->flags & SMTPD_CMD_FLAG_PRE_TLS) == 0) {
> +??? ??? msg_warn("Missing required STARTTLS command from %s",
> +??? ??? ?????????? state->namaddr);
> ???? ??? smtpd_chat_reply(state,
> ???? ??? ??? ?? "530 5.7.0 Must issue a STARTTLS command first");
> ???? ??? state->error_count++;
> @@ -5699,8 +5701,12 @@
> ???? ??? ??? ?cmdp->name, state->namaddr, STR(state->expand_buf));
> ???? ??? state->flags |= SMTPD_FLAG_ILL_PIPELINING;
> ???? ??? }
> -??? ??? if (cmdp->action(state, argc, argv) != 0)
> +??? ??? if (cmdp->action(state, argc, argv) != 0) {
> ???? ??? state->error_count++;
> +??????????????? if (state->error_mask & MAIL_ERROR_PROTOCOL)
> +??? ??? ??????? msg_info("smtp protocol error in %s from %s",
> +??? ??? ??? ?????? cmdp->name, state->namaddr);
> +??? ??? }
> ???? ??? else
> ???? ??? cmdp->success_count += 1;
> ???? ??? if ((cmdp->flags & SMTPD_CMD_FLAG_LIMIT)
>
>
