Snort license changes revisited

Today I noticed that Snort 2.7.0 was quietly released on July 12th. I have a problem with this release, a licensing problem. I have written about my issues with Sourcefires Snort licensing before here and on the mailinglist as well, here. They seem to have listened a little bit, since they are no longer claiming copyright of Todd C. Millers BSD licensed strlcpy and strlcat implementation. Sadly, our other complaints are completely ignored.

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 <>”. 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 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 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 (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.

Snort and the GPL version 3

Today the final version of the GPL version 3 was released. This is interesting from many perspectives, and one of them is Snort licensing. Much has been written about Snort and the GPL lately, but that was all about new license language introduced with Snort 3.0 alpha and not about the currently maintained and developed 2.6 and 2.7 branches. When I’m talking about Snort here and now, I mean those versions prior to 3.0.

Snort, like many other OSS projects (including my own Vuurmuur and Modsec2Sguil) comes with many files (but not all) that are distributed with the following lines in the copyright notice:

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

What it says, is that the GPLv2 license applies to this file, but that if there is a newer GPL license available (GPLv3 in this case), you may choose to ‘redistribute it and/or modify it’ under that later version. So it appears that this means that the files in Snort that contain this header can be distributed under the GPLv3 as well.

SourceFire however, disagrees. Martin Roesch wrote on that SourceFire has chosen not to do the transition to the GPLv3 yet. He points to a page on the site where it is explained why SourceFire thinks that despite the ‘(at your option) any later version’ line, only the GPLv2 applies to Snort.

The reasoning is rather simple, Snort is governed by the GPLv2 because it is governed by the GPLv2. Here is how SourceFire said it:

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

I think this is an impossible position. For years the Snort source code has been distributed leaving the option to developers to pick a new version of the GPL when it would become available. But now that this time has come, they are coming back to that. Here is what they say:

For ease of reference, the comparable notice that is used with SNORT (contained in the ‘README’ file) is as follows:

“This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License Version 2 as published by the Free Software Foundation. You may not use, modify or distribute this program under any other version of the GNU General Public License.”” (source)

Note however, that future versions of Snort may hold this notice, but currently released code does not. Apparently, SourceFire has no trust in their own explanation of the ‘(at your option) any later version’ line, so they are going to remove it altogether.

In my opinion this is effectively a licensing change. It changes from GPLv2+ to GPLv2. This has a couple of implications. First of all, all code already out there is licensed as it is. The language in the source files is clear. Second of all, while SourceFire has certainly written the vast majority of code, not all code in Snort is copyrighted by them. Copyright of the Snort_inline project was not transferred to SourceFire when they incorporated our inline patch in 2.3.0RC1. There may be other contributions by others without copyright transfer.

Many projects have chosen to change the licensing language long ago to remove the ‘(at your option) any later version’ line. SourceFire hasn’t done this. It is my believe that by deliberately spreading the code with this clause for many years, SourceFire is allowing anyone to ‘redistribute it and/or modify’ the affected source files under the GPL version 3.

Disclaimer: this is my personal opinion, not (necessarily) the opinion of other Snort_inline developers.

Debian should update their Snort package

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

So why is Debian not updating Snort? The answer can be found in the Debian bugtracker. Snort is released under the GPL and up to and including version 2.3.3 included a ruleset. But since then only Snort itself is distributed under the GPL, the (VRT) rules are now under a less free license. Of course the user can get them for free, but with a 30 day delay and only after registering with SourceFire. Big deal, I would say, just remove the rules from the package and put some doc describing how to get rules. But the Debian maintainer doesn’t like this idea:

“Consequently, upgrading to 2.4 would mean providing just an IDS engine, not an IDS “service”.” (source)

I think this reasoning makes no sense, for a number of reasons:

  1. Snort can be useful even without any rules: it can detect anomalies in stream tracking, dns, ftp, http, smtp. It can provide statistics, capture traffic.
  2. Managing the Snort rules through the very static Debian packages system make no sense in the first place. Many of the rules change weekly or even daily. Debian would never update the package for this. Oinkmaster should be used for this, and Debian provides this tool as well.
  3. People can write their own rules.
  4. There still are many free rules available. The Snort community rules are GPL licensed, Bleeding rules are BSD licensed. Together they have thousands of rules.

So Debian, please make your Snort package usable again, and update it to the latest stable version! And while you are at it, provide an inline enabled package as well 😉

Differences between Snort and Snort_inline

Every few weeks the same question comes up: what is the difference between Snort in inline mode and Snort_inline. This makes sense, because the Snort_inline documentation and website fail to explain it. In this post I will try to highlight the main differences. In general I can say that we try to develop Snort_inline as a patchset on top of Snort. Snort_inline is focused at improving the inline part of Snort. Originally of course, Snort’s inline capabilities were developed in the Snort_inline project. With Snort 2.3.0RC1 they were merged into mainline Snort.


We did a number of things to make Snort_inline a little more convenient for inline users.

  • inline is enabled by default in ./configure
  • we got rid of libnet 1.0.2a, switched to libdnet 1.1 instead
  • a snort_inline specific manual page was added, as well as some extra docs
  • a example configuration file for inline use is supplied

Added functionality

  • we support Linux’ new queue’ing mechanism called nfqueue. This was contributed by Nitro Security. Nfqueue supports running multiple copies of Snort_inline to take advantage of SMP and reduce risk of denial of service when Snort_inline should crash.
  • stickydrop preprocessor enables you to add options to the rules to block an ipaddress for a configurable amount of time
  • bait-and-switch preprocessor (Linux only) allows you to redirect traffic from a host to a honeypot based on the rules
  • clamav preprocessor is included (you still need to pass –enable-clamav to ./configure)
  • reinject action for FreeBSD: reinjects an accepted packet into the ipfw list at a specific rule number

Improved for inline use

  • reject action can send RST packets to both source and destination
  • stream4 can drop attacks detected in the reassembled stream. It also enforces the TCP window. It implements a number of ideas from Vern Paxson on TCP reassembly, such as a limit on the number of out of order packets and bytes that are accepted in a stream.
  • some fixes for FreeBSD

As the list shows, if you are interested in Snort running inline, using Snort_inline might be a better choice for you!

New WordPress issue + Snort and ModSecurity rules

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:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”WORDPRESS wp-login.php redirect_to credentials stealing attempt”; flow:to_server,established; uricontent:”/wp-login.php”; nocase; uricontent:”redirect_to”; pcre:”/redirect_to=(ht|f)tps?://iU”; classtype:web-application-attack; sid:4000003; rev:1;)

Update 2: fixed the Snort rule, thanks to Shirkdog for pointing out that it had some broken pcre in it. The rule is now included in the BleedingThreats ruleset (check here), however that (slightly modified) rule doesn’t detect the attack for me.

Update 3: the Bleeding rule is now fixed. I’ve updated the above rule as well.

Update 4: updated the ModSecurity rule to prevent a possible evasion by prepending tab chars to the redirect url. Thanks to Ryan Barnett for pointing this out.

Experimenting with IPv6

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:

Linux firewalling: IPtables supports IPv6 for quite some time, however it only very recently gained stateful packet filtering support. This hasn’t made it into Debian Sarge or even backports yet, so I’m just using stateless filtering now.

Vuurmuur: my own IPtables frontend has no support for IPv6 at all. I’ve been thinking about adding it for years, but decided to wait at least until stateful support would be available. Next to this my coding time is limited, and many other features are probably more interesting to Vuurmuur users.

Snort/Snort_inline: both Snort and Snort_inline lack support for IPv6. Sourcefire is working on it as far as I know, but no code is available from them. I did find a IPv6 patch for Snort 2.3.3, which can be found here. I ran it in sniffer mode and that works. I haven’t played with it much other than that, but I certainly will in the future.

ModSecurity: my Apache 2 installation has IPv6 enabled by default and ModSecurity 2.x just worked with it without any configuration change! I haven’t looked into how to create rules specific for IPv6 addresses however, so maybe surprises will come up here. I do know from looking at the source that the rbl functionality doesn’t support IPv6 addresses yet, but I haven’t even checked if realtime blacklists exist for IPv6.

Sguil/Modsec2sguil: my modsec2sguil script, that takes ModSecurity alerts and feeds them to Sguil, doesn’t act on the IPv6 alerts because it expects IPv4 addresses. This is not a problem however, since Sguil doesn’t support IPv6 addresses. This makes sense since Snort doesn’t support it either.

So compared to my IPv4 access, protection is somewhat limited. I’m only enabling HTTP for now, so ModSecurity should be able to handle that just fine.

Anyway, it seems to be working fine now, but consider the IPv6 support experimental, as I’m playing with how it all works. So don’t be surpised if it’s broken all of a sudden 😉