Category Archives: IPv6

Vuurmuur 0.8rc1 released

Posted on by

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

Additionally, amd64 packages for Debian and Ubuntu are now available. See Installation Debian for instructions.

IPv6 Evasions, Scanners and the importance of staying current

Posted on by

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.

Vuurmuur 0.8beta4 released

Posted on by

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

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!

Suricata 1.3 released

Posted on by

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(-)

These changes have been made by 11 committers, only four of which were paid by OISF. The others were either developers from supporting vendors or great community members. I’d like to thank everyone for their contribution!

With the 1.3 release, for some people work only just started. I think this would be an ideal time for the Emerging Threats project to fork their Suricata ruleset. The new set for 1.3 could then start taking advantage of features like http_user_agent, file_data, file keywords, tls/ssl keywords, etc. One of the new features in 1.3, the rule analyzer, should be really helpful for the rule writer folks.

Looking towards the future, we’re planning for some nice new features and improvement. First, the TLS/SSL handling will be further improved. The guys are working on certificate fingerprint matching, storing certs to disk and more. We’ll also continue to improve our IPv6 support. Of course, performance work is always on our agenda, so also for the time to come. See our roadmap here.

Finally, if you’re interested discussing the roadmap with us in person, the RAID 2012 conference in Amsterdam next fall is a good opportunity. Most of the team will be present.

Vuurmuur IPv6

Posted on by

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!

Vuurmuur development

Posted on by

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!

Available for contract work

Posted on by

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…

Checkout my LinkedIn profile for more info. My resume is available on request.

If you have some work or know someone that does, please let me know!

Tunnel unwrapping for Snort_inline 2.8.0.1

Posted on by

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:

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

Then have a look at doc/README.IP6TUNNEL for configuration options.

Once again thanks to the great people of Nitro Security. I think it’s great to see this company giving back to the community!

Snort_inline updated to 2.8.0.1 in SVN

Posted on by

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:

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

Consider the code to be of beta quality for now, so be careful with it. Please report any problems with it!

Again, a big thank you to NitroSecurity for funding this work!

New Snortsam patch for Snort 2.8.0.1

Posted on by

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

Here are the instructions for getting your Snort 2.8.0.1 source patched:

Make sure you have a clean Snort 2.8.0.1 tree, then patch it:

cd snort-2.8.0.1
patch -p1 < ../snortsam-2.8.0.1.diff

Next, run ‘autojunk.sh’ to update the build system (you need to have libtoolize, aclocal, autoheader, autoconf and automake installed). After this, configure and build Snort normally:

./configure <your configure options>
make
make install

Thats it.

Thanks to Matt Jonkman of Emerging Threats for paying me to do this and CunningPike for doing the first iterations of the patch!