This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

7.501 IPS False Positive Gotcha

Hello all,

We have an OpenFire XMPP chat server in our DMZ. It had been running fine for months. Upgraded to 7.501 yesterday (ASG425a cluster).

After the upgrade, queries from the OpenFire / LDAP to our AD server running on the trusted network were taking minutes to return.

The cause was inexplicable. You could SSH, you could do a command line LDAP bind and query, MySQL continued to work etc. etc. We packet traced with Wireshark and saw all sorts of connection resets.

Thankfully someone else has posted on the forums about 7.501 IDS oddities. A quick look in the IDS logs yielded:

WEB-MISC Microsoft Active Directory LDAP query DoS attempt

This is clearly incorrect so I disabled rule 16202 and everything is back to normal.

What I don't understand is:

1. Why the upgrade would start triggering these events? New patterns?
2. When I had all notifications all turned on no emails were emitted?

Anyway it's solved now so I hope this is of use for someone else trying to debug upgrade oddities.


This thread was automatically locked due to age.
Parents
  • 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?
Reply
  • 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?
Children
No Data