11 ms·

Last time I checked, pfSense was good at firewalling but bad at everything else security-wise. - Web panel allows root code execution on the device (every XSS

by lima 10y ago

Last time I checked, pfSense was good at firewalling but bad at everything else security-wise. - Web panel allows root code execution on the device (every XSS is full RCE!) - Everything runs as root - No ASLR or other hardening flags because FreeBSD - Lots of XSS and CSRF opportunities (probably got better with the new UI) - Did not replace SSL certificate after Heartbleed (on packages.pfsense.org!) - No package signing, either (not sure if this is still true with pkgng) - Did not even have SSL on packages.pfsense.org until one or two years ago I'm also missing the fq_codel queueing discipline on my home network (prevents bufferbloat). I still use it since it's awesome, but I hope their security posture has improved since. Most of the commercial vendors are even worse, but still.

bcook 10y ago
fq_codel is on it's way (though, it's implemented in dummynet/"limiters" rather than ALTQ): http://caia.swin.edu.au/freebsd/aqm/ http://caia.swin.edu.au/freebsd/aqm/ pfSense already has codel, which can be used with FAIRQ.
- nalllar 10y ago
  > pfSense already has codel, which can be used with FAIRQ. That's not nearly as good as fq_codel, which is not the same as using fairq + codel.
Algent 10y ago
I also had some very bad experience with pfense performances in a virtual environment. Under Proxmox any kind of network load have an abnormal impact on cpu load, often almost freezing the host. On esx it's a bit better but at the cost of low throughput. From what I've read it's an issue with offload/checksum with FreeBSD. After lots of digging on the subject I gave up and switched to VyOS for my proxmox cluster. It doesn't have a nice web panel but the load of the host is now barely noticeable.
- ComputerGuru 10y ago
  Yeah, you have to disable tcp hardware packet segmentation offloading.
  - chrisper 10y ago
    Do you know if I have to do that with regular FreeBSD as well? Like if I were to run just FreeBSD and not pfSense.
    - ComputerGuru 10y ago
      I don't on my FreeBSD hosts and haven't had any problems, but I think it depends on the drivers you have installed. On all my production servers I use standalone Intel NICs w/ the Intel drives; pfSense may be using something else depending on the configuration. FWIW, pfSense has been basically stock FreeBSD + software/skin for the past couple of years.
      - wila 10y ago
        yep, use Intel e1000e NICs for freeBSD on VMware hosts.
      - gonzo 10y ago
        > FWIW, pfSense has been basically stock FreeBSD + software/skin for the past couple of years. While we try to move things upstream as much as possible, there are still patches in pfSense that don't make sense for FreeBSD. > I don't on my FreeBSD hosts and haven't had any problems TSO and routing/forwarding (and thus filtering) are incompatible.
    - krylon 10y ago
      FWIW, I have seen that advice given for problems with networking performance in virtualized environments, regardless of the operating system.
    - gonzo 10y ago
      The answer here is 'Yes'. TSO and routing / packet filtering are incompatible. https://wiki.freebsd.org/10gFreeBSD/Router#Disabling_LRO_and_TSO https://wiki.freebsd.org/10gFreeBSD/Router#Disabling_LRO_and...
Kurtz79 10y ago
Are there other valid open-source alternatives, possibly Linux-based ?
- xenophonf 10y ago
  Dunno about Linux but OPNsense forked off them a while back. Can't speak about the rest but I know that fq_codel is supported because I use that myself. (Frankly, I switched away from pfSense because I like the OPNsense developers and surrounding community better. I'm more confident that if they haven't already addressed those defects, they will soon or they'll welcome patches that do.)
- throwawaydbfif 10y ago
  You probably know, but pfsense is mostly just a nice UI on top of built in networking support in BSD. Linux network support has a lot more features on top of that. You can do more than pfsense with a plain old Linux box but it takes some dense reading to learn to manipulate the traffic control and routing tables yourself. The reason why most open source router distributions with a UI are pretty basic is because everyone doing things sufficiently advanced knows how to manipulate the network stack directly and only needs command line
  - Kurtz79 10y ago
    "You can do more than pfsense with a plain old Linux box but it takes some dense reading to learn to manipulate the traffic control and routing tables yourself." That's why having a nice UI adds already a lot of value :). I wanted something under Linux and I ended up trying a combination of Shorewall and its Webmin plugin to have something similar, but a more holistic solution would be interesting.
    - kbenson 10y ago
      Not to mention that PFSensenormalizes a lot of management. It provides an easy mechanism to queue changes and apply them, lof when changes were made and what the changes were, etc. In a previous job we used to deploy OpenBSD firewalls to provide site-to-site VPNs. We switched to PFSense because management was easier when you have 10-20 of them to deal with, and multiple people might have access. That said, we definitely would have preferred an equivalent interface on top of OpenBSD instead of FreeBSD. There were some differences in the CARP implementation in FreeBSD that made some features of CARP we relied on with OpenBSD unavailable in FreeBSD, and thus PFSense.
tr1ck5t3r 10y ago
What many have not seen is that since 2.0.2 the DNSmasq lookups also give away what type of hardware you have behind it. For example the www.php.net lookup indicates you have HP hardware either running pfsense or behind it, the order these dns lookups take place in are a code waiting to be cracked if you have even noticed what they really are! In later versions these lookups are hidden from the message logs, but you can find them easily, just assign a fictional Lan IP address to the DNS during setup, do not allow the override of DNS from ISP/PPPoe, log all messages. In later versions of pfsense ie 2.0.3, don't complete the wizard during the initial setup which forces a reboot, the reboot hides these messages, open a new tab pointed at the main pfsense interface and do the above changes to log the dns lookups, just don't reboot. In even later versions, those dns lookups can be found by packet capturing the wan output or plug the wan interface into another firewall (double nats I know its bad) and then monitoring the lookups that way. The spooks can use these dns lookups to obtain information about your setup, as can ISP's and anyone who has hacked any switches belonging to your ISP or those en-route to the root servers in the states. When using Bind and the root servers, the capitalisation of certain root servers also gives away the type of firewall you use to the NSA for later hacking. You'll notice that Bind doesn't capitalise the root servers on other platforms like the RaspberryPi, thus not giving away anything you might have hidden behind a Raspbian based firewall. You'll also notice that the Texas repository of pfsense https://atxfiles.pfsense.org/mirror/downloads/old/ https://atxfiles.pfsense.org/mirror/downloads/old/ doesn't have the 2.0.x iso's available any more. Perhaps because its an attempt to cover up what I have detailed above? I have ISO's here for my own records, but the earliest ISO's available are 2.3.x In a way from a hacking perspective, not only do you have all your eggs in one basket with everything pfsense has to offer, because of the inbuilt rules (also seen in opnsense) to allow anything out from the firewall, its good at distributing malware from the pfsense box without any users knowing about it. After all you trust what your firewall says, which is a variation on the lizard squad hacks that targeted routers. Time and time again, I keep coming back to the conclusion, you just cant trust the Americans!
dperfect 10y ago
> Web panel allows root code execution on the device (every XSS is full RCE!) I assume this is only true in the context of authenticated sessions within the web panel, right? If that's the case, is there really a lot of damage an attacker could do with RCE in an authenticated session that they couldn't already do with admin access in the portal? I could be wrong, but it seems the security implications would be roughly the same just by virtue of providing a web admin tool with the ability to perform almost any superuser-level action.
- nitrogen 10y ago
  Yes, RCE allows an attacker to install a permanent bot/rootkit/whatever. XSS and CSRS can allow the attacks to occur silently. Put them together and you can get hacked just by browsing the web, without ever realizing it.
  - dperfect 10y ago
    If I remember correctly, the web panel allows installing packages from custom repository sources. I'm not saying that's inherently secure (it obviously makes other vulnerabilities much more critical), but how is it realistically different from arbitrary RCE within authenticated sessions? I agree that CSRF and XSS vulnerabilities - when combined with superuser-level access of any kind - are basically "game over" for security, but from what I've seen, pfSense has been reasonably quick to patch any such vulnerabilities in the past. XSS, while still applicable, is less likely in a system where very little third-party content is rendered in the browser. When it comes to CSRF, I believe most security-conscious administrators keep things like pfSense web sessions limited, logging out before resuming any other browsing (or better, using it only from a separate browser profile). That doesn't solve those issues, but it can limit the attack surface. Not trying to defend pfSense's security as a whole; I'm just pointing out that RCE is somewhat irrelevant when we're talking about a tool that already allows so much access anyway. One should essentially treat a pfSense admin session as if it were a web-based root shell (because it essentially is that). A web admin tool that can perform superuser actions is - and probably always will be - less secure than other alternatives. Security-conscious people understand that, and will skip tools like pfSense in high-risk environments. But for many others, those risks are reasonable to accept for the added convenience.
gonzo 10y ago
> Last time I checked, pfSense was good at firewalling but bad at everything else security-wise. > - Web panel allows root code execution on the device (every XSS is full RCE!) Mostly, but not absolutely true, and being addressed. > - Everything runs as root Basically true. > - No ASLR or other hardening flags because FreeBSD And because SafeStack CPI is a much better solution, and our focus. > - Lots of XSS and CSRF opportunities (probably got better with the new UI) Work going into 2.4 to basically quash XSS / CARF. > - Did not replace SSL certificate after Heartbleed (on packages.pfsense.org!) I recall differently, but we were more focused on fixing pfSense and the four releases in that month. > - No package signing, either (not sure if this is still true with pkgng) 2.3 got pkgng, and yes, we sign packages. > - Did not even have SSL on packages.pfsense.org until one or two years ago I finally had to take these parts over from the previous admin. If you have more suggestions, I'm listening.
- walterbell 10y ago
  Don't load images (icons) from a public web server, put the images into the local pfSense web server. It should not be necessary to have internet access to use the pfsense web GUI on a private network.
  - logicwon 10y ago
    Do you have any privacy plugins that might be blocking font-awesome files?
  - walterbell 10y ago
    Is there a setting or CLI command that could change this default behavior, or does PHP code need to be edited?
  - gonzo 10y ago
    I'm at a loss as to what you're referring to here. The Font Awesome icons used in 2.3 and forward are located in /usr/local/www/vendor/font-awesome we can (and do) use the GUI when there is no WAN connection Edit: any chance you're running a browser plugin that is blocking the font-awesome fonts? FA started adding logos and stuff to the fonts and there are 3rd party lists you can use that are more aggressive and font-awesome is in some. https://github.com/FortAwesome/Font-Awesome/wiki/Troubleshooting#some-icons-dont-show-up https://github.com/FortAwesome/Font-Awesome/wiki/Troubleshoo...
floatboth 10y ago
> No ASLR or other hardening flags because FreeBSD OPNSense (fork of pfSense) is built on top of HardenedBSD, so there's ASLR, PIE, SEGVGUARD, all the things :)
- pyvpx 10y ago
  it doesn't work very well, even for the little OPN/pfSense do.
  - MohammadLee 10y ago
    From my experience it works actually pretty well, and OPNSense does indeed address the issues the parent posted
tete 10y ago
> No ASLR or other hardening flags because FreeBSD I hope I am not going too far here, but ASLR might be an obsolete feature soon. http://www.cs.vu.nl//~herbertb/download/papers/anc_ndss17.pdf http://www.cs.vu.nl//~herbertb/download/papers/anc_ndss17.pd...

by lima 10y ago

bcook 10y ago

fq_codel is on it's way (though, it's implemented in dummynet/"limiters" rather than ALTQ): http://caia.swin.edu.au/freebsd/aqm/ http://caia.swin.edu.au/freebsd/aqm/ pfSense already has codel, which can be used with FAIRQ.

nalllar 10y ago
> pfSense already has codel, which can be used with FAIRQ. That's not nearly as good as fq_codel, which is not the same as using fairq + codel.

Algent 10y ago

I also had some very bad experience with pfense performances in a virtual environment. Under Proxmox any kind of network load have an abnormal impact on cpu load, often almost freezing the host. On esx it's a bit better but at the cost of low throughput. From what I've read it's an issue with offload/checksum with FreeBSD. After lots of digging on the subject I gave up and switched to VyOS for my proxmox cluster. It doesn't have a nice web panel but the load of the host is now barely noticeable.

ComputerGuru 10y ago
Yeah, you have to disable tcp hardware packet segmentation offloading.
- chrisper 10y ago
  Do you know if I have to do that with regular FreeBSD as well? Like if I were to run just FreeBSD and not pfSense.
  - ComputerGuru 10y ago
    I don't on my FreeBSD hosts and haven't had any problems, but I think it depends on the drivers you have installed. On all my production servers I use standalone Intel NICs w/ the Intel drives; pfSense may be using something else depending on the configuration. FWIW, pfSense has been basically stock FreeBSD + software/skin for the past couple of years.
    - wila 10y ago
      yep, use Intel e1000e NICs for freeBSD on VMware hosts.
    - gonzo 10y ago
      > FWIW, pfSense has been basically stock FreeBSD + software/skin for the past couple of years. While we try to move things upstream as much as possible, there are still patches in pfSense that don't make sense for FreeBSD. > I don't on my FreeBSD hosts and haven't had any problems TSO and routing/forwarding (and thus filtering) are incompatible.
  - krylon 10y ago
    FWIW, I have seen that advice given for problems with networking performance in virtualized environments, regardless of the operating system.
  - gonzo 10y ago
    The answer here is 'Yes'. TSO and routing / packet filtering are incompatible. https://wiki.freebsd.org/10gFreeBSD/Router#Disabling_LRO_and_TSO https://wiki.freebsd.org/10gFreeBSD/Router#Disabling_LRO_and...

Kurtz79 10y ago

Are there other valid open-source alternatives, possibly Linux-based ?

xenophonf 10y ago
Dunno about Linux but OPNsense forked off them a while back. Can't speak about the rest but I know that fq_codel is supported because I use that myself. (Frankly, I switched away from pfSense because I like the OPNsense developers and surrounding community better. I'm more confident that if they haven't already addressed those defects, they will soon or they'll welcome patches that do.)
throwawaydbfif 10y ago
You probably know, but pfsense is mostly just a nice UI on top of built in networking support in BSD. Linux network support has a lot more features on top of that. You can do more than pfsense with a plain old Linux box but it takes some dense reading to learn to manipulate the traffic control and routing tables yourself. The reason why most open source router distributions with a UI are pretty basic is because everyone doing things sufficiently advanced knows how to manipulate the network stack directly and only needs command line
- Kurtz79 10y ago
  "You can do more than pfsense with a plain old Linux box but it takes some dense reading to learn to manipulate the traffic control and routing tables yourself." That's why having a nice UI adds already a lot of value :). I wanted something under Linux and I ended up trying a combination of Shorewall and its Webmin plugin to have something similar, but a more holistic solution would be interesting.
  - kbenson 10y ago
    Not to mention that PFSensenormalizes a lot of management. It provides an easy mechanism to queue changes and apply them, lof when changes were made and what the changes were, etc. In a previous job we used to deploy OpenBSD firewalls to provide site-to-site VPNs. We switched to PFSense because management was easier when you have 10-20 of them to deal with, and multiple people might have access. That said, we definitely would have preferred an equivalent interface on top of OpenBSD instead of FreeBSD. There were some differences in the CARP implementation in FreeBSD that made some features of CARP we relied on with OpenBSD unavailable in FreeBSD, and thus PFSense.

tr1ck5t3r 10y ago

What many have not seen is that since 2.0.2 the DNSmasq lookups also give away what type of hardware you have behind it. For example the www.php.net lookup indicates you have HP hardware either running pfsense or behind it, the order these dns lookups take place in are a code waiting to be cracked if you have even noticed what they really are! In later versions these lookups are hidden from the message logs, but you can find them easily, just assign a fictional Lan IP address to the DNS during setup, do not allow the override of DNS from ISP/PPPoe, log all messages. In later versions of pfsense ie 2.0.3, don't complete the wizard during the initial setup which forces a reboot, the reboot hides these messages, open a new tab pointed at the main pfsense interface and do the above changes to log the dns lookups, just don't reboot. In even later versions, those dns lookups can be found by packet capturing the wan output or plug the wan interface into another firewall (double nats I know its bad) and then monitoring the lookups that way. The spooks can use these dns lookups to obtain information about your setup, as can ISP's and anyone who has hacked any switches belonging to your ISP or those en-route to the root servers in the states. When using Bind and the root servers, the capitalisation of certain root servers also gives away the type of firewall you use to the NSA for later hacking. You'll notice that Bind doesn't capitalise the root servers on other platforms like the RaspberryPi, thus not giving away anything you might have hidden behind a Raspbian based firewall. You'll also notice that the Texas repository of pfsense https://atxfiles.pfsense.org/mirror/downloads/old/ https://atxfiles.pfsense.org/mirror/downloads/old/ doesn't have the 2.0.x iso's available any more. Perhaps because its an attempt to cover up what I have detailed above? I have ISO's here for my own records, but the earliest ISO's available are 2.3.x In a way from a hacking perspective, not only do you have all your eggs in one basket with everything pfsense has to offer, because of the inbuilt rules (also seen in opnsense) to allow anything out from the firewall, its good at distributing malware from the pfsense box without any users knowing about it. After all you trust what your firewall says, which is a variation on the lizard squad hacks that targeted routers. Time and time again, I keep coming back to the conclusion, you just cant trust the Americans!

dperfect 10y ago

> Web panel allows root code execution on the device (every XSS is full RCE!) I assume this is only true in the context of authenticated sessions within the web panel, right? If that's the case, is there really a lot of damage an attacker could do with RCE in an authenticated session that they couldn't already do with admin access in the portal? I could be wrong, but it seems the security implications would be roughly the same just by virtue of providing a web admin tool with the ability to perform almost any superuser-level action.

nitrogen 10y ago
Yes, RCE allows an attacker to install a permanent bot/rootkit/whatever. XSS and CSRS can allow the attacks to occur silently. Put them together and you can get hacked just by browsing the web, without ever realizing it.
- dperfect 10y ago
  If I remember correctly, the web panel allows installing packages from custom repository sources. I'm not saying that's inherently secure (it obviously makes other vulnerabilities much more critical), but how is it realistically different from arbitrary RCE within authenticated sessions? I agree that CSRF and XSS vulnerabilities - when combined with superuser-level access of any kind - are basically "game over" for security, but from what I've seen, pfSense has been reasonably quick to patch any such vulnerabilities in the past. XSS, while still applicable, is less likely in a system where very little third-party content is rendered in the browser. When it comes to CSRF, I believe most security-conscious administrators keep things like pfSense web sessions limited, logging out before resuming any other browsing (or better, using it only from a separate browser profile). That doesn't solve those issues, but it can limit the attack surface. Not trying to defend pfSense's security as a whole; I'm just pointing out that RCE is somewhat irrelevant when we're talking about a tool that already allows so much access anyway. One should essentially treat a pfSense admin session as if it were a web-based root shell (because it essentially is that). A web admin tool that can perform superuser actions is - and probably always will be - less secure than other alternatives. Security-conscious people understand that, and will skip tools like pfSense in high-risk environments. But for many others, those risks are reasonable to accept for the added convenience.

gonzo 10y ago

> Last time I checked, pfSense was good at firewalling but bad at everything else security-wise. > - Web panel allows root code execution on the device (every XSS is full RCE!) Mostly, but not absolutely true, and being addressed. > - Everything runs as root Basically true. > - No ASLR or other hardening flags because FreeBSD And because SafeStack CPI is a much better solution, and our focus. > - Lots of XSS and CSRF opportunities (probably got better with the new UI) Work going into 2.4 to basically quash XSS / CARF. > - Did not replace SSL certificate after Heartbleed (on packages.pfsense.org!) I recall differently, but we were more focused on fixing pfSense and the four releases in that month. > - No package signing, either (not sure if this is still true with pkgng) 2.3 got pkgng, and yes, we sign packages. > - Did not even have SSL on packages.pfsense.org until one or two years ago I finally had to take these parts over from the previous admin. If you have more suggestions, I'm listening.

walterbell 10y ago
Don't load images (icons) from a public web server, put the images into the local pfSense web server. It should not be necessary to have internet access to use the pfsense web GUI on a private network.
- logicwon 10y ago
  Do you have any privacy plugins that might be blocking font-awesome files?
- walterbell 10y ago
  Is there a setting or CLI command that could change this default behavior, or does PHP code need to be edited?
- gonzo 10y ago
  I'm at a loss as to what you're referring to here. The Font Awesome icons used in 2.3 and forward are located in /usr/local/www/vendor/font-awesome we can (and do) use the GUI when there is no WAN connection Edit: any chance you're running a browser plugin that is blocking the font-awesome fonts? FA started adding logos and stuff to the fonts and there are 3rd party lists you can use that are more aggressive and font-awesome is in some. https://github.com/FortAwesome/Font-Awesome/wiki/Troubleshooting#some-icons-dont-show-up https://github.com/FortAwesome/Font-Awesome/wiki/Troubleshoo...

floatboth 10y ago

> No ASLR or other hardening flags because FreeBSD OPNSense (fork of pfSense) is built on top of HardenedBSD, so there's ASLR, PIE, SEGVGUARD, all the things :)

pyvpx 10y ago
it doesn't work very well, even for the little OPN/pfSense do.
- MohammadLee 10y ago
  From my experience it works actually pretty well, and OPNSense does indeed address the issues the parent posted

tete 10y ago

> No ASLR or other hardening flags because FreeBSD I hope I am not going too far here, but ASLR might be an obsolete feature soon. http://www.cs.vu.nl//~herbertb/download/papers/anc_ndss17.pdf http://www.cs.vu.nl//~herbertb/download/papers/anc_ndss17.pd...