Hacker News Reader

Hacker News

Comment by lima | Hacker News Reader

Full thread

lima

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.

View on HN

> 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.

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.

Is there a setting or CLI command that could change this default behavior, or does PHP code need to be edited?

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/Troubleshoo...

Thanks for the pointer, it looks like iOS content blockers are preventing the images from loading in mobile Safari.

Not "blockers" - the one app you installed and where you enabled web fonts blocking...

Do you have any privacy plugins that might be blocking font-awesome files?

Can it be configured to use full Code-Pointer Integrity? That would be a nice advantage.

SafeStack first, but that's where we're headed. There is still a lot of clean-up.

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.

Yeah, you have to disable tcp hardware packet segmentation offloading.

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.

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.

yep, use Intel e1000e NICs for freeBSD on VMware hosts.

> 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.

FWIW, I have seen that advice given for problems with networking performance in virtualized environments, regardless of the operating system.

The answer here is 'Yes'. TSO and routing / packet filtering are incompatible.

https://wiki.freebsd.org/10gFreeBSD/Router#Disabling_LRO_and...

So why isn't it disabled out of the box (on pfSense, not FreeBSD)?

They are.

https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting...

Do you know when this was instituted? I'm quite sure that wasn't the default when I set up my pfSense systems..

My understanding is that vm is still in development. I don't see a download option from the main page.

There's not an appliance per se but you can just install it to a virtual machine. I was running a 1 CPU, 256MB instance with a 100mbs line and noticed no issues - ESX running on Core i7-920

I really thought they had a blog post somewhere or maybe a tweet or something stating they were planning to support a vm, but I'm failing to find the link. Maybe I'm remembering incorrectly. In any case, they do have a forum section dedicated to virtualization:

https://forum.pfsense.org/index.php?board=37.0

I've used pfSense in VirtualBox for years, as VPN-gateway VMs. I'm posting from a VM that hits the Internet through three VPNs in a nested chain. Each pfSense VM uses just ~70MB.

pfSense works as a Xen guest.

I had the opposite experience, I had to disable all hardware offload to get it to work correctly on XenServer.

There was a bug in pf which made it break with TSO, but it was fixed a couple years ago.

I have pfSense running on a hyper-v server; I haven't noticed any problems with it.

For VMware use the intel e1000e NIC's, not the default ones that you get when setting up the VM using the GUI.

In order to do so, shut down your VM and edit the lines in the .vmx file with the virtual NIC to look like:

  ethernet0.virtualDev = "e1000e"

Repeat that for each NIC.

After that performance should be fine.

4-5 years ago I used pfsense as internet gateway and vpn for point to point in an office with probably 20-30users. We had it clustered between a VM (on ESXi) and a physical appliance on alix (if I recall correctly, or another of the supported sff appliances). The VM was rock solid while the appliance from time to time was experiencing issues (stuck/memory exhausted I think) up to the point that DHCP lease were not released anymore and the office was de facto unable to work.

I think at the end we just kept the VM running alone.

fq_codel is on it's way (though, it's implemented in dummynet/"limiters" rather than ALTQ): http://caia.swin.edu.au/freebsd/aqm/

pfSense already has codel, which can be used with FAIRQ.

> 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.

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

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.)

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

"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.

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.

I wish there were better UI based ditros but the value is kinda limited since people doing the really advanced stuff know Linux specific networking like qdisks and iptables.

You pretty much learn the commands while reading about how the stuff works. I've seen a ton of horribly configured psfense boxes because it exposes all this functionality to people that honestly shouldn't have it and don't know what they're doing.

It's like regedit for networking. If you know enough about the registry to be fooling with it you don't really need a UI but it's nice to have

http://www.ipfire.org/ is Linux based.

I was going to say ipfire, which is particularly interesting to me because of grsec built in, which is awesome.

That being said, if you haven't already, it's time to start learning NFTables and skip right to the chase.

Personally, I tend to not like abstracting firewalls away via guis or other methods like firewalld. It's more work sure, but I understand whats going on and have better control.

You don't have to use pfSense, you can use pf directly and just configure the box yourself.

VyOS, based on Brocade's Vyatta platform (from which Ubiquiti's EdgeMAX platform is also derived).

Take a look at http://www.smoothwall.org/.

Just use OpenBSD. They are the upstream developer of pf anyway.

pfsense uses FreeBSD's fork of pf, which is years out of date. They forked in order to add multithreading, ostensibly for performance. But the diff is too complicated to keep rebasing on top of upstream, so they're stuck with a pf from 2009.

Here are a few resources to get you started. You'll learn plenty about routing!

https://www.openbsd.org/faq/pf/example1.html

https://www.22decembre.eu/2016/05/27/openbsd-router-en/

Compared to Linux, OpenBSD is starkly minimal. It can be a little bewildering when common programs seem to be missing, but the man pages are outstanding. And the system is very simple and reliable. Config files are almost comically short. My /etc/hostname.re0 config is just five bytes: `dhcp\n`.

I appreciate pfSense offering something that's better than the average firewall, but I really wish they would just build it on top of the latest release of OpenBSD.

OpenBSD and pf really is the best. As noted above, FreeBSD has wandered off into the weeds with pf for no good reason. There have been so many improvements to pf since 2009 that I wouldn't even consider using something that old.

I used pfSense years ago when I was first learning firewalls. These days the best GUI for me is no GUI but a CLI, but some people don't want to take the time to build a firewall. Granted, once you know how to do it, it doesn't take that much time to build a firewall, but it does take time to understand what you're doing and why. But really, not that much time, considering the aggravation it can save you down the road.

Why does pfSense use FreeBSD vs. OpenBSD?

Mostly because m0n0wall was written on top of FreeBSD.

you also dislike many OpenBSD policies, and developers.

There are exactly two things I dislike about openbsd.

One is the past behavior of one developer who claimed to reverse engineer code that obviously wasn't.

The other is a mistake made in 2003, to which they've still not owned up.

You don't silently patch security issues, especially when they are discovered and fixed by someone outside the project.

Other than these, I have nothing but admiration for the project and it's developers.

pfsense uses FreeBSD's fork of pf, which is years out of date

It is true that FreeBSD's pf lacks some of the recent improvements which have been made in OpenBSD's pf.

It is also true that OpenBSD's pf lacks some of the recent improvements which have been made in FreeBSD's pf.

What are some of FreeBSD's improvements, apart from multithreading?

VIMAGE / VNET, which allow you to have an instance of pf for each jail. Very useful

The MT work is important, don't be so ready to dismiss it. There has also been work on speeding up pf outside of the MT work.

I'm just not sure how significant the MT work is. OpenBSD's pf has also had performance improvements since 4.5; it would be good to see a benchmark.

Thanks, appreciated.

> 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.

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.

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.

There is actually work going into 2.4 that should further rectify the situation.

pfSenseHelpers.js (https://github.com/pfsense/pfsense/commit/f0136b178022cf3b04...) now contains code that intercepts clicks on anchor tags with the attribute "usepost" set. The target URL and the GET arguments are extracted from the event href attribute, and these are used to compose a new, temporary form with the previous arguments inserted as POST parameters.

Here is a simple example:

Before:

  <?php
  $id = $_GET['id'];
   
  if ($_POST) {
      if (!save_config($id)) {
          $input_errors[] = "Something broke";
      }
  }
  ?>
   
  <a type="button" href="system_something.php?id=<?=$id?>&user=<?=$pconfig['user']?> >
      <i class="fa fa-save></i>
      <?=gettext("Save")?>
  </a>

  After:
  <?php
  $id = $_POST['id'];    // $_GET was changed to $_POST
   
  if ($_POST['save']) {  // The generic if ($_POST) is now if ($_POST['save'] to detect when the form is being saved
      if (!save_config($id)) {
          $input_errors[] = "Something broke";
      }
  }
  ?>
   
  <!-- The "usepost" attribute is added to the anchor -->
  <a type="button" href="system_something.php?id=<?=$id?>&user=<?=$pconfig['user']?> usepost>
      <i class="fa fa-save></i>
      <?=gettext("Save")?>
  </a>

Most of the GUI is being converted to use these, and the result should be in pfSense software release 2.4.

Why isn't `$id` HTML-escaped before being echoed in an HTML attribute context? That's a potential XSS vector. Slightly more difficult to exploit when pulled from `$_POST`, but still a problem.

it's an example.

I don't mean to be combative, but when providing an example of how you're planning to mitigate vulnerabilities, it seems unwise to use code that contains an easily avoidable XSS vuln. I love pfSense and have used it for years, but this sort of thing doesn't inspire confidence.

Understood. It wasn't provided in the example, because it is not a user-entered item and is rarely displayed on the screen. It is typically an index. In other cases (perhaps) because people who originally wrote it knew no better.

(There is a lot if "isnumeric()" stuff used around $id. I inherited this codebase.)

> 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 :)

it doesn't work very well, even for the little OPN/pfSense do.

From my experience it works actually pretty well, and OPNSense does indeed address the issues the parent posted

> 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.pd...

Reply on news.ycombinator.com