Best practices to strengthen Plesk server security
Plesk Server Security Hardening – Generic Steps
Latest Plesk has enhanced level of security right after the installation. Recently, Plesk launched Advisor, which unifies the best possible security practices and performance tune-up of the server and hosted websites. At the same time, it’s a good idea to ensure the following routine steps:
- Insure regular Plesk updates
- Change password strength to Strong
- Use two step verification by installing Google Authenticator
- Use SSL/TLS to secure mail server
- Set sFTP connection
- Limit administrative access to the system
- Limit remote access via XML API
- Actively use Web Application Firewall
- Actively use WordPress Toolkit Security Check
- Set automatic updates for WordPress instances
- Insure outdated web applications are not used or update them on regular basis. The failure to comply this rule may result unexpected security vulnerabilities
- Use VirusTotal Website Check to check existing websites
Block all ports which are not in use with the help of firewall.
Server Security Tips for Plesk under Linux
- Use keyfile to allow SSH access
- Use custom port to establish SSH connections
- No SSH authentication for root user
- Turn off Perl/Python for the website if these languages are not used as well as do no use mod_perl/mod_python
- Use Opsani vulnerability scanner
- Set Fail2Ban to prevent hacking attempts
- Avoid PHP handler served as Apache module – not a secure practice
- Ensure automatic updates of system packages are on
Server Security Tips for Plesk under Windows
- Custom port usage for RDP connections is a must
- Get rid of unused programming languages
- Make sure you install the latest Windows updates
- Restrict users from overriding handlers via web.config files
- Keep DDoS protection enabled
What to do if server security is compromised
What we suggest here is migration to the new server. With a successful attack, intruders raise their privileges to root level – meaning they can do anything with the server. And just because you find malware/rootkits during investigation and clean it, doesn’t guarantee no others inside your system. It’s possible to load malware directly into RAM. There can be backdoors enabled or even common cronjobs for wget to download rootkits from already infected servers.
Try to restore the server using a previous snapshot doesn’t mean no server problems. Because in many cases, it’s not clear when exactly the server was hacked and rootkits uploaded to the server.
How to identify the source of the problem
While using security solutions dedicated to scanning for rootkits/malware you need to understand the following – these solutions use only already known patterns to identify the presence of malware and can be completely useless for new malicious software. To be 100% sure on how the server was hacked please contact security audit company which specializes on such cases. Please do not change anything before investigation to avoid the loss of traces.
Oh no, sorry about that!
Let us know how we can do better below
Tell us how we can improve this post?