At this point I really don’t care much. What the Suricata development by the OISF has shown in my opinion is that we’ve managed to create a very promising new Open Source project out here. In little over a year, funded for about $600k by the US government and with heavy (and growing) industry support, we’ve produced a new IDS/IPS engine mostly compatible with Snort but build on a all new code base an incorporating some very interesting fresh ideas. We’re already seeing a community form around our project with a lot of support from that new community.

So about this performance fuzz. Who to believe? Is Suricata faster than Snort? Yes, no, ehhh, depends on how you look at it. Is Suricata faster than Snort on a single core cycle for cycle, tick for tick? No. It’s pretty clear we aren’t, I didn’t expect us to be either. But we scale. We’ve had reports of running on a 32 core box and scaling to use all cores. There Suricata is much faster. Like Martin Roesch wrote on the VRT blog one can set up Snort on a box to one have instance of Snort per core (or multiple per core). This is in fact the way many appliance builders get to high speeds with it. While this may be feasible for appliance builders, admins we talked to that run their own IDS/IPS think it’s a management nightmare.

As we’re a new project with a fresh codebase, there is going to be a lot of low hanging fruit in performance optimizations. I’ll give an example here. On a test pcap, with a reduced ruleset (about 10k rules), Suricata took about 400s to inspect. Then with a bigger ruleset (about 14k rules), it suddenly took 1600s! After a little bit of cache profiling it turned out that the part of the engine where the address part of a signature was inspected was horribly cache inefficient. In less than an afternoon I rewrote it to be more efficient. Result, the same test now completes in under 600s. This code is in the current git master and will be in 1.0.1.

My point here being that there will be lots of room for optimizations, and not just minor stuff. So far we’ve mostly focused on being accurate (we still have work to do here) and having the algorithms be correct. Hardly any tuning has been done. In our last OISF meeting we’ve gotten a few very interesting help offers for serious performance testing and tuning on some really big boxes, state of the art CUDA hardware, 10GBit labs, etc. So I expect a lot of progress in the months to follow.

It’s clear that we have work to do. What I’m really excited about is how fast that work is progressing, how much help we’re getting both from our brand new community and the industry, and the openness of our development process.

On a final note, during the development of this project we’ve found a lot of bugs and issues in other tools. Will Metcalf, who runs our QA, has been reporting many issues in Snort and VRT sigs to Sourcefire, in Emerging Threats sigs to the ET community. We’ve found bugs in other tools as well, for example in a neat library called libcap-ng. So everyone benefits from our work!

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.

It also does a estimate of the cost of a project. For the Suricata project it currently estimates cost of 2.1 million USD. Actual cost are significantly less than that, less than half of that. So either we are severely underpaid or the calculation is off quite a bit

The per developer code statistics show that I’ve “touched” 131k lines of code out of 148k which confirms what I already knew: I need some vacation…

Anyway, check it out. Vuurmuur is on there, as are Snort and ModSecurity.

Oh by the way, Suricata 1.0 coming out tomorrow!

For the last two years I’ve been doing work as a contractor in the (open source) security field. My experience is mostly in coding in C and Perl, primarily on Snort and Snort_inline. Recently I created the (Perl language) SidReporter program for Emerging Threats. Areas I worked in: IPv6 IDS/IPS coding, signature writing, Web Application Firewalls, threading, bandwidth accounting, and more…

Checkout my LinkedIn profile for more info. My resume is available on request.

If you have some work or know someone that does, please let me know!

Also Richard Bejtlich and Nr have good posts about the improvements of the last versions. See Richards post about a fixed frag3 vulnerability here and see Nr’s post here.

Please note that our SVN code has seen limited testing so far, so be careful! Please report any issues!

First however, I will be traveling to California this week. I will be meeting Will there, so I’ll try to get him to fix that damn code

This update removes the libdnet dependency and replaces it with libnet 1.1. To be able to send ICMPv6 unreachable packets you will need the libnet 1.1 patch I wrote a while ago. You can find that here. Get the latest Snort_inline by checking out SVN:

svn co https://snort-inline.svn.sourceforge.net/svnroot/snort-inline/trunk

Consider the code to be of beta quality for now, so be careful with it. Please report any problems with it!

Again, a big thank you to NitroSecurity for funding this work!

For my work on a IPv6 enabled Snort_inline I’ve only fixed the checksum issue and added a libnet_build_icmpv6_unreach() function. The patch against libnet 1.1.3-RC-01 can be found here. It’s development was funded by the great people of NitroSecurity Inc., who are funding my work to bring IPv6 to Snort_inline. The work is not based on Sourcefire‘s recent IPv6 implementation, so it will be interesting to see if and how those codebases can be used to improve each other. The changes to Snort_inline will be made available as well later, WhenItsDone(tm) Like with the support for NFQueue, NitroSecurity gives back to the community, which I really appreciate!

The patch: http://www.inliniac.net/files/libnet-1.1.3-RC-01-ipv6.diff.gz

Sourcefire claims that Snort is governed by the GPLv2 only. There is a problem with this claim. It’s actually a license change from the recent past. Snort used to be under “GPLv2 or (at your option) any later version”. Now it isn’t anymore. Thats a license change. Now don’t get me wrong, I don’t have any problem with Sourcefire relicensing their code. It’s their right do so. But only for their code. Not for my code, not for code they don’t own the copyright from. In other words, not for all of Snort.

Sourcefire changed the license also for the parts of Snort they don’t own. But, the funny thing is, Sourcefire isn’t even claiming full copyright on Snort. For example in src/inline.c they state “Portions Copyright (C) 1998-2006 Sourcefire, Inc.”. In another example, the file src/preprocessors/spp_arpspoof.c states “Copyright (C) 2001-2004 Jeff Nathan <jeff@snort.org>”. There are many more files where Sourcefire doesn’t claim the (full) copyright for an obvious reason. They don’t own it for these files.

Sourcefire says it is distributing Snort under the GPLv2 so that’s the license governing it. Yes it’s true: Snort until this day is and was distributed with a copy of the GPLv2 license. But their site until very recently clearly stated “This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.” (source). How recent is recently? Well the newest archived version of the Snort site in the wayback machine is from May 9th, 2007. It has the above text, thats less than three months ago. This was no accident, this line of text has been on the Snort site as long as the wayback machine takes us back, which is until the year 2000. But wait, there is more: Many, I estimate the majority, of the source files of the Snort source code of Snort 2.6.1.5 contain that same line as well.

So now Sourcefires claims that “SNORT is an open source project that is governed exclusively by the GPL V2 and any third party desiring to use, modify or distribute SNORT must do so by strictly following the terms and conditions of GPL V2. Anyone using, modifying or distributing SNORT does not have the option to choose to use, modify or distribute SNORT under any revised or new version of the GPL, including without limitation, the GNU General Public License Version 3.” (source) This is clearly a license change because under the conditions active until at least May 9th, 2007, the user was free to select a newer version of the license as well. The funny thing is, the original page stating this is still online at snort.org. And that STILL says “GPLv2 or (at your option) any later version”.

I draw two conclusions from this. First, there was a license change. It’s clear that Snort used to be under the “GPLv2 or (at your option) any later version.” The page claiming that until at least May 9th of this year is even still online. Until 2.6.1.5 (and possibly 2.7.0rc1) most of the source code contained the same language. Second, Sourcefire had no right to relicense all of Snort. They have no right because they don’t own all of the copyright. What can they do about it? Simple: remove the current 2.7.0 release, and replace it by one that respects everyones rights!

Disclaimer: I’m not a lawyer, nor do I look like one or am I married to one. But I believe my point of view is correct. If you believe it’s not, please let me know.