Protect All Your Home Devices From Malware & Hackers

We do a lot to protect our homes. After all, the home is meant to be our safe place, where we can find comfort and have privacy. To protect our safe place we have fences, locks on doors, alarm systems with sensors, surveillance cameras, and even video doorbells. Oh, and let’s not forget man’s best friend, guard dogs. We apply all these protections to keep our things, and more importantly, our family safe. Who doesn’t want to protect their home? However, with the volume of computers and consumer IoT devices we welcome into our homes, we’ve created a digital backdoor. Now we must protect our home from MALWARE AND HACKERS!

Okay, using all caps in that last sentence was a bit dramatic, but the threat from malware and hackers is real. What is also real is the volume of Internet-connected devices invading our homes, and the fact that most people do not understand or think about how to make their home networks secure. This is a problem, and where there’s a problem to be solved there’s a solution to be sold. There are several products in the market place that have answered that call. These products claim to protect against MALWARE AND HACKERS! I became curious about some of these products so I decided to try a few out to learn more about them and get a sense of what they had to offer. Specifically, I was interested in how they protect home networks from inbound malicious traffic from the Internet. I also took a cursory look at any additional features that would be beneficial in securing a home network. In this post, I’ll share my findings and opinions about these solutions.

Evaluation Approach

My approach to evaluating these solutions was very simple. I didn’t perform any reverse engineering or packet captures with deep packet analysis. My assumption is I should be able to observe sufficient protection against incoming malicious traffic with only basic testing. Just by connecting any device directly to the Internet it will almost immediately be scanned and inundated with various attack traffic (see examples of this traffic at HoneyDB). In a home network scenario, the device directly connected to the Internet is typically going to be your ISP’s modem (DSL, Cable, Fiber, etc). For testing, I deployed a honeypot (honeydb-agent) behind the modem and router to see what traffic gets through.

Also, as part of this evaluation, I’m assuming the use case for a non-advanced technical user. For example, you purchased one of these devices for your parents or grandparents. Not the uber-geek that likes to trick out his network or runs their startup’s server farm out of a basement.

The Devices Tested

The two products I tested were RATtrap and Firewalla. RATtrap is an in-line firewall solution that is installed between your modem and your router. Being in-line, it can inspect all traffic going in and out of your network. Firewalla takes a different approach. You plug Firewall into your router and it uses ARP spoofing to route all traffic to itself for inspection.

Test Setup

Below is a network diagram of the setup I used for testing. RATtrap on the left and Firewalla on the right. Nothing surprising here since I installed the devices as intended. However, you can also see where I added the honeypot.

Image for post
Image for post

Typically, and hopefully, by default consumer routers won’t allow traffic initiated from the Internet to computers or devices on your network. To expose the honeypot to the Internet I enabled the router’s default DMZ server setting to the honeypot’s IP address. This means all traffic coming from the outside will be routed directly to the honeypot. The honeypot was a Raspberry Pi 3 running Raspbian (Stretch) with the honeydb-agent installed. It was configured to listen with the following protocols and ports:

udp 7
udp 8
tcp 8
tcp 21 (FTP)
tcp 23 (Telnet)
tcp 25
udp 53
udp 69 (TFTP)
tcp 80 (HTTP)
tcp 389
tcp 502
tcp 2048
tcp 2223
tcp 3033
tcp 3306
tcp 3389 (RDP)
tcp 3625
tcp 4096
udp 5060 (SIP)
tcp 5900 (VNC)
tcp 6379 (Redis)
tcp 7001 (WebLogic)
tcp 9200 (Elasticsearch)
tcp 11211
tcp 19166
tcp 28448
tcp 55002

For each test I exposed the honeypot for about 24 hours. RATtrap has three levels of protection a user can choose from. These levels are Default, High, and Extreme (Experimental). Firewalla does not have the concept of different protection levels. As a result, I implemented four testing periods at 24 hours each.

Traffic Results

Being that these products are intended to be easy to use protection, I would expect them to block any incoming traffic from the Internet by default. However, that was not the case as you can see from the results below.

RATtrap — Default

The honeypot captured connections from the Internet for the following protocols.

RATtrap — High

In protection level “High”, the honeypot captured traffic from significantly fewer protocols.

RATtrap — Extreme (Experimental)

In protection level “Extreme”, the honeypot only captured traffic from one protocol.


The honeypot captured connections from the Internet for the following protocols.

Observations & Opinions

The results were a bit of a surprise to me. For a typical home network, there is no good reason for incoming connections via the protocols above.

Having said that…

Image for post
Image for post
Example blocked attacks data summary from RATtrap

Finally, I’d be remiss if I didn’t highlight that blocking inbound traffic is part of what these products do, but it’s not all they do. They also provide ad blocking and blocking of outbound traffic to malicious sites. This is the part that can help defend against malware when it tries to call out to command and control servers. This is also another area where more research on the efficacy of these solutions would be interesting.

Observations specific to RATtrap

Image for post
Image for post
Example attack data from RATtrap

Observations specific to Firewalla

Image for post
Image for post
Image for post
Image for post


With the premise of my testing, both devices did not perform well. Undesired malicious traffic of various protocols was allowed in and established connections to the honeypot. I also would like to see much more detail related to attack data from both devices. However, my narrowly scoped testing is not a fair assessment of these devices as a whole. It’s likely a typical user would not be as interested in detailed attack data but would be more interested in the additional protection features these devices offer. Specifically, outbound blocking on ads and other malicious traffic. After all, blocking outbound traffic can help to mitigate malware from performing malicious tasks or propagating on your home network.

Ultimately I find both of these devices to be useful. RATtrap is more of a solution that is set it and forget it — but also hope they do a good job at what they claim to do. Firewalla can also be set it and forget it, but it offers a more wide range of controls and features for the tech-savvy user. Either solution will provide broader coverage than just installing an ad-blocker or script blockers in grandma’s web browser. In the end, home networks are becoming more and more sophisticated with computers, mobile devices, and consumer IoT. It’s worthwhile to add a security device that can give grandma a fighting chance to help stop MALWARE AND HACKERS!

Do you want run your own honeypot(s) and collect data like this?

If you are interested in running your own honeypot to capture data and perform your own analysis, I have a few tools for you. HoneyDB is a community driven honeypot sensor data collection and aggregation service. Free to use, with the HoneyDB Agent and HoneyDB data collection anyone can easily run their own honeypot. For more details on getting started, go here.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store