Ipv6 on Inliniac

Vuurmuur 0.8rc1 released

Fri, 25 Jan 2013 16:45:34 +0000

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.
Services now support possible protocols. #63
Add support for rpfilter match. #137

Get this release from the ftp server: ftp://ftp.vuurmuur.org/releases/0.8rc1/Vuurmuur-0.8rc1.tar.gz

IPv6 Evasions, Scanners and the importance of staying current

Tue, 11 Dec 2012 16:13:49 +0000

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.

Vuurmuur 0.8beta4 released

Fri, 31 Aug 2012 13:20:08 +0000

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 - NAT - blocklist - IPv6 address to Vuurmuur name conversion in the log

Suricata 1.3 released

Fri, 06 Jul 2012 16:06:52 +0000

Today, almost half a year after the last “stable” release, we released Suricata 1.3. I think this release is a big step forward with regard to maturity of Suricata. Performance and scalability have been much improved, just like accuracy and stability.

The official announcement can be found on the OISF site

In the last 6 months a lot of code has been changed:

384 files changed, 44332 insertions(+), 18478 deletions(-)

Vuurmuur IPv6

Thu, 31 Mar 2011 21:14:43 +0000

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”.

Vuurmuur development

Sun, 01 Nov 2009 17:46:07 +0000

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!

Available for contract work

Mon, 05 Jan 2009 13:26:06 +0000

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…

Tunnel unwrapping for Snort_inline 2.8.0.1

Fri, 11 Jan 2008 16:24:37 +0000

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:

Snort_inline updated to 2.8.0.1 in SVN

Wed, 09 Jan 2008 15:41:19 +0000

I’ve just committed an update to Snort_inline’s SVN. It brings it to the Snort 2.8.0.1 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:

New Snortsam patch for Snort 2.8.0.1

Tue, 08 Jan 2008 12:30:53 +0000

Matt Jonkman of Emerging Threats asked me to have a look at the existing Snortsam 2.8.0.1 patch as people were continuing to report problems with it. I updated it to compile without compiler warnings, build cleanly with debugging enabled, build cleanly with Snort’s IPv6 support enabled and added a check so it won’t act on alerts in IPv6 packets since the Snortsam framework does not support IPv6. Finally I removed the patch script so it’s provided as a ’normal’ diff. Here is the patch: http://www.inliniac.net/files/snortsam-2.8.0.1.diff

Working on Snort_inline 2.8.0.1

Sat, 22 Dec 2007 12:49:20 +0000

The last week I’ve been working on bringing Snort_inline to the Snort 2.8.0.1 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 1.1 IPv6 fixes and additions

Tue, 16 Oct 2007 21:35:11 +0000

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.

Running IPv6 with Freenet6 when on the road

Tue, 27 Mar 2007 18:25:33 +0000

I wrote about my experiments with IPv6 before. These were done for my home network where I have an ISP that offers an IPv6 tunnel broker. The last two months I have not been in my home, but instead using internet ‘on the road’ mostly through wireless LANs. There are a number of techniques for using IPv6 if your provider doesn’t offer it, and today I stumbled on one in this NetworkWorld article, so I decided to give it a try.

Leaking information by using IPv6

Thu, 15 Mar 2007 19:56:16 +0000

As I wrote before, I’m experimenting with IPv6. I have a tunnel to my ISP from my router. The router is running Linux and uses radvd to advertise my IPv6 prefix to my networks. My dmz, in which this blog is hosted, get the 2001:888:13c5:cafe::/64 prefix. The IPaddresses are then created by taking the MACaddress of a network interface and placing that behind the prefix. It’s a nice and simple autoconfiguration system. So the IPv6 address of the blog is 2001:888:13c5:cafe:20c:29ff:fe13:2b42.

Experimenting with IPv6

Tue, 13 Mar 2007 19:04:51 +0000

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: