The new IPS in 14.1

[MechanicalThinker]

To disable a signature, you can create a rule that matches the signature id and applies the disable action.
To enable a specific signature, you can create a rule that matches the signature id to set one of the non-disabled actions.

Yes, I figured that out. But the problem is that there are literally hundreds if not thousands of pointless signatures enabled after setting things up with broad brushstrokes. I tried to make it as granular as possible with classtypes and categories but still there's huge amount of stuff enabled that is completely pointless as well as stuff that is not enabled but should be.

Picking these signatures out one by one into separate rule(s) would be a lot of work. With the old system I could just go through the list and check/uncheck what is needed. It would take a day or two to go through the list but in the end only necessary signatures would be there.

With the current system it will probably take a week, probably more to pick all the signatures out into a separate rules. For example, about 2/3 of the signatures in web-attacks are completely useless because we do not have these web apps but there's no way to narrow the selection even more down sans manually copy and pasting every signature id into a separate rule set. That's crazy. It will create a huge mess.

I do appreciate the ability to mass enable the signatures but the new system is far from perfect. A simple ctrl/shift + click action would have been much better. As the list can be sorted by signature comment, protocol etc all that was needed was an ability to mass select a block of signature and enable/disable them.

[johnsonx42]

I do appreciate the ability to mass enable the signatures but the new system is far from perfect. A simple ctrl/shift + click action would have been much better. As the list can be sorted by signature comment, protocol etc all that was needed was an ability to mass select a block of signature and enable/disable them.

I think if you look carefully at the signatures you want to enable, you'll find some common attribute(s) that you can use to make a rule. For example, I have a rule that sets to block all signatures in the Drop, Dshield, and Compromised categories. These are all hosts that are known to be malicious, so I have no interest in hearing from them, ever.

[johnsonx42]

A simple ctrl/shift + click action would have been much better.

also, if I correctly understand things I read in JIRA about the new IPS and reasons for it, there's a very good reason why single rules can't be enabled/disabled in the same manner as before, so it's not just a simple matter of bringing back the feature... it can't be brought back because it just doesn't work that way any more.

[Sam Graf]

also, if I correctly understand things I read in JIRA about the new IPS and reasons for it, there's a very good reason why single rules can't be enabled/disabled in the same manner as before, so it's not just a simple matter of bringing back the feature... it can't be brought back because it just doesn't work that way any more.

Good to know. Thank you.

[dmorris]

One of the main goals of this IPS is to get the "signatures" *out* of the settings.

1) Putting sigs in settings makes settings a general pain to manage. What happens if the updates change the signature and the user changed the default? Keep the old? Use the new? Keep both? How do we deal with signatures removed from upstream? What if those signatures state has been changed? Discard it? The issues are just really gross and generally lead to behavior that is not predictable nor intuitive from a user perspective. Now these scenarios are entirely predictable.

2) Moving signatures out of settings, means the settings can be cloud managed because they are of a manageable size. Now the rules are the defacto definition of behavior and these can be centrally managed easily. They can also be shared, which has some utility as IPS rules now describe your approach and are not just a hardcoded signature set at a point in time.

3) For future purposes, Separating the settings (rules) from the signatures (defaults) allows you to use the same model on different signature providers instead of being tightly bound to a specific provider.

[Sam Graf]

One of the main goals of this IPS is to get the "signatures" *out* of the settings.

All that does make sense in terms of my experience with the old IPS. Things would change widely and unpredictably over time as the signature definitions changed widely and unpredictably. And #2 is clearly a good thing.

The thing I'll be interested in over time is seeing if I'm prone to a proliferation of event-based rules by responding primarily to the log. Or will I (sooner or later) take the time to consider a classtype- or even category-based rule in their place? Right now it's not too tempting to just let event-based rules accumulate, and I can't see any general good coming from letting them accumulate. So hopefully I'll keep that in mind.

[sky-knight]

I just got an early morning wakeup call because I enabled this feature with all the default rules on my largest network.

It was actually doing great, except one of he RCON signatures matches on a generic SNMP query my server was using to determine a printer's online status.

Two stores that can't print because I turned on everything and went to bed. Now I'm just using the rules that log instead of blocking.

[Sam Graf]

I just got an early morning wakeup call because I enabled this feature with all the default rules on my largest network.

Oops...

I've settled on the 115 blocks provided by the dshield, compromised, and ciarmy categories and will watch the reports for awhile, in particular the "spillover" effect (including the resulting few snmp blocks).
Intrusion_Prevention-Top_Categories_(blocked)-11.12.2018-1106.png

Currently, under the default enabled rules plus the three, there is little to no outbound traffic in the reports. That might be perfect, a very good sign, but I'll explore that next. I'll probably start with enabling the default Low Priority rule.

I'm still learning, still having fun. Hopefully your early morning call won't simply reinforce your disapproval of IDS/IPS stuff.

[sky-knight]

In my case the reason this happened was the VRRP clustered Untangle servers in question are not only Internet connected, but have a private link that attaches to branch offices. This link is also managed by Untangle and traffic going to and from those locations is subject to Untangle filtration. Because the IDS app doesn't have an apparent means (at least to me at this time) to exempt traffic it processes, I do not know how to bypass the module short of using bypass rules. I do not want to bypass the traffic, because I use the firewall module to control the private links.

Which brings us to the fact that all system apps need an internal means to bypass just that app for specified traffic.

[Kyawa]

I just signed up for the webinar.