Overview of Site Security Levels

When multiple sites are hosted on a single server, sharing system resources, there is a high possibility of sabotage or inadvertent activity that may compromise the integrity of data. You can check misuse or malevolent activity by setting appropriate security features for each site when you create the site.

Depending on the security level chosen, certain services for the site run in protected mode within the restricted environment of the site's file system, technically referred to as a chrooted environment. This prohibits the resources of the secured site from unauthorized access; also, the administrator and users of the secured site cannot access data or resources pertaining to other sites on the server.

Chroot stands for change root. It basically redefines the operational environment for an application, more precisely it redefines the root directory for an application. By definition, the root directory is the starting point of access on the navigation tree; when you change the root of an application, you make the directory of that application the starting point of access; this precludes view or access to system-wide files.

For example, consider the file sample.htm located in the root (/) directory, /sample.htm. When located at the root, this file becomes a global file accessible to anybody who has root privileges.

If you change the root of this file to the relevant site's home directory (say, /var/www/html/), then the file acquires a new root environment, which is, /var/www/html/sample.htm, so only people with access rights to the site can view or use the file.

Since files are locked into a secure area of the operational environment and denied access to global files it is also in non-technical terminology said to be "jailed".

Important: Changing the root of a directory or application requires that all files served and used by the directory or files in the application reside in the new root environment of the application, without which they will malfunction.

Why chroot?

Changing the root of a directory or application secures it from unauthorized access by isolating it from other users on the system. When you change the root of an directory or application, other users on the system can not view or access the directory or application resources. Thus, users are limited in the commands or exploits they can carry out on the files.

Changing the root of a directory or application enhances security but thwarts optimal use of resources by posing resource sharing constraints. For example, changing the root of CGI scripts mandates that you copy the libraries and configuration files necessary for running CGI scripts into the new root directory.

The control panel offers three security levels:

• High security
• Medium security
• Low security

High security

High security runs certain services, that are vulnerable to security breaches, inside the restrictive environment of the site's file system.

This security level is recommended if you provide a shared hosting environment and want to ensure a secure environment for sites that enable CGI scripting capability and remote access services.

The services that are secured are:

• CGI scripts
• Telnet/Secure Shell
• mod_perl/mod_php

CGI Scripts

CGI scripts can present security loopholes in two ways:

• They can reveal information about the host system thus enabling hackers to break into the system
• When the scripts process remote user input, such as the contents of a form, they become vulnerable to remote exploits that subvert the scripts to run potentially destructive commands

High security uses the chroot mechanism to place CGI scripts inside the restrictive part of the site's file system.

Important: High security poses problems if the CGI scripts for a site source required libraries or configuration files from outside the site's file system, in which case, the necessary files must be copied across to the site's file system.

For example, if a CGI script uses Perl, then all the Perl libraries and configuration files must be copied into the site's file system.

Telnet/Secure Shell

Remote login services like Telnet or SSH allow users to interact with remote computers on the Internet. They can expose your system to denial-of-service attacks and enable hackers to run subversive code.

High security jails remote user logins (administrator and users of the site) to the restrictive environment of their home directories. Administrators and users of the site are logged into their respective home directories, preventing view or access to any system-wide resources from the site's operating environment.

mod_perl/mod_php

mod_perl and mod_php are modules that allow users to run scripts on the Web server, thus exposing your Web server to potential exploits.

High security disables the mod_perl and mod_php services for a site, so that users cannot run scripts using these modules on the site.

Important: In high security sites, the .pl (Perl) files located at /var/www/perl and the .php files are run as CGI processes. However, in medium security and low security sites, the .php files are managed by mod_php and the .pl files located at /var/www/perl are managed by mod_perl. To take advantage of the full capabilities of these services, you must opt for medium security or low security.

Medium security

Medium security offers a loosely knit security environment wherein remote login services are secured, but CGI scripts run in a vulnerable environment.

Note: This security level preserves the settings of existing sites and allows CGI scripts to run without any modification.

• CGI scripts
• Telnet/Secure Shell
• mod_perl/mod_php

CGI scripts

CGI scripts are not jailed into the site's file system. This compromises security but eliminates file sharing constraints posed by secured CGI scripts.

Telnet / Secure Shell

Telnet and SSH services are secured as in high security. Remote user logins (administrator and users of the site) are restricted to the protective environment of the site's file system.

mod_perl / mod_php

mod_perl and mod_php services are enabled for the site, allowing users to run these scripts on the site.

Low security

Low security enables all files residing on the server to be shared or accessed (depending on file access privileges) by the administrator of the site. Users, however, are always restricted to the home directory of the site.

This security level is recommended only for trusted user environments, as it allows remote access services and CGI scripts access to the whole server, including other user's data on the server. This security level is not recommended for shared hosting environments.

Important: Since low security provides an open operating environment, the administrator name must be unique across all the sites hosted on the server.

The site is also enabled to run mod_perl and mod_php scripts.

None of the following services are secured for the site.

• CGI scripts
• Telnet/Secure Shell
• mod_perl/mod_php

CGI scripts

While CGI scripts reside within the site's file system, the administrator of the site can access or share system-wide resources outside the cgi-bin directory.

Telnet / Secure Shell

With low security, administrators can use the Telnet or SSH remote login service to traverse the file hierarchy outside the site's home directory. Users, however, are restricted to the home directory of the site.

Note: For IP-based sites, remote access, using the Telnet service, is locked into the site's file system. When the Site Administrator or the site users connect to the site they are logged directly into their home directory. To override this limitation, Site Administrators need to connect to the server on which the site is hosted and then log in with the user name <user_name>@<site_name> to the server.

mod_perl / mod_php

mod_perl and mod_php services are enabled for the site and can be used to run mod_perl and mod_php scripts on the site.