Tag Archives: nitro security

DC meeting

Posted on by

So I just got back from Washington D.C. where we had our first public meeting for the OISF. I think it went very well as there were more people than expected. The attendees came from all parts from the industry & government. Overall reception was very positive and we’ve gotten many offers for help in development & testing.

Around the public meetings we had private meetings with a number of companies and I’m very happy that three of them commited to the project already:

Endace the New Zealand based hardware acceleration company was first to commit. They are providing us with hardware and time from their coders. Naturally they will be interested in getting our code to perform as good as possible on their hardware, but they have offered to assist in the general development of the engine as well.

Breach Security is supporting us too. They are providing us with coding time of Brian Rectanus, the current developer and maintainer of ModSecurity. Given my enthusiasm about ModSecurity, no one will be surprised that I’m really excited to having Brian and Breach involved. Naturally, they are going to help us make sure our engine excels at HTTP security. More on that in a later post.

Last (for now), we’re getting support from Nitro Security. Having worked with Nitro in the past I’m really excited about this as well, especially as Nitro has an IPS interest. Of course inliniac cares a lot about IPS! 🙂 The form of Nitro’s support is still to be determined, but it’ll likely be in the form of time from their coders.

At this point, contributions like this (coding support, QA hardware) is what we are interested in most. We’re talking to a number of other companies for setting similar partnerships. We’ll announce them as soon as we know more.

On a last note, I’d like to thank Frank Knobbe, Daniel Peck and Richard Bejtlich for attending the meeting. It was great finally meeting you guys in person and thanks for your great input. Same goes for the other people that were there, thanks a lot for coming!

We will be publishing our meeting notes soon. Stay tuned!

Snort_inline load balancing

Posted on by

Dave Remien of NitroSecurity created a patch that “implements a relatively simple form of (IPV4) load balancing” between multiple Snort_inline processes using Nfqueue. Here is what it does:

1. Load balancing. The bottom half of the source and dest addresses are added together, and mod’d with the number of “load-balancing” snorts you desire to run. This means that traffic stays with a particular snort, so that state is maintained.

2. Because you can run many snorts (presumably on many CPUs), you can now take advantage of that super-hooty 16way box and those 10 gig NICs you just got your hands on…

3. The snort at the “magicqueue” is a back-up snort – normally no traffic is sent to it, but in the event that one of the “load-balancing” snorts isn’t present, the traffic for that “load-balancing” snort gets sent to the “backup” snort.

And even more, read that here.

I haven’t tried this myself, but it sure looks cool. Try it by checking out the latest SVN code for Snort_inline. Then follow the instructions from README.NFQUEUE.

Big thanks to Dave Remien & NitroSecurity for this contribution!

Tunnel unwrapping for Snort_inline 2.8.0.1

Posted on by

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!

Snort_inline updated to 2.8.0.1 in SVN

Posted on by

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!

Working on Snort_inline 2.8.0.1

Posted on by

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!

Libnet 1.1 IPv6 fixes and additions

Posted on by

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.

For my work on a IPv6 enabled Snort_inline I’ve only fixed the checksum issue and added a libnet_build_icmpv6_unreach() function. The patch against libnet 1.1.3-RC-01 can be found here. It’s development was funded by the great people of NitroSecurity Inc., who are funding my work to bring IPv6 to Snort_inline. The work is not based on Sourcefire‘s recent IPv6 implementation, so it will be interesting to see if and how those codebases can be used to improve each other. The changes to Snort_inline will be made available as well later, WhenItsDone(tm) 🙂 Like with the support for NFQueue, NitroSecurity gives back to the community, which I really appreciate!

The patch: http://www.inliniac.net/files/libnet-1.1.3-RC-01-ipv6.diff.gz

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!