Re: Edit ACP Policy in FTD2100?

CiscoBrownBelt · ‎03-29-2023

I know the ACP Policy (in the FMC GUI not FTD) consists of different policies, but I am trying to make sense of all the Prefilters configured as most don't show any hits. These policies are automatically applied to the FTD or connected devices?

Click on the AC Policy in Hit Count window and it shows 2 rules, and only Default ACtion rule is getting hits so seems traffic is allowed via this rule.

Default Prefilter Policy from main Pre-filter window is blank with no rules (states cant add rules, can only change default action options) says it is for allowing all tunnels.

How do I view/edit this rule for the AC Policy (if possible) or how do I confirm what default action is?

Eric R. Jones · ‎03-29-2023

My understanding is that you can't do anything with any of the default policies in the FMC/FTD. You can create a new one and keep the default settings. In this case it is Allow all tunnel traffic. I played around with this a bit but never deployed what I created as it's not need.

Octavian Szolga · ‎03-29-2023

Hi,

Using prefilter you can either manipulate (block/allow/inspect) tunnelled traffic or offload some flows (that is - skip any extra inspection - process this flow as quickly as possible).

FTD will process tunneled traffic based on the Default Prefilter Policy setting, which by default is to analyze all tunnel traffic:

GRE
IP in IP
IPv6 in IP
Teredo tunneling (UDP 3544)

This policy applies by default to any FTD device managed by FMC.

If you wanna have a look as to what the default prefilter policy contains, just connect to the FTD management IP, go to LINA CLI and do a show access-list. In the example below, look at lines 8 to 13 including.

Cisco Firepower Threat Defense for VMware v7.2.0 (build 82)

> system support diagnostic-cli 
Attaching to Diagnostic CLI ... Press 'Ctrl+a then d' to detach.
Type help or '?' for a list of available commands.

ftdv# term pager 24
ftdv# sh access-list
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
            alert-interval 300
access-list CSM_FW_ACL_; 50 elements; name hash: 0x4a69e3f3
access-list CSM_FW_ACL_ line 1 remark rule-id 268443682: PREFILTER POLICY: FTDv-Prefilter
.... CUSTOM RULES.... (PART OF PREFILTER)
access-list CSM_FW_ACL_ line 7 remark rule-id 268443671: PREFILTER POLICY: FTDv-Prefilter
access-list CSM_FW_ACL_ line 8 remark rule-id 268443671: RULE: DEFAULT TUNNEL ACTION RULE
access-list CSM_FW_ACL_ line 9 advanced permit ipinip any any rule-id 268443671 (hitcnt=0) 0xf5b597d6 
access-list CSM_FW_ACL_ line 10 advanced permit udp any eq 3544 any range 1025 65535 rule-id 268443671 (hitcnt=0) 0x46d7839e 
access-list CSM_FW_ACL_ line 11 advanced permit udp any range 1025 65535 any eq 3544 rule-id 268443671 (hitcnt=0) 0xaf1d5aa5 
access-list CSM_FW_ACL_ line 12 advanced permit 41 any any rule-id 268443671 (hitcnt=0) 0x06095aba 
access-list CSM_FW_ACL_ line 13 advanced permit gre any any rule-id 268443671 (hitcnt=0) 0x52c7a066 
access-list CSM_FW_ACL_ line 14 remark rule-id 268457986: ACCESS POLICY: FTDv-ACP - Mandatory
......... CUSTOM RULES.... (PART OF MANDATORY SECTION OF ACP)
.....

BR,

Octavian

CiscoBrownBelt · ‎03-30-2023

Right, so the thing is, just about all the pre-filter rules have 0 hits and the default rule shown in screenshot above has all the hits.
I don't have any tunneled connections. I am basically trying to confirm which rules are not actually needed. Thing is, the normal ACL rules don't have hits on most either, I am having hard time confirming just which rule traffic is applied to (not so familiar how to do it on non-ASA). Based on routing, it supports traffic must come through External interface but then if I create test rule for this traffic and apply to external interface it never gets hit. I am basically trying to clean up and tighten up rules in the FTD.

Here is cli example:

access-list CSM_FW_ACL_ line 29 advanced permit tcp XX_host XXX.10 ifc External host XXX21 eq 8080 rule-id 268444675 (hitcnt=0) 0x3c4e8cbe

CiscoBrownBelt · ‎03-30-2023

Are pre-filter rules configured in the FMC applied on the FMC and not a device managed by FMC such as the FTD correct?

Wouldn't the default rule shown be DENY ANY?

Also, when doing packet-tracer to try and confirm which rule allows certain traffic in, I see the following. Would it mean some other type policy is allowing this traffic? How do I confirm what it is?

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Octavian Szolga · ‎03-31-2023

Hi,

Prefilter rules are applied from FMC to FTD. FTD is the device which actually evaluates prefilter and ACP rules.

Read carefully what I've described above regarding prefilter rules. The default action is not deny.
Prefilter rules are processed before ACP rules, that's why the default action is to analyse all tunnelled traffic. Analyse means check ACP and see which rule you're hitting. The ACP may have an IPS or a file policy attached for deeper inspection.

Check if you're using a prefilter policy - other than default prefilter and also, check what is the default action for your ACP policy.

BTW - What device you're using? Is it ASA with Firepower Services or FTD?

BR,

Octavian

CiscoBrownBelt · ‎03-31-2023

Hi, yes there are many pre-filter policies - I am trying to determine what is not needed as many show ZERO hits but I am having trouble confirming exactly how traffic is being allowed in. I don't have any tunneled traffic.

It is FTD2140 managed by FMC.

Eric R. Jones · ‎03-30-2023

Hello, Tried the above commands but it failed to provide the ftd> prompt. Is this an FTD running FDM and the FXOS? Ours is managed by the FMC and when I entered the system support diagnostic-cli it went to a different prompt. I can run the show access-list command without having to run the support command. Unfortunately setting the term pager has never worked.

Octavian Szolga · ‎03-31-2023

Hi,

The above commands were executed on a virtual FTD managed by FMC, but I also have hardware platforms (2100) which behave exacly the same. I don't use FDM.

The approach will be different if your device is a 4100 series device because it's using FXOS and Firepower Chassis Manager.

CiscoBrownBelt · ‎03-31-2023

FTD managed via FMC.

Strange, I can set terminal pager... in diagnostic-cli.

I am trying to determine what is not needed as many show ZERO hits but I am having trouble confirming exactly how traffic is being allowed in. I don't have any tunneled traffic.

tvotna · ‎03-31-2023

Ignore this ones:

access-list CSM_FW_ACL_ line 9 advanced permit ipinip any any rule-id 268443671 (hitcnt=0) 0xf5b597d6 
access-list CSM_FW_ACL_ line 10 advanced permit udp any eq 3544 any range 1025 65535 rule-id 268443671 (hitcnt=0) 0x46d7839e 
access-list CSM_FW_ACL_ line 11 advanced permit udp any range 1025 65535 any eq 3544 rule-id 268443671 (hitcnt=0) 0xaf1d5aa5 
access-list CSM_FW_ACL_ line 12 advanced permit 41 any any rule-id 268443671 (hitcnt=0) 0x06095aba 
access-list CSM_FW_ACL_ line 13 advanced permit gre any any rule-id 268443671 (hitcnt=0) 0x52c7a066

They're used to send traffic which goes over unencrypted tunnels to Snort for analysis. Snort will scan ACP rules from the beginning to find a match for encapsulated packets (by inner IP header, etc.).

This Lina ACE was created from a regular ACP rule, not from a pre-filter policy rule:

access-list CSM_FW_ACL_ line 29 advanced permit tcp XX_host XXX.10 ifc External host XXX21 eq 8080 rule-id 268444675 (hitcnt=0) 0x3c4e8cbe

Actually, you're asking very good question about hitcounts. Perhaps @Octavian Szolga or @Eric R. Jones or other members can provide input. The question is: if hitcount in the above output is zero, does this mean that corresponding ACP rule with rule-id 268444675 has never been hit? I'm not sure. I'm not sure that Lina increments hitcount when Snort verdict is received (which includes Snort ACP rule-id which was hist). Instead, I believe that Lina increments its ACL hitcount when connection hits its ACE (first match in the global ACL). Snort ACP rules may have many more conditions than Lina ACLs, e.g. AppID, so the Lina ACE which was hit by the SYN may not correspond to the actual ACP rule which processed user traffic and resulted in a Snort verdict...

Or I'm just overheated on Friday.

Octavian Szolga · ‎04-03-2023

Hi,

I understand your point, and I totally agree.
Regarding your question, after doing some tests, I've come to the conclusion that snort does not update any LINA counters and the reason is simple: each engine keeps track of its own counters.

Let's say you have something like this:

rule 1 - allow dropbox and google (application conditions = snort = appid)
rule 2 - allow DNS (L3/L4 condition - LINA - not very interesting for snort)
rule 3 - deny any

These rules can be seen using a show access-list command either at CLISH prompt (>)or at LINA level (#), but the output is LINA related, not snort.
Same or almost all rules are also present at snort level - you can see them using the following commands:

> expert
admin@ftdv:~$ cat /var/sf/detection_engines/[press-TAB]/ngfw.rules

In order to identity the app, the firewall has to allow some packets in order to see any app specific payload or just to see the certificate that the server presents to the user and just extrapolate and confirm that this is the specific app.

Going back to the previous example, let's say I open a browser and go to cnn.com.
LINA will match rule 1 (it has no app knowledge - L3/L4 filtering) - it will increase hitcount per rule (#show access-list), and will also send the packets to SNORT for analysis.
Somewhere - at the 6th or 7th packet - SNORT will see that the server is cnn.com (based on server cert) and not dropbox or google and will reclassify the flow, actually searching the rest of the rules.

Rule 2 is no match, rule 3 is a match.

Not sure if rule 3 will have its hitcount increased at LINA level, but you should see a hitcount at SNORT level for rule 3, not rule 1.

At LINA level, rule1 will have a high hitcount, but at the same time, at Snort level, same rule will have a very low hitcount.

Checks:
>show access-list
(grep for your IP and see the snort ID for rule 1; also check hitcount - this line will have a high hitcount)

>show rule hits
(grep for the previously discovered snort ID - this line will have a hitcount that refers only to those sessions which actually belong 100% to all rule conditions (L7 including) - low hitcount

BR,

Octavian

CiscoBrownBelt · ‎04-04-2023

Great info! I am going to do what you described and get back to everyone.

When entering the /cat command, presing tab after detection_engines/ enters a string of numbers then I put ngfw.rules at the end, but command is not found.

Should be entering the snort rule ID or something found in packet-tracer for certain traffic or rules I am trying to analyze?

Octavian Szolga · ‎04-04-2023

Hi,

The command is cat, not /cat. You want to view the file.

Regarding the content of ngfw.rules, I'm not sure it will be of any use to you.

It will show you the rules expressed in a different format, not LINA based.

BR,

Octavian

CiscoBrownBelt · ‎04-05-2023

Sorry that is what I meant. Must of had a typo as it worked this time and produced the normal output - sorry I am not good with Linux.

Trying to analyze things now and will post up. Is there a good way to match ACLs view on CLI to ACLs viewed on FMC given I don't see the Rule ID? You know instead of trying to look at the objects and stuff it references?