Detecting and Countering Server Intrusions - Web Server Hardening
(Page 4 of 4 )
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.
- Do server monitoring.
- 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.
Apache HTTP Server
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 following is a set of hardening guidelines for securing Apache:
- The Apache process should run as its own user and not root.
Establish a group for web administration and allow that group to read/write configuration files and read the Apache log files:
groupadd webadmi n
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.
Manage .htaccess from within the httpd.conf file instead of .htaccess. In the server configuration file, put:
<Directory />
AllowOverride None
</Directory>
- Enable Mod_Security. This module intercepts request to the web server and vali dates 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.)
Security concerns
Protect server files by default
Inside the Apache configuration file (httpd.conf) have the following directory directive:
<Directory />
<LimitExcept GET POST>
Deny from all
</LimitExcept>
Order Allow,Deny
Allow from all
Options None
AllowOverride Non e
</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>
Script aliasing
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 (SSI)
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 con tent 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 <--#include virtual="..." --> to execute CGI scripts if these scripts are in directories designated by a ScriptAlias directive.
mod_security
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.
Please check back next week for the conclusion to this article.
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
|
 This article is excerpted from chapter four of Securing Ajax Applications: Ensuring the Safety of the Dynamic Web, written by Christopher Wells (O'Reilly, 2007; ISBN: 0596529317). Check it out today at your favorite bookstore. Buy this book now.
|
|
