Brksec 2020

Firewall Deployment (FTD)
Steven Chimes, Consulting Systems Engineer

BRKSEC-2020
Session Objectives & Housekeeping
The BRKSEC-2020 session format is based upon a use case, using a fictional company,
that requires the deployment of an FTD firewall solution project using Cisco best practices.
• Relevant diagrams and configuration examples are the foundation of the format.
At the end of the session, you should have:
• Knowledge of common firewall deployment scenarios, including edge, data center, HA, etc., using
the latest code (FTD 6.1).
• Understanding of how the firewall implements the critical integrated features – including packet flows.
• Best practice suggestions for optimizing your firewall deployment using Cisco designs.
• High level understanding of how various NGFW policies are configured and fit together.
• Note: Session will NOT cover Cisco IOS Firewall, FWSM, ASA, IPSec/SSL VPN or clustering. This
session is not a deep-dive on NGIPS or AMP.
Speed through repetitive configurations – to allow more time for technology!
Contained in the deck are various slides for your reference, which may be briefly discussed
or skipped entirely. They are denoted by Reference
BRKSEC-2020 © 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Cisco Firepower Sessions: Building Blocks
BRKSEC-2020 BRKSEC-2050 BRKSEC-2058

Firewall Deployment ASA Firepower NGFW A Deep Dive into using
(FTD) typical deployment the Firepower Manager
scenarios
(Mon 8:00 AM) (Mon 1:30 PM) (Wed 8:00 AM)
(Tue 8:00 AM) (Tue 1:30 PM) (Wed 1:30 PM)
BRKSEC-3004 BRKSEC-2030 BRKSEC-3035 BRKSEC-3032

Deep Dive on Cisco Deploying Intrusion Firepower 9300 ASA Clustering
Security in ACI Prevention Systems Deep Dive Deep Dive
(Tue 1:30 PM) (Tue 1:30 PM) (Wed 1:30 PM) (Thu 8:00 AM)
Agenda
• Cisco Firepower NGFW Overview
• Use Case Introduction
• Deploying the L3 Firewall at the Edge
• Interfaces, Routing & NAT
• NGFW Policies
• High Availability
• Deploying the L2 Firewall in the Data Center

• Deploying Virtual Firewalls
Cisco Firepower NGFW
Cisco Firepower NGFW Product Family
Running Firepower Threat Defense (FTD)
Firepower 9300
Performance and Scalability
(SM-24, SM-36, SM-44)
Firepower 4140 /
Firepower 4150
ASA 5555-X
Firepower 4110 /
ASA 5545-X Firepower 4120
ASA 5516-X / ASA 5525-X
ASA 5506H-X
ASA 5508-X / ASA 5515-X
ASA 5506W-X ASA 5512-X
ASA 5506-X
FTDv
SMB & Distributed Enterprise Commercial & Enterprise Data Center, High Performance Computing, Service
Provider
Firepower Threat Defense (FTD) Software
Firepower (L7) Firepower Threat Defense

• Threat-Centric NGIPS
• AVC, URL Filtering for NGFW Full Feature Set Single Converged OS
• Advanced Malware Protection
ASA (L2-L4)
• L2-L4 Stateful Firewall
• Scalable CGNAT, ACL, routing Continuous Feature Firewall URL Visibility Threats
• Application inspection Migration
Firepower Management
Center (FMC)*
* Also manages Firepower Appliances and FirePOWER Services (not ASA Software)
Use Case Network – CLINET
(clinet.com)
CLINET (clinet.com)
Cisco LIVE Information Networking Company
• CLINET (clinet.com) is a fictional company created for understanding use cases
in FTD firewall deployment.
• CLINET has embarked on a network/security deployment project entitled
“The Security 20/20 Project” which serves as the basis for the use case.
• Company requirements and configuration examples are based upon real-life
customer conversations and deployments.
Overview – clinet.com Logical Network Diagram
Firewall Deployment
ISP-A ISP-B
DMZ Network Edge

(Public Web/DB) Aggregation
Deploy Redundant Firepower

NGFWs in Routed Mode for Edge Agg
Edge/DMZ VDC
Data Center
Core
(Routed)
Core VDC
Data Center
Aggregation
Deploy Redundant Firepower NGFWs
in Transparent Mode for Data Center / Agg VDC
Access Fabric
Virtual Access /
Deploy FTD Virtual Compute
(FTDv) in Virtual
Environment
Note: Storage architecture not depicted in this layout, nor will it be discussed
clinet.com Edge FTD Deployment Details
General Requirements
clinet.com ASN 65345
ISP-A ISP-B IP Range 128.107.1.0/24
1
Edge Routers Edge
running HSRP –
FHRP address is
Aggregation
1
128.107.1.1 6
DMZ Network(2) Two DMZ Zones will be created:
3 1 – Web Public (www, DNS, SMTP)
Outside and DMZ (Public Web/DB) 2 – Partner Intranet (wwwin, Oracle
using Redundant 3 link)
Interfaces G1/1
G1/2 G1/3 6
2
3 VLAN 150
FW deployed in L3 ‘routed’ mode, 2 G1/5
7
with NAT and ACLs – Routing G1/4 Public Web DMZ – 10.200.1.0/24
protocol will be used on inside G1/6
G1/7 VLAN 151
G1/8 Partner Intranet – 10.100.100.0/24
4 Web/App/DB – 172.16.25.250
VPC VPC
4
Inside Interface
using 7
EtherChannel Edge Aggregation Active/Standby HA
VDC will be used at the
5 VLAN VLAN edge
VLAN 2
120 1299 DMZ 5
Diversion Use-case specific Internal Zones:
Inside Zone for
network VL2 – Security Diversion network for
Network contractor
for scanning questionable traffic
‘Trusted / BYOD
Scanning VL120 – Primary Internal Zone - services the
Zone” unknown primary internal network
VL1299 – Isolated Internal DMZ for BYOD /
contractor / unknown – Internet access only
clinet.com Data Center FTD Deployment Details
1 VLAN 1299
VLAN 2 VLAN 120
Use-case specific Internal DMZ Zone
Zones from Edge Aggregation Sidecar Inside
1 1 for
into core network Network
contractor / Data Center
for ‘Trusted
BYOD Core
Scanning Zone”
unknown (Routed)
Core VDC 2
DC Core is routed using OSPF.
Routing will remain in place (on
OSPF Routed Core DC Switches). FTD must be
deployed without disrupting
2 current L3 architecture
Data Center
Aggregation
Aggregation
VDC
3
Firepower 9300 is used
for scale and flow offload
Virtual Access /
Compute Networks
FTD H/A Pair
4
Virtual FTD (FTDv) deployed
within hypervisor to protect
East/West Traffic Flows
FTD Initial Setup
FTD Deployment Checklist (Edge)
 Primary NGFW: (after initial setup)
1 – Determine Deployment Mode – Routed or Transparent
2 – Examine Interface Types ISP-A ISP-B
3 – Interface Configuration(s) Edge
 EtherChannel / LACP / Redundant Aggregation
 VLAN Tagging / Sub-Interfaces / Trunk 4
4 – Routing DMZ Network(2)

(Public Web/DB)
 Default Route / Static / Routing Protocols VLAN 150
G1/1 3
5 – NAT 2 G1/2 G1/7
3
VLAN 151
 Static and Dynamic Translations 1 G1/5
7 3
5 6 G1/8
 Auto NAT & Manual NAT G1/6
G1/1
6 – NGFW Policies G1/4
 Access Control VPC

3
VPC
 Inspection
 Malware & File Edge Aggregation
 SSL VDC
3 3
VLAN 2 VLAN 120 VLAN 1299
 Implement HA
7 – Active/Standby Failover
Installing Firepower Threat Defense
Management Center Smart License FirePOWER Services on ASA
Firepower Firepower 5.4

1. FireSIGHT 5.4
2. Management 3.
Center 6.0 ASA 9.4.x
Upgrade/
Register Reimage
Install
Firepower
Cisco Smart Firepower
Management
Software Manager Threat Defense
Center 6.0
FMC Installation Guide: http://www.cisco.com/c/en/us/td/docs/security/firepower/hw/firepower_management_center/management_center/installation.html

FTD Quick Start Guide: http://www.cisco.com/c/en/us/td/docs/security/firepower/quick_start/5500X/ftd-55xx-X-qsg.html
Management Connections
• FTD is managed by FMC through a management interface.

• Management interface is used only for management and eventing.
• Can be on the same subnet as a data interface or on separate subnet.
• Usually is placed on the same subnet as the inside interface.
• Management interfaces are not shown on diagrams, but are present.
Firepower Management
Center (FMC)
Layer-2 Switch
FTD Inside Outside
FTD Management
FTD Initial Setup – FTD Console
• Initial setup through console interface is prompted. Default username/password

is admin/Admin123
Cisco ASA5506W-X Threat Defense v6.1.0 (build 254)
firepower login: admin
Password: Admin123
• Prompts to configure both password and management connectivity (IPv4 and/or

IPv6):
You must change the password for 'admin' to continue.
<snip>
You must configure the network to continue.
<snip>
FTD Initial Setup – FTD Console
• 5506-X, 5508-X and 5516-x include a easy to use/simplistic local manager.

• Local manager only manages local appliance (not HA pair).
• For the use case, CLINET is using FMC for central management.
Manage the device locally? (yes/no) [yes]: no
• Firewall mode is one of the few features configured locally. We will cover modes
in more detail later on.
Configure firewall mode? (routed/transparent) [routed]:
• Connection to FMC must be preconfigured on FTD, single line command.

• Registration key can be any string you want – just remember it!
configure manager add [hostname | ip address ] [registration key ]
FTD Initial Setup – Adding a Device to FMC
Either hostname
or IP address
Registration key
we used in CLI Add device
drop down
Select based Access Control

upon Policy we just
subscriptions created
purchased
Firewall Deployment Modes
Firewall Design: Modes of Operation
• Routed Mode is the traditional mode of the firewall. Two or 10.1.1.0/24
more interfaces that separate L3 domains – Firewall is the
10.1.1.1
Router and Gateway for local hosts.
NAT
DRP
192.168.1.1
192.168.1.0/24
IP:192.168.1.100
GW: 192.168.1.1
Firewall Design: Modes of Operation 192.168.1.1
• Routed Mode is the traditional mode of the firewall. Two or

more interfaces that separate L3 domains – Firewall is the VLAN192
Router and Gateway for local hosts.
• Transparent Mode is where the firewall acts as a bridge
functioning at L2.
• Transparent mode firewall offers some unique benefits in the DC. VLAN1920
• Transparent deployment is tightly integrated with our ‘best
practice’ data center designs. 192.168.1.0/24
• Note:
IP:192.168.1.100
• No multiple context mode available on FTD today. GW: 192.168.1.1
• Routed or transparent mode configured with setup dialog.
• Changing between these modes requires re-registering with FMC.
• Policies will be re-deployed.
Working With FTD Interfaces
FTD Security Zones
• True zone based firewall
• Security Zones are collections of interfaces or sub-interfaces
• Policy rules can apply to source and/or destination security zones
• Security levels are not used
Optional Interface Modes
• By default, all interfaces are firewall interfaces (routed or transparent)
• Optionally, specific interfaces can be configured for use as IDS or IPS
• IDS Mode
• Inline Tap
• Passive
• ERSPAN
• IPS Mode
• Inline TAP
Mix and Match Interface Modes
Routed or Transparent
A F Interfaces
Policy Tables
Passive
B G
Inline Pair 1
C H
Inline Set
Inline Pair 2
D I
Inline Tap
E J
Reference
Basic Interface Configuration

Just an example – Final config will be different once redundancy is added
Basic Interface Configuration
Interface in RED
Just an example – final config will be different
once redundancy is added
ISP-A ISP-B
Edge
Aggregation
DMZ Network(2)
(Public Web/DB)
G1/1
VPC VPC
Edge Aggregation
VDC
Deploying the Redundant Outside Interfaces
Edge Use Case
outside
ISP-A ISP-B
Edge
Aggregation
DMZ Network(2)
(Public Web/DB)
G1/1 G1/2
VPC VPC
Edge Aggregation
VDC
Deploying the Redundant DMZ Interfaces
Will use sub-interfaces to accommodate the 2 VLANs
ISP-A ISP-B
No security
Edge
zone this time Aggregation
DMZ Network(2)
(Public Web/DB)
GigabitEthernet1/3
GigabitEthernet1/4 G1/3 VLAN 150

VLAN 150
trunk
trunk
VLAN 151
VLAN 151
G1/4
VPC VPC
No IP either Edge Aggregation

VDC
ISP-A ISP-B
Edge
Aggregation
DMZ Network(2)
(Public Web/DB)
G1/3 VLAN 150

trunk
VLAN 151
G1/4
VPC VPC
Edge Aggregation
VDC
Repeat 1x for VLAN 151
Reference

ISP-A ISP-B
Edge
Aggregation
DMZ Network(2)
(Public Web/DB)
G1/3 VLAN 150

trunk
VLAN 151
G1/4
VPC VPC
Edge Aggregation
VDC
Deploying Changes
Changes don’t take affect until you deploy the policy
Can optionally
check for rule
conflicts
FTD EtherChannel Link Aggregation
What is an EtherChannel?
• EtherChannel LAG (IEEE standard is 802.3ad) allows
up to 16 physical Ethernet links to be combined into one
logical link. 16 links can be active and forwarding data.
• Ports must be of same capabilities: duplex, speed, type, etc.
• Benefits of EtherChannel are increasing scale, load-
balancing and HA
• Load balancing is performed via a load-balancing hashing
algorithm (src-dst-ip, src-dst-ip-port, etc.)
LACP Load Balance
• EtherChannel uses LACP (Link Aggregation Control src-dst-IP (hash)
Protocol) to allow dynamic bundling and dynamic
recovery in case of failure
• Static LAG can be used, but should be aware of potential
traffic black holes this may cause
What is a vPC EtherChannel?
• vPC (like VSS) is known as Multi-Chassis EtherChannel
• Virtual Port Channels (vPC) are common EtherChannel
deployments, especially in the data center, and allow
multiple devices to share multiple interfaces 20G
• All links are active – no STP blocked ports
• A vPC Peer Link is used on Nexus devices to instantiate the 10G

vPC domain and allow sharing 10G
• Peer Link synchronizes state between vPC peers
• vPC can maximize throughput since each port channel is LACP Load Balance
treated as a single link for spanning-tree purposes src-dst-IP (hash)
• Spanning Tree is not disabled, but does not affect the network
• vPC White paper:

http://www.cisco.com/c/dam/en/us/td/docs/switches/datacenter
VPC PEER LINK
/sw/design/vpc_design/vpc_best_practices_design_guide.pdf
EtherChannel on FTD
• Supports 802.3ad and LACP standards
• Direct support for vPC/VSS - CVD
• No issues with traffic normalization or asymmetry
• Up to 16 active links
• 100Mb, 1Gb, 10Gb, 40Gb are all supported – must match
• Supported in all modes (transparent and routed)

• Configurable hash algorithm (default is src-dest-ip)
• SHOULD match the peer device for most deterministic
flows
• Redundant interface feature and LAG on FTD are

mutually exclusive
Deploying the Inside Interfaces with EtherChannel
We will use sub-interfaces to accommodate the 3 internal VLANs
No security
zone again
No IP either
VLAN 120
Repeat 2x for VLAN 2 and VLAN 1299
Reference

Reference


(Public Web/DB)
G1/1 3
5 – NAT 2 G1/2 G1/3
3
VLAN 151
7 3
5 6 G1/4
G7/1

3
VPC
 Inspection
 SSL VDC
3 3
 Implement HA
Routing on FTD
Reference
FTD Packet Processing Flow
SSL Policy Enforcement

Yes
IP Application Policy Enforcement
Application
Reputation/ URL Policy Enforcement
Identification
SI NGIPS Policy Enforcement
AMP Policy Enforcement Fastpath
Event Gen or Allow
Yes No
No DROP No
RX Ingress Existing NAT Advanced No
Pkt Conn Fastpath? DROP
Interface Untranslate ACL
Permit
Yes
No
Yes Yes Yes

DROP
ALG NAT IP Egress L3 L2 TX
Checks Header Interface Route Addr Pkt
No No
No No
DROP DROP DROP DROP
Routing on FTD
• FTD performs L3 route lookup as part of its normal packet
Outside Network
processing flow
• FTD is optimized as a flow-based inspection device FHRP 128.107.1.1
• For smaller deployments, FTD is perfectly acceptable as the router
• For larger deployments, a dedicated router (ISR, ASR, Nexus) is a
much better option. G1/1 DMZ Network
• FTD may originate routes depending on the network design Static Default
G1/3
• FTD Supports static routing and most IGP routing protocols:

Static or IGP
• BGP-4 with IPv4 & IPv6 (aka BGPv4 & BGPv6) G1/2
• OSPFv2 & OSPFv3 (IPv6)
• RIP v1/v2 Inside 10.120.1.0/24
• Multicast (FTD 6.1)

• No EIGRP
• Complete IP Routing configuration in config guides:

Inside Network
http://www.cisco.com/c/en/us/td/docs/security/firepower/601/c
onfiguration/guide/fpmc-config-guide-v601.pdf
Reference
BGP
• FTD supports BGPv4 and BGPv6 for dynamic routing across all platforms
• Standard communities and all path attributes, route redistribution; up to 100K prefixes and 2000 neighbors
• Null0 and Remotely-Triggered Black Hole (RTBH) support
• RTBH – DDoS mitigation
• Confederations, route reflectors, tagging, neighbor source-interface, and BFD are not supported
• BGP RIB is replicated in failover along with other protocols
Reference
Non Stop Forwarding (NSF)

• Routing Information Base is replicated in failover mode
• Active unit or master establish dynamic routing adjacencies and keep standby up-to-date
• When the active unit fails, the failover pair continue traffic forwarding based on RIB
• New active unit re-establish the dynamic routing adjacencies and update the RIB
• Adjacent routers flush routes upon adjacency re-establishment and cause momentary traffic blackholing
• Non Stop Forwarding (NSF) and Graceful Restart (GR) support in FTD:
• Cisco or IETF compatible for OSPFv2, OSPF3; RFC 4724 for BGPv4
• FTD notifies compatible peer routers after a switchover in failover
• FTD acts as a helper to support a graceful or unexpected restart of a peer router in all modes
1. Active FTD fails over to standby; newly active 2. Router re-establishes OSPF adjacency with the
unit initiates OSPF adjacency with the router OSPF FTD while retaining the stale routes; these routes
indicating that traffic forwarding should continue. are refreshed when the adjacency reestablishes.
4. FTD continues normal traffic forwarding until OSPF 3. Primary Route Processor undergoes a restart,
the primary RP restarts or the backup takes over signals the peer FTD to continue forwarding while
or the timeout expires. Forwarding Plane the backup re-establishes adjacencies.
FTD Routing – Static Use Case
FTD Routing – Dynamic Use Case
Step 1 – Enable the OSPF Process
Step 2 – Add an Area
Next slide is from

redistribution tab
Step 3 – Add Redistribution
FTD Deployment Checklist – Summary

(Public Web/DB)
G1/1 3
5 – NAT 2 G1/2 G1/3
3
VLAN 151
7 3
5 6 G1/4
G7/1

3
VPC
 Inspection
 SSL VDC
3 3
 Implement HA
NAT on FTD
Reference

Yes
Application
Identification
Event Gen or Allow
Yes No
No DROP No
Permit
Yes
No
Yes Yes Yes

DROP
No No
No No
DROP DROP DROP DROP
NAT on FTD
• NAT on FTD is built around objects, with two types of NAT:
• Auto NAT – Only source is used as a match criteria
• Only used for static or dynamic NAT
• When configuring, it is configured within a network object (internally)
• Device automatically orders the rules for processing:
• Static over dynamic
• Quantity of real IP addresses – from smallest to largest
• IP address – from lowest to highest
• Name of network object – in alphabetical order
• Manual NAT – Source (and possibly destination) is used as a match criteria

• More flexibility in NAT rules (one-to-one, one-to-many, many-to-many, many-to-one)
• Supports NAT of the source and destination in a single rule
• Only the order matters for processing
NAT on FTD Processing
• Single NAT rule table (matching on a first match basis).
• Uses a simplified “Original Packet” to “Translated Packet” approach:
• NAT is ordered within 3 sections.

• Section 1 – NAT Rules Before (Manual NAT)
• Section 2 – Auto NAT Rules (Object NAT)
• Section 3 – NAT Rules After (Manual NAT)
• By default only Sections 1 and 2 are used. Select “NAT Rule After” category
when configuring a Manual NAT rule to place it within Section 3.
Auto NAT Use Case
Dynamic NAT translation of 10.120.1.0/24 to the using Interface PAT
Reference
Auto NAT Use Case
Static NAT translation of 172.16.25.200 to a public IP of 128.107.1.200
Reference
Auto NAT Use Case
Dynamic NAT translation of 10.120.1.0/24 to 128.107.1.10-128.107.1.20
Manual NAT Use Case
Static NAT of 192.168.1.10  128.107.1.242 to 192.168.1.155  128.107.1.155
Sample NAT Policy
Easy to understand
NAT logic
Manual NAT Rules
Auto NAT Rules

(Public Web/DB)
G1/1 3
5 – NAT 2 G1/2 G1/3
3
VLAN 151
7 3
5 6 G1/4
G7/1

3
VPC
 Inspection
 SSL VDC
3 3
 Implement HA
FTD NGFW Policies
Reference

Yes
Application
Identification
Event Gen or Allow
Yes No
No DROP No
Permit
Yes
No
Yes Yes Yes

DROP
No No
No No
DROP DROP DROP DROP
NGFW Policy Types in FTD
Policy Type Function
Access Control Specify, inspect and log network traffic
Intrusion Inspect traffic for security violations (including block or alter)
Malware & File Detect and inspect files for malware (including block)
SSL Inspect encrypted traffic (including decrypt and block)
DNS Controls whitelisting or blacklisting of traffic based on domain
Identity Collect identity information via captive portal
Prefilter Early handling of traffic based L1-L4 criteria
Access Control Policy Overview
• Controls what and how traffic is allowed, blocked, inspected and logged
• Simplest policy contains only default action:
• Block All Traffic
• Trust All Traffic – Does not pass through Intrusion and Malware & File inspection
• Network Discovery – Discovery applications, users and devices on the network only
• Intrusion Prevention – Using a specific intrusion policy
• Criteria can includes zones, networks, VLAN tags, applications, ports, URLs and
SGT/ISE attributes
• The same Access Control Policy can be applied to one or more device
• Complex policies can contain multiple rules, inherit settings from other access
control policies and specify other policy types that should be used for inspection
Access Control Policy Use Case #1
Allow MS SQL from inside to pubdmz
Rules below are

still processed
Displays block
page over HTTP
Determines if rule can be

overridden by child policy
Access Control Policy Use Case #1 – Applications
Access Control Policy Use Case #1 – Logging Tab
Logging will increase the number of

events the FMC must handle. Be
sure to consider your logging
requirements when sizing your FMC
Access Control Policy Use Case #2 – Introduction
CLINET requirements:
• Allow all outbound HTTP/HTTPS traffic, regardless of port
• Perform IDS inspection of the traffic (with all Chrome rules enabled)
• Block any malware
• Block any HTTPS connections that use a self-signed certificate
• Policies we’ll need to create:

1. Intrusion Policy
2. Malware & File Policy
3. SSL Policy
Intrusion Policy Overview
• Controls how IDS or IPS inspection is performed on network traffic
• Simple policy inherits settings from 1 of 5 Cisco Talos maintained base policies:
• Balanced Security and Connectivity – Default and recommended
• Connectivity Over Security – Fewer rules enabled, only most critical rules block
• Maximum Detection – Favors detection over rated throughput
• No Rules Active
• Security Over Connectivity – More rules enabled, deeper inspection
• Individual rules can be set to generate events, drop and generate events, or
disabled
• Layers allow for grouping of settings/rules for easier management
• Complex policies can contain multiple layers and multiple levels of inheritance
Intrusion Policy for Use Case #2
Detection Only (No Inline Blocking) + Alert on Chrome Attacks
Intrusion Policy for Use Case #2
IDS  Drop when Inline unchecked

IPS  Drop when Inline checked
Intrusion Policy for Use Case #2 – Rules Menu
Freeform search
Selecting browser-chrome
populates the appropriate
filter in the filter bar
The rules are

now enabled
Malware & File Policy Overview
• Controls what and how files are allowed, blocked and inspected
• Simple policy applies the same action (Malware Cloud Lookup) to all files
• Actions are:
• Detect Files – Detect and log the file transfer, perform no inspection
• Block Files – Block and log the file transfer, perform no inspection
• Malware Cloud Lookup – Inspect the file to determine disposition (Malware, Unknown or
Clean) and log
• Block Malware – Inspect the file to determine disposition, log and block if Malware
• Inspection includes static analysis of the file (via Spero), dynamic analysis (via
AMP Threat Grid) and local analysis (via ClamAV)
• Complex policies can include different actions and levels of inspections for
different application protocols, directions and file types.
Malware & File Policy for Use Case #2
Block malicious Office, Executable and PDF files transferred over HTTP
Blocks all files matching

policy file type(s)
Detection only
(no blocking)
Stores files on
sensor for further
investigation by
Spero = Static Analysis analyst
Dynamic Analysis = Upload of

the file to the cloud for analysis
Capacity Handling = Store file

and resubmit if file submission
limit exceeded
Local Malware Analysis = Local

ClamAV signature scanning
Malware & File Policy for Use Case #2 – Rule Added
Add more rules

as needed
Rule we just
created
SSL Policy Overview
• Controls how and what encrypted traffic is inspected and decrypted
• Simple policy blocks all encrypted traffic that uses a self-signed certificate
• Actions are:
• Decrypt - Resign – Used for SSL decryption of public services (Google, Facebook, etc.)
• Decrypt - Known Key – Used when you have the certificate’s private key
• Do not decrypt
• Block
• Block with reset
• Monitor
• Many actions can be taken on encrypted traffic without decryption by inspecting
the certificate, DN, cert status, cipher suite and version (all supported by FTD)
SSL Policy for Use Case #2
Block Connections That Use a Self-Signed Certificate
For public servers (you don’t control)
For servers you control
SSL Policy for Use Case #2 – Cert Status Tab
None of these require

decryption of traffic
Access Control Policy – Revisited
The glue that ties everything together
Access Control Policy
Prefilter SSL Identity

DNS Policy
Policy Policy Policy
Inspection Options
Access Control Criteria Action

Rule (to match) Intrusion Malware & File
Policy Policy
Access Control Policy Use Case #2 – Recap
Inspect Outbound HTTP/HTTPS Connections (IDS, Malware and SSL)
• CLINET requirements:
• Allow all outbound HTTP/HTTPS traffic, regardless of port
• Perform IDS inspection of the traffic (with all Chrome rules enabled)
• Block any malware
• Block any HTTPS connections that use a self-signed certificate
• Policies we just created:

We now need to apply them
1. Edge Intrusion Policy
2. Edge Malware & File Policy
by creating a rule in the
3. Edge SSL Policy
Edge Access Control Policy
Note: We will do this with a single rule for time/demonstration purposes.

There are multiple ways the same result could be achieved depending on the overall policy required.
Access Control Policy Use Case #2 – Graphically
Edge Access Control Policy
Edge SSL
Policy
Inspection Options
Criteria Action
Access Control
Rule All HTTP Allow Edge Intrusion Edge Malware &
Traffic Policy File Policy
Access Control Policy Use Case #2 – Applications
Access Control Policy Use Case #2 – Inspections
Intrusion policy we
created previously
Malware & file policy

we created previously
Access Control Policy Use Case #2 – Logging
Log Files automatically

enabled with File
policy present
Access Control Policy Use Case #2 – Rule Added
SSL Policy applies to

the entire access control
policy, not just one rule
Rule we
just created
Access Control Policy Use Case #2 – Advanced Tab
This tab contains advanced settings for

the entire access control policy

(Public Web/DB)
G1/1 3
5 – NAT 2 G1/2 G1/3
3
VLAN 151
7 3
5 6 G1/4
G7/1

3
VPC
 Inspection
 SSL VDC
3 3
 Implement HA
FTD High Availability
Firepower Threat Defense High Availability
• Supported on all models (except in AWS)
• Stateful Active/Standby failover only
• All features are supported with failover
• Both NGFWs in pair must be identical in

Primary Failover Backup
software, memory, interfaces and mode NGFW NGFW
• On FP9300, failover is only supported (active) State (standby
)
• Across blades in different chassis
• In non-cluster mode
• Long distance LAN failover is supported if

latency is less than 100ms
Firepower Threat Defense High Availability (Part 2)
• Two nodes connected by one or two
dedicated connections called “failover links”
• Failover and state
• Can use the same link for both
• Best practice is to use a dedicated link for
each if possible (cross-over or VLAN) Primary Failover Backup
NGFW NGFW
(active) State (standby
• When first configured, Primary’s policies )
are synchronized to Secondary
• Configuration/policy updates are sent to
current active node by FMC
• Active unit replicates policies to standby
How Failover Works
Failover link passes Hellos between active
and standby units every 15 seconds
(tunable from 200msec - 15 seconds)
HELLO HELLO
Primary Failover Secondary

FTD FTD
(active) State (standby)
How Failover Works
HELLO
Primary Failover Secondary

FTD HELLO
FTD
(active) State (standby)
HELLO
After three missed hellos, local unit sends If no response…

hellos over all interfaces to check health of its
peer – whether a failover occurs depends on
the responses received
How Failover Works
Failover Secondary
FTD
State (active)
Local unit If no response…

becomes active
Reference
Stateful Failover Supported Features

• NAT translation table • URL With Notes:
• TCP connection states • Geolocation • Dynamic Routing
• UDP connection states • URL Filtering Protocols
• Snort connection states • TLS sessions not decrypted • AVC
• Strict TCP enforcement • TLS URL • IPS Detection state
• The ARP table • User Agent • File malware blocking
• The Layer 2 bridge table • ISE Session Directory • File type detection
• SIP signaling sessions • IP Reputation • Identity/Captive Portal
• Snort Inspection • URL Reputation • Signature Lookup
• Static Routes • DNS Sinkhole • File Storage
• DHCP Server • Fragment settings • File Pre-class (Local
• ARP Inspection Analysis)
• File Dynamic Analysis
• Archive File Support
See Chapter: Firepower Threat Defense High Availability for full details:
• Custom Blacklisting
http://www.cisco.com/c/en/us/td/docs/security/firepower/601/configuration/guide/fp
mc-config-guide-v601/fpmc-config-guide-v601_chapter_01100110.html
Easier Way: Stateful Failover Unsupported Features
• Every feature is supported, except:
• Sessions inside plaintext tunnels
• Inspection after decryption
• TLS Decryption State
• The HTTP connection table
• DHCP client
• DHCP server address leases
• Multicast routing
HA with Interface Redundancy
Before… After with redundant interfaces
Primary Failover Backup Primary Failover Backup

FTD FTD FTD FTD
(active) State (standby) (active) State (standby)
HA with Interface Redundancy
Before… After with redundant interfaces
Failures 11 - 7,
7 still
no FAILOVER
1
1 2 3
Any Causes
1 4
1
FAILOVER
Primary Failover Backup Primary Failover Backup

FTD FTD FTD FTD
(active) State (standby) (active) State (standby)
5
1
1 6 7
Port Channel feature makes this concept somewhat obsolete if switches support VSS/vPC
Deploying Active/Standby Failover
With both devices added to FMC, use “Add High Availability” dropdown
Deploying Active/Standby Failover
Whoops! Good to go!

• Fix the error and try again.
• In the example below, policies had
been changed, but not yet
deployed
Best practice - separate

interfaces/VLANs
Deploying Active/Standby Failover – Secondary IPs
Required to send hellos between data interfaces
Edit interfaces to add

standby IP addresses
for better interface
monitoring

(Public Web/DB)
G1/1 3
5 – NAT 2 G1/2 G1/3
3
VLAN 151
7 3
5 6 G1/4
G7/1

3
VPC
 Inspection
 SSL VDC
3 3
 Implement HA
Deploying FTD in Transparent Mode
FTD Deployment Checklist (Data Center)
 Specific Items for FTD in the Data Center
1 – Verify Deployment Mode – Routed or Transparent
2 – Transparent Mode Firewalls
 Deploying Transparent Mode
 How Transparent Mode Works
3 – Flow Bypass
 Deploying FTDv (Virtual FTD)

4 – ESXi Deployment
A Note about the ASA for DC Deployments
• ASA image is still a very common deployment for many use cases:
• Scalability – ASA supports 16 node clusters, over 1 TBPS of throughput
• Spanned DC – ASA supports clustering across physical DCs
• Firewall Consolidation – ASA supports up to 250 contexts
• FTD supported hardware (ASA5555-X, FP9300, etc.) are all capable of running
the ASA software image and are field upgradeable from the ASA image to the
Firepower Threat Defense (FTD) image
• Pick the right software image for your use case!
Review: Modes of Operation 192.168.1.1
• Routed Mode is the traditional mode of the firewall. Two or

more interfaces that separate L3 domains – Firewall is the VLAN192
Router and Gateway for local hosts
• Transparent Mode is where the firewall acts as a bridge
functioning at L2
• Transparent mode firewall offers some unique benefits in the DC VLAN1920
• Transparent deployment is tightly integrated with our ‘best
practice’ data center designs 192.168.1.0/24
IP:192.168.1.100
GW: 192.168.1.1
Why Deploy Transparent Mode?
• Very popular architecture in data center environments
• Existing Nexus/DC network fabric does not need to be modified to employ L2 Firewall!
• It is as simple as changing host(s) VLAN ID
• Firewall does not need to run routing protocols / become a segment gateway
• Firewalls are more suited to flow-based inspection (not packet forwarding like a router)
• Routing protocols can establish adjacencies through the firewall
• Protocols such as HSRP, VRRP, GLBP can cross the firewall
• Multicast streams can traverse the firewall
• Non-IP traffic can be allowed (IPX, MPLS, BPDUs)
• Much faster deployment time for brown field (months vs. years)
Firewall – Transparent Mode
• Firewall functions like a bridge
• “Bump in the wire” at L2
• Only ARP packets pass without an explicit

ACL
• Full policy functionality is included – NAT,
AVC, NGIPS, AMP, etc.
• Same subnet exists on all interfaces in the
bridge-group
• Different VLANs on inside and outside
interfaces
Transparent Mode Configuration in the DC (2 interfaces)
Step 1 – Create Port-Channel to Nexus
SVI VLAN200 172.16.25.253 SVI VLAN200 172.16.25.254
FHRP – 172.16.25.1 FHRP – 172.16.25.1
North Zone
VLAN 200
None
No Security
Zone
VPC
VLAN 200
Outside
VLAN 201
Inside
VPC BVI 172.16.25.86/24
Trunk Allowed 1,201 South Zone

VLAN 201
No IP either
Server in
VLAN 201
Step 2 – Create Sub Interfaces (1 for each VLAN)
SVI VLAN200 172.16.25.253 SVI VLAN200 172.16.25.254
FHRP – 172.16.25.1 FHRP – 172.16.25.1
North Zone
VLAN 200
VPC
VLAN 200
Outside
VLAN 201
Inside
VPC BVI 172.16.25.86/24

VLAN 201
Server in
VLAN 201
Part 3 – Stitch everything together with a Bridge Group Interface
SVI VLAN200 172.16.25.253 SVI VLAN200 172.16.25.254
FHRP – 172.16.25.1 FHRP – 172.16.25.1
North Zone
VLAN 200
VPC
VLAN 200
Outside
VLAN 201
Inside
VPC BVI 172.16.25.86/24

VLAN 201
Server in
VLAN 201
Reference
FTD L2 Mode: Local Packet
10.10.44.100
Destination 1
1
SVI VLAN200 172.16.25.253 SVI VLAN200 172.16.25.254

FHRP – 172.16.25.1 FHRP – 172.16.25.1
1 Session Request to server 172.16.25.200 from North Zone

source 10.10.44.100
44 VLAN 200
22
2 ARP request (or Lookup) 172.16.25.200 on
VLAN 200– ARP Reply from FTD containing
local MAC (outside) on VLAN tag 200. ARP
request packet actually passes through FTD
and on return trip to the Nexus the FTD
updates its MAC table with the server MAC
with VLAN 201 (Inside). It forwards a reply to VPC
the Nexus with its server MAC and a VLAN 200 VLAN 200
tag (rewritten). This is how the Nexus knows to Outside
direct traffic thru the FTD to reach server.
3 FTD receives packet with Server destination

33 VLAN 201
Inside
172.16.25.200 and processes the access VPC BVI 172.16.25.86/24
control policy. If allowed, it forwards the
packet back to the Nexus with a VLAN tag of
201.
4 Since Nexus does not have an SVI for VLAN

201, it forwards packets across it local trunk
which allows VLAN 201 tag – southbound Trunk Allowed 1,201 South Zone
towards the 5K. Source MAC address is the VLAN 201
FTD 55
5 Request is delivered to Server 172.16.25.200 in Server in VLAN 201
VLAN 201 172.16.25.200
Reference
FTD L2 Mode: Remote Packet
10.10.44.100
Destination 5
SVI VLAN200 172.16.25.253 SVI VLAN200 172.16.25.254

FHRP – 172.16.25.1 FHRP – 172.16.25.1
1 Return path from server 172.16.25.200 in VLAN North Zone

201 to remote destination 10.10.44.100
4 2 VLAN 200
2 Packet received on Nexus from Server on

VLAN 201. MAC in table that processes these
packets is FTD inside interface (from
southbound example) Traffic is redirected to
FTD (inside) VLAN tag 201
VPC
3 FTD receives packet with destination VLAN 200
10.10.44.100 and processes the access control Outside
policy. If FTD does not have MAC Address in
table, it sends an ICMP-Echo packet to
10.10.44.100 (sourced from its BVI IP Address) 3 VLAN 201
Inside
with TTL=1. FHRP on Nexus will respond with
Time Exceeded, MAC address = FHRP MAC VPC BVI 172.16.25.86/24
VLAN 200 (Outside) which will update FTD
MAC table with the MAC-IP Mapping of Nexus
on VLAN 200 (outside)
4 FTD forwards packet to Nexus SVI (FHRP)

address 172.16.25.1 on VLAN 200 for delivery Trunk Allowed 1,201 South Zone
to destination 10.10.44.100 VLAN 201
1
5 Nexus executes ARP request (if necessary) per
standard routing function. Request is Server in VLAN 201
forwarded towards destination 10.10.44.100 172.16.25.200
3 – Flow Bypass

FTD Flow Bypass
FTD Flow Offload
• Trusted flow processing with limited security visibility
• Maximize single-flow throughput and packet rate, minimize latency
• High performance compute, frequency trading, demanding data center applications
• Static hardware-based offload in Smart NIC for FTD

• Automatically enabled when rule in Prefilter Policy uses the Fastpath action
• Targeting 30Gbps+ per single flow (TCP/UDP) and 2.9us of 64-byte UDP latency
• Unicast IPv4 TCP/UDP/GRE and VLAN encapsulation only, no CMD/SGT
• Conditional offloading and selective inspection in the future
Reference
FTD Flow Offload Operation

Full Inspection Extended Offload Path (Future)
• Dynamically program Offload engine after flow establishment • Dedicated x86 cores for advanced processing
• Ability to switch between Offload and full inspection on the fly • Packet capture and extended statistics
Firepower 4100 or 9300

x86 CPU Complex
Full FTD Engine Lightweight Data Path
New and fully Offload Flow Advanced

inspected flows instructions updates Processing
Incoming Established
Flow Classifier Rewrite Engine
traffic trusted flows
Smart NIC
Flow Offload
• Limited state tracking, NAT/PAT, TCP Seq Randomization
• 30-40Gbps per single TCP/UDP flow, 2.5us UDP latency, 32K tracked flows
FTD Virtual Firewall Deployment
clinet.com Virtual DC FTD Deployment Details
VLAN 1299
VLAN 2 VLAN 120
DMZ Zone
Sidecar Inside
for
network Network
contractor / Data Center
for ‘Trusted
BYOD Core
Scanning Zone”
unknown (Routed)
Core VDC
OSPF Routed Core
Data Center
Aggregation
Aggregation
VDC
Virtual Access /
Compute Networks
FTD H/A Pair
Virtual FTD (FTDv) deployed

within hypervisor to protect
East/West Traffic Flows
Cisco Virtual FTD and FMC
VMware KVM (FTD 6.1)

OVF for vSphere and ESXi Cisco FTDv qcow2 image
VMware ESXi 5.x, 6.x Public Cloud
KVM 1.0 Virtio driver
E1000, VMXNET3
Amazon Web Services
AMI in the marketplace
Same Feature Set As Physical Appliances
Reference
Cisco FTDv for VMware

• ESXi version 5.1 and 5.5 (FTD 6.0) and ESXi version 6.0 (FTD 6.1)
• Interfaces
• Default of 4 E1000 interfaces (1 management, 3 data)
• Minimum of 4 interfaces required – even if your use case requires less
• Maximum of 10 interfaces (1 management, 9 data)
• VMXNET3 interfaces for 10G also supported
• 4 GB default / 8 GB max (allocate more, based upon features – e.g. AMP)

• 4 vCPU default / 8 vCPU max (allocate more for better performance)
• 40GB hard disk is allocated and cannot be changed
• No web interface. You must initially configure via console CLI and manage from
Firepower Management Center.
Virtual FTD Installation steps (vSphere)
Deploy OVF Template
Enter the details asked

for by the Setup Wizard
Add FTD to Firepower

Management Center
Reference
Cisco FTDv for VMware

High Availability
FTDv FTDv
VM (Active) FTDv FTDv (Standby)
VM VM VM VM
VM Port-Group Failover VM VM
Port-Group A
VM VM VM VM
Port-Group B
Distributed Virtual Switch
ESXi-1 ESXi-2
• Supports Active/Standby HA for Stateful Failover. No caveats.

• A dedicated segment and failover interface is recommended. The loss of the failover
link and keep-alive messages may introduce loops (both units become Active)
• No Live Migration and other VMware High Availability tools are supported
FTDv Deployment Scenario – Passive
• Monitoring traffic between Server A
ESXi Host
and Server B
Management
• Dedicated FTDv per ESXi host
Sensing
• Promiscuous mode enabled in ESXi FTDv
for FTDv Sensing port group vSwitch2
Virtual
Server A
Virtual
Server B
vSwitch3 | P Port Group
NIC2 NIC3
FTDv Deployment Scenario – Routed
• L3 NGFW gateway for servers
ESXi Host
• Configure 2 vSwitches: Management
• One with external interface (Outside)
• One with without (Inside) Outside Inside
FTDv
• Servers connect to Inside vSwitch vSwitch2
Virtual
Server A
• Port groups used for the Outside
interface must have only 1 active Virtual
Server B
uplink
vSwitch4 vSwitch3 | P Port Group
Protected vSwitch
NIC2 NIC4
FTDv Deployment Scenario – Transparent
• NGFW segmentation between hosts
ESXi Host
• Bridge up to 4 segments per BVI Management
• Configure 2 vSwitches:
Outside Inside
• One with external interface (Outside) FTDv
• One with without (Inside) vSwitch2
Virtual
Server A
• Servers connect to Inside vSwitch
Virtual
• Promiscuous mode enabled in ESXi Server B
for FTDv Inside port group
vSwitch4 vSwitch3 | P Port Group
• Use port channels to avoid loops – Protected vSwitch
disable any NIC teaming NIC2 NIC4
3 – Flow Bypass

Project
Complete!
Wrapping Up
Session Summary
You should now be able to:
• Describe the core capabilities of Firepower Threat Defense (FTD)
• Determine the firewall deployment that is appropriate for which use case
• Describe how resilience is provided through high availability
• Deploy FTD at the edge, in the data center and virtually
• Utilize next-generation firewall features to provide effective network security
BRKSEC-2020 © 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public
Complete Your Online Session Evaluation
• Give us your feedback to be
entered into a Daily Survey
Drawing. A daily winner will
receive a $750 Amazon gift card.
• Complete your session surveys
through the Cisco Live mobile
app or from the Session Catalog
on CiscoLive.com/us.
Don’t forget: Cisco Live sessions will be available

Please leave comments! for viewing on-demand after the event at
(and your email if you want a response) CiscoLive.com/Online
Continue Your Education
• Demos in the Cisco campus
• Hands-On NGFW Demo
• Central and Local Firepower Management
• Lunch & Learn

• Firepower and ASAv (Wed)
• Related sessions
• BRKSEC-2050 – ASA Firepower NGFW typical deployment scenarios
• Mon @ 1:30 PM & Tue @ 1:30 PM
• BRKSEC-2058 – A Deep Dive into using the Firepower Manager
• Wed @ 8:00 AM & Wed @ 1:30 PM
Presentation ID © 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public 142
Security Joins the Customer Connection Program
Customer User Group Program
19,000+
Members
• Who can join: Cisco customers, service Strong
providers, solution partners and training partners
• Private online community to connect with Join in World of Solutions
peers & Cisco’s Security product teams
Security zone  Customer Connection stand
• Monthly technical & roadmap briefings via
WebEx  Learn about CCP and Join
 New member thank-you gift*
• Opportunities to influence product direction  Customer Connection Member badge ribbon
• Local in-person meet ups starting Fall 2016

Join Online
• New member thank you gift*
& badge ribbon www.cisco.com/go/ccp
when you join in the Cisco Security booth
Come to Security zone to get your new member gift*
• Other CCP tracks: Collaboration & Enterprise and ribbon
Networks
* While supplies last
Thank you

Brksec 2020

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Brksec 2020

Uploaded by

Copyright:

Available Formats

Firewall Deployment (FTD)

Steven Chimes, Consulting Systems Engineer

BRKSEC-2020 BRKSEC-2050 BRKSEC-2058

BRKSEC-3004 BRKSEC-2030 BRKSEC-3035 BRKSEC-3032

• Deploying the L2 Firewall in the Data Center

(SM-24, SM-36, SM-44)

Firepower (L7) Firepower Threat Defense

• Application inspection Migration

DMZ Network Edge

Deploy Redundant Firepower

FTD H/A Pair

4 – Routing DMZ Network(2)

 Access Control VPC

Firepower Firepower 5.4

FMC Installation Guide: http://www.cisco.com/c/en/us/td/docs/security/firepower/hw/firepower_management_center/management_center/installation.html

• FTD is managed by FMC through a management interface.

FTD Inside Outside

• Initial setup through console interface is prompted. Default username/password

• Prompts to configure both password and management connectivity (IPv4 and/or

• 5506-X, 5508-X and 5516-x include a easy to use/simplistic local manager.

• Connection to FMC must be preconfigured on FTD, single line command.

Select based Access Control

• Routed Mode is the traditional mode of the firewall. Two or

Basic Interface Configuration

GigabitEthernet1/4 G1/3 VLAN 150

No IP either Edge Aggregation

G1/3 VLAN 150

Repeat 1x for VLAN 151

Deploying the Redundant DMZ Interfaces

G1/3 VLAN 150

• A vPC Peer Link is used on Nexus devices to instantiate the 10G

• vPC White paper:

• Supported in all modes (transparent and routed)

• Redundant interface feature and LAG on FTD are

Deploying the Inside Interfaces with EtherChannel

Deploying the Inside Interfaces with EtherChannel

4 – Routing DMZ Network(2)

 Access Control VPC

FTD Packet Processing Flow

SSL Policy Enforcement

Yes Yes Yes

DROP DROP DROP DROP

• FTD Supports static routing and most IGP routing protocols:

• Multicast (FTD 6.1)

• Complete IP Routing configuration in config guides:

• BGP RIB is replicated in failover along with other protocols

Non Stop Forwarding (NSF)

Next slide is from

4 – Routing DMZ Network(2)

 Access Control VPC

FTD Packet Processing Flow

SSL Policy Enforcement

Yes Yes Yes

DROP DROP DROP DROP

• Manual NAT – Source (and possibly destination) is used as a match criteria

• NAT is ordered within 3 sections.

Auto NAT Rules

4 – Routing DMZ Network(2)

 Access Control VPC

FTD Packet Processing Flow

SSL Policy Enforcement

Yes Yes Yes

DROP DROP DROP DROP