Introduction
This document is intended to guide a user through initially setting up and understanding a mod_security+Apache2 under EnGarde Secure Linux setup. Once you have completed reading this document, you should be able to understand the basics of mod_security, what it is used for, and why it may apply to you and your environment.
Why mod_security
The need for mod_security may not be initially apparent since we are all perfect programmers and rarely make a mistake that could prove hazardous to security. It may not be for you, but it is for the users of your servers who may not be as adept in creating web applications.
mod_security is a web application intrusion detection and prevention engine. It operates by ‘hook’ing itself into apache and inspecting all requests for your specific ruleset. It can be used to monitor your server with logging or even protect it by ”deny”ing attacks.
Skills Needed
You will need to have access to the WebTool and the GDSN Package Manager. You need to have shell access to the machine and the ability to use a text editor to make the necessary changes to the configuration files.
Installation
To install mod_security, go into the GDSN Manager in the Guardian Digital WebTool.
1 2 | System -> Guardian Digital Secure Network Module -> Package Management |
Find the line that says libapache-mod_security and check the checkbox next to it. Click the Install Selected Packages button. Let the mod_security package install.
Configuration
Now its time to configure the mod_security package. The first thing that has to be done is to add the configuration file for mod_security (that we are going to create) to the apache2 configuration file. To accomplish this, ensure that the following line is somewhere in your /etc/httpd/conf/httpd.conf:
1 | Include conf/mod_security.conf |
This ensures that when apache2 starts up, the configuration that you spcify in /etc/httpd/conf/httpd.conf will be loaded.
Basic Configuration
Once you have installed mod_security, it’s time for some basic configuration. In order to keep consistency, the mod_security.conf configuration file should be created in the /etc/httpd/conf/ directory. For a basic configuration (which we will walk through step-by-step), your /etc/httpd/conf/mod_security.conf file should looks as follows:
LoadModule security_module /usr/libexec/apache/mod_security.so <IfModule mod_security.c> SecFilterEngine On SecFilterDefaultAction "log" SecFilterCheckURLEncoding On SecFilterForceByteRange 1 255 SecServerSignature "Microsoft-IIS/5.0" SecAuditEngine RelevantOnly SecAuditLog /etc/httpd/logs/modsec_audit_log SecFilterDebugLog /etc/httpd/logs/modsec_debug_log SecFilterDebugLevel 0 </IfModule>
SecFilterEngine
This directive turns on mod_security.
SecFilterDefaultAction
This directive decides what happens to a request that is caught by the mod_security filtering engine. In our case, we are going to log the request. By reading the documentation, you will find that there are many other options
available. By changing this line slightly (once you have logged and found out when and how the mod_security engine catches requests), you can deny requests and produce errors:
1 | SecFilterDefaultAction "deny,log,status:404" |
This line denies the request, logs it to your log files, and send the requester back a HTTP status code 404 (also known as Page Not Found).
SecFilterCheckURLEncoding
This directive checks the URL to ensure that all characters in the URL are properly encoded.
SecFilterForceByteRange
This directive asserts which bytes are allowed in requests. The 1…255 specified in the example allows almost all characters. To bring this down to just the minimal ASCII character set, replace the above line with:
1 | SecFilterForceByteRange 32 126 |
SecServerSignature
This directive can be used to attempt to mask the identity of the apache server. Although this method works well, it is not 100% effective as there are other methods that can be used to determine the server type and version. It should be noted that for this to work, the Apache2 configuration variable ServerTokens should be changed from Prod (default) to Full so the line reads as follows:
1 | ServerTokens Full |
SecAuditEngine
This directive allows more information about the methods of an attacker to be logged to the specified logfile. To turn this on to log every request object use the syntax:
1 | SecAuditEngine On |
This is not very desirable as this produces a LOT of output. The more desirable version is the one used above:
1 | SecAuditEngine RelevantOnly |
This logs only the interesting stuff that may be useful in back tracing the methods of an attacker.
SecAuditLog
This is the location of the audit log file. It is generally preferred to use absolute paths to files to ensure the correct path is being used.
SecFilterDebugLevel
This directive refers to the debug level logged to the specified logfile. The current value of 0 should be used on production systems. While the environment is in testing, a level of 1..4 should be used with increasing
verbosity between from 1 up to 4.
SecFilterDebugLog
This is the location of the audit log file. It is generally preferred to use absolute paths to files to ensure the correct path is being used.
We will add some lines to do some Selective filtering. Selective filters are used to handle some specific situations that cannot be targeted with site-wide policy. However you need to be careful of what you make site-wide policy since some of these security measures can break your current setup.
There are even more in depth uses where you can number rules and apply them to certain sets of directives and not to others. mod_security allows for very granular control. The in depth discussions on using these is beyond the scope of this document.
General
Since mod_security is a keyword driven engine, it will take the specified action on simple keyword matches. This is to say that anything that follows the directive SecFilter will engage the appropriate action. For example:
1 | SecFilter ">applet" |
If the <applet> tag appears anywhere in the request, then the log action specified above is taken.
XSS Attacks
To try to prevent some types of cross site scripting attacks, you can add the following lines to your configuration file:
1 2 | SecFilter "<script" SecFilter "<.+>" |
This tries to prevent Javascript injections or HTML injections.
Directory Traversal
Rarely will it be necessary for a user to traverse directories using the “../” construct. In order to prevent that, we can add the line:
1 | SecFilter "\.\./" |
GET/HEAD Requests
With the use of these lines, we will not accept GET or HEAD requests that have bodies:
1 2 | SecFilterSelective REQUEST_METHOD "^(GET|HEAD)$" chain SecFilterSelective HTTP_Content-Length "!^$" |
Unknown Requests
There are occasionally requests that come across (usually malicious) that we don’t know how to handle. At that point we let mod_security handle the request by adding the following lines:
1 | SecFilterSelective HTTP_Transfer-Encoding "!^$" |
Conclusion
At this point, you should be capable of setting up a basic installation of mod_security. They are many more combinations of both simple and advanced techniques and directives that can be used to protect your server. By reading the documentation, you can have very granular control over your web server attack detection and prevention.
