Sunday, July 17, 2016

pfSense Secure WAN (and LAN) Interface Access

In my last pfSense topic , I discussed locking down the pfSense interface to only HTTPS ("Secure HTTP", or web browsing) and SSH (Secure Shell) access. This is to a required level in a modern security environment when accessing your network from the outside (where there may be someone able to see the transmission of your username and password for your pfSense firewall electronically), but I also recommend it for within your home network too. I even have an administrative network (on a separate VLAN, or Virtual LAN, trunked between managed Ethernet switches) separate from my main LAN (Local Area Network) without a wireless access point (WAP) that is the only connection able to access my network infrastructure.

You will also learn the concepts of an "Access Control List" (ACL), "aliases" within pfSense, and using "Reserved" IP addresses within your network(s). An ACL is a limitation by source IP address to a network interface (which can be both WAN(s) and LAN(s)), basically only sources that you want to allow, like from work or another location. pfSense allows the use of "aliases", meaning that you can create a collection of IP addresses or ports under a single name. Lastly, both the ACL and aliases work best on your LAN(s) when you have the IP addresses on those interfaces organized. "Reserved" IP addresses allow you to control that from the DHCP server in pfSense, so that a device or system always gets the same address without needing to set it statically.

In fact, I recommend setting up external access and verifying it works before limiting access or implementing an ACL internally: If you lock yourself out through a bad entry you can remotely access pfSense to remove the new rule and correct it. Initially, we will need to change the interface access to HTTPS if you don't have it set that way already, but there shouldn't be any other potential to lock yourself internally for this first section:


After you apply the setting, log off and log back in specifying Secure HTTP with "https://" leading the URL for your firewall (I actually don't know if these steps are prompted with the change, as I have had "HTTPS" selected from my initial pfSense installation). All modern browsers will provide a certificate warning, you can create a security exception for Firefox, or just click through the 'Advanced' selection for Chrome to continue. Of course, you have taken the steps to have a secure password on a username you have created for your firewall, disabling the default?

Next, we will start creating the alias(es) and rule(s) for external access. In pfSense select 'Aliases' from the 'Firewall' menu, then select the 'Ports' heading. 'Add' a new alias with both the SSH (22) and HTTPS (443) ports to the list, then apply the changes.



Under 'IP' in the same 'Aliases' section make entries for the IP address sources that you will be accessing your firewall from. I recommend separate aliases and rules for each location, so that they can be disabled individually later (for instance I will have a remote location that I seldom visit, that I turn on and off access depending if I will be staying there briefly). Here is what my entry looks like:


A '/32' is a single (IPv4) IP address. Have your ACL as tight as possible, only allow a range if you might need access from all addresses in that range, anticipating that your account and password is enough protection potentially from others also trying to access your pfSense firewall. You can also have the attempts logged, and pay attention to failed log-in attempts as someone possibly trying to hack in. Next, we create the rule itself:


As I said earlier, create separate rules for each outside WAN location. pfSense allows you to add a similar rule very easily (the only thing that will change is the 'Source' and comment description). Test access from each location added, and if possible an external address slightly different from one on your ACL, just to verify it is excluded. In the next topic, we will continue on for limiting access internally, stay tuned!

No comments:

Post a Comment