ModSecurity Trustwave
This blog has moved! Please update your
bookmarks to http://blog.spiderlabs.com/modsecurity/.

ModSecurity Blog: September 2005

A few more features made it into ModSecurity 1.9

A small number of new features made it into 1.9 at the very last minute. Initially I intended to only review code after 1.9dev3 but, as I my review went along, I realised there were certain features that are needed to fulfil the spirit of the 1.9 release. Although 1.9 brings many improvements throughout, this release is about three things: support for real-time audit log aggregation, stateful operation (used in 1.9 for defence against Denial-of-Service attacks; more features will be available in the subsequent releases), and support for rule databases.

With the last improvement in mind, I changed a few things in 1.9dev4. First is the way per-rule actions are merged with the default actions in the configuration context (set via SecFilterDefaultActions). Before there was no merging - if you wanted to change only one thing about a rule you still had to specify (or specify again) every action that needs to happen. Any rule coming out of a rule database would make use of the meta-data actions (id, rev, msg, severity), which means all such rules would make use of the per-rule action list. This would mean rule database producers would have to embed other actions in their rules (whether to deny a rule or not, which status to use, etc), but that is simply not acceptable. You don't want other people to decide your policy for you. What if their rules are not as tight as you would have wanted?

Merging, introduced in 1.9dev4, allows meta-data actions to be used freely while the administrator is still able to retain the control. To reiterate this point further I introduced the SecFilterActionsRestricted directive. When this directive is set to "On", the subsequent rules are allowed to *only* use the meta-data actions. This makes it somewhat safer to use third-party rules on a system.

Another improvement makes it possible now to use SecFilterDefaultAction many times within the same configuration context. The action list specified in the directive will be applied until the next appearance of the same directive. This is another change that allows the user to move the actions out of the rules. Before you could have only one default action list per configuration, so every rule that wanted to do something differently (e.g. not reject the request) had to have a per-rule action list. Now you can simply have multiple occurrences of the SecFilterDefaultAction directive and group the rules according to how they behave.

Now that I look back at the blog entry I have just written I realise ModSecurity is no longer that simple tool it once was. Although it can still be used in a simple manner, if you decide to do so, there is a lot of support for advanced usage scenarios, ones that are often needed in real life.

Apache 2.1.7 beta released

A new beta version of the Apache web server has been released. This release is important because it is a beta version in the 2.1.x development branch, meaning Apache is one step closer to an official 2.2 version. The most important changes are the refactoring of the authentication/authorisation backend, faster and better caching support, and the much improved mod_proxy with support for load balancing.

What's new in ModSecurity 1.9

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_NAME_* -

    • 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.

Being appreciated feels really good

I received a heart-warming email from Roshen Chandran the other day: "A quick note to tell you I thoroughly enjoyed reading Apache Security. We have also made it part of our internal training program here at Paladion. --Roshen". It feels good to be appreciated. Roshen also pointed me to the Apache Security review on Palisade. A positive review aside, I was really pleasantly surprised with Palisade. It is a monthly online magazine that focuses on application security. The content is excellent, but the design and the format are fantastic. I urge you to have a look.

Calendar

November 2010
Sun Mon Tue Wed Thu Fri Sat
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30

Feeds

Atom Feed

Search

Categories

Recent Entries

Archives