The new IPS in 14.1

[Sam Graf]

Thanks again for the hard work. I never thought about having fun (it's always been a learning exercise, which is good) while working with IPS. Maybe I've finally just done gone 'round the bend...

[johnsonx42]

@cblaise - you really did do a very good job with the new IPS; I may have been grumpy about the problems with the old IPS, and so failed to praise the new one beyond "well at least it finally works". Let me remedy that, it does far more than "finally work", it's a huge improvement; the Rules, once understood, are particularly elegant. Well done sir.

Also, I think the use of "reject" rather than "drop" for the Block action is a good choice.

[sky-knight]

It's also smooth enough to operate that I'm starting to experiment with it, and I despise IDS platforms. The extra visibility it provides is nice.

[MechanicalThinker]

Overall I definitely do not share Untangle's view on IPS. IPS in CheckPoint, Fortigate, Tippingpoint and Cisco appliances is really useful and has very good interface that provides great visibility into attacks.

That said, as the new version hit our box, I'm trying to re-tune it and are at a loss. How am I supposed to disable a singe IPS signature? The edit icon in Signatures page is greyed out. I would like to disable log action on all the non-important signatures that generate a lot of log noise and only keep events that are really important. There are couple of useless signatures that create majority of logs. This was possible in previous version where I could just disable the specific signature.

[MechanicalThinker]

Ok, I must say that it's super hard to fine tune the IPS with the new system. It's close to impossible to turn on only specific signatures without also turning on a bunch of pointless signatures. I would rather have preferred a ctrl/shift action on block and log check boxes.

[cblaise]

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.

[johnsonx42]

that did annoy me at first, the need to create a rule to enable a signature. however I understand the idea: most users are going to be using the provided signatures, and those mostly come in groups and they also change from time to time, so devising a rule to activate them en masse by various attributes is a good way to handle it

if you use the Filter function on the signature screen to filter down to the signatures you want, you can then click "Create Rule" and it'll start a rule for you with all your filters added as rule conditions.

if you're adding your own signatures as I am, there is also a rule category called "custom signature" which will be true for any you add.

[johnsonx42]

@cblaise - just came across a bug: On the Signatures screen, if you add a filter for Category, the dropdown box fills with the descriptions of each category, not the actual Category names.

[Sam Graf]

@cblaise - just came across a bug: On the Signatures screen, if you add a filter for Category, the dropdown box fills with the descriptions of each category, not the actual Category names.

I can confirm that.

I do think the process of enabling a single signature is perhaps a step backward from the old system. At the same time, the ability to respond quickly to something in the log is a definite plus. In any case, if thinking classtypes is the recommended way to approach IPS, then single signatures become less the focus.

Except… I’m still trying to sort out the value of thinking classtypes over categories, on the subject of fine tuning, because categories are a more granular approach. Enabling/disabling things by classtype seems to me to elevate the need to deal with individual signatures. I clearly still have a lot to learn.

[cblaise]

Thanks for the category list. I'll file a bug.