TIP: Better security for mails to avoid being blacklisted. Block direct-to-MX attacks

Hi, this is not a Hestia related topic, but i think this will be useful for many of you. As I can imagine you suffer from attacks to clients sites hosted on your servers, specially if you are running CMS like wordpress.

In my case, i manage more than 450 sites, and sometimes one of them gets infected.
When a site is compromised, a very common symptom is to see some executable being executed by the unix user that owns that site. Programs executed by hackers are used to send spam, mine crypto, or phishing related stuff.

If the program is used to mine crypto you will probably see the server very slow, or maybe your provider alert you about it and aks you to fix it.
If the problem is phishing related you will probably see a red flag warning by google and others alerting the user of malware on that site, and of course also you may receive some complain from your server provider. But after cleaning all will be alright if you catch it soon.
But the most damaging case of all is when the hackers start sending spam from your server. Because after the attack your IP reputation will suffer, your legit mail will be blocked or mark as junk, and you will need to ask every blacklist to unlist your IP, this process is painful for sysadmins and clients.

You can say to me: disable SSH access to users. And you will be right. But in our case we use SSH a lot, automated scripts that runs under regular users, and also support engineers and developers needs to be able to run commands under regular users, so disabling SSH is not an option for us.

I already add some extra security to exim, for example i disable completely ports 143 and 110, so all communication is thru secure protocols. Also i completely disable unix users ability to send mail thru Exim without authentication (the type of emails sended by PHP scripts). I force every project hosted on the server to use phpmailer and authenticate via SMTP. Also i add a spam filter to outgoing mail using exim config.

But there are cases were the attacker managed to run a binary that sends spam directly connecting to port 25 on destination, bypassing exim, in other words, they mount an alternative MTA inside the infected user and starts to send a lot of junk email. This is very bad because you will not see this activity on exim logs or any other place on the server.

Completely avoid this type of exploits is very difficult, but what we CAN DO, is mitigate the effect of this malware. And this can be accomplish with this 2 simple rules for iptables:

iptables -A OUTPUT -p tcp -m tcp --dport 25 -m owner --uid-owner Debian-exim -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j DROP

The first rule is using owner module for iptables and basically is allowing the user Debian-exim (the unix user that runs exim service) to connect to remote 25 port.
The second rule is denying the connection to remote 25 port to any other user in the system.
(the order of rules is important).

If you need the rules to persist after reboot install iptables-persistent
apt install iptables-persistent
This will save current rules to /etc/iptables/rules.v4 and /etc/iptables/rules.v6 and this will be automatically loaded on boot time.

After doing that every user will be forced to use exim authentication in order to send mail thru our server.

This will not prevent wordpress or other CMSs sites from being compromised, you will still need to maintain the code updated and follow all the web security recommendations. But in the case you get compromised at least your IP reputation will not suffer too much.

I suggest to add this feature in any new hestia install, or at least to have an optional “Better security for mail system” option.

Let me know your thoughts.

4 Likes

Feel free to submit it a PR it will not hurt as an additional security measure …

1 Like

Thank you for your TIP. I completely support your security enhancement.

In my case, I use separate servers for websites and email and therefore I can’t give my clients a single panel to manage everything.

If the security increased significantly, I could consider to use hestiaCP as it was designed: one server with everything.

1 Like

I also support this. But I have a question… does the proposal only address the problems on debian servers? All I use is debian, so it is not an issue with me. But there are some people who use Ubuntu.

Ubuntu also has a mail user it is only different if I am right…

You are right. Ubuntu may also work with the above code as Ubuntu is a child of Debian.

But sometimes Ubuntu adds its own code. I am therefore wondering if another line is needed besides
uid-owner Debian-exim
But perhaps in this case it will just work with the Debian-exim.

I do not have a Ubuntu server so I can not test it to find out.

You need to check the user that runs exim4 process. I don’t know if ubunto has a different user for exim.

Debian-exim

So it should be the same…

So if a website uses its own PHP script to send email instead of using exim, then wouldn’t that get denied? That would be running as the user the site is set up under. I’m thinking plugins like WP SMTP which can be asked to send mail through an external server.
I guess you could persuade them to use a different port if it was available. But the fact that it might break some sites makes me wonder about making it a compulsory inclusion in Hestia. Perhaps add it as a Security toggle?

Yes that would be denied. But SMPT plugin or phpmailer can solve it…

It should be optional anyway…

1 Like

In my opinion mail function in PHP should be always be disable. Because if the site is compromised your server could be exploited and send tons of spam.
In my case i always use phpmailer, connecting to port 465 (ssl) or 587 (startls) using proper SMTP credentials.
I agree with @eris regarding that this should be optional, but i think is a good practice to hard the security of an email server, otherwise IP reputation is very difficult to maintain