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

Strange alerts after IPS updates....

Hi all,

after the last ips patterns update released on friday 12th:

Up2Date 7.165 package description:

RPM packages contained:
 u2d-ips-7.164-165.patch.rpm


I'm getting a lots (hundreds) of IPS alerts like this:

Message........: DOS Microsoft Windows TCP SACK invalid range denial of service attempt
Details........: www.snort.org/.../sigs.cgi
Time...........: 2010:02:15-12:50:44
Packet dropped.: yes
Priority.......: 2 (medium)
Classification.: Attempted Denial of Service
IP protocol....: 6 (TCP)


I'm sure this is a false positive because this alerts is related to a well kown TCP traffic involving an external device to an internal DMZ server.
Again Astaro continues to give an invalid snort link as detail and however in this case, the sid=16408 is not defined in the snort rules (Snort seach)

Does anyone detect this strange behaviour?


This thread was automatically locked due to age.
  • Yes, I too have been experiencing this also today and yesterday from various external devices to a DMZ server, wasn't there a patch released for this last week from MS?


    Hi all,

    after the last ips patterns update released on friday 12th:

    Up2Date 7.165 package description:

    RPM packages contained:
     u2d-ips-7.164-165.patch.rpm


    I'm getting a lots (hundreds) of IPS alerts like this:

    Message........: DOS Microsoft Windows TCP SACK invalid range denial of service attempt
    Details........: http://www.snort.org/pub-bin/sigs.cgi?sid=16408
    Time...........: 2010:02:15-12:50:44
    Packet dropped.: yes
    Priority.......: 2 (medium)
    Classification.: Attempted Denial of Service
    IP protocol....: 6 (TCP)


    I'm sure this is a false positive because this alerts is related to a well kown TCP traffic involving an external device to an internal DMZ server.
    Again Astaro continues to give an invalid snort link as detail and however in this case, the sid=16408 is not defined in the snort rules (Snort seach)

    Does anyone detect this strange behaviour?
  • Hi Fozwiz,

    maybe related to the latest M$ patches but why is this rule not present on the snort rules DB?
  • I think we're seeing quite a few false positives with this rule; I've had to disable it at a few sites.
  • We just started seeing it as well.
  • Sure, in my case they are false posivites. 
    But the problem is that with Astaro v7 is not possible to disable a single (or group) rule against a specific destination. 
    The only thing I can do is to create an exception for my DMZ server but in this way I disable completely the IPS for that host...
    Or, I can disable the rule but this will affect all my DMZ servers or I can disable the log notification but I'll never receive nothing in case of real attack.

    As I told in other posts, the v7 IPS configuration options are very limiting.
    We hope in v8...:-)
  • Sure, in my case they are false posivites. 
    But the problem is that with Astaro v7 is not possible to disable a single (or group) rule against a specific destination. 
    The only thing I can do is to create an exception for my DMZ server but in this way I disable completely the IPS for that host...
    Or, I can disable the rule but this will affect all my DMZ servers or I can disable the log notification but I'll never receive nothing in case of real attack.

    As I told in other posts, the v7 IPS configuration options are very limiting.
    We hope in v8...:-)


    I hope in V8 there won't be so many BUGS in the IPS! I have had to completely disable IPS on email because of the FALSE positives. 
     Does this sound like a reliable IPS system to you? I know there are hundreds or thousands of variables that have to be taken into consideration but this has become cumbersome.
     Currently running 4 astaros and Very happy with almost all aspects of them except IPS!
  • The new version of IPS isn't buggy at all - it's more powerful and has more rules to protect against new threats.  In our Astaro, I've disabled some rules that didn't seem to be a threat for us (everyone should decide for their situation which rules they feel comfortable disabling):

    1437 multimedia
    2515 exploit of Microsoft PCT
    2579 exploit a heap overflow associated with Kerberos V5. 
    2707 exploit a known vulnerability in Microsoft GDI using a malformed JPEG image.
    4135 attempt is made to exploit a known vulnerability in Internet Explorer ising a jpeg
    4136 attempt is made to exploit a known vulnerability in Internet Explorer using a jpeg
    5318 exploit a known vulnerability in Microsoft Windows systems via the graphics rendering engine.
    6692 exploit a known vulnerability in Windows Media Player. 
    6697 an attempt is made to return to a web client a file with a Class ID (CLSID) embedded in the file.
    12633 exploit a known vulnerability in Image Viewer.
    12634 exploit a known vulnerability in Image Viewer.
    12798 when shellcode is detected in network traffic. 
    12799 when shellcode is detected in network traffic. 
    12800 when shellcode is detected in network traffic. 
    12801 when shellcode is detected in network traffic. 
    12802 when shellcode is detected in network traffic. 
    15462 when shellcode is detected in network traffic. 



    Cheers - Bob
  • Ok, then exchange the term "false positive" with the word Bugs. The end result is the same.
  • You're right to be miffed - While this is a substantial improvement from a security point of view, I agree that Astaro didn't do a good job of explaining that this would occur and how to manage it.  It would have been nice to get some advance warning.  I hope they do better next time!

    Cheers - Bob
    PS I'll go back and hyperlink the above list with the descriptions.
  • snort[4243]: id="2101" severity="warn" sys="SecureNet" sub="ips" name="Intrusion protection alert" action="drop" reason="DOS Microsoft Windows TCP SACK invalid range denial of service attempt"


    I also get this sucking drops. How do i disable this rule?

    Cheers..

    Edit: Found it ^^ But this is still annoying