Vuurmuur 0.7 is out

A new version of Vuurmuur is out: 0.7. This release mainly fixes bugs and build issues. Translations are generated and installed again, lots of traffic shaping fixes were made.

Support for pmtu MSS clamping was added, as was support for NAT source port randomization.

See http://www.vuurmuur.org/trac/wiki/Changelog for all changes.

Debs for Debian and Ubuntu are available, see
http://www.vuurmuur.org/trac/wiki/InstallationDebian

The source installer and Autopackage are on the ftp server:
ftp://ftp.vuurmuur.org/releases/0.7/

Looking forward, I’m planning on improving the services handling in 0.8. Especially supporting all protocols from /etc/protocols, instead of just a small list of hardcodes ones. Check http://www.vuurmuur.org/trac/milestone/0.8 to monitor the plans and progress on the 0.8 release. Suggestions & help are welcome!

Update November 3rd: RPMS are available as well: ftp://ftp.vuurmuur.org/releases/0.7/contrib/

Checking out SourceForge’s Marketplace

I’ve registered myself as a seller of services on SourceForge’s Open Source Marketplace. I’ve done so offering software development services for the Snort, Snort_inline and Vuurmuur projects. I was wondering if anyone has any experience (good or bad) with the Marketplace system, either as a buyer or seller of services. Let me know!

Vuurmuur makes it into Debian (Sid)

Thanks to the hard work of Debian’s Daniel Baumann Vuurmuur has been included in Debian unstable/Sid. This hopefully means that Vuurmuur will be getting a lot more users. Eventually it should get into testing and even stable, although the next release “lenny” will come too soon for that. The “lenny” feature freeze was already in place before Vuurmuur got included in Sid. Anyway, for me this is big news!

See here for the packages:
http://packages.debian.org/sid/libvuurmuur0
http://packages.debian.org/sid/vuurmuur
http://packages.debian.org/sid/vuurmuur-conf

Big thanks to Daniel Bauman!

New Vuurmuur version numbering scheme

Today I’ve changed the versioning scheme for Vuurmuur. I was unhappy with the scheme for quite some time already. Versions like 0.5.73 are not making much sense in my view. Originally, my intention was to have a scheme like the linux kernel at the time had. Even versions for stable releases, odd versions for unstable/development releases. The idea was that the 0.5.x development series would some day become a 0.6 stable, after which the 0.7 development series would begin. Of course, that never happened. Instead, I added the alpha releases that became the real development releases and the 0.5.x effectively became the stable releases. So we ended up with releases like 0.5.74 alpha 6. In my opinion quite confusing.

The new scheme is a lot simpler. There will be a two digit version number with optionally a suffix for development releases. The next stable release will be 0.6. In the path to it, there will be 0.6betaX releases and 0.6rcX releases. After the 0.6 release the next will be 0.7 and so on. After 0.9 the next is 1.0, so no more .74 releases 😉

I’ve released 0.6rc1 today, and expect 0.6 stable to be out shortly.

Support for source port randomization in Vuurmuur

One of the workarounds for the current DNS problems is that servers introduce source port randomization.  So it’s time for you to patch your DNS server so it uses random source ports. If for some reason you are unable to do that, iptables can help. Michael Rash has a good write up of how that works here.

In Vuurmuur there is now a per rule option, that can be enabled for the SNAT, MASQ, PORTFW, DNAT and BOUNCE actions, called ‘random’. This passes the ‘–random’ option to the iptables rules Vuurmuur creates. Note that you need a recent distro for this. Debian Etch is too old, Ubuntu Hardy is fine. The new functionality is just released in Vuurmuur 0.5.74 alpha 6. Check it out!

*UPDATE 29/07/08* it turns out iptables/netfilter does not undo existing randomization so removed the text suggesting that.

Multiple Snort_inline processes with Vuurmuur

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.