Detecting and Countering Server Intrusions

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:

1. 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.
   
2. Require that all cookies going to the client are marked secure.
   
3. Authenticate users before initiating sessions.
   
4. Do server monitoring.
   
5. Read the logs.
   
6. Validate fire integrity.
   
7. Review web application for software flaws and vulnerabilities.
   
8. 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:

1. The Apache process should run as its own user and not root.
   
2. 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 
   
3. 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 
   
4. 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
   
5. Disable any modules you are not using.
   
6. Manage .htaccess from within the httpd.conf file instead of .htaccess. In the server configuration file, put:
   
     <Directory />
     AllowOverride None
     </Directory>
   
7. 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.)
   
8. 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.