Modsecurity on Inliniac

Ohloh

Wed, 30 Jun 2010 08:47:54 +0000

Ohloh is a pretty cool site for keeping track of projects and programmers. It’s an easy way to keep track of the development in a project and gives a nice indication of how actively it’s being developed. It has some social networkish features too, such as individual developers giving each other “kudos”.

The code analysis is pretty nice: it gives statistics on code base size, growth, comment ratio, languages used, etc. Per developer it tracks quite a few stats as well.

Removing Trac ticket comment spam in Debian Lenny

Fri, 23 Apr 2010 10:23:20 +0000

The Vuurmuur website runs Trac and overall I’m pretty happy with it. The only thing that Trac doesn’t do well, is dealing with spammers. Spammers target Trac a lot, so that’s a real problem.

To prevent spammers from making it through, I run Scallywhack and a number of custom ModSecurity rules. So far, spams only made it through as new tickets in the ticket tracker, so I installed the TicketDeletePlugin.

Yesterday, I saw the first spam as a comment to an existing and valid ticket. Like tickets themselves, ticket comments can not be removed by Trac by default. Luckily, upstream Trac seems to have fixed this. I’m running Debian’s version of Trac 0.11.1 however, so I decided to patch that. The patches in the Trac ticket #454 didn’t apply cleanly, so I had to patch it manually. To save others the work, it’s available here: http://www.inliniac.net/files/trac_0.11.1-debian-comment_edit.patch

Book review: Magnus Mischel - ModSecurity 2.5

Wed, 31 Mar 2010 13:15:38 +0000

It’s been quite a while since I received my review copy of Magnus Mischel’s ModSecurity book titled “ModSecurity 2.5” but I finally found the time to read it and write up my review. As the title suggest it’s a book about the ModSecurity Web Application Firewall (WAF) module for Apache and about version 2.5 of it specifically. There are some books about the 1.x series of ModSecurity. It’s great that there is a book about the 2.x ModSecurity series now as ModSecurity 2.x is very different from the 1.x series.

Extracting bad url's from ModSecurity events in Sguil

Wed, 14 Jan 2009 23:53:08 +0000

Running a PHP based blog, I see a lot of attempts to include code hosted elsewhere in requests. A long time ago I added a simple rule to block one type of the these attempts. A typical attempt looks like this:

GET /blog/category/index.php?page=http://www.djrady.ru/includes/conf.txt?? HTTP/1.1

Notice the trailing questionmarks? Turns out these are always present, so very easy to block on. I’m doing that for a long time now, never seen a single false positive. The rule looks like this:

Wordpress version 2.6 & ModSecurity

Wed, 16 Jul 2008 16:29:25 +0000

Today I updated my Wordpress installation to version 2.6. The upgrade went smooth as usual. However afterwards I couldn’t login anymore because one of my ModSecurity rules was triggered at the login. Turns out the Wordpress developers changed the use of the ‘redirect_to’ argument in wp-login.php. Wordpress uses it to redirect the browser to some part of the weblog software after a successful login. Some time ago there used to be a vulnerability in Wordpress as described here: http://www.securityfocus.com/archive/1/463291. To prevent exploitation on my box at the time I created the following rule:

Update to Modsec2sguil

Wed, 26 Mar 2008 12:57:13 +0000

Yesterday the much anticipated Sguil 0.7.0 final was released, as was announced here. I’ve updated Modsec2sguil to support it. Next to this Ryan Cummings sent me a patch for supporting ModSecurity 2.5. So that is included as well. I haven’t given it much testing yet, but works on my boxes.

Get the new release here: http://www.inliniac.net/modsec2sguil/

Thank you Ryan for your contribution!

New security weblog by Ivan Ristic

Tue, 22 Jan 2008 11:40:04 +0000

I just noticed that ModSecurity developer Ivan Ristic has started a new blog on computer security and open source. Check it out here: http://blog.ivanristic.com/

Great idea Ivan! :)

ModSecurity rules for Tikiwiki 1.x tiki-graph_formula.php Function Injection Vulnerability

Thu, 11 Oct 2007 11:13:44 +0000

A new vulnerability has been found in Tikiwiki. Read more about it here.

I’ve created the following ModSecurity rule to block it.

SecDefaultAction “log,deny,phase:2,status:403,t:urlDecodeUni,t:lowercase”

SecRule REQUEST_FILENAME “tiki-graph_formula.php” “chain,msg:‘TIKIWIKI tiki-graph_formula.php link inclusion attempt’,severity:2” SecRule ARGS:/^s*[a-z]+$/ “^(ht|f)tps?://”

SecRule REQUEST_FILENAME “tiki-graph_formula.php” “chain,msg:‘TIKIWIKI tiki-graph_formula.php f parameter Function Injection Vulnerability’,severity:2” SecRule ARGS_NAMES “^s*f[.*]$”

Ivan, I hope these rules survive your scrutiny ;-)

Updated at 13:50: The first rule only covered the file inclusion in the title parameter which was what I was seeing in my logs. These rules should cover both the inclusion and the injection.

ModSecurity rule for Tikiwiki XSS

Mon, 27 Aug 2007 15:06:22 +0000

I just read about a Tikiwiki XSS here. Since the Vuurmuur wiki runs Tikiwiki I created a ModSecurity rule for it:

SecDefaultAction “log,deny,phase:2,status:403,t:urlDecodeUni,t:lowercase”

# XSS in remind password field SecRule REQUEST_METHOD “^post$” “chain,msg:‘TIKIWIKI lost password XSS’” SecRule REQUEST_FILENAME “tiki-remind_password.php” “chain” SecRule ARGS:/s*username/ “!^(:?[a-z0-9-_]{1,37})$”

This allows only valid usernames to be entered.

Update: Ivan Ristic privately pointed me at some possible problems with the rule:

the escaping of the - and _ chars is not needed, although it seems to be harmless.
the $ at the end of the filename is dangerous, because Apache treats tiki-remind_password.php/xxx as tiki-remind_password.php. In this case the rule is evaded.
PHP (which Tikiwiki uses) ignores leading spaces in request arguments. So it treats ’ username’ the same as ‘username’. The rule needs to deal with that.

Thanks for your feedback Ivan!

Using Modsec2sguil for HTTP transaction logging

Wed, 15 Aug 2007 13:05:08 +0000

Modsec2sguil is currently configured to send alerts to Sguil. ModSecurity can be configured to log any event or transaction, including 200 OK, 302 Redirect, etc. Modsec2sguil distinguishes between alerts and other events by only processing HTTP codes of 400 and higher. Since 0.8-dev2 there is a configuration directive to prevent certain codes, such as 404, from being treated as an alert.

Now I have the following idea. Since ModSecurity can log all events with details of request headers, response headers and POST message body, it may be interesting to just send all these events to Sguil. They should not be appearing as alerts, but having them in the database can perhaps be interesting. I know using flow data and full packet captures the same data can be accessed, but having it in the database makes querying it a lot easier and longer available.

First Modsec2sguil release for Sguil 0.7-CVS

Mon, 13 Aug 2007 22:00:29 +0000

I just uploaded a new version of Modsec2sguil. I’ve been working on it the last weeks to get it updated to Sguil 0.7. The scripts are changed all over the place. This is because in the 0.7 framework, my scripts would no longer be a replacement for Barnyard only talking to the sensor_agent on the localhost, instead now it would become a full agent talking to the Sguil server directly.

Sguil 0.7 CVS installation on Debian Etch

Tue, 12 Jun 2007 21:58:51 +0000

Sguil 0.7 is getting shape quite nicely. One of the most interesting new features is the splitting up of different types of agents and the option to create ’net groups’. This are groups of agents that Sguil considers part of the same network. You can use this to spread the agents over multiple servers, but still use it from Sguil as if it was one single sensor. For example, this way you can easily create a Snort sensor and a separate full content logging capture server. When you request the full content for a Snort event in Sguil, it will know that it needs to request the packet data from the capture server. This way you can also have multiple Snort agents without the need for capturing the same sancp and full content data over and over again.

ModSecurity IRC channel

Wed, 16 May 2007 09:29:44 +0000

Since a few weeks there is an active IRC channel for ModSecurity. It’s hosted on the Freenode network. The channelname is #modsecurity.

Join us there! :)

Running IPv6 with Freenet6 when on the road

Tue, 27 Mar 2007 18:25:33 +0000

I wrote about my experiments with IPv6 before. These were done for my home network where I have an ISP that offers an IPv6 tunnel broker. The last two months I have not been in my home, but instead using internet ‘on the road’ mostly through wireless LANs. There are a number of techniques for using IPv6 if your provider doesn’t offer it, and today I stumbled on one in this NetworkWorld article, so I decided to give it a try.

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:

Modsec2sguil 0.7 released

Sun, 18 Mar 2007 10:41:28 +0000

I’ve just released version 0.7 of Modsec2sguil, the set of perl scripts to feed ModSecurity alerts to the Sguil NSM system. The main change of this release is that it adds support for alerts produced by ModSecurity 2.x, while 1.9.x remains to be supported. Next to this the conversion between ModSecurity’s severity and Snort’s priority was fixed, so alerts should show up in the right pane in Sguil again.

Please give this release a try and let me know how it works for you!

Experimenting with IPv6

Tue, 13 Mar 2007 19:04:51 +0000

My ISP is one of the few here in the Netherlands that provides a IPv6 tunnel broker. I have played with it some during the last year or so, but now decided to get a little more serious with it. So I’ve decided to enable it for my blog. When opening up my site to IPv6 one thing that is important is security. I will describe the status of IPv6 support of my current setup:

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.

Update on using realtime blacklists with ModSecurity

Thu, 01 Mar 2007 08:04:55 +0000

A few days ago I posted a blog article about stopping comment spam with ModSecurity using realtime blacklists (rbl). While the approach was working, I noted having problems with rules when I tried to match on POST methods in HTTP requests.

Luckily, ModSecurity creator Ivan Ristic was quick to point out where the problem is. I’m using the Core Ruleset for ModSecurity, and one thing that ruleset does is use the ’lowercase’ transformation. This converts all text from arguments to lowercase, so my ^POST$ match would never be able to match. So like Ivan suggested, using ^post$ solved this part.

Blocking comment spam using ModSecurity and realtime blacklists

Thu, 22 Feb 2007 22:25:45 +0000

Spammers are known to use compromised hosts from all over the world to send their messages. Many people are blocking or scoring email spam based on realtime blacklist (rbl), which contain ipaddresses of these known bad hosts. In my experience this works fairly well for email. A while ago I noticed in the ModSecurity documentation for version 2.0 that ModSecurity features an operator called rbl, that can be used to check the ipaddress of a visitor with a rbl. So I decided to see if I could use the realtime blacklists to prevent comment spam on my blog. Turns out this works great! In this post I’ll show how to get it working.

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

Rules for reported Tikiwiki vulnerabilities

Thu, 02 Nov 2006 11:02:52 +0000

Yesterday there was a mail to the bugtraq mailinglist about two types of vulnerabilties in Tikiwiki 1.9.5. The most serious is a claimed MySQL password disclosure through a special URI. The second is an XSS, also through an special URI. The message can be found here.

I wrote ‘claimed password disclosure’, because on the Tikiwiki server I run, I could not reproduce it. With that I mean the password disclosure, since I do see that Tikiwiki gives an error that reveals other information, most notably the location of the website on the local filesystem.

Modsec2sguil 0.6 released

Fri, 06 Oct 2006 22:01:16 +0000

I’ve just release a new version of modsec2sguil, the set of Perl scripts that feeds ModSecurity alerts to Sguil. No new features, but many changes ‘under the hood’. I’ve created two modules, ModsecAlert and SguilBarnyardComms. These can be used in a Object Oriented way to parse ModSecurity events and communitcate a Sguil sensor agent.

It would be interesting to see if the SguilBarnyardComms module could be connected with the work of Jason Brevnik of SourceFire, who wrote a Barnyard replacement in Perl. If I have some spare time, I will have a look at this.

First (beta) release of modsec2sguil 0.5

Wed, 20 Sep 2006 20:26:03 +0000

I have been writing about getting ModSecurity alerts into Sguil before. Today I can finally release a first public version. It’s pretty crude, but it WorksForMe(tm).

The release can be found here. If you are interested, please try it. There is some documentation in the archive.

Sguil: adding support for ModSecurity alerts, continued

Thu, 07 Sep 2006 22:19:34 +0000

After the successful test with the Perl script to add ModSecurity alerts to Sguil, I have been working on a more robust implementation, also in Perl. Let me first describe the basic setup. The setup works with two scripts. The first places links to event files into a special queue directory. The second reads the links from that directory, parses them and sends the alerts among these events to Sguil. After that, the links are removed.

ModSecurity: rule for latest Tikiwiki vulnerability

Wed, 06 Sep 2006 13:02:57 +0000

A few days ago a new vulnerability was reported in Tikiwiki 1.9.x, the software I use for the Vuurmuur Wiki. Luckily, the Snort.org Community rules quickly had a rule for detecting the attack. Because I also run ModSecurity on the webserver, i wanted to have protection there as well. This rule should block the attack:

SecFilterSelective POST_PAYLOAD “jhot.php” “log,deny,status:403,msg:‘LOCAL tikiwiki jhot.php attempt’”

Let’s see if I ever get a hit on it. An update for Tikiwiki as been released, so that should fix the issue completely.

Sguil: adding support for ModSecurity alerts

Wed, 30 Aug 2006 20:14:45 +0000

I’m a huge fan of both Sguil and ModSecurity, but sadly the alerts generated by ModSecurity can’t show up in Sguil… or… can they? Well, if it all works out, soon they can!

Today I have hacked together a perl script that emulates barnyard for ModSecurity. It very much in a proof-of-concept phase, but it somewhat works already, at least good enough so i can show this screenshot.

Nice huh? It is not ready for release yet, but when it is i’ll announce it here. I plan to release it under the GPL. Sguil author Bamm Visscher told me that the next release of Sguil will have support for having barnyard and PADS on the same sensor. By then, i hope that ModSecurity can be added to that list! :-)

Sguil: using advanced queries to get more info on Snort events

Mon, 28 Aug 2006 21:21:54 +0000

Today, David Bianco showed me a way of creating SQL queries that I didn’t even know was possible. This is a technique with which it is possible to query the payload of Snort events in the Sguil database. These payloads are stored by Snort when it alerts and is the payload the actual rule triggered on. David showed a nice example of retrieving url’s for PHP url inclusion attacks.

I have written before about my usage of Mod_Security. I let Mod_Security respond with a 403 Forbidden message. Sadly, the alert generated by Mod_Security can not be displayed in Sguil. As somewhat of a replacement for that, I let Snort alert on the 403 Forbidden messages, so i can see in Sguil that Mod_Security blocked something. The disadvantage of this is that the 403 alert in itself does not contain much info. The sheer number of 403’s makes inspecting every single one with requesting a transcript a bit to much work.

ModSecurity: rules against comment spam

Wed, 23 Aug 2006 08:07:40 +0000

Lately the wiki of my Vuurmuur project has been receiving quite a lot of comment spam. Although removing the spam manually is boring work, i still don’t really mind the spam, because it enables me to practice with ModSecurity rules to fight it off. So far, the spam seems to be following a pattern, in which the spam is posted by bots, and has the same general layout for longer periods of time. That makes it worthwhile to spend time on creating rules against it. Yesterday a new type of spam emerged on the wiki. The following audit_log is for one of them. I had to slightly edit it for layout reasons.

ModSecurity: more security by obscurity

Thu, 17 Aug 2006 07:27:13 +0000

Yesterday, Philippe Baumgart showed me that my obscurity setup is not yet perfect. In fact, he could very easily enter an URL that didn’t exist and caused the webserver behind my proxy to respond with a 404. In this 404 the name and the version of the webserver were exposed.

After some testing i found that adding the following to my config worked very well.

# enable output scanning in Mod Security. SecFilterScanOutput On

ModSecurity: further improvements to the reverse proxy

Mon, 14 Aug 2006 08:52:55 +0000

People can reach my webserver in three ways: by my domain inliniac.net, by the hostname connected to my dsl, and by my ipaddress. What i now wanted is setup the proxy in such a way, that only people visiting inliniac.net would be proxied to the webserver.

Blocking requests that are IP based instead of name based have an important advantage. IP based requests are mostly used by scantools and other forms of malicious traffic that just attempt connecting to port 80 on large IP-ranges. So this way one should be able to keep a lot of crap like worm traffic out.

ModSecurity: redirection

Tue, 08 Aug 2006 22:09:50 +0000

Another nice feature of ModSecurity is rule based redirection. Lets say i want to block visitors of my website from opening the login page of wordpress, /blog/wp-login.php. I could of course just deny access to it, so the visitor gets a 403 error. This works fine, however sometimes you might want to use a more userfriendly message, for example: ‘Due to maintainance logins are currently disabled’.

To do this i first created a very simple html file called nologin.html, and placed it in the webroot of the server. Then i added the following rules to Mod_Security:

ModSecurity: directory hiding a.k.a. security by obscurity

Sun, 06 Aug 2006 20:24:07 +0000

Ok, that’s a bit misleading, because i’m not just hiding, but also blocking and logging. What i wanted is this: I’m running awstats on my reverse proxy, but i don’t want anyone to know. So i just made the entire ‘cgi-bin’ part forbidden for everyone, so that covers the script. The fact that my webserver has a cgi-bin directory is nothing special and won’t tell you i’m using awstats. However, awstats also uses icons, and these are by default in /awstats-icon/

ModSecurity: setting up a reverse proxy

Sat, 05 Aug 2006 13:35:49 +0000

A few weeks ago i wrote that i wanted to investigate setting up a reverse web proxy with mod_security. I have now finally found a little time to do so. What surprised me was how easy it actually is!

<IfModule mod_proxy.c>

#turning ProxyRequests on and allowing proxying from all may allow #spammers to use your proxy to send email.

ProxyRequests Off

<Proxy *> Order deny,allow Allow from all #Allow from .your_domain.com

ModSecurity: my first rules

Tue, 11 Jul 2006 09:37:33 +0000

I have been using ModSecurity for quite some time now to protect a webserver, but i never felt the need to write my own rules. Recently though, my site got quite a lot of spam in the comments of my TikiWiki based site. Since i was not willing to disable the anonymous comment posting i decided to see if i could use Mod_Security to block the spam.

The spam all looked alike with the following characteristics. It all contained a list uri’s with a pipe | before them. So decided to try the most easy way, by blocking all posts with this characteristic.

Books: Preventing Webattacks with Apache

Mon, 10 Jul 2006 21:54:51 +0000

I just finished Preventing Webattacks with Apache by Ryan C. Barnett. Even though the title says it is about Apache it is really mostly about Mod_Security, and this is why i really love the book.

Especially cool is the part of the book where the author challenges the user to setup his ‘Buggy Bank’ example application to play with the vulnarebilities and with the possible counter measures.

This book got me even more exited about Mod_Security, which I use already to protect one webserver. I plan to check out setting up a reverse filtering web proxy soon.