Tue
18
Apr
2017
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.
Tue
17
Mar
2015
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 :)
Mon
06
Jan
2014
I was trying to find a good reason to buy the well-known raspberry pi, apart from the usual ones, and I decided that it would be ideal to make it a syslog server for my home firewall (running on pfsense). No grahpics required, not significant cpu-power or memory requirements, etc, some just storage for storing text logs.
As an OS, I decided to use moebius linux, a Raspbian based and consequently, Debian based one, just because it is minimalistic, as a syslog server should be.
After copying the image to a 2GB SD card, it seems to be more than enough, (for installation instructions please check here), login into it (using ssh of course), configuring it (using moebius.config or moebius.config --normal), updating it (apt-get update and then apt-get upgrade, as in any Debian-based system), and finally, restarting it, it's now time to tailor it according to our needs.
First, create your user:
useradd myuser -d /home/myuser -m -s /bin/bash
Configure myuser's password
passwd myuser
Of course, do not forget to change your root's password too, if you haven't already done it.
Now, it's time for some hardening.
First, let's harden ssh. Moebius does not use OpenSSH, but Dropbear (it saves more than 10 MBytes of RAM):
vi /etc/default/dropbear
Add the following lines:
DROPBEAR_PORT=45323 #the TCP port that your Dropbear server will listen on
DROPBEAR_EXTRA_ARGS="-w" #Disallow root logins
Restart the service
/etc/init.d/dropbear restart
Now, we'll add the required software / packages. First of all, install iptables, to use them as a host firewall to our syslog server:
apt-get install iptables
Assuming that your SOHO firewall (the logs of which you want to store into the syslog server) has an IP of 192.168.1.101 and your PC from where you access the raspberry has an IP of 192.168.1.60, let's configure the iptables to accept the required connections only by them (of course, do the following as root):
iptables -I INPUT 1 -p udp --src 192.168.1.101 --dport 514 -j ACCEPT #to accept syslog connections from your SOHO firewall
iptables -I INPUT 2 -p tcp --src 192.168.1.60 --dport 45323 -m state --state NEW -j ACCEPT #to accept ssh connections from your pc
iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED
iptables -I INPUT 3 --src 192.168.1.60 -p icmp -m icmp --icmp-type 8 -j ACCEPT #to check from your PC whether raspberry is alive
iptables -P INPUT DROP #Default dropping policy
iptables-save > /etc/iptables.conf
echo '#!/bin/bash' > /etc/network/if-up.d/iptables
echo '/sbin/iptables-restore < /etc/iptables.conf' >> /etc/network/if-up.d/iptables
chmod +x /etc/network/if-up.d/iptables
Moebius uses the inetutils-syslogd software. Uninstall it, for our purposes we shall use syslog-ng:
apt-get remove inetutils-syslogd
apt-get install syslog-ng
Now, let's configure syslog-ng:
vi /etc/syslog-ng/syslog-ng.conf
Go at #Sources and comment internal(), as following:
source s_src {
system();
# internal();
};
Now, add the following lines:
source s_net { udp(ip(0.0.0.0) port(514)); }; #0.0.0.0 will bind to all interfaces on your syslog server.
destination pfsense { file(“/var/log/pfsense.log”); };
log { source(s_net); destination(pfsense); };
Exit the configuration file and start the service:
service syslog-ng start
Create the corresponding log file:
touch /var/log/pfsense.log
Almost done. Time to configure pfsense to send the logs to your brand-new minimalistic syslog server. At the web interface of pfsense, go to:
Status -> System Logs -> Remote Logging Options
Check Send log messages to remote syslog server
Enter your syslog server's IP at: Remote Syslog Servers Server 1
At the Remote Syslog Contents enable (tick) just the Firewall events (this is what
we are interested in).
Press the Save button below and you are all set.
You'll find your logs at /var/log/pfsense.log . If you want to check them very quickly, just run:
cat pfsense.log | grep -v match | grep -v From | grep \> | awk -F " " '{print $6 " > " $8 " "$9 " " $10}'
You should see sth like:
178.151.224.39.65421 > 212.251.127.252.24922: Flags [S],
178.151.224.39.65421 > 212.251.127.252.24922: Flags [S],
178.151.224.39.65421 > 212.251.127.252.24922: Flags [S],
84.125.77.90.42601 > 212.251.127.252.35074: UDP, length
200.120.43.102.59696 > 212.251.127.252.19783: UDP, length
212.253.163.15.49425 > 212.251.127.252.19783: Flags [S],
212.253.163.15.58323 > 212.251.127.252.19783: UDP, length
212.253.163.15.49425 > 212.251.127.252.19783: Flags [S],
212.253.163.15.58323 > 212.251.127.252.19783: UDP, length
212.253.163.15.49425 > 212.251.127.252.19783: Flags [S],
212.253.163.15.58323 > 212.251.127.252.19783: UDP, length
46.117.45.207.61116 > 212.251.127.252.35074: Flags [S],
46.117.45.207.61116 > 212.251.127.252.35074: Flags [S],
46.117.45.207.61116 > 212.251.127.252.35074: Flags [S],
46.117.45.207.61116 > 212.251.127.252.35074: Flags [S],
46.117.45.207.61116 > 212.251.127.252.35074: Flags [S],
46.117.45.207.61116 > 212.251.127.252.35074: Flags [S],
46.117.45.207.61116 > 212.251.127.252.35074: Flags [S],
46.117.45.207.61116 > 212.251.127.252.35074: Flags [S],
212.253.163.15.50420 > 212.251.127.252.19783: Flags [S],
212.253.163.15.58323 > 212.251.127.252.19783: UDP, length
212.253.163.15.58323 > 212.251.127.252.19783: UDP, length
212.253.163.15.50420 > 212.251.127.252.19783: Flags [S],
186.177.13.108.36363 > 212.251.127.252.49455: Flags [S],
186.177.13.108.36363 > 212.251.127.252.49455: Flags [S],
186.177.13.108.36363 > 212.251.127.252.49455: Flags [S],
186.177.13.108.36363 > 212.251.127.252.49455: Flags [S],
186.177.13.108.36363 > 212.251.127.252.49455: Flags [S],
123.243.30.8.55691 > 212.251.127.252.35074: Flags [S],
123.243.30.8.55691 > 212.251.127.252.35074: Flags [S],
123.243.30.8.55691 > 212.251.127.252.35074: Flags [S],
186.198.163.87.1024 > 212.251.127.252.19783: UDP, length
212.253.163.15.58323 > 212.251.127.252.19783: UDP, length
212.253.163.15.58323 > 212.251.127.252.19783: UDP, length
....
Enjoy!
Mon
07
Oct
2013
The long-waiting PfSense 2.1, one of my favourite open-source firewalls, was released in 15th September of 2013. Apart from the various other improvements and new features that it offers (see http://blog.pfsense.org/?p=712 for more details), PfSense 2.1, based on FreeBSD 8.3-RELEASE-p11, for first time supports out of the box the IPv6 protocol in a stable version.
After installing it and establishing as an IPv6 firewall for testing purposes and configuring it to work properly, I checked its IPv6 security features and specifically the Firewall IPv6 options that were available from its WebGUI. To my dissapointment, the options are mainly similar to the IPv4 ones, plus some more regarding ICMPv6 additional types (e.g. Router Advertisement, etc.). However, there were no options regarding blocking or allowing several IPv6 Extension Headers, like Fragmentation Header, Destination Option Header, etc. These headers are new in IPv6 and, apart from the new feautures they introduce, they also bring several new potential attack vectors (for discussion about such issues, please check my "Papers / Presentations" section. Hence, this lack of supported options (at least at the Web GUI), seems rather important to me from a security perspective. But let's be patient, as I said this is just the first stable release of Pfsense that supports IPv6.
On the contrary, I must admit that m0n0wall, the "big" brother of Pfsense (since Pfsense is a fork of m0n0wall) has much more available options regarding the support of IPv6 security features. Of course, it lacks some other features, but this is another story.
I intend to launch several tests against Pfsense and m0n0wall regarding the supported IPv6 security. So, stay tuned to see the results, if you are interested!