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

ModSecurity Blog: June 2008

ModSecurity Licensing Exception Draft Is Ready

As you may know, ModSecurity is licensed under GPL version 2. This licence has served us reasonably well, but there’s been one problem that has been following us for a long time. I chose to use the GPLv2 for ModSecurity, back in day, mostly in order to prevent the use of ModSecurity in proprietary derivative works. This strategy worked, but it had an unfortunate side effect of also preventing creation of open source derivative works due to the incompatibility between the Apache Software License version 2 and the GPLv2. The problem eventually caused the removal of ModSecurity from Debian.

After the GPLv3 was introduced we had an option to switch to it (the incompatibility with the ASLv2 was fixed), but doing that would require a significant investment to fully understand the new licence and the consequences of its use. (Decisions were easier to make when I was the only person making them; now there are quite a few people involved.) The fact that GPLv3 hasn’t been proven in practice does not help. At some point we realised that the path to fixing the problem was not through the licence change, but through an exception that would grant additional rights to qualifying open source projects. The exception creates additional rights for those who choose to accept it, but it does not change the licence of ModSecurity itself, which remains licensed under GPLv2. Changes and improvements to ModSecurity must still comply with the GPLv2.

Anyway, the final draft of the exception is ready: ModSecurity_Licensing_Exception_1.0-draft5.pdf . Here’s a brief overview:

  1. You want to package a web server distribution based on Apache and you want to include ModSecurity in it. The Exception allows you to do this for as long as all the components use the approved open source licences.
  2. If you make changes or improvements to ModSecurity, or write code that links with it—either directly or indirectly (e.g. through a third component)—such code must be released under GPLv2; it cannot be covered by the Exception.
  3. If you build a user interface to control the derivative work (and thus ModSecurity too) you can choose any approved open source licence for it.

The plan for now is to give you some time to send us feedback, if you wish. If everything goes well, the next stable version of ModSecurity will include the Exception too.

Integrating Vulnerability Scanners and Web Application Firewalls

In case you missed it, Breach Security has teamed up with WhiteHat Security so that their Sentinel scanning service will automatically create custom ModSecurity rules for certain classes of vulnerabilities that they find in your web applications.  This works with both open source ModSecurity installations and with the commercial M1100 appliance.  If your initial reaction to this is not "Wow, that is cool!" then you probably have never been in the operational security position of having to protect public web applications.  In order to paint a better picture of why this is a pretty slick integration, let me provide you with some background.

As I mentioned in my previous post - What's the Score of the Game - I feel that one of areas where organizations are failing, with regards to web application security, is that there is a lack of communication between the following three groups: Development teams (who are running source code reviews), InfoSec teams (who are running vulnerability scans) and Operational Security teams (who are running web application firewalls).  These three teams each have unique perspectives on the vulnerabilities of the webapps and they should share their data with each other.

Speaking from my own personal experience, I used to lead an operational security team for a federal government customer.  I was charged with defending the public web applications and had built some home-grown ModSecurity WAFs to allow me to implement virtual patches for identified vulnerabilities while the development teams tried to address the root causes.  Unfortunately, much of my time was spent simply tracking down information about the vulnerability.  Either the vulnerability scanning team did not always provide OpSec with the results or the development teams didn't want to provide details about their "Ugly Baby".  So, I would get an initial statement that application X has an SQL Injection issue but with no actionable details (what host, url and parameter).

When I did track the technical information down, the next step was to analyze the details to see if it provided enough information for me to create an appropriate filter.  This was hit and miss, especially if the vulnerability scans were not tuned or if the secure code review consultant didn't understand how to abstract out and explain how a remote client could exploit the issue.  The point is that I spent a fair amount of time in the research phase.

When I did get enough information, I then had to create some ModSecurity rules and run through some testing to ensure that it functioned as expected and did not deny any legitimate traffic.  I could then deploy the virtual patch in production in a logging-only mode until we could schedule a re-scan.  At that point I could switch it into a blocking mode.

When considering the whole "Time to Fix" concept, the process I was going through was much faster then the actual source code fixing route, however it was still manually intensive and took a fair amount of time.  This is where I believe that the real value of the Sentinel + ModSecurity integration shows by automatically creating these custom ModSecurity virtual patches, we are solving two big problems -

  1. Shrinking the time to fix - the process is expedited as the WAF analyst does not need to manually research, create and test the virtual patch, and
  2. Increased confidence in blocking - The virtual patch is a targeted negative security filter that will not block legitimate traffic.

One other added benefit is that many organizations do not necessarily have technical staff with the required skillset to properly create ModSecurity virtual patches.  With this integration, you don't have to have a ModSecurity guru on staff to create the rules.  It will very interesting as Whitehat Security starts to track the "Time to Fix" metrics of their clients and to see how the customers who have ModSecurity installed fair against those that are using traditional code change processes!

ModSecurity Is Blooming

OWASP AppSec Europe 2008 in Ghent, which I wrote about in a previous post, indeed felt like a ModSecurity user meeting. We kicked-off the conference with 2 days of ModSecurity training, with 8 people attending. Eight is not only the perfect number of attendees for a class (you get enough time to speak properly with everyone), but also a great number in terms of interest in ModSecurity. Our traditional party was very popular (Breach Security always throws an OWASP party on the last training day), and I had the pleasure of speaking to many ModSecurity users. But the truly great thing was that I didn't have to explain to anyone what ModSecurity was--everybody knew! Admittedly, it's a self-selected group of people, but it's an achievement nevertheless. It means that we've made yet another step forward.

Above everything else, it is becoming increasingly evident that there's an emerging group of ModSecurity power users, who are either running their own projects related to ModSecurity, or stretching, in their deployments, what ModSecurity can do. I've had the fortune of talking to three such users at the conference (in no particular order): Christian Folini (REMO), Christian Bockermann (JWall) and Marc Stern.

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