3.0 Chapter 3: Securing Additional Services

3.1 WEB SECURITY

The web server installed with Red Hat 7.3 is apache (http://httpd.apache.org). The rpm packages distributed with the installation disk are vulnerable to multiple security issues (see http://rhn.redhat.com/errata/RHSA-2002-222.html). Be sure the latest updated packages (i.e., apache-1.3.27-2 as of 20-Dec-02) have been installed before proceeding.

3.1.1 Ensure Only Necessary Modules Are Installed

The httpd executable is compiled with Dynamic Shared Object (DSO) support to provide extensibility for plugging in many additional modules (e.g. SSL, PERL, DAV, etc.). Some of these modules are included with the base rpm package, but most of them are stand-alone packages having names beginning with the string "mod_" (e.g. mod_ssl, mod_perl, mod_dav). If the functionality provided by a module is not required, the module should be removed. A good candidate for removal is the Distributed Authoring and Version (DAV) module which enables modifications to files on the web server using the client's browser. Use the rpm command below to remove the DAV module package:

 [root@localhost]# /bin/rpm -e mod_dav 

3.1.2 Harden the Main Configuration File (/etc/httpd/conf/httpd.conf)

3.1.2.1 Comment Out Unused Modules

In order for the apache server to use the functionality provided by a module, the LoadModule and AddModule directives corresponding to the module must be present in the configuration file. For an additional layer of security, comment out (or remove) the pair of lines for each module that will not be used by the server. Some candidates for removal are:

Table 3-1: Candidate Modules for Commenting Out When Not Used

Module	Functionality provided	Comments
mod_autoindex	Automatic directory listings	Providing directory listings gives away too much information to potential crackers.
mod_include	Server Parsed Documents	If server side includes are not required by the website, it is safer to disable them.
mod_info	Server Configuration Information	Providing the server configuration information, just by visiting a URL, gives away too much information.
mod_status	Server Status Display	Providing the server status information, just by visiting a URL, gives away too much information.
mod_userdir	User Home Directories	Allows users to serve pages from a directory within their home directory. This introduces potential vulnerabilities if users are not web knowledgeable and careful.
Ref. 1: http://httpd.apache.org/docs/mod/

3.1.2.2 Tighten Default Directory Access Permissions

Change the <Directory /> stanza that controls the default access permissions.

Table 3-2: Modification of Default Directory Access Permissions

Original	Modified
<Directory /> Options FollowSymLinks AllowOverride None </Directory>	<Directory /> Options None AllowOverride None Order allow,deny Deny from all </Directory>

The original version allows symbolic links to be followed to anywhere on the file system. This increases the likelihood that files outside the document root might be shown to a visitor.

3.1.2.3 Document Root Access Permissions

Change the <Directory /var/www/html/> stanza that controls the access permissions to the web server document root.

Table 3-3: Modification of Default Root Access Permissions

Original	Modified
<Directory "/var/www/html"> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory>	<Directory /var/www/html> Options SymLinksIfOwnerMatch AllowOverride None Order allow,deny Allow from all </Directory>

The original version will show the visitor a directory listing for any directory in the document root without an index.html file (or other similar file defined by the DirectoryIndex directive). As mentioned in the previous step, this is too much information to give to a visitor. Another change is the use of the more restrictive SymLinksIfOwnerMatch option. Generally, all the files served by a web server are owned by the root user or web administrator. Therefore, this option prevents the server from following any links that may be created by other users to areas outside the DocumentRoot.

There is an option to consider (instead of None ) for the AllowOveride directive. If many people have responsibility for access control to different directories under the web server document root, AllowOveride AuthConfig may be used instead. This will enable separate configuration of access control using a .htaccess (or a file name that matches the AccessFileName directive) file in each directory, instead of having to give everyone write permission to the main httpd.conf configuration file. The drawback is that it makes auditing access to the server more difficult, since there is more than one place to look.

3.1.2.4 Conceal Server Version Information

Apache is configured by default to add a signature to web pages that it dynamically generates (like default error pages). The signature potentially includes the server name, version number, and modules. The following directive, placed in httpd.conf, will prevent this signature from being displayed:

 ServerSignature Off 

In addition to the server signature, apache will provide a string in the HTTP header returned to clients requesting documents that contains the name, version, and modules that were loaded on start-up. The following directive will minimize the amount of information leaked.

 ServerTokens Prod 

Occasionally, the email address of the web server administrator is displayed on server-generated pages. Locate the directive below and change the email address to the address of the Webmaster.

 ServerAdmin root@localhost 

3.1.2.5 Disable cgi-bin Directory (if not used)

Probably the main vector used to attack web servers is a CGI program. If the web site hosted by the server does not host any CGI pages, comment out the following lines to disable CGI functionality and access to the cgi-bin directory:

 LoadModule cgi_module    modules/mod_cgi.so     LoadModule env_module    modules/mod_env.so     AddModule mod_env.c     AddModule mod_cgi.c     ScriptAlias /cgi-bin/ "/var/www/cgi-bin/" <Directory "/var/www/cgi-bin">   AllowOverride None  Options None   Order allow,deny   Allow from all </Directory> 

3.1.3 Check Permissions on Files in the DocumentRoot

To help prevent defacements of web pages, the owner of the web server process should never have write permission to any file or directory where files reside that are served by the web server. The user and group that the web server process runs under are defined by the User and Group directive in the httpd.conf file, respectively. Run the following commands for all directories served by the web server to identify any files for which the owner of the web server process has write permission. For the best security, the output from the commands should be empty.

 [root@localhost]# /usr/bin/find /var/www/html -user apache -perm +202 --exec ls -- ld {} \;     [root@localhost]# /usr/bin/find /var/www/html -group apache -perm +022 - exec ls -- ld {} \; 

In these commands, the user and group are apache, as they are with the default installation. Also, for additional security, these commands can be combined into a script and run on a daily basis from a cron job so any changes to the files permissions will be promptly detected .

3.1.4 Encrypt Sensitive Traffic Using HTTPS

The Secure Sockets Layer (SSL) module enables the apache web server to use strong authentication for all client server communications. At a minimum, the https protocol requires that the server have an X.509 certificate for identification. Ideally, the certificate should be signed by a trusted third party who has taken the steps to verify that the server is actually being operated by who it claims to be. Optionally, the server may also require the client to provide a certificate.

The sample certificate installed with Red Hat 7.3 (/etc/httpd/conf/ssl.crt/server.crt) enables apache to start and function as an HTTPS server. However, if the server will be used to serve and handle sensitive data (e.g. for an e-Commerce web site), an authentic certificate should be created and signed by a trusted authority. See http://www.thawte.com/html/SUPPORT/server/softwaredocs/apachessl.html for details on how to create one.

3.1.5 Where to Find More Information

The GCUX practical entitled Securing Apache Step-by-Step (http://www.giac.org/practical/ryan_barnett_gcux.zip) written by Ryan Barnett is an excellent resource on these items and others related to the Apache server.