119:15 HI_CLIENT_OVERSIZE_DIR, and all other 119 alerts

[bhaskarayani]

How to tune this signature within the sourcefire? We have so many alerts triggering, whenever there are conenctions iniitiated from inside to outside while accessing any website like Business/News category and many other categories. HTTP inspection is enabled already. 

Also we have too  many alerts for the following

HI_CLIENT_IIS_UNICODE 119:7

HI_CLIENT_BARE_BYTE 119:4

HI_CLIENT_DOUBLE_DECODE 119:2

How we can we surpress them in right way? Best approach to deal with these stuff.

Thanks

[Aastha Bhardwaj]

Hi,

They are not indicating an intrusion attempt, but more-so a violation of protocol standards. GID of 119, like these rules have, indicate that itis not a standard rule, but a preprocessor that is triggering these, more specifically, 119 is the HTTP Inspect preprocessor.


> HI_CLIENT_IIS_UNICODE (119:7)     - indicates that a very long URI was used.

> HI_CLIENT_DOUBLE_DECODE (119:2)   - Some characters were encoded twice

> HI_CLIENT_BARE_BYTE (119:4)   - Microsoft IIS servers are able to use non-ASCII characters as values when decoding UTF-8 values. This is non-standard behavior for a webserver and violates RFC recommendations. All non-ASCII values should be encoded with a %. This
event may indicate an attack against a web server or at the least an attempt to evade an IDS. No web clients encode UTF-8 characters in  this way. This is most likely a malicious request.

But you can suppress the events .You can do that based on either source,destination or rule. In this case you can do that based on Rule.

Refer : http://www.cisco.com/c/en/us/td/docs/security/firesight/541/user-guide/FireSIGHT-System-UserGuide-v5401/Intrusion-Events.html#pgfId-4185933

Regards,

Aastha Bhardwaj

Rate if that helps!!!

[bhaskarayani]

sorry for the delayed response. This is quite informational. Thank you. 

[rweir0001]

Aastha,

Would you suggest suppressing these alerts or creating a pass rule? My internal web filter is triggering a lot of these alerts in my IPS as it connects to some outside destinations. I'm sure it is a false-positive and not an indication of an attack. I was thinking of creating pass rules for these alerts when my web filter is the source IP, because I believe suppression will simply drop the packets without any logging at all and I don't like that idea. The only issue I have with the pass rules is that if the rule they were copied from changes it will not affect my pass rule. I wonder if there is a situation where the original rules changes to such a degree that my pass rule doesn't function any longer and then my IPS suddenly begins dropping these packets. That could be very bad for us because the packets dropped would be from our internal users trying to reach sites on the internet.

Thoughts?

[mcvosi]

I see 119:4's happening to an remote IIS server. My best guess is that a filter rule should be created, allowing known traffic to pass.