CCIE Security - FTD NGFW (INE-converted)

Introduction to
Firepower Systems
Copyright © www.ine.com
Firepower Systems Overview
 An evolved version of Snort-based IPS - SourceFire
Acquired by Cisco (2013) and re-branded to Firepower
Previously FireSIGHT, FirePOWER or FirePower
Originally also referred to as Next-Generation IPS (NGIPS)
 Firepower is now often sold as Firepower Threat Defense (FTD)

A combination of NGIPS & ASA with additional features
Also known as Next-Generation Firewall (NGFW) or NGFW/NGIPS
Firepower Threat Defense (FTD)
 FTD Features
ASA : L2-L4 Stateful Firewall, Application Inspection, NAT, ACL, Routing, HA
Firepower : IPS, AVC, URL Filtering, AMP
Other : Security Intelligence, Prefiltering & more
Firepower System Components
 Management appliance
Firepower Management Center (FMC)
Previously Sourcefire Defense Center or FireSIGHT Management Center
 Sensor
ASA FirePOWER Services module
Physical & virtual appliances
Firepower Sensor Platforms
 Firepower NGIPS
FirePOWER 7000/8000 series
G2 & 4000 ISRs
NGIPSv
 FTD NGFW
Firepower 2100/4100/9300 series
Most ASA-X appliances
Except for 5505 & 5585
NGFWv
FTD Management
FTD Management Overview
 FTD can be configured using two solutions
Firepower Device Manager (FDM)
Software-included
Accessible through a browser
Firepower Management Center (FMC) Appliance
Recommended
 FDM functionality is limited

Unsupported features
Might work for very small networks
Firepower Management Center (FMC)
 Dedicated appliance capable of managing multiple FTDs
FMC 1000
50 sensors, 50k hosts & users, 900 GB event storage
FMC 2500
300 sensors, 150k hosts & users, 1.8 TB event storage
FMC 4500
750 sensors, 600k hosts & users, 3.2 TB event storage
FMCv
25 sensors, 50k hosts & users, 250 GB event storage
Management Interfaces
 FMC’s management port
Default/initialized IP can be changed via GUI or SSH (configure-network)
Requires root privileges (sudo su first or sudo configure-network)
 FTD’s physical management port comprises two logical interfaces

Diagnostic (optional)
SNMP and/or Syslog monitoring
Management (br1)
Used for administration (GUI, SSH) & sensor registration
Configured during initial setup
IP address can be changed with configure network or from FMC
Verify with show network

FTD CLI (6.1+)
 The management port can be configured for SSH
Login with user „admin” & password „Admin123”
 FTD Shell Types

Default shell (CLISH)
Diagnostic CLI
Moves you to the ASA aka „LINA” OS
system support diagnostic-cli
Linux shell
expert
FXOS (hardware platforms only)
FTD Registration
The Registration Procedure
 To manage a sensor with FMC you need to first register it
Requires a working license
 The registration is performed over an encrypted tunnel

Built between management ports (FMC -> FTD) over TCP port 8305
 The Procedure
Console/SSH to FTD and add FMC (configure manager add)
Verify TCP socket with netstat
Enter the FTD details on FMC (Devices -> Device Management -> Add Device)
Check the session details on FTD (show managers or sftunnel-status)
FTD Troubleshooting
Troubleshooting FTD
 A packet traversing FTD may be dropped by one of two engines
Firewall
Sometimes referred to as LINA
Firepower
 Troubleshooting Tools
Connection Events
Ping, Traceroute & Show Commands
Packet Tracer (packet-tracer)
Packet Capture (capture vs capture-traffic)
Troubleshooting Firewall Engine
 Traffic Capture
capture name interface if match
View with show capture
The file can be downloaded via HTTPS
HTTPS : Devices -> Platform Settings -> Threat Defense Settings Policy
Navigate to https://IP_addr/capture/http_traffic/pcap/file_name.pcap
 Example
ICMP traffic from 10.1.1.1 to 10.2.2.2 on the inside
capture CAP1 interface inside match icmp host 10.1.1.1 host 10.2.2.2
Troubleshooting Firepower Engine
 Traffic Capture
capture-traffic
Useful options
Display Ethernet header (-e)
Print ASCII/HEX values (-X)
Number of packets to capture (-c)
Useful keywords
host, net
port, portrange
src, dst
and, or, not
Troubleshooting Firepower Engine
 Traffic Capture Examples
Five HTTP packets between a web server & host 172.16.1.1 (to & from)
capture-traffic -c 5 host 172.16.1.1 and port 80
SSH traffic originated by 10.1.1.1
capture-traffic src 10.1.1.1 and dst port 22
 Capture & Packet Tracer are built-in to the FMC GUI since 6.2
Devices -> Device Management -> Troubleshoot -> Advanced
Troubleshooting
FTD Objects
Objects Overview
 Most of the FTD features are configured with the use of Objects
Object is a system- or user- defined component associated with a value
Object Types
Network, Port
URL
Variable Sets
Interface
Certain types of Objects can be grouped into an Object Group
Contains one or more Objects and/or values
Configured under Objects -> Object Management
Interface Objects
 Allow to combine interfaces sharing some common criteria
Security Zone
The level of trustworthiness of connected networks
Note : security-levels are not used
One per interface
Interface Group
Arbitrary criteria
 Each FTD interface must be assigned to a Zone and/or Group

Some policies only support Zones, some Zones & Groups
FTD Deployment Modes
FTD Deployment Terminology
 Term „FTD Mode” refers to two aspects of the deployment
Operational
Routed vs Transparent
Also referred to as Firewall Mode
Determines available Interface Modes
Functional
NGIPS vs NGFW
NGIPS = IPS-only
NGFW = Firewall & optional IPS
Determined by configured Interface Modes
FTD Deployment Terminology
 FTD Interface Modes
Routed Mode
Routed
Inline Pair
Inline Pair with Tap
Passive
Transparent Mode
Transparent/Switched/BVI
Inline Pair
Inline Pair with Tap
Passive
Passive (ERSPAN)
Deploying FTD
 FTD function depends on the mode of configured interfaces
NGFW
Routed or Transparent/Switched/BVI
Using both types is referred to as Integrated Routing & Bridging (IRB)
NGIPS (IPS-only)
Passive, Passive (ERSPAN), Inline Pair or Inline Pair with Tap
Using different modes on a single unit is allowed
 Design Aspects
Firewall & IPS functions might need to be separated between the units
Performance, policy requirements, etc.
Firewall Modes
 Routed FTD acts as a L3 hop in the network
Interfaces belong to different IP subnets and traffic is routed between them
 Transparent FTD bridges different L2 networks under 1 IP subnet

Interfaces belong to the same bridge group
IP address is only configured on the BVI
 Firewall mode is selected during initial setup

Use configure firewall to change it
The unit must be first unregistered from the FMC
Changing the firewall mode wipes out any existing FTD configuration
Firewall Modes : Pros & Cons
 Deploying Routed FTD into a live network causes problems
Requires new IP subnet(s) and re-addressing
Supports all main FTD features
 Transparent FTD easily fits into existing infrastructure

L3 settings don’t change
Commonly deployed in Data Centers
Does not support certain features, such as dynamic routing, QoS or VPNs
 NGIPS functions can be enabled in any Firewall Mode
NGIPS (IPS-only) Mode : Passive
 Passive interface works on a copy of real traffic
Usually delivered by SPAN, RSPAN or ERSPAN
Makes FTD an Intrusion Detection System (IDS)
Packets cannot be blocked or normalized
NGIPS (IPS-only) Mode : Inline
 Inline mode correlates (pairs) two individual interfaces
Packets coming in on one interface always leave through the other
Similar to Transparent mode with two bridged interfaces
Makes FTD an Intrusion Prevention System (IPS)
The device sits “inline” with real traffic and can drop or normalize packets
Interface pair(s) must be associated with an Inline Set
Devices -> Device Management -> Inline Sets
Optionally the “Tap” mode may be enabled to test the policies
Also known as Inline Tap
Inline cabling is used but only a copy of the traffic is processed
FTD Initialization & Routing
FTD Initialization
 Regular firewall interfaces support HA modes & 802.1q trunking
Redundant Interfaces
EtherChannel
Physical appliances only
Subinterfaces
 Configuration
Devices -> Device Management -> Interfaces
Enable the physical port
Choose the interface type with Add Interfaces
FTD Routing Overview
 Routing on FTD is very similar to routing on the ASA
AD, metrics, static routes, separate RIB for management & data, etc.
 Supported Routing Protocols

OSPF (v2/v3)
BGP for IPv4 & IPv6
RIP for IPv4
EIGRP via FlexConfig

 Configuration
Devices -> Device Management -> Routing
FTD Policies
Policies Overview
 Policies control the traffic traversing through FTD
Each Policy offers a unique type of functionality
Identity
SSL
Intrusion Detection
Access Control and more
Policies Overview
 Common Policies characteristics
Consist of rules
Processed top down using first-match algorithm*
Each rule is made of several elements
Conditions
Actions
Explicit or implicit
Position
Logging settings & Comments
Policy-specific attributes
Policy Processing Order
 FTD policies & features are processed in a sequential order
Prefilter (global L3/L4 ACL)
Access Control Policy
L3/L4 ACL
Security Intelligence (IP)
SSL
Network Analysis (IPS – Preprocessors) & Network Discovery (Applications)
Security Intelligence (DNS, URL)
Identity
L7 (Application & URL filtering)
File + AMP
Intrusion Detection (IPS - Snort)
FTD Full Packet Processing
FTD Performance Optimization
 Proper Policy configuration improves FTD performance
Recommended rule order
L3/L4
L7 (DPI)
Application detection, URL Filtering, etc.
Advanced Firepower inspections
Intrusion & File Policies
Other guidelines
Constrain rules by interface (security zones, interface groups)
Minimize conditions (grouping into objects does not count)
Cut down on resource-intensive rules
Access Control Policy
Access Control Policy (ACP)
Overview
 Main source of policy information for FTD
Describes HOW traffic should be handled
E.g. allow or block
Invokes other Policies
SSL, Identity, Intrusion Detection and more
 ACP rules can be placed under two sections

Mandatory or Default
Important if you use Hierarchical Policies
Base Policy Mandatory rules go to the top
ACP Rule Actions
 Monitor
Tracks & logs traffic
The Policy processing does not stop - other rules are still evaluated
 Block (and Reset)

Blocks traffic without further processing
 Interactive Block (and Reset)

Works with HTTP & HTTPS only
Blocks traffic but displays a warning page allowing user to bypass the block
Bypassed traffic is processed like with “Allow” action (inspections apply)
ACP Rule Actions
 Allow
Inspects traffic with all configured Policies
E.g. Snort, File/AMP, Network Discovery, etc.
The traffic is allowed to pass unless blocked by one of those Policy engines
 Trust
Bypasses Snort, File/AMP & Network Discovery inspections
FTD does not perform DPI on Trusted, Blocked or Encrypted traffic
Traffic is inspected by SI, Identity & QoS Policies
The traffic is allowed to pass unless blocked by one of those Policy engines
Don’t use it for protocols negotiation secondary channels
ACP Default Action
 Traffic not matching any ACP rule is subject to the Default Action
Network Discovery Only
Trust All Traffic
Block All Traffic
Recommended for NGFW deployments
Intrusion Prevention
Snort + Network Discovery
File/AMP is not supported
Recommended for NGIPS deployments
ACP Logging
 Logging is by default disabled on every ACP rule (including default)
Except for “Monitor” rules
Security Events (e.g. IPS-detected attacks) are logged regardless of the
settings
 Logging can be enabled using the rule’s logging tab

Log either the beginning OR the end of any connection
Use “Log at Beginning of Connection” for “Block” rules
ACP & LINA
 Access Control Policy is deployed to both FTD engines
Firepower
/var/sf/detection_engines/UUID/ngfw.rules
LINA
Global ACL
CSM_FW_ACL_
 The LINA Global ACL

In addition to ACP, also stores Prefilter Policy rules
Prefilter rules go the top, then ACP
Rules listed as advanced permit don’t necessarily allow traffic
Special Policies
QoS Policy
 FTD supports traffic rate-limiting through a QoS Policy
Only evaluated for traffic matching ACP „Allow” or „Trust” rules
I.e. not prefiltered or blocked traffic
FTD supports one active QoS Policy
 Configuration
Devices -> QoS
CLI verification : show service-policy
Prefilter Policy
 Allows to exclude certain traffic from any Firepower inspections
Prefilter rules are evaluated before any other ACP rules at the LINA level
E.g. trusted elephant/latency-sensitive/control plane flows or any tunnels
Prefilter Policy & Tunneling
 ACP rules always apply to the innermost detectable header
Unless the tunnel is encrypted
This approach ensures the most granular level of inspection
May require a lot of additional resources
 Prefilter rules use L2-L4 information from the outer-header only

Useful to quickly pass/drop trusted/untrusted tunnels
Prefilter Policy Rules
 Prefilter Policy supports two types of rules : Tunnel & Prefilter
Tunnel
Useful to quickly match plain-text tunnels
GRE, IP-in-IP, IPv6-in-IP, Teredo
Bidirectional (default) or unidirectional
Supports rezoning
Tagging the tunnel with a new zone for re-evaluation in ACP
Prefilter
Used to match non-tunnel traffic based on L2-L4 conditions
VLAN, Security Zone, IPs, Protocol, Ports
Unidirectional
Prefilter Policy Actions
 Block
Blocks traffic without any further inspections
 Analyze
Passes traffic to ACP for further analysis using inner headers (if apply)
Does not drop/allow packets on its own
Allows for rezoning
Commonly used to make exceptions to a broader Fastpath rule
Prefilter Policy Actions
 Fastpath
Enables prefiltering
Exempts traffic from ALL further inspections & controls
ACP Rules, SI, Identity, SSL, IPS, File & AMP, Network Discovery & QoS
 ACP „Trust” vs Prefilter „Fastpath”

Bypasses DPI & Network Discovery, but not SI, authentication or rate-limiting
Supports conditions other than L3/L4
User, application, etc.
Inspects the innermost header
Prefilter Policy Configuration
 Prefilter Policy is invoked by ACP
The Default Prefilter Policy is used if no custom policy was defined
Affects tunnels only – passes traffic to the ACP
May be changed to „Block all tunnel traffic”
A new policy can be configured under Policies -> Access Control -> Prefilter
Activate it under Policies -> Access Control -> Advanced
Security Intelligence
Security Intelligence (SI) Overview
 Special FTD engine designed to quickly drop certain traffic
I.e. traffic originated by known malicious sources
IP addresses, URLs & domains
Identified by Talos
Improves performance
Early phase of ACP
SI Information Sources
 Feeds
Requires Threat License
 Manual Lists
Static IPs/URLs/domains to Blacklist or Whitelist
Blacklist IP/URL objects can be set for Monitor-only instead of Block
Logs packets as blacklisted without dropping them
Whitelisted or Monitored traffic still goes to the ACP
 Blacklist/Whitelist IP Now
Allows to blacklist/whitelist an address instantly from Connection Event
Viewer
SI Configuration : IPs & URL
 Dynamic Blacklisting
Update the Feed (Object -> Object Management -> Update Feeds)
Select the categories to use
Policies -> Access Control -> Security Intelligence
 Manual Lists
Add your entries into a .txt file
One record per line
Upload the file under Object -> Object Management -> Security Intelligence
Update ACP (Security Intelligence) with the new Object
DNS Policy
 Enables domain support for SI
Stops DNS Queries for known malicious or unsafe domains
No IP address -> no traffic to inspect
 DNS Policy consists of Whitelist & Blacklist sections

Whitelist rules take precedence over all Blacklist rules
First global, then custom
DNS Policy Actions
 Rule Actions determine ultimate handling of matching DNS traffic
Whitelist
Passes traffic to the ACP
Monitor
Traffic is logged but still evaluated by other rules
Blacklist
Drop
Domain Not Found
DNS Response with NXDOMAIN
Sinkhole
DNS Response with a false IP
SI Configuration : DNS Policy
 The system-provided DNS Policy is used by default
 Custom Policy
Define a custom Policy
Policies -> Access Control -> DNS
Edit rules
Add objects to use
Object -> Object Management -> Security Intelligence -> DNS Lists & Feeds
Enable the Policy
Policies -> Access Control -> Security Intelligence -> DNS Policy
URL Filtering
URL Filtering Overview
 HTTP/HTTPS traffic control mechanism
Manual URL Filtering
Individual URLs or URL Groups
No special license needed
Category-based URL Filtering
Category
Group of websites sharing similar content, e.g. cnn.com -> News
Reputation
Ranges from 1 (High Risk) to 5 (Well Known)
Requires URL Filtering license
Manual URL Filtering
 Commonly used to make exceptions to Category-based filtering
HTTP URLs are treated as substrings & subdomains are honored
I.e. only part of the URL must match
Example 1 : “trainings.com” matches “trainings.com”, “www.trainings.com”,
“ndtrainings.com”, but not “trainingsnd.com”
Example 2 : “streaming.ndtrainings.com” matches “www.streaming.ndtranings.com” but
not “ndtrainings.com”
Encrypted HTTPS URLs (certificate’s CN)
Disregards subdomains matching first-level domain only
E.g. use “ndtrainings.com” and not “streaming.ndtrainings.com”
Use the “Protocol” condition to distinguish between HTTP & HTTPS URLs
E.g. Allow URL “ndtrainings.com” & Application HTTPS
Category-based URL Filtering
 FTD caches URLs & their Category
If the URL information is missing a query to the FMC is sent
FMC’s behavior depends on the System -> Integration -> Cisco CSI setting
If “Query Cisco CSI for Unknown URLs” is on, the Cloud is checked
Otherwise FMC places the unknown URL into the “Uncategorized” group
 Traffic to unknown URLs may be passed immediately

Policies -> Access Control -> Advanced -> General Settings
Disable “Retry URL Cache Miss Lookup”
URL Filtering Configuration
 Pre-requisites
URL Filtering License (Category-based URL Filtering)
CSI Cloud must be on
System -> Integration -> Cisco CSI
 URL Filtering conditions are enabled directly in the ACP

Select the URLs tab
Define individual URLs and/or groups/lists under Object -> Object
Management
Network Discovery
Network Discovery Overview
 A detection mechanism designed for collection of network data
Running Applications, Hosts & Users
Used by certain FTD features
E.g. Firepower Recommendations
 Works by passively analyzing traffic traversing FTD

Traffic blocked by Prefiltering or ACP rules is not subject to analysis
Some devices generate low traffic or the traffic misses FTD
Actively collect information with NMAP
Policies -> Actions -> Scanners
Network Discovery Policy
 Controls the type & amount of discovered data
The Default Network Discovery Policy analyzes all IP traffic (0.0.0.0/0 + ::/0)
Detects applications only
Application detection engine requires first few packets in a session
 The Default (or new) Network Discovery Policy must be tuned

Policies -> Network Discovery
Replace the default “any IP” with your own networks to save resources
Choose the data to collect (Applications, Hosts, Users)
Host Profiles might be very useful for IPS deployments
Exclude Load Balancers & NAT devices from the discovery
File Policy
File Policy Overview
 File Policy allows to detect & inspect transmitted files
Supported protocols include FTP, HTTP, SMTP, IMAP, POP3 & NetBIOS-ssn
Consists of two separate features : File Control & AMP
File Control
Capble of blocking files of a certain type/extension
Requires Threat License
Advanced Malware Protection (AMP) for Networks
Detects & handles malware
Requires Malware License
File Control
 File Control is independent from malware inspections
Files can be blocked/allowed no matter if they are infected or not
Based on categories (e.g. multimedia) and/or types (e.g. PDF)
Does not require any Cloud lookups
If AMP and/or IPS is also configured for the traffic, File Control happens first
AMP for Networks
 The main AMP detection engine relies on hash comparisons
A SHA-256 hash of the file being analyzed is sent to FMC for disposition
FMC queries the AMP Cloud unless the hash was already cached
File Dispositions
Malware
Dynamic verdict (AMP Cloud)
Clean
This verdict can be dynamic (AMP Cloud) or static (Clean List)
Custom
Static verdict (Custom Detection List)
Unknown
Unavailable
AMP for Networks
 Hash-based file analysis might be extended with other engines
Dynamic
Sends “Unknown” files for additional analysis to AMP Threat Grid
Based on returned threat score the file can be blocked by the Policy
Spero
Heuristics (0-day attacks) for .exe files
Local
Local anti-virus scan with ClamAV
 Analyzed files can be also stored on FTD for further inspection
File Policy Configuration
 Pre-requisites
Adaptive Profiling must be enabled
Policies -> Access Control -> Advanced
 File Policy manages File Control and/or AMP settings

Policies -> Access Control -> Malware & File
Select application, transfer direction, files and/or categories
Enable File Control and/or AMP by using the appropriate action
 File Control
Detect Files
Allow, log and optionally locally store the file
Block Files
Enables true File Control – may block file based on its category/type
 AMP
Malware Cloud Lookup
Query the Cloud but allow the file regardless of the disposition
Block Malware
Enables true AMP – may block the file based on its disposition
 File Policy must be invoked by the ACP
Policies -> Access Control -> Inspection
Remember to “Allow” and not “Trust” or Prefilter for the inspected traffic
Verification
Analysis -> Files -> File Events
SSL Policy
SSL Policy Overview
 SSL Policy has two main applications
HTTPS decryption
Selective blocking of encrypted traffic
 Activating SSL Policy changes encrypted traffic handling behavior

SSL Policy is used before ACP
HTTPS Decryption
 FTD supports two SSL/TLS decryption methods
Known Key
Used for traffic coming to your network/servers
Server’s Private Key is uploaded to FTD
FTD decrypts the client-server traffic on the fly
Resign
Used for traffic to external servers
FTD splits the original session into two : client – FTD & FTD - server
The original server’s certificate is modified & resigned by FTD

 Decrypted web traffic is still subject to ACP inspections
Encrypted Traffic Blocking
 Decryption may pose severe load on FTD
SSL Policy can block traffic selectively without decrypting it
URLs, certificate status, SSL/TLS version, cipher suite & more
 Encrypted traffic handling

Server’s certificate
Does not work for wildcard certificates
Server Name Indication (SNI)
A browser includes website’s hostname inside of the TLS Client Hello
SSL Policy Actions
 Monitor
Log & check other rules
 Block (with Reset)

Immediately block traffic
 Don’t Decrypt
 Decrypt Known Key / Decrypt Resign

Perform decryption & send clear-text traffic to the ACP
SSL Policy Configuration
 Define PKI objects by importing the right certificates
Object -> Object Management -> PKI
Internal CA
Internal CA’s certificate (“keyCertSign” usage) & keys
Needed for “Decrypt Resign” rules
Internal Certificate
Your server’s certificate & keys
Needed for “Decrypt Known Key” rules
 Create a new SSL Policy & add rules
Policies -> Access Control -> SSL
 Activate the Policy

 Typical SSL Policy
Pass trusted outbound traffic unencrypted
E.g. backup traffic
Decrypt all traffic destined to your public servers
Add exceptions for outbound traffic that is subject to legal regulations
E.g. HIPAA
Decrypt all outbound web traffic
Use “Don’t decrypt” as the Default Action
Identity Policy
Identity Policy Overview
 Responsible for extraction of user identity information
Allows to build true identity-based ACP rules
Once Identity is extracted, it is bound to an IP address
 Identity Policy rules determine what traffic is subject to AuthC

Authentication can be Passive or Active
Passive authentication is transparent and relies on additional software
E.g. AD User Agent
Activate authentication uses the Captive Portal
Requires Routed interfaces
Identity Policy Configuration
 Define a Realm which represents an external Identity Store
System -> Integration -> Realms
Ensure that time is synchronized
 Create a Policy & Rules

Policies -> Access Control -> Identity
Select authentication method
Passive, Active, No Authentication
 Activate the Policy

Introduction to FTD NGIPS
FTD NGIPS Overview
 FTD offers top-notch NGIPS functionality based on Snort
Legacy IPS systems focus on threats (signatures) - NGIPS is much more than
that
Application/Protocol/User/Vulnerability/Context awareness
Advanced Event Correlation & others
 Deployment Modes
Passive (IDS)
Requires Passive, Passive ERSPAN or Inline Pair with Tap interface
Inline (IPS)
Requires Inline Pair interface
Normalization
 Snort requires packets to be presented in a standardized way
Handled by Preprocessors during Normalization
Stream/fragment reassembly, checksuming, protocol-specific, etc.
Evasion & attack detection

 Preprocessors are controlled by the Network Analysis Policy (NAP)
Intrusion Policy
 Controls Snort rules used to inspect network traffic
 Rule Types
Shared Object
Written by Talos
Irretrievable
Standard Text
Clear-text
Includes Custom (Local) rules
Uploaded from a .txt file or created using FMC GUI
Default Policies
 FTD comes with several Default Policies to expedite a deployment
Used as a baseline for a custom policy
Intrusion and/or Network Analysis
 Default Intrusion Policies

Differ in number of enabled rules & Preprocessor settings
No Rules Active
Balanced Security and Connectivity
Connectivity over Security
Security over Connectivity
Maximum Detection
Snort Variables & Rules
Snort Variables
 Snort rules work on variables rather than actual IPs/ports
Allows to use rules in any environment without modifying them
Located under Objects -> Object Management -> Variable Set
 Variable Types
$*_NET
Network/subnet addresses, such as $HOME_NET
$*_SERVERS
Individual server IPs, e.g. $DNS_SERVERS
$*_PORTS
TCP/UDP ports, like $HTTP_PORTS
Snort Variables
 Correct variable definition is critical to proper NGIPS operations
Always tune $HOME_NET and $EXTERNAL_NET values
Setting $EXTERNAL_NET to !$HOME_NET won’t always work
May leave trusted segments unprotected
Best Practices
Set $HOME_NET to all protected subnets & public ranges you own
Leave $EXTERNAL_NET as “any”
Tune all used $*_SERVERS and appropriate $*_PORTS
If in doubt, set $*_SERVERS to $HOME_NET
 Using multiple Variable Sets might be an alternative
Snort Rules
 Each Snort Rule consists of a Header and a Body
Rule Header
Tells what traffic to look at (L3/L4)
Source/destination IPs/ports, protocol & flow direction
Defines an action to take
Alert, pass, disabled, generate events, drop and generate event
Rule Body (Rule Options)
Describes the attack (Payload)
Keywords, arguments & patterns
A match triggers the rule action
Contains Event Message
Snort Rule Example
 Rule Header
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
 Rule Body
(msg:“Test rule fires”; flow:to_server,established; \
uricontent: “cgi/main/malware.exe”; reference:cve-1991-1345; \
classtype:web-application-activity; sid:9991; rev:1;)
Snort Rules
 Rule Body is formed with the aid of keywords & arguments
The Body always starts with “(“ and ends with “)”
If multiple lines are needed, separate them with “\”
Keywords end with “:” and the last argument/option end with “;”
Arguments/options are separated by commas
E.g. (msg:“Test rule fires”; flow:to_server,established;)
 Rules can be uploaded (.txt) or written using the FMC’s GUI
Rule Keywords & Arguments
 Keyword : content
Describes the string to look for in a packet
ASCII, hex characters (surrounded by “|”), or both
E.g. “|28|C|29|/bin/sh” matches (C)/bin/sh
Sample Arguments
nocase
offset
depth
From the beginning of the payload or offset (if configured)
distance
Number of bytes from the previous match (for subsequent matches)
 Keyword : pcre
Allows to use Perl-compatible regular expressions to look for content
Regular expression must be enclosed within “//”
E.g. /mail(file|seek)\.cgi/
Optional modifiers follow the regex
/regex/ismxAEGRBUIPHDMCKSY
Refer to the DoC CD or Snort documentation (www.snort.org)

 Keyword : flow
Allows to specify the direction of the traffic
Sample Arguments
to client
from client
to server
established
stateless
Implementing NGIPS
NGIPS Configuration
 NGIPS is controlled by three Policies
Network Analysis
Intrusion
Access Control
NGIPS Configuration
 Network Analysis Policy (NAP)
ACP uses one global NAP by default
ACP -> Advanced -> Network Analysis and Intrusion Policies
For Custom NAP navigate to NAP from ACP or Intrusion Policy page
“Balanced Security and Connectivity” is recommended as a base
Tuning IP Defragmentation & TCP Stream is considered as a best practice
Custom NAP rules
NGIPS Configuration
 Intrusion Policy
Pre-requisites
Configure Snort Variables
Accurate $HOME_NET is critical to proper NGIPS operations
Policies -> Access Control -> Intrusion
“Balanced Security and Connectivity” is recommended as a base
Enable/disable/tune Snort rules
Objects -> Intrusion Rules
Consider using Firepower Recommendations
Firepower Recommendations
 Advises on which rules to enable/disable in a given network
Heavily relies on Network Discovery
Use Firepower Recommendations AFTER the discovery
 Configuration
Define networks to examine
Should match Network Discovery settings
Set Recommendation Threshold
Considers rule’s CPU overhead
As a best practice schedule Recommendations to re-run periodically
NGIPS Configuration
 Access Control Policy
Start with Advanced settings
Ensure that Adaptive Profiles are enabled
Tune the pre-scan Policy & choose NAP
Network Analysis and Intrusion Policies
Invoke Intrusion Policies in the ACP rules
Inspection
Re-configure the Default Action, if needed
 Verification
Analysis -> Intrusions -> Events

CCIE Security - FTD NGFW (INE-converted)

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

CCIE Security - FTD NGFW (INE-converted)

Uploaded by

Copyright:

Available Formats

Introduction to

Firepower is now often sold as Firepower Threat Defense (FTD)

FDM functionality is limited

FTD’s physical management port comprises two logical interfaces

FTD Shell Types

The registration is performed over an encrypted tunnel

Each FTD interface must be assigned to a Zone and/or Group

Transparent FTD bridges different L2 networks under 1 IP subnet

Firewall mode is selected during initial setup

Transparent FTD easily fits into existing infrastructure

NGIPS functions can be enabled in any Firewall Mode

Supported Routing Protocols

ACP rules can be placed under two sections

Block (and Reset)

Interactive Block (and Reset)

Logging can be enabled using the rule’s logging tab

The LINA Global ACL

E.g. trusted elephant/latency-sensitive/control plane flows or any tunnels

Prefilter rules use L2-L4 information from the outer-header only

ACP „Trust” vs Prefilter „Fastpath”

DNS Policy consists of Whitelist & Blacklist sections

Traffic to unknown URLs may be passed immediately

URL Filtering conditions are enabled directly in the ACP

Works by passively analyzing traffic traversing FTD

The Default (or new) Network Discovery Policy must be tuned

Analyzed files can be also stored on FTD for further inspection

File Policy manages File Control and/or AMP settings

Activating SSL Policy changes encrypted traffic handling behavior

Encrypted traffic handling

Block (with Reset)

Decrypt Known Key / Decrypt Resign

Activate the Policy

Identity Policy rules determine what traffic is subject to AuthC

Create a Policy & Rules

Activate the Policy

Default Intrusion Policies

Using multiple Variable Sets might be an alternative

Rules can be uploaded (.txt) or written using the FMC’s GUI

You might also like

 Firepower is now often sold as Firepower Threat Defense (FTD)

 FDM functionality is limited

 FTD’s physical management port comprises two logical interfaces

 FTD Shell Types

 The registration is performed over an encrypted tunnel

 Each FTD interface must be assigned to a Zone and/or Group

 Transparent FTD bridges different L2 networks under 1 IP subnet

 Firewall mode is selected during initial setup

 Transparent FTD easily fits into existing infrastructure

 NGIPS functions can be enabled in any Firewall Mode

 Supported Routing Protocols

 ACP rules can be placed under two sections

 Block (and Reset)

 Interactive Block (and Reset)

 Logging can be enabled using the rule’s logging tab

 The LINA Global ACL

 Prefilter rules use L2-L4 information from the outer-header only

 ACP „Trust” vs Prefilter „Fastpath”

 DNS Policy consists of Whitelist & Blacklist sections

 Traffic to unknown URLs may be passed immediately

 URL Filtering conditions are enabled directly in the ACP

 Works by passively analyzing traffic traversing FTD

 The Default (or new) Network Discovery Policy must be tuned

 Analyzed files can be also stored on FTD for further inspection

 File Policy manages File Control and/or AMP settings

 Activating SSL Policy changes encrypted traffic handling behavior

 Encrypted traffic handling

 Block (with Reset)

 Decrypt Known Key / Decrypt Resign

 Activate the Policy

 Identity Policy rules determine what traffic is subject to AuthC

 Create a Policy & Rules

 Activate the Policy

 Default Intrusion Policies

 Using multiple Variable Sets might be an alternative

 Rules can be uploaded (.txt) or written using the FMC’s GUI