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!
Tag Archives: Vuurmuur
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.
GUI part of Vuurmuur traffic shaping done
Vuurmuur gets traffic 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.
2. Guaranteeing bandwidth to rules.
Again per rule a guaranteed minimum of available bandwidth can be configured. This way you can for example make sure your VoIP calls get enough. It’s important to not over commit the bandwidth. If you do that Vuurmuur will issue a warning but will still work because HTB, the used scheduler, accepts it as well. In this case the minimal bandwidth can not be guaranteed. To use this option add the in_min and out_min options. The syntax is the same as with in_max/out_max.
3. Prioritizing rules.
Like the first two options the priority can be set per rule. It’s a number where 1 is the highest prio. The default prio is 3. The syntax is prio=1. The lowest prio possible is 255.
For each interface, Vuurmuur needs to know the maximal bandwidth. Also, the shaping can be enabled and disabled on a per interface basis. Because shaping is attached to interfaces, rules using source and/or destination ‘any’ or ‘firewall(any)’ won’t be able to shape. Also, only outgoing shaping is supported, which is no problem in a gateway setup because then all traffic is outgoing on one of the interfaces, but on traffic from and to the firewall, this can be a limitation.
For example, to set the bandwidth in the interface ‘inet-nic’ which has a bandwidth of 3072kbit/512kbit, use the following vuurmuur_script commands:
vuurmuur_script -M -i inet-nic -V SHAPE -S Yes
vuurmuur_script -M -i inet-nic -V BW_IN -S 3
vuurmuur_script -M -i inet-nic -V BW_IN_UNIT -S mbit
vuurmuur_script -M -i inet-nic -V BW_OUT -S 512
vuurmuur_script -M -i inet-nic -V BW_OUT_UNIT -S kbit
Using vuurmuur_conf, it’s already possible to set the location of the tc binary. Look at ‘Vuurmuur Config -> General’.
An example of what a full rule using shaping can look like:
accept service ftp from local.lan to world.inet options prio=2, in_max=200kbps, out_max=15kbps
This example limits HTTP downloading to a speed of 200kb/s and uploading to 15kb/s.
The coming days and weeks I’ll finish the GUI support and release a test version.
Interview about Vuurmuur on security.nl
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!
Vuurmuur developments
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.
Third, I have been busy setting up a new site for Vuurmuur. It is based on the Trac software and replaces both the static site at sourceforge.net and the tikiwiki based wiki. The new site can be found at http://www.vuurmuur.org/
Last but not least, and the reason for this post, is that today I’ve released a new version of Vuurmuur. The version, 0.5.73, is the first non-test release since January. This has taken a lot longer than I wanted, but work and other projects and of course ‘real life’ have taken much of the time from Vuurmuur. I don’t think this will change any time soon, unless someone will join the project to contribute some serious amount of coding time, or someone wants to fund me to do so.
On the roadmap (which is a nice feature of Trac btw) one can see the future directions of Vuurmuur. Ideas and comments are welcome. So are bug reports of course 🙂
Vuurmuur NFQUEUE support
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.
Inliniac 
You must be logged in to post a comment.