Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Wrong diagnostic from signatures


we are observing repeated false positives from some signatures. The following ones are particularly problematic because the applications do exist on the network but the diagnostic is obviously wrong. Note that in all three cases the NSDB specifies "no known benign triggers" ....

- MS NetMeeting RDS DOS: triggers on HTTP traffic with dest port 1720

- Tivoli Storage Manager Client Acceptor Overflow: HTTP traffic with dest port 1581

- Oracle 9iAS Web Cache Buffer Overflow: HTTP traffic with dest port 1100

In all cases, these are responses to HTTP queries. The signatures look extremely simple, something like (port+exceeded length in some field) and do not properly qualify the underlying vulnerability. We need these signatures enabled because the related applications are used. Could somebody at Cisco look into them and ensure that they trigger only on appropriate traffic ?




Re: Wrong diagnostic from signatures

None of these are known issues. You will want to give the TAC a call to file a bug.

Cisco Employee

Re: Wrong diagnostic from signatures

This is a known issue.

The Engine is tracking packets destined to those ports with the assumption being that they are the server ports. The Engines therefore analyze all of the traffic going to those ports looking for the associated patterns for the signatures.

What you've found is that in your case these ports are being used as client ports. And the data being sent to them is the response from your web server. (or another service) In the responses from your web server the sensor is detecting the patterns and firing alarms for the signatures.

This happens because the engines look at packets without regard to whether or not the destination port is the server port or the client port. This is a bug in our Engines and is currently being worked on for correction in a future release.

Until then what you will need to do is Exclude your Web Server (or other service) as the SOURCE of these alarms. The response traffic from your web server will then no longer trigger the alarm. This will eliminate the majority of the false positives you are seeing.

NOTE: This only prevents the alarm from firing if the sensor thinks the web server is the atacking box, the alarm will still fire for attacks directed at your web server and other boxes from other machines.

Future alarms would have to be evaluated. If the destination port is the server port then the alarm is likely true, but if then destination port in the alarm is actually the client port then more than likely it is another false positive.

The NSDB will be updated to document these false positives as we work on getting them fixed in a future release.

CreatePlease to create content