Firepower Threat Defense

Tech Talk
Feature Overview
Abhishek Singh, Technical Marketing Engineer
Anant Mathur, Technical Marketing Engineer Manager
Eric Kostlan, Technical Marketing Engineer
Nanda Kumar, Technical Marketing Engineer

September 13th, 2017

 • Introduction
• Security Intelligence
• Application Visibility and
Control (AVC)
• Intrusion Prevention System
(IPS)
Agenda • Advanced Malware Protection
(AMP)
• Uniform Resource Locator
(URL) Filtering
• On-box Decryption
Introduction
Cisco NGFW and Firepower Threat Defense
(FTD)
Cisco Collective Security Intelligence Enabled

WWW
Advanced Malware
NGIPS Protection URL Filtering
High Availability

Analytics &
Automation

Network Firewall Built-in Network Identity-Policy Control

Application
Routing | Switching Profiling & VPN
Visibility & Control

4
Cisco Firepower
Historical perspective
• Snort created
• Created by Martin Roesch in 1998
• Snort is both an engine and a language
• Open source rapidly adopted and develops Snort
(currently more that 420,000 active members
• Sourcefire founded
• Founded in 2001 by Martin Roesch
• Created a commercial version of Snort
• Sourcefire acquires Immunet cloud based anti-malware vendor
• Acquisition completed 2011
• Cisco acquires Sourcefire
• Acquisition completed 2013 for $2,700,000,000

5
 Cisco Network Security Solutions
Other than FTD
• Adaptive Security Appliance (ASA)
• Best of breed traditional stateful firewall
• VPN concentrator (site-to-site, remote access and clientless)
• Managed by ASDM, CSM or CLI
• Firepower Next Generation IPS
• Best of breed IPS
• Based on open source Snort
• Managed by Firepower Management Center (aka FireSIGHT, aka Defense Center)
• ASA with Firepower services
• Combination of ASA with Firepower
• Contains all features of both products
• Requires 2 management consoles
• Packets are copied from ASA data plane to Firepower module
NGFW (FTD): ASA-Firepower Convergence
Security Application Convergence
ASA
• L2-L4 Stateful Firewall
• Scalable CGNAT, ACL, routing
• Application inspection
FirePOWER
• Threat-centric NGIPS
• AVC, URL Filtering for NGFW
• Advanced Malware Protection

Firepower Threat Defense (FTD)

• Converged NGFW/NGIPS image on Firepower 4100/9300 and ASA5500-X platforms
• Single point of management with Firepower Management Center
• Full FirePOWER functionality for NGFW/NGIPS deployments
• ASA Data Plane with TCP Normalizer, NAT, ACL, dynamic routing, failover functions
FTD Features
Threat NGFW ASA Management Licensing & Packaging
• IDS/IPS • Zone-based Unified Rule • Intra-Chassis Clustering • Off-box FMC • Single package with ASA
• Analytics Table with State Sharing • Diagnostic CLI and SF
• Dashboard • Objects • High Availability with • Domains with full RBAC • New Licensing Model
• Context Explorer • Active & Passive User State Sharing • On-Box WebUI (6.1) using Smart Licensing
• Event Views Identity/Auth • NAT • HA Management
• Network Map • App ID & Visibility • Switching • Clustering Management
• Event Views • URL Reputation • Routing • Device Inventory, Deploy
• Reports • Integrated SSL • Select ALG Functionality • Image Management
• File Trajectory
Decryption Policy • Firewall Basics • Estreamer
• Eventing • Syslog for Non-
• File Capture • Health Monitoring
• Syslog from device for connection Events
• Network AMP • Unified System
connection and IDS/IPS • Tunnel Policy (6.1)
• Dynamic Analysis Events
Authentication and
• Rate-limiting (6.1) Platform Settings
• Security Intelligence • Estreamer
• URL and DNS Blacklisting • Unified Navigation/Menu
• Rate-limiting (6.1) & Look and Feel
• DNS Sinkholing • YouTube EDU (6.1)
• File Pre-Classification • Google Safe Search (6.1)
using Clam AV
• Compliance Engine
• Inline and Passive Mode
Support
Security Intelligence
 Talos Collective Security Intelligence
Who

Event History
What

Where

When
Talos
How

Discover, Enforce, Harden Detect, Block, Defend Scope, Contain, Remediate

Firewall VPN NGIPS
Advanced Malware Protection
BEFORE NGFW UTM DURING Web Secuirty AFTER
Network Behavior Analysis
Secure Access + Identity Services Email Security
Application Visibility and Control
(AVC)
OpenAppID Overview
• What is OpenAppID?
• Application Visibility and Control (AVC) done the right way
• An open source application-focused detection language
• Enables users to create, share and implement custom application detection
• First for download as an extension of Snort 2.9.7 from http://www.snort.org
• Utilized in Firepower, starting with the 6.0 release
• Key advantages
• New simple language to detect apps
• Reduces dependency on vendor release cycles
• Build custom detections for new or specific
(ex. Geo-based) app-based threats
• Application-specific detail with security events
The AppID Preprocessor
• Identifies the application

• Generates appid attributes that can be used in snort rules.

alert tcp any any -> any any (msg:"FTP CWD to root"; appid:ftp;
pcre:"/cwd.*root/i"; gid:1000001; sid:1018758; rev:4; )

• Leverages Snort HTTP preprocessor for header extraction

• Generates application statistics

• Statistics are stored in Uniform2 format
• Statistics file can be read with the u2openappid or u2spewfoo commands
• Statistics can be forwarded to Syslog by using the u2streamer command

14
Lua Scripting Language
• OpenAppID preprocessor leverages the power of the Lua scripting language
• Application detectors are written using the Lua scripting language (not snort rules)
• Lua is a open-source scripting language.
• Lua is designed, implemented, and maintained by a team at PUC-Rio, the Pontifical Catholic
University of Rio de Janeiro in Brazil.
• Lua is the Portuguese word for moon.
• Benefits of Lua
• Proven – used in many industrial applications, including several Cisco products
• Powerful and fast – utilizes LuaJIT just-in-time compiler
• Portable and embeddable – well documented API
• Simple, lightweight, and small – under Linux, interpreter is 182K, libraries 244K
• See more at http://www.lua.org
Example of a Lua Script
--[[
detection_name: SampleAppDetector function DetectorInit(detectorInstance)
gDetector = detectorInstance;
version: 1
gAppId = gDetector:open_createApp("SampleApp");
description:
if gDetector.addPortPatternService then
Detects "cisco123" on port 8888 gDetector:addPortPatternService(proto,
--]] 8888,"cisco123",-1,gAppId);
end
require "DetectorCommon" end
local DC = DetectorCommon
local proto = DC.ipproto.tcp; function DetectorValidator()
DetectorPackageInfo = { end
name = "SampleAppDetector",
proto = proto, function DetectorClean()
server = { end
init = 'DetectorInit',
validate = 'DetectorValidator',
clean = 'DetectorClean',
minimum_matches = 1
}
}
Intrusion Prevention System
(IPS)
 Network
network
Snort Architecture DAQ libraries
High-level Snort architecture
Packet decoder
• Packet sniffer
• Packets are read using the Data AcQuisition library (DAQ)

• Packet decoder Preprocessors

• Decodes datalink, network and transport protocols

• Preprocessors
Detection engine
• Normalize traffic

• Detection engine
• Uses Snort rules to create signatures for threats Output module

• Output module
• Handles the task of writing and displaying events
Alert and log files
18
Preprocessors
• Preprocessors play a vital function in network traffic inspection
• Present packets to the detection engine in a contextually relevant way
• Normalize traffic
• Alert if they detect anomalous conditions as defined by their settings
• Major preprocessors include the following
• frag3 – Used to reassemble packet fragments prior to inspection
• stream5 – Used to reconstruct TCP data streams so that inspection can be done in the context of a
TCP conversation
• Protocol decoders – Normalize TCP streams including: telnet, ftp, smtp, and rpc.
• http_inspect – Normalizes http traffic
• DCE/RPC2 – Used to decode and desegment DCE traffic
• sfPortscan – Used to detect portscans

19
Network Preprocessor Execution Order

20
Detection Engine
• Consists of two components to perform inspection
• Rules builder
• Inspection component
• Rules builder
• On Snort startup, assembles rules into rule chains
• Optimizes rule matching by the inspection component
• Sources, destinations and port sources and destinations redundancies are eliminated
• Implements rules chains as linked lists
• Inspection component
• Matches traffic to a rule chain
• Further inspects traffic against the options in the matching rule chain

21
Snort Language
Overview
• A simple lightweight language for identifying
• Security policy violations
• Known network attacks and IDS/IPS evasion techniques
• Snort language supports event filters
• Limit – Alert on the a specified number of events during a specified time interval, then ignore events
for the rest of the specified time interval.
• Threshold – Only alert if the event is seen a specified number of times within a specified time
interval
• Communication between rules is accomplished using flowbits

Note: The snort engine is not restricted to the Snort language. It can use precompiled shared
objects in addition to Snort rules.

22
Snort Language
Sample Rule
Variables (set to “any” by default)

alert tcp $EXTERNAL_NET any -> $SQL_SERVERS 3306 Rule header

(msg:"SERVER-MYSQL Database COM_FIELD_LIST Buffer Overflow Alert
attempt"; text
flow:to_server,established; Flow attribute
content:"|04|"; depth:1; offset:4;
pcre:"/^[^\x0D\x0A\x00]{512}/iR";
Content search
metadata:policy max-detect-ips drop, Rule
service mysql; reference:cve,2010-1850; Metadata body
classtype:attempted-user;
sid:16703; rev:10; ) Signature ID and revision number
 Variable Sets
• Critical component
of IPS tuning
• Associated to
intrusion policies
in access control
policy rules
• Default variable set
is provided; custom
variable sets can
be created
• Support customized
variables to be used
in custom Snort rules

24
Host Attribute Table
• XML file associated with a particular IP address

• Specifies OS and service to port associations on the host

• Affect on preprocessors
• Frag3 and Stream5 – Uses OS information to determine policy, that is, the OS to emulate in packet
re-assembly.
• Application layer preprocessors – Users the service information to determine protocol to port
mapping.
• Affect on Snort rules through metadata attribute – see next slide

• Sourcefire builds Host Attribute Tables

• Manually
• Through network discovery

25
Snort Rule Metadata
• Example:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS
(msg:"MALWARE-CNC Win.Spyware.Rombertik outbound connection"; … ;
metadata:impact_flag red, policy balanced-ips drop, policy
security-ips drop, service http; … ; classtype:attempted-user;
sid:33161; rev:1;
• Open Source Snort
• Provides a way to annotate a rule
• Service attribute Host Attribute Table
• Sourcefire – makes additional use of
metadata attribute, including:
• Impact flag
• Action to take, based on intrusion policy

26
Life of a Flow (slide 1 of 2)
Simplified
• Packet sniffing and hardware processing

• Packet decoding

• Preprocessing
• Security Intelligence (IP blacklist and white list)
• Immediately mark flow as blocked or trusted
• Update hardware flow state
• Network layer preprocessors
• Defragmentation and stream re-assembly
• AppID
• Access control rules engine
• Network discovery
• Remaining preprocessors

27
Life of a Flow (slide 2 of 2)
Simplified
• Snort detection engine
• Leverages AppID preprocessor to select rules for relevant
applications
• Generates events
• If action is to block, mark the flow as blocked and update
hardware flow state
• File processing

28
Advanced Malware Protection
(AMP)
AMP for Networks
• Snort understands network protocols

• Files can be carved out of the network traffic

• AMP detection techniques can be applied to the file

• Hash lookups – both SHA 256 and Spero hashes
• Local malware analysis (Clam AV) on the firewall
• Submitting the file to Cisco Threat Grid for sandboxing
• File transfers can be blocked
• Based on file type – this can be determined using the first block of the file. The entire file will be
blocked.
• Based on malware verdict – this requires analyzing the entire file. Only the last piece of the file
transfer will be blocked.
Malware Detection Methods

All detection is less than 100%

One-to-One Fuzzy Machine Advanced Dynamic

Signature Finger-Printing Learning Analytics Analysis

Reputation Filtering and File Sandboxing

The AMP Everywhere
Architecture AMP Remote Endpoints

AMP Protection Across the Extended Network Threat Intelligence AMP for Endpoints
for an Integrated Threat Defense
Cloud

Threat Grid
AMP on Firepower NGIPS Malware Analysis + Threat AMP Private Cloud
Appliance Intelligence Engine Virtual Appliance
(AMP for Networks)

AMP on Web and Email

AMP on Cisco® ASA Firewall AMP for Endpoints Security Appliances
with Firepower Services

CWS/CTA

AMP on ISR with Firepower AMP on Cloud Web Security

Services and Hosted Email

CentOS, Red Hat

Windows OS Android Mobile Virtual MAC OS Linux for servers
and datacenters

AMP for Endpoints can be

launched from AnyConnect
An unknown file is present on
IP: 10.4.10.183, having been
downloaded from Firefox
At 10:57, the unknown file is
from IP 10.4.10.183 to IP:
10.5.11.8
Seven hours later the file is
then transferred to a third
device (10.3.4.51) using an
SMB application
The file is copied yet again
onto a fourth device
(10.5.60.66) through the same
SMB application a half hour
later
The Cisco Collective Security
Intelligence Cloud has learned
this file is malicious and a
retrospective event is raised
for all four devices
immediately.
At the same time, a device with
the FireAMP endpoint
connector reacts to the
retrospective event and
immediately stops and
quarantines the newly detected
malware
8 hours after the first attack,
the Malware tries to re-enter
the system through the
original point of entry but is
recognized and blocked.
Uniform Resource Locator (URL)
Filtering
URL Filtering
• Provides ability to block specific URLs or define policies based on the category
of the URL like Gambling, Social Media, Gaming etc.
• Provides visibility based on the categories of URL being visited by the users of
the network
URL Filtering Implementation
• HTTP or decrypted HTTPS
1. Snort identifies HTTP protocol
2. Snort parses HTTP request header – extracts URL
3. Looks up URL in local database – if miss, optionally can do a cloud lookup
• Un-decrypted HTTPS
1. Snort identifies SSL protocol
2. Snort parses SSL client hello and certificate – extracts FQDN from SNI or certificate
3. Looks up FQDN in local database – if miss, optionally can do a cloud lookup
On-box Decryption
Integrated SSL decryption
• Multiple Deployment modes
• Passive Inbound (known keys)
• Inbound Inline (with or without keys)
• Outbound Inline (without keys, MitM)
• Flexible SSL support for HTTPS & StartTLS based apps
• E.g. SMTPS, POP3S, FTPS, IMAPS, TelnetS
• Decrypt by URL category and other attributes
• Centralized enforcement of SSL certificate policies
• e.g. Blocking; self-signed encrypted traffic, SSL version, specific Cypher Suites,
unapproved mobile devices
Integrated SSL Decryption
• Multiple Deployment modes
• Passive Inbound (known keys)
• Inbound Inline (with or without keys)
• Outbound Inline (without keys, MitM)
• Support for HTTPS & StartTLS based apps
• SMTPS, POP3S, FTPS, IMAPS, TelnetS
• Provides enforcement of SSL certificate
policies
• Certificate status
Hardware
• SSL version
• specified cipher suites
 SSL Client Hello Manipulation
To ensure that Firepower is able to inspect encrypted sessions wherever possible, Firepower
participates in the initial SSL Client Hello handshake process.
• Client Hello modification enabled by default
• May be disabled using the FTD CLI
• May be modified, for example, by adding and deleting cipher suites and features
• To facilitate MitM, the following are removed from Client Hello:
• Unsupported ciphers
• Unsupported TLS options
• Unsupported TLS versions
• To help avoid possible decryption evasion, supports session resumption by stripping out existing
session IDs and tickets
Thank You
Firepower Threat Defense
Tech Talk
Architecture
Abhishek Singh, Technical Marketing Engineer
Anant Mathur, Technical Marketing Engineer Manager
Eric Kostlan, Technical Marketing Engineer
Nanda Kumar, Technical Marketing Engineer Manager

September 13th, 2017

 Architecture
Packet Flows

Agenda Deployment and Interface Modes

Resiliency options
Platform Overview
Architecture
FTD High-level overview
Firepower Threat Defense (FTD) merges 2 products:
ASA
Firepower (Snort)

Developed to solve 2 main problems:

Different management for ASA and FPR
Duplicated functions between ASA and FPR
FirePOWER on ASA vs FTD
FirePOWER on ASA
Requires 2 software images
2 Operating Systems on same HW
Duplicated functionality
2 management applications

FTD
Zero-copy packet inspection
Unified management (FMC/FDM)
Architecture Diagram
Modifications to ASA

• DP threads poll on local RX

queues first, exhausting local
work before polling remote
RX queues
• PDTS only load balances to
local Snort instances
FMC Management
Architecture
• Evolution of DC with CSM
components
• Deploys SF config files and ASA
delta CLI
• Communicates with device over SF
Tunnel
• Receives status events (health, HA /
Clustering, interface updates, etc.)
FTD Management interface
• FTD physical Management interface is divided into 2 logical sub-interfaces:
• diagnostic
• br1*
‘show int ip brief’

Sftunnel between
FMC/FTD is
terminated on br1 ‘show network’
FTD Management interface
• FTD br1 vs diagnostic subinterface comparison
br1 diagnostic
Purpose • Used in order to assign the FTD IP that will be • Provides remote access to ASA engine CLI
used for FTD/FMC communication (sftunnel) • Used as a source for ASA syslog, AAA messages etc
• Provides SSH access to the FTD box

Mandatory Yes, since it is used for FTD/FMC communication No and it is actually not recommended to configure it. The
(sftunnel terminates on it) recommendation is to use a data interface instead*

Verification From CLISH CLI: From ASA CLI:

> show network firepower# show interface ip brief
=======[ br1 ]======= Interface IP-Address OK? Method Status Protocol
State : Enabled ...
Channels : Management & Events Management1/1 192.168.1.1 YES unset up up
MAC Address : 18:8B:9D:1E:CA:7B
----------------------[ IPv4 ]-----------------
-----
Configuration : Manual
Address : 10.62.148.29
Netmask : 255.255.255.128
Broadcast : 10.62.148.127
Packet Flow
FTD Packet Processing – The big picture

1. A packet enters the ingress interface and it is handled by the ASA engine
2. If the policy dictates so the packet is inspected by the Snort engine
3. Snort engine returns a verdict (whitelist or blacklist) for the packet
4. The ASA engine drops or forwards the packet based on Snort’s verdict
• Snort engine runs 6.x code
• ASA engine runs 9.X.x code
 High Level Packet Processing on FTD
Trust
? Yes

No

Packet Early Advanced Egress Packet

Security Security details
Checks Checks verification

Note: Packets can be dropped at any of the 3 stages

Unified Access Control Policy
Policy L3/L4 L3/L4 L7 fields Action File, IPS policies
ID Source Destination

R1 S1 D1 Trust

R2 S2 D2 Deny Log

R3 S3 D3 App=Google+ Permit IPS-1, File-1

R4 S4 D4 URL=Games Warn File-2
R5 S5 D5 Permit IPS-2

ASA global access-group

Policy L3/L4 L3/L4 Action
ID Source Dest
NGFW Access Policy
Policy L3/4 L7 fields Action Profiles
R1 S1 D1 Trust ID fields

R2 S2 D2 Deny, Log
R3 … App=Google+ Permit IPS-1, File-1
R3 S3 D3 Permit
R4 S4 D4 Permit R4 … URL=Games Warn File-2

R5 S5 D5 Permit R5 … Permit IPS-2

FTD Packet Processing: Detailed
FTD Packet Processing: Ingress Interface

• Packet arrives on ingress interface.

• Input counters are incremented by NIC and periodically retrieved by CPU
• Similarly to classic ASA, input queue (RX ring) is an indicator of packet load
> show interface g1/2 detail
Interface GigabitEthernet1/2 "inside", is up, line protocol is up
Hardware is Accelerator rev01, BW 1000 Mbps, DLY 10 usec
IPS Interface-Mode: inline-tap, Inline-Set: Set1
47770671 packets input, 7620806887 bytes, 0 no buffer
Received 23734506 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
input queue (blocks free curr/low): hardware (1008/800)
output queue (blocks free curr/low): hardware (1023/985)
FTD Packet Processing: Connection Lookup

• ASA engine checks for existing connection

• If a match is found packet uses Fast Path bypassing basic checks
firepower# show capture CAPO packet-number 2 trace
2 packets captured
2: 12:51:51.094691 192.168.76.14 > 192.168.75.14: icmp: echo reply
...
Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found flow with id 1541, using existing flow
FTD Packet Processing: UN-NAT/Egress int.

• Egress interface determination

• In case there is Destination NAT (UN-NAT) the egress interface will be determined based on the
NAT rule, unless route lookup is preferred (identity NAT)
firepower# show capture DMZ packet-number 3 trace detail
Phase: 3
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (inside,dmz) source static Host-A Host-B
Additional Information:
NAT divert to egress interface inside
Untranslate 192.168.76.100/0 to 192.168.75.14/0
FTD Packet Processing: UN-NAT/Egress int.

• In case route lookup is taking place the ‘in’ entries of the ASP routing table will be checked to
determine the egress interface:
firepower# show asp table routing
route table timestamp: 449
in 192.168.75.0 255.255.255.0 inside
in 192.168.76.0 255.255.255.0 dmz
in 192.168.77.0 255.255.255.0 outside
in 5.5.5.5 255.255.255.255 via 192.168.77.1, outside
out 255.255.255.255 255.255.255.255 outside
out 5.5.5.5 255.255.255.255 via 192.168.77.1, outside
out 10.1.1.0 255.255.255.0 via 192.168.77.1, outside
FTD Packet Processing: Prefilter Policy

• Prefilter Policy got introduced in 6.1 version

• Serves 2 main purposes
1. Adds additional flexibility when it comes to handling tunneled traffic:
• GRE
• IP-in-IP
• IPv6-in-IP
• Teredo Port 3544
2. Provides Early Access Control (EAC) which allows a flow to bypass completely the Snort engine
FTD Packet Processing: Prefilter Policy

• Prefilter Policy got introduced in 6.1 version

• Serves 2 main purposes
1. Adds additional flexibility when it comes to handling tunneled traffic:
• GRE
• IP-in-IP
• IPv6-in-IP
• Teredo Port 3544
2. Provides Early Access Control (EAC) which allows a flow to bypass completely the Snort engine
FTD Packet Processing: Prefilter Policy

• Navigate to Policies > Access Control > Prefilter and create a Prefilter Policy

• Add one or more Tunnel or/and Prefilter (Early Access Control) rules and attach the Policy to ACP
FTD Packet Processing: Prefilter Policy
(tunneled)

• Classic ASA checks the outer IP header

• A FirePOWER device (Snort) checks the inner IP header
• FTD ASA code checks the outer IP header while the Snort engine checks the inner IP header
FTD Packet Processing: Prefilter Policy
(tunneled)

• Tunneled Rules provide 3 possible actions:

1. Block – Drops the tunneled traffic

2. Fastpath – Allows the tunneled traffic and bypasses the Snort Engine
3. Analyze – Will send the tunneled traffic to Snort Engine. Optionally allows traffic Tagging
 FTD Packet Processing: Prefilter Policy
(tunneled)

• How works the analyze action:

firepower# show access-list
access-list CSM_FW_ACL_ line 5 remark rule-id 268435473: RULE: Tunnel_Rule1
access-list CSM_FW_ACL_ line 6 advanced permit gre any any rule-id 268435473

root@FTD5506-1:/var/sf/detection_engines/UUID# cat ngfw.rules

# Start of tunnel and priority rules.
# These rules are evaluated by LINA. Only tunnel tags are used ..
268435473 allow any any any any any any any 47 (tunnel 2)
268434456 allow any any any any any any any 4 (tunnel -1)
268434456 allow any any any any any any any 41 (tunnel -1)
# End of tunnel and priority rules.
# Start of AC rule.
268435474 allow 2 any any any any any any any
268435468 allow any any any any any any any any (log dcforward) #
End of AC rule.
FTD Packet Processing: Prefilter Policy
(EAC)

• Early Access Control Rules provide 3 possible actions:

1. Block – Drops the traffic

2. Fastpath – Allows the traffic and bypasses the Snort Engine
3. Analyze – Will send the traffic to Snort Engine
FTD Packet Processing: Prefilter Policy

• Prefilter Rules are deployed to ASA as L3/L4 ACEs and are placed above the normal L3/L4 ACEs
firepower# show access-list
access-list CSM_FW_ACL_; 7 elements; name hash: 0x4a69e3f3
access-list CSM_FW_ACL_ line 1 remark rule-id 268434457: PREFILTER POLICY: FTD_Prefilter_Policy
access-list CSM_FW_ACL_ line 2 remark rule-id 268434457: RULE: Fastpath_Rule1
}
access-list CSM_FW_ACL_ line 3 advanced trust ip host 192.168.75.16 any rule-id 268434457 event-log both (hitcnt=0)
access-list CSM_FW_ACL_ line 4 remark rule-id 268434456: PREFILTER POLICY: FTD_Prefilter_Policy
access-list CSM_FW_ACL_ line 5 remark rule-id 268434456: RULE: DEFAULT TUNNEL ACTION RULE
EAC Prefilter
Rules

access-list CSM_FW_ACL_ line 6 advanced permit ipinip any any rule-id 268434456 (hitcnt=0) 0xf5b597d6
access-list CSM_FW_ACL_ line 7 advanced permit 41 any any rule-id 268434456 (hitcnt=0) 0x06095aba
access-list CSM_FW_ACL_ line 8 advanced permit gre any any rule-id 268434456 (hitcnt=2) 0x52c7a066
access-list CSM_FW_ACL_ line 9 advanced permit udp any any eq 3544 rule-id 268434456 (hitcnt=0) 0xcf6309bc
} Tunnel Prefilter
Rules

}
access-list CSM_FW_ACL_ line 10 remark rule-id 268434445: ACCESS POLICY: FTD5506-1 - Mandatory/1
access-list CSM_FW_ACL_ line 11 remark rule-id 268434445: L4 RULE: Block ICMP
access-list CSM_FW_ACL_ line 12 advanced deny ip host 10.1.1.1 any rule-id 268434445 event-log flow-start (hitcnt=0) 0x8bf72c63 L3/L4
access-list CSM_FW_ACL_ line 13 remark rule-id 268434434: ACCESS POLICY: FTD5506-1 - Default/1 ACEs
access-list CSM_FW_ACL_ line 14 remark rule-id 268434434: L4 RULE: DEFAULT ACTION RULE
access-list CSM_FW_ACL_ line 15 advanced permit ip any any rule-id 268434434 (hitcnt=410) 0xa1d3780e
FTD Packet Processing: L3/L4 ACL

• Advanced L3/L4 ASA ACL is an Access Control Policy (ACP) that is configured on FMC.
• Pushed as a global ACL (CSM_FW_ACL_) to ASA engine and as AC rules in
/var/sf/detection_engines/UUID/ngfw.rules file in Snort engine
firepower# show run access-list
access-list CSM_FW_ACL_ advanced deny ip host 10.1.1.1 any rule-id 268434445 event-log flow-start
firepower# show run access-group
access-group CSM_FW_ACL_ global

• 7 possible actions to the traffic:

FTD Packet Processing: L3/L4 ACL - Allow

• Allow Rule will be pushed to ASA engine as permit action and to Snort engine as allow action. The
rule ID correlates the ASA rules with the Snort rules
firepower# show access-list
access-list CSM_FW_ACL_ line 8 remark rule-id 268435456: L7 RULE: ACP_Rule1_Allow_ICMP_App
access-list CSM_FW_ACL_ line 9 advanced permit ip host 1.1.1.1 host 2.2.2.2 rule-id 268435456
access-list CSM_FW_ACL_ line 11 remark rule-id 268435457: L4 RULE: ACP_Rule2_Allow_ICMP_Type
access-list CSM_FW_ACL_ line 12 advanced permit icmp host 2.2.2.2 host 3.3.3.3 echo rule-id 268435457

root@FTD5506-1:/home/admin# cat /var/sf/detection_engines/27306154-256d-11e6-9fc9-180edde177c5/ngfw.rules

268435456 allow any 1.1.1.1 32 any any 2.2.2.2 32 any any any (appid 3501:1)
268435457 allow any 2.2.2.2 32 8 any 3.3.3.3 32 any any 1
FTD Packet Processing: L3/L4 ACL - Allow

• packet-tracer shows that ASA engine will send the packet to Snort engine for a Verdict
> packet-tracer input inside icmp 1.1.1.1 8 0 2.2.2.2

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip host 1.1.1.1 host 2.2.2.2 rule-id 268435456
access-list CSM_FW_ACL_ remark rule-id 268435456: ACCESS POLICY: FTD5506-1 - Mandatory/1
access-list CSM_FW_ACL_ remark rule-id 268435456: L7 RULE: ACP_Rule1_Allow_ICMP_App
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be reached
FTD Packet Processing: L3/L4 ACL - Allow

• Tracing a real packet will show the Snort Verdict

firepower# show capture CAPI packet-number 1 trace
1: 09:17:18.996149 1.1.1.1 > 2.2.2.2: icmp: echo request
!
Phase: 4
Type: ACCESS-LIST
...
This packet will be sent to snort for additional processing where a verdict will be reached
!
Phase: 13
Type: EXTERNAL-INSPECT
...
Application: 'SNORT Inspect'

Phase: 14
Type: SNORT
...
Snort Verdict: (pass-packet) allow this packet
FTD Packet Processing: L3/L4 ACL - Allow

• ‘Allow’ action will forward all packets to Snort engine.

• In show snort statistics output the packets will be shown as Passed Packets
> clear snort statistics
> show snort statistics

Packet Counters:
Passed Packets 5
Blocked Packets 0
Injected Packets 0

Flow Counters:
Fast-Forwarded Flows 0
Blacklisted Flows 0
Flows bypassed (Snort Down) 0
Flows bypassed (Snort Busy) 0
FTD Packet Processing: L3/L4 ACL - Trust

• Trust Rule will be pushed to ASA engine as trust action and to Snort engine as fastpath action
firepower# show access-list
access-list CSM_FW_ACL_ line 17 remark rule-id 268435477: L4 RULE: ACP_Rule4_Trust_DNS_Port
access-list CSM_FW_ACL_ line 18 advanced trust udp host 4.4.4.4 host 5.5.5.5 eq domain rule-id 268435477

root@FTD5506-1:/home/admin# cat /var/sf/detection_engines/27306154-256d-11e6-9fc9-180edde177c5/ngfw.rules

268435477 fastpath any 4.4.4.4 32 any any 5.5.5.5 32 53 any 17
FTD Packet Processing: L3/L4 ACL - Trust

Packet-tracer shows that ASA engine will not send any packets to Snort engine
> packet-tracer input inside udp 4.4.4.4 1111 5.5.5.5 53

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced trust udp host 4.4.4.4 host 5.5.5.5 eq domain rule-id 268435477 No Additional Information means
event-log flow-end
the packet is not going to be
access-list CSM_FW_ACL_ remark rule-id 268435477: ACCESS POLICY: FTD5506-1 - Mandatory/4
access-list CSM_FW_ACL_ remark rule-id 268435477: L4 RULE: ACP_Rule4_Trust_DNS_Port redirected to Snort engine
Additional Information:
FTD Packet Processing: L3/L4 ACL - Trust

• Tracing real packets shows that no packets are going to be sent to Snort
> show capture CAPI packet-number 1 trace > show snort statistics
1: 19:46:23.626386 192.168.75.14.50152 > 192.168.76.14.53: udp 34
Packet Counters:
Phase: 4 Passed Packets 0
Type: ACCESS-LIST Blocked Packets 0
Subtype: log Injected Packets 0
Result: ALLOW
Config: Flow Counters:
access-group CSM_FW_ACL_ global Fast-Forwarded Flows 0
access-list CSM_FW_ACL_ advanced trust udp host 192.168.75.14 host 192.168.76.14 eq domain Blacklisted Flows 0
access-list CSM_FW_ACL_ remark rule-id 268435477: ACCESS POLICY: FTD5506-1 - Mandatory/4 Flows bypassed (Snort Down) 0
access-list CSM_FW_ACL_ remark rule-id 268435477: L4 RULE: ACP_Rule4_Trust_DNS_Port Flows bypassed (Snort Busy) 0
Additional Information:
Miscellaneous Counters:
Start-of-Flow events 23
End-of-Flow events 49
FTD Packet Processing: L3/L4 ACL - Trust

In case one or more of the following is true the Trust Rule will be pushed to ASA engine as permit action:
• Application is used as a condition and/or SI, QoS, Identity Policy, SSL Policy
firepower# show access-list
access-list CSM_FW_ACL_ line 14 remark rule-id 268435458: L7 RULE: ACP_Rule3_Trust_DNS_App
access-list CSM_FW_ACL_ line 15 advanced permit ip host 3.3.3.3 host 4.4.4.4 rule-id 268435458

root@FTD5506-1:/home/admin# cat /var/sf/detection_engines/27306154-256d-11e6-9fc9-180edde177c5/ngfw.rules

268435458 fastpath any 3.3.3.3 32 any any 4.4.4.4 32 any any any (appid 617:1)
FTD Packet Processing: L3/L4 ACL - Trust

In that case packet-tracer shows that ASA engine will send the packet to Snort engine for a Verdict
> packet-tracer input inside udp 3.3.3.3 1111 4.4.4.4 53

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip host 3.3.3.3 host 4.4.4.4 rule-id 268435458
access-list CSM_FW_ACL_ remark rule-id 268435458: ACCESS POLICY: FTD5506-1 - Mandatory/3
access-list CSM_FW_ACL_ remark rule-id 268435458: L7 RULE: ACP_Rule3_Trust_DNS_App
Additional Information:
This packet will be sent to snort for additional processing where a verdict will be reached
FTD Packet Processing: L3/L4 ACL - Trust

• Tracing real packets shows that the first few packets of the flow are being sent to Snort, but the
remaining bypass the Snort engine. Snort statistics also reflect this.
> show capture CAPI packet-number 1 trace > show snort statistics
Phase: 4
Few packets to
Type: EXTERNAL-INSPECT Packet Counters:
Application: 'SNORT Inspect' Snort engine Passed Packets 2
Phase: 5 Blocked Packets 0
Type: SNORT Injected Packets 0
Snort Verdict: (pass-packet) allow this packet
Flow Counters:
> show capture CAPI packet-number 10 trace Fast-Forwarded Flows 7
Phase: 3 Blacklisted Flows 0
Type: FLOW-LOOKUP Flows bypassed (Snort Down) 0
Found flow with id 23429, using existing flow Flows bypassed (Snort Busy) 0
Phase: 4
Type: SNORT The remaining packets
Snort Verdict: (fast-forward) fast forward this flow bypass the Snort engine
FTD Packet Processing: L3/L4 ACL - Monitor

• Monitor Rule will be pushed to ASA engine as a permit action and to Snort engine as an audit action
firepower# show access-list
access-list CSM_FW_ACL_ line 17 remark rule-id 268435459: L7 RULE: ACP_Rule4_Monitor_HTTP
access-list CSM_FW_ACL_ line 18 advanced permit ip host 4.4.4.4 host 5.5.5.5 rule-id 268435459

root@FTD5506-1:/home/admin# cat /var/sf/detection_engines/27306154-256d-11e6-9fc9-180edde177c5/ngfw.rules

268435459 audit any 4.4.4.4 32 any any 5.5.5.5 32 any any any (log dcforward flowend) (appid 676:1)
FTD Packet Processing: L3/L4 ACL - Monitor

• Monitor Rule doesn’t drop or permit traffic, but it generates a Connection Event. The packet is
checked against subsequent rules and it is either allowed or dropped

• FMC Connection Events show that the packet matched 2 rules including the Monitor Rule
FTD Packet Processing: L3/L4 ACL - Monitor

• CLISH Snort debug shows that the packet matches 2 rules (audit + block in this case)
> system support firewall-engine-debug

Please specify an IP protocol: tcp

Please specify a client IP address: 4.4.4.4
Please specify a client port:
Please specify a server IP address: 5.5.5.5
Please specify a server port: 80
Monitoring firewall engine debug messages
...
4.4.4.4-36758 > 5.5.5.5-80 6 AS 1 I 1 match rule order 4, 'ACP_Rule4_Monitor_HTTP', action Audit
4.4.4.4-36758 > 5.5.5.5-80 6 AS 1 I 1 no match rule order 5, 'ACP_Rule5_Block_Telnet_App', src network and GEO
4.4.4.4-36758 > 5.5.5.5-80 6 AS 1 I 1 no match rule order 6, 'ACP_Rule6_Block_Telnet_Port', DstPort
4.4.4.4-36758 > 5.5.5.5-80 6 AS 1 I 1 no match rule order 7, 'ACP_Rule7_Block_RST_Youtube', src network and GEO
4.4.4.4-36758 > 5.5.5.5-80 6 AS 1 I 1 no match rule order 8, 'ACP_Rule8_Interactive_Block', src network and GEO
4.4.4.4-36758 > 5.5.5.5-80 6 AS 1 I 1 no match rule order 9, 'ACL_Rule9_Interactive_Blck_RST', src network and GEO
4.4.4.4-36758 > 5.5.5.5-80 6 AS 1 I 1 match rule order 10, id 268434434 action Block
4.4.4.4-36758 > 5.5.5.5-80 6 AS 1 I 1 deny action
FTD Packet Processing: L3/L4 ACL - Block

• Block Rule will be pushed to ASA engine as a permit or deny action depending on the rule conditions
and to Snort engine as deny rule. If both applied, Application takes precedence over Dest Ports.
firepower# show access-list Packet matching this rule will
access-list CSM_FW_ACL_ line 20 remark rule-id 268435460: L7 RULE: ACP_Rule5_Block_Telnet_App be dropped by Snort engine
access-list CSM_FW_ACL_ line 21 advanced permit ip host 5.5.5.5 host 6.6.6.6 rule-id 268435460
access-list CSM_FW_ACL_ line 23 remark rule-id 268435464: L4 RULE: ACP_Rule6_Block_Telnet_Port
access-list CSM_FW_ACL_ line 24 advanced deny tcp host 6.6.6.6 host 7.7.7.7 eq telnet rule-id 268435464 Packet matching this
rule will be dropped
root@FTD5506-1:/home/admin# cat /var/sf/detection_engines/27306154-256d-11e6-9fc9-180edde177c5/ngfw.rules by ASA engine
268435460 deny any 5.5.5.5 32 any any 6.6.6.6 32 any any any (appid 861:1)
268435464 deny any 6.6.6.6 32 any any 7.7.7.7 32 23 any 6
FTD Packet Processing: L3/L4 ACL - Block

• In case traffic matches an ASA deny rule tracing of a real packet shows that the packet is dropped by
ASA engine and it is not being forwarded to Snort
firepower# show capture CAPI packet-number 1 trace
1: 12:29:00.844438 6.6.6.6.18791 > 7.7.7.7.23: S 2574076177:2574076177(0) win 4128 <mss 536>

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: DROP
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced deny tcp host 6.6.6.6 host 7.7.7.7 eq telnet rule-id 268435464 event-log flow-start
access-list CSM_FW_ACL_ remark rule-id 268435464: ACCESS POLICY: FTD5506-1 - Mandatory/6
access-list CSM_FW_ACL_ remark rule-id 268435464: L4 RULE: ACP_Rule6_Block_Telnet_Port
Additional Information:
FTD Packet Processing: L3/L4 ACL - Block

• For Block Rule that uses Application the tracing of a real packet shows that the packet is dropped by
ASA due to Snort engine verdict
firepower# show capture CAPI packet-number 7 trace
7: 13:42:53.655971 192.168.75.14.36775 > 192.168.76.14.23: P 4147441466:4147441487(21) ack 884051486 win 16695
Type: SNORT
Subtype: Snort needs to process few packets before
Result: DROP
determines the Application type
Additional Information:
Snort Verdict: (black-list) black list this flow

• Snort engine debug shows how the verdict was determined

> system support firewall-engine-debug
5.5.5.5-36774 > 6.6.6.6-23 6 AS 1 I 0 Starting with minimum 6, 'ACP_Rule5_Block_Telnet_App', and IPProto first with zones
3 -> 1, geo 0(0) -> 0, vlan 0, sgt tag: untagged, svc 861, payload 0, client 2000000861, misc 0, user 9999997, url , xff
5.5.5.5-36774 > 6.6.6.6-23 6 AS 1 I 0 match rule order 5, 'ACP_Rule5_Block_Telnet_App', action Block
5.5.5.5-36774 > 6.6.6.6-23 6 AS 1 I 0 deny action
FTD Packet Processing: L3/L4 ACL -
Block/RST

• Block Rule will be pushed to ASA engine as a permit or deny action depending on the rule conditions
and to Snort engine as reset rule
firepower# show access-list
access-list CSM_FW_ACL_ line 26 remark rule-id 268435461: L7 RULE: ACP_Rule7_Block_RST_Youtube
access-list CSM_FW_ACL_ line 27 advanced permit ip host 7.7.7.7 host 8.8.8.8 rule-id 268435461

root@FTD5506-1:/home/admin# cat /var/sf/detection_engines/27306154-256d-11e6-9fc9-180edde177c5/ngfw.rules

268435461 reset any 7.7.7.7 32 any any 8.8.8.8 32 any any any (appid 929:7)
FTD Packet Processing: L3/L4 ACL -
Block/RST

• When matching Block with Reset rule FTD sends a TCP Reset packet or an ICMP Type 3 Code 13
Destination Unreachable (Administratively filtered) message
• Snort engine debug shows the Reset action
> system support firewall-engine-debug
7.7.7.7-36778 > 8.8.8.8-80 6 AS 1 I 0 match rule order 7, 'ACP_Rule7_Block_RST_Youtube', action Reset
7.7.7.7-36778 > 8.8.8.8-80 6 AS 1 I 0 reset action

• The Reset is sent after processing few packets

firepower# show capture CAPI
5: 15:10:56.983393 192.168.75.14.36776 > 192.168.76.14.80:
6: 15:10:56.984675 192.168.76.14.80 > 192.168.75.14.36776:
7: 15:10:56.984980 192.168.75.14.36776 > 192.168.76.14.80:
8: 15:10:56.985376 192.168.75.14.36776 > 192.168.76.14.80:
9: 15:10:56.994211 192.168.76.14.80 > 192.168.75.14.36776:
S 894520672:894520672(0) win 8192 <mss 1260,nop,nop,sackOK>
S 3490934048:3490934048(0) ack 894520673 win 8192 <mss 1380,nop,nop,sackOK>
. ack 3490934049 win 65520
P 894520673:894521071(398) ack 3490934049 win 65520
R 3490934049:3490934049(0) ack 894521071 win 0
FTD Packet Processing: L3/L4 ACL - Inter.
Block

• Interactive Block Rule will be pushed to ASA engine as a permit or deny action depending on the rule
conditions and to Snort engine as bypass rule
firepower# show access-list
access-list CSM_FW_ACL_ line 29 remark rule-id 268435462: L7 RULE: ACP_Rule8_Interactive_Block
access-list CSM_FW_ACL_ line 30 advanced permit ip host 8.8.8.8 host 9.9.9.9 rule-id 268435462

root@FTD5506-1:/home/admin# cat /var/sf/detection_engines/27306154-256d-11e6-9fc9-180edde177c5/ngfw.rules

268435462 bypass any 8.8.8.8 32 any any 9.9.9.9 32 any any any (appid 61:7)
FTD Packet Processing: L3/L4 ACL - Inter.
Block

• Interactive Block Rule will prompt the user that the destination is forbidden

• Snort debug shows that the rule was matched and an interactive response was sent
> system support firewall-engine-debug
8.8.8.8-36793 > 9.9.9.9-80 6 AS 1 I 0 match rule order 8, 'ACP_Rule8_Interactive_Block', action Interactive
8.8.8.8-36793 > 9.9.9.9-80 6 AS 1 I 0 bypass action sending interactive response of 1093 bytes
FTD Packet Processing: L3/L4 ACL - Inter.
Block

• The user can click on Continue button or Refresh the brower page to bypass and continue

• If the user clicks on Continue button the Snort debug shows that the traffic is allowed by the same rule
> system support firewall-engine-debug
8.8.8.8-36794 > 9.9.9.9-80 6 AS 1 I 0 New session
8.8.8.8-36794 > 9.9.9.9-80 6 AS 1 I 0 match rule order 8, 'ACP_Rule8_Interactive_Block', action Interactive
8.8.8.8-36794 > 9.9.9.9-80 6 AS 1 I 0 bypass action interactive bypass The rule mimics
8.8.8.8-36794 > 9.9.9.9-80 6 AS 1 I 0 allow action an Allow action
FTD Packet Processing: L3/L4 ACL - IB
w/RST

• Interactive Block Rule will be pushed to ASA engine as a permit action depending on the rule
conditions and to Snort engine as intreset rule
firepower# show access-list
access-list CSM_FW_ACL_ line 32 remark rule-id 268435463: L7 RULE: ACL_Rule9_Interactive_Blck_RST
access-list CSM_FW_ACL_ line 33 advanced permit ip host 9.9.9.9 host 10.10.10.10 rule-id 268435463

root@FTD5506-1:/home/admin# cat /var/sf/detection_engines/27306154-256d-11e6-9fc9-180edde177c5/ngfw.rules

268435466 intreset any 9.9.9.9 32 any any 10.10.10.10 32 any any any (appid 623:3)
FTD Packet Processing: L3/L4 ACL - IB
w/RST

• Similar to Block with Reset, the user can click on Continue button

• In the Snort debug the action shown in Interactive Reset

> system support firewall-engine-debug
192.168.75.14-36815 > 192.168.76.14-80 6 AS 1 I 1 Starting with minimum 9, 'ACL_Rule9_Interactive_Blck_RST', and IPProto first with
zones 3 -> 1, geo 0(0) -> 0,
192.168.75.14-36815 > 192.168.76.14-80 6 AS 1 I 1 match rule order 9, 'ACL_Rule9_Interactive_Blck_RST', action Interactive Reset
192.168.75.14-36815 > 192.168.76.14-80 6 AS 1 I 1 bypass action sending interactive response of 1093 bytes
FTD Packet Processing: DAQ

• Data Acquisition Library (DAQ) is the interface between ASA engine and Snort engine
• DAQ communicates with ASA Datapath processes through Packet Data Transport System (PDTS)
1. A packet is placed into DMA Memory
2. Datapath processes the packet
3. If requires Snort inspection a pointer to the packet is added
to PDTS TX Queue of a specific Snort instance
4. Snort instances periodically read the TX Rings and process the
packets in the DMA Memory
5. When a Snort instance finishes the processing puts to PDTS RX
queue a PDTS Notification (Verdict or SSL Decrypted packet)
6. Datapath processes reads the Verdict or copies the Decrypted
packet to DMA memory
FTD Packet Processing: DAQ

• To see the queue utilization and the utilization of PDTS queues from CLISH
> show asp inspect-dp snort queues > show asp inspect-dp snort

SNORT Inspect Instance Queue Configuration SNORT Inspect Instance Status Info

RxQ-Size: 1 MB Id Pid Cpu-Usage Conns Segs/Pkts Status

TxQ-Size: 128 KB tot (usr | sys)
TxQ-Data-Limit: 102.4 KB (80%) -- ----- ---------------- ---------- ---------- ----------
TxQ-Data-Hi-Thresh: 35.8 KB (28%) 0 4024 0% ( 0%| 0%) 5 0 READY
1 4023 0% ( 0%| 0%) 0 0 READY
Id QId RxQ RxQ TxQ TxQ
(used) (util) (used) (util) Snort instance Process ID
-- ---- ---------- ------ ---------- ------
0 All 0 0% 0 0%
PDTS Queue utilization
1 All 0 0% 0 0%
FTD Packet Processing: SI (IP)

• Security Intelligence (SI) can Blacklist (drop) or Whitelist (allow) IP addresses early in the packet
processing lifetime within the Snort engine
• Whitelist overwrites the Blacklist
• The Blacklist can be populated in 2 ways:
1. Manually by the FMC administrator
2. Automatically by Intelligence Feed (Talos or custom) or List
• Snort returns to ASA a verdict about a packet being blacklisted
FTD Packet Processing: SI (IP)

• The files containing the IPs from Talos SI Feed are in /ngfw/var/sf/iprep_download directory
root@FTD5506-1:/ngfw/var/sf/iprep_download# ls -alt | grep blf
-rw-r--r-- 1 root root 1252278 Jun 12 16:06 3e2af68e-5fc8-4b1c-b5bc-b4e7cab598ba.blf
-rw-r--r-- 1 root root 227696 Jun 12 16:05 032ba433-c295-11e4-a919-d4ae5275a468.blf

• If a packet is being dropped by Snort SI the ASA capture trace shows the Verdict
> show capture CAPI packet-number 1 trace
1: 16:07:45.147743 192.168.75.14 > 38.229.186.248: icmp: echo request
Phase: 14
Type: SNORT
Subtype:
Result: DROP
Additional Information:
Snort Verdict: (black-list) black list this flow
FTD Packet Processing: SSL Decryption

• SSL Inspection Policy controls which traffic will be decrypted by FTD so that other policies (ACP, File,
Snort) can inspect the traffic.
• Can be configured in the Firepower Management Center, under Policies > SSL.
• FTD provides 2 Decryption modes:
1. Decrypt - Know Key - SSL/TLS server owned by us
2. Decrypt - Resign - 3rd party SSL/TLS server. The FTD does man-in-the-middle and for that
reason requires Internal CA
• SSL Policy is attached to Access Control Policy (ACP)
• Client Hello features (enabled by default) allows FTD to modify (TLS ver, Ciphers) the Client Hello
message (Required for Safe Search and YouTube EDU)
FTD Packet Processing: SI (DNS/URL)

Security Intelligence (URL)

• Works similarly to IP Security Intelligence and provides 3 actions
1. Whitelist
2. Blacklist (Block)
3. Blacklist (Monitor)

• In case Talos URL Feed is used part of the db is stored locally and updated daily
• For non-cached URLs a Cloud lookup is done
FTD Packet Processing: Identity Policy

Identity Policy enables user-based authentication. The user info can be obtain in various ways:
1. Passive Authentication
• Integration with LDAP Requires User Agent

• Integration with ISE pxGrid

• Integration with Citrix VDI Identifying multiple users behind one IP

• Network Discovery (User) Traffic-based Detection (LDAP, FTP etc)
2. Active Authentication
• Captive Portal Basic, NTLM, Kerberos
FTD Packet Processing: L7 ACL

Correlate SSL Policy User-based rules

L7 ACL can do among others: Application filtering

SafeSearch

Forward to Intrusion Policy Forward to

File Policy YouTube EDU
FTD Packet Processing: QoS (Rate Limiting)

• QoS Rate-Limiting capabilities added on FTD 6.1 release

• QoS Traffic Shaping and Policing not available at the moment
• You create/manage QoS Policies from FMC Devices > Qos section
• Compared to other policies, a QoS Policy is not attached to Access Control Policy, but directly to FTD
device
 FTD Packet Processing: QoS (Rate Limiting)

Source Interface Object – The interface facing the Initiator

- In case of TCP initiator is the one who sent the SYN packet
- In case of UDP is the one who send the first packet. The UDP session has idle time 2 min

Interfaces are defined by Destination Interface Objects - The interface facing the Responder
usage of Security Zones
or Interface Groups

Download - Rate limit of traffic flowing to the devices connected to the source interfaces
and from the devices connected to the destination interfaces
Upload - Rate limit of traffic leaving devices connected to the source interfaces
FTD Packet Processing: Network Discovery

• Network Discovery is used in 2 main places:

1. FMC Dashboards
2. Intrusion Prevention FireSIGHT Recommendations
• Same functionality as on classic Firepower devices
• Configuration from Policies > Network Discovery
Tip – Make sure you tune the
networks in the Network
Discovery Policy to match the
networks you want to discover
and remove the 0.0.0.0/0 and
::/0 entries
FTD Packet Processing: File Policy (AMP)

• File Policy provides few different functionalities:

Detect Files = Checks first 1460 Bytes of a file,
determines the type and generates a log

Block Files = Blocks the file based on first 1460 Bytes

Malware Cloud Lookup = Sends the SHA-256 hash of a file to the cloud for analysis
and depending on the answer generates a log if the file is bad. Optionally, Local
Analysis can analyze the file and Dynamic Analysis Capable files can be sent to cloud for
Dynamic Analysis and/or SPERO analysis

Block Malware = Sends the SHA-256 hash of a file to the cloud for analysis and
depending on the answer blocks it if the file is bad. Optionally, Local Analysis can
block the file and/or Dynamic Analysis Capable files can be sent to cloud for Dynamic
Analysis and/or SPERO analysis.
FTD Packet Processing: Intrusion Policy

• Tracing a real packet shows the Snort engine verdict when a Snort Rule is being matched
firepower# show capture CAPO packet-number 2 trace
2: 12:16:09.232776 192.168.77.40 > 192.168.75.39: icmp: echo reply
Phase: 5
Type: SNORT
Subtype:
Result: DROP
Config:
Additional Information:
Snort Verdict: (black-list) black list this flow
..
Result:
input-interface: outside
input-status: up
input-line-status: up
Action: drop
Drop-reason: (snort-drop) Snort requested to drop the frame
FTD Packet Processing: ALG Checks

• ASA Application Layer Gateway (ALG) are the classic Modular Policy Framework (MPF) rules applied
on ASA engine
• Currently on FTD the configuration MPF is not tunable (With 6.2 you can tune using Flexconfig)
• You can use classic ASA MPF commands to verify the existing MPF configuration
firepower# show run class-map
firepower# show run policy-map
firepower# show run service-policy
!
firepower# show service-policy flow tcp host 192.168.75.14 host 192.168.77.40 eq 80
FTD Packet Processing: NAT, VPN, L3, L2

• The remaining checks on ASA engine are the same as on classic ASA
• NAT IP header
• VPN Encrypt
• L3 Route
• L2 Resolution of next hop
Thank You