80% false positive

Some rules will have a lot of false positives. Unfortunately, that's pretty much the way it is with almost all IDS/IPS systems.

Fortunately, you are free to turn off rules which you feel are ineffective.

Barry

true, but whats the use of ids than?

[ QUOTE ]
true, but whats the use of ids than? 

[/ QUOTE ]

To protect you. The blocking rules are here because they match real world attack patterns. The problem is that some good traffic will also trigger these packets. So, like a great many things in security, the default is to err on the side of safety and reject everything that looks like bad traffic automatically. After that, the human administrator can decide wether or not corrective action should be taken and which ones (like disabling the rule or changing it).

in addition to that, some rules are better written than others. For instance, the rule that detect MStream communication (a botnet sofwtware) simply picks up any TCP communtication on TCP 6723 as a "communication between agent and handler" which is simply wrong and caused me to be recalled from holidays because of a manager not knowing his zeroes from his ones (since we don't run *nix on any of the "compromized" machines, this was guarantee to be a false positive of some sort and it was indeed).

So, it's unfortunate, but false positives are a given in the admin's daily routine.

[ QUOTE ]
true, but whats the use of ids than? 

[/ QUOTE ]

To protect you. The blocking rules are here because they match real world attack patterns. The problem is that some good traffic will also trigger these packets. So, like a great many things in security, the default is to err on the side of safety and reject everything that looks like bad traffic automatically. After that, the human administrator can decide wether or not corrective action should be taken and which ones (like disabling the rule or changing it).

in addition to that, some rules are better written than others. For instance, the rule that detect MStream communication (a botnet sofwtware) simply picks up any TCP communtication on TCP 6723 as a "communication between agent and handler" which is simply wrong and caused me to be recalled from holidays because of a manager not knowing his zeroes from his ones (since we don't run *nix on any of the "compromized" machines, this was guarantee to be a false positive of some sort and it was indeed).

So, it's unfortunate, but false positives are a given in the admin's daily routine.