Suricata as a NSM

Help
1

Hi.

I am currently running Zeek and Suricata. I treat Zeek as the NSM and Suricata as the IPS/IDS system. I see companies like Corelight is using both, but Stamus only uses Suricata.

In the forum there is some mention of Suricata as a NSM, but I can’t find it talked about in detail. I go through the Suricata.yaml configuration file and see the different protocol analyzers for the common protocols. What functionality is missing compared to Zeek? If it can do all of the NSM functionality why isn’t it highlighted. I would much rather have a single tool to focus on.

thanks,
Geoff

2

Suricata indeed do offer competent NSM functionalities, it all depends on what you are looking for in an NSM, protocol classification and metadata extraction? It is there, file extraction? Pcap logging?

3

Yes, indeed Suricata has powerful NSM capabilities. At my company, we leverage these quite extensively in our commercial solution.

Here are links to a few articles that describe these Suricata capabilities: The Other Side of Suricata
Suricata Myth Busting: Alerts and NSM

And this book (available as a free PDF) - “Security Analyst’s Guide to Suricata” - has several chapters (look at 3, 7, and 9) dedicated to some of these NSM capabilities: Suricata for Analysts - the Book | Stamus Networks

4

Hi Mark.

Yes. I have looked at the articles and books you referenced, plus tons of the videos from oisf on youtube.

Why does Corelight have both Suricata and Zeek in their stack and Stamus only has Suricata?

thanks,
Geoff

5

Hi @IDSTower

Is there something that is missing in Suricata that Zeek has?

I am building my cyber stack. Right now I have been working with both of them. If I can do a deep dive on just one, that would be way easier.

thanks,
Geoff

6

Yes, among those differences that comes to my mind:

  • shared state between hosts in a zeek cluster, Suricata lacks this and every Suricata host works independently, while in Zeek, you can share state that facilitate detection logic between different hosts.
  • zeek has a scripting language that allows you to br more descriptive in your detection logic beyond what Suricata rules language offers, it also allows you to “extend” Zeek functionality.
  • Suricata has its rule language and library of tens of thousands of rules both free and commercial, this is absent in zeek and it is the biggest advantage IMHO.

Why corelight uses both Suricata and Zeek? I think part of it is historical reasons, zeek/bro was better in protocol metadata extraction and the creators of the company were involved in Zeek development.

Today, Suricata is as good for metadata extraction (NSM).

Since you are building your stack and the requirements are not fully clear for you, I recommend that you use Suricata as a start and see hoe far it can fulfill your needs.

1 Like
7

thank you @IDSTower

I have both installed, because that is what the common configuration is.

There needs to be more written about Suricata’s features beyond being an IPS – even forum threads like these will help.

I was learning the Zeek scripting language, but now that I know Suricata can do pretty much everything that simplifies things. It is easier to do a deep dive on a single tool.

8

I concur with IDSTower.

Corelight includes both Zeek and Suricata for historical reasons. They only recently added Suricata to their platform - my guess is because their customers requested it.

Unfortunately, running both Suricata & Zeek is unnecessary, inefficient, and less effective. Running Suricata along side the Zeek engine is completely unnecessary given that Suricata can extract all the same network data that Zeek can. And external correlation between the Zeek logs and Suricata alerts does not work for all use cases and requires separate processing, placing a massive drain on resources.

So, given that you are starting from scratch, you would likely benefit from a pure Suricata approach - especially if you are running in a high performance environment.

9

Hello everyone,

I’m wearing my NSM hat, not my Corelight hat. :slightly_smiling_face:

In my experience and definitions (1998-, first book content in 2002) NSM involves four types of data derived from the network:

  • alerts
  • transaction data
  • full content
  • extracted content

Traditionally, operators have achieved collection using a stack like this:

  • alerts: Snort or Suricata
  • transaction data: Zeek, or in a pinch Argus or custom code
  • full content: Daemonlogger or some other pcap writer; even Tcpdump in a ring buffer mode works
  • extracted content: Zeek or custom code

I strongly disagree that “running both Suricata & Zeek is unnecessary, inefficient, and less effective. Running Suricata along side the Zeek engine is completely unnecessary given that Suricata can extract all the same network data that Zeek can. And external correlation between the Zeek logs and Suricata alerts does not work for all use cases and requires separate processing, placing a massive drain on resources.”

Suricata “cannot extract all the same network data that Zeek can.”

I have never seen a “massive drain on resources” in any implementation that I have designed and run, at whatever scale, if you mean analyst resources. If you mean technical limitations of the code, then that is one of the reasons commercial vendors have an opportunity to help customers. Running all this code at high bandwidth is a challenge.

I, my colleagues, former students, and customers get a TON of value running Suricata and Zeek together. Suricata is the default rules language for alerts, never mind its other capabilities.

Ultimately it’s up to the analyst to decide what SORTS of transaction data you want. Some may just need what Suricata can log. Others might need different data.

Also, as IDSTowever mentioned, Zeek provides a network-oriented language that devs use to write their own packages. This greatly extends what Zeek can do and is again a nice complement to Suricata.

I have always seen this as an AND situation, never an OR situation.

Sincerely,

Richard

10

Point taken, we need some stronger messaging here. We do try to point this out on our home page without calling out NSM directly: IDS alerts, protocol transaction logs, flow logging, full packet capture, and file extraction are highlighted on the main home page, https://suricata.io/, but we need to do better at messaging on what we think IDS is these days.

There are some good arguments in this thread, and while features overlap between Suricata and Zeek, there will always be features distinct to each tool that may warrant running the 2 alongside each other.

Something I personally see and hear still with respect to Suricata is the need for an additional tool for the connection or flow log, and perhaps some passive DNS, or TLS certificate/SNI logging. However, Suricata is able to provide all this with a default install, which goes back to the messaging.

1 Like
11

Having done this build out you aren’t going to find a single tool that will accomplish everything, which is probably why both are included in some setups. You should look at deploying Arkime(https://arkime.com/) with your suricata instances as well. They also have a plugin that will tag traffic with the alerted SID allowing you to search based on just the identifier. This will also give you some context of interactions before or after a signature alert was matched, which becomes useful when you have flow bits set on any rulesets.

Suricata also allows you to copy the monitored traffic through the copy-mode:tap settings under af-packet settings. I have a few sensors setup to receive the traffic feed then use another network interface on the box to copy traffic to another arkime node.

To extend your network security monitoring you can also look at https://ids-hogzilla.com/. This is an anomaly based IDS which differs from Suricata which is signature(SID) based.

12

Thanks for mentioning Hogzilla. Am I correct in noticing that it basically analyzes sFlow? And that it has a Snort alert analyzer under development? TBH I’m surprised that in 2023 there are still projects that obsess over simple flow records. Apologies if it’s just something on your radar and not a tool you’ve tried.

Sincerely,

Richard

13

Hi Richard,

My usage of hogzilla was mostly in a VM as a troubleshooting/investigative tool, however reviewing the project it appears that it may not be as active as it was previously on the open source side. I can see sFlow being the primary input for this as its anomaly detection through statistical analysis. They had a section of reference papers, wether those are what Hogzilla is based on or not i’m not sure.

Most of what I used hogzilla for I’ve replaced with Jupyter+scikit+pandas+seaborn. I have looked at getting https://openargus.org/ setup for a more automated collection and processing.

OpenArgus maybe the better suggestion here in-place of hogzilla.