IDS Rule Descriptions

[smajor]

Hi all,

Is there a better description of the IDS rules? All the info buttons go to here: http://doc.emergingthreats.net/bin/view/Main/EmergingFAQ

...and that's fine, great descriptions of the obvious ones, but there are many more rules available than the generic descriptions listed there.

Some are self-explanatory or subsets of the lists on that page, which is again, easy.  Others I just don't have a clue about.

[franco]

I've worked with ET in the past, shifting through the individual rules and I must say there is no conclusive documentation or explanation for the sets.

One of the things that have been useful was the individual rule history:

http://doc.emergingthreats.net/2006434

And the changelogs provided:

http://www.proofpoint.com/us/daily-ruleset-update-summary

But those are both completely technical and won't help assess scope or motivations for individual rules.

There is a varying degree of usefulness within the rules and rule sets. To me it seems like every org needs an "expert" who will take care of ruleset tweaking, which becomes an art for and may very well end in tweaking for performance.

TL;DR: Can't help much here, sorry.

[interfaSys]

I agree with Franco, there is a lot of research and experimentation to be done on each rule to be able to decide if an alert should be turned into a drop.

[goodron]

I am rather new to all this and have spent a rather mixed few evenings looking through some of this myself. You could almost do with a set of enablement templates under one or two drop lists? For say [all off], [recommended analysis], [thorough analysis], [full analysis], [recommended blocks], [thorough blocks], [full blocks]. Much better range of labels could be used I am sure.

I wonder also if there is way finding sums of community preferred / recommended switch options for certain rule sets, to limit false positives and/or for use on hardware of lower or higher perfomance. It would certainly reduce the setting effort involved. Leaving individual users to tweak odd settings.

It's not clear to me how the logging works here, when logging you get a result, but when set to block it doesn''t appear to log sucessful blocks, shouldn't it, or is it me?

[interfaSys]

That's a good idea, but it really depends on your use case and not necessarily on the level of restriction your want to place on your traffic. Still, worth trying to see if something could be put together.

If you switch to drop and hit apply, then it will be logged when blocked. It may be that this specific kind of alert is linked to a certain type of traffic, so it doesn't always pop up right away.

[smajor]

I run a mail server, so SMTP is a no-brainer for me, and I'm seeing lots of blocks there. In concert with my server-side block lists and filters, it has cut the spam down.

I really thought I'd see some other blocks, but only a couple potential DOS on NTP and that's about it.