Protect All Your Home Devices From Malware & Hackers

Photo by Lorenzo Herrera on Unsplash

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.

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.

• DNS (UDP)
• Elasticsearch
• FTP
• HTTP
• RDP
• Redis
• SIP
• Telnet
• VNC
• Weblogic

RATtrap — High

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

• DNS
• SIP
• TFTP

RATtrap — Extreme (Experimental)

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

• TFTP

Firewalla

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

• DNS (UDP)
• HTTP
• Redis
• RDP
• SIP
• Telnet
• TFTP
• VNC

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…

• The only reason that could possibly justify this is the classic balance of security vs usability. Or in other words, in case an advanced user wants to allow traffic in, we choose not to block so we don’t have to deal with support requests — or build a port management feature into the product.
• While the products didn’t block these ports/protocols, they did report on blocking traffic on other ports. So it’s possible those other ports are known to be associated with malware, and the products use that as a basis for selective port blocking. More research on that would be needed to confirm.
• If the user is not intentionally opening ports on their router, then perhaps malware executing from inside the network would. Otherwise, my theorized selective port blocking is pointless because it would likely never be a risk. No port, no risk. But this also begs the question, why not block all incoming traffic.
• Interestingly enough, or not. The dashboard displays the count of thousands of attacks that make it seem like these attacks would have got you had the product not been present.

Example blocked attacks data summary from RATtrap

• Another observation is the amount of data they are collecting. Certainly, the idea here is customer’s security will benefit from all the data they collect, and from the machine learning they apply to it. However, I can’t help but think about how much they can profit from selling the data, and their customers are paying them to collect it. Note, I’m not judging this as a good or bad thing, I’m just stating my observation of it.

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

• Install was very easy. Instructions here, however, there are a few more steps to register a login with the portal. The portal or mobile app is where you can manage configuration.
• While implementing the Extreme level significantly reduces the mount of allowed inbound traffic, this level caused some other observable issues. This included blocking some video streaming, and blocking access to various web sites. In one example, I was blocked from one of my own domains that uses Cloudflare CDN — the device was blocking Cloudflare IP addresses. However, the Extreme level is labeled as experimental, so aggressive blocking is not unexpected.
• One of the bigger issues I have with RATtrap is the lack of transparency into the actual attack data. Now, a user like grandma might not care to see those details, but certainly, I was. The only information provided about an attack is the source IP address, destination port, city, and country. Note, for outbound traffic blocks the same limited information is provided.

Example attack data from RATtrap

Observations specific to Firewalla

• Install was very easy. Instructions here. However, the process does require the mobile app and takes a little longer than RATtrap did.
• Firewalla actually identifies all the devices on your network, which gives you the ability to disable monitoring for specific devices if desired. Note, the identification of devices on your network is part of the reason why the initial setup takes a bit longer.
• Firewalla provides a bit more details on blocked attacks than RATtrap. For instance, it can tell you which device on the network was targeted when the block occurred.

• When displaying attack details, it will also display a summary traffic history — example below.
• Firewalla will indicate if it detected the attack as a brute force attack. See the title “SSH Password Guessing” below. Otherwise, it uses the label “Security Activity” — example above.

• Firewalla has a handful more features that might be useful to a more savvy user. These features include a VPN Server, family protect, DDNS, monitoring for ports being opened via UPNP, and social networking site blocking.

Conclusion

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.