Recently I was reading about one of the latest and greatest cyberthreats called VPN Filter which infects consumer grade routers with a nasty piece of malware (read more about it here), and I was pleased to find that my router is not known to be vulnerable. I don’t run a very normal router, after all, I run pfSense! That also got me thinking, however, that I had not yet fully tapped the capabilities of using pfSense as a home router / firewall, so I decided to spend some time enabling some more functionality that I had not yet gotten around to turning on. One of those features I was planning on adding was Suricata – and this post is about my first week running Suricata on my home network, and what lessons can be learned from that experience.
About My Setup – Why Run pfSense?
Let’s start with a little bit of background and talk about the different systems at play in my home network environment, but first let’s discuss why I set it up this way.
I will be the first to admit that this is not exactly your mother’s home network architecture (or my mother’s, for that matter). As a security professional dedicated to continuing to improve my craft, my networking needs are above and beyond most home users and even some small businesses. For example, my network currently has different segments for general traffic, as well as guest and lab networks that are completely isolated from other traffic.
Since VDA Labs operates as a distributed team it has been great to have a lab environment to use for testing IoT devices and working on configurations for our own equipment (such as our penetration testing dropboxes), within an environment that is separated from my every day home use. This lab also gives me the flexibility to practice penetration testing techniques, try out new software, or many other use cases that might not be a good mix with normal home network activities.
What is pfSense and Suricata?
So – what is pfSense exactly and why did I chose to use it? pfSense is an open source firewall / router distribution that is based on the FreeBSD operating system. You can run pfSense on commodity x86 based hardware, as a virtual machine (either locally or in the cloud), or on a purpose built device from pfSense’s commercial arm, Netgate. One of the really great things about pfSense is it’s ability to run modules that can add greatly to it’s ‘out of the box’ capabilities – one of those being the Suricata package.
Suricata is a network based IDS (intrusion detection system) that analyzes network traffic looking for indicators that match a set of rules to identify network traffic. Depending on the rule sets selected, you can look for many different types of traffic patterns – malware, gaming, file sharing, adult content, and more. The screenshot below shows some of the variety of rule sets.
So why am I using Suricata? On my unit I have enabled rule sets that will potentially allow me to detect any malicious traffic on my network. I want to know if there is some sort of infection or compromised system, and also just generally to gain more experience with IDS capabilities and monitoring. I have therefore selected rulesets such as those shown above which might indicate compromised hosts on the network, or other suspicious activity.
So – once I got Suricata installed and configured, what lessons were learned after the first week of use?
Tuning is necessary – the job isn’t done once you install
The first thing I noticed after enabling Suricata was lots and lots of noise in my alerts. The first alerts that flooded the feed were things like “UDP Invalid Checksum” and a few others that, while not necessarily good to see, were not of a high concern to me. These might be important to watch in a different environment, however I quickly added some “suppress” rules that hid these numerous and uninteresting types of alerts. My home SOC has only one, very part time, analyst, so it’s important to only see the more interesting alerts.
In this industry we like to think that we can buy a new piece of technology and it will suddenly work, fixing all of our problems like magic. That is rarely the case – often the work has only just begun when a piece of technology is brought online. Then there is the process of figuring out how the system works in practice, not just the theoretical value from the marketing sheet.
Once I got some basic suppress rules in place, I could actually start to see some interesting traffic!
Alert before you block – or risk self DoS
Suricata can function as either an Intrusion Detection System (IDS) or Intrusion Protection System (IPS). More precisely, that means it can serve as either a detective or preventive control depending on whether it is configured in ‘alert’ or ‘block’ mode. Many modern IT security systems can function in this way where it’s a hybrid of detection and blocking including Web Application Firewalls (WAF), Endpoint Defense platforms, and more.
The important thing to realize, however, is that escalating directly to ‘blocking’ is probably not the best choice. Running a new product in ‘Detect’ mode will allow you and your organization to get a baseline understanding of what is going on in the environment and what the potential impact of turning on ‘blocking’ mode might be. If I would have turned on blocking mode straight away, I know at least two different systems I use at home would have experienced some kind of interruption – that means a business with many many more systems would most likely experience the same. More details below.
Be prepared to investigate, and for false positives
The whole point of turning on an IDS, for me, is to find traffic that appears to be suspicious so that it can be remediated. But I must say – part of me was hoping that there wouldn’t be any alerts that required followup. That was not the case. Below is an example of a highly suspicious alert that ultimate proved to be benign.
This “Network Trojan” turned out to be a part of my stereo system that I use for streaming music from Spotify. The receiver, it seems, does some HTTP requests using a User-Agent string that matches against some known malware. Good thing I didn’t have blocking mode enabled, or I could have DoS’d my own tunes!
I spent half of my Saturday tracing down various alerts that popped up, both on the network level and within the various host systems on my network.
You will (hopefully) find what you are looking for
Once you have tuned the system, and have the ability to investigate alerts, you will eventually come across alerts that aren’t false positives – great! So what did I discover?
Oh sneaky! Suricata detected some outbound UDP traffic on port 53 – that wasn’t DNS traffic! The good thing is that I knew to be looking for this ahead of time as I have been working on some techniques for bypassing firewalls. Allowing UDP 53 traffic outbound would be a somewhat normal firewall configuration, however Suricata (using the ET DNS rule set) can identify when something unusual is happening. In this case I was running an OpenVPN connection through port 53, which was flagged as unusual. If you saw this sort of bypass on your corporate network, which was configured to prevent most outbound connections, it would definitely merit investigation!
The adventure has only just begun
Having an IDS system in place for a week has started to show some interesting information. More than that, I am seeing how I might be able to use it to test certain tradecraft. But now that it’s up I need to keep in mind that it’s still not a set-and-forget solution. There is more work to do when it comes to tuning, and I would like to create a dashboard for alert monitoring that pulls from other sources as well such as IP blocking and host based events. That will take more doing, but again – it should be worth the effort.