The next stable version of Vuurmuur, 0.7, is getting close. Last week I released release candidate 3. If you’re a Vuurmuur user, please try 0.7rc3 and report back to me on how it works! For a list of changes, please see the closed tickets. Thanks!
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!
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 ...
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. ...
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! ...
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. ...
The GUI part of Vuurmuur’s traffic shaping is done. That means it’s in a usable state. It’s probably rough around the edges, but anyone is invited to give it a try. Below two screens. Vuurmuur shape rule settings. The per rule shaping settings. Vuurmuur shape interface settings. The per interface settings for the shaping. ...
The last weeks I’ve been working on adding traffic shaping support to Vuurmuur. The work is largely done, only the GUI part is still missing. But using vuurmuur_script it is already usable in the current SVN trunk. I’ve written before about my shaping ideas here. The support currently focuses on three different options: 1. Limiting bandwidth usage by rules. Per rule a limit can be set for the maximum amount of bandwidth all traffic from this rule uses. Both directions of a connection have different limits. The in_max and out_max options can be added to existing rules for this. The syntax of the in_max and out_max is simple: out_max=15kbps means that traffic in the source to destination direction of a rule can at max use 15 kb/s. ...
The Dutch security site security.nl has interviewed me about the Vuurmuur project. The (Dutch language) article can be found here. Thanks to Joran Polak of security.nl for giving me the opportunity to tell something about this project!
Last weeks I’ve spend many hours on my Vuurmuur Firewall project. First I’ve been improving the code to prepare for a new release. I’ve added NFQUEUE support to Vuurmuur, so I could use it with nfnetlink enabled Snort_inline. Also the connection killing has been improved. The rules limit options were extended, to allow more flexibility. Second, with the great help of Adi Kriegisch, I’ve been working on setting up a new build server for Debian and Ubuntu packages. Credits mostly go to Adi, who did most of the work and hosts the server. So many thanks to Adi! The new build server supports all version of Debian from Sarge up and of Ubuntu from Dapper and up. ...