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