Now that we have a secure, stable, bastionized host to begin with we can look at the web server itself. First, you are going to have to decide which web server to use. Ubuntu came with Apache2—at least that is what was installed after I chose the install LAMP option—so, I am going to start there. But several web servers are available, some part of larger frameworks like application servers.
The following are some general guidelines to protecting web servers/traffic:
Run SSL. Probably one of the best security things you could do is invest in a digital certificate (http://www.verisign.com) for your web server. In an age where Internet attacks are on the rise, it is hard to tell a secure site from an insecure one. SSL goes a long way toward solving that problem.
Require that all cookies going to the client are marked secure.
Authenticate users before initiating sessions.
Read the logs.
Validate fire integrity.
Review web application for software flaws and vulnerabilities.
Consider running web applications behind a web proxy server, which prevents requests from directly accessing the application. This creates a place where content filtering can be done before data reaches the application.
Now, let's look at the specific web servers and see what we can do to secure them.
The Apache HTTP Server is the most popular web server on the Internet, which helps explain why it comes as the default web server on so many systems. The Apache HTTP Server Project is an effort to develop and maintain an open source HTTP server for modern operating systems including Unix and Windows. The goal of this project is to provide a secure, efficient, and extensible server that provides HTTP services in sync with the current HTTP standards.
The Apache process should run as its own user and not root.
groupadd webadmin chgrp -R webadmin /etc/apache2 chgrp -R webadmin /var/apache2 chmod -R g+rw /etc/apache2 chmod -R g+r /var/log/apache2 usermod -G webadmin user1,user2
Establish a group for web development.
groupadd webdev chmod -R g+r /etc/apache2 chmod -R g+rw /var/apache2 chmod -R g+r /var/log/apache2 usermod -G user1,user2,user3,user4
Establish a group for compiling and other development.
group development chgrp development 'which gcc' 'which cc' chmod 550 'which gcc' 'which cc' usermod -G development user1,user2
Disable any modules you are not using.
<Directory /> AllowOverride None </Directory>
Enable Mod_Security. This module intercepts request to the web server and validates them before processing. The filter can also be used on http response to trap information from being disclosed. (Note: enabling this module does have performance implications, but the security benefits far outweigh the performance impact for a web site with moderate web traffic.)
Enable Mod_dosevasive. This module restricts the amount of requests that can be placed during a given time period. (Note: enabling this module does have performance implications, but the security benefits far outweigh the performance impact for a web site with moderate web traffic.)
<Directory /> <LimitExcept GET POST> Deny from all </LimitExcept> Order Allow,Deny Allow from all Options None AllowOverride None </Directory> <Directory /var/apache2/htdocs/> <LimitExcept GET POST> Deny from all </LimitExcept> Options -Indexes -FollowSymLinks -Multiviews -Includes Order Allow,Deny Allow from all AllowOverride None </Directory>
From a security perspective it is better to designate which directories can employ dynamic functionality or execute scripts. By using script aliases administrators can control which directories and resources will be allowed to execute scripts. If a site needs the ability to execute scripts this approach is preferred.
Server side includes are directives found in HTML pages that Apache evaluates while serving a page. If SSIs are enabled they allow dynamic execution of content without having to initiate another CGI program.
Generally I recommend not using SSIs. There are better options for serving dynamic content. SSI is easy to implement but because of its flexibility hard to secure.
Users may still use
--> to execute CGI scripts if these scripts are
in directories designated by a ScriptAlias directive.
mod_security is a web application firewall that is an Apache Web Server add-on module that provides intrusion detection, content filtering, and web-based attack protection. It is good at detecting and stopping many known web attacks, such as many SQL injection type attacks, cross-site scripting, directory traversal type attacks, and many more.
mod_security does come with a performance cost. Because the module must inspect web traffic going both to and from the web server it can cripple sites with high user loads. In most cases, however, the security benefits far outweigh the performance costs.
apt-get install libapache2-mod-security a2enmod mod-security /etc/init.d/apache2 force-reload
mod_security.conf contains an example mod_security configuration. The example configuration has a lot of stuff in it that we may not need, so I recommend trimming the file down a bit and starting with the basics:
<IfModule mod_security.c> # Turn the filtering engine On or Off SecFilterEngine On # Make sure that URL encoding is valid SecFilterCheckURLEncoding On # Unicode encoding check SecFilterCheckUnicodeEncoding Off # Only allow bytes from this range SecFilterForceByteRange 0 255 # Only log actionable requests SecAuditEngine RelevantOnly # The name of the audit log file SecAuditLog /var/log/apache2/audit_log # Debug level set to a minimum SecFilterDebugLog /var/log/apache2/modsec_debug_log SecFilterDebugLevel 0 # Should mod_security inspect POST payloads SecFilterScanPOST On # By default log and deny suspicious requests # with HTTP status 500 SecFilterDefaultAction "deny,log,status:500" # Add custom secfilter rules here </IfModule>
From here, we can look at what actions we can configure.
Table 4-1 lists the most important actions mod_security can apply to an event caught by the filtering ruleset.
Table 4-1. mod_security filtering rulesets
Skip remaining rules and allow the matching request.
Write request to the audit log.
Chain the current rule with the rule that follows.
Deny the request.
Execute (launch) an external script or process as a result of this request.
Log the request (Apache error_log and audit log).
Message that will appear in the log.
Do not log the match to the audit log.
Do not log the match to any log.
Proceed to next rule.
If request is denied then redirect to this URL.
Now, we can configure a few basic rules specific to our environment that enable mod_security to protect our applications.
Let's say some of our applications pass parameters around that
may end up in our MySql database. Let's also say we were lazy and
did not positively validate those fields before trying to
INSERT them into the database. Then, some
wily hacker comes along and tries to perform a SQL injection
So, how does this really work? With mod_security's filters we can write rules that look for these kinds of attacks:
SecFilter "drop[[:space:]]table" SecFilter "select.+from" SecFilter "insert[[:space:]]+into"
Ivan Ristic has provided a thorough primer on mod_security in his book Apache Security (O'Reilly). Go pick up a copy and have a look. I also highly recommend a visit to the site http://www.modsecurity.org if you intend on using mod_security. There you will find documentation, tools, and additional downloads.
PHP has grown from a set of tools that get web sites up and working fast to one of the most popular languages for web site development. The following are some recommendations for hardening web servers that use or support PHP.
Apply all the Apache security hardening guidelines.
Microsoft Internet Information Services (IIS) is an HTTP server that provides web application infrastructure for most versions of Windows.
In versions of IIS prior to 6.0, the server was not "locked down" by default. This open configuration, although flexible, was not very secure. Many unnecessary services were enabled by default. As threats to the server have increased so to has the need to harden the server. In these older versions of IIS, hardening the server is a manual process and often difficult to get right.
With IIS 6.0 administrators have more control over how, when, and what gets installed when installing the IIS server. Unlike previous versions, an out-of-the-box installation will result in an IIS server that accepts requests only for static files until configured to handle web applications plus sever timeouts, and other security policy settings are configured aggressively.
Make sure that the system IIS is installed in a secured and hardened Windows environment. Additionally, make sure the server is configured to discourage Internet surfing and email use.
Web site resources, HTML files, images, CSS, and so on should be located on a nonsystem file partition.
Only allow Script access when SSL is enabled.
Only allow Write access to a folder when SSL is enabled.
Map all extensions not used by the IIS applications to 404.dll (.idq, .htw, .ida, .shtml, .shtm, .stm, .idc, .htr, .printer, and so on).
Make sure certificates are valid, up to date, and have not been revoked.
Use certificates appropriately. (For example, do not use web certificates for email.)
Remove All Permissions from the Internet Zone.
Filter HTTP requests using URLScan.
Secure or disable remote administration of the server.