7.501 IPS False Positive Gotcha

7.5 has a new version of IPS, but i would say it was "just" the new patterns.

I learned quickly that, whenever there is a problem which did not existed before, to first have a look into the IPS. In most cases that is the reason.

So I am guessing that Astaro team is aware of the problems that the new IPS version/patterns has? It seems that the ips enable/desable/ solves many of the problems users are facing

The IPS is not a problem in itself.  The concept of an IPS includes the reality that false positives can and will occur (just as many, if not all, commericial AV products do from time to time); there's just too many different combinations of configurations, software, programming techniques, etc. to be able to test them all against any IPS system.  I've worked with free systems, systems like the Astaro, and more expensive systems; all require occasional tuning, configuration, and "pruning"... 

The upgrade to 7.5xx has brung us a new, more capable IPS engine, and thus we now have new rules that dig deeper into the traffic than ever before;  false positives are going to happen.  They are easily corrected.  I'd rather have the enhanced protection than very weak protection, or none at all.

Here's the rub: the IPS is only snort. I'm not sure whether it's "deeper" inspection or just "more". And "more" does not imply "intelligence".

* 7.40x: all LDAP traffic DMZ  Internal works fine
* 7.50x: some LDAP traffic DMZ  Internal works fine (my LDAP queries came back after 2-3 minutes)

I think the blanket use of an IPS such as snort is defence via assumed protection:

1. We assume that snort has a complete and comprehensive rule set. Does it?
2. We assume that when snort intercepts and drops packets then is must be doing it's job. It doesn't. It's dumb.

Hence I think the blanket use of snort is flawed:

1. I know the protocols that I run between certain segments of my network
2. I know that server A talking to server B using protocol Y is correct

And yes I know I can reconfigure Astaro IDS to report rather than drop. IMHO report should be the out of the box configuration rather than drop.

Why? Well by virtue of the fact that I have to disable rules or allow exceptions this leads me to believe that the use of IPS should be targeted. Hence, an inverse configuration scenario would be beneficial:

1. Enable IPS (enabled in reporting mode only)
2. Apply IPS to specific firewall rules (eg. internet -> HTTP server)
3. Only apply specific IPS policies to that firewall rule (why intercept and test for DNS  when I know HTTP is the only traffic to pass via that rule) along with general anomaly protection.

The obvious counter argument is that you could run other protocols on the same port but is my webserver vulnerable to someone attempting to throw malformed rsync packets at it? I think not.

Lastly, the IPS implementation on the ASGs is terrible for performance. It's easily the biggest memory and CPU hog especially when more than just a few interfaces are lit. We use a lot of Meru wifi gear with inbuilt firewalls and IPS - they tend to offload all that traffic processing to another device.

Hi all,

here similar troubles with IPS poor performance...
I had to disable the IPS even on 7.4x version because it caused several issues with our network applications.
Consider that my ASG separates the DMZ from LAN and applications on DMZ sometimes fail to contact the DB servers on LAN but no problems with the IPS disabled.
So I waited for the new 7.5x because it was annunced with best performance on IPS engine but I can say that with 7.5x it is a complete disaster!!!
Periodically I notice all CPUs at 100% on snort_inline processes with related network issues.
In order to work, now the situation is IPS = OFF

The configuration is ASG software on a Dell PE 1850, 2 x dual Intel Xeon 3GHz, 4GB RAM, CTRL Raid Perc4/i, RAID 1 with 2x73GB HD 10K.
Is this too weak?

When I hear people complain that IPS pegs their CPU, I remember a mistake I made several years ago; for some reason, at one client, I put "External (Network)" along with "Internal (Network)" in 'Local networks'.  When they got a little busy, the thing would lock up, and the reports later showed petabits of traffic - not bad for a 100mb interface connected to a T1!  Once that error was corrected, the 120 almost thought it was sleeping.

Cheers - Bob

sure Bob, the IPS is configured to monitor only "Internal Network"....

...just a little question: is astaro v7.5x using barnyard?

Here's the rub: the IPS is only snort. I'm not sure whether it's "deeper" inspection or just "more". And "more" does not imply "intelligence".

* 7.40x: all LDAP traffic DMZ  Internal works fine
* 7.50x: some LDAP traffic DMZ  Internal works fine (my LDAP queries came back after 2-3 minutes)

I think the blanket use of an IPS such as snort is defence via assumed protection:

1. We assume that snort has a complete and comprehensive rule set. Does it?
2. We assume that when snort intercepts and drops packets then is must be doing it's job. It doesn't. It's dumb.

Hence I think the blanket use of snort is flawed:

1. I know the protocols that I run between certain segments of my network
2. I know that server A talking to server B using protocol Y is correct

And yes I know I can reconfigure Astaro IDS to report rather than drop. IMHO report should be the out of the box configuration rather than drop.

Why? Well by virtue of the fact that I have to disable rules or allow exceptions this leads me to believe that the use of IPS should be targeted. Hence, an inverse configuration scenario would be beneficial:

1. Enable IPS (enabled in reporting mode only)
2. Apply IPS to specific firewall rules (eg. internet -> HTTP server)
3. Only apply specific IPS policies to that firewall rule (why intercept and test for DNS  when I know HTTP is the only traffic to pass via that rule) along with general anomaly protection.

The obvious counter argument is that you could run other protocols on the same port but is my webserver vulnerable to someone attempting to throw malformed rsync packets at it? I think not.

Lastly, the IPS implementation on the ASGs is terrible for performance. It's easily the biggest memory and CPU hog especially when more than just a few interfaces are lit. We use a lot of Meru wifi gear with inbuilt firewalls and IPS - they tend to offload all that traffic processing to another device.

It's "deeper" and "more" protection... there are more preprocessors ("deeper") supported in the new IPS version, and along with that comes more rules.

As to the performance aspect; with properly sized hardware for the load, the IPS adds little overhead as far as speed goes.

Also, the IPS as it stands can be targeted; there are fields in Webadmin for denoting which servers are HTTP servers, SQL Servers, DNS Servers, etc.  I do agree I'd like even more granularity; I'm sure that's something being worked on.

...just a little question: is astaro v7.5x using barnyard?

ps aux|grep barn

Hi, I don't see it running on 7.501, but I have seen it in Astaro before.

Barry