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!

Normally an ‘accept’ rule in Vuurmuur looks like this:

accept service http from local.lan to world.inet options log

The NFQUEUE equivalent of this rule is:

nfqueue service http from local.lan to world.inet options log,nfqueuenum=”1″

To have ftp handled by another Snort_inline instance, just add a new rule:

nfqueue service ftp from local.lan to world.inet options log,nfqueuenum=”2″

Easy, no? Vuurmuur creates the iptables rules that are required. It uses some advanced connmark-fu for it, so the right Snort_inline process receives all packets from a connection. It uses the helper match to make sure related connections are handled by the right queue, such as the ftp data channel. Of course you also need Snort_inline to be ready for it. See this post for more info on that.

The Snort_inline configuration part takes some work. You have to setup your init scripts to start all instances, setup different configs, logging to different locations. You will need multiple Barnyard’s and if using Sguil multiple snort_agent.tcl instances. When updating the rules you need to take care of the multiple processes as well. As said, it takes some work, but it’s rewarding. You can for example setup an extra Snort_inline instance for testing purposes only. Send all traffic from a certain IP to it to try out new rules, config changes, etc. I have set it up to have separate processes monitor my dmz and my lan.

What is possible as well, but not with Vuurmuur so far, is to have a form of poor man’s load balancing by sending new connections to one of multiple processes. This could be done by making use of the ‘ipt_statistics’ iptables module (fmr ipt_random). This allows a rule to be activated only some percent of the time. By using some more connmark-fu it’s possible to have multiple Snort_inline instances to handle different connections of the same type of traffic. I’ll add support for that to a future Vuurmuur release.