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 2nd 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 2nd 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 :)
Write a comment