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?

2
  • 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, 2021 at 8: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, 2021 at 5:36

2 Answers 2

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.

3
  • 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.
    – anx
    Aug 21, 2021 at 7: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, 2021 at 5: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, 2021 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.