Saturday, July 30, 2016

Limiting uPNP Functionality on pfSense Interfaces

In my previous article, I discussed limiting the outbound traffic on pfSense networks by ports. The uPNP mechanism can bypass the port limitations you have set up by opening additional ports on the interface. Typically this will be devices like gaming consoles, and it can be a needed ability that is just too complex to manage manually otherwise.

However, on pfSense networks that you may not want to allow this I will show you how to turn it off or limit the functionality by specific interface(s). You may have a neighbour on your "guest" wireless using BitTorrent to download pirated content (and you get blamed for it). That system uses uPNP to add port entries to get through your pfSense firewall!

Rules added by uPNP should be shown in the "Floating" column. To choose which network interfaces you want to allow to be modified by uPNP, select "uPnP & NAT-PNP" from the "Services" menu. You will see a page that looks like this:


Under "Interfaces"your networks with uPNP enabled will be selected. In this example, I only have my 'LAN' interface using uPNP. Below this box (not shown on my screenshot) you can also limit bandwidth or control conditions for uPNP on the interfaces where it is active.

Stay tuned for further pfSense content...

Friday, July 29, 2016

Limiting Outbound Ports in pfSense by Interface

In this article, I will cover limiting outbound port traffic, typically done for interfaces like a DMZ (Demilitarized Zone, of the same construct as a conflict between countries) network, a place for systems  (or devices, as in a previous article about an isolated network for "Internet of Things" to be) that you do not want on your LAN because of security concerns. Limiting ports is to restrict the network only the traffic that you want to allow. As an example, TCP ports 80 (HTTP) and 443 (HTTPS) for web content. Basic services like DNS (TCP and UDP protocols port 53) and NTP (Network Time Protocol, on TCP and UDP port 123) should also be enabled for functionality.

This is the main grouping of my DMZ rules limiting outbound traffic by ports (along with defined names and aliases):


Any outside equipment that should not be accessed from systems on the DMZ interface are aliased and blocked (with logging enabled) with the first rule. Access to the pfSense interface is blocked on the next line. On the next two rules, I explicitly block traffic from the DMZ to my administrative and Local Area Network, although you may have an inverse rule on those interfaces to access something like a webserver hosted within your DMZ.

My next "any-any" rule is disabled, but placed for troubleshooting when you might be locking down ports too tightly, and can be quickly toggled to enable all ports to determine if the firewall is the issue. Disable it again after adding the correct port(s). I also turn off outbound PINGs (ICMP) from the DMZ, but have a rule (the last) to enable that functionality if necessary.

Four rules are in place to allow basic web browsing (both HTTP and HTTPS) over the DMZ interface, being assigned a DHCP address and DNS from a wireless access point (WAP). Specific web addresses are also blocked from that WAP. More details are in an earlier blog post on setting up a "guest" wireless network.

That's all there is to structuring the use of your network(s) in pfSense. Of course, your LAN environment can be more complex, with such things as gaming consoles needing other odd ports open at need, but the uPNP mechanism (which does that process automatically on pfSense and other gateway devices and firewalls) can be controlled by interface in pfSense. The WAP I use on my DMZ interface has uPNP disabled.

Stay tuned for other pfSense content, and ask questions in the comments section below...

Monday, July 18, 2016

pfSense 2.3 Part 7 "DNS Resolving and Benchmarking"


DNS Server settings for pfSense, which can also be very helpful:


pfSense 2.3 Part 6 "DHCP Server"


A little bit more on DHCP Server functionality in pfSense. Some of the areas Mark shows are critical to my earlier blog entries, so this is the place to study DHCP aspects closer. I'm a big fan of setting the static mappings for all the systems on my networks.


pfSense 2.3 Part 5.4 "NTP Server"

The basic functionality of the Network Time Protocol on the Internet, and how the pfSense firewall interfaces to those time sources:


pfSense 2.3 Part 5.3 "Configuration Backup / Restore"

Now on to the useful practice of backing up your pfSense configuration (even though I've never had a problem where I had to restore a pfSense configuration):


pfSense 2.3 Part 5.2 "RRD Graphs"


I'm going to link the remaining pfSense videos by Mark Furneaux without much comment (because Mark does well enough explaining things himself). You get to see more of the beauty and functionality of pfSense 2.3 (now at the 2.3.1 release). It's worth noting that although I first set up pfSense for protecting my home networks, now with it handling the job appropriately I focus more on the visibility it provides on how well those networks are working, and how my uplink bandwidth is loaded.

Case in point, the RRD Graphs:


pfSense Secure Interface Access, Part 2

In the second portion of the section, I am going to address secure LAN access to your pfSense firewall. The structure of the first section is also used here, although not required to be enabled (with the caveat that you can undo a bad rule if you accidentally lock yourself out. Even though I have a separate administrative network to access my pfSense firewall, I am going to describe how you tighten security from a single LAN interface (it may actually be more important in this example). There is also the side benefit of being able to lock down access to external equipment to a limited number of your systems when your WAN IP address is on an ACL for that equipment.

Initially we will need to work with the DHCP server functionality, some planning, and the "Reserved" IP addresses possible with pfSense. Mark Furneaux covers the DHCP server of pfSense in a video I haven't linked (yet), but I'll show how to do the steps I am referring to here. The 2.3 release of pfSense makes setting a reserved address extremely easy.

First, we're going to look at the configuration of the DHCP Server, which you can do by selecting 'DHCP Server' from the 'Services' menu. Again, ignore that I have an 'ADMIN' and 'DMZ' interface. Your subnet of the LAN interface will be shown (192.168.1.0 would be common), and the range of IP addresses on that interface (the subnet 255.255.255.0 is also common, meaning 254 available IP addresses, with the firewall using one of them for that interface).

We want to have the DHCP server enabled for the LAN interface, and 'Deny Unknown Clients' unchecked at this point. You will either need to know how to determine the MAC address of your systems and devices, or get them on the network one at a time. It will be helpful to start up an Excel spreadsheet (or Google Sheets) to be organized. I set a small DHCP pool in a range of about 20 to 30 addresses, then start arranging blocks above that range of IP addresses for the "reservations".

For this example (with the address range example above) we will set a DHCP pool range 'From' 192.168.1.10 'To' 192.168.1.29 (30 available IP addresses). I've obscured the address ranges I use, but you can see where the entries go. Here is a screenshot:


Now we are going to pull up the 'DHCP Leases' screen under the 'Status' menu. You will need to determine which systems have a 'dynamic' address, and the IP address that you want to assign them (outside the DHCP pool, on the same subnet, and uniquely on that IP address, however pfSense will check all that when you try to apply the static mapping). That is where you spreadsheet will come into play for organization. You are going to set one column for the IP addresses, one column for the systems, and a column for the MAC address.


I'm extremely organized, and provide a range of ten to twenty addresses for each person (depending how many Internet-enabled devices they have) in the household. There are separate entries when a device or system (like some Roku models or a laptop) that have both a wired and wireless connection. Click on the left-most '+' ('Add Static Mapping', without the blue background) under the 'Actions' column for the system we are going to add for the first "reserved" address.

Come up with a descriptive hostname for the system, and describe it appropriately. Remember to use your spreadsheet to be organized. Apply the settings after you have filled out at least the needed entries:


I recommend setting all the devices and systems (except for your network infrastructure that has addresses statically assigned) on your network this way. Put the "IoT" devices on your DMZ network, as described in my earlier article "Internet of Things, Isolated Networks". Then you are going to check 'Deny Unknown Clients' in the DHCP Server section (for all the network interfaces you have), and tell household members not to give out the wireless password to their friends.

Of course you would have followed my "Guest Wireless Access Point Security" entry earlier this year to set up a DMZ network. Yes, there will be devices that household members will need to add from time-to-time, and you might also need to set up a block of IP addresses for statically mapping those "friend's" devices that haven't followed your rules.

Once you have your spreadsheet completed, with which systems you want to be able to access your pfSense firewall, we are going to create an alias (internally I just have a single entry, with all of the IP addresses I allow) for those systems:


Then we will create the rule(s) for allowing these systems to access the firewall interface. The second rule is not needed, it is just an implicit block I have set up for all other systems on the LAN. Note that I am not showing the "Anti-Lockout Rule" (that we will disable later) at the top of the list:



To disable the "Anti-Lockout Rule", one way is to select 'Advanced' from the 'System' menu, or just click on the blue gear to the far-right of that specific rule. Scroll down to this portion and check the box. If you accidentally lock yourself out on the LAN interface entirely (and don't have a similar set of rules set up on your equivalent of my "ADMIN" network), then access the firewall from the WAN side and re-enable the 'Anti-Lockout Rule".



If there are any steps that I need to explain better, or you feel I should add something, please comment below. The next blog entries will be the remainder of the Mark Furneaux series on pfSense, without many comments. Stay tuned for further pfSense configurations!


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!