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 ?
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.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR
and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity
options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in
HA DocumentationCode download linksGoalRequirementLimitationsSupported
ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and
UCS-E Blades:Step by Step ConfigurationCo...
Question I am currently unable to specify "crypto keyring" command when
configuring VPN connection on my cisco 2901 router. The following
licenses have been activated on my router :