Specific Ensim Question
Question: Overview of site security levels
Answer:
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 site’s file system, technically referred to as a chrooted environment. This prohibits the resources of the secured site from unauthorized access; also, the Site Administrator and users of the secured site can not access data or resources pertaining to other sites on the Web server.
The control panel offers three security levels:
* High security
* 3.1 compatibility
* 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 your account operates in a shared hosting environment and you want to ensure a secure environment for sites that use CGI 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 unwittingly 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 a restrictive part of the site's file system.
* Important: High security could pose 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 will have to 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 as 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 account 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 3.1 compatibility 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. If you want to harness the full power of these services, you must opt for 3.1 compatibility or low security.
3.1 compatibility
3.1 compatibility offers a loosely knit security environment wherein remote login services are secured, but CGI scripts run in a vulnerable environment.
* Note: This security level should be opted for if your sites have been upgraded from WEBppliance 3.1. This security level preserves the settings of existing sites and allows CGI scripts to run without any modification.
The following services are secured.
* 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 locked into 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, but users are always restricted to their home directory within 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 jailed to their home directory within 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 @ 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.
Last updated: August 29, 2005
Browse by FAQ categories:
FAQ Home > Specific Ensim Question
Similar questions:
|