Monthly Archives: June 2007

Snort and the GPL version 3

Posted on by

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 Snort.org that SourceFire has chosen not to do the transition to the GPLv3 yet. He points to a page on the snort.org 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.

Compiling Snort_inline with NFQUEUE support on Ubuntu

Posted on by

I needed to setup the right libraries for Snort_inline development on my fresh Ubuntu Feisty installation, so I decided to write down the procedure for those who think compiling Snort_inline from source is hard. 🙂

Make sure you have build-essential package installed. This makes sure you have a compiler and development packages for glibc and other important libraries. I’m installing the libraries from source to get the latest versions because the latest versions are more stable and perform better than the versions included in Feisty. I’m installing them into /usr because some programs like them there best.

Download the library libnfnetlink version 0.0.25 from http://ftp.netfilter.org/pub/libnfnetlink/

$ tar xvfj libnfnetlink-0.0.25.tar.bz2
$ cd libnfnetlink-0.0.25/
$ ./configure --prefix=/usr
$ make
$ sudo make install

Next download libnetfilter_queue version 0.0.13 from http://ftp.netfilter.org/pub/libnetfilter_queue/

$ tar xvfj libnetfilter_queue-0.0.13.tar.bz2
$ cd libnetfilter_queue-0.0.13
$ ./configure --prefix=/usr
$ make
$ sudo make install

Okay, that sets up the Netfilter libraries.

Next is the installation of libdnet. Do not use the dnet packages from Debian and Ubuntu because this is not the same library as we need for Snort_inline.

Download libdnet 1.11 from http://libdnet.sourceforge.net/

$ tar xzvf libdnet-1.11.tar.gz
$ cd libdnet-1.11
$ ./configure --prefix=/usr
$ make
$ sudo make install

Download snort_inline 2.6.1.5 from http://snort-inline.sourceforge.net/

$ tar xvzf snort_inline-2.6.1.5.tar.gz
$ cd snort_inline-2.6.1.5
$ ./configure --enable-nfnetlink
$ make
$ sudo make install

Test if it works (as root):

# iptables -A OUTPUT -p icmp -j NFQUEUE
# iptables -A INPUT -p icmp -j NFQUEUE
# /usr/local/bin/snort_inline -v -Q -H0

Then ping some host and you should see Snort_inline display the packets. If it doesn’t work, it might be that the kernel modules needed for nfqueue are not yet loaded. Using ‘lsmod’ check if ‘nfnetlink’ and ‘nfnetlink_queue’ are loaded. If not, load them manually.

After this, setup Snort_inline as normal.

Sguil 0.7-CVS client on Ubuntu Feisty

Posted on by

I just got a new workstation that I’m setting up today with Ubuntu Feisty 7.04. When setting up the Sguil client from CVS I needed to install the following packages (including dependencies, but apt-get takes care of that):

tcl8.4
tclx8.4
tcllib
tk8.4
iwidgets4

After this it ran but looked horrible because of some ugly font that was used. I found that for my use the following fonts look good:

standard: Bitstream Vera Sans 12
fixed: Bitstream Vera Sans Mono 12

Both fonts are installed by default and can be selected in the Sguil client by opening the ‘File’ dropdown menu and choosing ‘Change Font’.

Debian should update their Snort package

Posted on by

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.

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 😉

TCP Window scaling in Snort_inline

Posted on by

The TCP window field in the TCP header is only 16 bits, so the maximum window size it can handle is only 64kb. A long time ago this was enough, but nowadays it isn’t, by far. Luckily, this is something the window scaling option fixes. Window scaling is very common these days. Your pc or laptop probably uses it by default. Snort’s stream4 however, does not support it. This means that when tracking and reassembling streams, Snort for most connections has no idea about what data is in window and which is out of window. To make matters worse, the packets that are in window when using wscaling, but appear out of window when the wscaling is not accounted for, are never used in the reassembly process. This makes Snort evadable.

One of the goals when creating the stream4inline modifications, was to be able to drop on all TCP anomalies stream4 detects. For this support for window scaling was added to Stream4, so Snort_inline would be able to drop out of window packets. There is however a big problem with window scaling. With window scaling the TCP window possibly increases to a maximum of 1GB (with the maximum wscale value of 14). Stream4 would thus theoretically have to queue up to 1GB of packet data, per stream. While this is something that is unlikely to happen during normal connections, it is possible. This could then be used by an attacker to attack Snort_inline itself.

To prevent this, I added an option to stream4inline that allows the administrator to set a maximum allowable wscale setting. Any higher setting will be normalized away. In these cases the packet is modified and the wscale lowered to the maximum that is allowed. The hosts talking to each other then think the other accepts only the lower wscale and accepts that setting. This can however have some unexpected consequences. If the link that Snort_inline deals with is high speed, high latency or both, setting the wscale value to low can result in serious performance degradation. Connections that are (way) slower than usual is how this issue shows. In these cases the wscale value needs to be increased.

The default value of Snort_inline 2.6.1.5 is a wscale of 2, which is quite low but works fine on my home DSL connection. To change the setting add ‘norm_wscale_max 5’ to your stream4 configuration line. This will allow for a wscale of up to 5. The maximum value is 14. I’d be interested in what values people use on what types and speeds of lines, so please let me know! We can use it to suggest values in the docs or to set a less insane default value 🙂

Sguil 0.7 CVS installation on Debian Etch

Posted on by

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.

David Bianco has written a very nice guide for installing Sguil 0.7 on Redhat Enterprise 4. I used this guide to install the server and sensor on a Debian Etch installation. The main difference is that I used Debian packages where ever possible. These packages could be used:

mysql-server
p0f
tcpflow
tcllib
mysqltcl
tcltls
tcl8.3
tclx8.3

Important: do not use the tcl8.4 package. It is not compatible with Sguil and will produce the following message:

ERROR: This version of tcl was compile with threading enabled. Sguil is NOT compatible with threading.
SGUILD: Exiting…

You can get Sguil 0.7 CVS by checking out the latest CVS version:

cvs -d:pserver:anonymous@sguil.cvs.sourceforge.net:/cvsroot/sguil login
cvs -d:pserver:anonymous@sguil.cvs.sourceforge.net:/cvsroot/sguil co sguil

I will update Modsec2sguil soon!

Snort_inline 2.6.1.5 released

Posted on by

Finally, after many months of development and testing, Snort_inline 2.6.1.5 has been released. It’s the first stable release in almost a year and also the first stable release based on Snort 2.6. William sent the announcement:

snort_inline-2.6.1.5 released

List,

I know it has been a long time since we have had a non-beta release,
but what can I say? Victor and I have both been busy in our personal
and professional lives. If you have been running the version of code
in SVN, there are no major updates with this release other than a
memleak fix for stream4inline. I don't think this gets said often
enough, so I would like to thank Sourcefire for all the hard work they
put into snort and the snort rule sets for which I and the rest of the
community greatly benefit.

Regards,

Will

snort_inline-2.6.1.5
http://snort-inline.sourceforge.net/download.html

Differences between snort in inline mode and snort_inline
http://www.inliniac.net/blog/?p=74

Go and get it! 🙂