Warning: this is a rant triggered by losing (yet again) 3 hours of time trying to configure that piece of... canine byproduct which is the ASL IPS module.
While the whole ASL package in nice and user-friendly, the built-in IPS is not usable in it's present state. It generates a truckload of false positives which have to be handeled manually. Now, getting false positive is ok: tailoring the IPS to your use is part of doing your job when managing security. Unfortunately, the tools provided by ASL for the task are completely lacking to the point of being dangerous.
it all start with reporting: there is no mention at all in the log of what triggered the attack: you get no dump, no rule description, just a few link that most of the time go to 404 web pages. So you're left on your own to dig through the snort rulesets to find what the problem was. That, in itself, is very bad because you don't have the necessary tools to decide if a specific attack is a false positive or not and therefore cannot make a motivated decision about what to do next.
But let's assume it was a false positive and that you know it's a false positive: for instance, editing a web page from the typo3 CMS will freeze the page if you have web client attack set to block (default).
So, what will you do ? the basic idea would be to disable the specific rule that caused problem for teh specific network that triggered it. Well, you can't. Not only that, but you can't even remove that network properly as you'll need a blanket "to OR from" rule for it to work.
So, next step is to disable the problematic rule: that could be for these zillons of silly false poitives triggered by, for instance, IMC sessions. There you can work it out somehow: go in "advanced" add a manual rule modification, enter the rule SID and disable it.
But here comes the problem: you CANNOT see what rule you've disabled, you cannot see when the exception whas created, by who or even setup a note for the exception. The net result is that, 6 month after you've setup the exception, you'll have no more idea why it's there or even if it's valid. That can be solved by maintaining external documentation (which is always good) but the failure mode of that work model is disastrous as a single omission makes it impossible to maintain consistency.
So, to sum up: Astaro's IPS interface should either be rewritten completely, this time without assuming people will simply disable it or removed from the product altogether. In it's current state, it's dangerous to use and cases way too many headache. For a security gateway product, that's not acceptable.
(rant off. Sorry but I had to get that out of my system).
This thread was automatically locked due to age.
