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.
