When you share a single physical server between many users, you consider all security aspects thoroughly. Although Plesk provides an acceptable security level, there are suggested ways to improve it. This chapter provides instructions on protecting Plesk server and hosted domains from unauthorized access.

Configuring Site Isolation Settings

If you offer shared hosting services, one of the most important security aspects is site isolation. This means that users must not be able to access other users’ files and databases.

Customers’ files are usually located in separate directories owned by the corresponding system users, so other customers cannot access them by SSH or FTP. The main issue with site isolation is that the server sometimes executes all scripts of the same type (for example, Perl scripts) on behalf of the same system user. This means, for example, that if a customer’s Perl script creates a file in the /tmp directory, another customer’s Perl script can access this file because the system executes both script on behalf of the same user.

For PHP scripts, you can solve the site isolation problem by running PHP as a FastCGI or CGI application. In this case, the system executes each user’s PHP scripts on behalf of the corresponding system user and thus isolates scripts owned by different users. In turn, if Plesk runs PHP as an Apache module, all PHP scripts are executed on behalf of the apache user. This weakens the site isolation.

Some other scripts, such as those written in Perl and Python, are always executed by Plesk on behalf of the same system user. So, in order to provide the best site isolation, you should either prohibit their execution on the server or manually configure the system to execute them securely. Refer to the corresponding documentation for instructions on configuring secure execution of such scripts.

By default, no server-wide site isolation settings are applied: for each subscription, its site isolation settings are defined by its service plan (if the subscription is synced with it) or its own settings (if the subscription is customized and locked).

Note: Customers can change their site isolation settings only if they have the permission Hosting Settings Management.

To define the server-wide site isolation settings:

  1. Open for editing the file PRODUCT_ROOT_D/admin/conf/site_isolation_settings.ini, where $PRODUCT_ROOT_D is /usr/local/psa for RPM-based systems and /opt/psa on DEB-based systems.

    This configuration file specifies the list of allowed values for hosting settings:

;php = on
;php_handler_type = fastcgi
;python = off
;perl = off
;fastcgi = any
;ssi = any
;ssl = on
;shell = /usr/local/psa/bin/chrootsh
;php_safe_mode = on

By default, all lines are commented out with semicolons (;), so no server-wide settings apply.

  1. To define a server-wide setting, uncomment the corresponding line by removing the semicolon (;) and edit the line. For example, to prohibit executing Perl scripts on your server, remove the semicolon from the line ;perl = off.

    You can set the following values for the settings:

    • on and off for scripting options.
    • module, fastcgi, cgi, or fpm for php_handler_type.
    • A line from /etc/shells file for shell.
    • any for any option if the option value is not restricted.

    In addition, there are the following restrictions on the use of these values:

    • If php is off, php_handler_type and php_safe_mode must be set to any.
    • If fastcgi is off, php_handler_type must not be set to fastcgi.

However, you can grant the permission to override the server-wide settings to certain subscriptions or service plans. To do this, select the option Setup of potentially insecure web scripting options that override provider’s policy in the subscription or service plan settings, Permissions tab.

Note: You can grant the permission Setup of potentially insecure web scripting options that override provider’s policy in a plan only after you grant the permission Hosting settings management.

Protecting from Running Tasks on Behalf of root

By default, Plesk allows utilities or scripts to be run on behalf of the root user in two cases:

  • When the Plesk administrator creates a scheduled task and explicitly selects root as the user to run the task under.
  • When the Plesk administrator creates an event handler and explicitly selects root as the user to run the associated command under.

This gives the Plesk administrator more flexibility, but can potentially present a security threat if the Plesk administrator account is compromised (for example, via social engineering), as the malicious actor can then use this functionality to execute commands on the server on behalf of the root user without knowing the root user password.

To counteract this, the Plesk administrator can choose to forbid the creation of scheduled tasks and/or event handlers running on behalf of the root user.

  • To prevent users from running cron tasks and viewing the list of tasks scheduled on behalf of the root user, create an empty file named root.crontab.lock in the $PRODUCT_ROOT_D/var/ directory.
  • To prevent users from creating event handlers functioning on behalf of the root user, create an empty file named root.event_handler.lock in the $PRODUCT_ROOT_D/var/ directory.

The $PRODUCT_ROOT_D is /usr/local/psa for RPM-based systems or /opt/psa on DEB-based systems.