Re: ASA 5545-X SFR Firepower Module not logging 'would be blocked' in connection events

Mike Pennycook · ‎05-11-2019

Hi All

Hope you're well

We have an SFR/Firepower SSD installed in an ASA 5545-X in monitor only mode:

class-map SFR
match any

policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect netbios
inspect tftp
inspect pptp
inspect icmp
inspect sip
class netflow-export-class
flow-export event-type all destination 172.16.72.11
class SFR
sfr fail-open monitor-only

As I understand it this will copy traffic to the SFR module but not allow it to tell the ASA to either block or allow.

However in this mode we should still be able to see if the SFR module would have blocked the traffic or not.

I can see traffic entering the SFR module and it is seen in the connection events, however all traffic only matches 1 ACL, which is 'Monitor Allowed Traffic'. I have created lots of other ACLs which I would expect the traffic to match, and this is what I would like to test before I set the SFR to inline mode.

My question is why are the connection events for this SFR module only showing up matching 1 ACL?

Also how would the SFR module display traffic that it would block, provided that it matches the right ACL?

Thanks

Marvin Rhoads · ‎05-11-2019

Firepower Access Control Policy (ACP) entries work on first match logic. That is, they are evaluated from top to bottom and, once a match occurs, no further entries are evaluated.

If the ACP entry results in a block action from the module's perspective it will be noted as such in the connection events table (as seen in asdm or FMC depending on which you are using for management). There difference is that, with "monitor-only" in the ASA configuration the ASA will not honor any message (i.e. to drop or reset the connection or flow) coming from the Firepower module.

GRANT3779 · ‎05-11-2019

I always thought that the monitor action within an ACP would initially track/log network traffic and then move the traffic onto the next rule for evaluation.
I'm aware that the monitor-only mode when redirecting traffic to the sfr is similar to a span port, but the monitor action in the ACP, i always thought just collected some data then passed onto other rules?

Rule 1: Monitor evaluates traffic first. Monitor rules track and log network traffic but do not affect traffic flow. The system continues to match traffic against additional rules to determine whether to permit or deny it.

Mike Pennycook · ‎05-12-2019

Hi Grant,

Thanks for your input

With regards to the action defined in the access control rules, all my rules have an action of either 'block' or 'allow', I haven't configured any rules applied to this SFR module with an action of monitor. You will see in my other reply in the attached picture that traffic matches a rule that is named "monitor allowed traffic". This is from connection events in the FMC. All traffic is matching this, and the action I can see for that rule is allow (i can only see that it has an action of allow from the logs, I can't find this rule anywhere in the access control policy however)

GRANT3779 · ‎05-12-2019

I misunderstood and thought you had a monitor rule at top of your ACP. I understand what you see now.

I actually have access to a pair of ASAs which are using the monitor-only mode for redirected firepower traffic but won't be able to check the FMC until tomorrow, just to see if it exhibits similar behaviour. Will let you know if you still don't have an explanation by then.

Out of interest, in your connection events, where there is an action column, does it say anything such as 'would have been dropped' for any flows.

Mike Pennycook · ‎05-12-2019

Hi Grant,

Yes please, that would be much appreciated, thanks

I just checked, for that access control policy there are only a few flows that seem to be blocked by the security intelligence policy, please see the attached picture. However the field for the access control rule is blank.

I filtered the logs for any other blocks, nothing came up just what's in the attached screenshot

Thanks

Mike Pennycook · ‎05-12-2019

Hi Marvin,

Thanks very much for your response

We are using FMC to manage the SFR module on the ASA 5545-X. There is an access control policy applied to that module, but in the rules I don't see rule which is being hit constantly. I check this using the connection events in the FMC.

Please see the attached picture, which shows what rule is being hit. I can't find this rule in the access control policy applied to this SFR module. I did a search in the window where you have all the rules configured for 'monitor' and it isn't there, and also not in the prefilter policy.

It seems this is being configured elsewhere?

At the moment it's fine that the ASA would not honour any block/allow verdict from the SFR module, but for evaluation purposes I wanted to know how accurate my access control policy was before putting it inline mode, so would like to see traffic matching the other rules.

Marvin Rhoads · ‎05-12-2019

Hmm that does look a bit strange to me as well.

I can't say I have dug into one of those setups deeply thought so I may be mistaken about the operational behavior of the ACP. According to what I have been taught (reference "Firepower Threat Defense by @Nazmul Rajib - specifically Chapter 12), using the "Monitor only" command in the ASA service policy is equivalent to setting up a Firepower device in "inline tap" mode - i.e. we should still see Allow, Block etc. as actions in the connection events even though the module isn't affecting the actual flow through the ASA - it's only looking at a copy of the traffic.

Can you check a flow using the "system support firewall-engine-debug" command from the sensor's cli? (That's roughly equivalent to packet-tracer on an ASA.)

Mike Pennycook · ‎05-12-2019

Hi Marvin,

That's my understanding as well reading up on the topic. I have that book too but unfortunately not with me today, but I'll have it tomorrow.

Thanks for suggesting the command, I can see some evidence of that rule being hit:

x.x.x.x-52630 > x.x.x.x-443 6 AS 0 I 2 pending rule order 1, 'Malicious Traffic Monitor', AppID
x.x.x.x-52630 > x.x.x.x-443 6 AS 0 I 2 Starting with minimum 0, id 0 and SrcZone first with zones -1 -> -1, geo 0 -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 0, payload client 0, misc 0, user 9999997, icmpType 0, icmpCode 0
x.x.x.x-52630 > x.x.x.x-443 6 AS 0 I 2 pending rule order 1, 'Malicious Traffic Monitor', AppID
x.x.x.x-52630 > x.x.x.x-443 6 AS 0 I 2 deleting firewall session
x.x.x.x-52630 > x.x.x.x-443 6 AS 0 I 2 Starting with minimum 0, id 0 and SrcZone first with zones -1 -> -1, geo 0 -> 0, vlan 0, inline sgt tag: 0, ISE sgt id: 0, svc -1, payload -1, client -1, misc -1, user 9999997, icmpType 150, icmpCode 187
x.x.x.x-52630 > x.x.x.x-443 6 AS 0 I 2 no match rule order, 'Malicious Traffic Monitor', app s=-1 c=-1 p=-1 m=-1
x.x.x.x-52630 > x.x.x.x-443 6 AS 0 I 2 match rule order 2, 'Monitor Allowed Traffic', action Allow
x.x.x.x-43294 > x.x.x.x-443 6 AS 0 I 2 new firewall session
x.x.x.x-43294 > x.x.x.x-443 6 AS 0 I 2 Starting with minimum 0, id 0 and SrcZone first with zones -1 -> -1, geo 0 -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 0, icmpCode 0
x.x.x.x-43294 > x.x.x.x-443 6 AS 0 I 2 pending ruleder 1, 'Malicious Traffic Monitor', AppID
x.x.x.x-43294 > x.x.x.x-443 6 AS 0 I 2 Starting with minimum 0, id 0 and SrcZone first with zones -1 -> -1, geo 0 -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 0, payload 0, client 0, misc 0, user 9999997, icmpTyp 0, icmpCode 0
x.x.x.x-43294 > x.x.x.x-443 6 AS 0 I 2 pending rule order 1, 'Malicious Traffic Monitor', AppID
x.x.x.x-43294 > x.x.x.x-443 6 AS 0 I 2 Starting with minimum 0, id 0 and SrcZone first with zones -1 -> -1, geo 0 -> 0, vlan 0, inline sgt tag: untagd, ISE sgt id: 0, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 0, icmpCode 0
x.x.x.x-43294 > x.x.x.x-443 6 AS 0 I 2 pending rule order 1, 'Malicious Traffic Monitor', AppID
x.x.x.x-43294 > x.x.x.x-443 6 AS 0 I 2 Starting with minimum 0, id 0 anrcZone first with zones -1 -> -1, geo 0(0) -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 1122, payload 0, client 1296, misc 0, user 9999997, min url-cat-list 0-0-0, url , xff
x.x.x.x-43294 > x.x.x.x-443 6 AS 0 I 2 skipping pending web app rule order 1, 'Malicious Traffic Monitor', app s=1122 c=1296 p=0 m=0
x.x.x.x-43294 > x.x.x.x-443 6 AS 0 I 2 match rule order 2, 'Monitor Allowed Traffic', action Allow
x.x.x.x-43294 > x.x.x.x-443 6 AS 0 I 2 allow action
x.x.x.x-43294 > x.x.x.x-443 6 AS 0 I 2 deleti firewall session
x.x.x.x-43889 > x.x.x.x-80 6 AS 0 I 1 new firewall session
x.x.x.x-43889 > x.x.x.x-80 6 AS 0 I 1 Starting with minimum 0, id 0 and SrcZone first with zones -1 -> -1, geo 0 -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 0, payload 0, client 0, misc 0, user 9999997, icmpType 0, icmpCode 0

One other thing I noticed was the ASA that I logged into was the active one of the pair. Once I consoled into the SFR module I see that the SFR module is standby, on the active ASA... ?

output from active ASA, consoled into it's SFR module:

> show summary
-----[ firepowerstandby.x.com ]------
Model : ASA5545 (72) Version 6.2.3 (Build 83)
UUID : d076d1ea-7c18-11e8-aaaf-9d0c1fe30c83
Rules update version : 2017-09-13-001-vrt
VDB version : 290
----------------------------------------------------

------------------[ policy info ]-----------------
Access Control Policy : Corporate Firewall

----------------------------------------------------

---------------[ snort version info ]---------------
Snort Version : 2.9.12 GRE (Build 136)
libpcap Version : 1.1.1
PCRE Version : 7.4 2007-09-21
ZLIB Version : 1.2.5
----------------------------------------------------

> show interfaces
----------------------------------------------------

>

Now if I login to the standby ASA and it's SFR module:

> show summary
---------[ firepower.x.com ]---------
Model : ASA5545 (72) Version 6.2.3 (Build 83)
UUID : c625163a-5ef8-11e8-92f0-c998cd8c1268
Rules update version : 2017-09-13-001-vrt
VDB version : 290
----------------------------------------------------

------------------[ policy info ]-----------------
Access Control Policy : Corporate Firewall

--------------------[ a1 ]---------------------
Physical Interface : GigabitEthernet0/0
Type : ASA
Security Zone : A1
Status : Enabled
Load Balancing Mode : N/A
------------------[ b1 ]-------------------
Physical Interface : GigabitEthernet0/1.275
Type : ASA
Security Zone : B1
Status : Enabled
Load Balancing Mode : N/A
--------------------[ c1 ]---------------------
Physical Interface : GigabitEthernet0/1.600
Type : ASA
Security Zone : C1
Status : Enabled
Load Balancing Mode : N/A
------------------[ d1 ]-------------------
Physical Interface : GigabitEthernet0/2
Type : ASA
Security Zone : D1
Status : Enabled
Load Balancing Mode : N/A
--------------------[ e1 ]--------------------
Physical Interface : GigabitEthernet0/3
Type : ASA
Security Zone : E1
Stus : Enabled
Load Balancing Mode : N/A
---------------------[ f1 ]----------------------
Physical Interface : GigabitEthernet0/4
Type : ASA
Security Zone : F1
Status : Enabled
Load Blancing Mode : N/A
------------------[ g1 ]------------------
Physical Interface : GigabitEthernet0/5.561
Type : ASA
Security Zone :G1
Status : Enabled
Load Balancing Mode : N/A
------------------[ h1 ]------------------
Physical Interface : GigabitEthernet0/.563
Type : ASA
Security Zone : H1
Status : Enabled
Load Balancing Mode : N/A
------------------[ i1 ]------------------
Physical Interface : GigabitEthernet0/5.564
Type : ASA
Security Zone : I1
Status : Enabled
Load Balancing Mode : N/A
----------------[ j1 ]----------------
Physical Interface : GigabitEthernet0/5.565
Type : ASA
Security Zone : J1
Status : Enabled
Load Balancing Mode : N/A
--------------[ k1 ]---------------
Physical Interface : GigabitEthernet0/5.566
Type : ASA
Security Zone : K1
Status : Enabled
Load Balancing Mode : N/A
------------------[ l1 ]-------------------
Physical Interface : GigabitEthernet1/0
Type : ASA
Security Zone : L1
Status : Enabled
Load Balancing Mode : N/A
---------------------[ cplane ]---------------------
IPv4 Address : 127.0.4.1
----------------------[ eth0 ]----------------------
Physical Interface : eth0
Type : Management
Status : Enabled
MDI/MDIX : Auto
MTU : 1500
MAC Address : 58:F3:9C:F7:21:B6
IPv4 Address : x.x.x.x
----------------------[ eth1 ]----------------------
Physical Interface : eth1
Type : Management
Status : Disabled
Link Mode : Autoneg
MDI/MDIX : Auto
MTU : 1500
MAC Address : 52:54:00:12:34:56
----------------------[ tun1 ]----------------------
IPv6 Address : fdcc::bd:0:ffff:a9fe:1/64
---------------------[ tunl0 ]----------------------
----------------------------------------------------

---------------[ snort version info ]---------------
Snort Version : 2.9.12 GRE (Build 136)
lpcap Version : 1.1.1
PCRE Version : 7.4 2007-09-21
ZLIB Version : 1.2.5
----------------------------------------------------

>

I wonder if the active ASA having the standby SFR module would have any impact on whether it reports an allow or block?

As a side note, I would have expected the module to fail over with the failover status of the ASA

Mike Pennycook · ‎05-12-2019

Just read another post on the SFR module where Marvin mentioned these modules have no concept of active/standby:

https://community.cisco.com/t5/firepower/firepower-failover-asa5545x/td-p/2732328

However I was confused as to why one module is able to report it's interfaces and the other isn't

GRANT3779 · ‎05-13-2019

Hi Mike,

The FMC is not showing the same as yours. The ASAs reporting into this FMC are using the monitor-only when redirecting traffic to the SFR. What I am seeing is attached which is what I would expect.

Mike Pennycook · ‎05-13-2019

Hi Grant,

You are right, I've spent time with TAC today and it was found that the SFR module on the active ASA was corrupt. As such I need to re-image it, but having failed over the ASA and with traffic passing through the other SFR module - it's working as expected and matching the ACLs! Like your screenshot!

Thanks very much!

Marvin Rhoads · ‎05-13-2019

Thanks for sharing the resolution. That's quite disconcerting to have a "silent failure" like that.

As you discovered, the Firepower service modules are "always on". The "firepowerstandby" prompt you saw is simply the hostname the person assigned when setting it up. It's locally significant only and has nothing to do with HA or active-standby per se.

FTD devices can act as HA pairs and then one unit is completely standby, just like an ASA pair without a service module in the mix.