Snort_inline

The last week I’ve been working on bringing Snort_inline to the Snort 2.8.0.1 level, including it’s IPv6 support. I’m almost ready to commit it to SVN, there are just some issues I need to fix in the inline specific code. The code will get rid of libdnet and use libnet 1.1 for sending reset/reject packets for both IPv4 and IPv6. After committing I will start working on getting the IPv6 features I wrote for NitroSecurity into this tree. This includes more matches, tunnel decoding (including for example the freenet6 tunnel, etc). So stay tuned! ...

A while ago I wrote about why the TCP window scaling normalization in Snort_inline was broken by design. I also wrote about a new solution I was working on and testing that would be uploaded to SVN soon. I just committed the patch to SVN. What it does is add two new options to stream4: norm_window: normalize the TCP window (disabled by default). This is to protect Snort_inline from being forced to queue too many packets. max_win_size: maximum size of the scaled TCP window. Packets increasing the window beyond the limit are modified. ...

Matt Jonkman is stepping out of the Bleeding Edge project. He announced this here. Apparently Sensory Networks, one of the sponsors of the project, now owns it. It will be interesting to see if they will continue it, and if so, how. Honestly, I’m a bit skeptical, since to my knowledge not many Sensory people are directly involved at this moment. Still I believe Sensory consists of good people. I did a contract job for them about a year ago, and enjoyed working with them. ...

One of the cool things of the Snort_inline project is the support for NFQUEUE. NFQUEUE is the new queuing mechanism to push packets from the kernel to userspace so a userspace program can issue a verdict on it. What makes NFQUEUE cooler than it’s predecessor ip_queue is that it supports multiple queue’s. This means that there can be more than one Snort_inline process inspecting and judging traffic. The challenge is to make sure that each Snort_inline instance sees all traffic belonging to a certain connection so Snort_inline can do stateful inspection on it. Luckily, Vuurmuur makes it very easy. ...

Libnet is a cool packet crafting tool, used by Snort to send TCP reset packets and ICMP unreachable packets as part of active responses. Libnet 1.1 supports IPv6 which is what I needed for my work. After some reading and testing there were a few problems. First, while possible to send TCP reset packets, the packets didn’t have a correct checksum and debugging this with valgrind showed lots of memory errors. Second, ICMPv6 was only partly implemented. The libnet_build_* functions for it are missing. This is, by the way, quite a common picture. Many libraries and projects have some support for IPv6, but generally incomplete and less well tested. ...

After debugging some connection problems I found that the wscale normalization concept is flawed. I’ll describe here what is wrong with it and then move on to suggest a different solution I’m currently testing. The problem I was seeing is that some connections to some webservers stalled without an apparent reason. First a quick reminder of why I originally came up with the wscale normalization. Stream4 originally doesn’t look at the window scaling value when determining the TCP window. This causes it to be wrong about the TCP window in about every connection, which is one of the reasons out of window packets are not dropped (this is actually a gaping evasion hole since these packets are not used in stream reassembly). This is why I decided to add window scaling support to the stream4inline extension. This works great and allows the admin to drop out of window packets. There is a problem associated with it though. The maximal window that is possible with wscaling is 1GB. This would mean that Snort_inline would in the worst case have to queue almost 1GB of data in it’s buffers for a single stream. To prevent this being used by an attacker to attack Snort_inline, I wanted give the admin the option to set a maximal wscale size. ...

In Snort_inline’s stream4 modifications, one of the changes is that out of order TCP packets are treated differently from unmodified stream4. This can cause some new alerts to appear and some unexpected behaviour. So I’ll try to explain what happens here. First of all let me explain quickly what out of order packets are. To put it simple, TCP packets are send out by the source host in a specific order but can arrive in a different order at the destination. Packetloss, link saturation, routing issues are among many things that can cause this. A Snort_inline specific issue is that when Snort_inline can’t keep up with the packets it needs to process, it will drop packets which causes packetloss. These packets will then have to be resent by the sending host. ...

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

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

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