Modsecurity

ModSecurity implements security measures similar to URLScan, but on the Apache Web server. One of the other key differences between URLScan and ModSecurity is flexibility. While URLScan provides relatively static protection capabilities, ModSecurity aims to provide a flexible rules engine that can be used to create complex constructs that enable features like forensic logging, real-time traffic monitoring (web intrusion detection), and preventative "soft patching." ModSecurity continues to evolve , and we look forward to even more innovative capabilities in future releases.

This section will describe basic ModSecurity installation and configuration. For links to more advanced information, see "References and Further Reading" at the end of this chapter.

Modsecurity Installation

ModSecurity can be compiled either as a dynamic library or can be compiled into Apache web server base statically. The easier and better method of the two is to compile it is as a module. Compiling it as a module enables easy updates to ModSecurity without recompiling the entire Apache code base. To compile it as a module, run the following command:

 apxs -i -a -c mod_security.c 

This should be sufficient, since the apxs utility will copy the ModSecurity .so file to the correct location and update the web server's httpd.conf configuration file in most cases (or report an error message if it fails).

If necessary, you can manually deploy the .so files as follows :

 cp mod_security.so /path/to/apache/libexec/mod_security.so chmod 755 /path/to/apache/libexec/mod_security.so 

Manual configuration of httpd.conf involves inserting the following line:

 LoadModule security_module libexec/mod_security.so. 

Of course, Apache needs to be restarted following the new configuration:

 apachectl stop apachectl start 

Modsecurity Configuration

ModSecurity is configured by editing the configuration directives contained in the <IfModule mod_security.c> </IfModule> section of the httpd.conf file (much like URLScan is configured using UrlScan.ini). A sample configuration is provided with ModSecurity, and it provides a good template with which to start. The remainder of this section will provide brief overviews of key ModSecurity configuration directives, including our recommended configuration advice. We've organized our discussion around the basic filtering directives provided by ModSecurity (which enable the bulk of its security functionality), general security directives that affect web server security globally, and "housekeeping" directives that specify logistical configurations relevant to ModSecurity itself.

Note 

ModSecurity has many other configuration directives than we list here, and we direct the reader to the public descriptions available on the ModSecurity web site for further documentation.

Tip 

The ModSecurity Rules project provides a very nice collection of prewritten rule sets. They will be distributed with ModSecurity starting with the 2.0 release.

Filter Directives

Like URLScan, one of the primary benefits provided by ModSecurity is the filtering functionality it provides for web applications. Here we list the key filtering directives in ModSecurity, along with our recommended configuration.

• SecFilterEngine (On/Off)  Enables or disables ModSecurity. It is on in the sample script.

• SecFilterDefaultAction (action,log,status)  Provides a list of actions to be taken when match is received on request. The default "reject" action is "deny,log,status:403," which will set the engine to log the rule match and reject the request with status code 403. The action is performed on every rule matched. It is recommended that at a minimum the above string be used.

• SecFilterScanPOST (On/Off)  Enables/disables scanning of POST data. The default configuration has this on, which is also our recommendation.

• SecFilterCheckURLEncoding (On/Off)  Enables/disables the transmission of URL encoding of characters . As we saw in Chapters 6 and 12, attackers frequently URL-encode attacks to bypass input validation or avoid intrusion detection. ModSecurity checks all supplied encodings in order to verify only valid characters are sent. This directive is enabled by default and should remain enabled.

• SecFilterCheckUnicodeEncoding (On/Off)  Enables/disables the transmission of UTF-8encoded character set. As we saw in Chapters 6 and 12, Unicode is one of the more popular encoding tricks used by attackers. SecFilterCheckUnicodeEncoding checks for the proper number of bytes in a UTF encoded string, as well as invalid encoding and overlong character sets. By default, this directive is disabled; it is recommended that it should be enabled.

• SecFilterForceByteRange (lower,upper)  Restricts the range of bytes in a request. The default range of ASCII characters that are allowed are 1 through 255. A setting of 32 through 126 is more secure, since it eliminates ASCII characters usually contained in "random" binary content sent within buffer overflow attacks.

• SecFilterSelective (location,keyword,actions)  An advanced filtering directive. The directive allows you to configure where the search should be performed. The SecFilterSelective directive takes three arguments, namely, LOCATION KEYWORD [ACTIONS]. The LOCATION parameter could be a series of location identifiers, KEYWORD is a regular expression, and ACTION is what action must take place when there is a match. The action parameter can be of primary, secondary, or flow action type. The primary action can be of only one type that specifies where to continue or not. Primary actions can be either deny, pass, or redirect. The secondary actions are performed on the results of the primary action filter. There can be any number of secondary actions. For example, exec is a secondary action. Finally, the flow action can change the flow of rules, thus causing the filtering to skip rules or move to another rule. For example, flow action can be either chain or skip . Since SecFilterSelective can be somewhat challenging to understand, we've provided some examples in the next section.

Examples of SecFilterSelective   The example SecFilterSelective configurations shown next accept request encodings application/x-www-form-urlencoded and multipart/form-data type only. The others are dropped. Additionally, the first rule specifies the method that can be used to pass these types of encoding, namely the GET and the HEAD method. Other than that, all the other methods are rejected. The argument chain specifies that the next SecFilterSelective directive is a flow action that specifies that the action is in continuation from the previous SecFilterSelective directive.

SecFilterSelective REQUEST_METHOD "!^(GETHEAD)$" chain

SecFilterSelective HTTP_Content-Type

"!(^application/x-www-form-urlencoded$^multipart/form-data;)"

Similar to the previous example, the next SecFilterSelective directive specifies that the method used is the GET and the HEAD method; the directive is a flow action that is chained and requires that the content length must not be provided.

SecFilterSelective REQUEST_METHOD "^(GETHEAD)$" chain

SecFilterSelective HTTP_Content-Length "!^$"

The next SecFilterSelective directive example specifies that the method used is only the POST method; the directive is a flow action that is chained and requires that the content length must be provided.

SecFilterSelective REQUEST_METHOD "^POST$" chain

SecFilterSelective HTTP_Content-Length "^$"

The difference between the two HTTP_Content-Length expressions is very subtle. The regular expression for the two are different by just the exclamation mark "!^$" and "^$". The ^ character specifies start of a string and the $ character specifies the end of a string. The ! character at the beginning of ^$ specifies " not ^$", which implies the argument must be empty.

The SecFilterSelective HTTP_Transfer-Encoding "!^$" directive specifies the engine not to accept any transfer encodings.

Some other common attacks against web applications that are potentially mitigated using the SecFilter directive include the directory traversal attack, which can be thwarted by providing "\.\./" as an argument to SecFilter.

Basic cross-site scripting attacks can be disabled by providing "<script" and "<.+>" tags to the SecFilter directive. The "<script" filter will protect against JavaScript injection with the tag script in the input field, and the ""<.+>" will disallow any HTML code in parameters in an input field.

SQL injection attacks can also be filtered by using the SecFilter directive. The delete, insert, and select directives can be intercepted and dropped by providing them as arguments to SecFilter. For example, the following tags will ensure that no dynamic SQL statement with delete, insert, select, and drop is executed.

 SecFilter "delete.+from" SecFilter "insert.+into" SecFilter "select.+from" SecFilter "drop[[:space:]]+table.+"                    SecFilter "drop[[:space:]]+DATABASE.+" 

Other Security Directives

So far we've discussed filtering directives in ModSecurity. This section will cover some other types of security- impacting directives that aren't focused solely on filtering input.

Chroot is a method of restricting a process to an isolated subset of the file system. It is a very involved process to set up a chroot environment. However, with ModSecurity, chroot can be set up very easily. The SecChrootDir directive can be used to set up the chroot.

 SecChrootDir /chroot/apache 

Unlike the traditional chroot, none of the libraries are required for the ModSecurity version of chroot. Only the files that are needed for the web application should be in the chrooted web root.

Housekeeping Directives

So far, we've covered the key filtering and general security-oriented directives in ModSecurity. Here are a few "housekeeping" directives that we considered important to mention:

• SecUploadDir (path)  ModSecurity uploads files to the temporary directory specified by this directive. It is recommended that a directory outside the web root be provided that the web server user can access but that the web application user can't access.

• SecUploadKeepFiles (On/Off)  Controls whether the files that are uploaded to the web server are kept or not.

• SecFilterDebugLevel (03)  Disabled by default (set to 0) and should be left as is. The arguments range from 03, where 3 is very verbose debugging. The related SecFilterDebugLog directive takes an argument of the location of the log file.

• SecAuditEngine (On/Off/RelevantOnly)  Controls extended logging of all the session. It is best to leave this as is (RelevantOnly) as this will log only interesting sessions, thus not filling the logs very quickly. As a partial aside, DynamicOrRelevant (SecAuditEngine setting) and DynamicOnly (SecFilterEngine setting) have been found to be overly challenging for users and are deprecated.

• SecAuditLogRelevantStatus (regex)  Disabled by default. This directive can help log all errors with error codes of a certain range; for example, if you want to log all errors in the 5xx range (internal errors in the web server itself), then setting SecAuditLogRelevantStatus with the regular expression ^5 would record all the responses from the server with 500+ error codes. The information recorded is very detailed, but we recommend leaving it disabled unless you need to conduct forensics.

• SecAuditLog (path)  The location of the ModSecurity log file. If the parameter does not start with a forward slash, the log file is stored relative to the Apache home path. A new audit log type was introduced in ModSecurity 1.9 to increase performance (one file per transaction is created, avoiding the need to synchronize writes between concurrent requests ) and the amount of information logged, and also to allow for real-time audit log aggregation (a proof-of-concept piped logging script, modsec-auditlog-collector.pl, is included in the distribution). The new audit log type can also log the HTTP response body, a feature lacking in previous versions.