Top 15 Plesk Server Security Best Practices to Protect Your Website

Top 15 Plesk Server Security Best Practices

If you don’t use cPanel, you probably use Plesk, as it’s one of the most common hosting platforms on the market. Similar to cPanel, hackers target hosting platforms to gain high-privilege access to web applications and server resources. Plesk has several security extensions that will help harden the protection of sites, but relying on simple extensions without following best practices could still leave your site and the main Plesk master account vulnerable to malware and exploits. In this article, you will learn about Plesk and discover Plesk security best practices:

What is Plesk?

Why Plesk Security Hardening is Important

Security Best Practices for Plesk

Update Consistently
Use Password Complexity Rules When Creating Passwords
Enforce Multi-Factor Authentication
Use SSL/TLS for Remote Administration and SSH
Use sFTP and not FTP for File Sharing
Automate CMS Updates
Secure Plesk and the Website with SSL/TLS
Configure the Domain to Avoid Clickjacking
Configure Plesk with Trusted Hosts to Avoid Open URL Redirects
Restrict Remote Access via the Plesk API
Restrict Administrative Access
Mitigate the Symlinks Vulnerability
Configure Plesk to Use Enhanced Security Mode
Follow PCI-DSS Compliance Regulations
Use the Imunify360 Plesk Extension

What is Plesk?

What is Plesk

To help website owners manage their sites, hosting administrators install platforms and management tools so that customers can customize their site to meet their business needs. Plesk is one of the most popular tools along with cPanel, but Plesk is often used in environments where multiple operating systems and platforms are offered as hosting options. It’s best for hosting providers who offer virtual private server (VPS) and dedicated server options to customers.

What makes Plesk attractive to hosters and their customers is its integration with common content management systems (CMS) applications such as WordPress, Joomla, and Drupal. Because most hosting customers work with these CMS applications, installing Plesk makes it easier for customers to manage their sites and hosting providers to oversee them. It supports database engines such as MySQL, PostgreSQL, and Microsoft SQL Server and web hosting applications such as Apache Tomcat Java and ColdFusion.

Plesk supports extensions to its base code - that can be used to add other functionality to customer sites. A few examples are Docker support, SEO Toolkit, Git support, Developer Pack, Servershield by CloudFlare, and KernelCare. As you can see, some of these extensions offer security protection, but they do not offer a full solution that will assure protection from all attack types.

Why Plesk Security Hardening is Important

Because a hoster might have hundreds of sites on one server, compromised Plesk could mean it affecting hundreds of customers. Any zero-day Plesk vulnerabilities could affect thousands of sites across multiple servers, so administrators should stay updated on the latest Plesk advisories.

As an example of what can happen with a Plesk zero-day, in 2012, a vulnerability in the hosting platform allowed attackers to extract the master password used by hoster administrators to manage all websites on the server. With this password, attackers were able to take control of any site on the Plesk server. The vulnerability exists on older versions of Plesk (note: updating Plesk is one best practice), and this zero-day affected approximately 50,000 sites before it was discovered.

Site hijacking isn’t the only damage that can be done, although it’s one of the worst. Attackers can upload malware or inject code files with malicious content. The malware could remain undetected and exhaust server resources, damaging customer experience through lowering performance . This then leads to complaints from customers and eventually damage to the hosting company’s reputation. Malware running on the server can also eavesdrop on data and potentially steal sensitive information.

Any damage done to servers and the hoster’s reputation, stolen customer data, and compromised websites has an ultimate effect on hoster revenue. Instead of using revenue to clean up a massive compromise, hosters can harden Plesk security to better ensure data protection and safeguard customer sites.

Security Best Practices for Plesk

Security Best Practices for Plesk Whether you’re a host server administrator or a site owner, these best practices should be implemented across all of your sites. Just one hacked site can have an effect on server performance, so Plesk security should always be a top priority.

Update Consistently

Whenever a security vulnerability is found or bugs are reported and remediated, Plesk developers release an update. All updates are important, but security patches are even more important for protecting sites from known vulnerabilities. These updates remediate vulnerabilities discovered in the wild. Should you leave the Plesk application unpatched, you leave your site and any other sites managed by Plesk open to exploits.

Out-of-date software has been the reason for numerous large data breaches, including the well-known Equifax compromise. You can use configurations to automatically install Plesk updates to ensure that you always have the latest version. Plesk might go offline for a few minutes after updates, so this option is not always feasible for large hosts. If you do not use automatic updates, administrators should use notifications for when Plesk updates so that they know it’s time to update the software as soon as possible.

Use Password Complexity Rules When Creating Passwords

Use Password Complexity Rules

Users have a tendency to use the same password across multiple sites, and their passwords are typically made up of a word and possibly a couple of numbers. Passwords with few characters used across multiple sites makes the user password vulnerable to brute-force attacks. Attackers could identify the user’s password on another site, and then use the cracked password to then authenticate and compromise the Plesk account using the same credentials.

Hosters can apply password rules to ensure that users only use cryptographically secure passwords resistant to brute-force attacks. The more characters in a password, the more secure it is from brute-force attacks, however, the number of characters is not enough. The user must also follow complexity rules. Complexity rules require passwords to be a combination of uppercase and lowercase letters, numbers, and special characters. For an even more secure password, characters should be randomized and not made up of dictionary words.

Plesk lets you set up password rules, but it suggests that passwords should be eight characters. Currently, a password that contains one uppercase character, five lowercase letters, one number and one special character, or eight characters, only takes about 2 hours to crack, making it cryptographically insecure. Hosters should use at least 10 characters for the master password to protect it from brute-force attacks and users should be encouraged to have 10-12 character passwords also.

Enforce Multi-Factor Authentication

Phishing and brute-force password attacks are common, and the Plesk administrator can’t force a user to have a unique password across all sites. Should the user or Plesk administrator fall victim to a phishing attack, multi-factor authentication (MFA) would stop a threat actor from authenticating into the target account.

Text message two-factor authentication (2FA) has been rendered insecure as vulnerabilities in the SS7 protocol allow attackers to hijack messages. SIM swapping is also an issue where attackers use social engineering to convince telecom representatives to direct messages for a targeted user to the attacker’s SIM. For these two reasons, most organizations work with authenticators to generate a user-specific code for the second step in 2FA.

Plesk works with the Google Authenticator application that can be downloaded to a user’s smartphone. The feature requires installation of an extension, but it’s well worth the effort to better secure authentication from phishing. The Authenticator generates codes used in the second phase of MFA. It’s much more secure than using text messages.

Use SSL/TLS for Remote Administration and SSH

SSH is commonly used for remote administration of Linux machines, but it opens up the risk of several threats, including complete takeover of the server using the root account - if it’s not properly locked down. You can implement several best practices to protect SSH from being compromised on the main physical server and user instances:

Use a keyfile to authenticate instead of passwords.
Configure SSH to use an alternative port.
Disable authentication for the root user on SSH.

SSL/TLS certificates will encrypt any traffic between the user’s computer and the host. This protects from eavesdropping and man-in-the-middle attacks that could be used to steal sensitive information.

Use sFTP and not FTP for File Sharing

It’s not uncommon for hosting companies to offer FTP for its users, but FTP is a protocol that transfers data in cleartext. This means that any files uploaded using FTP are vulnerable to man-in-the-middle attacks and data theft. Although it’s a different protocol than HTTP, transferring files with FTP is just as bad as transferring financial data in HTTP cleartext. Any sensitive data in uploaded files could be manipulated or stolen.

Secure FTP (sFTP) uses encryption to transfer files, similar to adding encryption to the HTTP protocol with HTTPS. It adds a layer of security to file transfers to protect them from eavesdropping. It works the same as FTP, only encryption is added to the protocol and users must have the FTP software that supports sFTP.

Automate CMS Updates

WordPress allows you to turn on automatic updates, but you can turn them on with Plesk too. Automatic updates will ensure that the CMS software is always updated with the latest patches and upgrades, which secure the software from the latest CVEs. When updating WordPress, don’t forget that all plugins must be updated as well to ensure that they too are not leaving vulnerabilities open on the site.

CMS isn’t the only software installed on a single site. Site owners usually have several applications running on their website that must be updated including gallery software, ecommerce systems, email and gallery applications. Plesk provides functionality that turns on automatic updates for these applications so that they are not the source for a compromise.

Secure Plesk and the Website with SSL/TLS

Just like FTP, a cleartext connection to the Plesk software or the website itself leaves any data transferred open to man-in-the-middle attacks. Website owners should be encouraged to add an SSL/TLS certificate to their site for the safety of their own users, but hosters should also always add SSL/TLS certificates to Plesk connections.

Adding SSL/TLS to Plesk pages ensures that users will not fall victim to password theft in man-in-the-middle attacks. Any site pages that transfer sensitive data should only be accessible over HTTPS, so host administrators should configure redirects from HTTP to HTTPS when users connect to Plesk using cleartext channels.

Configure the Domain to Avoid Clickjacking

Clickjacking is a threat used to trick users into performing commands without their knowledge as they click buttons and enter information on an attacker-controlled site. A hidden iframe is used as an overlay that contains the legitimate site unbeknownst to the user. The attacker loads the iframe with the legitimate site content usually with the targeted victim authenticated. As the targeted victim clicks buttons on the attacker-controlled site, the commands are sent to the legitimate site, which could perform actions such as bank transfers or disclosure of sensitive information.

Website owners protect their sites from being used in clickjacking by adding the X-Frame-Options header to server responses with the header value set to DENY. You can configure Apache and nginx domains in Plesk to block third-party sites from wrapping a domain in an iframe in clickjacking attacks. The server header should look like the following:

X-Frame-Options: DENY

Configure Plesk with Trusted Hosts to Avoid Open URL Redirects

When developers redirect users based on query string parameters, it leaves the site open to malicious URL redirects. For example, suppose a user site contains the following URL:

mysite.com?redirect=mysite.com/loggedin

If programmers use the “mysite.com/loggedin” value to automatically redirect users, then an attacker can use the same URL to redirect users to their own site. Attackers link a targeted user to a URL pointing to the legitimate site domain and then use the legitimate domain to redirect users to a malicious website meant to steal data. Because the link was directed to a legitimate site, targeted victims think they are accessing a safe domain.

To remediate this vulnerability in Plesk, administrators can create a whitelist of domains and add them to the Plesk configuration file. In the panel.ini file, a security section has a configuration labeled “trustedRedirectHosts.” In this section, you can set a trusted domain users get redirected to after authentication.

An example of allowing only redirects to mydomain.com would look like the following in the panel.ini file:

[security]

trustedRedirectHosts = mydomain.com

Restrict Remote Access via the Plesk API

The Plesk application comes with an API that lets administrators interact with the software or lets users configure settings remotely. To reduce your attack surface when the API will not be used, administrators should disable it. Disabling the Plesk API can be done in the panel.ini file. In the “api” section of the panel.ini file, you can either turn off the API altogether or whitelist IPs that can access it.

To disable the Plesk API altogether, use the following configuration in the panel.ini:

[api]

enabled = off

The following configuration whitelists two IPs so that only users (or servers) with these two IP addresses can access the API:

[api]

allowedIPs = 10.58.108.100,192.168.0.0

Restrict Administrative Access

If the master password is compromised or a user with administrative access has their password compromised, the attacker could take over sites and do damage to site code. The Plesk administrator can limit damage from a compromised password and provide a whitelist of IP addresses that can access administrative functions. You can also use a blacklist to block specific IP addresses, but this option is much more permissive.

To configure a whitelist of IP addresses, use the following instructions:

Go to Tools & Settings > Restrict Administrative Access (under “Security”).
Click Settings, select the “Denied from the networks that are not listed” radio button, and then click OK.
Click Add Network and specify the IP address or addresses from which administrative access to Plesk must be allowed:
Individual IP addresses (for example, 192.168.1.110)
Subnets of IP addresses (for example, 123.0.0.1/16 or 123.123.*.*)
Click OK.

Mitigate the Symlinks Vulnerability

Subscribed users can access their subscription documents using a feature in Apache or nginx called Symlinks. These links use an alias to access documents, but it leaves Plesk open to attacks where a third-party subscribed user can view subscription documents of other subscribed users if they know the aliased link. The information in subscription documents is often sensitive (e.g., passwords and CMS settings), so it’s a vulnerability that should be mitigated. Symlink mitigation settings depend on the host operating system and CMS. Plesk shows you how to mitigate the Symlink vulnerability in their documentation.

Configure Plesk to Use Enhanced Security Mode

Enhanced Security Mode is turned on by default in Plesk version 11 and later, but conversions to newer versions and earlier must be configured manually. The setting is found in the Security Policy section of Plesk. Make sure that the “Enhanced security mode” checkbox is set to “On.”

The enhancements added with this security configuration protect data from being stolen after a compromise. It does the following:

Encrypts Plesk passwords in the database.
Disallows sensitive data such as passwords from being retrieved from the API.
Password recovery email no longer contains the password in cleartext.

Follow PCI-DSS Compliance Regulations

Compliance regulations require companies to follow several guidelines to safeguard user data and avoid hefty penalties for violations. PCI-DSS is specific to financial transactions, which host providers have on their sites to take customer payments. Site owners should also be aware of the other compliance regulations that oversee their business.

Plesk has several configuration options that control the security of data. The configurations cover:

SSL/TLS cipher limitations to only those that are considered cryptographically secure.
Blocking external connections to the MySQL database server
Protecting files and file permissions
Securing FTP access

Use the Imunify360 Plesk Extension

Following best practices greatly reduces risk and protects the Plesk server and sites hosted on the server from exploits, but it doesn’t monitor the threats or tell you when a threat was found. No solution is 100% risk-free, but adding the Imunify360 Plesk extension will work in alignment with best practices to harden security even further. Imunify360 has a Linux malware scanner and a Linux server antivirus solution.

Using Imunify360, you not only have methods to stop malware and exploits - hosters and site owners can monitor their assets for any threats that could bypass security. By adding monitoring to your site, you can find threats before they become more damaging to potentially hundreds of sites on one server.

Take your web hosting security to the next level with Imunify360 security suite. Imunify360 is a complete security suite with all components working together to keep your servers safe and running while you could focus on other business tasks. Imunify360 is a synergy of Antivirus, Firewall, WAF, PHP Security Layer, Patch Management, Domain Reputation with easy UI and advanced automation. Try Imunify360 free for 14 days and see results in just one week.