Security Monitoring At Home With the Raspberry Pi (Part 2)

Welcome back for the second part in the series. This is the post where I’ll be evaluating options for
building my monitoring solution. Let’s get right to it!

Raspberry Pi NSM


First Impressions


The first solution I looked at is the Raspberry Pi NSM build over at SneakyMonkey.net, the InfoSec
blog from UK Security Analyst Mark Robinson. The article I would be following to implement this
solution is his from the above title link. He based that project on SweetSecurity by Tripwire's Travis
Smith. I love most of the elements presented here, primarily ease and speed of setup. Basically once
you have all the required materials, and have Raspbian installed on your Pi, run the provided script
and you’re ready to start creepin all that beautiful (and not so beautiful) traffic! The rest seems to be
customization to add more functionality and improve performance. This solution seems
well-considered and adds a ton of functionality that should really come in handy (particularly if you’re
not looking to write a lot of your own detection rules at the moment).




Elements Included

-Zeek (formerly Bro) IDS protocol analyzer
-Netsniff speed optimized full packet capturing daemon
-Loki for file scanning using customizable YARA rules
-Critical Stack for threat intelligence/information
-(And the Team Cymru Malware Hashing Registry, default for Zeek/Bro)




Pros
-Meant to run on the Pi, so it should work smoothly
-Includes ability to send alerts by e-mail
-Active IOC (Indicator of Compromise) subscription and scanning ensures checking for the latest
threat indicators


Cons

-NIDS (Network Intrusion Detection) only. Doesn’t monitor host logs. Would eventually like to have
HIDS (Host Intrusion Detection) send data to my monitoring solution.
-Solution requires either a network tap or a mirrored port/span port on the router/switch in use at the
network. Either way this will most likely require a purchase. The options for network taps don’t cost
much, and I found one in particular for only about $40 US. Not too bad, but my objective here is to
see what can be done with just the Raspberry Pi and a pretty simple home networking connection.

Raspberry Pi Snort Sensor


Impressions

This method aims to install Snort on the Raspberry Pi and get it to send traffic alerts to a configured
AlienVault SIEM running on a system in your local network. The guide I would use is the one by
Joseph DePlato. This article was written some time ago, so it might need some adaptation in terms of
possible changes in the packages it advises that we use, as well as links that no longer work.
Additionally, if you read the first article in this series, you’ll see that I ran into an issue where the
software originally intended for use no longer supports the ARM processor the Raspberry Pi uses.
Something like that is always a possibility too.

I like the idea of using Snort for IDS because it’s well known, widely adopted, and there’s a ton of
documentation online to help learn more about its use and functionality should we run into issues.
One possible downside is that in researching this project I found that a few sources noted that the Pi
isn’t powerful enough to run Snort well. I’d still be willing to try it, but I do tend towards trying for the
solution with the best chance of success. I have Raspbian installed on my Pi already, and I suspect
that many others who might follow this guide do as well. For that reason, I’m not a big fan of the fact
that this article expects that we use Kali Linux as the Pi’s operating system. The author has good
reasons for doing so, namely that Kali already contains a majority of the packages needed for the
project, thereby avoiding “dependency hell” -- That’s the situation where you end up having to install
a package, and it has dependencies (or packages which it depends on), and those dependencies
have their own dependencies, etc. Not pretty, but you can get through it. Personally, I’d prefer that to
the pain of having to reinstall the OS. A big part of this solution is using the AlienVault OSSIM
(Open Source Security Information Management) system. Having a full-featured SIEM (Security
Information and Event Management) system goes a long way towards threat hunting and correlating
events to find malicious activity.


Elements Included

-Snort as our Intrusion Detection System
-Syslog to send logs to the AlienVault OSSIM
-AlienVault OSSIM for analyzing the information that comes in



Pros

-Tried and true IDS Snort has lots of support to be found
-Included SIEM component is very polished and there is lots of educational material to help with
learning to use it for threat characterization and analysis
-Allows for eventually setting up a HIDS on each of our desired hosts and having that log info sent to
the SIEM for analysis. In fact, it’s possible that our Pi-only solutions here might not work due to the
fact that the device might not have sufficient visibility without the network tap or port mirroring
functionality.
-Snort has rules that update, though you can write your own detection rules based on threat
intelligence as well.




Cons

-Snort only uses one processor core. It’s possible that Snort might not run very well on the Pi.
-The AlienVault OSSIM software is intended to run on a virtual machine in the cloud. If you run it
locally, you’ll need either an extra computer that runs it constantly or a cloud VM, which could be
expensive.

Home Intrusion Detection (With Suricata)


Impressions

I like the fact that this solution is very simple. A great rule to keep in mind is that solutions should be
only as complex as required to accomplish the objectives of a project. This minimizes the number of
different things that can go wrong and helps speed troubleshooting later. The only distinct component
of this plan, aside from Linux and the Raspberry Pi, is Suricata itself. Suricata is an open source
IDS/IPS (Intrusion Detection and Intrusion Prevention System). While Snort focuses on finding
suspicious network traffic, Suricata is application aware. In fact, Suricata has the ability to extract
complete files from HTTP traffic for analysis, which is pretty awesome since you may not always
have immediate access to the machine that might’ve downloaded a malicious file. Provided by
Sothis’ Christopher Domingo: https://www.sothis.tech/en/detecting-intruders-at-home-ii/

Another great consideration, is that Suricata is multithreaded. That means that we’ll be able to take
advantage of the Raspberry Pi’s four cores. With only 1 GB of ram, I think that additional processing
capability will come in handy.



Elements Included

-Suricata IDS/IPS



Pros

-Simplicity
-Application layer aware Suricata
-Suricata can integrate with SIEMs such as AlienVault OSSIM
-Suricata includes functionality to keep detection rules updated
-Suricata is Multithreaded



Cons

-This implementation plan doesn’t seem to include the extra functionality of the others such as a
SIEM
-Doesn’t seem to have provisions for collecting logs from HIDS if we should wish to install them on
endpoints later. This could be a big one if it turns out that our Raspberry Pi isn’t able to see all the
network traffic.





RESULT

In the end, I decided to go with the Snort sensor solution. I suspect that I might be able to
place
the Raspberry Pi’s NIC in promiscuous mode to view the Wireless traffic and solve the lack of
a network tap or port mirroring/span port for it’s internet connection that way, if I don’t get the
desired results, I’ll have to fall back to a solution that is a log collector and analyser. That way
I can have the host systems send their logs to the AlienVault OSSIM for analysis. The obvious
drawback here is that I will need either a spare computer to run the OSSIM on a resource
intensive VM, or a VM running in the cloud. I’m willing to that in exchange for the wealth of i
nformation analysis the OSSIM will provide, as well as the fact that this particular approach
will help me improve my skills working with the same technology I use in the SOC I work in as
a security analyst.

That said, I certainly might revisit the other options in the future. I’m especially intrigued with
the application layer monitoring of Suricata, and the file monitoring and hashing solutions
provided by the first article. If and when I do examine those solutions, I’ll be sure to do a write
up of my implementation, and post the link here.

The last post in this series, Part 3, will describe my experiences implementing the solution I
chose in detail. Since personally, when I read instructional blog posts, I often have little time
and want to get to the meat of the instruction rather than read a lot of discussion and
background (until I have the time to check it out later), I'm going to write that article in such a
way that I present only the absolutely necessary steps I followed first (including the
need-to-know parts), then circle back and discuss any issues I ran into, as well as choices I
might have made during the process. It shouldn't be too long before I get started writing that
post, but I really want to get working on my very next post where I examine the forensic
failures which led to the wrongful imprisonment of experienced ethical Uruguayan security
researcher Alberto Hill, based on the fact that he reported a security vulnerability which
someone else later compromised. We'll be looking at what it would have taken to reasonably
prove he sent the incriminating e-mail the case centered around. Hope to see you back!





Comments

Popular Posts