Back
Lesson 3 of 6

Intrusion Prevention (IPS)

Objective

In this lesson you will learn how the Cisco Secure Firewall Threat Defense (FTD) uses the Snort Intrusion Prevention System (IPS) during packet processing, how to influence whether traffic gets inspected, how Security Intelligence (SI) blocklists interact with flows, and how to verify IPS behavior using the device CLI. This matters in production because IPS decisions can block traffic before access-control rules are applied — a critical consideration when troubleshooting false positives or unexpected connectivity failures. Real-world scenario: an administrator needs to confirm why SSH or ICMP flows were terminated even though an Access Control Policy rule allows them — IPS or SI may have blocked them earlier in the pipeline.

Topology (recap from Lesson 1)

ASCII topology with exact IPs and interface names used in this lesson:

[Host-A]                    [FTD5506-1]                    [Host-B]
(Inside)                     (Device)                       (DMZ/Outside)
1.1.1.1/32  ---inside---   inside  <->  outside   ---dmz/out--- 2.2.2.2/32
                                 |                               
4.4.4.4/32  ---inside---             (FTD processes flows)         
                                 |
5.5.5.5/32  ---outside---         (SI files at /ngfw/var/sf/iprep_download)
                                 |
192.168.62.3/32  ---inside---  (example attacker/source)          
10.123.175.22/32 ---outside---  (example server/target)

Device table

DeviceRoleNotable interfaces/IPs
FTD5506-1Secure Firewall (FTD)inside/outside/dmz (logical zones shown in packet-tracer)
Host-AInternal test host1.1.1.1, 4.4.4.4, 192.168.62.3
Host-BRemote server / external test2.2.2.2, 5.5.5.5, 10.123.175.22
Local SI files hostFTD filesystem/ngfw/var/sf/iprep_download (SI blocklist files)

Quick Recap

This lesson builds on the topology from Lesson 1. No new devices are added. We will use the exact IP addresses shown above to demonstrate how the FTD’s packet processing interacts with Snort (IPS) and Security Intelligence (SI). You will not need any external management GUI to follow the CLI verification steps shown here.

Key Concepts

  • Lina vs Snort processing order: The FTD’s packet processing pipeline first evaluates L3/L4 ACLs in the Lina engine; for many ACLs the packet is passed to the Snort engine for an intrusion verdict. If Snort issues a Block verdict (or a blocklist matches), the flow may be terminated before the Access Control decision is applied. In production this is why an allowed AC rule may never see the traffic.
  • Trust vs Inspect: ACL entries marked trust usually bypass Snort (no deep inspection). ACLs that permit but are intended for application inspection will be sent to Snort for a verdict. Think of “trust” as a fast-pass lane that doesn't get screened by the IDS scanner.
  • Security Intelligence (SI) early drop: SI blocklists are consulted early inside the Snort engine; an IP on the SI Blocklist can be dropped quickly (fast-forward or block-list verdict), and the FTD will re-evaluate AC rules afterward. In production, SI is used to quickly quarantine known bad infrastructure (botnets, scanners).
  • Stream Preprocessor events: The Snort stream5 preprocessor affects how TCP streams are normalized and reassembled; enabling its rules generates events that help troubleshoot stream-related problems (e.g., out-of-order reassembly). You can enable identifiers to generate events for stream preprocessing to debug complex flows.
  • Logs & connection table verification: Use syslog output (show logging), the connection table (show conn address), and file checks on the FTD filesystem (ls/grep under /ngfw/var/sf/iprep_download) to confirm SI behavior and IPS drops.

Tip: Think of Snort as a specialized traffic inspector working alongside the firewall — it can pull a flow off the general path for deeper checks and, if necessary, remove it from circulation entirely.

Step-by-step configuration

Step 1: Create an ACL that will be processed by Snort (a permit that is sent to Snort)

What we are doing: We create an ACL entry that permits ICMP from host 1.1.1.1 to host 2.2.2.2. In the FTD packet-tracer examples this type of L3/L4 ACL permit is sent to the Snort engine for application-level inspection (L7), which is how IPS rules can act on ICMP content.

configure terminal
access-list CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit iphost 1.1.1.1 host 2.2.2.2
access-list CSM_FW_ACL_ remark rule-id 268435456: ACCESS POLICY: FTD5506-1-Mandatory/1
access-list CSM_FW_ACL_ remark rule-id 268435456: L7 RULE: ACP_Rule1_Allow_ICMP_App
exit

What just happened: These commands created a global access-list named CSM_FW_ACL_ and added an advanced permit entry for ICMP (permit IP from exactly 1.1.1.1 to 2.2.2.2). The remarks annotate the rule-id and describe that this ACL entry corresponds to an ACP L7 rule; packets matching this rule will be sent to the Snort engine for a verdict.

Real-world note: In production, use precise host-based rules sparingly. Broad L7 inspection for many hosts can cause high CPU on the Snort engine.

Verify:

packet-tracer input inside icmp 1.1.1.1 8 0 2.2.2.2

Expected output (exact lines relevant to Snort engagement):

Phase: 2 Type: ACCESS-LIST Subtype: log Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit iphost 1.1.1.1 host 2.2.2.2 rule-id 268435456
access-list CSM_FW_ACL_ remark rule-id 268435456: ACCESS POLICY: FTD5506-1-Mandatory/1
access-list CSM_FW_ACL_ remark rule-id 268435456: L7 RULE: ACP_Rule1_Allow_ICMP_App
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be reached

Step 2: Create a Trust ACL entry that bypasses Snort

What we are doing: Add a UDP trust ACL so DNS traffic between 4.4.4.4 and 5.5.5.5 is trusted and will not be sent to Snort. This demonstrates the difference between "trust" and "inspect" behavior.

configure terminal
access-list CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced trustudphost 4.4.4.4 host 5.5.5.5 eq domain
access-list CSM_FW_ACL_ remark rule-id 268435477: ACCESS POLICY: FTD5506-1-Mandatory/4
access-list CSM_FW_ACL_ remark rule-id 268435477: L4 RULE: ACP_Rule4_Trust_DNS_Port
exit

What just happened: The trustudphost entry instructs the Lina engine that DNS flows between the specified hosts should be allowed and not forwarded to Snort. This produces faster forwarding and avoids deep inspection for those flows.

Real-world note: Use trust entries for high-volume, low-risk control plane traffic (e.g., internal DNS) to reduce inspection load.

Verify:

packet-tracer input inside udp 4.4.4.4 1111 5.5.5.5 53

Expected output (showing no Snort processing):

Phase: 4 Type: ACCESS-LIST Subtype: log Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced trustudphost 4.4.4.4 host 5.5.5.5 eq domain rule-id 268435477
access-list CSM_FW_ACL_ remark rule-id 268435477: ACCESS POLICY: FTD5506-1-Mandatory/4
access-list CSM_FW_ACL_ remark rule-id 268435477: L4 RULE: ACP_Rule4_Trust_DNS_Port
Additional Information:
event-log flow-end

Step 3: Configure and observe a layer-4 deny (Telnet) ACL entry

What we are doing: Add an explicit DENY for Telnet between source 6.6.6.6 and destination 7.7.7.7 to illustrate an L4 ACL block. L4 denies are evaluated by Lina and will prevent the flow from being established (and may or may not involve Snort depending on rule semantics).

configure terminal
access-list CSM_FW_ACL_ global
access-list CSM_FW_ACL_ line 24 advanced denytcphost 6.6.6.6 host 7.7.7.7 eq telnet rule-id 268435464
exit

What just happened: A specific deny entry for Telnet (TCP port 23) is added; flows matching this entry will be dropped by the ACL. This is an example of an L4 rule being used to block specific service access.

Real-world note: Explicit denies are useful to prevent legacy protocols (Telnet) at the firewall perimeter, but remember that IPS might already block related traffic earlier.

Verify:

packet-tracer input inside tcp 6.6.6.6 1024 7.7.7.7 23

Expected result (typical lines; admin should observe DENY in Phase showing ACL rule):

Phase: 2 Type: ACCESS-LIST Subtype: log Result: DROP
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ line 24 advanced denytcphost 6.6.6.6 host 7.7.7.7 eq telnet rule-id 268435464
Additional Information:
This packet matched an ACL entry and was denied

Step 4: View logs showing IPS/Snort blocking a session before AC match

What we are doing: Inspect the FTD logs to find evidence where the Snort engine blocked a flow, deleted the session, and the Lina engine re-evaluated the AC policy. This is crucial when troubleshooting why allowed connections are being removed.

show logging | include connection

Expected output (copying exact lines from the reference):

Jun 13 2022 13:32:49: %FTD-6-302021: Teardown ICMP connection for faddr192.168.76.14/0 gaddr192.168.75.14/0 laddr 192.168.75.14/0
Jun 13 2022 13:33:00: %FTD-6-302016: Teardown UDP connection 357875 for inside:192.168.75.14/60131 to dmz:192.168.76.14/53 duration 0:02:01 bytes 43

What just happened: The logging command shows teardown events for ICMP and UDP sessions. In a real IPS block, you'll also see messages indicating session deletion because an IPS rule dropped the flow (the reference includes a narrative indicating sessions were deleted because an IPS rule blocklisted the flow and that this happened before AC rule matching).

Real-world note: When you see session teardown messages that coincide with expected traffic, correlate with Snort/SI events to determine whether an IPS signature or an SI blocklist caused the drop.

Step 5: Verify Security Intelligence blocklist files and search for IPs

What we are doing: Inspect the SI feed files stored on the FTD filesystem to confirm whether a particular IP is present in a blocklist. If an IP is present, SI will cause early drops within Snort.

# List SI blocklist files
ls -alt /ngfw/var/sf/iprep_download | grep blf

Expected output (exact sample lines from reference):

-rw-r--r-- 1 root root 1252278 Jun 12 16:06 3e2af68e-5fc8-4b1c-b5bc-b4e7cab598ba.blf
-rw-r--r-- 1 root root 227696 Jun 12 16:05 032ba433-c295-11e4-a919-d4ae5275a468.blf

Then verify whether a specific IP is listed:

grep -Fr 192.168.62.3 /var/sf/iprep_download

Expected output (if present; otherwise no output). The command and path are taken from the reference: grep –Fr [IP_ADDRESS] /var/sf/iprep_download

What just happened: You enumerated the SI blocklist files and searched them for a particular IP. If the IP is found, SI will classify it as blocklisted and the Snort engine may drop traffic from that IP early in processing.

Real-world note: SI blocklists can be populated automatically (Talos feed) or manually; confirm whether an IP must be in a Do-Not-Block list to allow traffic that would otherwise be blocked.

Step 6: Inspect current connection state to correlate with logs

What we are doing: Use the connection table to see active/idle sessions and bytes transferred to verify whether traffic is being passed or torn down.

show conn address 192.168.75.179

Expected output (exact lines from the reference):

UDP outside 192.168.75.179:138 inside 192.168.75.255:138, idle 0:00:19, bytes 35306, flags -N
UDP outside 192.168.75.179:137 inside 192.168.75.255:137, idle 0:00:19, bytes 6350, flags -N

What just happened: This shows UDP sessions in the connection table and their state. Use this to confirm whether flows are alive or being torn down by IPS or ACLs.

Real-world note: Connection table entries confirm whether a flow has been successfully established. A missing entry for an attempted connection suggests the flow was blocked earlier — by IPS, SI, NAT, or ACL.

Verification Checklist

  • Check 1: ACL that triggers Snort — use packet-tracer input inside icmp 1.1.1.1 8 0 2.2.2.2 and confirm "This packet will be sent to snort..."
  • Check 2: Trust ACL bypasses Snort — use packet-tracer input inside udp 4.4.4.4 1111 5.5.5.5 53 and confirm no Snort processing lines.
  • Check 3: SI blocklist presence — run ls -alt /ngfw/var/sf/iprep_download | grep blf and grep -Fr [IP] /var/sf/iprep_download to verify blocklisting of an offending IP.
  • Check 4: Correlate logs and conn table — use show logging | include connection and show conn address <ip> to map teardown events to live connections.

Common Mistakes

SymptomCauseFix
Packets are dropped even though ACL permits themA Snort IPS or SI blocklist dropped the flow before AC rule matchingCheck show logging for IPS/Snort messages and search SI files with grep -Fr [IP] /var/sf/iprep_download
Packet-tracer shows ALLOW but real traffic is blockedSI blocklist or IPS signature dynamically blocked the live flowInspect runtime logs and connection table; verify SI lists and IPS event logs
Expecting trust rules to be inspected by SnortUsed trust ACL type (e.g., trustudphost), which bypasses SnortUse permit/inspect ACL entries when you need Snort to evaluate traffic
High CPU on FTD after enabling many L7 rulesOveruse of host-based L7 inspection causing Snort loadNarrow scopes (specific hosts/ports), apply Do-Not-Inspect where safe, monitor performance

Key Takeaways

  • The FTD pipeline can have traffic blocked by Snort (IPS) or Security Intelligence (SI) before an Access Control rule is applied; always check IPS/SI when an allowed flow is failing.
  • Use packet-tracer to determine whether a packet will be forwarded to Snort for inspection or will be fast-trusted; the output explicitly states if "This packet will be sent to snort..."
  • SI blocklists live on the FTD filesystem under /ngfw/var/sf/iprep_download; use ls and grep to verify presence of IPs that may be blocked.
  • Distinguish trust ACLs (bypass Snort) from inspect/permit ACLs (sent to Snort). In production, balance inspection coverage with performance.

Important: When troubleshooting production outages, always correlate packet-tracer results with actual runtime logs (show logging) and the connection table (show conn address) — packet-tracer is predictive, while logs and conn state show what actually happened.

If you want, the next lesson will show how to tune specific signatures (for example GID=1, SID=408 for ICMP echo replies) and how to generate safe test traffic that produces IPS events without impacting production hosts.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security