pfSense is a clone of m0n0wall and, to the best of my knowledge, the eldest open source IPv6 firewall which is still maintained by its developers. Therefore, it should be expected that its maturity level should be good enough for normal usage.

 

The latest pfSense version currently available is 2.3.3, based on FreeBSD 10.3-RELEASE-p16.

pfSense provides the same capabilities with OPNsense regarding the IPv6 configuration of its interfaces, the deployment of DHCPv6 server, the sending of Router Advertisements and their configuration, etc. So, the only difference from an IPv6 configuration perspective between pfSense and OPNsense is the capability of filtering IPv6 Extension headers, which, nevertheless, does not seem to really work.

As the Cisco Labs measurements show, IPv6 is a protocol that cannot be ignored any more. In some countries, like Belgium, Greece, Germany, the US, etc. the percentage of the users employing IPv6 is about 30% or even to 50%, and, based on the estimations, the increase of IPv6 traffic will continue to grow exponentially. So, it’s time to ensure that our firewall supports IPv6 as well.

 

While there are several open-source based solutions regarding firewalls, Linux-based or FreeBSD-based ones, this is not also the case when we want IPv6 support as well. Since m0n0wall project has officially ended, the only two options actually left for open-source users seeking for an iPv6 firewall are OPNsense and pfSense (if someone has an additional suggestion, please let me know).

 

Whilst pfSense supports IPv6 for quite a long time, as a firewall from a security perspective has a significant disadvantage: As of version 2.3.3 Community Edition it does not allow the filtering of IPv6 datagrams based on the used IPv6 Extension Headers. Therefore, if its administrator wants to filter e.g. IPv6 traffic carrying a Hop-by-Hop header, a Destination Options header, etc. (see [RFC 2460] for more details on IPv6 Extension headers), he simply cannot do it. And I do consider the capability of filtering IPv6 Extension headers really important for the reasons demonstrated here and here. In my opinion, this capability should be configurable.Therefore, I decided to give OPNsense a try since it seems to be the only open-source solutions that currently offers IPv6 Extension headers filtering capabilities.

 

IP fragmentation is the source of many security issues, even from the IPv4 era; the case could not be different in IPv6 (see for example here and here). Of course, IPv6 Extension Headers can make the situation much worse. Hence, it seems that we have quite a few good reasons to block fragmentation at our firewalls, either at our network perimeter or even at host firewalls.

While writing an IPv6 Hardening Guide for Linux Servers, I found that the usual ip6tables rules to block fragmentation did not work in latest Red-Hat Enterprise OS and clones (e.g. Centos). Specifically, I found out that at Red Hat Enterprise version 6.6 (also affects version 7), while applying ip6tables to block incoming IPv6 fragments, IPv6 fragments are not blocked, as it should be the case, either for atomic or non-atomic ones. You can easily confirm it by:

a. Issuing the command: ip6tables -I INPUT 1 -i eth1 -m ipv6header --header frag --soft -j DROP

b. Sending ICMPv6 Echo Requests with size bigger than the MTU size, e.g.: ping6 -s 4000 <IPv6 address of the target machine>.

Note: This issue affects only the blocking of IPv6 Fragment header, not the rest of the IPv6 Extension headers.

Similar results (no blocking of IPv6 fragments) are obtained for the following commands:

ip6tables -I INPUT 1 -m frag --fragfirst -j DROP #(it should drop the first fragment)

ip6tables -I INPUT 1 -m frag --fraglast -j DROP #(it should drop the last fragment)

ip6tables -I INPUT 1 -m frag --fragmore -j DROP #(it should drop all but the last fragment)

I immediately reported it as a bug at Red Hat Bugzilla (Bug 1170144), assuming that this would be a kind of a bug that it would be fixed easily and quickly. However, the developers that responded mentioned that actually this was a consequence of a deliberate change of fragmentation handling in these systems. Specifically, they mentioned that this was probably because after bug id 1011214 (kernel-2.6.32-437.el6) netfilter started processing the reassembled packet instead of the fragments, like IPv4 does. For Red Hat 6.5 this was fixed on kernel-2.6.32-431.5.1.el6 and thus, any kernel before that would work differently. Now netfilter works like it works for IPv4. That is, the only way to see such fragments again through netfilter chains is by unloading nf_defrag_ipv6 module. They also mentioned that the change of behavior is because now only the final, reassembled, packet is pushed through netfilter chains - and not the fragments.

There is also a positive effect though. Due to this change, atomic fragments are not forward anymore, meaning that they will get reassembled and forwarded as a “clean” (without IPv6 Fragment header) packet, which is obviously good, at least from a security perspective.

However, this is not true for genuine fragments, since they will get re-fragmented on output in case you're forwarding them.

By unloading that module, you can still receive such packets locally but you're not able to use conntrack on that system.

After confirming that this was the case, it was obvious that a workaround should be found. A first few comments though.

First, the fact that "...genuine fragments, they will get re-fragmented on output, in case you're forwarding" seems to somewhat break one of the basic IPv6 principles (RFC 2460, section 4.5) which defines that: "unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path". But this is not the most important consequence, although it introduces a delay (due to reassembly-refragmentation process).

As a security engineer I would like to have the ability to block fragments if I wanted to. Fragmentation in IPv6 when combined with Extension headers can have some really bad security consequences, as discussed briefly at the beginning of this article; so, I would like to be able to block them, if, for instance, this is the policy of my organisation, company, etc.

Now, if we use the aforementioned workaround (unloading the suggested kernel module), we will lose the capability of connection tracking, which is not good either (if not worse).

After a (short) discussion and a kinf of brainstorming, Florian Westphal from Red Hat suggested that IPv6 fragmented traffic could be filtered using nftables, because with them you can define arbitrary tables and priorities; so, its easy to hook packets before they hit defrag. However, at the time of this writing, March of 2015, nftables were not supported even on RHEL 7.1. Anyway, Marcelo Ricardo Leitner suggested a rule to block IPv6 fragments using nftables which would look like as follows:

table ip6 filter {

   chain preroute500 {

      type filter hook prerouting priority -500; policy accept;

      ip6 nexthdr ipv6-frag counter packets 2 bytes 2104

   }

}

As Marcelo explained, the line "ip6 nexthdr ipv6-frag counter" will match whenever an IPv6 packet is seen with a nexthdr field being set to ipv6-frag, which is only used for fragments (even atomic ones); other traffic will pass this check. Of course, for dropping, you have to add a 'drop' in this rule.

Is the aforementioned approach effective on blocking IPv6 fragments? Frankly, I have not tested it yet, but certainly, taking into account the latest kernel changes it seems to be the only way to do go. Hopefully, I will have the chance to test it soon, so, stay tuned :)

Given the fresh release of the latest pfSense, version 2.2.1 (which is based on FreeBSD 10.1-RELEASE-p6) and the recently announced end of the m0n0wall project, I decided to give pfSense a try since it seems that this is the only remaining open-source firewall solution that supports IPv6 out-of-the-box (I am not aware of any Linux alternative, if there is one, please let me know). My question was twofold. First, can the firewall administrator configure which IPv6 Extension headers should be allowed or not at the perimeter and secondly, what is the default behaviour of pfSense regarding the acceptance or not of IPv6 Extension headers?

 

The answer to the first question was rather easy, but disappointing. You can only configure the acceptance/dropping of  IPSec-related Extension headers, namely ESP and AH, probably because these are the ones known from the IPv4 era. Regarding the rest ones (Hop-by-Hop, Destinatioon Options, Routing header, or even fragmentation) there are no similar capabilities. This was not the case regarding m0n0wall where their configuration was possible (and this was one of the reasons why I used to prefer m0n0wall instead of pfSense).

 

OK, since we are not able of configuring them, what is the default behaviour of pfSense?  Are we ...protected from the "evil" IPv6 Extension headers? The tested configuration is really simple and it is displayed below:

 

 Attacker --------->  pfSense (running www server) ----------> target (running ssh).

       

As we can see, there is a pfSense firewall in the middle, running a web server available in the WAN interface too (this is not / should not be normally the case, but it was enabled just for my testing purposes), as well as a target "behind" the pfSense firewall running ssh.

Attacker and target reside on different network prefixes.

pfSense is configured to allow ssh traffic to the target and http traffic to the firewall itself over IPv6. All the other traffic, by default is blocked at the WAN interface.

For the tests, Chiron was used.

 

First, it was examined using which IPv6 Extension headers can be used to reach the otherwise allowed to port 80 tcp traffic. In this case, the WAN interface of pfSense itself is the target. The results are summarised below:

 

Extension Header                       Allowed

----------------                       ------

Hop-by-Hop header                     YES

Destination Options Header           YES

Fragmentation                            YES

Atomic Fragments                        NO

Type-0 Routing Header                 NO

Type 1, 2,3 Routing Header           NO

Layer 4 header in 2^nd fragment      NO

(RFC 7112 implementation)

 

 

 

Not that bad. What I liked is that a) Type-0 Routing header (which is deprecated) is dropped, b) Atomic fragments (which may be deprecated in the near future) are also drooped and more importantly, c) RFC 7112 is actually implemented (actually, given the FreeBSD inheritance of pfSense, this was actually the case even before RFC 7112 was published).

 

But, what is the case when we try to reach a target behind the firewall itself (reminder: in the tested scenario ssh traffic to the target is allowed)?  The results are summarised below:

 

Extension Header                       Allowed

----------------                       ------

Hop-by-Hop header                     YES

Destination Options Header           YES

Fragmentation                            NO

Atomic Fragments                        NO

Type-0 Routing Header                 NO

Type 1, 2,3 Routing Header           NO

Layer 4 header in 2^nd fragment      NO

(RFC 7112 implementation)

 

As we can see, the situation is even more strict now; fragmentation is also not allowed, which is certainly a good thing from a security perspective (the question is, if for any reason fragmentation over IPv6 is required, what can be the operational implications)?

 

To sum up, pfSense, in its latest release 2.2.1 a) does not offer any capabilities to customise IPv6 rules using IPv6 Extension headers (with the exception of IPSec ones) and, b) due to the FreeBSD inheritance, by default only very basic IPv6 Extension headers functionality is allowed, which does not include fragmentation.

 

What about if we want to customise our IPv6 rules regarding Extension headers? Well, it seems that for the time being, CLI and pfctl is the only option.

 

Have a nice day :) 

 

During the RISC project, a collaborative project with ERNW.de, we had the change to test several IPv6-capable Security and Netwowrking Devices. Specifically, we had the chance to test the following devices:

 

● Firewalls:
    –  Cisco ASA 5505 running firmware 9.1(4)
    –  Checkpoint Gaia Release 77.10 running on commodity hardware
    –  Juniper SRX 100H2 running JunOS 12.1X46-DH.2
    –  Fortinet Fortigate 200B running v5.0,build0252 (GA Patch 5)
●  IPS
    –  Tipping Point, TOS Package 3.6.1.4036 and digital vaccine 3.2.0.8530.
●  Layer-2 switch
    –  Cisco Catalyst 4948E running Cisco IOS Release 15.2(1)E1.

We performed several tests and the results quite interesting security-wise. Both the IPS and the Cisco Switch could be evaded (although the last case was already known). Especially as far as the IPS is concerned, we could make it completely "blind" and to fly under it's radars no matter what kind of attack we launched. The other devices appeared to have some minor issues too.

We also checked the aforementioned devices regarding their RFC-compliance, as well as how IPv6-Ready really other. Are they going to face any operational issues when deployed?

The full presentation with all the results, as presented during the IPv6 Security Summit @ Troopers 14, can be downloaded from here.