Rules on Inliniac

Debian should update their Snort package

Sat, 16 Jun 2007 12:37:13 +0000

Last week there was some discussion in the #snort IRC channel about why Debian distributes such an ancient version of Snort, namely version 2.3.3. This release is more than 2 years old and no longer supported by SourceFire. The snort.org website says about the old versions:

You should not use these unless you really know what you are doing. Many bugs may have been fixed, including remote vulnerabilities

Even though Debian is able to fix any security bugs themselves, and they don’t need to rely on SourceFire for this, Snort 2.3.3 is still going to be inferior to the recent 2.6.1.5. Why? Well recent Snort versions have many more and improved detection options, such as a better pattern matcher, defragmentation preprocessor, improved stream preprocessor, smtp plugin, etc, etc.

New WordPress issue + Snort and ModSecurity rules

Tue, 20 Mar 2007 18:03:21 +0000

I just read about a new issue with WordPress here at SecurityFocus. It’s a potential credential stealing vulnerability, so I quickly created these ModSecurity 2 rules:

SecDefaultAction “log,deny,status:403,phase:2,t:lowercase,t:escapeSeqDecode” SecRule REQUEST_FILENAME “/wp-login.php$” “chain,msg:‘WORDPRESS wp-login.php redirect_to credentials stealing attempt’,severity:2,t:normalisePath” SecRule ARGS_NAMES “^redirect_to$” “chain” SecRule ARGS:redirect_to “(ht|f)tps?://”

I can still login to my WordPress install, so it seems that the rule does no harm. Use at your own risk!

Update: I’ve created a Snort rule as well:

ModSecurity evasion vulnerability

Tue, 06 Mar 2007 17:35:09 +0000

ModSecurity author Ivan Ristic just reported that a ModSecurity evasion vulnerability has been published without him being notified in advance, so there is no update available yet. Check here for his announcement. And here for the advisory. Ivan Ristic suggests everyone to use this workaround until an updated version of ModSecurity is released (put on a single line):

SecRule REQUEST_BODY “@validateByteRange 1-255” “log,deny,phase:2,t:none,msg:‘ModSecurity ASCIIZ Evasion Attempt’”

I’ve been using that rule for an hour or so, and have seen no false positives so far.

Migrating from ModSecurity 1.9.4 to 2.0.4

Sat, 20 Jan 2007 10:34:05 +0000

ModSecurity 2 has been out for a while now, and although I have played with it some, I never found some time to upgrade my own servers. The upgrading generally went quite smooth, even though ModSecurity 2 changed quite a bit.

First of all there are now 5 phases where you can filter. Actually, one of them only applies to the logging, so you can filter in 4 phases. The phases are headers and body for both request and response traffic. Filtering on specific URIs can be done in phase 1 (request headers), while inspecting a POST payload requires phase 2 (request body).