According to Dr. Johannes Ullrich, CTO of the SANS Institute's Internet Storm Center, "web application attacks account for a significant portion of hacking activities across the Internet." Securing web servers is an important step towards preventing some of the most common application layer attacks. Netcraft Web Server Survey, June 2006 recorded that Apache is the leading web server in the market with a market share of 61.25%. In this first part of the two part series, we will look at some of the general secure configuration settings of Apache web server.
As perimeter defenses across different organizations are being beefed up, we see more attacks directed towards the application layer. According to Dr. Johannes Ullrich, CTO of the SANS Institute's Internet Storm Center, "Once you move past the worms targeting buffer overflows or weak passwords and examine the manual attacks, classically called hacking, web application attacks account for a significant portion of the activity." Securing web servers is an important step towards preventing some of the most common application layer attacks. A “default” installation of any application/software is generally insecure, web servers are no exceptions, hence in order to secure a web site, it is essential to secure the web server before moving on to any application specific issues.
Netcraft Web Server Survey, June 2006 recorded the largest one-month increase in the number of sites(an increase of 3.96 million) that responded to the survey. Apache again proved to be the leading web server in the market with a market share of 61.25% out of a total market consisting of around 86 million hosting servers worldwide.
In this first part, we will look at some of the general secure configuration settings of Apache web server.
Originating in the early 90s, it was then known to be the HTTPd server of the NCSA( National Center for Supercomputing Applications). Sometime later when development on the web server was stalled, user groups using the NCSA web server got together to form a forum which could enable them to easily exchange patches, this forum came to be known as APACHE, and the web server, Apache web server.
Apache HTTP server project is the best place to get the latest version's "clean" installation files for Apache Web Server. The latest version available for download from httpd.apache.org is Apache 2.2.2.
Apache web server can be installed in windows either to start as a service or to be started manually by any user.When installed to run as a service it is registered to run as the system user LocalSystem.
This account has system wide privileges locally but has no network privileges. The default installation directory is c:program FilesApache GroupApache.
From Redhat Linux 7.3 onwards, Apache web server runs as user apache and group apache. It is recommended to have a dedicated user and group for Apache as administration regarding file permissions for the various folders of Apache installation and web content becomes easier. Apache starts as the root user and hands over the process to the apache user after binding to a privileged port and before accepting connection requests. The default installation directory is /usr/local/apache
Secure directory structure and file permissions
Directory structure in Apache web servers can be defined by 3 configuration parameters or directives. Each of the 3 directives refer to a system path where configuration, doc, web content and script files are stored in Apache web server. These directives have to be specified in the Apache configuration file httpd.conf . In linux it is present in usr/local/apache/conf .For windows it is usually present in c:program FilesApache GroupApacheconf. The 3 directives are:
- ServerRoot - Specifies path where binary(bin directory), server configuration(conf directory) and log(log) files reside.
- ScriptAlias - Specifies alias to the file system path where cgi script files should reside, this is a way of limiting CGI to special directories in the server.
It is generally recommended to use a directory structure based on user's file permissions i.e. directories given root permissions should be totally independent of directories requiring content developers and script developers.
For purpose of illustration we shall look into a directory structure below and the corresponding file permissions. Once the appropriate directory structure is created , we shall look into the file permissions.
Since the path specified by the ServerRoot directive contains important binaries and configuration files, only root user must have ownership rights and full permission(read, write,execute) on these directories (i.e bin and conf). Log files must also be protected from misuse by non-root users, hence the directory containing log files( log) must also be owned by root and only root user must have full permissions to it.
In order to set permissions for ServerRoot following commands are applicable :-
chown -R root.root /usr/local/apache
chmod -R 755 /usr/local/apache
For the DocumentRoot directory, only the web development team should have read,write,execute access and apache user must read and execute privileges. We can create a group call "webdev" and add web development users to this group as required. The commands to set file permissions are as below :-
chown -R apache.webdev /var/htdocs
chmod -R 2570 /var/htdocs
For the ScriptAlias directory only certain script developers or website administrator must have full access rights to this folder. Under no circumstances should a script be executed with root privileges. We can create a group call "scriptdev" and add script development users to this group as required. The commands to set file permissions are as below :-
chown -R apache.scriptdev /var/cgi-bin
chmod -R 2570 /var/cgi-bin
Secure Configuration Parameters
We shall now see some important security related parameters or directives from the httpd.conf file.These directives are listed and explained in detail at http://httpd.apache.org/docs/2.0/mod/core.html .
KeepAlive, MaxKeepAliveRequests, KeepAliveTimeout, Timeout
KeepAlive turns persistent HTTP connections i.e., multiple HTTP requests over the same TCP connection, on/off. MaxKeepAliveRequest determines the number of HTTP requests per connection. KeepAliveTimeout determines the idle time for a connection,Once a request is received, the timeout value specified by Timeout directive applies. These 4 directives in combination will determine the server efficiency in processing requests. It is recommended that KeepAliveTimeout should not be more than 60 seconds same should be set for Timeout , and MaxKeepAliveRequests should be set to a high value(say 500) a value of 0 represents infinite number of requests.
ServerSignature can be set to off, on or email. By default it is set to on and returns the server name and version and modules loaded at startup, information with any server generated pages like error pages. Setting it to email will also include a mailto: link to server administrator as defined my the directive ServerAdmin . To prevent targeted attacks on the server this directive must be set to off.
Options Indexes, DirectoryIndex
When the client requests an index of the directory by specifying a / at the end of the directory name 3 things can happen, Apache servers an index.html file present in the directory, it serves a directory listing of all the files and folders in the directory this can be dangerous as it gives away crucial file system information, it returns an error page saying the directory is not accessible. The directory should contain the a file by the name as specified in the DirectoryIndex directive.
DirectoryIndex index.html, index.txt, /index.html
It can be noted that absolute files need not be relative to the directory and a default index file can also be served by the server.
Options FollowSymLinks, SymLinksIfOwnerMatch
FollowSymLinks and SymLinksIfOwnerMatch allows the server to traverse to the path where symbolic link files in the current directory point to. In latter case server will traverse to the symbolic link path only if the ownership of the destination file or directory is same as that of the link. Both options are not recommended to be set as this provides a way of executing files outside the context of the current directory. For example if FollowSymLinks is allowed in /var/cgi-bin directory then any malicious user could place a symbolic link file to point to a file placed in any of the system directories(/,/etc) and gain access to server resources.
It is recommended that Options is set to none at httpd.conf file and turned on for specific directories accessed.
AccessFileName, AllowOverride, Allow, Deny
These are access control directives which help in restricting the use of the various directives in the different file system paths of the server.
AccessFileName directive specifies the file (default is .htaccess) which is used to configure security settings for each directory traversable by the server. These settings by default override the settings in the main configuration file by the AllowOverride directive which is set to "all" .
Allow, Deny directives specify which hosts or networks can access resources at the server. A combination of these directives can help to configure access control at the web server. In the httpd.conf file put the following lines :-
Deny from all
The idea is to first deny access from "all" clients to "any" resources at the server, and then specifically enable access to certain resources to certain users. For example, above configuration prevents running of cgi scripts and SSI(Server Side Include) everywhere on the system.
Now enable use of .htaccess files for specific directories by putting thes lines in httpd.conf
If you observe the above lines , cgi-bin directory can configure a .htaccess file which defines all the directives specifically meant for it.Like Options ExecCGI for executing cgi scripts.
The htdocs file contains static html pages and indexes hence need not have access to all directives, only allow and deny directives can be specified in the .htaccess file for htdocs directory.
Note :- The (.) before "htaccess" is used to hide it from any directory listings generated by the server in response directory requests from clients.
Cgi scripting has long been considered as a security risk for an apache installation, However there are a few basic rules to consider while using cgi scripts for hosting web applications.
- Give access for cgi-bin folder to only script developers.
- Ensure scripts cannot be executed from other sites, Check the HTTP_REFERER environment variable.
- Perform input validation, before inputs are passed to the command line for exection. Allow only those input values which have valid set of characters(e.g :- A-Z, 0-9,) etc.
- Avoid running cgi-scripts under the Apache user, use the suEXEC application which allows cgi-scripts to be executed as a different user.
Let us take a look at a URL pattern which is common to most websites nowadays.
A simple product information request to the website of this kind can reveal details about the underlying technology i.e PHP in this case, used by the website. Information of this kind is irrelevant to the user, but gives hackers enough details to plan and launch attacks on the application running on the web server.
In contrast a URL like the one here http://www.mysite.com/catalog/2 is much safer and easier for navigating the website. We need a way to dynamically redirect link texts like the one above to the real URLs without the knowledge of the website's user. Apache's mod_rewrite module helps to achieve this through a set of rules entered in .htaccess file. Before we look at the rules we shall look at some of the directives or configuration parameters that make up these rules.
RewriteEngine, RewriteBase, RewriteRule
RewriteEngine on - this directive enables rewriting in your website.
RewriteBase www.mysite.com - this directive sets the base URL for all the URLs mentioned in the RewriteRule directive.
Rewriterule <linktext> <realURL> - this directive defines a single redirection rule, many such rules can exist and the order of rules is important.
An illustration of a rule written for mysite.com is as shown below,
RewriteRule ^search$ search.php
The symbols ^ and $ in the RewriteRule directive above signify start and end of pattern matching for the Apache web server. The rule illustrated above transparently redirects any request to www.mysite.com/search to www.mysite.com/search.php
Using Regular Expressions
Regular expressions used in link texts are a way of pattern matching a list of URLs and redirect them to a script that handles inputs from these URLs as parameters. Take the case of requesting product information from a website as discussed above, we write the rule
RewriteRule ^catalog/([0-9]+)/$ catalog.php?itemID=$1
This will match any link texts with 'catalog/' followed by any digit between the range [0-9] (links like 'catalog/2/') and redirect to the PHP page catalog.php. The regular expressions encased in parentheses '()' are indexed and return a value which can be referenced as $1(for the first parentheses), $2(for the second parentheses) and so on. The '+' symbol is a match modifier that modifies whatever comes directly before it, in the above rule it enables digits in the range [0-9] to appear multiple times after the link 'catalog/' i.e links 'catalog/1/' and 'catalog/1000/' are both valid. This provides flexibility of displaying information of as many number of products as possible in the website.
In case a website user references a product in the website using the following URL www.mysite.com/catalog/2, he/she will not be redirected to the PHP page, as the trailing '/' is missing. In order to avoid such a situation we add one more rule which handles such requests and effectively redirects such requests to the same URL with the '/' appended.
RewriteRule ^catalog/([0-9]+)$ catalog/$1/ [R]
RewriteRule ^catalog/([0-9]+)/$ catalog.php?itemID=$1
Thus we have seen that secure configuration of Apache web server involves securing the directory structure and file permissions, setting the appropriate configuration parameters , following precautions while writing cgi scripts and URL redirection to hide the underlying technology used.
In the next issue we shall cover the general secure configuration for IIS web server.
Tags: Best Practices