ModSecurity Trustwave
This blog has moved! Please update your
bookmarks to

ModSecurity Blog: November 2005

Positive security model in ModSecurity

One of the major improvements in the next release of ModSecurity (v2.0) will be the support for a positive security model. Even now, with its flexible rule language, ModSecurity supports the positive security model. But there are areas that are not covered (e.g. automated policy generation is difficult to achieve) so I have decided to provide a complete solution for this problem.

I have been looking at the possible solutions for a positive security model for some time now. There are three ways to solve the problem:

  1. Strict and comprehensive resource and parameter checking.
  2. Statistics-based anomaly detection (a very interesting paper on this subject).
  3. Anomaly detection based on neural networks.

I have decided to start with the first option, mostly because this approach is easy to understand and allows whitelists to be created and/or updated manually. Furthermore, it may be possible to get the developers to distribute positive security model configuration files with their applications. Automated tools may be used to create these files in the first place. Below is a quick overview of what I have in mind:

  • Access to some areas of a web site need not be controlled (allow all).
  • Access to some areas of a web site must never be allowed (deny all).
  • Web site is a collection of resources (e.g. scripts).
  • Each resource can be used in one or more different ways (resource profiles).
  • Each profile needs to support a different set of parameters. (For example, one set of parameters is used when the resource is invoked with GET, another set of parameters when resource invoked with POST.)
  • Parameters are identified by their name, type (field or file), cardinality, character class (or a fixed range of acceptable values), and length (minimum and maximum).
  • Additional support for parameter arrays (dynamically created paramters) is needed.
  • Support for parameters transported in PATH_INFO is needed.
  • Support for parameters transported in the URI (e.g. URI append) is needed.

A full XML-based configuration file example is available here.

Our bundle of joy has arrived!

I am very happy to report my wife Jelena and I have just become parents of a little baby girl. She is absolutely adorable! She surprised us a bit by arriving a couple of weeks early, but we were more than happy to see her!

Software Documentation with DocBook Quick HOWTO

I am amazed how we still don't have proper technology to produce technical content. If you are just starting on a software project you can, for example, choose to use your favourite text processor. (It is what I initially did for ModSecurity.) This choice is quick to start with and allows you to write comfortably. Unfortunately it is not adequate when it comes to publishing. The text processor I used, OpenOffice, produces nice PDF documents but it fails miserably when it comes to HTML output.

One approach that looks particularly promising is DocBook; I have been looking at it for years. DocBook is a XML-based markup language designed specially to be used with technical content. People behind DocBook have done tremendous work on the backend stuff. DocBook appears to be well-designed and well-documented. You will even find two complete DocBook books, containing everything you need to know, freely available online. The problematic area is authoring, because the support for DocBook in text processors is very limited. Until recently your choice was to write XML by hand or, at best, write with the help of an XML editor. But it is insane to write anything but the simplest documents this way. As if writing is not difficult enough and you need your tools to make it more difficult.

Book publishers are trying to get round this problem by customising the text processors, using special templates and macros. (Publishers also have a much bigger problem as they need to support collaboration between people involved in book writing too.) This approach generally works but it is an one way street. Toward the end of the process the manuscript is converted into something more suitable for use in production. (I don't know what happens when you need to write the second edition, I haven't tried that with my book yet.)


For me, discovery of the XMLmind XML editor was a glimpse of hope. Here we have a tool that allows you to write DocBook in a way that is similar to that of writing using a normal text processor. Naturally, the feature set of this young tool cannot be compared with those of the mature text writing tools. Still, XMLmind editor is quite usable in its current state. What's even better, the Standard edition is completely free. We appear have finally sorted the authoring part of the problem. All you now need is a little patience to learn the DocBook ways (you can start with DocBook 5.0: The Definitive Guide).


After having written the documentation in DocBook you need to figure out how to convert it into one of the supported formats. You will need the following resources for that:

To produce PDF: -xsl $DOCBOOK_XSL_HOME/fo/docbook.xsl -xml input.xml -pdf output.pdf

To produce singe-page HTML: -xsl $DOCBOOK_XSL_HOME/html/docbook.xsl -in input.xml -out output.html

To produce multi-page HTML: -xsl $DOCBOOK_XSL_HOME/html/chunked.xsl -in input.xml -param base.dir ./output/

Although it is possible to use XSL to publish DocBook to text format I did not find the option very useful. You can get much better results creating text output from a single-page HTML using Lynx:

lynx -dump input.html > output.txt

FOP does not support RTF output at this time (although there is some talk of it being supported shortly), but you can produce it with the XSL utility. From the command line:

xslutil -out rtf output.rtf input.xml $DOCBOOK_XSL_HOME/fo/docbook.xsl

ModSecurity for Apache 1.9 has been released!

Finally. I already wrote about many new features available in this release. Relieved from the pressure caused by a long delay between stable releases I can now go and add more features. (Goes away and looks at the TODO list.) Some of the things that are likely to find their way into ModSecurity in the near future are:

  • Positive security model, backed by automatically generated rules.
  • Per-rule configuration of normalisation techniques.
  • Request rating.
  • Stateful operation and session rating.

Hmmm, I wonder which of these I should do first. Have your say!


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


Atom Feed



Recent Entries