1

My Postfix server keeps getting used by spammers. Here is the output of sudo postcat -vq for the last spam message caught:

└──> sudo postcat -vq 3513818A8A
postcat: name_mask: all
postcat: inet_addr_local: configured 2 IPv4 addresses
postcat: inet_addr_local: configured 2 IPv6 addresses
*** ENVELOPE RECORDS deferred/3/3513818A8A ***
message_size:            8412             720               1               0            8412
message_arrival_time: Thu Aug 19 13:35:50 2021
create_time: Thu Aug 19 13:35:50 2021
named_attribute: log_ident=3513818A8A
named_attribute: rewrite_context=remote
named_attribute: sasl_method=LOGIN
named_attribute: sasl_username=root
sender: xfinity@fitprobands.com
named_attribute: log_client_name=unknown
named_attribute: log_client_address=93.122.252.4
named_attribute: log_client_port=16374
named_attribute: log_message_origin=unknown[93.122.252.4]
named_attribute: log_helo_name=109-166-129-221.orangero.net
named_attribute: log_protocol_name=ESMTP
named_attribute: client_name=unknown
named_attribute: reverse_client_name=unknown
named_attribute: client_address=93.122.252.4
named_attribute: client_port=16374
named_attribute: helo_name=109-166-129-221.orangero.net
named_attribute: protocol_name=ESMTP
named_attribute: client_address_type=2
named_attribute: dsn_orig_rcpt=rfc822;conyers811@comcast.net
original_recipient: conyers811@comcast.net
recipient: conyers811@comcast.net

Based on these two lines:

named_attribute: sasl_method=LOGIN
named_attribute: sasl_username=root

I believe the spammer is successfully logging as root and then sending their spam messages out of my server. And that's confirmed by running sudo cat /var/log/maillog | grep sasl_username=root which shows lot's of entries like:

Aug 19 17:13:15 mail postfix/smtpd[11442]: EA58D18CCD: client=unknown[93.122.252.4], sasl_method=LOGIN, sasl_username=root
Aug 19 17:13:17 mail postfix/smtpd[11442]: BDA4E18D32: client=unknown[93.122.252.4], sasl_method=LOGIN, sasl_username=root
Aug 19 17:13:19 mail postfix/smtpd[11442]: 7387E18D31: client=unknown[93.122.252.4], sasl_method=LOGIN, sasl_username=root
Aug 19 17:13:21 mail postfix/smtpd[11442]: 1C0FB18D34: client=unknown[93.122.252.4], sasl_method=LOGIN, sasl_username=root
Aug 19 17:13:22 mail postfix/smtpd[11442]: DCB4418D36: client=unknown[93.122.252.4], sasl_method=LOGIN, sasl_username=root
Aug 19 17:13:24 mail postfix/smtpd[11442]: B62DD18D39: client=unknown[93.122.252.4], sasl_method=LOGIN, sasl_username=root
Aug 19 17:13:26 mail postfix/smtpd[11442]: 6F52B18D38: client=unknown[93.122.252.4], sasl_method=LOGIN, sasl_username=root
Aug 19 17:13:28 mail postfix/smtpd[11442]: 24DEF18D3A: client=unknown[93.122.252.4], sasl_method=LOGIN, sasl_username=root
Aug 19 17:13:29 mail postfix/smtpd[11442]: A30B418D3C: client=unknown[93.122.252.4], sasl_method=LOGIN, sasl_username=root
Aug 19 17:13:31 mail postfix/smtpd[11442]: 88D8318D3B: client=unknown[93.122.252.4], sasl_method=LOGIN, sasl_username=root
Aug 19 17:13:33 mail postfix/smtpd[11442]: 11F6118D44: client=unknown[93.122.252.4], sasl_method=LOGIN, sasl_username=root

I have Dovecot running on the server besides Postfix, so checking the /etc/dovecot/conf.d/10-mail.conf files shows:

# Valid UID range for users, defaults to 500 and above. This is mostly
# to make sure that users can't log in as daemons or other system users.
# Note that denying root logins is hardcoded to dovecot binary and can't
# be done even if first_valid_uid is set to 0.
first_valid_uid = 1000
#last_valid_uid = 0

So I'm now lost how exactly the spammer is managing to authenticate as root. Goes without saying the root user is disabled on the system.

Any suggestions how to completely prevent sasl_username root from logging into the system?

anx
  • 6,875
  • 4
  • 22
  • 45
user102362
  • 15
  • 3
  • I suspect you are not using Dovecot to validate sasl logins. The output of the command `postconf smtpd_sasl_type` will tell. I also doubt that you have a good reason to accept authenticated submissions on port 25 (the line starting `smtp inet`), so review your master.cf and ensure that `-o smtpd_sasl_auth_enable=yes` only appears attached to services meant for submission (the line starting `smtps inet` and optionally `submission inet`). – anx Aug 20 '21 at 08:17
  • 1
    You were right: running `postconf smtpd_sasl_type` has pointed to `cyrus`. But then searching for `cyrus` on the system shows some entries in `selinux` (which is disabled) and some in `/usr/share/doc/`, so no any configuration files. – user102362 Aug 21 '21 at 05:36

2 Answers2

1

Without knowing who setup that system that way and why, I cannot give specific recommendation. But I can say that the overwhelming majority of servers where Dovecot handles IMAP authentication are well served by letting Dovecot also handle SMTP authentication, and that is how your Dovecot configuration first_valid_uid would become effective for mail submission as well.

Read the relevant documentation and then consider configuring your Postfix to defer authentication to Dovecot, typically these lines in main.cf:

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

Additionally, consider setting smtpd_sasl_auth_enable = no in main.cf and removing the first smtpd_sasl_auth_enable=yes up in your master.cf. Authentication is typically only desirable for services meant for submission (the line starting smtps inet and optionally submission inet), so it should be enabled only for one or two such services via master.cf. This would break clients that use port 25 to submit authenticated mail - but such clients configuration probably need review anyway if you are changing onfiguration.

anx
  • 6,875
  • 4
  • 22
  • 45
  • Once *new* submission are properly restricted, you still have to deal with previously submitted and still queued mail, for that you likely want to use [postsuper](https://serverfault.com/search?q=postsuper). – anx Aug 21 '21 at 07:37
  • The system came set in that way together with Webmin/Virtualmin. Setting `smtpd_sasl_auth_enable=` to `no` in line that starts with `smtp` in master.cf file seems to have stopped all undesired sasl auth attempts, at the same time giving legitimate users to continue to use their mail clients. Thanks a lot! – user102362 Aug 24 '21 at 05:34
  • @user102362 Just to be super clear here: Disabling the authentication features on one particular port where it is unnecessary may stop one particular bot abusing your misconfigured authentication setup - *but you still must fix* your authentication configuration, as your server could still be abused that way on the other ports used by legitimate user! – anx Aug 24 '21 at 11:52
1

Lately I have had exactly the same on my uptodate Ubuntu box. I am sure I had smtpd_sasl_type = dovecot and smtpd_sasl_path = private/auth set.

I have the same question as user102362 has: when I read this in my config:

# Note that denying root logins is hardcoded to dovecot binary and can't
# be done even if first_valid_uid is set to 0.

I assume that its not possible to authenticate as root. But then, WHY is this possible:

Jan 19 21:16:46 VPS postfix/smtpd[9392]: EF1B6BD5B8: client=unknown[213.233.y.x], sasl_method=LOGIN, sasl_username=root

and resulted in sending lots of unsolicited mail?

Coincidence or not, the (successful) SASL authentications came from the same country and operator, so I decided to block the following blocks completely:

93.122.128.0/17
213.233.88.0/24
46.97.176.0/21
178.138.64.0/18
109.166.128.0/17

And I changed the root (and other accounts) password.

Jarris
  • 11
  • 1