Monthly Archives: May 2007

Installing and creating Autopackages in a chroot

Posted on by

This may be a little off-topic for this weblog, but since I spend quite some time researching this, I’ve decided to write about it anyway. When preparing a new release for Vuurmuur, I wanted to create an Autopackage as well. For those that are unaware of it Autopackage is a distribution independent installer for Linux binaries. Because creating packages for every distro including flavor and versions is way out of my reach, a general installer can save the day.

Because I had some issues with Autopackage 1.2.2 in Ubuntu Edgy, I tried getting a Debian Etch install in a chroot to build the package. However, while installing the autopackage-devel package I got some weird errors:

$ package install /data/Autopackage Development Environment 1.2.3.package

# Preparing package: Autopackage Development Environment
# Checking for required C library versions … passed
# Checking for autopackage runtime prefix … passed
Removing currently installed version of ‘Autopackage Development Environment’.
This may take a moment, please wait … done
# Installing package: Autopackage Development Environment (package 1 of 1)
# Preparing executables…
# Installing executables…
# Copying files to /usr/include
/usr/share/autopackage/apkg-script-utils: line 803: cd: include: No such file or directory
/usr/share/autopackage/apkg-script-utils: line 861: cd: include: No such file or directory
cp: cannot stat `*’: No such file or directory
# Copying files to /usr/libexec
/usr/share/autopackage/apkg-script-utils: line 803: cd: libexec: No such file or directory
/usr/share/autopackage/apkg-script-utils: line 861: cd: libexec: No such file or directory
cp: cannot stat `*’: No such file or directory
# Copying files to /usr/binreloc
/usr/share/autopackage/apkg-script-utils: line 803: cd: binreloc: No such file or directory
/usr/share/autopackage/apkg-script-utils: line 861: cd: binreloc: No such file or directory
cp: cannot stat `*’: No such file or directory
# Installing data files…
/usr/share/autopackage/apkg-script-utils: line 803: cd: share: No such file or directory
# Copying files to /usr/local
FAIL: Package Autopackage Development Environment could not be installed.

After a lot of researching and debugging I finally found out that I forgot to mount the /proc filesystem in the chroot. The /dev/stdin, /dev/stdout and /dev/stderr files should link to /proc/self/fd/0, 1 and 2 respectively. After fixing this installing the package worked fine. Next I tried creating packages and this worked as well. I probably won’t be using the chroot though, because the Autopackage team released 1.2.3 and this release fixed my issues with Ubuntu.

Memory leak fixed in stream4inline

Posted on by

A few days ago William told me that if he enabled stream4inline on a busy gateway, Snort_inline would consume all memory within hours. The problem went away when disabling stream4inline, so it made sense that the problem would be in there somewhere.

The first suspect was the reassembly cache. The reassembly cache is used to keep a per stream copy of the reassembled packet in memory. While being memory expensive, it greatly speeds up the sliding window stream reassembly process, especially with small packets. The reason for this being the first and primary suspect is that this is the only place where stream4inline code allocates memory. Reviewing the code however, showed no leaks and adding a debug counter to monitor the memory usage also showed that the leak was not in that code.

Next my investigation focused on parts where stream4 behaves differently in stream4inline mode. I initially focused on what happened when stream4 hit it’s memory limit: the memcap. When the configurable memcap is reached, stream4 nukes 5 random sessions. In stream4inline the option to truncate 15 of the sessions was added, where an attempt is made to clear the memory by removing stored packets no longer needed from a stream. If that fails, 5 random sessions are nuked anyway.

Reviewing the truncating of the sessions didn’t show anything obvious to me so I went on to the killing of the sessions. Descending down the code I finally reached the DropSession function, where the memory cleanup for a session is handled. Here it turned out that the DeleteSpd function, used to clear the stored packets in a stream, was not called in stream4inline mode. The reason for this mistake is that with Snort 2.6.1 support for UDP was added to stream4. The merge with the Snort_inline code went wrong because of extra checks added to the DropSession function.

The stupid thing is that when I did the merge, I was already in doubt about it as a comment showed:

/* XXX did I merge this right??? VJ */

Guess I know the answer now: No 😉

Vuurmuur NFQUEUE support

Posted on by

Vuurmuur supported the QUEUE target for a while already, even though it needed a little bit of a hack to handle the state. This is because the iptables ruleset Vuurmuur creates is quite simple: after a few general protection rules it starts by accepting traffic with the state established. Since there is no way to say ‘queue established traffic that was queued before’ in iptables I decided to use traffic marking to distinguish between traffic to be queued or accepted. But there was a problem with this approach. I didn’t want to cripple the marking of traffic for other purposes, such as traffic shaping and routing, so I decided to use mark-ranges to either queue or accept:

/sbin/iptables -t filter -A FORWARD -m mark –mark 0x0/0xff000000 -m state –state ESTABLISHED -j ACCEPT

/sbin/iptables -t filter -A FORWARD -m mark –mark 0x1000000/0xff000000 -m state –state ESTABLISHED -j QUEUE

The reason I am explaining all this is that while this works fine for the QUEUE target with a single queue, it won’t work as well for NFQUEUE. One of the new things with NFQUEUE is that there are up to 65536 different queues. The above solution won’t scale for numbers like this.

I could just settle for supporting a few queues so the marking would still work. However, this conflicts with my design goals for Vuurmuur. It is the goal to put as little artificial limitations in the usage of Vuurmuur as possible. A second goal is that Vuurmuur should be able to run on standard distribution kernels. So I’m not interested in adding obscure features that require patching of the kernel and the iptables userland tools. For this purpose, I consider Debian Stable to be the standard.

For the NFQUEUE support I decided to repeat the mark trick using the newer connmark target and match. The advantage of connmark is that you only have to set it once for a connection, as opposed to for every packet with mark. Additionally connmark works separately from mark, so marking the traffic for other purposes still works. Because connmark wasn’t supported by many distributions at the time the QUEUE support was added, I didn’t use it before. At this time only the NFQUEUE support uses connmark, so if your system doesn’t support it nothing will change.

The Vuurmuur NFQUEUE support is now available in the Vuurmuur SVN repository.

Differences between Snort and Snort_inline

Posted on by

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.

Convenience

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!

Vuurmuur SVN now open

Posted on by

For version control for Vuurmuur development I have been using Bazaar and Bazaar-NG. I’ve never really gotten used to Bazaar-NG. I admit that this is mostly due to lack of trying. For the Snort_inline project I have gotten used to Subversion, for which I even bought a book (Practical Subversion by Garrett Rooney, great book!). So recently I decided to move Vuurmuur also to SVN, for these three reasons:

  • this way I need to work with only one tool
  • people in the OSS community are more used to SVN so it’s easier for users and people interested in contributing
  • Bazaar-NG doesn’t support SVN-style tags, except (I think) for the latest version which is not in my distro

So the SVN repository is now open. It is hosted at SourceForge at:

https://vuurmuur.svn.sourceforge.net/svnroot/vuurmuur

I’m working on an update to the install script to be able to update your installation to the latest SVN version automatically. Checking out the latest code can be done with the command:

svn co https://vuurmuur.svn.sourceforge.net/svnroot/vuurmuur/trunk

Check it out! 🙂