Today I’ve spent some time on updating the Snort_inline source to the latest 2.8.2.rc1. The updating went quite smooth, so I hope no big issues pop up. Like before, trying out this code can be done by checking out SVN like this:
svn co https://snort-inline.svn.sourceforge.net/svnroot/snort-inline/trunk
This will save the source to the directory ‘trunk’. In the directory ‘trunk’, run ’sh autojunk.sh’ and then configure, make, make install…
Yesterday the much anticipated Sguil 0.7.0 final was released, as was announced here. I’ve updated Modsec2sguil to support it. Next to this Ryan Cummings sent me a patch for supporting ModSecurity 2.5. So that is included as well. I haven’t given it much testing yet, but works on my boxes.
Get the new release here: http://www.inliniac.net/modsec2sguil/
Thank you Ryan for your contribution!
A while ago I wrote about porting Snort_inline to 2.8.0.1. That worked well, however we are still trying to resolve some issues. Especially in stickydrop, that is just broken right now. Also, SourceFire released 2.8.0.2 last week, so we need to update to that too.
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 
When using Snort_inline with NFQ support, it’s likely that at some point you’ve seen messages like these on the console: packet recv contents failure: No buffer space available. When the messages are appearing Snort_inline slows down significantly. I’ve been trying to find out why.
There are a number of setting that influence NFQ performance. One of them is the NFQ queue maximum length. This is a value in packets. Snort_inline takes an argument to modify the buffer length: –queue-maxlen 5000 (note: there are two dashes before queue-maxlen).
That’s not enough though. The following settings increase the buffer that NFQ seems to use for it’s queue. Since I’ve set it this high, I haven’t been able to get a single read error anymore:
sysctl -w net.core.rmem_default=’8388608′
sysctl -w net.core.wmem_default=’8388608′
The values are in bytes. The following values increase buffers for tcp traffic.
sysctl -w net.ipv4.tcp_wmem=’1048576 4194304 16777216′
sysctl -w net.ipv4.tcp_rmem=’1048576 4194304 16777216′
For more details see this page: http://www-didc.lbl.gov/TCP-tuning/linux.html
Setting these values fixed all my NFQ related slowdowns. The values probably work for ip_queue as well. If you use other values, please put them in a comment below.
Thanks to Dave Remien for helping me track this down!
I just noticed that ModSecurity developer Ivan Ristic has started a new blog on computer security and open source. Check it out here: http://blog.ivanristic.com/
Great idea Ivan! 
Not many people have native IPv6 connectivity and use some form of tunneling. For this reason Nitro Security asked me to develop a Snort preprocessor to unwrap various tunnels. This resulted in the preprocessor ‘ip6tunnel’, which I uploaded to Snort_inline’s SVN yesterday. The preprocessor is capable of unwrapping IPv6-in-IPv4, IPv6-in-IPv6, IPv4-in-IPv6, IPv4-in-IPv4 and finally IPv6-over-UDP. The latter is used by Freenet6.
I chose to develop it as a preprocessor because this allows Snort to inspect both the original packet and the tunnel packet(s). The preprocessor supports recursive unwrapping. The recursion depth is limited to 3 by default, but can be configured differently. Get the preprocessor from Snort_inline’s SVN by checking out the latest trunk:
svn co https://snort-inline.svn.sourceforge.net/svnroot/snort-inline/trunk
Then have a look at doc/README.IP6TUNNEL for configuration options.
Once again thanks to the great people of Nitro Security. I think it’s great to see this company giving back to the community!
I’ve just committed an update to Snort_inline’s SVN. It brings it to the Snort 2.8.0.1 level. It supports both IPv4 and IPv6 on IPQ and NFQ. I have not been able to test IPFW on IPv6, so I don’t think that will work currently.
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!
Matt Jonkman of Emerging Threats asked me to have a look at the existing Snortsam 2.8.0.1 patch as people were continuing to report problems with it. I updated it to compile without compiler warnings, build cleanly with debugging enabled, build cleanly with Snort’s IPv6 support enabled and added a check so it won’t act on alerts in IPv6 packets since the Snortsam framework does not support IPv6. Finally I removed the patch script so it’s provided as a ‘normal’ diff. Here is the patch: http://www.inliniac.net/files/snortsam-2.8.0.1.diff
Here are the instructions for getting your Snort 2.8.0.1 source patched:
Make sure you have a clean Snort 2.8.0.1 tree, then patch it:
cd snort-2.8.0.1
patch -p1 < ../snortsam-2.8.0.1.diff
Next, run ‘autojunk.sh’ to update the build system (you need to have libtoolize, aclocal, autoheader, autoconf and automake installed). After this, configure and build Snort normally:
./configure <your configure options>
make
make install
Thats it.
Thanks to Matt Jonkman of Emerging Threats for paying me to do this and CunningPike for doing the first iterations of the patch!
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.
This option is disabled by default, and the old wscale normalization code is removed, as are the options that configured it. It runs fine on my gateway, without noticeable slowdowns, but I haven’t done any benchmarking so far. Please try this and let me know how it works for you!