Basic security tips for Sentora

It’s pretty common for people to consider Sentora as an insecure control panel just based on the fact that it runs on port 80 while other panels run a separate webserver and thus use a different port.

However, running a separate webserver for the control panel only has it’s cost and that cost is taken out of the server’s resources, so resource usage wise, Sentora is a good control panel because it spares the need of running a separate webserver just for the sake of having a different port for the control panel. On a VPS resources do matter (psst. Froxlor runs on port 80 too).

Now that this is settled let’s get down to business.

Securing the panel login via .htaccess

There are several ways to secure the panel login using .htaccess:

  1. Deny access to everyone except yourself by IP. You can find a good tutorial here and I will not go into it deeper because the tutorial is pretty straight forward.
  2. Restrict access to the panel using the IP and instead use a hostname. It’s already set in the .htaccess of Sentora, but commented out and can be adjusted as needed.
  3. Use the Apache level password protection to add an extra password layer to the panel login. Again, you will find a good tutorial here which does not require any additional input.
  4. Another effective way to secure the panel login would be to alter the login URL using mod_rewrite so that the default URL redirects to a placeholder page, while the custom URL resolves the login page. (as this is a separate matter that I want to address in a future article I will update the link later)
  5. Prevent POST queries from being executed unless certain rules are met (like correct IP, referrer, cookie etc.). This can be easily done with mod_rewrite and it’s a subject I have a draft for.
  6. Prevent XSS attacks by adding security headers and mitigation of XSS, RFI, SQLi attacks via mod_rewrite as well as preventing RFI and SQLi attacks by adjusting the PHP configuration in php.ini. Again, this is another subject I intend to document soon.

Securing the webserver

You can easily secure the webserver with the use of specific Apache2 modules like mod_security or mod_evasive. While mod_security provides enhanced protection against the most common attack vectors based on OWASP rules, mod_evasive is capable of blocking DDoS and bruteforce attacks.

However, please be aware that both of them require specific tweaks and adjustments in order to prevent false positive blocks so a bit of knowledge is required for them. This basically is independent of the control panel used, but it’s something that references a better security level.

Securing the server

The last and most important part represents securing the server itself, which again is independent of the control panel used and should be done before anything:

  1. Insure that you have the latest software versions installed at any time since most of the patches are released to fix security issues, not just bugs.
  2. Install and use a firewall regardless if it’s CSF (cross platform), UFW (Debian & Ubuntu specific) or fail2ban (cross platform)
  3. Use the firewall to open externally only the ports you actually use: 80 for  Apache, 53 for DNS etc.
  4. Change the SSH port to something different than 22 (this will lower the volume of bruteforce attacks). You can do it by editing /etc/ssh/sshd_config and altering the port value there. Make sure that you also allow the new port in the firewall and that you deny port 22 afterwards.
  5. If you don’t use it don’t keep it open. This applies to mail, FTP and other similar services that should not be started at boot and should not be opened to the internet.
  6. Always use strong passwords and insure that the devices you’re using to access the panels are malware free.
  7. Replace default software versions with more secure alternatives. MySQL can be replaced with Percona or MariaDB instead and Sentora is one of the panels that’s fully flexible with that.
  8. Isolate the websites and client accounts from one another using suPHP, suEXEC etc.

Probably the most insecure part of Sentora is the weakness of the passwords used when creating MySQL users, but that can be improved too.

P.S. Sentora is free, don’t say it’s bad just because you don’t know how to secure it for as long as you’re not paying for it. If you want a panel that does all the work above for you then go ahead and pay for cPanel as security has it’s price.

P.P.S This article resulted from a discussion on the LET forum.