
Cisco FTD Snort Drop: show asp drop When IPS Kills a Trusted App
- 3 days ago
- 2 min read

A trusted vendor app dies after you set IPS to prevention. ACP is allow.
This is a live-ticket style lesson from Techclick Infosec. You will isolate the fault with CLI first, then prove the fix with one clean packet or log.
What you will be able to do
Name the first CLI command to run on Cisco FTD for this ticket
Separate the layer that is actually broken from the layer people blame
Apply one scoped fix instead of a global disable
Prove the ticket closed with a session, log, or counter
Quick answer
show asp drop and intrusion events name the Snort signature. Suppress or set that rule to alert, do not turn off IPS.
Why this ticket shows up
Snort can drop after ACP allow. That is by design in prevention mode.
Symptoms operators actually see
asp drop snort counters climb
Intrusion event on that app
Started after prevention
Other apps fine
CLI first — copy this block
Run these on the Cisco FTD device or console named in the ticket. Do not skip the first show command — it tells you which later command matters.
show asp drop
show conn address 10.4.4.4
system support trace
# FMC: Analysis > Intrusions for the SIDHow to read that output
A climbing snort drop counter plus an SID is your exception candidate.
Triage order
show asp drop twice
Find the SID in intrusion events
Set that SID to alert for the vendor network
Deploy
Retest
Classic traps
What you see | Real cause | Fix |
IPS off globally | One SID | Tune the SID |
Another ACP allow | ACP already allowed | Wrong layer |
Ignore asp drop | That is the drop point | Read it |
Proof the ticket is closed
SID no longer drops that flow
IPS still prevention
App works
Say this in an interview
ACP allow plus a dead app is Snort until asp drop is clean.
Need the full vendor lab, mock interview, and production runbooks? Techclick trains Palo Alto, Zscaler, F5, FortiGate, Check Point, Cisco ISE, Azure and routing with live CLI — start at https://www.techclick.in/



Comments