You may have noticed it's been a while since ModSecurity has had a major release. This does not mean I was lazy. I was working on it throughout, but for various reasons beyond my control, I had to postpone the 1.9 release from Spring 2005 to SummerAutumn 2005. The other day I was compiling a list of new features for a client and I was amazed at the number of new features added. Below is a partial list. It will probably change slightly before the final release. Below is the final list of improvements.
- A brand new audit logging subsystem was added, aimed at supporting real-time audit log aggregation. This subsystem offers significantly better performance (the central audit log lock has been removed), records more information, and allows for log entries to be stored in a database or in flat files. It is now possible configure exactly what is being logged. In the Apache 2.x version of mod_security it is possible to log the response bodies too.
- Several new directives allow for a finer control of how rules are inherited between contexts:
- SecFilterImport - import rules (identified via their IDs) from the parent context
- SecFilterRemove - remove rules from the current context
- SecFilterInheritanceMandatory - force all rules in the current context to be inherited in child contexts. This is useful when distributed configuration (via .htaccess files) is used.
- Improvements to the way per-rule actions are configured:
- Directive SecFilterActionsRestricted which, when enabled, only allows meta-data actions (id, rev, message, severity) to be used as per-rule actions.
- Directive SecFilterSignatureAction can now be used as a template. The actions specified with this directive are inherited by the rules using per-rule actions. SecFilterSignatureAction can appear more than once in a configuration context, and this allows rules to be grouped according to how they respond to attacks. And it allows meta-data to be separated from policy, making it easier to rely on third-party rules.
- A new directive, SecGuardianLog, allows information on all request processed by the web server to be exported to one external process (via piped logging). This is used in mod_security 1.9 to connect Apache to httpd-guardian, a stateful Denial-of-Service defence tool that detects attacks across all Apache processes. When an attack is detected httpd-guardian can communicate with a firewall to restrict access from the IP address. In its default implementation httpd-guardian uses iptables, the Linux host-based firewall, for this purpose.
- New actions:
- setenv - create an environment variable, used to interact with other Apache modules, or applications
- setnote - create an Apache note, used to interact with other Apache modules
- auditlog - force request to be sent to the audit log
- noauditlog - forbid request from being recorded in the audit log
- id - assign unique ID to the rule
- rev - assign a rule revision
- message - assign message to the rule, the message will appear in the log entry (error log, audit log)
- severity - assign severity to the rule; the severity will appear in the log entry (error log, audit log)
- proxy - instead of processing the request locally, use the built-in reverse proxy to forward it to some other web server
- mandatory - mark a rule as mandatory for inheritance
- Implemented performance measurement facilities throughout, in the Apache 2.x version. Now it is possible to measure the performance of ModSecurity itself (each processing phase individually, or each rule individually). It is also possible to measure network performance and the request processing time separately. This separation allows the client communication speeds to be measured, and to look at request processing performance with no impact from slow clients.
- Full support for methods other than GET and POST. Files uploaded using PUT are now treated as files uploaded through POST and multipart/form-data.
- Support for integration with ClamAV antivirus, allowing uploaded files to be inspected for viruses.
- New directive, SecAuditLogRelevantStatus, allows transactions to be recorded in the audit log depending on their response status code. This is useful to record unusual transactions and to allow for communication between applications and mod_security. For example, if an internal error occurs in a script, if it sets the response code to 500 mod_security will record the complete transaction for further investigation.
- Many new variables were added. They allow for a much finer control of what is allowed and what not.
- FILE_SIZE_* - uploaded files' sizes
- FILE_NAMES - look at all uploaded files' names
- FILE_SIZES - look at all uploaded files' sizes
- FILES_COUNT - how many files are being uploaded?
- HEADER_* - look at a specific header
- HEADERS - look at all headers (names and values)
- HEADERS_NAMES - header names (all)
- HEADERS_VALUES - header values (all)
- HEADERS_COUNT - how many headers are there?
- ARGS_COUNT - how many arguments are there?
- COOKIES_COUNT - how many cookies are there?
- A new family of variables allows greater control of which scripts are allowed to run. This feature can be used, for example, to only allow scripts owned by a named user to be run. This would lead attack attempts based on code upload and execution to fail.
- SCRIPT_UID - script user ID
- SCRIPT_GID - script group ID
- SCRIPT_USERNAME - username of the script owner
- SCRIPT_GROUPNAME - group name of the script owner
- SCRIPT_MODE - script permissions
- Added output status filtering to the Apache 2.x version. It is now possible to take action based on the response status code.
- Completely rewritten support for cookies. Two brand new parsers were implemented, one for v0 cookies (Netscape-style) and the other for v1 cookies.
- Improvements to the internal chroot functionality. The implementation is now much cleaner, and avoids a need for a temporary lock file.
- Many smaller improvements throughout.
Update (October 6): The list now includes all the features new to 1.9.
