Introduction
Hear that sound? That is someone rattling your doorknob. If they are able to break in, they will ransack your home, rifle through your private papers, correspondence, bank statements, photos, and if lucky they’ll find your club memberships and credit cards – your identity. They may even plant listening devices. If you lived in a bad neighborhood, you’d put in high quality locks and maybe an alarm system. The problem is, on the net, everywhere is a bad neighborhood.
What stands between you and this happening on the internet is generally your router, which is designed more as a doorway than a lock. Consumer grade firewalls, either software or hardware, can act as a lock or gatekeeper. But to truly turn back the faceless attacks (even if they would just find pictures of your kids), you need a dynamic firewall with intrusion detection; the kind of 1U firewall server appliances usually found only in corporate data centers (read: expensive). Devices that generally start at about $3K; a Cisco PIX firewall starts at nine.
We’ll show you how you can put together your own firewall/router with all of the capabilities of high-end gear using open source software and inexpensive components. There are a significant number of open source distributions available for homebrew router/firewall builds. We chose pfSense for its outstanding built-in functionality, active support forums, first class documentation and overall maturity. Most significantly, beyond rich routing functionality, pfSense offers firewall and intrusion detection/prevention well beyond that of the mere mortal router.
Firewall vs. Intrusion Detection/Prevention
To understand the advantages offered by pfSense over your router or a firewall, we need to understand the difference between what a router/firewall offers and what an Intrusion detection system (IDS) provides.
A firewall, in the most general sense, works at the connection level of your network traffic, looking at the envelope of a network connection: Where is it coming from? Where is it going? What is the origin and/or destination address/port?
Figure 1 is as real firewall log, notice the aforementioned doorknob rattling:
Figure 1: A real firewall log showing network probes
An intrusion detection system goes beyond and below firewall filtering. Beyond, by looking at the pattern of network connections, recognizing port scans, specific threat signatures and denial of service attacks. Below by looking at the actual contents of each packet, recognizing executable code, badly formed packets, buffer overflow attempts, and things like plain-text credit card numbers.
Figure 2 shows a real log from the IDS tool Snort for the same period as above:
Figure 2: Snort log
Note: The IP addresses have been obscured to protect the innocent and the network the router/firewall protects. These logs are from a developer’s (my) home network, with no P2P traffic or other dodgey activity that might advertise the WAN IP address.
pfSense
pfSense is a free, mature open source project that runs on top of FreeBSD, for firewall/router installations. It has been around since 2004, when it was spun-off from m0n0wall. Where m0n0wall is designed for embedded systems, pfSense is geared toward x86 commodity hardware.
Like any modern router, pfSense is administered through a comprehensive Web GUI (Figure 3). At no point do you need to drop to a shell window, unless you want to further customize your router.
Figure 3: pfSense Dashboard
The out-of-the-box functionality is impressive, and too long to go into here, but includes full routing capabilities across multiple interfaces, graphical traffic monitoring, firewall filtering, VPN Support (IPSec, OpenVPN, PPTP ), Captive Portal login handling, Quality of Service traffic shaping, load balancing across multiple interfaces, ISP & Router failover, and network logging. Over the top functionality.
In addition, Table 1 shows a few of pfSense’s add-in integrated packages adapted to pfSense’s Web GUI, providing a surprising array of functionality.
| Snort | Eminent packet filtering rules engine, providing intrusion detection and prevention, allows for policy enforcement, and IP blocking. With custom and regularly updated dynamic rules. |
|---|---|
| Squid | High speed caching web proxy, can run transparently |
| SquidGuard | Squid Proxy Add-on for Content Filtering |
| HAVP | HTTP antivirus scanning proxy, a front-end to ClamAV |
| IP-Blocklist | IP blocking based on various published IP address lists from iBlockList.com |
Table 1: pfSense packages
Beyond the integrated pfSense packages, FreeBSD offers a rich set of network tools and open source packages, including EtherApe, PFTop and Tarpit that can run in conjunction with and alongside pfSense.
The Build
Meet Cerberus, named after the mythical three-headed dog guarding hell. The name was chosen because of the three forms of protection that it provides: the pfSense Firewall, Snort IDS, and the IP-Blocklist package.
Figure 4: Cerberus hardware
Figure 5: Cerberus hardware – rear view
Figure 6: Cerberus hardware – top
This is my second pfSense build, the first used a mothballed 550W Pentium Core 2 Duo E6750 desktop with two network cards added to support a total of three interfaces, WAN, LAN and a Guest WLAN access point. Though inexpensive (already had the hardware), it was like killing a gnat with a bazooka. pfSense requires nowhere near that much machine, and left an ATX Desktop box where the much smaller DGL-4500 router used to sit.
When the need for a Drupal developer machine arose, it was decided that a purpose-built, low power small footprint pfSense box would be used to free up the desktop machine for that purpose. Less cost, greener, and not nearly as ugly.
For size, Mini-ITX was selected: a dual NIC motherboard using Intel’s NIC chipset, and supporting up to 3 GB of memory to support the memory-hungry Snort package. The budget was initially around $200, reusing spare parts from the previous build. We were not set on a particular processor; that decision was driven by the motherboard size, memory limit, and Intel dual NIC requirements (wanting to avoid the widely reported problems around the Realtek NIC chipsets). Our only choice of CPU was the Atom processor.
Dual NIC was needed to support all three interfaces, a single NIC motherboard, though cheaper, would have required a significantly more expensive Intel Dual NIC card, pushing the price to about the same point as a mini-ITX server motherboard.
| CPU | Intel Atom D525 (Pineview-D) Dual Core, 1.8GHz (13W) processor | Incl in mobo |
|---|---|---|
| Motherboard | Supermicro X7SPA-H-D525 Mini-ITX Server | $180 |
| RAM | 2 x non-ECC DDR3 1066MHz SO-DIMM (running @800MHz) | $50 |
| Storage | WD Scorpio Blue 2.5” 250Gig drive | $40 |
| Ethernet | Intel 10/100/1000 PCIe NIC | $30* |
| Case | Antec Mini-Skeleton-90 | $90 |
| DVD | Sony DVD-ROM | * |
Table 2: Component list
* Reused from previous build
I initially selected the Asus Hummingbird Atom D510 motherboard. But when that was temporarily out of stock, I discovered the less expensive, newer generation Supermicro Atom D525 motherboard. Though scarcer, it sold for the same price as the D510 Supermicro model and for less than the Asus.
The choice of Antec Mini-Skeleton-90 case, though relatively expensive, was completely driven by aesthetics and build quality. All other choices were non-descript boxes. This decision did mean a 2.5” SATA drive would be needed, since the case provides only one 3.5” drive bay for our spare DVD drive, and two internal 2.5” bays. After the build, we realized the DVD drive was unnecessary, the install could have been done from a USB drive and a spare 3.5” SATA hard drive could have been used instead.
To get our third network interface, we reused the Intel 1000/100 Pro board from our first build for the wireless guest AP via a wireless N bridge. If we had not already had these components on hand we probably had gone with a Wireless-N PCI-e NIC (most likely the Asus PCE-N13, which was not supported at the time of the first build).
A note for builders looking at a Mini-ITX build for the first time, the selection and availability is dramatically different than you are probably used to in the ATX world. We found only one vendor for the Asus board, and getting the newer D525 Supermicro board took some wrangling with a very helpful small vendor, who also carried the Antec case (a thanks for personal attention to InterProMicro.com).
Several other components were needed to make this a full-blooded router, which we took from the first build. To expand the number of ports to support our home network, a Gigabit switch was added. The already-mentioned wireless-N bridge was added for guest wireless, and our old wireless router in AP mode for wireless access to the LAN network to provide shared file and printer access to trusted clients.
| Port Expansion | D-Link DGS-2205 Gigabit 5-Port Desktop Switch | $32 |
|---|---|---|
| Guest Wireless | TRENDnet TEW-637AP 802.11b/g/n Wireless Easy-N-Upgrader | $45 |
| LAN Wireless AP | D-Link DGL-4500 (existing router) | – |
Table 3: External component list
These components are largely optional and dependent on your requirements. Your current wireless router may already have guest wireless, and the switch is only needed if the number of machines exceeds the remaining ports on your router. With the switch and the router, Cerberus can handle seven wired clients. Additionally, the wireless bridge can be turned off in the absence of guests.
Total base cost was about $360. If you add the switch, the bridge, and the NIC, you are looking at about $470 all in. Yes, it’s a little high, and almost twice our budget. But you can get a reasonable case for half the cost and pfSense will run in half the amount of memory and a lesser processor.
Further cost reduction is realized by dropping guest wireless. This would eliminate the third NIC and need for the wireless bridge. And if you have a spare port on your current router, no switch is needed.
These changes would bring total cost below $300– maybe $100 more than a premium router. Of course, the cheapest solution would be our first build, an old surplus x86 machine fitted with the needed additional NICs for maybe $80?
The assembly itself was straightforward, no need for seating of the CPU or cooler, the case provides a power brick, and there is pull-out tray with sufficient cable play to easily wire up the case from there – the fingers pinch a bit fitting in the drives, and cable routing is a bit of a hassle. But this was the quickest build I’ve ever accomplished.
Performance
One of the available packages for pfSense is iPerf, making it easy to measure throughput.
Running iPerf as the server on Cerberus, directly over Gigabit LAN to iPerf on another machine running Windows 7, the average throughput was 236 Mbps, with a peak of 253 Mbps (Figure 7).
Figure 7: Cerberus performance
CPU utilization was never over 75%, and under normal usage the CPU utilization rarely exceeded 10%, which means that Atom D410 would probably serve just as well. Surprisingly, running Snort versus not running Snort had a negligible effect on throughput.
pfSense and Package Install
Installing pfSense could not be easier, and is well documented here, but briefly:
- Burn a LiveCD, downloaded from pfSense.org.
- Boot the CD.
- Using Auto-Detect, when prompted plug in each network cable, in order: LAN, WAN, OPT1/WLAN.
- Your router is now up in RAM. From here, select from the menu &99. Install to hard disk.
- Go with the defaults to dedicate the hard disk to pfSense; once completed, remove the CD.
- From a browser, log in to your router’s Web GUI at 192.168.1.1 – with the default user-id / password of admin, pfSense
- Step through the set-up wizard, changing the defaults: LAN IP, User Name, Password.
- Set up your wireless interface, change the name, and enable DHCP.
- Set up a Firewall Rule to define a route for the Wireless interface to the WAN and to your LAN, or not.
For Cerberus, this entire process took less than an hour, and was seamless. You will need to configure your legacy router to operate as an AP. The steps are specific to your router – but generally, you need to disable DHCP and plug a LAN cable into a LAN, not the WAN port. You can also check this popular how-to.
For your wireless bridge setup, follow the manufacturer’s directions. These tend to be configured first and then plugged into your optional WLAN interface.
Snort
As previously introduced, Snort is a packet inspection rules engine which scans network traffic looking for anything that might raise an eyebrow. The rules for Snort come from Snort.org, and are comprehensive – thousands of rules. As you can imagine, setting up and running Snort is a bit more demanding both for you and for your build; you, because of the inevitable generation of false positives, and for your build, because of the sheer amount of processing and memory required for real-time packet scanning of that many rules.
To get rules for your install, you need to register with Snort.org and get your free OinkMaster Code. Once you get your code, you are ready to install.
All packages for pfSense are added through the System->Packages submenu. Once added, enter your code into the Snort’s global settings (Figure 8) by going back to Packages, then to Services->Snort. Then update rules through the Update tab. If you have a problem, ensure there are no trailing or leading blanks in your Oinkmaster code.
Figure 8: Snort global settings
You now need to bind Snort to your interfaces. Start with the WAN interface. This is like alarming your main entrance, it’s where most of the action occurs. I recommend either the AC-STD or AC-SPARSEBANDS memory model, providing a good balance between performance and memory usage (Figure 9).
Figure 9: Snort WAN interface settings
Choosing to block offenders will make you more invisible to those probing your network for a weakness and offers higher security But this requires more administration as you’ll need to clear false positives and add them to your whitelist. A shorter block period in global settings will ease this burden – I use one day, but a couple of hours would probably be enough to make an attacker move on to an easier target.
Once this is accomplished, turn up the rules you want applied. Return to the Snort Interfaces tab and select the edit icon for the WAN interface. For many of the rules, HTTP Inspect has to be enabled. You’ll also want to normalize specific traffic for scanning as well as enable detection of port scans, done via the Preprocessor tab. These settings are pretty self-explanatory (Figure 10).
Figure 10: Snort preprocessor settings
We are now ready to select the rules that Snort will apply. From the Preprocessors tab, select Categories. If you performed the update correctly, the rule categories should be prefixed with Snort, ET (Emerging Threat), and pfSense. These are the rule sources; ignore any categories without a prefix.
A way to approach these categories is that there are three types: policy, specific target, and general target categories. The policy categories include P2P, Games, and Inappropriate – and allow you to block those types of traffic from your network. For example, you might enable the P2P categories on your Guest WLAN interface because of bandwidth or legal responsibility concerns.
Specific target categories are those where a particular protocol or software package can be targeted by attackers. These include protocols like SNMP, IMAP, and NNTP and software packages like IIS, Oracle, and MYSQL. If you are not running these protocols or software packages on your network there is no reason to enable those categories. Remember, the more categories you enable, the larger the performance burden. Additionally, the more categories you enable, the higher the probability of false positives and more of a network administration headache.
The General target categories, as I’m sure you’ve guessed, are general attacks on your network, for example denial of service attacks, web client, and the exploit categories. You’ll probably want to enable all of these.
If you are unsure of the type of the category, just click on it. This will take you to the corresponding rule set, where the rule descriptions should clarify the ambiguity. For example, are the FTP categories a policy or a specific target?
Once you’ve completed selecting your categories and saving your settings, you can now start Snort for the WAN interface from the Snort Interfaces tab. You can now be confident that you are protected against all sorts of nefarious interlopers.
You’ll find that it takes longer to set up Snort than it took bring up pfSense for the first time, but for the protection it offers you will find the time well spent.
IP-Blocklist
IP Blocking is another tool for securing your network, by preventing a user from accidentally inviting in players whose only interest is wreaking havoc.
IP-Blocklist is another pfSense package that blocks specific IP addresses and ranges of IP addresses from accessing your network. Common IP Address lists include known compromised hosts, spammers, spyware, and egregious advertisers – you can find all sorts of lists on iBlocklist.com, a clearing house for list maintainers.
Once installed and enabled, you’ll need to provide a set of URLs that point to the lists you want to use (Figure 11). Each URL must point to a gzipped file.
To do this you need to de-reference the URLs from iBlocklist. The easiest way to do this is to first download the list, then use your browser’s download manager get the URL to enter.
Figure 11: IP blocklist
Other Packages
Cerberus has several “lesser” packages installed (Figure 12). These provide mostly expanded monitoring capabilities and enabling identification of performance issues and possible intrusions such as traffic irregularities.
Figure 12: Other pfSense packages
Security Tips
It has been recently reported that routers configured and administered via a Web GUI can be vulnerable to “Man in the Middle” attacks. There are some basic hygiene steps you can take to prevent this from happening to you. These steps apply to any networking product that has a web interface.
- Change all the defaults to personalized values; change the default IP address from 192.168.1.1; change the default user from ‘admin’.
- Use a separate browser to administer and monitor your router. If you use Firefox for web browsing, use Chrome to administer your router.
- Use HTTPS instead of HTTP to access your router.
- Use a unique strong password (need it be said?)
- Unless you have a compelling reason to do so, do not allow for remote administration.
- Review your system and traffic logs from time to time, looking for any unusual traffic.
Conclusion
After installing my first pfSense router, I was surprised to see my network constantly under siege; packet after packet, scan after scan poking and prodding my home network. This converted me to a true believer in IDS as I became enamored with pfSense and its impressive capabilities. So this begs the question, why doesn’t everyone run one of these puppies?
It strikes me that that $400 dollars is not a lot of money to spend on an intrusion detection appliance that allows the user to be confident that the machines they rely on, on their home network, haven’t become zombified members of a global botnet.
If you look at commercial IDS appliances, you’ll see the price for this DIY solution is in the ballpark. But it comes without subscription prices, generally offers better performance and, as an open platform, is wholly extensible.
The next logical step for Cerberus is to add an LCD display to the front, for bandwidth monitoring and intrusion alerts. Both pfSense and the Antec case can support a nice display. Replacing the wireless bridge with the Asus PCE-N13 would also reduce the cable tangle behind the router. And maybe we’ll install Tarpit for a little fun…