If you manage any network, chances are you have at least one device managed via a web interface. If you manage a corporate environment, it may be up into the dozens, hundreds, or thousands. While web based administration is desirable for a number of reasons such as cross-platform administration capabilities, it also has some unique security risks.

Every web managed device has had a few issues over the years, and pfSense and m0n0wall haven’t been exempt. There are also issues inherent in web managed systems that the systems themselves have little or no control over. The following provides some recommendations on how to securely manage any web-administered device, not specific to pfSense. You should consider these things in the management practices of every device on your network controlled via a web interface.

Keep up to date

Vulnerabilities will inevitably be found on occasion in your web managed devices. We fixed some issues in pfSense prior to 1.2 release, as soon as we were aware of them. Most were minor, though one that was common to m0n0wall, DD-WRT and several other similar distributions allowed cross-site request forgery (CSRF) on the DHCP leases page. This allowed anyone on a local segment with the DHCP server enabled to inject things into the hostname of the DHCP request that would then be displayed unsanitized on the DHCP leases screen. This allowed someone on a locally connected subnet to do anything to your firewall, if you logged into the management interface and viewed the DHCP leases page. There is an exploit out for this now, and a paper covering this kind of issue in web administered devices. If your internal network contains untrusted users, it is important to be running 1.2 release! Note this is only possible for machines connected to an interface with the DHCP server enabled, it isn’t exploitable by anyone outside your network.

Restrict management access

More serious vulnerabilities can allow unauthenticated users with access to the management interface to do bad things. To proactively protect your network from issues like this that may be discovered in the future, restrict access to the management interface as much as possible. First, never open any web management interface’s port to the entire Internet! If you require access from the WAN side, be as restrictive as possible with source IPs or networks. Using a VPN connection and accessing the admin interface by internal IP over VPN is a more secure solution for remote administration.

You should also restrict management access on your internal network in many environments. If you’re administering a small home network, you probably don’t care. If it’s a network with dozens, hundreds, or thousands of devices, restricting access internally is strongly recommended. There is a howto on the doc site describing how restrict management access in pfSense. You should investigate similar controls on your other web managed devices.

Don’t browse the Internet with the same browser you use for administration

If you are authenticated to a web managed device in the same browser you are using to access the Internet, there are several possibilities for persons with nefarious intent to exploit that access. The safest thing is to never browse the Internet from the browser you use for administration. If you use Firefox for Internet browsing, use Opera, Internet Explorer, Safari or some other browser for administration. pfSense works with all those mentioned browsers, though there are a few cosmetic issues in browsers other than Firefox, they don’t affect your ability to manage the device. As an aside, we welcome patches to fix those cosmetic issues in other browsers. We aren’t masochistic enough to care to fix them. ;)

Use a dedicated system not connected to the Internet for administration

You can take the above one step further by using a dedicated machine or virtual machine for administration of your web managed devices that does not have any access to the Internet. The best means of ensuring it doesn’t have Internet access is to assign the management PC a static IP or DHCP reservation and reject Internet-bound traffic from that IP at your perimeter firewall. This is an extreme step in most environments, but is something to consider.