New snapshot creates pf rule that ignores default deny ipv6 for LAN
-
A recent commit (fc654f2c36186af8aaf59a1feedce5b343df1252 on July 7) fixed a typo that didn't allow two if statements involving track6-interface in filter.inc to be executed. One statement now correctly generates dhcpv6 rules for the LAN, but another at line 2954 is now executed:
/* add automatic LAN rules to allow IPv6 traffic out for dynamic IPv6 networks */ foreach ($FilterIflist as $ifdescr => $ifcfg) { if (isset($ifcfg['track6-interface'])) { if (is_ipaddrv6($ifcfg['ipv6'])) { $trackifname = $ifcfg['track6-interface']; $trackcfg = $FilterIflist[$trackifname]; $pdlen = 64 - calculate_ipv6_delegation_length($trackifname); $prefix = Net_IPv6::getNetmask($ifcfg['ipv6'], $pdlen); $ipfrules .= "pass in on \${$ifcfg['descr']} inet6 from $prefix/$pdlen to any keep state label \"Allow IPv6 on {$ifcfg['descr']} to any\"\n"; /* add rules on the WAN for traffic back in, let the downstream router * figure out what to do with the traffic */ if (is_ipaddrv6($trackcfg['ipv6'])) $ipfrules .= "pass in on \${$trackcfg['descr']} inet6 from any to $prefix/$pdlen keep state label \"Allow IPv6 in on {$trackcfg['descr']} to $prefix/$pdlen\"\n"; } } }$ipfrules .= "pass in on \${$trackcfg['descr']} inet6 from any to $prefix/$pdlen keep state label \"Allow IPv6 in on {$trackcfg['descr']} to $prefix/$pdlen\"\n"; ```generates a rule that ignores the default 'drop inet6 all' and opens up the LAN to all incoming ipv6 if configured for track interface (such as DHCPv6-PD). Any service listening on :: can be reached if such machine isn't already firewalled off locally. Something like ssh listening on a track IP can be accessed without passing a firewall rule. This code was added a few months back but was never able to be executed until now so I'm not sure if this was overlooked. Also a default config.xml has a default allow LAN IPv6 to any rule, so``` $ipfrules .= "pass in on \${$ifcfg['descr']} inet6 from $prefix/$pdlen to any keep state label \"Allow IPv6 on {$ifcfg['descr']} to any\"\n"; ```seems to add a rule that does the same thing. This was snapshot Mon Jul 8 09:32:55 EDT 2013 -
At the bottom of /tmp/rules.debug:
Automatic Pass rules for any delegated IPv6 prefixes through dynamic IPv6 clients
pass in on $LAN inet6 from x
x0:0:0:0/64 to any keep state label "Allow IPv6 on LAN to any"
pass in on $WAN inet6 from any to xx0:0:0:0/64 keep state label "Allow IPv6 in on WAN to xx0:0:0:0/64"I'm not sure if the last rule is needed or intended. DHCP-PD machines can already connect out and receive replies from the allow LAN IPv6 to any rule, and firewall rules can open specific IPs and ports for servers or services instead of this one opening the entire lan. Is this meant for machines that change IPv6 address every day or so for privacy reasons via RFC 4941? Even though ipv6 address space is huge port scanners can probe machines on the lan with this rule if you knew a machine's ipv6 address.
-
Yeah, I noticed that rule as well. Even if it is indeed intended to accommodate incoming connections to temporary addresses (tho I'm not sure what the point of that would be), I think it would be better to let the user add a rule like this explicitly if desired, rather than just allowing all IPv6 traffic to delegated prefixes by default.
-
Those rules do not have 'quick' set. You can make your own to block whatever traffic you don't want.
The rules as they are have the intended "automatic" feel to them that most people expect. It would be nicer to have them show up in the ruleset like the existing LAN to any default rule, but maybe we can work on that for 2.2.
-
It would definitely be nice if these rules at least showed up in the web interface; as it is, without looking under the hood, it's not obvious at all that the firewall is wide open for externally initiated IPv6 traffic by default. I'm not sure I'd agree that this is a behavior that most people would actually expect; I most certainly didn't.
-
+1
I don't think the average user should expect this behaviour. I have been surfing the web fine via IPv6 without letting any externally initiated traffic in and I think surfing is what the average user would do. OK, IIRC one has to let ICMPv6 unreach, paramprob and toobig initiated from WAN to LAN to be sure not to break protocols. I have not looked into IPv6 active FTP though. If that is still a problem, then the FTP helper would need to be expanded if it isn't already.
But other than that, I would not let anything initiated from the outside into LAN, especially not without a proper warning to the user. -
I don't understand the idea behind this either… Allow ICMPv6 traffic on WAN, not "any". Completely unexpected behaviour.
-
I believe originally the logic there was done to allow for a chain of routers doing delegation. For example, if you upstream DHCPv6 gave you a /48 or /56 then yours in turn would be setup to delegate its own set of prefixes back to things behind it and open traffic to them. So it was more to act as an intermediate router than to sit in front of clients.
That could probably be revisited, only the LAN side rule is strictly necessary there.
-
Well I think nowadays there's quite a growing amount of clients sitting behind IA-PD.
And even if I were to use pfSense as a device doing delegation in a chain, I would still think that I needed to write my own rules for the delegated nets, because pfSense is mainly a firewall, not just a router and thus in my opinion should be secure by default… -
That could probably be revisited, only the LAN side rule is strictly necessary there.
Given that an explicit pass rule is required to let IPv4 traffic in on the LAN side, I think it would be more consistent to require the same for IPv6 traffic as well.
-
True, but there is also an expectation that it will pass out "out of the box" there. I suppose it should probably just be a default allow out IPv6 rule in the GUI like the default LAN rule though, no matter what. (For a fresh install)
-
OK I confirmed that adding a rule to pass IPv6 from LAN subnet to any does pick up the correct delegated prefix subnet, so those rules really don't need to exist. I just pushed a commit to take them out.
-
OK I confirmed that adding a rule to pass IPv6 from LAN subnet to any does pick up the correct delegated prefix subnet, so those rules really don't need to exist. I just pushed a commit to take them out.
Cool, thanks. 8)
