Using Mod_Security to Protect Your Server

Like web servers, application servers are flexible in their configuration. This flexibility allows them to be integrated into diverse environments. However, in many cases the out-of-the-box installation will not be hardened for Internet usage. Steps need to be taken to configure these servers so that they are secure. The following are some hardening guidelines for application servers.

Java and .NET

The following are hardening recommendations for all next generation web application servers, but particularly for Java and .NET servers.

Hardening guidelines

1. Run all applications over SSL.
   
2. Do no rely on client-side validation. Make input validation decisions on the server.
   
3. Use the HttpOnly cookie option to help protect against cross-site scripting.
   
4. Plan how authentication and access controls work before implementation.
   
5. Employ role-base authorization checks for resources such as pages and directories.
   
6. Divide the file structure of the site into public and restricted areas and provide proper authentication and access controls to restricted areas.
   
7. Validate all input for type, length, and format. Employ positive validation and check for known acceptable data before filtering for bad data.
   
8. Handle exceptions securely by not providing debug or infrastructure details as part of the exception.
   
9. Use absolute URLs when sites contain secure and unsecure items.
   
10. Ensure parameters used in SQL statements or data access codes are validated for length and type of data to help prevent SQL injection.
    
11. Mark cookies as “secure.” Restrict authentication cookies by requiring the use of the secure cookie property.
    
12. Ensure authentication cookies are not persisted or logged.
    
13. Make sure cookies have unique path/name combinations.
    
14. Personalization cookies are separate from authentication cookies.
    
15. Require error-directives or error pages for all web applications.
    
16. Strong password policies are implemented for authentication.
    
17. Define a low session timeout (15 minutes).
    
18. Avoid generic server resource mappings such as wildcards (/*.do).
    
19. Protect resources by storing them under the WEB-INF directory and not allowing direct access to them.
    
20. Do not store sensitive data (passwords, private data, and so on) in a web application root directory or other browsable location.

For More Information

Apache. “Apache HTTP Server Project.” http://httpd.apache.org/.

CERT. “Creating a Computer Security Incident Response Team: A Process for Getting Started.” http://www.cert.org/csirts/Creating-A-CSIRT.html.

Howtoforge. “Secure Your Apache with mod_security.” http://www.howtoforge.com/apache_mod_security.

Microsoft. Technical Overview of Internet Information Services (IIS) 6.0. http:// download.microsoft.com/download/8/a/7/8a700c68-d1af-4c8d-b11e-5f974636a7dc/ IISOverview.doc (accessed Dec. 1, 2006).

 “Checklist: Securing Your Web Server.”, http://msdn2.microsoft.com/en-us/library/ aa302351.aspx. 

Microsoft., “Checklist: Securing ASP.NET.”; available from: http://msdn2.microsoft.com/ en-us/library/ms178699.aspx. 

O’Reilly ONLamp.com. LAMP: The Open Source Platform. http://www.onlamp.com.

PHP. “Hypertext Preprocessor.” http://www.php.net/.

Ristic, Ivan. Apache Security. California: O’Reilly Media, Inc., 2005.

Security Focus. “Incident Response Tools For Unix, Part One: System Tools.” http:// www.securityfocus.com/infocus/1679.

Ubuntu. “What Is Ubuntu?” http://www.ubuntu.com/.