The Quest for Network Security at Home, Part 2

In the first part of this series, I shared my frustrating journey seeking a better way to secure my network at home. It’s been two months since then and the main change is the release of the second generation Bit Defender Box. It’s still a little early to make a call on this device as it’s just rolling out. It also seems that Norton has continued to improve their Core with software updates, but the device still only has 3.3 stars on Amazon and that gives me pause.

As I needed to put something new in place to increase my security, I decided to give pfSense a try. The path is not for the casual user-you need to have some aptitude for networking and IT systems administration to understand what you are doing. That said, I found the process to be very smooth, and the variety of community resources amazingly helpful (especially pfSense Documentation and pfSense Setup HQ). I even breezed through the process upgrading my initial pfSense installation from version 2.3 to the newly released 2.4 and a variety of small patches thanks to their wonderful administration panel.

The first step in the setup process was putting the basic pfSense firewall in place. It was easy to burn a DVD with the install packages and a wizard guided me through the process of configuring the basics. Now it was time to layer on the security.

As a basic level of security, I decided to skip using my ISP’s DNS servers and move straight to OpenDNS. After running some benchmarks, it was clear that these servers were more performant than those of my ISPs. It also had the added benefit of refusing to resolve DNS queries for sites that are known as phishing, have malware, or are compromised. As an added bonus, parents also have the option of selecting a set of servers that also refuse to resolve sites with adult content. I highly recommend that everyone consider making this tweak on their home network-especially since it’s free and can be done with almost all home networking equipment.

Since I was going to all this effort, I really wanted to put a IDS/IPS solution in place as well. Snort seemed like the logical choice, so I easily installed those packages with the pfSense package manager. The next step was deciding what “rules” to enable detect threats. Why not simply enable all the rules? Unfortunately, it potentially can slow down performance. And after all, why enable rules for threats that don’t apply to my network? I found this rules explanation extremely helpful in selecting the right rules to enable.

I initially started with the freely available Snort VRT and ET Open rules. Eventually, I opted to pay $30 for an actual license to Snort rules (giving me access to new rules 30 days earlier). I reached out to the makers of ET Open a couple times for licensing on their rulesets, but I never received a response.

As I evaluated alternative hardware options (to replace my giant and old server used for testing), I quickly realized that many of the affordable options had less processing power available for IDS/IPS. At this point, I learned about Suricata. It’s a competitor to Snort, however, is architected in such a way it can take advantage of multiple cores (whereas the current version of Snort is still single-threaded).

With pfSense’s package wizard, it was easy to switch and I’ve stayed with this configuration. And as a pleasant surprise, it also runs on the same Snort and ET Open rulesets so there was no money lost. The only time-consuming part of this process was continuing to tune the log alerts for the rules. Initially, a lot of false-positives are generated because software developers don’t strictly follow TCP/IP guidelines. After a week or two, I was able to reduce the alerts to a much more manageable set.

I didn’t want to log into my router every day to check the logs, I found a package called mailreport and configured it to e-mail me interesting log entries daily. It’d sure be nice if there was some form of mobile app for administering pfSense, but I also understand why that does not exist as it’s not a product targeted at consumers.

The next level of security I added was enabled by a package called PFBlockerNG. I found this setup resource extremely helpful: https://www.tecmint.com/install-configure-pfblockerng-dns-black-listing-in-pfsense/. The feature I was most excited about was blocking IPs based on region. I mainly interact with servers in North America, so there’s no need for any of my systems to reach out to other parts of the world. In fact, if a system was to reach out to a server in another geographic region, it likely has been compromised. I easily created outgoing rules blocking traffic to these regions. Note that only outgoing rules are needed in my case as the firewall is already blocking incoming traffic by default and I’m not running any on-site servers. I’m also still working on selecting appropriate DNSBL lists—but feel less pressure in this area since I’m already relying on OpenDNS.

I think I’m going to run with this configuration for a while and see what new products emerge over the next year. I almost pulled the trigger on purchasing some new hardware from Netgate (the company that maintains pfSense), but the initially helpful sales rep went silent on me. Their entire product line is based on Intel Atom processors and I needed some assistance picking the right unit with enough CPU power to perform IDS/IPS. That said, my current hardware is meeting my needs and should bridge me over until the next generation of solutions emerge.