Hello, I am using the latest version of Virtualmin Pro and I have noticed that some people are using the user debian@mydomainforexample.com to send emails. Currently, the debian user is not associated with any email address; it only exists in /etc/passwd as a user who cannot connect via SSH. However, Postfix recognises it as a real system user and allows email relaying. Does it serve any purpose, or can it be deleted? Is there anything I can do to prevent this behaviour?
Virtualmin did not create that user, unless you used Virtualmin to create that user.
Allows email relaying in which direction? Are you saying you’re receiving mail for that user (harmless, minor annoyance), or are you saying spammers are sending with that user (disaster, indicative of some sort of compromise, possibly a web app, possibly a user account)?
Was this user possibly created as a default with a provider image install? I shudder to think they would use the same default password on each instance, but… 
Makes no sense that a user would be created just to disallow ssh for that user. Any user is a real user.
Yes, the attacker sent emails to people. And i didn’t create this user debian. This is why i asked if i can delete. At end i deleted it.
And I set more secure parameters in the postfix and dovecot servers. I also uninstalled exim4, which I don’t use. I no longer see any emails coming out now.
Yes may be it was a default user created by exim4 or by the vps provider. For sure i didn’t create it. It was already disallowed to ssh login but the problem is that dovecot don’t care if is allowed or not. Or so it seems, and if there are no specific parameters, dovecot lets the relay proceed anyway.
No.
Quite likely.
Dovecot is not involved in sending email, it is a POP3/IMAP server.
Postfix is your SMTP server in a Virtualmin system (though you said you have exim4 installed, which would conflict with Postfix, so I don’t know what’s happening there). SMTP is how email is sent.
There is also a Dovecot SASL authentication server, which could be used to authenticate remote SMTP users, but we don’t use it in a Virtualmin system, we use Cyrus saslauthd.
Any local user can send email in a variety of ways. If someone is able to log into your system via some shell-like mechanism, they can send email. Even if Postfix does not allow them to send mail, they could run any of a variety of scripts that can send email, or even their own local SMTP server. SMTP is a stupidly simple protocol, and you can send email with a few lines in a bash, Perl, PHP, Python, whatever script. If someone has a shell on your system, they can send spam, if that’s what they want to do, regardless of Postfix configuration.
Thank you for the quick answer.
Debian-exim:!:xxx:xxx::/var/spool/exim4:/usr/sbin/nologin:::::
May be it was an user created by exim when it saw the debian user. I deleted this user too after removing user debian.
There were no SSH logins; I checked the logs and last -x. In any case, the only hostallow is the host I use to log in, and the iptables are set to logging mode. It sends me an email every time someone logs in, every minute. To be on the safe side, I also ran anti-rootkit scans in case someone had masked some activity, and I checked the signatures.
I also read that dovecot “alone” does not send emails but needs postfix, which accepts local users by default. The changes I made to Dovecot to make it secure were to enable only TLS/SSL and the changes I made to Postfix. As for Postfix, which otherwise sends, if I’m not mistaken, the default Virtualmin settings are these:
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
Correct?
I put these:
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination
smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unauthenticated_sender_login_mismatch, check_sender_access hash:/etc/postfix/sender_access
Is this correct?
From what I understand, local users without shell access could send emails via sendmail or local Postfix because Postfix considers all users on the system to be valid local senders if they belong to mynetworks or use the local queue.
The default configuration did not distinguish between legitimate users and “debian” users without passwords or with default passwords.
local_only and reject_sender_login_mismatch in the previous configuration were not sufficient if the user was considered local by Postfix.
I read DSA 554-1, which says that some users used default SASL credentials or no password. I don’t know if this is the case, but I don’t think so because the packages have been updated since then.
Among other things, I also set authorized_submit_users, which was not there, and this is understandable because you can never know for sure, and it would be too restrictive by default.
I also thought that an attacker could have used a bug in the panel scripts to inject code and exploit the default settings of Postfix, which give local users free rein to do whatever they want, but I see these things in the logs:
mail postfix/smtpd[2141657]: xxxxxxxx: client=unknown[xx.xx.xxx.xxx], sasl_method=LOGIN, sasl_username=debian
I put the x’s in to avoid specific references. In short, someone remotely authenticated to sasl and sent the emails, but I don’t understand how this is possible. Or at least I’m not sure. The fact is that the emails were sent, and after I removed that system user and applied the configuration changes, I no longer see any emails going out. I noticed this by chance because the user did not exist as an email user and therefore went to the main email where I receive all emails sent to non-existent mailboxes, since I am the only one who uses this domain and this server to send emails, or so it should be. Of course, I don’t recognize the IP in the log.
I later noticed, while reading some very old logs from the journal associated with this Debian, that there was a packer-os-template from a local internal IP that is not present within my VPS. It is possible that it is a default user that is used by the VPS provider when the machine is generated. I therefore suppose that the combination of the postfix configuration parameters and this packer-os-template with the default Debian user created the problem.
Could this be a plausible hypothesis?
“Debian-exim” is a user for exim4 SMTP server.
you use postfix, so you don’t need exim4 stuff nor the Debian-exim user.
but totally irrelevant to “debian” user.
this user could be anything really, check system and virtual server users to see when this user was created, home dir, etc..
Webmin → System → Users and Groups
I am waiting for a response from my provider to verify whether this is a service user they have created.
why would an isp service send emails from your machine? do you use some service that sends out emails? and where does it send out emails to?
if it’s spam, you should disable this user asap, not wait for provider to respond.
2c.
What I meant was that some providers use a user with the template to generate virtual machines or manage them through portals. Then the combination of standard parameters set by Virtualmin did the rest. Or at least that’s how it seems, since when I changed the settings, the emails stopped immediately. Of course, I have already removed that user. Now I’ll see what the provider says.
yes, i understand that. they could be using a user for their cloud-init or whatever.
still that doesn’t explain why this user would login from some foreign address to send email. (email to whom? does it send messages to the provider? )
smells scammy, not provider related, but anyway…
I asked the provider of vpx to understand better and to close the circle.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.