Protect yourself on public Wi-Fi networks

By Ulrich Lang

Home|Protect yourself on public Wi-Fi networks

Firewalls come in many forms and often do not offer enough protection. In this blog post I describe a little project I’ve done to see how we can use a hardware firewall with Suricata based intrusion prevention in a somewhat portable way. Paranoid or necessary? I’d say necessary, considering the myriad of attacks that can hit you over any network.

I really wanted a solution that protects as well as being on our intranet, but without a major performance hit on my computer. This ruled out sticking a firewall in a VM and forwarding network traffic through it – in which case the computer would need to run the firewall, and the computer would still be exposed to the network directly.

The firewall … small but cool!

I have used pfSense before with good success. pfSense is a popular open source firewall that supports a range of features such as Snort, Suricata, pfBlocker, VPN etc. However, Snort/Suricata usually require a good amount of hardware to work fast enough for inline blocking. I decided to give the Netgate SG-1000 micro firewall a go – looked like a pretty cool gizmo to play with. Not cheap at $149, but you also get 1 year of pfSense Gold membership and the pfSense book with it.

The hardware is an single-core ARM processor and here are two 1GB ethernet ports. It also has an OTG USB, and comes with a 2.5A 5V power supply. The box is very small, somewhere between a Raspberry Pi and a Raspberry Pi Zero. The reviews online were so-so, stating that the hardware simply isn’t powerful enough to run this firewall effectively. Well, there was only one way to find out…

firewalls are just not cutting it at all

Out of the box the firewall on FreeBSD does not come with any installed packages. However, I really wanted to use Snort or Suricata with logging and blocking, because without an intrusion detection based feature, firewalls are just not cutting it at all. The reviews online said it cannot be done, and Netgate themselves recommend against installing Sort and Suricata.

Well, turned out Snort ran quickly and then the firewall “died”, with the CPU perpetually being at 100%. I uninstalled and installed Suricata, and after some back and forth, it actually worked. The way that worked to turn it on was to install the package, then configure it, then reinstall the package, which takes a couple of minutes. After that Suricata was on. Success 😉

This may come as a somewhat of a surprise to cybersecurity professionals – Suricata usually beats Snorts on multi-core CPUs but requires extra overheads to do that. So on a single CPU I would have assumed Snort would be faster. Oh yes, and it only runs on the WAN interfaces, not on the LAN interface. I tried to set it on both but something fails – it seems the CPU cannot handle the “double burden”.

The Wi-Fi workaround

The next challenge was to enable wi-fi. I wanted to use this little firewall in our Raspberry Pi R&D cluster, but also when using public hotspots. Turns out it doesn’t come with Wi-Fi. And BSD is known for being not so hardware friendly. I found a spreadsheet of wi-fi dongles supported by pfSense but wasn’t convinced that any of them would work on an ARM port of BSD and pfSense. So I ordered two dongles, including an old one that is known to work with FreeBSD. Well, turned out not old enough, apparently the vendor changed the chipset at some point without changing the model number, and there was no way to track down “revision A1”. After some playing around, I gave up and contacted Netgate, who said that they are not sure any wi-fi dongles would work with the hardware and OS. I am sure I could have eventually made it work but it would have been a complete time sink…

Plan B

“Plan B” regarding wi-fi was to just use a small wi-fi bridge and plug it right into the firewall. Turns out those are cheap and plentiful, so I bought one with OpenWRT pre-installed for $40 on Amazon. The particular model I bought (Gl-Inet) was a bit finicky, at first it wouldn’t store its settings (incl. stored wi-fi SSIDs/passwords), but after some factory resetting and other playing around it did it. Pretty nice hardware for $40, and runs off a normal 1A 5V USB. The SG-1000’s OTG USB adapter provides enough amps to power this device, so you don’t need a second USB charger for it. As a side-note, this device provides an extra layer of security, but adds another device to the setup. Anyway, setting up wi-fi this way was of course trivial and works well.

The verdict? Yes it works.

So it works and the performance is definitely fine for a single computer behind the firewall. I do’t think the hardware will scale much beyond that though – when rapidly opening browser tabs, the CPU hits 100%. However, I did not find any noticeable performance hit, browsing, email, cloud uploads/downloads worked fine. Even video Skype worked just fine (79% CPU as shown in the screenshot). This setup definitely provides very robust firewall protection when using public networks.

The final setup looks like this: there are a bunch of cables, and you need a power plug to power the devices. I’ve used an USB to ethernet adapter to plug my laptop into the firewall. It is nice that the wi-fi bridge tries to connect to known networks when booting up. This way the setup is zero configuration when started up – you just need to wait, and after 1 minute or so, you have “ethernet” (from your computer’s perspective) on your computer.

I hope this helps you protect yourself. And please contact ObjectSecurity if you have any questions or comments.

 The icing on the Cake – OpenPMF Security policy management for pfSense

If you want to manage access policies for this setup consistently with other access policies, our OpenPMF 4.0 Security Policy Automation product supports pfSense firewall rules. The following screenshot shows imported rules. The interfacing is not seamless (yet though), you will need to upload your firewall’s config.xml into OpenPMF (this is easy using the web file uploader that comes with the importer), and after changes you will need to install the changed config.xml (you can upload this in Backup/Restore in pfSense’s web interface, or just SSH into the box and SCP the file over.

By |November 21st, 2017|