5

I just started using Snort. There is a lot to it. I'm just looking for better documentation of what some of the Snort rules actually mean -- i.e. How I should react to them when I have an alert for a given rule pop up. It seems that the Snort docs, examples, and forums assume a lot of esoteric network security administrator background knowledge that I appear not to have (yet).

For example, I found this:

https://www.snort.org/rule-docs/119-3

However that section of the Snort website is woefully out of date and the search part doesn't work, and 404's pop up when I manually input many of the rule ids I'm interested in.

Example, for the stream5 preprocessor:

The second one, "129:12", has a text description of "Consecutive TCP small segments exceeding threshold". What does that even mean? In what way is that indicative of a problem? I examined our network, and there's only acceptable network activity (that I could tell). During an event where Snort was very verbose about this particular problem (on the order of 100 messages per minute), the problem was traced to authorized traffic passing out through our squid proxy.

So what, should I just suppress all of these messages? Is that a normal way to tune Snort? Just suppress the noise? That strikes me as crazy... If I suppress all these messages, what if there are messages of this class that actually indicate a problem?

I hope you get the idea.

Currently I am using pulledpork to assemble rulesets, and suppressing noisy rules via suppress directives in threshold.conf.

Lastly, I should mention that I'm running Snort in a fairly non-conventional way, as a workaround to satisfy IDS requirements for PCI, while running in the AWS cloud. Long story short, we have Snort running on all boxes that we classify as "edge" boxes, and are sniffing traffic on those. I'll provide more detail if requested, but that doesn't change the basic gist of this question.

Improve this question

1 Answer 1

Reset to default
3

You're encountering one of the most basic issue with pretty much ALL monitoring system: how to handle the data generated properly and separate the signal from the noise.

Unfortunately for you, there is no easy answer because it all depends on your what your resources are and the value of what you're protecting.

Let me be more specific: if you're working with a small, high-value network and have plenty of (competent) people to handle the task, you can leave all alerts on and investigate all of them completely. That is obviously very expensive and you need highly trained people (and probably very smart software) to be able to handle it correctly.

On the other hand of the spectrum, if you have a large, low-value network with few people available for incident handling, then you could decide simply to log everything and only investigate issues that are explicitly flagged as incident through a different channel ("Who changed the password of the CEO's email?"). Your IDS will still be of value to you because you can use the logs for some post-mortem analysis of an incident but it will not allow you to react proactively.

Most networks falls in between these two extremes so you're supposed to create alerts that match as closely as possible your actual threat level and response capacities. That takes time and it's a process that should be continuous: you'll have to adjust your rules to react to new threats, changes in usage or in capacity all the time.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .