CSCux95928 - Would Have Dropped inline result needs additional information

[DBR-SOC]

I have the same trouble in version 6.2.0.4

I can reproduce the problem : 

- open a TCP session

- generate some bad request

- packet are drop by the sensor

- close the TCP session

Instead of multiple alert for each drop packet, it will generate a uniq alert.

This alert have the timestamp of the first bad request and "would have drop" status.

[jmeetze80]

I have this same issue except the "Would Have Dropped" events are only triggered on port scan detection rules 122. I worked with TAC for several months and case was eventually escalated to Cisco's BU. Cisco seems to think it's related to FirePower's Latency-Based Packet handling where packets are bypassing inspection due to load and thus this is why packet's display as "Would Have Dropped".

Cisco's suggestion was to try tuning the threshold for packet handling under the Latency Based Performance Settings in the ACP. I had mine set as high as 4096 microseconds, but that did not help. The other suggestion was from Cisco was to try disabling the packet handling feature under Latency-Based Performance settings, but that only seemed to make the issue worse.

After trying all of these suggestions and working on the case for several months, Cisco finally said that there's nothing they can do and referred me to this bug.

It sounds to me that FirePower just has a poor way of handling port-scanning and honestly, the best option would probably be to just disable it and place another IPS inline to handle this.

[John Groetzinger]

The behavior here is "by design" and this is a serviceability problem we have always had with snort2. There are a lot of different situations and different results you may see in regards to the inline result and the reason. We have addressed this problem in snort3 by adding more granular reason fields to the IPS event as well as a detailed Reason for these scenarios to provide more information when this occurs.

Snort3 was released in version 7.0 for FMC managed FTDs, see the FMC User Guide:

https://www.cisco.com/c/en/us/td/docs/security/firepower/70/configuration/guide/fpmc-config-guide-v70/working_with_intrusion_events.html#ID-2211-000002cf 

See the "Table 1. Inline Result Field Contents in Workflow and Table Views" which explains all the various inline results and reasons you may see.