Inliniac

My ISP is one of the few here in the Netherlands that provides a IPv6 tunnel broker. I have played with it some during the last year or so, but now decided to get a little more serious with it. So I’ve decided to enable it for my blog. When opening up my site to IPv6 one thing that is important is security. I will describe the status of IPv6 support of my current setup:

Linux firewalling: IPtables supports IPv6 for quite some time, however it only very recently gained stateful packet filtering support. This hasn’t made it into Debian Sarge or even backports yet, so I’m just using stateless filtering now.

Vuurmuur: my own IPtables frontend has no support for IPv6 at all. I’ve been thinking about adding it for years, but decided to wait at least until stateful support would be available. Next to this my coding time is limited, and many other features are probably more interesting to Vuurmuur users.

Snort/Snort_inline: both Snort and Snort_inline lack support for IPv6. Sourcefire is working on it as far as I know, but no code is available from them. I did find a IPv6 patch for Snort 2.3.3, which can be found here. I ran it in sniffer mode and that works. I haven’t played with it much other than that, but I certainly will in the future.

ModSecurity: my Apache 2 installation has IPv6 enabled by default and ModSecurity 2.x just worked with it without any configuration change! I haven’t looked into how to create rules specific for IPv6 addresses however, so maybe surprises will come up here. I do know from looking at the source that the rbl functionality doesn’t support IPv6 addresses yet, but I haven’t even checked if realtime blacklists exist for IPv6.

Sguil/Modsec2sguil: my modsec2sguil script, that takes ModSecurity alerts and feeds them to Sguil, doesn’t act on the IPv6 alerts because it expects IPv4 addresses. This is not a problem however, since Sguil doesn’t support IPv6 addresses. This makes sense since Snort doesn’t support it either.

So compared to my IPv4 access, protection is somewhat limited. I’m only enabling HTTP for now, so ModSecurity should be able to handle that just fine.

Anyway, it seems to be working fine now, but consider the IPv6 support experimental, as I’m playing with how it all works. So don’t be surpised if it’s broken all of a sudden

This is my first blog post in 2007, so let me start by wishing everyone a good and healthy new year. In the new year I finally released a new version of Vuurmuur. It was the longest period between two releases, the last one was in April 06. The last year has been pretty hectic, with my graduation, looking for work, and now working… Also I’ve been stepping up work on Snort_inline and Modsec2sguil, which all took away coding time from Vuurmuur.

Of course, just after the new release came out, I discovered some problems with the connection killing functionality, and a new alpha release partly fixing that is already out. Partly, since I have yet some fixes to make. The release got a fair amount of publicity since it was mentioned on the Dutch computer enthousiast site tweakers.net. The server that hosts the wiki (and the screenshots) nearly colapsed under the requests, but luckily I could adapts it’s config in time to bring the load down from 18 to 2.

Looking ahead, I intent to get a new release out fairly quickly, hopefully even this month. The focus of this release will be fixing the bugs from 0.5.72. Looking further ahead main focus will be the setup wizard, that should help new users to get going quickly. Adi is working on an updated autobuild server that can also support the newer versions of Debian and Ubuntu. He will also be looking at adding support for rpm-building.

I’m also thinking about modifying the iptables rules that Vuurmuur creates, to better handle traffic marking, add support for the classify target and support nfqueue. But it will be a while before work on that will start…

In Vuurmuur 0.5.72 alpha 1, I introduced a connection management interface to the connection viewer, allowing the administrator to kill connections and add ipaddresses to the blocklist. Next, I’m working on doing about the same for the logviewer. The idea is to have a menu with options for each individual logline. I can think of a large number of interesting options, but I think the best would be an option like ‘create a rule based on this logline’. This would then open a prefilled rule window based on the values in the log. This option would make it very easy to get going with a new Vuurmuur setup.

Other options I can think of are:

1. create a host based on the logline
2. create a service
3. append a portrange to a service
4. add a host to a group
5. change new connection limit

For now I will first focus on getting the same options as with the connection viewer. When that is done I will probably release it as 0.5.72 alpha 3. For alpha 4 I will extend the number of options.

I would be very interested in hearing more ideas for the connection and log options. If you are missing something in the list above, please add a comment!

The main new feature of the 0.5.72 release of Vuurmuur will be the ability to kill existing connections from vuurmuur_conf. It will use the conntrack tool for this. Below is a screenshot of how it works.

Currently it works only for TCP connections and UDP pseudo connections. From the connection manager IPAdresses can also be added to the blocklist. All existing connections for this IP will be killed on that action. I have yet to extend this to hosts blocked manually.

Quite a while ago a placed a poll on the Vuurmuur Wiki, asking for the most important feature Vuurmuur needs. It turns out most people want traffic shaping. Traffic shaping has been on my todo list for a long time, but i never really got into using it, let alone understand it enough to integrate it into a GUI. So the last couple of days i had some spare time, and i have been checking it out. So far i am distinguishing the following types of traffic shaping.

First there is simple priorization: my VoIP/Gaming traffic should have priority over people up- and downloading ISO images. This is quite simple, and could be done using setting the ToS and creating some rules for that. In Vuurmuur, setting ToS could for example be done in a service.

Second, there is some more advanced priorization, with soft limits. This could for example be used in a situation where you say VoIP/Gaming should have a guaranteed bandwith of 20kb/s, but if on VoIP is active or not using the full 20kb/s, other traffic is allowed to use the 20kb/s in addition to the other bandwidth. Most important here is to keep interactive traffic responsive.

Third, the hard limits. For example saying that p2p should never be able to use more than 40kb/s, no matter how many bandwidth you have available. This could also be useful for assigning speed limits to specific hosts, for example in hosting companies.

Fourth and last, there is some misc stuff for which shaping can be useful, like limiting the rate of SYN packets, giving smaller packets priority over larger, etc.

Okay, on to my baby steps:

DEV=ppp0
$TC qdisc add dev $DEV root handle 1: htb default 30

This creates a htb root qdisc, which defaults to class 1:30.

MAX_PPP_UP=512kbit
$TC class add dev $DEV parent 1: classid 1:1 htb rate $MAX_PPP_UP

Here we create the class, where we define the max speed of this class to be MAX_PPP_UP.

MAX_PPP_UP_BULK=350kbit
$TC class add dev $DEV parent 1:1 classid 1:10 htb rate 100kbit ceil $MAX_PPP_UP burst 4k prio 1
$TC class add dev $DEV parent 1:1 classid 1:20 htb rate $MAX_PPP_UP_BULK burst 0k prio 2
$TC class add dev $DEV parent 1:1 classid 1:30 htb rate 200kbit burst 1k prio 3
$TC class add dev $DEV parent 1:1 classid 1:40 htb rate 100kbit burst 0k prio 4

Here we define the actual limits. The first rule gets 100kbit guaranteed, but as a ceiling of the maximum speed. It has the highest priority. The second class is for bulk uploading, and it is set to about 70% of the maximum upload speed. With this set, i can upload at about 40kb/s, and still have a ping of around 80-100ms, while setting this higher will cause it to go into the 200+ms levels very quickly. I’ve also disabled burst for this class, because i don’t want ping spikes. The other two have hard limits, and can be used to really rate limit some traffic.

Like stated above, unclassified traffic gets into the default class 1:30. To have some traffic go into another class, i’m using the iptables CLASSIFY target:

# icmp gets high prio
$IPTABLES -t mangle -A FORWARD -i eth0 -o ppp0 -p icmp -j CLASSIFY –set-class 1:10

# http data from dmz to wan is bulk
$IPTABLES -t mangle -A FORWARD -i eth1 -o ppp0 -p tcp –sport 80 -j CLASSIFY –set-class 1:20

I like the CLASSIFY iptables target over the tc filter rules because it enables me to use the netfilter connection tracking helpers. This way i could for example say:

$IPTABLES -t mangle -A FORWARD -i eth0 -o ppp0 -m helper –helper sip -j CLASSIFY –set-class 1:10

So this way all traffic related to the SIP VoIP connection (the RTP stream) gets into the highest priority class.

This is all egress shaping, the only shaping that works well, or so everyone says. Ingress shaping is not as easy, for a number of reasons. First, we have no real control over the rate of traffic being sent to us. Second, linux shaping is not as advanced for ingress shaping as it is for egress shaping. IMQ and later IFB have been invented to deal with this, but i have never looked at it yet.

However, in a gateway setup, egress shaping can do all we need. Traffic that comes in on my ppp0 interface, gets out on my eth1 interface. At this eth1 interface we can do egress shaping for incoming traffic coming in on ppp0.

This about sums up my first attempt at understanding and using traffic shaping. So far i think it works very well. The next big question will be how this can be integrated into Vuurmuur. If i get some ideas about this, i’ll post them here.

Oh yeah, if anyone is interested in participating in this process, i have setup a page on the wiki to help determine what we want and how we want to do it: here. Feel free to add to it, edit, etc.

Last week a user of Vuurmuur let me know he had another security audit at his work, and Vuurmuur passed without any remarks whatsoever. The auditors even said that this was quite unusual.

The user is working in a Dutch company involved in stocktrading, and are forced to have the same level of security as their parent company, which is a bank. After the last time they had an audit, i added the auditlog feature to Vuurmuur, and it seems that has pleased them because unlike last time, they didn’t even complain about Vuurmuur’s beta status

Now, i don’t know any specifics about the audit, so take it for what it’s worth. I still think it is cool to see Vuurmuur pass the security checks of financial institutions though!