Tag Archives: connmark

Multiple Snort_inline processes with Vuurmuur

Posted on by

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.

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.

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.