Verify FMC/FTD SI rule is working

[atsukane]

Hi team,

Question around how to verify whether SI is actually dropping intended traffic.

My understanding is that SI is processed BEFORE ACP is evaluated.

When I run packet tracer against an IP that's included in one of the lists/feeds in /var/sf/iprep_download, I do get DROP verdict but it's towards the end in the SNORT phase. (see below packet tracer output)

Since our Intrusion policy is in Detection mode, I'm slightly confused as to whether it's actually dropped or not. 

Issuing "show access-control-config" on the managed device shows me what lists and feeds are in use but doesn't show you the hit counts against SIs as far as I can see.

Other confusing thing I've noticed recently is that Connection Events used to show "Would be blocked" but now it only says "Block" despite our Intrusion policy being Detection mode.

Anyway, if anyone could tell us how to verify SI is dropping the traffic or not, that'd be very much appreciated.

Many thanks in advance.

[nspasov]

Your understanding is correct that Security Intelligence checks take place before the Access Control Policy. Since the Intrusion policy "lives" inside your ACP, its mode (Detection / Protection) is irrelevant. If you want the run SI rules in "detection" mode then you need to right click on the "Block List" objects and select "Monitor-Only." Make sure you have the "Log Connection" checked for both URL and Network and then you can use the unified event viewer to check for such events. 
About your particular drop that you have captured in the screenshot: The SI step "passed" and it is right above drop and I suspect you have an ACP rule that is based on URL category. Can you check and confirm this?

Thank you for rating helpful posts!

[nspasov]

Thank you for rating helpful posts!

[atsukane]

Hi @nspasov 

Thanks for the response.  No, we do not have ACP rules based on URLs for that IP. As a test, I've picked another IP from the Cisco SI feeds and ran packet tracer and got the same results. I can't see SI phase in the packt tracer anyhow, so this could be expected behaviour?

[nspasov]

I am pretty sure the event "Snort | SI-IP" right above the drop in your screenshot is the step for Security Intelligence. What version of code are you running?

Thank you for rating helpful posts!

[nspasov]

Thank you for rating helpful posts!

[atsukane]

Thanks @nspasov  We are running 7.4.2.1. 

The IPs I've used in these examples are found in "Cisco intelligence feed: Malware"

[Marvin Rhoads]

@atsukane 

Expand the "Additional Information" section within the snort stages to see the details from firewall-engine-debug.

Reference slide #38 in the following presentation: https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2024/pdf/LTRSEC-3880.pdf

Also see slides 46 onward for more tips about looking for SI events and enabling logging of the same.

[atsukane]

Thanks @Marvin Rhoads  

It says "gid:136, sid:4, rev:2, action:reject, msg:"(reputation) packets blocked based on destination""

The "reputation" part makes sense as the IP i used is in one found under /var/sf/iprep_download.

Also thanks for the Cisco Li9ve doc, I'll read it through.  

Thanks again.

[MHM Cisco World]

Hi friend 

gid:136, sid:4 <<- use this in snort search' then go to it and select allow not block.

If you dont know how to search please mention me in your reply.

MHM

[MHM Cisco World]

https://www.cisco.com/c/en/us/support/docs/security/secure-firewall-threat-defense/221881-configure-custom-local-snort-rules-in-sn.html <<- this link help you to search about gid:sid that block traffic 

MHM