I just released a new Vuurmuur version: 0.8rc1. The first release candidate for the 0.8 series. This release improves IPv6 support a lot. The wizard is now also fully functional. Try “vuurmuur_conf –wizard”.
Improved IPv6 support: #115
Improved Debian packages, switching to nflog as default for logging.
Fix connection viewer not showing accounting on newer systems. #141
Amd64 packages for Debian and Ubuntu are now available through the apt server. #83
Switch from “state” match to “conntrack” match for connection tracking.
Lots of activity on the IPv6 front lately. There was a talk on a conference on bypassing IDS using IPv6 tricks. Also a new scan tool (Topera) claimed to scan a host while staying below the radar of an IDS was released. To start with the latter, even though Suricata doesn’t have a dedicated port scan detector, the tool’s traffic lights up like a Christmas tree. The trick it pulls is to pack a lot of duplicate DST OPTS extension headers in the IPv6 packets. These options are just fillers, the only options they use are the “pad” option. In Suricata we’ve had an event for duplicate DST OPTS headers since 1.3 and the padding only headers generate an event in 1.4. Both alerts will be very noisy, so calling this a stealth attack rather dubious.
The other thing was a talk on IPv6 evasions, where the author compared Snort and Suricata. Suricata didn’t do very well. Sadly the authors chose not to contact us. On closer inspection it turned out an old Suricata version was used. Which one wasn’t specified, but as they did mention using Security Onion, I’m assuming 1.2. In the 1.3 branch (current stable) we’ve fixed and improved IPv6 in a lot of areas. Nonetheless, while testing the various protocol tricks, we did find some bugs that are now fixed in the git masters for the 1.3 stable branch and the 1.4 development branch.
I think these developments serve as a reminder that staying current with your IDS software’s version is critical. For that reason it’s too bad that distro’s like Security Onion, Debian, Ubuntu all lag significantly. The reasons differ through. For the guys from Security Onion it’s mostly a time problem (so go help them if you can!) for Debian and Ubuntu it’s actually policy. For that reason we’re providing PPAs for Ubuntu and for Debian we’re working on getting Suricata into the “backports” repo. The only mainstream distro that does it right for us is Fedora. They just update to the latest stable as soon as it’s out.
Given the complexity of protocols like IPv6 and the new developments all over the board, I see no viable case for staying on older versions. I know it’s a hassle, but stay current. It’s important.
I just released a new Vuurmuur version. The last release was in 2009, so it has been a while.
This release adds basic IPv6 support. The state of the IPv6 support is incomplete, but quite functional.
Supported features are:
- rules generation
- log viewing
- setting IPv6 addresses in hosts, networks and interfaces
Unsupported features are:
- connection viewer
- IPv6 address to Vuurmuur name conversion in the log
I’ve been running it myself for a couple of months w/o major issues, so it should be safe to test.
Also new in this release is the support of NFLOG for the traffic log. This means no more cluttering of messages or other system logs. Much of this work has been done by Fred Leeflang.
It’s now also possible to use a “zone” directly in a rule. For Every network in that rule a set of iptables rules will be automatically be created.
Finally, for those that hate the blue background, you can now also set it to black. In vuurmuur_conf, go to “vuurmuur_conf settings” and enable “Use black background”. Restart vuurmuur_conf and you’re set!
The last few years Vuurmuur development has been very slow, not to say pretty much stagnant. This had a couple of reasons. The first is that my attention was drawn to other projects, mostly Suricata these days. The second reason is that Vuurmuur pretty much does all I want. The third reason is that despite some minor contributions, no other developer has stepped up to take over.
Meanwhile, people continued using Vuurmuur, it made it’s way into Debian, got removed from it again, made it’s way into Ubuntu. Lately, every few weeks someone would ask me if Vuurmuur was still being developed. My answer always was “yes, but very slowly”.
I plan to change that. The reason? IPv6. I’ve been using IPv6 on and off over the years, usually through the experimental tunnel service my ISP offered. But a while back my ISP started offering native IPv6 connectivity, which I’m using on a daily basis now. In the feature set Vuurmuur has, IPv6 is the only glaring omission. So, it’s time to address that.
Over the next months my idea is to slowly start adding IPv6 support to Vuurmuur. As I’m already using a simple script the idea is to start with logging support. Then move up from there.
Supporting all current features on IPv6 is going to require a lot of effort. In some cases I’m not even sure we can. But getting at least a basic IPv6 ruleset going should be fairly straightforward. If you’re interested in helping out, please let me know. Any help is greatly appreciated!
Ever since I’ve been working on the OISF engine I’ve been unable to spend much time on my Vuurmuur project. Luckily it seems development is picking up some speed again because there are some (new) people working on some improvements. Two development branches have been started in svn. The first is “nflog” which is meant for the development of support for libnetfilter_log to replace the current syslog based vuurmuur_log.
The second is called “ipv6″ and is meant for adding IPv6 support to Vuurmuur as a frontend to ip6tables. This is going to be quite an effort, but I’m excited that it got started!
Anyone interested in joining the development effort is welcome to do so. Join us at #vuurmuur on freenode.
On a side note, last week I released Vuurmuur 0.8 beta 2, exactly 6 months after beta 1. I’ll try to do the next release a little sooner!
This year there will be a lot of work that needs to be done for the Open Infosec Foundation. And like I wrote a few days ago, a lot of work is already being done. However, most of it is unpaid at this time as it will be some months before our funding comes in. So at least until then I’m available and looking for contract work.
For the last two years I’ve been doing work as a contractor in the (open source) security field. My experience is mostly in coding in C and Perl, primarily on Snort and Snort_inline. Recently I created the (Perl language) SidReporter program for Emerging Threats. Areas I worked in: IPv6 IDS/IPS coding, signature writing, Web Application Firewalls, threading, bandwidth accounting, and more…
Not many people have native IPv6 connectivity and use some form of tunneling. For this reason Nitro Security asked me to develop a Snort preprocessor to unwrap various tunnels. This resulted in the preprocessor ‘ip6tunnel’, which I uploaded to Snort_inline’s SVN yesterday. The preprocessor is capable of unwrapping IPv6-in-IPv4, IPv6-in-IPv6, IPv4-in-IPv6, IPv4-in-IPv4 and finally IPv6-over-UDP. The latter is used by Freenet6.
I chose to develop it as a preprocessor because this allows Snort to inspect both the original packet and the tunnel packet(s). The preprocessor supports recursive unwrapping. The recursion depth is limited to 3 by default, but can be configured differently. Get the preprocessor from Snort_inline’s SVN by checking out the latest trunk:
I’ve just committed an update to Snort_inline’s SVN. It brings it to the Snort 184.108.40.206 level. It supports both IPv4 and IPv6 on IPQ and NFQ. I have not been able to test IPFW on IPv6, so I don’t think that will work currently.
This update removes the libdnet dependency and replaces it with libnet 1.1. To be able to send ICMPv6 unreachable packets you will need the libnet 1.1 patch I wrote a while ago. You can find that here. Get the latest Snort_inline by checking out SVN:
The last week I’ve been working on bringing Snort_inline to the Snort 220.127.116.11 level, including it’s IPv6 support. I’m almost ready to commit it to SVN, there are just some issues I need to fix in the inline specific code. The code will get rid of libdnet and use libnet 1.1 for sending reset/reject packets for both IPv4 and IPv6. After committing I will start working on getting the IPv6 features I wrote for NitroSecurity into this tree. This includes more matches, tunnel decoding (including for example the freenet6 tunnel, etc). So stay tuned!
Libnet is a cool packet crafting tool, used by Snort to send TCP reset packets and ICMP unreachable packets as part of active responses. Libnet 1.1 supports IPv6 which is what I needed for my work. After some reading and testing there were a few problems. First, while possible to send TCP reset packets, the packets didn’t have a correct checksum and debugging this with valgrind showed lots of memory errors. Second, ICMPv6 was only partly implemented. The libnet_build_* functions for it are missing. This is, by the way, quite a common picture. Many libraries and projects have some support for IPv6, but generally incomplete and less well tested.
For my work on a IPv6 enabled Snort_inline I’ve only fixed the checksum issue and added a libnet_build_icmpv6_unreach() function. The patch against libnet 1.1.3-RC-01 can be found here. It’s development was funded by the great people of NitroSecurity Inc., who are funding my work to bring IPv6 to Snort_inline. The work is not based on Sourcefire‘s recent IPv6 implementation, so it will be interesting to see if and how those codebases can be used to improve each other. The changes to Snort_inline will be made available as well later, WhenItsDone(tm) Like with the support for NFQueue, NitroSecurity gives back to the community, which I really appreciate!