So you your boss asked you to secure his new strategic web application which is part of his plan to conquer the world. But that damn developers are used to think that their work is finish when it just works, and debugging their whole code is simply not an option. Here’s the solution: use a web application firewall like ModSecurity2.

ModSecurity can be embedded as a module on your webserver, or you can set up an Apache based reverse web proxy with ModSecurity protecting multiple web sites, without wondering which kind of server they are running.

It can be used in different ways: either to intercept know exploits or suspicious activities, or to simply only allow access to your application web page, parameters, and the kind of characters the value’s parameters are supposed to be… But the last step might require a lot of work, so you may want to combine generic rules with a few rules dedicated to forbid the use of the holes you’ve just found on your brand new web site.

A set of “generic rules” is provided with ModSecurity: the Core Rules. For optimization reasons, the regular expressions (rules are based on regexp) are mixed in a small number of rules and are almost not understandable for most of them. The script used for this task is not yet released, but should be in a “near feature” according to Breach. Update: Yes, it was released here !

You might also pick rules from alternative sources, like

If you install rules from the tarball found on the website, be sure to remove write permissions on them for everybody (yes, default permissions are -rw-rw-rw- !!!).

Now, let’s try to make a few rules:

You might first want to whitelist an IP address. The following rule can be added to your own file on your core rules directory, or better (especially if you have multiple virtual host), on the virtual host config file:

<IfModule mod_security2.c>SecRule REMOTE_ADDR "^$" phase:1,nolog,allow,ctl:ruleEngine=DetectionOnly</IfModule>

What is the meaning of this rule: the first argument is the variable name on which the operator will be applied; the second is the operator, in this case a regular expression; the third one is the action to take, if it matches.

If you want to disable a specific rule, use the following statement:

SecRuleRemoveById 960017

Make sure that it is specified after the rule itself. It is therefore best to place these at the end of your rule files.

It is also possible to combine two rules, if we need to check two different variables. For example, we might want to allow the admin login only from the internal network:

SecRule ARGS:login "admin" "phase:2,chain,redirect:error.html"SecRule REMOTE_ADDR "!^10.0."

In this case, the the user will be redirected on page error.html on the web site. Note that ModSecurity cannot modify the page’s content at this time, but content injection is an experimental feature in the development version (2.5).

You might also enforce password strength, by denying passwords without numeric or special characters (supposing that your form password field name is passwd) :

SecRule ARGS:passwd "!(W|d)" deny

Or, like in the following example:

SecRule ARGS:passwd "!@rx ^(?=.*d)(?=.*[a-z])(?=.*[A-Z])([x20-x7E]){6,20}$" "deny,t:none"

Which means:

  • password length must be between 6 and 20
  • password must contain at least a number, a lower case character, and an upper case one.
  • password may be composed of ascii characters between 20 and 7e (in hexa), which means alphabetical characters, numbers, and special characters
  • the t:none means that ModSecurity must not lower the case even if specified in SecDefaultAction (which is the default in 2.1 versions)

You might also prevent brute force authentication, with this example (taken from the manual) :

SecAction initcol:ip=%{REMOTE_ADDR},nologSecRule ARGS:login "!^$" nolog,phase:1,setvar:ip.auth_attempt=+1,deprecatevar:ip.auth_attempt=20/120SecRule IP:AUTH_ATTEMPT "@gt 25" "log,drop,phase:1,msg:'Possible Brute Force Attack'"

It keeps track of the numbers of login attempts made by IP, and drop the request after a specific threshold (more than 25 for 2 minutes).

With theses examples, you’re now ready to make your own rules to protect your own web applications.

November 29, 2007, 1:08 am lock

Add your own comment or set a trackback

Currently no comments

  1. No comment yet

Add your own comment

To prove you're a person (not a spam script), type the security word shown in the picture.
Anti-Spam Image

Follow comments according to this article through a RSS 2.0 feed