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

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

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.

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"

After that performance should be fine.

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

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

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

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.

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

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.

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

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.

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.

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.

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

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

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.

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.

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

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.

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.

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>

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

OPNSense (fork of pfSense) is built on top of HardenedBSD, so there's ASLR, PIE, SEGVGUARD, all the things :)

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