Tag Archives: svn

Vuurmuur gets traffic shaping

Posted on by

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.

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.

Vuurmuur SVN now open

Posted on by

For version control for Vuurmuur development I have been using Bazaar and Bazaar-NG. I’ve never really gotten used to Bazaar-NG. I admit that this is mostly due to lack of trying. For the Snort_inline project I have gotten used to Subversion, for which I even bought a book (Practical Subversion by Garrett Rooney, great book!). So recently I decided to move Vuurmuur also to SVN, for these three reasons:

  • this way I need to work with only one tool
  • people in the OSS community are more used to SVN so it’s easier for users and people interested in contributing
  • Bazaar-NG doesn’t support SVN-style tags, except (I think) for the latest version which is not in my distro

So the SVN repository is now open. It is hosted at SourceForge at:

https://vuurmuur.svn.sourceforge.net/svnroot/vuurmuur

I’m working on an update to the install script to be able to update your installation to the latest SVN version automatically. Checking out the latest code can be done with the command:

svn co https://vuurmuur.svn.sourceforge.net/svnroot/vuurmuur/trunk

Check it out! 🙂

Snort_inline updated to 2.6.1.4 in SVN

Posted on by

After moving, which went fine, I now finally have some real coding time again. The last week I have been updating and fixing various parts of Snort_inline. The most important change was the update to Snort version 2.6.1.4, which contains security fixes. William also found an issue with the Stream4inline code. The issue was that the memcap that the admin sets to limit the amount of memory used by stream4 wasn’t properly enforced.

Other fixes that are done is that Snort_inline in nfqueue mode now properly honors signals and also no longer needs the libipq library and headers. There are few changes that will be committed soon. One is an issue that clamav can sometimes return an error when parsing malformed file. Until now the spp_clamav preprocessor would issue a FatalError and cause Snort_inline to die. This is obviously not desirable so the patch makes sure that Snort_inline no longer dies and gives the admin an option to either drop or pass traffic that can’t be inspected.

Last but not least there will be a fix to the nfqueue code that appears to solve the ‘stuck packet problem’ we were seeing under heavy load. A number of people are testing my patch currently so if all goes well that will be commited soon as well.

Checking out the latest code is done with the following command:

svn co https://snort-inline.svn.sourceforge.net/svnroot/snort-inline/trunk