cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3078
Views
4
Helpful
9
Replies

It does not seem like my FMC/FTD ACP rules are used...

m1xed0s
Spotlight
Spotlight

Here is what I mean,

 

I have vFMC managing several FTDs and I have a parent ACP applied to all the FTD. Each FTD also has its own specific ACP rules. I also have site specific Prefilter to bypass the inspection for Site to Site traffic.

 

The over ACP rule#1 is blocking rule if the accessed URL is in my defined blacklist. But from what I tested so far using Packet Tracer, I think the LINA/SNORT only process the rule#1 and if the URL is not in blacklist, it will permit traffic bypassing all my rest of the rules...Here below is output from packet tracer.

 

If this is the correct behaviour, how should I change the order of my ACP rules to not bypass my other rules? Or I should put L7 rules below L3-4 rules?

Phase: 1
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Config:
Implicit Rule
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x2b535821aa30, priority=1, domain=permit, deny=false
	hits=52263, user_data=0x0, cs_id=0x0, l3_type=0x8
	src mac=0000.0000.0000, mask=0000.0000.0000
	dst mac=0000.0000.0000, mask=0100.0000.0000
	input_ifc=inside, output_ifc=any

Phase: 2
Type: INPUT-ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
Found next-hop 10.10.10.2 using egress ifc  outside(vrfid:0)

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 2684601 
access-list CSM_FW_ACL_ remark rule-id 2684601: ACCESS POLICY: Parent Policy - Mandatory
access-list CSM_FW_ACL_ remark rule-id 2684601: L7 RULE: Blacklisted URLs
Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached
 Forward Flow based lookup yields rule:
 in  id=0x2b5358222e30, priority=12, domain=permit, deny=false
	hits=209082504, user_data=0x2b5349bf26c0, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
	src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
	dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any,, dscp=0x0
	input_ifc=any, output_ifc=any

Phase: 4
Type: CONN-SETTINGS
Subtype: 
Result: ALLOW
Config:
class-map class-default
 match any
policy-map global_policy
 class class-default
  set connection advanced-options UM_STATIC_TCP_MAP
service-policy global_policy global
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x2b53594b7b10, priority=7, domain=conn-set, deny=false
	hits=168118747, user_data=0x2b53594b1c20, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
	src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
	dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
	input_ifc=inside(vrfid:0), output_ifc=any

Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x2b53568f2110, priority=0, domain=nat-per-session, deny=false
	hits=156117954, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
	src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
	dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
	input_ifc=any, output_ifc=any

Phase: 6
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x2b5358221ad0, priority=0, domain=inspect-ip-options, deny=true
	hits=245028413, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
	src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
	dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
	input_ifc=inside(vrfid:0), output_ifc=any

Phase: 7
Type: FLOW-EXPORT
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x2b53594bb2f0, priority=18, domain=flow-export, deny=false
	hits=168991554, user_data=0x2b5358f94400, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
	src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
	dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
	input_ifc=inside(vrfid:0), output_ifc=any

Phase: 8
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 in  id=0x2b53568f2110, priority=0, domain=nat-per-session, deny=false
	hits=156117956, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6
	src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
	dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
	input_ifc=any, output_ifc=any

Phase: 9
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
 in  id=0x2b5358144f40, priority=0, domain=inspect-ip-options, deny=true
	hits=266541351, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
	src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
	dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
	input_ifc=outside(vrfid:0), output_ifc=any

Phase: 10
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 278428903, packet dispatched to next module
Module information for forward flow ...
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_snort
snp_fp_translate
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_fp_tracer_drop
snp_ifc_stat

Module information for reverse flow ...
snp_fp_inspect_ip_options
snp_fp_tcp_normalizer
snp_fp_translate
snp_fp_snort
snp_fp_tcp_normalizer
snp_fp_adjacency
snp_fp_fragment
snp_fp_tracer_drop
snp_ifc_stat

Phase: 11
Type: EXTERNAL-INSPECT
Subtype: 
Result: ALLOW
Config:
Additional Information:
Application: 'SNORT Inspect'

Phase: 12
Type: SNORT
Subtype: 
Result: ALLOW
Config:
Additional Information:
Snort Trace:
Packet: TCP, SYN, seq 1480753017
Session: new snort session
AppID: service unknown (0), application unknown (0)
Firewall: starting AC rule matching, zone 3 -> 4, geo 0 -> 0, vlan 0, sgt 0, src sgt type 0, dest_sgt_tag 0, dest sgt type 0, user 9999999, icmpType 0, icmpCode 0
Firewall: pending rule-matching,  'Blacklisted URLs' , pending URL
Snort id 0, NAP id 2, IPS id 0, Verdict PASS
Snort Verdict: (pass-packet) allow this packet

Phase: 13
Type: INPUT-ROUTE-LOOKUP-FROM-OUTPUT-ROUTE-LOOKUP
Subtype: Resolve Preferred Egress interface
Result: ALLOW
Config:
Additional Information:
Found next-hop 10.10.10.2 using egress ifc  outside(vrfid:0)

Phase: 14
Type: ADJACENCY-LOOKUP
Subtype: Resolve Nexthop IP address to MAC
Result: ALLOW
Config:
Additional Information:
Found adjacency entry for Next-hop 10.10.10.2 on interface  outside
Adjacency :Active
MAC address f08e.dba1.ad91 hits 47553 reference 4070

Result:
input-interface: inside(vrfid:0)
input-status: up
input-line-status: up
output-interface: outside(vrfid:0)
output-status: up
output-line-status: up
Action: allow

   

9 Replies 9

balaji.bandi
Hall of Fame
Hall of Fame

Loos like it hitting snort

 

Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached

 

can you post how the ACP rule configured.

 

or refer below example guide :

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/200908-configuring-firepower-threat-defense-int.html

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Here is my rule#1 configuration.

1.png

So I guess once the SNORT verdict PASS is received, all the remaining ACP rules will be skipped? 

Panos Bouras
Level 1
Level 1

hi @m1xed0s 

 

Can you share a bit more of your rules and how there are ordered?

Additionally I would try to be very specific about the rule and limit the ports also e.g. 80 and 443. Also add source network.

 

Thank you,Panos.
Please Rate Posts (by clicking on Star) and/or Mark Solutions as Accepted, when applies

What I have been doing is I put blocking/deny rules at the very top, then put specific allow rules next and then those generic allow/block and lastly the catch-all.

 

The "issue" I am trying to figure out is, why the engine only processes the 1st rule (even there is pass verdict from SNORT) and skips all the remaining rules below. I do understand firewall will inspect traffic based on first matched rule top to bottom to apply action and then stop for further checking with the remaining rules. But my rule#1 is only matching for specific URLs and my tests did not try any of those URLs. So why the engine (based from packet-tracer) thinks rule#1 is a match and skips all the remaining? 

I understand your point, but some packets would be allowed (whitelisted by Snort) in order to reach to the point where an URL can be extracted from the session. Imagine the simple scenario of a client trying to reach www.cisco.com,

Client will first send a SYN request to port 80
Server will respond with SYN,ACK
Client will ACK
Then the client will send an HTTP GET with the URL www.cisco.com.

So Snort should allow the first packets to flow in order to get to the point where it can extract the URL info (same goes when you use Application instead of ports). At some point later e.g. Client packet #4 will be "released" by Snort and then it will get evaluated from rules below.

Now let's say that you don't include any L3-L4 filters or zone info in your rule, this rule will be applied to all traffic even the one from outside and the first packets will be allowed by Snort until it reaches a point that "releases" the flow to rules below.

So my recommendation is be very specific about the traffic that you want to send to snort and try to include as much L3-L4 filters possible on the rule, in order to avoid the first packets issue. If not sure place your rule lower that you can and try to block unwanted traffic before it reaches this rule.

Thank you,Panos.
Please Rate Posts (by clicking on Star) and/or Mark Solutions as Accepted, when applies

Thanks!! I do agree that for the L7 inspection, the first or even second packets of the flow would be "matched" to rule#1 as PASS in order for the engine to see the actual URL for inspection. But how would I know the subsequent packets of the same flow are actually been processed by remaining rules below? Obviously the easy option packet-tracer won't provide me the information...

A packet capture with trace will show you the rules applied to each packet.

And for a more detailed approach on how to see the whole flow, check the following guide from the guys at Security Cisco TAC at Krakow
https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-threat-defense-f.html
https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/215092-analyze-firepower-firewall-captures-to-e.html

Thank you,Panos.
Please Rate Posts (by clicking on Star) and/or Mark Solutions as Accepted, when applies

And this ones, just check Scenario 2. Drop Due to Snort Verdict (Similar as it uses AVC)

https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212321-clarify-the-firepower-threat-defense-acc.html?referring_site=RE&pos=3&page=https://www.cisco.com/c/en/us/support/docs/security/firepower-ngfw/212474-working-with-firepower-thre...

Thank you,Panos.
Please Rate Posts (by clicking on Star) and/or Mark Solutions as Accepted, when applies

Thanks, will go through them later...

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: