Suggestions/Options for open source IDS sensors on commodity hardware

alias454

I am wondering what people are doing in the way of open source IDS sensors on commodity hardware/VMs. I have been looking around recently and find that there a lot of options with no clear choice. So far, the undeniable star is Snort but then I have been reading a lot about Suricata too. Expanding on that, there is OSSEC, which appears to be able to feed data into Snort(I assume it could work in a similar fashion with Suricata). I see there is another product named Sagan that performs a similar function as OSSEC.

Snort and OSSEC are both single threaded where Suricata and Sagan are multi-threaded. OSSEC clearly has Windows agents where I have not been able to find mention of Windows support on Sagan in the form of an agent other than an article discussing using cygwin (no way thats gonna happen). I don't know how important the local agent is to me but I can think of some benefit but it isn't a deal breaker.

It seems there are several frontends for Snort. The two that seem the most popular are Snorby and Sguil (my opinion is only based on the number of times I see those two mentioned), From what I gather, Snorby and Sguil can also be used with Suricata. Then there are a few of what I will call correlation pieces, which are SEC, OSSIM/USM, and Aanval, of which, both OSSIM and Aanval offer a limited "free" version. Do you still use something like Snorby/Sguil if you are going to use something like Aanval?

I already have a significant logging infrastructure built on rsyslog, Graylog, and Elasticsearch so I would like to leverage that as much as possible where it makes sense. There are about 250 devices sending in logs with the expectation of adding in another 50-100 endpoints in the coming months.

Correct me if I am wrong in the way I think this should work together. Basically, logs and information from endpoints funnel into OSSEC/Sagan directly or route from the rsyslog server and data from the network would flow into multiple Snort/Suricata sensors. This is where it gets murky for me, then data from OSSEC/Sagan(?) can be sent to Snort/Suricata(?)(for processing, storing or both?) or is that only if you use a frontend like Snorby/Sguil. Do you do that if using something like OSSIM/Aanval?

I am just starting to scratch the service with this and it's starting to feel a lot like I did when looking into logging stacks. Does this pretty much sum up the current open source IDS field or are there other pieces I am missing?

Regards,

Matt2

The answer is Security Onion. It's what I use for our PCI and non PCI environments.
Security Onion
https://security-onion-solutions.github.io/security-onion/

Security Onion is a Linux distro for intrusion detection, network security monitoring, and log management. It's based on Ubuntu and contains Snort, Suricata, Bro, OSSEC, Sguil, Squert, ELSA, Xplico, NetworkMiner, and many other security tools.

You can feed other logs into it too.
Forum: https://groups.google.com/forum/#!forum/security-onion

alias454

Thanks I have seen security onion and have downloaded the newest release. I assumed it was meant as an eval ISO since it had so much stuff on it, which I had planned to do. Can you explain a little bit about how you are using it? I would be curious about the hardware you are running it on, what type of capture speeds you can get, and how many sensors deployed throughout your enviorment.

chrisone

+1 on Security Onion

I plan on implementing a box sometime toward the end of the year after I get a good understanding of Security Onion. Aside from the online tutorials and youtube, this book is pretty much dedicated to SO.

Robot Check

^ not sure why it shows up as robot check, but the book is called

The Practice of Network Security Monitoring: Understanding Incident Detection and Response

wes allen

SO is pretty cool, but it takes some heavy duty hardware to run on a production network.

I am a big Suricata fan = output to JSON and send to Splunk or ELK. You can log a bunch of data - not just alerts. We capture all DNS, HTTP, TLS, and flow traffic with it. Sorta like Bro light. We also run Bro, but mostly for the scripting - like we pull down the free critical stack threat intel feed.

alias454

I spun up the security onion VM tonight and was pretty impressed at how easy it was to get going(even though it runs on ubuntu but that's for another thread ). The problem I have with bundled instances like this is when push comes to shove, I don't know exactly how the pieces fit together. SO is definitely worth playing with and studying but my preference is to put something together from sources. With that said, I have some reading to do and look forward to additional feedback/comments from members.

@Wes, initially I would be looking to setup a span port on our firewall to the internet, which is about 3-4 GB's an hour for traffic.
I am also thinking the components that will be used are Sagan, Suricata, and Aanval. However, I can't actual be certain until I build out my lab and do some small scale testing. My log lab proved my initial inclination to use ELK wasn't going to work for my needs so I ended up going with Graylog instead.

Besides reading, where can someone gain experience with these kinds of things? While hacking stuff together and figuring it out is fun, it is definitely time consuming.

Regards,

wes allen

For a pipe that size, SO should be OK. I had an 8 core / 16gb ram server class sensor running SO that would fall over within 15 minutes of sending traffic to it. But, that was a heavily utilized GB link.

You might also try Splunk (may be able to get by with the free version?) there is a Suricata App that I helped out a bit with, so it will extract the JSON output for searching and dashboards.

You might also look at FlowBAT - a pretty cool project to make SiLK easier to use.

Mostly, you just need to start working with it. You might also look into SANS Sec511 or 503.

Matt2

I have deployed 3 standalone instances at appropriate locations in our Networks (2 in DC and 1 in office). Call it 8 core 16 or 32GB of ram and 1-4TB of disk space depending on location. For the most sensitive areas I keep all the full packet capture data for 60-90 days. For less sensitive a month is fine with me. The database of events retains data for a year (required for PCI compliance).

You of course need to properly size your hardware to meet the network size.

Hardware requirements here, and Doug and others on the forums are very helpful too. https://github.com/Security-Onion-Solutions/security-onion/wiki/Hardware

alias454

Thanks. I picked out my reading list and it is almost 200 bucks! Granted I won't purchase them all at once but dang.