Firepower FTD ACP rule Block action

-

FTD LINA engine: A global  ACL named as CSM_FW_ACL_
FTD Snort engine: Access Control (AC) rules in the /var/sf/detection_engines/UUID/ngfw.rules



1. Block rule uses L4 condition (Destination Port TCP 80)

LINA rule:
access-list CSM_FW_ACL_ remark rule-id 268434433: L4 RULE: Rule1
access-list CSM_FW_ACL_ advanced deny tcp ifc Inside object 10.10.10.0_24 ifc Outside object Website-203.0.113.1 eq www rule-id 268434433

SNORT Rule:
# Start of AC rule.
268434433 deny 2 10.10.10.0 24 any 1 203.0.113.1 32 80 any 6
268434432 deny any any  any any any  any any any
# End of AC rule.

The behavior is same with ASA rule, SYN will be dropped by FTD, no packet passes though FTD, no connection entry in connection table.



2. Block rule uses L7 condition (Application HTTP)


    LINA rule:
access-list CSM_FW_ACL_ line 9 remark rule-id 268434433: L7 RULE: Rule1
access-list CSM_FW_ACL_ line 10 advanced permit ip ifc Inside object 10.10.10.0_24 ifc Outside object Website-203.0.113.1 rule-id 268434433 (hitcnt=0) 0xc3c58394
  access-list CSM_FW_ACL_ line 10 advanced permit ip ifc Inside 10.10.10.0 255.255.255.0 ifc Outside host 203.0.113.1 rule-id 268434433 (hitcnt=0) 0xc3c58394

   Snort rule:
   # Start of AC rule.
268434433 deny 2 10.10.10.0 24 any 1 203.0.113.1 32 any any any  (appid 676:1)
268434432 deny any any  any any any  any any any

LINA rule is permit action because LINE cannot determine that session uses HTTP, need permit and pass it to SNORT engine.
In order for SNORT engine to determine the application, a few packets are allowed to pass though FTD.
From below capture, we can see TCP connection actually is created between the client and the server,  so there will be a connection entry in conn table, after that packets are blocked by FTD.

ftd# sh capture IN

 76 packets captured

    1: 20:21:27.682917       10.10.10.2.49178 > 203.0.113.1.80: S 1954500335:1954500335(0) win 8192
   2: 20:21:27.741462       203.0.113.1.80 > 10.10.10.2.49178: S 3683251406:3683251406(0) ack 1954500336 win 4128
   3: 20:21:27.742744       10.10.10.2.49178 > 203.0.113.1.80: . ack 3683251407 win 65520
   4: 20:21:27.744254       10.10.10.2.49178 > 203.0.113.1.80: P 1954500336:1954500644(308) ack 3683251407 win 65520
   5: 20:21:28.045575       10.10.10.2.49178 > 203.0.113.1.80: P 1954500336:1954500644(308) ack 3683251407 win 65520
   6: 20:21:28.654018       10.10.10.2.49178 > 203.0.113.1.80: P 1954500336:1954500644(308) ack 3683251407 win 65520
   7: 20:21:29.856904       10.10.10.2.49178 > 203.0.113.1.80: P 1954500336:1954500644(308) ack 3683251407 win 65520
   8: 20:21:31.056713       10.10.10.2.49178 > 203.0.113.1.80: P 1954500336:1954500644(308) ack 3683251407 win 65520
   9: 20:21:32.261400       10.10.10.2.49178 > 203.0.113.1.80: P 1954500336:1954500644(308) ack 3683251407 win 65520
  10: 20:21:34.663738       10.10.10.2.49178 > 203.0.113.1.80: P 1954500336:1954500644(308) ack 3683251407 win 65520
  11: 20:21:37.751105       10.10.10.2.49178 > 203.0.113.1.80: . 1954500335:1954500336(1) ack 3683251407 win 65520
  12: 20:21:38.764776       10.10.10.2.49178 > 203.0.113.1.80: . 1954500335:1954500336(1) ack 3683251407 win 65520
  13: 20:21:39.466833       10.10.10.2.49178 > 203.0.113.1.80: P 1954500336:1954500644(308) ack 3683251407 win 65520
  14: 20:21:39.763083       10.10.10.2.49178 > 203.0.113.1.80: . 1954500335:1954500336(1) ack 3683251407 win 65520
  15: 20:21:40.761587       10.10.10.2.49178 > 203.0.113.1.80: . 1954500335:1954500336(1) ack 3683251407 win 65520
  16: 20:21:41.759573       10.10.10.2.49178 > 203.0.113.1.80: . 1954500335:1954500336(1) ack 3683251407 win 65520
  17: 20:21:42.784886       10.10.10.2.49178 > 203.0.113.1.80: . 1954500335:1954500336(1) ack 3683251407 win 65520
  18: 20:21:43.772115       10.10.10.2.49178 > 203.0.113.1.80: . 1954500335:1954500336(1) ack 3683251407 win 65520
  19: 20:21:44.797215       10.10.10.2.49178 > 203.0.113.1.80: . 1954500335:1954500336(1) ack 3683251407 win 65520
  20: 20:21:45.784810       10.10.10.2.49178 > 203.0.113.1.80: . 1954500335:1954500336(1) ack 3683251407 win 65520
  21: 20:21:46.794926       10.10.10.2.49178 > 203.0.113.1.80: . 1954500335:1954500336(1) ack 3683251407 win 65520
  22: 20:21:47.797688       10.10.10.2.49178 > 203.0.113.1.80: R 1954500644:1954500644(0) ack 3683251407 win 0
ftd# sh capture OUT

 21 packets captured

    1: 20:21:27.698419       203.0.113.2.49178 > 203.0.113.1.80: S 3921820917:3921820917(0) win 8192
   2: 20:21:27.730003       203.0.113.1.80 > 203.0.113.2.49178: S 1793103879:1793103879(0) ack 3921820918 win 4128
   3: 20:21:27.744163       203.0.113.2.49178 > 203.0.113.1.80: . ack 1793103880 win 65520
   4: 20:21:27.947582       203.0.113.1.80 > 203.0.113.2.49178: . ack 3921820918 win 4128

Use the flowing command to trace each packet:
LINA engine:
show capture IN packet-number 1 trace
show capture IN packet-number 2 trace
show capture IN packet-number 3 trace
SNORT engine (need real traffic):
> system support trace

 Please specify an IP protocol: tcp
Please specify a client IP address: 10.10.10.2
Please specify a client port:
Please specify a server IP address: 203.0.113.1
Please specify a server port: 80
Enable firewall-engine-debug too? [n]:
Monitoring packet tracer debug messages
10.10.10.2-49190 - 203.0.113.1-80 6 Packet: TCP, SYN, seq 3491715646
10.10.10.2-49190 - 203.0.113.1-80 6 Session: new snort session
10.10.10.2-49190 - 203.0.113.1-80 6 AppID: service unknown (0), application unknown (0)
10.10.10.2-49190 > 203.0.113.1-80 6 Firewall: starting rule matching, zone 2 -> 1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0
10.10.10.2-49190 > 203.0.113.1-80 6 Firewall: pending rule-matching, 'Rule1', pending AppID
10.10.10.2-49190 > 203.0.113.1-80 6 Snort id 1, NAP id 1, IPS id 0, Verdict PASS

 10.10.10.2-49190 - 203.0.113.1-80 6 Packet: TCP, SYN, ACK, seq 2303702544, ack 3491715647
10.10.10.2-49190 - 203.0.113.1-80 6 AppID: service unknown (0), application unknown (0)
10.10.10.2-49190 > 203.0.113.1-80 6 Firewall: starting rule matching, zone 2 -> 1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0
10.10.10.2-49190 > 203.0.113.1-80 6 Firewall: pending rule-matching, 'Rule1', pending AppID
10.10.10.2-49190 > 203.0.113.1-80 6 Snort id 1, NAP id 1, IPS id 0, Verdict PASS

 10.10.10.2-49190 - 203.0.113.1-80 6 Packet: TCP, ACK, seq 3491715647, ack 2303702545
10.10.10.2-49190 - 203.0.113.1-80 6 AppID: service unknown (0), application unknown (0)
10.10.10.2-49190 > 203.0.113.1-80 6 Firewall: starting rule matching, zone 2 -> 1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0
10.10.10.2-49190 > 203.0.113.1-80 6 Firewall: pending rule-matching, 'Rule1', pending AppID
10.10.10.2-49190 > 203.0.113.1-80 6 Snort id 1, NAP id 1, IPS id 0, Verdict PASS

 10.10.10.2-49190 - 203.0.113.1-80 6 Packet: TCP, ACK, seq 3491715647, ack 2303702545
10.10.10.2-49190 - 203.0.113.1-80 6 AppID: service HTTP (676), application unknown (0)
10.10.10.2-49190 > 203.0.113.1-80 6 Firewall: starting rule matching, zone 2 -> 1, geo 0(0) -> 0, vlan 0, sgt 65535, user 9999997, url http://203.0.113.1/
10.10.10.2-49190 > 203.0.113.1-80 6 Firewall: block rule, 'Rule1', drop
10.10.10.2-49190 > 203.0.113.1-80 6 Snort: processed decoder alerts or actions queue, drop
10.10.10.2-49190 > 203.0.113.1-80 6 Snort id 1, NAP id 1, IPS id 0, Verdict BLACKLIST
10.10.10.2-49190 > 203.0.113.1-80 6 ===> Blocked by Firewall
Verdict reason is sent to DAQ


LINA engine packet-tracer will not be able to see the packet is dropped by FTD, as the SYN will pass through.
ftd# packet-tracer input inside tcp 10.10.10.2 4000 203.0.113.1 80

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

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

 Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 203.0.113.1 using egress ifc  Outside

 Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip ifc Inside object 10.10.10.0_24 ifc Outside object Website-203.0.113.1 rule-id 268434433
access-list CSM_FW_ACL_ remark rule-id 268434433: ACCESS POLICY: ACP - Mandatory
access-list CSM_FW_ACL_ remark rule-id 268434433: L7 RULE: Rule1
Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached

 Phase: 5
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:

 Phase: 6
Type: NAT
Subtype:
Result: ALLOW
Config:
object network 10.10.10.0_24
 nat (Inside,Outside) dynamic interface
Additional Information:
Dynamic translate 10.10.10.2/4000 to 203.0.113.2/4000

......

 Phase: 15
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 34, packet dispatched to next module

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

 Phase: 17
Type: SNORT
Subtype:
Result: ALLOW
Config:
Additional Information:
Snort Trace:
Packet: TCP, SYN, seq 985093668
Session: new snort session
AppID: service unknown (0), application unknown (0)
Firewall: starting rule matching, zone 2 -> 1, geo 0 -> 0, vlan 0, sgt 65535, user 9999997, icmpType 0, icmpCode 0
Firewall: pending rule-matching, id 268434433, pending AppID
Snort id 0, NAP id 1, IPS id 0, Verdict PASS
Snort Verdict: (pass-packet) allow this packet

 Phase: 18
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 203.0.113.1 using egress ifc  Outside

 Phase: 19
Type: ADJACENCY-LOOKUP
Subtype: next-hop and adjacency
Result: ALLOW
Config:
Additional Information:
adjacency Active
next-hop mac address aabb.cc00.3000 hits 28 reference 1

 Result:
input-interface: Inside
input-status: up
input-line-status: up
output-interface: Outside
output-status: up
output-line-status: up
Action: allow

In order to see if FTD blocks or permits the traffic, and which rule blocks or permit,  use the following SNORT engine command, this command needs client to generate real traffic.
> system support firewall-engine-debug

 Please specify an IP protocol: tcp
Please specify a client IP address: 10.10.10.2
Please specify a client port:
Please specify a server IP address: 203.0.113.1
Please specify a server port: 80
Monitoring firewall engine debug messages

 10.10.10.2-49193 > 203.0.113.1-80 6 AS 1 I 1 new firewall session
10.10.10.2-49193 > 203.0.113.1-80 6 AS 1 I 1 Starting with minimum 2, 'Rule1', and SrcZone first with zones 2 -> 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
10.10.10.2-49193 > 203.0.113.1-80 6 AS 1 I 1 pending rule order 2, 'Rule1', AppID
10.10.10.2-49193 > 203.0.113.1-80 6 AS 1 I 1 Starting with minimum 2, 'Rule1', and SrcZone first with zones 2 -> 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
10.10.10.2-49193 > 203.0.113.1-80 6 AS 1 I 1 pending rule order 2, 'Rule1', AppID
10.10.10.2-49193 > 203.0.113.1-80 6 AS 1 I 1 Starting with minimum 2, 'Rule1', and SrcZone first with zones 2 -> 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
10.10.10.2-49193 > 203.0.113.1-80 6 AS 1 I 1 pending rule order 2, 'Rule1', AppID
10.10.10.2-49193 > 203.0.113.1-80 6 AS 1 I 1 Starting with minimum 2, 'Rule1', and SrcZone first with zones 2 -> 1, geo 0(0) -> 0, vlan 0, inline sgt tag: untagged, ISE sgt id: 0, svc 676, payload 0, client 638, misc 0, user 9999997, min url-cat-list 0-0-0, url http://203.0.113.1/, xff
10.10.10.2-49193 > 203.0.113.1-80 6 AS 1 I 1 match rule order 2, 'Rule1', action Block
10.10.10.2-49193 > 203.0.113.1-80 6 AS 1 I 1 deny action
10.10.10.2-49193 > 203.0.113.1-80 6 AS 1 I 1 deleting firewall session













Comments

Post a Comment

Popular posts from this blog

Firepower FMC and FTD troubleshooting

-
 1. Display real time log on FMC or FTD: pigtail for example: pigtail | grep 192.168.2.20                      pigtail | grep sftunnel 2. Restart communication channel manage_procs.pl run it from  the sensor only, run it from FMC will reset all sensors' channel. This scripts are nice to be used when the FMC and FTD have communication problems like heartbeats are not received, policy deployment is failing or events are not received > expert ************************************************************** NOTICE - Shell access will be deprecated in future releases          and will be replaced with a separate expert mode CLI. ************************************************************** admin@FTD:~$ sudo su Password: root@FTD:/home/admin# manage_procs.pl ****************  Configuration Utility  **************  1   Reconfigure Correlator  2   Reconfigure and flush Correlator  3    Restart Comm. channel  4   Update routes  5   Reset all routes  6   Validate Network  0   Exit *****
Read more

ASA IKEv1 VPN troubleshooting Steps and Tips

-
  1. Phase I proposal mismatch  Run show crypto isakmp sa  Initiator: MM_WAIT_MSG2 Responder: No info  Most likely this is phase1 proposal mismatch, verify IKEv1 policy, other symptoms:   Initiator log: Information Exchange processing failed All configured IKE versions failed to establish the tunnel Initiator debug: Received an un-encrypted NO_PROPOSAL_CHOSEN notify message, dropping Responder log: Error processing payload: Payload ID Responder debug:  All SA proposals found unacceptable 2. IKE version mismatch:  Run  show crypto isakmp sa  no info at both initiator and responder Initiator log: Removing peer from correlator table failed, no match! Reason: User Requested  All configured IKE versions failed to establish the tunnel Initiator debug: Oakley begin quick mode PHASE 1 COMPLETED IKE Initiator sending 1st QM pkt Removing peer from correlator table failed, no match! Session is being torn down. Reason: User Requested Responder log: Tunnel Rejected: Conflicting protocols specified
Read more

Firepower 2100/1100 FTD/ASA initial setup, reimage, upgrade.

-
  Chassis FXOS and FTD share same management IP (default 192.168.45.45) Chassis FXOS (192.168.45.45) and ASA ()use different management IP although on same physical interface. SSH to FXOS/FTD are on FTD CLI prompt, go to FXOS using the  connect fxos  command Console to Chassis is on FXOS CLI prompt, go to FTD using the  connect ftd  command The Firepower 1100 does not support the FXOS Firepower Chassis Manager; only a limited CLI is supported for troubleshooting purposes. The Firepower 2100 runs an underlying operating system called the Firepower eXtensible Operating System (FXOS).  If you run ASA on Firepower 2100, ASA can be in the following modes: Appliance mode (the default after ASA 9.13)—Appliance mode lets you configure all settings in the ASA. Only advanced troubleshooting commands are available from the FXOS CLI. See the  FXOS troubleshooting guide  for more information. Firepower Chassis Manager is not supported . ciscoasa# connect fxos [admin] Connecting to fxos. Connected
Read more