False positives for 3604 and 11005

[pheuch]

We get false positives for the signatures 11005 and 3604. The reason for this is, that these signatures trigger on replies from normal server.

Here is an example:

A client contacts a webserver on port 80. The source port for this connection is 1204. The reply from the webserver triggers now signature 11005.

I think the real problem is that the sensor does not know who did establish a connection. A workaround would be to ignore any source port less than 1024, but this is not the best way.

I wonder how many signatures are implemented this way?

[mcerha]

Signature 11005 looks for a 'GET' going to port 1214, so it's strange that the web server is returning this. It is a known 3.x problem of tracking the true client <-> server relationship as you mention. This has been corrected in version 4.0. If you want further clarification, please any log files that you have to mcerha@cisco.com.

[pheuch]

Well it is not so easy. The sensor triggers on any occurance of a get string with any case. It does not look on the http header only. So we have some 11005 events triggered by the reply of an https server .

It is also not very unlikely that a javascript code fragment includes get .

I did send some log extracts by mail for further investigation.

[a.arndt]

We've seen the same thing here.

3.1(3)S47 sensors are triggering SigID 11005 during what appears to be normal HTTP transactions.

Here's an example: A Hotmail web server returns HTML to a request (server port 80, client port 1214). Here is the matched context from the alarm's context buffer:

rs_918.gif" alt="Sign out of .NET Passport sites" width="66" height="19">

Not what I'd call KaZaA traffic...

Search the Web

[mcerha]

Yes, this is a false positive. I have submitted a bug id for this. It will be included in the next signature update. The regex pattern will be modified to try and reduce the problem. There is still the issue of 3.x sensors confusing the client vs server relationship. Some level of false positives may occur because of this. 4.0 sensors do not have this problem.