3

Among community rules and registered rules, all are "alert" type rules only. Since there are more rule types like log,pass,activate,dynamic,drop,sdrop available , snort official rule sets use only alert type. Why other type of rules are not included in the snort official rule sets ?

1
  • Is there any specific reason behind it to use only "alert" rule in all snort official rule sets? Commented Oct 6, 2016 at 11:09

3 Answers 3

1

Is there any specific reason behind it to use only "alert" rule in all snort official rule sets?

It's a safety precaution. Defining all matches to alerts allows snort to be initially installed without causing problems for your users.

Imagine you're on the network team that's set up snort for the first time in your organization. Suddenly your app team is getting calls that the website stopped working! Nobody would know why, and it would be a big emergency. Eventually, we can hope that someone would be clever enough to break out Wireshark, and discover these strange RST packets coming from the new snort box. When you went to investigate why, you discovered that there was a snort rule that matched one of your existing packets and it was configured to reject, which killed the legitimate connection. People in your organization would be very unhappy with you.

By setting them to alerts first, when you install snort your organization will not be impacted. Of course you can (and should) investigate all the alerts you see. You'll see that some of them will likely be false positives - had any of those been configured to reset the connections or drop the packets, snort would have been the cause of a catastrophe.

The converse is also true. By not setting them to log only as a default setting, they also are being cautious about not allowing actual malicious traffic to be ignored.

The idea is that when you turn on snort, you'll suddenly get a bunch of alerts as part of your normal traffic, and you will have to evaluate them all. Most will have safe explanations, and you can choose to pass on those; some will be kind of weird and you may choose to log them. Some may be legitimate alerts of data that you want to drop. And anything else you discover, well, that might be really bad traffic you don't want on your network, so you set those to reject.

1

"Alert" type is the default one that can be used if you want to generate that kind of event when the signature matches. Based on your need, and to customize the use of the application, you might want to not be alerted all the time, for example.

You might want to set "log" type for some rules that might be too noisy, so that you can analyze them once a day, with some analytic methodology.

1

Well, ALERT is the default rule actions. It is more a best practice issue to use ALERT as the rule actions for the community rules and registered rules. No technical reason behind it up to my knowledge.

Here is why? The other rule actions options are really user-specific. You will only use them to achieve a specific purpose or reach a goal specific to your network. The community rules and registered rules are also general purpose rules most likely you will end up customizing them.

In addition using the other rule actions without really understanding how they work could be harmful especially for people who are new to snort. For instance, Why would you have a rule with a log or ignore actions in the default rule set? This could be the desired behavior in your SNORT deployment but not for others.

You must log in to answer this question.

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