Contents at a Glance

Introduction

Chapter 1 Fundamentals of Cisco Next-Generation Security

Chapter 2 Introduction to and Design of Cisco ASA with FirePOWER

Services

Chapter 3 Configuring Cisco ASA with FirePOWER Services

Chapter 4 Troubleshooting Cisco ASA with FirePOWER Services and

Firepower Threat Defense (FTD)

Chapter 5 Introduction to and Architecture of Cisco AMP

Chapter 6 Cisco AMP for Networks

Chapter 7 Cisco AMP for Content Security

Chapter 8 Cisco AMP for Endpoints

Chapter 9 AMP Threat Grid: Malware Analysis and Threat Intelligence

Chapter 10 Introduction to and Deployment of Cisco Next-Generation IPS

Chapter 11 Configuring Cisco Next-Generation IPS

Chapter 12 Reporting and Troubleshooting with Cisco Next-Generation IPS

Index

15
Contents
Introduction

Chapter 1 Fundamentals of Cisco Next-Generation Security

The New Threat Landscape and Attack Continuum

The Attack Continuum

Cisco ASA 5500-X Series Next-Generation Firewalls and the Cisco ASA
with FirePOWER Services

Cisco Firepower Threat Defense (FTD)

Cisco Firepower 4100 Series

Cisco Firepower 9300 Series

Cisco FTD for Cisco Integrated Services Routers (ISRs)

Next-Generation Intrusion Prevention Systems (NGIPS)

Firepower Management Center

AMP for Endpoints

AMP for Networks

AMP Threat Grid

Email Security Overview

Email Security Appliance

Cloud Email Security

Cisco Hybrid Email Security

Web Security Overview

16
Web Security Appliance

Cisco Security Management Appliance

Cisco Cloud Web Security (CWS)

Cisco Identity Services Engine (ISE)

Cisco Meraki Cloud-Managed MDM

Cisco Meraki Cloud-Managed Security Appliances

Cisco VPN Solutions

Summary

Chapter 2 Introduction to and Design of Cisco ASA with FirePOWER

Services

Introduction to Cisco ASA FirePOWER Services

Inline versus Promiscuous Mode

Inline Mode

Promiscuous Monitor-Only Mode

Cisco ASA FirePOWER Management Options

Accessing the Cisco ASA FirePOWER Module Management Interface in

Cisco ASA 5585-X Appliances

Accessing the Cisco ASA FirePOWER Module Management Interface in

Cisco ASA 5500-X Appliances

Cisco ASA FirePOWER Services Sizing

Cisco ASA FirePOWER Services Licensing

The Protection License

The Control License

17
The URL Filtering License

The Malware License

Viewing the Installed Cisco ASA FirePOWER Module Licenses

Adding a License to the Cisco ASA FirePOWER Module

Cisco ASA FirePOWER Compatibility with Other Cisco ASA Features

Cisco ASA FirePOWER Packet Processing Order of Operations

Cisco ASA FirePOWER Services and Failover

What Happens When the Cisco ASA FirePOWER Module Fails?

Cisco ASA FirePOWER Services and Clustering

Cluster Member Election

How Connections Are Established and Tracked in a Cluster

How a New TCP Connection Is Established and Tracked in a Cluster

How a New UDP-Like Connection Is Established and Tracked in a

Cluster

Centralized Connections in a Cluster

What Happens When the Flow Owner Fails

Deploying the Cisco ASA FirePOWER Services in the Internet Edge

Deploying the Cisco ASA FirePOWER Services in VPN Scenarios

Deploying Cisco ASA FirePOWER Services in the Data Center

Firepower Threat Defense (FTD)

Summary

Chapter 3 Configuring Cisco ASA with FirePOWER Services

18
Setting Up the Cisco ASA FirePOWER Module in Cisco ASA 5585-X
Appliances

Installing the Boot Image and Firepower System Software in the Cisco ASA
5585-X SSP

Setting Up the Cisco ASA FirePOWER Module in Cisco ASA 5500-X

Appliances

Installing the Boot Image and Firepower System Software in the SSD of
Cisco ASA 5500-X Appliances

Configuring of Cisco ASA 5506-X, 5508-X, and 5516-X Appliances

Uploading ASDM

Setting Up the Cisco ASA to Allow ASDM Access

Accessing the ASDM

Setting Up a Device Name and Passwords

Configuring an Interface

Configuring the Cisco ASA to Redirect Traffic to the Cisco ASA

FirePOWER Module

Configuring the Cisco ASA FirePOWER Module for the FMC

Configuring the Cisco ASA FirePOWER Module Using the ASDM

Configuring Access Control Policies

Creating a New Access Control Policy

Adding Rules to the Access Control Policy

Security Intelligence

HTTP Responses

Access Control Policy Advanced Settings

19
Configuring Intrusion Policies

Custom Rules

Configuring File Policies

Reusable Object Management

Keeping the Cisco FirePOWER Module Up-to-Date

Firepower Threat Defense

Installing FTD Boot Image and Software

FTD Firewall Mode

FTD Interface Types

FTD Security Zones

Static and Dynamic Routing in FTD

Summary

Chapter 4 Troubleshooting Cisco ASA with FirePOWER Services and

Firepower Threat Defense (FTD)

Useful show Commands

Displaying the Access Control Policy Details

Displaying the Network Configuration

Monitoring Storage Usage

Analyzing Running Processes

Using the System Log (Syslog)

Monitoring and Troubleshooting System Tasks

Generating Advanced Troubleshooting Logs

20
Useful ASA Debugging Commands

Summary

Chapter 5 Introduction to and Architecture of Cisco AMP

Introduction to Advanced Malware Protection (AMP)

Role of the AMP Cloud

Doing Security Differently

The Prevention Framework

1-to-1 Signatures

Ethos Engine

Spero Engine

Indicators of Compromise

Device Flow Correlation

Advanced Analytics

Dynamic Analysis with Threat Grid

The Retrospective Framework

The Cloud

Private Cloud

Cloud Proxy Mode

Air Gap Mode

Installing the Cisco AMP Private Cloud

Summary

Chapter 6 Cisco AMP for Networks

21
Introduction to Advanced Malware Protection (AMP) for Networks

What Is That Manager Called, Anyway?

Form Factors

What Does AMP for Networks Do?

Where Are the AMP Policies?

File Rules

Advanced File Policies

Summary

Chapter 7 Cisco AMP for Content Security

Introduction to AMP for Content Security

Content Security Connectors

Configuring Cisco AMP for Content Security

Configuring the Web Security Appliance (WSA) for AMP

Configuring the Email Security Appliance (ESA) for AMP

AMP Reports

Summary

Chapter 8 Cisco AMP for Endpoints

Introduction to AMP for Endpoints

What Is AMP for Endpoints?

Connections to the AMP Cloud

Firewalls, Destinations, and Ports, Oh My!

Outbreak Control

22
Custom Detections

Simple Custom Detections

Advanced Custom Detections

Android Custom Detections

IP Blacklists and Whitelists

Application Control

Exclusion Sets

The Many Faces of AMP for Endpoints

AMP for Windows

Windows Policies

General Tab

File Tab

Network Tab

Known Incompatible Software

AMP for Mac

MAC Policies

General Tab

File Tab

Network Tab

AMP for Linux

Linux Policies

General Tab

23
File Tab

Network Tab

AMP for Android

Installing AMP for Endpoints

Groups, Groups, and More Groups

Download Connector

Distributing via Cisco AnyConnect

Installing AMP for Windows

Installing AMP for Mac

Installing AMP for Linux

Installing AMP for Android

Android Activation Codes

Deploying the AMP for Android Connector

Proxy Complications

Proxy Server Autodetection

Incompatible Proxy Security Configurations

Using the Cloud Console

Summary

Chapter 9 AMP Threat Grid: Malware Analysis and Threat Intelligence

Cisco AMP Threat Grid

Cisco AMP Threat Grid Cloud Solution

Cisco AMP Threat Grid On-Premises Appliance

24
Default Users

Network Segment Configuration

Summary

Chapter 10 Introduction to and Deployment of Cisco Next-Generation

IPS

NGIPS Basics

Legacy IPS Versus NGIPS

Cisco NGIPS Capabilities

NGIPS Modes

NGIPS Deployment Locations and Scenarios

NGIPS Deployment Design Considerations

Threat Management and System Capabilities

Flow Handling

Scale and Availability

Management Platform Integration

Licensing and Cost

NGIPS Deployment Lifecycle

Policy Definition

Product Selection and Planning

Implementation and Operation

Evaluation and Control

Summary

25
Chapter 11 Configuring Cisco Next-Generation IPS

Policy

Policy Layers

Variables

Configuring a Cisco Firepower Intrusion Policy

Committing a Policy

Snort Rules

Rule Anatomy

Rule Headers

Rule Body

Writing a Rule

Managing Snort Rules in FMC

Cisco NGIPS Preprocessors

Firepower Recommendations

Performance Settings

Stack/Cluster

Summary

Chapter 12 Reporting and Troubleshooting with Cisco Next-Generation

IPS

Analysis

Intrusion Events

Intrusion Event Workflows

26
Reports

Incidents

Alerts

SNMP Alerts

Email Alerts

Syslog Alerts

Correlation Policies

Troubleshooting

Audit

Health Monitoring

Syslogs

Summary

Index

27
Introduction
This book covers Cisco next-generation network security products and
solutions. It provides detailed guidance for designing, configuring, and
troubleshooting the Cisco ASA with FirePOWER Services, Cisco next-
generation IPS appliances, Cisco Web Security Appliance (WSA), and
Cisco Email Security Appliance (ESA) with the new Advanced Malware
Protection (AMP) integration, as well as the Cisco AMP Threat Grid
malware analysis and threat intelligence and Cisco Firepower Management
Center (FMC).

Who Should Read This Book?

This book is a comprehensive guide for any network and/or security

professional who has deployed or is planning to deploy Cisco next-
generation security products, including the Cisco ASA with FirePOWER
Services, Cisco AMP for Networks and Endpoints, and Cisco next-
generation IPS appliances (including Firepower). Any security professional
who manages or configures Cisco Web Security Appliance (WSA) and
Cisco Email Security Appliance (ESA) with the Advanced Malware
Protection (AMP) solution will also benefit from this book.

How This Book Is Organized

This book is organized into 12 chapters. It starts with an overview of the
Cisco next- generation network security products and then dives into design,
configuration, and troubleshooting of the Cisco ASA FirePOWER Services
module, Cisco AMP for Networks, Cisco AMP for Endpoints, Cisco AMP
for Content Security, and Cisco next-generation IPS. This book also
provides an overview of the Cisco AMP Threat Grid mal-ware analysis and
threat intelligence. The following are the chapters in this book:

Chapter 1, “Fundamentals of Cisco Next-Generation Security”: This

chapter starts with an introduction to the new security threat landscape and
attack continuum. It then provides an overview of Cisco next-generation
network security products, including the Cisco ASA next-generation
firewalls and the FirePOWER module; next-generation intrusion prevention
systems (NGIPS); an introduction to Advanced Malware Protection (AMP)

28
for Endpoints and AMP for Networks; an overview of AMP Threat Grid;
Cisco Email Security; Cisco Web Security; Cisco Identity Services Engine
(ISE); Cisco Meraki Cloud Managed MDM and Security Appliances; and
the Cisco VPN solutions.

Chapter 2, “Introduction to and Design of Cisco ASA with

FirePOWER Services”: This chapter covers design topics of the Cisco
ASA with FirePOWER Services. It explains the inline versus promiscuous
mode deployment and the Cisco ASA Firepower management options. This
chapter also provides information about the Cisco ASA FirePOWER
Services licensing structure and information about compatibility with other
Cisco ASA features. It also covers the Cisco ASA Firepower packet
processing order of operations, high-availability design topics, and how to
deploy the Cisco ASA FirePOWER Services in the Internet edge, in the data
center, and in different VPN scenarios.

Chapter 3, “Configuring Cisco ASA with FirePOWER Services”: This

chapter starts with instructions on how to perform the initial setup of the
Cisco ASA FirePOWER module in Cisco ASA appliances. Then it provides
step-by-step configuration guidance on how to redirect traffic to the Cisco
ASA FirePOWER module, how to configure the Cisco ASA FirePOWER
module using the Adaptive Security Device Manager (ASDM), and how to
configure the Cisco ASA FirePOWER module for FireSIGHT Management.

Chapter 4, “Troubleshooting Cisco ASA with FirePOWER Services

and Firepower Threat Defense (FTD)”: This chapter provides tips on
troubleshooting problems in the Cisco ASA and the FirePOWER Services
module.

Chapter 5, “Introduction to and Architecture of Cisco AMP”: This

chapter introduces the Advanced Malware Protection solution, its
architectural makeup, and types of clouds. It also provides a step-by-step
walk-through for installing an AMP private cloud.

Chapter 6, “Cisco AMP for Networks”: This chapter describes how

AMP for Networks fits into the AMP architecture, along with the functions
of AMP for Networks. It describes and walks through the configuration of
malware and file policies for AMP for Networks.

Chapter 7, “Cisco AMP for Content Security”: This chapter describes

29
how AMP for Content Security fits within the AMP architecture, describing
the components and configuration of File Reputation and File Analysis
Services, along with the reporting for those services.

Chapter 8, “Cisco AMP for Endpoints”: This chapter dives into Cisco
AMP for Endpoints, custom detections, application control, AMP for
Endpoints installation, and policy management for applicable operating
systems (Windows, Mac, Linux, and Android). The chapter also reviews the
usage of the AMP cloud console.

Chapter 9, “AMP Threat Grid: Malware Analysis and Threat

Intelligence”: AMP Threat Grid is a malware dynamic analysis engine
integrated with Cisco AMP. This chapter presents the AMP Threat Grid
deployment options, which include a cloud and an on-premises appliance
solution. It summarizes the differences between the two and describes when
an organization would choose one over the other. It also provides example
snapshots of Threat Grid configuration options in the FMC.

Chapter 10, “Introduction and Deployment of Cisco Next-Generation

IPS”: This chapter presents next-generation IPS (NGIPS) and compares
NGIPS to legacy IPS systems. It also describes some basic NGIPS
deployment design options and locations based on an organization’s security
requirements. This chapter then goes over common deployment
considerations when designing an IPS deployment. Finally, it closes by
going over the NGIPS deployment lifecycle that organizations should follow
in order to maximize the benefits of an NGIPS deployment.

Chapter 11, “Configuring Cisco Next-Generation IPS”: This chapter

introduces the configuration options available in FMC. It presents policy
configuration options, IPS rules, Snort, and NGIPS preprocessors and
recommendations. It uses various snapshot images to portray the wealth of
available configuration options and the intuitive feel of the FMC graphical
interface. Finally, it describes performance settings and redundancy
configurations. This chapter does not present the ASDM IPS configuration
options, which are presented in Chapter 3.

Chapter 12, “Reporting and Troubleshooting with Cisco Next-

Generation IPS”: The last chapter of this book summarizes the Cisco
NGIPS reporting and troubleshooting capabilities. It describes the analysis
capabilities offered in FMC, which include intrusion events, custom

30
reporting, incidents, alerting, and correlation policies. It then provides
troubleshooting and health monitoring options that help administrators
identify and find the root cause of potential issues in the system.

Command Syntax Conventions

The conventions used to present command syntax in this book are the same
conventions used in the IOS Command Reference:

Boldface indicates commands and keywords that are entered literally as

shown. In actual configuration examples and output (not general command
syntax), boldface indicates commands that are manually input by the user
(such as a show command).

Italics indicate arguments for which you supply actual values.

Vertical bars ( | ) separate alternative, mutually exclusive elements.

Square brackets [ ] indicate optional elements.

Braces { } indicate a required choice.

Braces within brackets [{ }] indicate a required choice within an optional

element.

31
Chapter 1. Fundamentals of Cisco Next-
Generation Security
The threat landscape today is very different from that of just a few years
ago. Many bad actors are causing major disruptions to enterprises, service
providers, and governments with a combination of simple attacks and very
sophisticated, well-organized, and well-funded attack campaigns. A large
number of these advanced attacks are difficult to detect and remain in
networks for long periods of time.

Traditional security products have concentrated on providing high-level

visibility into what’s happening in the network and denying traffic at the
point of entry. However, bad actors do not carry out advanced attacks at a
single point in time. Their attack schemes and campaigns use sophisticated
methodologies like encrypted traffic, zero-day attacks, command and control
(C&C) detection evasion, lateral movement, and evasion techniques to
avoid detection.

Cisco creates some of the industry’s most comprehensive advanced threat

protection security products and services. These products and solutions are
designed to provide visibility, policy enforcement, and advanced threat
protection across a network and the entire attack continuum. This chapter
covers the following topics and Cisco next-generation security products and
solutions:

The new threat landscape and attack continuum

Cisco ASA 5500-X Series next-generation firewalls and the Cisco ASA
with FirePOWER Services

Cisco Firepower Threat Defense (FTD)

Next-generation intrusion prevention systems (NGIPS)

Firepower Management Center (FMC)

Advanced Malware Protection (AMP) for Endpoints

AMP for Networks

32
 AMP Threat Grid

Cisco Email Security Appliance (ESA)

Cloud Email Security

Cisco Web Security Appliance (WSA)

Cisco Cloud Web Security (CWS)

Cisco Identity Services Engine (ISE)

Cisco Meraki cloud-managed MDM

Cisco Meraki cloud-managed security appliances

Cisco VPN solutions

Note

This book focuses on the latest next-generation platforms.

The New Threat Landscape and Attack Continuum

Defending against cybersecurity attacks is becoming more challenging every

day, and it is not going to get any easier. The threat landscape is evolving to
a faster, more effective, and more efficient criminal economy profiting from
attacks against users, enterprises, services providers, and governments. The
organized cybercrime and exchange of exploits is booming and fueling a
very lucrative economy. Bad actors today have a clear understanding of the
underlying security technologies and their vulnerabilities. Hacker groups
now follow software development lifecycles, just as enterprises do. These
bad actors perform quality assurance testing against security products
before releasing them into the underground economy. They continue to find
ways to evade common security defenses. Attackers follow new techniques
such as the following:

Port and protocol hopping

Encryption

33
 Droppers

Social engineering

Zero-day attacks

Figure 1-1 illustrates how today’s security defenses must be architected.

Figure 1-1 Today’s Security Defenses

Next-generation security defenses must have the following characteristics:

Visibility driven: Defenses must maintain complete visibility and gather

data from all potential attack vectors across the network fabric, endpoints
(including mobile devices), email and web gateways, virtual machines in
the data center, and the cloud.

Threat focused: It is necessary to correlate all collected information with

indicators of compromise (IOC) and other contextual information in order
for network security administrators to make better decisions and take action.
Keeping up with a constantly evolving threat landscape is almost
impossible. Access controls reduce the attack surface, but attackers still get
through. Security technologies and solutions must focus on understanding,
detecting, and blocking attacks. These solutions require continuous analysis
and security intelligence delivered from the cloud and shared across all
products for better effectiveness.

Platform based: Security now requires an integrated system of agile and

34
open platforms that cover the network, endpoints, users, and the cloud.
These platforms must be scalable and centrally managed for device
configuration consistency.

The Attack Continuum

You as a security professional need to face the fact that you will get
attacked, and eventually some of the devices in your network will be
compromised. Security technologies and processes not only should focus on
detection but also should provide the capability to mitigate the impact of a
successful attack. Figure 1-2 illustrates the attack continuum.

Figure 1-2 The Attack Continuum

Security professionals must maintain visibility and control across the

extended network during the full attack continuum:

Before an attack takes place

During an active attack

After an attacker starts to damage systems or steal information

Cisco next-generation security products provide protection throughout the

attack continuum. Devices such as the Cisco ASA with FirePOWER
Services, available on the Cisco ASA 5500-X Series and ASA 5585-X
Adaptive Security Appliances; Firepower Threat Defense (FTD); and Cisco
Advanced Malware Protection (AMP) provide a security solution that help
discover threats and enforce and harden policies before an attack takes
place. In addition, you can detect, block, and defend against attacks that

35
have already taken place with next-generation intrusion prevention systems
(NGIPS), Email Security, and Web Security Appliance with AMP. These
solutions provide the capabilities to contain and remediate an attack to
minimize data loss and additional network degradation.

Tip

What is the difference between FirePOWER and Firepower? Cisco uses the
term FirePOWER (uppercase POWER) when referring to the Cisco ASA
FirePOWER Services module and uses Firepower (lowercase power) when
referring to the FTD unified image and newer software.

Cisco ASA 5500-X Series Next-Generation Firewalls and the

Cisco ASA with FirePOWER Services

The members of the Cisco ASA family come in many shapes and sizes, but
they all provide a similar set of features. Typically, smaller model numbers
represent smaller capacity for throughput. The main standalone appliance
model number begins with a 55, but there are also devices in the Cisco ASA
family that go into a switch, such as a 6500. Table 1-1 describes the various
models of the ASA family.

36
Table 1-1 Cisco ASA Models

The Cisco ASA family provides a very comprehensive set of features and
next-generation security capabilities. For example, it provides capabilities
such as simple packet filtering (normally configured with access control
lists [ACLs]) and stateful inspection. The Cisco ASA family also provides
support for application inspection/awareness. A Cisco ASA device can
listen in on conversations between devices on one side and devices on the
other side of the firewall. The benefit of listening in is that the firewall can
pay attention to application layer information.

The Cisco ASA family also supports Network Address Translation (NAT),
the capability to act as a Dynamic Host Configuration Protocol (DHCP)
server or client or both. The Cisco ASA family supports most of the interior
gateway routing protocols, including Routing Information Protocol (RIP),
Enhanced Interior Gateway Routing Protocol (EIGRP), and Open Shortest
Path First (OSPF). It also supports static routing. A Cisco ASA device also
can be implemented as a traditional Layer 3 firewall, which has IP
addresses assigned to each of its routable interfaces. The other option is to

37
implement a firewall as a transparent (Layer 2) firewall, in which case the
actual physical interfaces are not configured with individual IP addresses,
but a pair of interfaces operate like a bridge. Traffic that is going across this
two-port bridge is still subject to the rules and inspection that can be
implemented by the ASA. In addition, a Cisco ASA device is often used as
a head-end or remote-end device for VPN tunnels for both remote-access
VPN users and site-to-site VPN tunnels. The Cisco ASA family supports
IPsec and SSL-based remote-access VPNs. The SSL VPN capabilities
include support for clientless SSL VPN and full AnyConnect SSL VPN
tunnels.

The Cisco ASA family also provides a basic botnet traffic filtering feature.
A botnet is a collection of computers that have been compromised and are
willing to follow the instructions of someone who is attempting to centrally
control them (for example, 200,000 machines all willing [or so
commanded] to send a flood of ping requests to the IP address dictated by
the person controlling these devices). Often, users of these computers have
no idea that their computers are participating in a coordinated attack. An
ASA device works with an external system at Cisco that provides
information about the Botnet Traffic Filter Database and so can protect
against such attacks.

Cisco introduced the Cisco ASA FirePOWER module as part of the

integration of the Sourcefire technology.

Note

Cisco acquired the company Sourcefire to expand its security portfolio. The
Cisco ASA FirePOWER module provides NGIPS, Application Visibility
and Control (AVC), URL filtering, and AMP. This module runs as a separate
application from the classic Cisco ASA software. The Cisco ASA
FirePOWER module can be a hardware module on the ASA 5585-X only or
a software module that runs in an SSD in all other models.

The Cisco ASA FirePOWER module can be managed by the Firepower

Management Center (FMC), formerly known as the FireSIGHT Management
Center. The Firepower Management Center and the Cisco ASA FirePOWER
module require additional licenses. In all Cisco ASA models except the
5506-X, 5508-X, and 5516-X, the licenses are installed in the FirePOWER

38
module. There are no additional licenses required in a Cisco ASA device.
FirePOWER Services running on the Cisco ASA 5506-X, 5508-X, and
5516-X can be managed using Adaptive Security Device Manager (ASDM),
and the licenses can be installed using ASDM. In all Cisco ASAs with
FirePOWER Services managed by a Firepower Management Center, the
license is installed on the Firepower Management Center and used by the
module.

Chapter 2, “Introduction to and Design of Cisco ASA with FirePOWER

Services,” provides a more technical introduction to the Cisco ASA with
FirePOWER Services, as well as design guidelines and best practices.
Chapter 3, “Configuring Cisco ASA with FirePOWER Services,” provides
step-by-step instructions on how to configure the Cisco ASA with
FirePOWER Services, and Chapter 4, “Troubleshooting Cisco ASA with
FirePOWER Services and Firepower Threat Defense (FTD),” provides
detailed instructions and tips on how to troubleshoot Cisco ASA with
FirePOWER Services deployments.

Note

Cisco ASA 5500-X Series Next-Generation Firewalls LiveLessons

(Workshop): Deploying and Troubleshooting Techniques (ISBN 978-1-
58720-570-5) provides step-by-step instructions on how to deploy,
configure, and troubleshoot the firewall features of the Cisco ASA 5500-X
Series Next-Generation Firewalls, including an introduction to Cisco ASA
with FirePOWER Services.

The Cisco Press book Cisco ASA: All-in-One Next-Generation Firewall,

IPS, and VPN Services, third edition (ISBN 978-1-58714-307-6), provides
an all-in-one guide to the Cisco ASA. Both of these publications provide
guidance on how to install, configure, license, maintain, and troubleshoot
the newest ASA devices. You learn how to implement authentication,
authorization, and accounting (AAA) services, control and provision
network access with packet filtering, use context-aware Cisco ASA next-
generation firewall services, and take advantage of new NAT/PAT concepts.
These publications also provide guidance on how to configure IP routing,
application inspection, and QoS and how to implement high availability
with failover and elastic scalability with clustering. Cisco ASA: All-in-One

39
Next-Generation Firewall, IPS, and VPN Services, third edition, covers the
configuration and troubleshooting of site-to-site IPsec VPNs and all forms
of remote-access VPNs (IPsec, clientless SSL, and client-based SSL).

Cisco Firepower Threat Defense (FTD)

The Cisco FTD is unified software that includes Cisco ASA features, legacy
FirePOWER Services, and new features. FTD can be deployed on Cisco
Firepower 4100 and 9300 appliances to provide next-generation firewall
(NGFW) services. In addition to being able to run on the Cisco Firepower
4100 Series and the Firepower 9300 appliances, FTD can also run natively
on the ASA 5506-X, ASA 5506H-X, ASA 5506W-X, ASA 5508-X, ASA
5512-X, ASA 5515-X, ASA 5516-X, ASA 5525-X, ASA 5545-X, and ASA
5555-X. It is not supported in the ASA 5505 or the 5585-X.

Cisco Firepower 4100 Series

The Cisco Firepower 4100 Series appliances are next-generation firewalls

that run the Cisco FTD software and features. There are four models:

Cisco Firepower 4110, which supports up to 20 Gbps of firewall

throughput

Cisco Firepower 4120, which supports up to 40 Gbps of firewall

throughput

Cisco Firepower 4140, which supports up to 60 Gbps of firewall

throughput

Cisco Firepower 4150, which supports over 60 Gbps of firewall

throughput

All of the Cisco Firepower 4100 Series models are one rack-unit (1 RU)
appliances and are managed by the Cisco Firepower Management Center.

Cisco Firepower 9300 Series

The Cisco Firepower 9300 appliances are designed for very large
enterprises or service providers. They can scale beyond 1 Tbps and are
designed in a modular way, supporting Cisco ASA software, Cisco FTD

40
software, and Radware DefensePro DDoS mitigation software.

Note

The Radware DefensePro DDoS mitigation software is available and

supported directly from Cisco on Cisco Firepower 4150 and Cisco
Firepower 9300 appliances.

Radware’s DefensePro DDoS mitigation software provides real-time

analysis to protect the enterprise or service provider infrastructure against
network and application downtime due to distributed denial of service
(DDoS) attacks.

Cisco FTD for Cisco Integrated Services Routers (ISRs)

The Cisco FTD can run on Cisco Unified Computing System (UCS) E-
Series blades installed on Cisco ISR routers. Both the FMC and FTD are
deployed as virtual machines. There are two internal interfaces that connect
a router to an UCS E-Series blade. On ISR G2, Slot0 is a Peripheral
Component Interconnet Express (PCIe) internal interface, and UCS E-Series
Slot1 is a switched interface connected to the backplane Multi Gigabit
Fabric (MGF). In Cisco ISR 4000 Series routers, both internal interfaces
are connected to the MGF.

A hypervisor is installed on the UCS E-Series blade, and the Cisco FTD
software runs as a virtual machine on it. FTD for ISRs is supported on the
following platforms:

Cisco ISR G2 Series: 2911, 2921, 2951, 3925, 3945, 3925E, and 3945E

Cisco ISR 4000 Series: 4331, 4351, 4451, 4321, and 4431

Next-Generation Intrusion Prevention Systems (NGIPS)

As a result of the Sourcefire acquisition, Cisco expanded its NGIPS
portfolio with the following products:

Cisco FirePOWER 8000 Series appliances: These high-performance

41
appliances running Cisco FirePOWER Next-Generation IPS Services
support throughput speeds from 2 Gbps up through 60 Gbps.

Cisco FirePOWER 7000 Series appliances: These are the base platform
for the Cisco FirePOWER NGIPS software. Base platforms support
throughput speeds from 50 Mbps up through 1.25 Gbps.

Virtual next-generation IPS (NGIPSv) appliances for VMware: These

appliances can be deployed in virtualized environments. By deploying these
virtual appliances, security administrators can maintain network visibility
that is often lost in virtual environments.

Chapter 10, “Introduction to and Deployment of Cisco Next-Generation

IPS,” provides a more technical introduction of the Cisco NGIPS
appliances. Chapter 11, “Configuring Cisco Next-Generation IPS,” provides
step-by-step instructions on how to configure Cisco NGIPS appliances, and
Chapter 12, “Reporting and Troubleshooting with Cisco Next-Generation
IPS,” provides detailed instructions and tips on how to troubleshoot Cisco
NGIPS deployments.

Firepower Management Center

Cisco Firepower Management Center (FMC) provides a centralized

management and analysis platform for the Cisco NGIPS appliances and the
Cisco ASA with FirePOWER Services. It provides support for role-based
policy management and includes a fully customizable dashboard with
advanced reports and analytics. The following are the models of the Cisco
FMC appliances:

FS750: Supports a maximum of 10 managed devices (NGIPS or Cisco

ASA appliances) and a total of 20 million IPS events.

FS2000: Supports a maximum of 70 managed devices and up to 60 million

IPS events.

FS4000: Supports a maximum of 300 managed devices and a total of 300

million IPS events.

FMC Virtual Appliance: Allows you to conveniently provision on your

existing virtual infrastructure. It supports a maximum of 25 managed devices

42
and up to 10 million IPS events.

AMP for Endpoints

There are numerous antivirus and antimalware solutions on the market,

designed to detect, analyze, and protect against both known and emerging
endpoint threats. Before diving into these technologies, you should
understand viruses and malicious software (malware). The following are
the most common types of malicious software:

Computer virus: Malicious software that infects a host file or system area
to perform undesirable outcomes such as erasing data, stealing information,
or corrupting the integrity of the system. In numerous cases, these viruses
multiply again to form new generations of themselves.

Worm: A virus that replicates itself over the network, infecting numerous
vulnerable systems. In most cases, a worm executes malicious instructions
on a remote system without user interaction.

Mailer or mass-mailer worm: A type of worm that sends itself in an

email message. Examples of mass-mailer worms are Loveletter.A@mm and
W32/SKA.A@m (a.k.a. the Happy99 worm), which sends a copy of itself
every time the user sends a new message.

Logic bomb: A type of malicious code that is injected into a legitimate

application. An attacker can program a logic bomb to delete itself from the
disk after it performs the malicious tasks on the system. Examples of these
malicious tasks include deleting or corrupting files or databases and
executing a specific instruction after certain system conditions are met.

Trojan horse: A type of malware that executes instructions to delete files,

steal data, or otherwise compromise the integrity of the underlying operating
system. Trojan horses typically use a form of social engineering to fool
victims into installing such software in their computers or mobile devices.
Trojans can also act as back doors.

Back door: A piece of malware or a configuration change that allows

attackers to control the victim’s system remotely. For example, a back door
can open a network port on the affected system so that the attacker can
connect and control the system.

43
 Exploit: A malicious program designed to exploit, or take advantage of, a
single vulnerability or set of vulnerabilities.

Downloader: A piece of malware that downloads and installs other

malicious content from the Internet to perform additional exploitation on an
affected system.

Spammer: Malware that sends spam, or unsolicited messages sent via

email, instant messaging, newsgroups, or any other kind of computer or
mobile device communications. Spammers send these unsolicited messages
with the primary goal of fooling users to click malicious links, reply to
emails or other messages with sensitive information, or perform different
types of scams. The attacker’s main objective is to make money.

Key logger: A piece of malware that captures the user’s keystrokes on a

compromised computer or mobile device. It collects sensitive information,
such as passwords, personal ID numbers (PINs), personal identifiable
information (PII), credit card numbers, and more.

Rootkit: A set of tools used by an attacker to elevate his or her privilege

to obtain root-level access to be able to completely take control of the
affected system.

Ransomware: A type of malware that compromises a system and then

demands a ransom from the victim to pay the attacker in order for the
malicious activity to cease or for the malware to be removed from the
affected system. Two examples of ransomware are Crypto Locker and
CryptoWall, and they encrypt the victim’s data and demand that the user pay
a ransom in order for the data to be decrypted and accessible to the victim.

There are numerous types of commercial and free antivirus software. The
following are a few examples of commercial and free options:

Avast

AVG Internet Security

Bitdefender Antivirus Free

ZoneAlarm PRO ANTIVIRUS+, ZoneAlarm PRO FIREWALL, and

ZoneAlarm EXTREME SECURITY

44
 F-Secure Anti-virus

Kaspersky Anti-virus

McAfee AntiVirus

Panda Antivirus

Sophos Antivirus

Norton AntiVirus

ClamAV

Immunet AntiVirus

Note

ClamAV is an open source antivirus engine sponsored and maintained by

Cisco and non-Cisco engineers. You can download ClamAV from
www.clamav.net. Immunet is a free community-based antivirus software
maintained by Cisco Sourcefire. You can download Immunet from
www.immunet.com.

There are numerous other antivirus software companies and products. The
following link provides a comprehensive list and comparison of the
different antivirus software available on the market:
http://en.wikipedia.org/wiki/Comparison_of_antivirus_software.

Personal firewalls and host intrusion prevention systems (HIPS) are

software applications that you can install on end-user machines or servers
to protect them from external security threats and intrusions. The term
personal firewall typically applies to basic software that can control Layer
3 and Layer 4 access to client machines. HIPS provides several features that
offer more robust security than a traditional personal firewall, such as host
intrusion prevention and protection against spyware, viruses, worms,
Trojans, and other types of malware.

Today, more sophisticated software makes basic personal firewalls and

45
HIPS obsolete. For example, Cisco Advanced Malware Protection (AMP)
for Endpoints provides granular visibility and control to stop advanced
threats missed by other security layers. Cisco AMP for Endpoints takes
advantage of telemetry from big data, continuous analysis, and advanced
analytics provided by Cisco threat intelligence to be able to detect, analyze,
and stop advanced malware across endpoints.

Cisco AMP for Endpoints provides advanced malware protection for many
operating systems, including Windows, Mac OS X, Android, and Linux.

Attacks are getting very sophisticated and can evade detection of traditional
systems and endpoint protection. Today, attackers have the resources,
knowledge, and persistence to beat point-in-time detection. Cisco AMP for
Endpoints provides mitigation capabilities that go beyond point-in-time
detection. It uses threat intelligence from Cisco to perform retrospective
analysis and protection. Cisco AMP for Endpoints also provides device and
file trajectory capabilities to allow a security administrator to analyze the
full spectrum of an attack. Device trajectory and file trajectory support the
following file types in Windows and Mac OS X operating systems:

MSEXE

PDF

MSCAB

MSOLE2

ZIP

ELF

MACHO

MACHO_UNIBIN

SWF

JAVA

Note

46
The Mac OS X connector does not support SWF files. The Windows
connector does not scan ELF, JAVA, MACHO, or MACHO_UNIBIN files at
the time of this writing. The Android AMP connector scans APK files.

AMP for Networks

Cisco AMP for Networks provides next-generation security services that go

beyond point-in-time detection. It provides continuous analysis and tracking
of files and also retrospective security alerts so that a security administrator
can take action during and after an attack. The file trajectory feature of
Cisco AMP for Networks tracks file transmissions across the network, and
the file capture feature enables a security administrator to store and retrieve
files for further analysis. Chapter 6, “Cisco AMP for Networks,” provides
Cisco AMP for Networks configuration and troubleshooting guidance, with
step-by-step examples.

AMP Threat Grid

Cisco acquired a security company called ThreatGRID that provides cloud-

based and on-premises malware analysis solutions. Cisco integrated Cisco
AMP and Threat Grid to provide a solution for advanced malware analysis
with deep threat analytics. The Cisco AMP Threat Grid integrated solution
analyzes millions of files and correlates them with hundreds of millions of
malware samples. This provides a look into attack campaigns and how
malware is distributed. This solution provides a security administrator with
detailed reports of indicators of compromise and threat scores that help
prioritize mitigations and recover from attacks.

Chapter 9, “AMP Threat Grid: Malware Analysis and Threat Intelligence,”

provides the technical details of the AMP Threat Grid solution.

Email Security Overview

Users are no longer accessing email only from the corporate network or
from a single device. Cisco provides cloud-based, hybrid, and on-premises
ESA-based solutions that can help protect any dynamic environment. This
section introduces these solutions and technologies and explains how users
can use threat intelligence to detect, analyze, and protect against both known

47
and emerging threats.

There are several types of email-based threats. The following are the most
common:

Spam: Unsolicited email messages that can be advertising a service or

(typically) a scam or a message with malicious intent. Email spam continues
to be a major threat because it can be used to spread malware.

Malware attachments: Email messages containing malicious software

(malware).

Phishing: An attacker’s attempt to fool a user that the email

communication comes from a legitimate entity or site, such as banks, social
media websites, online payment processors, or even corporate IT
communications. The goal of a phishing email is to steal a user’s sensitive
information, such as user credentials, bank account information, and so on.

Spear phishing: Phishing attempts that are more targeted. Spear phishing
emails are directed to specific individual or organizations. For instance, an
attacker may perform a passive reconnaissance on an individual or
organization by gathering information from social media sites (for example,
Twitter, LinkedIn, Facebook) and other online resources. Then the attacker
may tailor a more directed and relevant message to the victim to increase
the probability that the user will be fooled to follow a malicious link, click
an attachment containing malware, or simply reply to the email and provide
sensitive information. Another phishing-based attack, called whaling,
specifically targets executives and high-profile users.

Email Security Appliance

The following are the different Email Security Appliance (ESA) models:

Cisco X-Series ESA models:

Cisco X1070: A high-performance ESA model for service providers and

large enterprises

Cisco C-Series ESA models:

48
 Cisco C680: A high-performance ESA model for service providers and
large enterprise

Cisco C670: An ESA model designed for medium-size enterprises

Cisco C380: An ESA model designed for medium-size enterprises

Cisco C370: An ESA model designed for small to medium-size

enterprises

Cisco C170: An ESA model designed for small businesses and branch
offices

The Cisco ESA runs the Cisco AsyncOS operating system. Cisco AsyncOS
supports numerous features that help mitigate email-based threats.

The following are examples of the features supported by the Cisco ESA:

Access control: Controlling access for inbound senders, according to a

sender’s IP address, IP address range, or domain name.

Anti-spam: Multilayer filters based on Cisco SenderBase reputation and

Cisco antispam integration. The antispam reputation and zero-day threat
intelligence are fueled by the Cisco security intelligence and research group
named Talos.

Network antivirus: Network antivirus capabilities at the gateway. Cisco

partnered with Sophos and McAfee, supporting their antivirus scanning
engines.

Advanced Malware Protection (AMP): Allows security administrators

to detect and block malware and perform continuous analysis and
retrospective alerting.

Data loss prevention (DLP): The ability to detect any sensitive emails
and documents leaving the corporation. The Cisco ESA integrates RSA
email DLP for outbound traffic.

Email encryption: The ability to encrypt outgoing mail to address

regulatory requirements. The administrator can configure an encryption
policy on the Cisco ESA and use a local key server or hosted key service to

49
encrypt the message.

Email authentication: A few email authentication mechanisms, including

Sender Policy Framework (SPF), Sender ID Framework (SIDF), and
DomainKeys Identified Mail (DKIM) verification of incoming mail, as well
as DomainKeys and DKIM signing of outgoing mail.

Outbreak filters: Preventive protection against new security outbreaks

and email-based scams using Cisco’s Security Intelligence Operations
(SIO) threat intelligence information.

Note

Cisco SenderBase (see www.senderbase.org) is the world’s largest email

and web traffic monitoring network. It provides real-time threat intelligence
powered by Cisco SIO.

The Cisco ESA acts as the email gateway for an organization, handling all
email connections, accepting messages, and relaying messages to the
appropriate systems. The Cisco ESA can service email connections from the
Internet to users inside a network and from systems inside the network to the
Internet. Email connections use Simple Mail Transfer Protocol (SMTP).
The ESA services all SMTP connections, by default acting as the SMTP
gateway.

Tip

Mail gateways are also known as a mail exchangers (MX).

The Cisco ESA uses listeners to handle incoming SMTP connection

requests. A listener defines an email processing service that is configured
on an interface in the Cisco ESA. Listeners apply to email entering the
appliance from either the Internet or internal systems.

The following listeners can be configured:

Public listeners for email coming in from the Internet

50
 Private listeners for email coming from hosts in the corporate (inside)
network (These emails are typically from internal groupware, Exchange,
POP, or IMAP email servers.)

Cisco ESA listeners are often referred to as SMTP daemons, and they run
on specific Cisco ESA interfaces. When a listener is configured, the
following information must be provided:

Listener properties such as a specific interface in the Cisco ESA and the
TCP port that will be used. The listener properties must also indicate
whether it is a public or a private listener.

The hosts that are allowed to connect to the listener, using a combination
of access control rules. An administrator can specify which remote hosts
can connect to the listener.

The local domains for which public listeners accept messages.

Cloud Email Security

Cisco Cloud Email Security provides a cloud-based solution that allows

companies to outsource the management of their email security management.
The service provides email security instances in multiple Cisco data centers
to enable high availability.

Cisco Hybrid Email Security

The Cisco Hybrid Email Security solution combines both cloud-based and
on-premises ESAs. This hybrid solution helps Cisco customers reduce their
onsite email security footprint and outsource a portion of their email
security to Cisco, while still allowing them to maintain control of
confidential information within their physical boundaries. Many
organizations must comply with regulations that require them to keep
sensitive data physically on their premises. The Cisco Hybrid Email
Security solution allows network security administrators to remain
compliant and to maintain advanced control with encryption, DLP, and
onsite identity-based integration.

Web Security Overview

51
For an organization to be able to protect its environment against web-based
security threats, security administrators need to deploy tools and mitigation
technologies that go far beyond traditional blocking of known bad websites.
Today, you can download malware through compromised legitimate
websites, including social media sites, advertisements in news and
corporate sites, and gaming sites. Cisco has developed several tools and
mechanisms to help customers combat these threats, including and Cisco
Web Security Appliance (WSA), Cisco Security Management Appliance
(SMA), and Cisco Cloud Web Security (CWS). These solutions enable
malware detection and blocking, continuous monitoring, and retrospective
alerting.

Web Security Appliance

A Cisco WSA uses cloud-based intelligence from Cisco to help protect an

organization before, during, and after an attack. This “lifecycle” is referred
to as the attack continuum. The cloud-based intelligence includes web
(URL) reputation and zero-day threat intelligence from the Talos Cisco
security intelligence and research group. This threat intelligence helps
security professionals stop threats before they enter the corporate network
and also enables file reputation and file sandboxing to identify threats
during an attack. Retrospective attack analysis allows security
administrators to investigate and provide protection after an attack, when
advanced malware might have evaded other layers of defense.

A Cisco WSA can be deployed in explicit proxy mode or as a transparent

proxy, using the Web Cache Communication Protocol (WCCP). WCCP was
originally developed by Cisco, but several other vendors have integrated
this protocol in their products to allow clustering and transparent proxy
deployments on networks using Cisco infrastructure devices (routers,
switches, firewalls, and so on).

Figure 1-3 illustrates a Cisco WSA deployed as an explicit proxy.

52
Figure 1-3 WSA Explicit Proxy Configuration

The following are the steps illustrated in Figure 1-3:

Step 1. An internal user makes an HTTP request to an external website. The

client browser is configured to send the request to the Cisco WSA.

Step 2. The Cisco WSA connects to the website on behalf of the internal
user.

Step 3. The firewall (Cisco ASA) is configured to only allow outbound

web traffic from the Cisco WSA, and it forwards the traffic to the web
server.

Figure 1-4 shows a Cisco WSA deployed as a transparent proxy.

Figure 1-4 Transparent Proxy Configuration

The following are the steps illustrated in Figure 1-4:

Step 1. An internal user makes an HTTP request to an external website.

53
Step 2. The internal router (R1) redirects the web request to the Cisco
WSA, using WCCP.

Step 3. The Cisco WSA connects to the website on behalf of the internal
user.

Step 4. The firewall (Cisco ASA) is configured to only allow outbound

web traffic from the WSA. The web traffic is sent to the Internet web server.

Figure 1-5 demonstrates how the WCCP registration works. The Cisco
WSA is the WCCP client, and the Cisco router is the WCCP server.

Figure 1-5 WCCP Registration

During the WCCP registration process, the WCCP client sends a registration
announcement (“Here I am”) every 10 seconds. The WCCP server (the
Cisco router, in this example) accepts the registration request and
acknowledges it with an “I see you” WCCP message. The WCCP server
waits 30 seconds before it declares the client as “inactive” (engine failed).
WCCP can be used in large-scale environments. Figure 1-6 shows a cluster
of Cisco WSAs, where internal Layer 3 switches redirect web traffic to the
cluster.

54
Figure 1-6 Cisco WSA Cluster Example

The following are the different Cisco WSA models:

Cisco WSA S680: A high-performance WSA designed for large

organizations with 6000 to 12,000 users. A two rack-unit (2 RU) appliance
with 16 (2 octa core) CPUs, 32 GB of memory, and 4.8 TB of disk space.

Cisco WSA S670: A high-performance WSA designed for large

organizations with 6000 to 12,000 users. A 2 RU appliance with 8 (2 octa
core) CPUs, 8 GB of memory, and 2.7 TB of disk space.

Cisco WSA S380: A WSA designed for medium-size organizations with

1500 to 6000 users. A 2 RU appliance with 6 (1 hexa core) CPUs, 16 GB of
memory, and 2.4 TB of disk space.

55
 Cisco WSA S370: A WSA designed for medium-size organizations with
1500 to 6000 users. A 2 RU appliance with 4 (1 quad core) CPUs, 4 GB or
memory, and 1.8 TB of disk space.

Cisco WSA S170: A WSA designed for small to medium-size

organizations with up to 1500 users. A 1 RU appliance with 2 (1 dual core)
CPUs, 4 GB of memory, and 500 GB of disk space.

The Cisco WSA runs the Cisco AsyncOS operating system. Cisco AsyncOS
supports numerous features that help mitigate web-based threats. The
following are examples of these features:

Real-time antimalware adaptive scanning: The Cisco WSA can be

configured to dynamically select an antimalware scanning engine based on
URL reputation, content type, and scanner effectiveness. Adaptive scanning
is a feature designed to increase the “catch rate” of malware that is
embedded in images, JavaScript, text, and Adobe Flash files. Adaptive
scanning is an additional layer of security on top of Cisco WSA web
reputation filters that include support for Sophos, Webroot, and McAfee.

Layer 4 traffic monitor: The Cisco WSA is used to detect and block
spyware. It dynamically adds IP addresses of known malware domains to
databases of sites to block.

Third-party DLP integration: The Cisco WSA redirects all outbound

traffic to a third-party DLP appliance, allowing deep content inspection for
regulatory compliance and data exfiltration protection. It enables an
administrator to inspect web content by title, metadata, and size and to even
prevent users from storing files to cloud services, such as Dropbox and
Google Drive.

File reputation: Using threat information from Cisco Talos, this file
reputation threat intelligence is updated every 3 to 5 minutes.

File sandboxing: If malware is detected, the Cisco AMP capabilities can

put files in a sandbox to inspect the malware’s behavior and combine the
inspection with machine-learning analysis to determine the threat level.
Cisco Cognitive Threat Analytics (CTA) uses machine-learning algorithms
to adapt over time.

56
 File retrospection: After a malicious attempt or malware is detected, the
Cisco WSA continues to cross-examine files over an extended period of
time.

Application visibility and control: The Cisco ASA can inspect and even
block applications that are not allowed by the corporate security polity. For
example, an administrator can allow users to use social media sites like
Facebook but block micro-applications such as Facebook games.

Cisco Security Management Appliance

Cisco Security Management Appliance (SMA) is a Cisco product that

centralizes the management and reporting for one or more Cisco ESAs and
Cisco WSAs. Cisco SMA enables you to consistently enforce policy and
enhances threat protection. Figure 1-7 shows a Cisco SMA that is
controlling Cisco ESA and Cisco WSAs in different geographic locations
(New York, Raleigh, Paris, and London).

Figure 1-7 Cisco SMA Centralized Deployment

The Cisco SMA comes in different models, including physical appliances

and the Cisco Content Security Management Virtual Appliance (SMAV):

Cisco SMA M680: Designed for large organizations with more than

57
10,000 users

Cisco SMAV M600v: Designed for organizations with more than 5000
users

Cisco SMA M380: Designed for organizations with 1000 to 10,000 users

Cisco SMAV M300v: Designed for organizations with 1000 to 5000 users

Cisco SMA M170: Designed for small business or branch offices with up
to 1000 users

Cisco SMAV M100v: Designed for small business or branch offices with
up to 1000 users

Note

Cisco also has a Cisco SMAV M000v that is used for evaluations only.

Cisco Cloud Web Security (CWS)

Cisco CWS is a cloud-based security service that provides worldwide

threat intelligence, advanced threat defense capabilities, and roaming user
protection. The Cisco CWS service uses web proxies in the Cisco cloud
environment that scan traffic for malware and policy enforcement. Cisco
customers can connect to the Cisco CWS service directly by using a proxy
auto-configuration (PAC) file in the user endpoint or through connectors
integrated into the following Cisco products:

Cisco ISR G2 routers

Cisco ASA

Cisco WSA

Cisco AnyConnect Secure Mobility Client

Organizations using the transparent proxy functionality through a connector

can get the most out of their existing infrastructure. In addition, the scanning

58
is offloaded from the hardware appliances to the cloud, reducing the impact
to hardware utilization and reducing network latency. Figure 1-8 illustrates
how the transparent proxy functionality through a connector works.

Figure 1-8 Cisco ASA with Cisco CWS Connector Example

In Figure 1-8, the Cisco ASA is enabled with the Cisco CWS connector at a
branch office and protects the corporate users at the branch office with these
steps:

Step 1. An internal user makes an HTTP request to an external website

(example.org).

Step 2. The Cisco ASA forwards the request to the Cisco CWS global
cloud infrastructure.

Step 3. Cisco CWS notices that example.org has some web content (ads)
that is redirecting the user to a known malicious site.

59
Step 4. Cisco CWS blocks the request to the malicious site.

Cisco Identity Services Engine (ISE)

The Cisco ISE is a comprehensive security identity management solution

designed to function as a policy decision point for network access. It allows
security administrators to collect real-time contextual information from a
network, its users, and devices. Cisco ISE is the central policy management
platform in the Cisco TrustSec solution. It supports a comprehensive set of
authentication, authorization, and accounting (AAA); posture; and network
profiler features in a single device.

Cisco ISE allows security administrators to provide network guest access

management and wide-ranging client provisioning policies, including
802.1X environments. The support of TrustSec features such as security
group tags (SGTs) and security group access control lists (SGACLs) make
the Cisco ISE a complete identity services solution. Cisco ISE supports
policy sets, which let a security administrator group sets of authentication
and authorization policies.

Cisco ISE provides Network Admission Control (NAC) features, including

posture policies, to enforce configuration of end-user devices with the most
up-to-date security settings or applications before they enter the network.
The Cisco ISE supports the following agent types for posture assessment
and compliance:

Cisco NAC Web Agent: A temporary agent that is installed in end-user

machines at the time of login. The Cisco NAC Web Agent is not visible on
the end-user machine after the user terminates the session.

Cisco NAC Agent: An agent that is installed permanently on a Windows

or Mac OS X client system.

AnyConnect ISE Agent: An agent that is installed permanently on a

Windows or Mac OS X client system.

Cisco ISE provides a comprehensive set of features to allow corporate

users to connect their personal devices—such as mobile phones, tablets,
laptops, and other network devices—to the network. Such a bring-your-own
device (BYOD) system introduces many challenges in terms of protecting

60
network services and enterprise data. Cisco ISE provides support for
multiple mobile device management (MDM) solutions to enforce policy on
endpoints. ISE can be configured to redirect users to MDM onboarding
portals and prompt them to update their devices before they can access the
network. Cisco ISE can also be configured to provide Internet-only access
to users who are not compliant with MDM policies.

Cisco ISE supports the Cisco Platform Exchange Grid (pxGrid), a

multivendor, cross-platform network system that combines different parts of
an IT infrastructure, such as the following:

Security monitoring

Detection systems

Network policy platforms

Asset and configuration management

Identity and access management platforms

Cisco pxGrid has a unified framework with an open application

programming interface (API) designed in a hub-and-spoke architecture.
pxGrid is used to enable the sharing of contextual-based information from a
Cisco ISE session directory to other policy network systems, such as Cisco
IOS devices and the Cisco ASA.

The Cisco ISE can be configured as a certificate authority (CA) to generate

and manage digital certificates for endpoints. Cisco ISE CA supports
standalone and subordinate deployments.

Cisco ISE software can be installed on a range of physical appliances or on

a VMware server (Cisco ISE VM). The Cisco ISE software image does not
support the installation of any other packages or applications on this
dedicated platform.

Cisco Meraki Cloud-Managed MDM

Cisco acquired a company called Meraki that provides cloud-managed

MDM, cloud-managed wireless devices, and security appliances. Cisco
Meraki cloud-based enterprise mobility management allows network

61
administrators to pre-enroll devices or dynamically add users as they try to
connect to the corporate network. An administrator can push apps and
content or restrict network access based on user groups.

The Cisco Meraki web-based (cloud) dashboard allows administrators to

locate, track, monitor, and manage all end-user systems and mobile devices
from anywhere in the world.

Note

For more information about Cisco Meraki MDM solutions, visit

https://meraki.cisco.com/products/systems-manager.

Cisco Meraki Cloud-Managed Security Appliances

Cisco Meraki also has a series of cloud-managed security appliances that

provide the following features:

Identity-based firewall features that enforce network policy and traffic-

shaping rules, VLAN tags, and bandwidth limits for different types of users

Intrusion prevention to detect and protect network resources

VPN features to securely connect remote locations using mesh or hub-and-

spoke topologies

Content filtering, anti-malware, and anti-phishing capabilities

High availability and failover

Note

For more information about Cisco Meraki MDM solutions, go to

https://meraki.cisco.com/products.

Cisco VPN Solutions

62
Numerous enterprises, service providers, and other institutions deploy
virtual private networks (VPNs) to provide data integrity, authentication,
and data encryption to ensure confidentiality of the packets sent over the
Internet or another unprotected network. VPNs are designed to avoid the
cost of unnecessary leased lines. Many different protocols are used for VPN
implementations, including the following:

Point-to-Point Tunneling Protocol (PPTP)

Layer 2 Forwarding (L2F) protocol

Layer 2 Tunneling Protocol (L2TP)

Generic routing encapsulation (GRE)

Multiprotocol Label Switching (MPLS) VPN

Internet Protocol Security (IPsec)

Secure Sockets Layer (SSL)

VPN implementations can be categorized into two distinct groups:

Site-to-site VPNs: Enable organizations to establish VPN tunnels

between two or more network infrastructure devices in different sites so that
they can communicate over a shared medium such as the Internet. Many
organizations use IPsec, GRE, or MPLS VPN as site-to-site VPN protocols.

Remote-access VPNs: Enable users to work from remote locations, such

as their homes, hotels, and other premises as if they were directly connected
to their corporate network. Many organizations use IPsec and SSL VPN for
remote-access VPNs.

Cisco provides a comprehensive VPN portfolio, including support for site-

to-site VPNs in Cisco IOS devices and the Cisco ASA. Remote-access VPN
support includes clientless SSL VPN and full client connections with the
Cisco AnyConnect Secure Mobility Client. This book does not cover any
VPN topics in detail. Cisco ASA: All-in-One Next-Generation Firewall,
IPS, and VPN Services, third edition, covers the configuration and
troubleshooting of site-to-site IPsec VPNs and all forms of remote-access
VPNs (IPsec, clientless SSL, and client-based SSL).

63
Summary
Cisco makes some of the most complete and advanced security products in
the industry. These products and solutions provide visibility, policy
enforcement, and advanced threat protection across the network and the
entire attack continuum. This chapter introduces the new threat landscape
and the attack continuum. It also provides details about the Cisco ASA
5500-X Series next-generation firewalls and the Cisco ASA with
FirePOWER Services, Cisco FTD, the Firepower 4100 and 9300
appliances, Cisco’s NGIPS, Firepower Management Center, Cisco AMP for
Endpoints, Cisco AMP for Networks, and Cisco AMP Threat Grid. It also
provides an introduction to email and web security, describing the Cisco
ESA, Cloud Email Security, Cisco WSA, and Cisco CWS. This chapter also
introduces other Cisco core security products, such as Cisco ISE, Cisco
Meraki cloud-managed MDM, and Cisco Meraki cloud-managed security
appliances and briefly explains the available Cisco VPN solutions. The
chapters that follow focus on the latest next-generation platforms.

64
Chapter 2. Introduction to and Design of Cisco
ASA with FirePOWER Services
This chapter provides an introduction to the Cisco ASA with FirePOWER
Services solution. It also provides design guidance and best practices for
deploying Cisco ASA with FirePOWER Services. This chapter covers the
following topics:

Introduction to Cisco ASA FirePOWER Services

Inline versus promiscuous mode

Cisco ASA FirePOWER management options

Cisco ASA FirePOWER Services sizing

Cisco ASA FirePOWER Services licensing

Compatibility with other Cisco ASA features

Cisco ASA FirePOWER packet processing order of operations

Cisco ASA FirePOWER Services and failover

Cisco ASA FirePOWER Services and clustering

Deployment of the Cisco ASA FirePOWER Services in the Internet edge

Deployment of the Cisco ASA FirePOWER Services in VPN scenarios

Deployment of the Cisco ASA FirePOWER Services in the data center

Introduction to Cisco ASA FirePOWER Services

In Chapter 1, “Fundamentals of Cisco Next-Generation Security,” you

learned about the different Cisco next-generation security products and
technologies. You also learned that those security technologies and
processes should not focus solely on detection but should also provide the
ability to mitigate the impact of an attack. Organizations must maintain

65
visibility and control across the extended network during the full attack
continuum:

Before an attack takes place

During an active attack

After an attacker starts to damage systems or steal information

The Cisco ASA with FirePOWER Services and Cisco’s Advanced

Malware Protection (AMP) provide a security solution that helps you
discover threats and enforce and harden policies before an attack takes
place. These technologies and solutions can help you detect, block, and
defend against attacks that have already taken place. In Chapter 1 you also
learned that the Cisco ASA family has members in many shapes and sizes,
and you learned about their uses in small, medium, and large organizations.

Cisco introduced the Cisco ASA FirePOWER Services as part of the

integration of the SourceFire technology. Cisco ASA FirePOWER Services
provides the following key capabilities:

Access control: This policy-based capability allows a network security

administrator to define, inspect, and log the traffic that traverses a firewall.
Access control policies determine how traffic is permitted or denied in a
network. For instance, you can configure a default action to inspect all
traffic or to block or trust all traffic without further inspection. You can also
achieve a more complete access control policy with enrichment data based
on security threat intelligence. Whether you configure simple or complex
rules, you can control traffic based on security zones, network or
geographical locations, ports, applications, requested URLs, and per user.

Intrusion detection and prevention: Intrusion detection and prevention

help you detect attempts from an attacker to gain unauthorized access to a
network or a host, create performance degradation, or steal information.
You define intrusion detection and prevention policies based on your access
control policies. You can create and tune custom policies at a very granular
level to specify how traffic is inspected in a network.

AMP and file control: You can detect, track, capture, analyze, and
optionally block the transmission of files, including malware files and
nested files inside archive files in network traffic. File control also enables

66
you to detect and block users from sending or receiving files of different
specified types over a multitude of application protocols. You can configure
file control as part of the overall access control policies and application
inspection.

Application programming interfaces (APIs): Cisco ASA FirePOWER

Services supports several ways to interact with the system using APIs.

The Cisco ASA FirePOWER module can be a hardware module on the ASA
5585-X only or a software module that runs in a solid state drive (SSD) in
all other Cisco ASA 5500-X models.

Note

The Cisco ASA FirePOWER Services module is not supported in the 5505.
For the 5512-X through ASA 5555-X, you must install an SSD. The SSD is
standard on the 5506-X, 5508-X, and 5516-X.

Inline versus Promiscuous Mode

The Cisco ASA FirePOWER module can be configured in either of the

following modes:

Inline mode

Promiscuous monitor-only (passive) mode

Inline Mode

When the Cisco ASA FirePOWER module is configured in inline mode, the
traffic passes through the firewall policies before it is sent to the Cisco
ASA FirePOWER module.

Figure 2-1 illustrates the order of operations when the Cisco ASA
FirePOWER module is configured in inline mode.

67
Figure 2-1 Inline Mode

1. Network traffic is received on a given interface of the Cisco ASA. In this

example, the traffic is received in the outside interface.

2. If IPsec or SSL VPN is configured, the incoming encrypted traffic is

decrypted.

3. Firewall policies are applied to the traffic.

4. If the traffic is compliant and allowed by the firewall policies, it is sent

to the Cisco ASA FirePOWER module.

5. The Cisco ASA FirePOWER module inspects the traffic and applies its
security policies and takes appropriate actions. If traffic is not compliant
with security policies or is determined to be malicious, the Cisco ASA
FirePOWER module sends back a verdict to the ASA, and the ASA blocks
the traffic and alerts the network security administrator. All valid traffic is
allowed by the Cisco ASA.

6. If IPsec or SSL VPN is configured, the outgoing traffic is encrypted.

7. The network traffic is sent to the network.

Promiscuous Monitor-Only Mode

When the Cisco ASA FirePOWER module is configured in promiscuous

monitor-only mode, a copy of each packet of the traffic that is defined in the

68
service policy is sent to the Cisco ASA FirePOWER module.

Figure 2-2 illustrates the order of operations when the Cisco ASA
FirePOWER module is configured in promiscuous monitor-only mode:

1. Network traffic is received on a given interface of the Cisco ASA. In this

example, the traffic is received in the outside interface.

Figure 2-2 Promiscuous Monitor-Only Mode

2. If IPsec or SSL VPN is configured, the incoming encrypted traffic is

decrypted.

3. Firewall policies are applied to the traffic.

4. If the traffic is compliant and allowed by the firewall policies, a copy of

each packet is sent to the Cisco ASA FirePOWER module. If traffic is not
compliant with security policies or is determined to be malicious, the Cisco
ASA FirePOWER module can be configured to alert the administrator, but it
does not block the traffic.

5. If IPsec or SSL VPN is configured, the outgoing traffic is encrypted.

6. The network traffic is sent to the network.

As you can see, the most secure and effective way to configure the Cisco
ASA FirePOWER module is in inline mode. You can configure the Cisco
ASA FirePOWER module in promiscuous monitor-only mode when you are

69
evaluating and performing capacity planning for a new deployment.

The Cisco ASA FirePOWER module modes are a bit different than those of
the Cisco FirePOWER Series of appliances, which support the following
deployment modes/options:

Standalone IPS (active/standby)

Clustering

SourceFire Redundancy Protocol (SFRP)

Bypass and non-bypass modules

Cisco FirePOWER Series next-generation intrusion prevention systems

(NGIPS) appliances can be deployed in multiple modes at once:

Passive

Inline

Routed

Switched

Note

Chapter 10, “Introduction to and Deployment of Cisco Next-Generation

IPS,” covers the different modes of operations of the Cisco FirePOWER
Series NGIPS appliances.

Cisco ASA FirePOWER Management Options

There are several options available for network security administrators to

manage the Cisco ASA FirePOWER module. The Cisco ASA FirePOWER
module provides a basic command-line interface (CLI) for initial
configuration and troubleshooting only. Network security administrators can
configure security policies on the Cisco ASA FirePOWER module using
either of these methods:

70
 Administrators can configure the Cisco Firepower Management Center
hosted on a separate appliance or deployed as a virtual machine (VM).

Administrators can configure the Cisco ASA FirePOWER module

deployed on Cisco ASA 5506-X, 5508-X, and 5516-X using Cisco’s
Adaptive Security Device Manager (ASDM).

Figure 2-3 shows a Cisco ASA with FirePOWER Services being managed
by a Cisco Firepower Management Center (FMC) in a VM.

Figure 2-3 Cisco ASA with FirePOWER Services Managed by a Cisco

Firepower Management Center

In Figure 2-3 the Cisco Firepower Management Center manages the Cisco
ASA FirePOWER module via its management interface. The following
section provides important information about configuring and accessing the
Cisco ASA FirePOWER module management interface.

Accessing the Cisco ASA FirePOWER Module Management Interface

in Cisco ASA 5585-X Appliances

In the Cisco ASA 5585-X, the Cisco ASA FirePOWER module includes a
separate management interface. All management traffic to and from the
Cisco ASA FirePOWER module must enter and exit this management
interface, and the management interface cannot be used as a data interface.

The Cisco ASA FirePOWER module needs Internet access to perform

71
several operations, such as automated system software updates and threat
intelligence updates. If the module is managed by the Firepower
Management Center, the FMC is the one that needs to have Internet access to
perform those tasks.

Figure 2-4 shows an example of how you can physically connect the Cisco
ASA FirePOWER module management interface to be able to reach the
Internet via the Cisco ASA interface.

Figure 2-4 Cisco ASA 5585-X FirePOWER Module Management Interface

In Figure 2-4, the Cisco ASA 5585-X has two modules:

A module running Cisco ASA software

A module running FirePOWER Services

The Cisco ASA is managed via the interface named management 0/0 in this
example. This interface is configured with the IP address 192.168.1.1. The
Cisco ASA FirePOWER module is managed via the interface named
management 1/0, configured with the IP address 192.168.1.2. The Cisco
ASA FirePOWER module is being managed by a virtual Cisco Firepower

72
Management Center. Both interfaces are connected to a Layer 2 switch in
this example.

Note

You can use other cabling options with the Cisco ASA FirePOWER module
management interface to be able to reach the Internet, depending on how you
want to connect your network. However, the example illustrated in Figure 2-
4 is one of the most common scenarios.

In order for the Cisco ASA FirePOWER module management interface to

have an Internet connection, the default gateway of the Cisco ASA
FirePOWER module is set to the Cisco ASA management interface IP
address (192.168.1.1 in this example). Figure 2-5 illustrates the logical
connection between the Cisco ASA FirePOWER module management
interface and the Cisco ASA management interface.

Figure 2-5 Cisco ASA FirePOWER Module Management Interface

Accessing the Cisco ASA FirePOWER Module Management Interface

in Cisco ASA 5500-X Appliances

In the rest of the Cisco 5500-X appliances, the management interface is

shared by the Cisco ASA FirePOWER module and the classic Cisco ASA
software. These appliances include the Cisco ASA 5506-X, 5506W-X,
5506H-X, 5508-X, 5512-X, 5515-X, 5516-X, 5525-X, 5545-X, and 5555-
X appliances.

Figure 2-6 shows a Cisco ASA 5516-X running Cisco ASA FirePOWER
Services.

73
Figure 2-6 Cisco ASA 5500-X FirePOWER Module Management Interface

In Figure 2-6, the management interface is used by the Cisco ASA

FirePOWER module. The management interface is configured with the IP
address 10.1.2.2. You cannot configure an IP address for this interface in the
Cisco ASA configuration. For the ASA 5506-X, 5508-X, and 5516-X, the
default configuration enables the preceding network deployment; the only
change you need to make is to set the module IP address to be on the same
network as the ASA inside interface and to configure the module gateway IP
address. For other models, you must remove the ASA-configured name and
IP address for management 0/0 or 1/1 and then configure the other interfaces
as shown in Figure 2-6.

Note

The management interface is considered completely separate from the Cisco

ASA, and routing must be configured accordingly.

The Cisco ASA FirePOWER module default gateway is configured to be the

inside interface of the Cisco ASA (10.1.2.1), as illustrated in Figure 2-7.

74
Figure 2-7 Cisco ASA 5500-X FirePOWER Module Default Gateway

If you must configure the management interface separately from the inside
interface, you can deploy a router or a Layer 3 switch between both
interfaces, as shown in Figure 2-8. This option is less common, as you still
need to manage the ASA via the inside interface.

Figure 2-8 Cisco ASA 5500-X FirePOWER Module Management Interface

Connected to a Router

In Figure 2-8, the Cisco ASA FirePOWER module default gateway is the
router labeled R1, with the IP address 10.1.2.1. The Cisco ASA’s inside

75
interface is configured with the IP address 10.1.1.1. The Cisco ASA
FirePOWER module must have a way to reach the inside interface of the
ASA to allow for on-box ASDM management. On the other hand, if you are
using FMC, the Cisco ASA FirePOWER module needs to have a way to
reach the FMC.

Cisco ASA FirePOWER Services Sizing

It is really important that you understand the capabilities of each Cisco ASA
model before you select the one that is appropriate for your specific
deployment. Table 2-1 lists the maximum application visibility and control
(AVC) and NGIPS throughput on each Cisco ASA–supported model.

For a complete and up-to-date Cisco ASA model comparison, visit Cisco’s
ASA website, at cisco.com/go/asa.

Table 2-1 The Maximum Concurrent Connections and AVC/NGIPS

76
Throughput

Cisco ASA FirePOWER Services Licensing

You have already learned that the Cisco ASA FirePOWER module can be
managed by the Firepower Management Center or ASDM, in the case of the
Cisco ASA 5506-X and 5508-X. The Firepower Management Center and
the Cisco ASA FirePOWER module require different licenses. These
licenses are installed in the Cisco FirePOWER module and the Cisco
Firepower Management Center. There are no additional licenses required in
the Cisco ASA.

The following are the different types of Cisco ASA FirePOWER Services
licenses:

Protection

Control

Malware

URL Filtering

Table 2-2 provides a high-level overview of each license.

Table 2-2 The Different Types of Cisco ASA FirePOWER Services

Licenses

The Protection License

The Protection license enables a network security administrator to perform

77
intrusion detection and prevention, file control, and security intelligence
filtering. The intrusion detection and prevention capabilities are used to
analyze network traffic for intrusions and exploits, to alert the network
security administrator and optionally block offending packets. File control
allows network security administrators to detect and (optionally) block
users from sending or receiving files of specific types over specific
application protocols.

Note

The Malware license also allows you to inspect and block a set of file
types, based on malware intelligence and dispositions. The Malware
license is covered later in this chapter.

Security intelligence filtering allows network security administrators to

blacklist different hosts/IP addresses before the traffic is analyzed by access
control rules. Cisco provides dynamic feeds, allowing a network security
administrator to immediately blacklist connections based on the Cisco threat
intelligence capabilities, fueled by Cisco’s research organization, Talos.
You can also configure this to be monitor only.

Tip

You can configure access control policies without a license; however, if you
do this, you will not be able to apply the policy until the Protection license
is added to the Cisco ASA FirePOWER module. If the Protection license is
for some reason deleted, the Cisco ASA FirePOWER module ceases to
detect intrusions and file events, and it is not able to reach the Internet for
either Cisco-provided or third-party security intelligence information.

A Protection license is required with all the other licenses (Control,

Malware, and URL Filtering licenses). If the Protection license is disabled
or deleted, this has a direct effect on any other licenses installed.

The Control License

78
The Control license allows a network security administrator to implement
user and application control. The administrator does this by adding user and
application settings to access control rules. As with the Protection license,
you can add user and application conditions to access control rules without
a Control license. You cannot apply the policy until the Control license is
installed and enabled in the Cisco ASA FirePOWER module, however.

The URL Filtering License

The URL Filtering license allows a network security administrator to

implement access control rules that determine what traffic can pass through
the firewall, based on URLs requested by monitored hosts. The Cisco ASA
FirePOWER module obtains information about those URLs from the Cisco
cloud, as illustrated in Figure 2-9.

Figure 2-9 URL Filtering Information Obtained from Cisco’s Cloud

You can configure individual URLs or groups of URLs to be allowed or

blocked by the Cisco ASA FirePOWER module without a URL Filtering
license; however, you cannot use URL category and reputation data to filter
network traffic without a URL Filtering license. The example in Figure 2-9
applies to Cisco ASA FirePOWER modules managed by ASDM. If the
Cisco ASA FirePOWER module is managed by the FMC, the URL
categorization and reputation information is received from Cisco by the
FMC and then sent to the managed devices (that is, Cisco ASA FirePOWER
modules, NGIPS, FTD, etc.).

79
Note

The URL Filtering license is a subscription-based license.

The Malware License

The Malware license enables Advanced Malware Protection (AMP) in the

Cisco ASA FirePOWER module. With AMP you can detect and block
malware potentially being transmitted over the network.

Malware detection is configured as part of a file policy, which you then

associate with one or more access control rules.

Note

Step-by-step examples of how to configure the Cisco ASA FirePOWER

module are provided in Chapter 3, “Configuring Cisco ASA with
FirePOWER Services.”

Viewing the Installed Cisco ASA FirePOWER Module Licenses

You can view the installed licenses in the Cisco ASA FirePOWER module
by navigating to System > Licenses in the Cisco Firepower Management
Center. The Licenses page lists all the licenses in the devices managed by
the Cisco Firepower Management Center, as shown in Figure 2-10.

80
Figure 2-10 Cisco Firepower Management Center Licenses Page

In Figure 2-10, a Cisco ASA 5515-X is being managed by the Cisco

Firepower Management Center. The Protection, Control, Malware, and URL
Filtering licenses are enabled.

Another way to view the installed licenses in the Cisco ASA FirePOWER
module is by navigating to Devices > Device Management in the Cisco
Firepower Management Center. Then click the device for which you want to
see the details, as shown in Figure 2-11.

81
Figure 2-11 Cisco Firepower Management Center Device Management

Adding a License to the Cisco ASA FirePOWER Module

This section covers how to add a license to the Cisco ASA FirePOWER
module after you receive the activation key provided by Cisco when you
purchase the license. The following are the steps to add a license:

Step 1. Navigate to System > Licenses in the Cisco Firepower

Management Center, as shown in Figure 2-12.

82
Figure 2-12 Adding a New License in the FMC

Step 2. Click Add New License on the Licenses page.

Step 3. Copy and paste the license into the License field and click Submit
License. If you do not have the license, follow the instructions onscreen to
obtain your license.

If you are configuring the Cisco ASA FirePOWER module using ASDM,
you can manage and install FirePOWER licenses by navigating to
Configuration > ASA FirePOWER Configuration > Licenses, as shown
in Figure 2-13.

83
Figure 2-13 Adding a New License in ASDM

Cisco ASA FirePOWER Compatibility with Other Cisco ASA

Features

The Cisco ASA FirePOWER module provides advanced HTTP inspection

and other advanced application inspection features. To take advantage of
these features, you do not configure traditional HTTP inspection in the
Cisco ASA.

In addition, the Mobile User Security (MUS) feature is not compatible with
the Cisco ASA FirePOWER module. You must disable MUS if it is enabled
in the Cisco ASA.

All other Cisco ASA application inspections are compatible with the Cisco
ASA FirePOWER module.

Cisco ASA FirePOWER Packet Processing Order of

84
Operations
When the Cisco ASA FirePOWER module is deployed, the Cisco ASA
processes all ingress packets against access control lists (ACLs),
connection tables, Network Address Translation (NAT), and application
inspections before traffic is forwarded to the FirePOWER Services module.
In order for the Cisco ASA to redirect packets to the Cisco ASA
FirePOWER module, you need to configure redirection policies using the
Cisco ASA Modular Policy Framework (MPF), as illustrated in Figure 2-
14.

Figure 2-14 Cisco ASA MPF, Redirecting Traffic to the Cisco ASA
FirePOWER Module

Note

Chapter 3 covers how to configure the Cisco ASA MPF to redirect traffic to
the Cisco ASA FirePOWER module.

85
Figure 2-15 shows the Cisco ASA packet processing order of operations.

Figure 2-15 The Cisco ASA Packet Processing Order of Operations

The following steps are illustrated in Figure 2-15:

Step 1. A packet is received on a given interface of the Cisco ASA. If a

VPN is configured, the packet is decrypted at this point. If ACL bypass is
configured for VPN traffic, the Cisco ASA proceeds to step 5.

Step 2. The Cisco ASA checks to see if there is an existing connection for
the source and destination hosts for that specific traffic. If there is an
existing connection, the Cisco ASA bypasses the ACL checks and performs
application inspection checks and proceeds to step 5.

Step 3. If there is no existing connection for that traffic, the Cisco ASA
performs the NAT checks (or untranslate process).

Step 4. The Cisco ASA allows or denies traffic based on the rules in the
configured ACLs.

Step 5. If traffic is allowed, the Cisco ASA performs application

inspection.

Step 6. The Cisco ASA forwards the packet to the Cisco ASA FirePOWER
module. If promiscuous monitor-only mode is configured, only a copy of the
packet is sent to the Cisco ASA FirePOWER module. If the Cisco ASA
FirePOWER module is configured in inline mode, the packet is inspected
and dropped if it does not conform to security policies. If the packet is
compliant with security policies and Cisco ASA FirePOWER module
protection capabilities, it is sent back to the ASA for processing.

86
Step 7. The Cisco ASA determines the egress interface based on NAT or
Layer 3 routing.

Step 8. Layer 3 routing is performed.

Step 9. Layer 2 address lookup occurs.

Step 10. The packet is sent to the network.

Figure 2-16 shows the packet flow in the Cisco ASA 5585-X.

Figure 2-16 The Packet Flow in the Cisco ASA 5585-X

In Cisco ASA 5585-X appliances, the SSP running Cisco ASA software
processes all ingress and egress packets. No packets are directly processed
by the Cisco ASA FirePOWER module (SSP) except for the Cisco ASA
FirePOWER module management port.

Cisco ASA FirePOWER Services and Failover

The Cisco ASA supports high availability using failover and clustering.
This section covers the deployment of the Cisco ASA FirePOWER module
in failover scenarios. Clustering is covered later in this chapter.

The Cisco ASA supports two types of failover:

Active/standby

Active/active

87
In active/standby failover, one unit in a failover pair is always active, and
the other one is in standby. Figure 2-17 illustrates active/standby failover.

Figure 2-17 Active/Standby Failover

The standby device drops all transit traffic that it may receive and accepts
only management connections. For a switchover to occur automatically, the
active unit must become less operationally healthy than the standby. The
failover event moves all transit traffic to the peer device, even if the actual
impact on the previously active unit is localized. When running in multiple-
context mode, all contexts switch over at the same time. Active/standby
failover is the only option when running in single-context mode.

What are these so-called security contexts? Security contexts enable a

physical Cisco ASA to be partitioned into multiple standalone firewalls.
Each context acts and behaves as an independent entity, with its own
configuration, interfaces, security policies, routing table, and administrators.
The following are some examples of scenarios in which security contexts
are useful in network deployments:

88
 You act as a service provider and want to provide firewall services to
customers; however, you do not want to purchase additional physical
firewalls for each client.

You manage an educational institution and want to segregate student

networks from faculty networks for improved security while using one
physical security appliance.

You administer a large enterprise with different departmental groups, and

each department wants to implement its own security policies.

You have overlapping networks in your organization and want to provide

firewall services to all those networks without changing the addressing
scheme.

You currently manage many physical firewalls, and you want to integrate
security policies from all firewalls into one physical firewall.

You manage a data center environment and want to provide end-to-end

virtualization to reduce operational costs and increase efficiency.

The responsibilities of the active unit include the following items:

Accept configuration commands from the user and replicate them to the
standby peer. All management and monitoring of a failover pair should
happen on the active unit because configuration replication is not a two-way
process. Making any changes on the standby ASA causes configuration
inconsistency that may prevent subsequent command synchronization and
create issues after a switchover event. If you inadvertently made a change
on the standby device, exit the configuration mode and issue the write
standby command on the active unit to restore the proper state. This
command completely overwrites the existing running configuration of the
standby unit with the running configuration of the active ASA.

Process all transit traffic, apply configured security policies, build and
tear down connections, and synchronize the connection information to the
standby unit, if configured for stateful failover.

Send NetFlow Secure Event Logging (NSEL) and syslog messages to the
configured event collectors. When necessary, you may configure the standby
unit to transmit syslog messages with the logging standby command. Keep

89
in mind that this command doubles the connection-related syslog traffic from
the failover pair.

Build and maintain dynamic routing adjacencies. The standby unit never
participates in dynamic routing.

By default, failover operates in a stateless manner. In this configuration, the

active unit only synchronizes its configuration to the standby device. All the
stateful flow information remains local to the active ASA, so all
connections must reestablish upon a failover event. While this configuration
preserves ASA processing resources, most high-availability configurations
require stateful failover. To pass state information to the standby ASA, you
must configure a stateful failover link.

Stateful failover is not available on the Cisco ASA 5505 platform. When
stateful replication is enabled, an active ASA synchronizes the following
additional information to the standby peer:

Stateful table for TCP and UDP connections. To preserve processing

resources, ASA does not synchronize certain short-lived connections by
default. For example, HTTP connections over TCP port 80 remain stateless
unless you configure the failover replication http command. Similarly,
ICMP connections synchronize only in active/active failover with
asymmetric routing (ASR) groups configured. Note that enabling stateful
replication for all connections may cause up to a 30 percent reduction in the
maximum connection setup rate supported by the particular ASA platform.

ARP table and bridge-group MAC mapping table when running in

transparent mode.

Routing table, including any dynamically learned routes. All dynamic

routing adjacencies must reestablish after a failover event, but the new
active unit continues to forward traffic based on the previous routing table
state until full reconvergence.

Certain application inspection data, such as General Packet Radio Service

(GPRS), GPRS Tunneling Protocol (GTP), Packet Data Protocol (PDP),
and Session Initiation Protocol (SIP) signaling tables. Keep in mind that
most application inspection engines do not synchronize their databases
because of resource constraints and complexity, so such connections switch
over at the Layer 4 level only. As the result, some of these connections may

90
have to reestablish after a failover event.

Most VPN data structures, including security associations (SA) for site-to-
site tunnels and remote-access users. Only some clientless SSL VPN
information remains stateless.

Stateful failover supports only Cisco ASA software features. The Cisco
ASA FirePOWER module tracks connection state independently, and the
Cisco ASAs do not synchronize their configuration or any other stateful data
in failover. When a Cisco ASA switchover occurs, the Cisco ASA
FirePOWER module typically recovers existing connections transparently
to the user, but some advanced security checks may apply only to new flows
that are established through the newly active Cisco ASA and its local
application module.

In active/active failover, Cisco ASAs operate in multiple-context mode. In

this configuration, the traffic load is split between members of the failover
pair so that each unit is active for some set of security contexts. This way,
both failover peers are passing traffic concurrently and fully utilizing their
respective hardware resources.

Figure 2-18 illustrates active/active failover.

91
Figure 2-18 Active/Active Failover

This separation is achieved by assigning specific application contexts to

one of the two failover groups and then making each of the failover peers
own one of these groups. As opposed to active/standby failover, where all
contexts switch over to the peer on active unit failure, this model localizes
the impact to the contexts in a particular failover group.

In total, an ASA supports three failover groups when configured for

active/active failover:

Group 0: This is a hidden, nonconfigurable group that covers only the

system context. It is always active on the same unit that is active for group 1.

Group 1: All newly created contexts belong to this group by default. The
admin context must always be a member of this group. By default, the
primary unit owns this group, and you typically keep it this way.

Group 2: Use this group to assign some contexts to be active on the

secondary unit. The primary unit also owns this group by default, so you

92
have to change its ownership to the secondary ASA after assigning all the
desired contexts. Keep in mind that both groups have to be active on the
same unit in order to move contexts between groups 1 and 2.

You should deploy active/active failover only when you can effectively
separate the network traffic flows into these two independent groups. Keep
in mind that interface sharing is not supported between contexts that belong
to different failover groups.

Although active/active failover offers some load-sharing benefits, consider

the following implications of this model:

You must be able to separate the traffic flows into multiple contexts such
that no interfaces are shared between contexts in different failover groups.
Keep in mind that not all features are supported in multiple-context mode.

If a switchover occurs, a single physical device must carry the full traffic
load that was originally intended for two ASA units. This effectively
reduces the benefits of load balancing because you should only plan the
overall load on the failover pair for this worst-case scenario with a single
remaining unit.

When using stateful failover, the standby device requires as much

processing power as the active one to create new connections; the only
difference is that the standby unit does not have to accept transit traffic from
the network. When you enable stateful replication with active/active
failover, you significantly reduce the available processing capacity of each
failover pair member.

Generally speaking, active/standby is the preferred deployment model for

failover. Consider clustering instead of active/active failover when your
ASA deployment scenario requires load sharing.

What Happens When the Cisco ASA FirePOWER Module Fails?

If the Cisco ASA FirePOWER module fails, you can configure it to do

either of the following:

Fail open

Fail close

93
When the Cisco ASA FirePOWER module is configured to fail open, all
traffic still passes through the Cisco ASA if the module fails. In contrast,
when the Cisco ASA FirePOWER module is configured to fail close, all
traffic stops through the Cisco ASA if the module fails.

Cisco ASA FirePOWER Services and Clustering

You can configure up to 16 identical Cisco ASA appliances in a cluster to

act as a combined traffic-processing system. When clustering is enabled, the
Cisco ASAs preserve the benefits of failover. In a cluster, virtual IP and
MAC addresses are used for first-hop redundancy.

All cluster members must have identical hardware configuration, SSP types,
application modules, and interface cards.

Figure 2-19 illustrates three Cisco ASAs configured in a cluster.

Figure 2-19 Cisco ASA Cluster

In a Cisco ASA cluster, the configuration is mirrored to all members, and

connection state is preserved after a single member failure.

Clustered Cisco ASA provides flow symmetry and high availability to the
Cisco ASA FirePOWER module. Packets and flows are not dropped by the
Cisco ASA FirePOWER module but instead are marked for “drop” or “drop
with TCP reset” and sent back to the corresponding Cisco ASA. This
methodology allows the Cisco ASA to clear the connection from the state

94
tables and send TCP resets, if needed.

When clustering is configured, stateless load balancing is done via IP

routing or spanned EtherChannel with the Link Aggregation Control
Protocol (LACP). In addition, all Cisco ASA appliances are connected to
the same subnet on each logical interface.

Figure 2-20 shows a Cisco ASA cluster configured with spanned

EtherChannel.

Figure 2-20 Cisco ASA Cluster Configured with Spanned EtherChannel

You can also configure a cluster in individual interface mode. Individual

interface mode is supported in Cisco ASAs configured in routed (Layer 3)
mode only. It is not supported in Cisco ASAs configured in transparent
(Layer 2) mode.

Figure 2-21 shows a Cisco ASA cluster configured in individual interface

mode.

95
Figure 2-21 Cisco ASA Cluster Configured in Individual Interface Mode

In individual interface mode, the cluster master owns the virtual IP on data
interfaces for management purposes only. All members get data interface IP
addresses from IP address pools in the order in which they join the cluster.

Cluster Member Election

When Cisco ASAs are configured in a cluster, one member is elected as the
master, and other Cisco ASAs are slaves. The master may be the first unit to
join the cluster or may be based on a configured priority. A new master is
elected only if the elected master fails. The master unit handles all
management and centralized functions, and the configuration is locked on
slaves.

Figure 2-22 illustrates the steps in the cluster master election process.

Figure 2-22 Cisco ASA Cluster Master Election Process

The following steps are illustrated in Figure 2-22:

Step 1. A Cisco ASA with clustering enabled boots and immediately looks

96
for a master within the cluster.

Step 2. It waits 45 seconds before it receives a reply from a master. If no

master is found, it assumes the role of master in the cluster.

Step 3. If a master already exists, the Cisco ASA assumes the role of slave
and synchronizes the configuration with the master Cisco ASA.

Step 4. The master admits one unit at a time.

Step 5. The cluster slave is ready to pass traffic.

There is a virtual IP address ownership for to-the-cluster connections, and

the master and slaves process all regular transit connections equally. If a
master fails, management traffic and other centralized connections must be
reestablished upon master failure.

How Connections Are Established and Tracked in a Cluster

This section explains how connections are established and tracked in a

Cisco ASA cluster configuration.

How a New TCP Connection Is Established and Tracked in a Cluster

Figure 2-23 illustrates how a new TCP connection is established and

tracked within a cluster.

97
Figure 2-23 A New TCP Connection in a Cisco ASA Cluster

The following steps are illustrated in Figure 2-23:

Step 1. A new TCP connection attempt is received from the client (TCP
SYN packet).

Step 2. The Cisco ASA that receives the TCP SYN (connection attempt)
becomes the flow owner and adds the TCP SYN cookie. It then delivers the
packet to the server.

Step 3. The server may reply with a TCP SYN ACK (response) through
another unit in the cluster.

Step 4. If another Cisco ASA in the cluster receives the response, it

forwards the packet to the flow owner and becomes the flow forwarder.

Step 5. The flow owner delivers the TCP SYN to the client.

Step 6. The flow owner updates the flow director with the connection
information.

How a New UDP-Like Connection Is Established and Tracked in a Cluster

98
Figure 2-24 illustrates how a new UDP or another pseudo-stateful
connection is established and tracked within a cluster.

Figure 2-24 A New UDP or Another Pseudo-stateful Connection in a

Cisco ASA Cluster

The following steps are illustrated in Figure 2-24:

Step 1. A new UDP or another pseudo-stateful connection attempt is

received from the client.

Step 2. The Cisco ASA that receives the connection attempt queries the
flow director to see if a connection already exists for that host.

Step 3. The Cisco ASA that received the packet becomes the flow owner if
no connection was found.

Step 4. The packet is delivered to the server.

Step 5. The flow owner updates the director with the new connection
information.

Step 6. The server responds to the client. If another Cisco ASA in the
cluster receives the response, it forwards the packet to the flow owner and
becomes the flow forwarder.

99
Step 7. The flow forwarder queries the director to see what Cisco ASA is
the flow owner.

Step 8. The director updates the flow forwarder with the flow owner
information.

Step 9. The flow forwarder forwards the server response to the flow
owner.

Step 10. The server response is delivered to the client.

Centralized Connections in a Cluster

There are several Cisco ASA features where connections are centralized,
such as VPN management, application inspection, and AAA for network
access. If a feature is handled in a centralized way, the cluster master
controls all the tasks.

Note

Packets for a nondistributed protocol inspection would have to all be

forwarded to the cluster master for processing.

Centralized connections decrease overall cluster performance because they

increase the processing and packet forwarding required to complete the
given task.

Note

All features that are handled in a centralized way have flows always
residing on the master unit in the cluster.

Figure 2-25 illustrates how a new centralized connection is established and

tracked within a cluster.

100
Figure 2-25 Centralized Connections in a Cisco ASA Cluster

The following steps are illustrated in Figure 2-25:

Step 1. A new connection attempt is received from the client.

Step 2. The Cisco ASA that receives the connection attempt recognizes the
centralized feature and redirects the connection attempt to the master.

Step 3. The master becomes the owner and delivers the packet to the server.

Step 4. The master updates the director with the connection information.

What Happens When the Flow Owner Fails

The Cisco ASA clustering feature provides high availability and

redundancy. Figure 2-26 illustrates what happens when a flow owner fails
for some reason.

101
Figure 2-26 Flow Owner Failure

The following steps are illustrated in Figure 2-26:

Step 1. A connection is already established between the client and the

server.

Step 2. The flow owner fails. This can be because of a power failure,
hardware failure, or some other event, such as a system crash.

Step 3. The client sends the next packet to the server, and another cluster
member receives the packet.

Step 4. The Cisco ASA that receives the packet queries the director.

Step 5. The director detects that the original flow owner failed and assigns
a new owner.

Step 6. The packet is delivered to the server.

Step 7. The new flow owner updates the flow director.

102
Deploying the Cisco ASA FirePOWER Services in the
Internet Edge

The Cisco ASA FirePOWER module provides unprecedented capabilities

to protect a corporate network from Internet threats. Many organizations of
all sizes deploy the Cisco ASA FirePOWER module at their Internet edge.
Figure 2-27 illustrates a pair of Cisco ASA with FirePOWER modules
deployed in the Internet edge of a corporate office in Raleigh, North
Carolina.

Figure 2-27 Cisco ASA FirePOWER Module in the Internet Edge

Deploying the Cisco ASA FirePOWER Services in VPN

Scenarios
The Cisco ASA FirePOWER module can be deployed in site-to-site and
remote-access VPN environments. As you learned earlier in this chapter, the
decryption process takes place before the packets are sent to the Cisco ASA
FirePOWER module by the Cisco ASA, and the packets are encrypted after
they are inspected by the Cisco ASA FirePOWER module and sent back to
the Cisco ASA.

Figure 2-28 illustrates how a Cisco ASA with the FirePOWER module is
deployed in an office in New York, terminating SSL and IPsec (IKEv2)
VPN tunnels from remote clients in the Internet.

103
Figure 2-28 Cisco ASA FirePOWER Module in a Remote-Access VPN
Scenario

In the example illustrated in Figure 2-28, the remote-access VPN clients are
using the Cisco AnyConnect client; however, clientless SSL VPN is also
supported.

Figure 2-29 illustrates how two Cisco ASAs with FirePOWER modules are
deployed in the headquarters office in New York (ASA 1) and a branch
office in Raleigh, North Carolina (ASA 2), establishing a site-to-site IPsec
VPN tunnel. In addition, ASA 2 in New York is also terminating a site-to-
site IPsec VPN tunnel to a router (R1) of a business partner in Las Vegas.

104
Figure 2-29 Cisco ASA FirePOWER Module in a Site-to-Site IPsec VPN
Scenario

In the example illustrated in Figure 2-29, the Cisco ASA FirePOWER

module not only protects against threats in the corporate network in the
remote branch office but also protects against threats coming from an
unmanaged business partner.

Deploying Cisco ASA FirePOWER Services in the Data

Center

The data center can be a very complex world. It not only provides a rich set
of services and architectures but also hosts the crown jewels of an
organization. It is extremely important to maintain visibility of everything
that is happening in the data center. The concept of “north-to-south” and
“east-to-west” is often used in describing the types of communication (or
flow) within and to the outside of the data center:

North-to-south describes communication between end users and external

entities.

East-to-west describes communication between entities in the data center.

Figure 2-30 illustrates the concepts of north-to-south and east-to-west

105
communication.

Figure 2-30 Data Center North-to-South and East-to-West

Communication

The data center has many different high-throughput and low-latency

requirements, in addition to increased high-availability requirements. In
addition, automated provisioning and control with orchestration, monitoring,
and management tools are crucial.

The data center architecture consists of three primary modular layers with
hierarchical interdependencies:

Data center foundation: This is the primary building block of the data
center, on which all other services rely. Regardless of the size of the data
center, the foundation must be resilient, scalable, and flexible to support
data center services that add value, performance, and reliability. The data
center foundation provides the computing necessary to support the
applications that process information and the seamless transport between

106
servers, storage, and the end users who access the applications.

Data center services: These services include infrastructure components

to enhance the security of the applications and access to critical data. They
also include virtual switching services to extend the network control in a
seamless manner from the foundation network into the hypervisor systems
on servers to increase control and reduce operational costs (as well as other
application resilience services).

User services: These services include email, order processing, and file
sharing or any other applications in the data center that rely on the data
center foundation and services, like database applications, modeling, and
transaction processing.

Figure 2-31 illustrates some of the components of the data center services
architecture.

107
Figure 2-31 The Data Center Services Architecture

Examples of the data center service insertion components include the

following:

Firewalls (In the example illustrated in Figure 2-31, Cisco ASAs with
FirePOWER modules are deployed.)

Intrusion prevention systems (IPS)

108
 Application delivery features

Server load balancing

Network analysis tools (such as NetFlow)

Virtualized services deployed in a distributed manner along with virtual

machines

Traffic direction with vPath and Nexus 1000v

Application Centric Infrastructure (ACI) automated framework

components for service insertion

In the case of virtualized environments, the Cisco ASAv (virtual machine)

can be deployed to protect VM-to-VM communication. The Cisco ASA
FirePOWER module in these environments is not supported, as the Cisco
ASAv is just a virtual machine. Cisco FirePOWER virtual machines running
network AMP can be deployed in those scenarios.

Note

The Cisco ASAv supports both traditional tiered data center deployments
and the fabric-based deployments of Cisco ACI environments. The Cisco
ASAv can also be deployed in cloud environments like Amazon Web
Services (AWS).

The Cisco ASA with FirePOWER modules can be deployed in

geographically dispersed cluster environments.

Figure 2-32 shows an example in which four Cisco ASAs with FirePOWER
modules are deployed in two separate sites (site A and site B).

109
Figure 2-32 Cisco ASA FirePOWER Module in a Geographically
Dispersed Data Center

In the example illustrated in Figure 2-32, the cluster of four Cisco ASAs is
fully extended between the two data centers, using the cluster control links
(CCL) operating at Layer 2 with a latency of less than 10 milliseconds. A
single spanned EtherChannel for transient data is used on the cluster side.
The local data links are also configured with EtherChannels at the switch
pairs on each site.

Tip

The data VLANs between the switches are not extended to prevent network
loops.

Firepower Threat Defense (FTD)

In Chapter 1 you learned that Firepower Threat Defense software is unified

software that provides next-generation firewall services, including the
following:

Stateful firewall capabilities

Static and dynamic routing

110
 Next-generation intrusion prevention systems (NGIPS)

Application visibility and control (AVC)

URL filtering

Advanced Malware Protection (AMP)

In the Cisco ASA, you can use FTD in single context mode and in routed or
transparent mode. Multiple context mode is not supported at this writing.

The following are the Cisco ASA 5500-X models that support a reimage to
run the FTD software:

ASA 5506-X

ASA 5506W-X

ASA 5506H-X

ASA 5508-X

ASA 5512-X

ASA 5515-X

ASA 5516-X

ASA 5525-X

ASA 5545-X

ASA 5555-X

To reimage one of the aforementioned Cisco ASA models, you must meet the
following prerequisites:

You must have a Cisco Smart Account. You can create one at Cisco
Software Central (https://software.cisco.com).

You need to review the FTD software version release notes to become
familiar of the supported features, as Cisco continues to add features very

111
regularly.

Add at least a base FTD license to your Smart Account (for example, L-
ASA5516T-BASE=).

You must have access to an FMC (virtual or physical).

You must have access to the console port of the Cisco 5500-X appliance
on which FTD software will be installed, either directly from the computer
being used for installing FTD software or through a terminal server.

It is a best practice to back up your existing configuration.

Understand that when you reimage and install FTD software on your Cisco
ASA, all previous files and configurations saved on the ASA are lost.

You need to have the required minimum free space (3 GB plus the size of
the boot software) available on the flash (disk0).

You must have an SSD in your Cisco ASA.

You must have access to a TFTP server to host the FTD images.

In Chapter 3, you will learn how to reimage and install the FTD software in
supported Cisco ASA models.

Summary

The Cisco ASA FirePOWER module provides network visibility, policy

enforcement, and advanced threat protection across many organizations and
the entire attack continuum. This chapter starts with an introduction to the
Cisco ASA FirePOWER module. It explains the difference between inline
and promiscuous (monitor-only) deployment modes. This chapter also
covers the different Cisco ASA FirePOWER management options and
provides guidance on what models to use, based on network size and
demands. You have also learned about the Cisco ASA FirePOWER
Services licensing and compatibility issues with other Cisco ASA features.
This chapter also provides a deep dive into the Cisco ASA and the Cisco
FirePOWER module packet-processing order of operations. You have
learned how the Cisco ASA FirePOWER module behaves and is deployed
in failover and clustering configurations. Several deployment scenarios are

112
covered, including deploying Cisco ASA FirePOWER Services at the
Internet Edge, in site-to-site and remote-access VPN scenarios, and in the
data center. At the end of the chapter, you learned a few details about the
FTD software and prerequisites prior to installation on a supported Cisco
ASA model.

113
Chapter 3. Configuring Cisco ASA with
FirePOWER Services
This chapter provides step-by-step guidance on how to set up and configure
the Cisco ASA with FirePOWER Services module. The following topics
are covered in this chapter:

Setting up the Cisco ASA FirePOWER module in Cisco ASA 5585-X

appliances

Setting up the Cisco ASA FirePOWER module in Cisco ASA 5500-X

appliances

Configuring the Cisco ASA to redirect traffic to the Cisco ASA

FirePOWER module

Configuring the Cisco ASA FirePOWER services module for the FMC

Configuring the Cisco ASA FirePOWER module using the Adaptive

Security Device Manager (ASDM)

Firepower Threat Defense (FTD)

Setting Up the Cisco ASA FirePOWER Module in Cisco

ASA 5585-X Appliances

In Chapter 2, “Introduction to and Design of Cisco ASA with FirePOWER

Services,” you learned that in the Cisco ASA 5585-X, the Cisco ASA
FirePOWER module includes a separate management interface. All
management traffic to and from the Cisco ASA FirePOWER module must
enter and exit this interface. You also learned that the Cisco ASA
FirePOWER module needs Internet access to perform several operations.

Figure 3-1 shows an example of how you can physically connect the Cisco
ASA FirePOWER module management interface to be able to reach the
Internet by using the Cisco ASA interface.

114
Figure 3-1 Cisco ASA 5585-X Management Interfaces

Figure 3-1 shows the Cisco ASA 5585-X with a module running Cisco ASA
software and a module running FirePOWER Services. The Cisco ASA
software is managed by using the interface named Management 0/0 in this
example. This interface is configured with the IP address 10.10.1.1. The
Cisco ASA FirePOWER module is managed by using the interface named
Management 1/0, configured with the IP address 10.10.1.2.

You can access the Cisco ASA FirePOWER module command-line interface
(CLI) by using the serial console port or Secure Shell (SSH).

Cisco ASA 5585-X appliances have a dedicated console port for the Cisco
ASA FirePOWER module. You can use a DB-9 to RJ-45 serial cable or a
USB serial adapter to connect to the console.

Note

In all other Cisco ASA models, you connect to the Cisco ASA console and
then you connect by using the backplane to the “module” or solid state drive
(SSD) by using the session sfr command. The Cisco ASA 5506-X, Cisco
ASA 5508-X, and Cisco ASA 5516-X also come with a mini-USB console

115
port that you can use.

You can also connect to the Cisco ASA FirePOWER module by using SSH,
with the default IP address.

Table 3-1 lists all the default parameters and credentials of the Cisco ASA
FirePOWER module.

Table 3-1 Cisco ASA FirePOWER Module Default Settings

Installing the Boot Image and Firepower System Software in the Cisco
ASA 5585-X SSP

In order to have a fully functional Cisco ASA FirePOWER module in a

Cisco ASA 5585-X, the boot image needs to first be installed, and then a
system software package needs to be installed as well.

Note

If you purchased a new Cisco ASA with FirePOWER Services, you do not
need to reimage the system to install upgrade packages.

To install the boot image, you need to transfer the image from a TFTP server
to the Management-0 port on the ASA Firepower SSP by logging in to the
module’s Console port.

116
Tip

The Management-0 port is in the first slot on an SSP. This management port
is also known as Management 1/0; however, it appears as Management-0 or
Management 0/1 in ROMMON.

Figure 3-2 illustrates a topology with a Cisco ASA with a Firepower SSP
and a TFTP server. The Cisco ASA Firepower SSP management interface is
configured with IP address 10.10.1.1 and the TFTP server with 10.10.1.2.

Figure 3-2 Firepower SSP TFTP Boot

Follow these steps to install the boot image:

Step 1. Place the boot image and a system software package on the TFTP
server so that they can be accessed by the Cisco ASA FirePOWER module.

Step 2. Connect to the Cisco ASA FirePOWER module through the

Management 1/0 interface. You must use this interface to TFTP boot the boot
image.

Step 3. Reboot the system with the system reboot command.

Step 4. As the system is booting, break out of the boot process by pressing
Esc (the Escape key on your keyboard). If you see grub start to boot the
system, you are too late, and you have to reboot the system again.

Step 5. From the ROMMON prompt, configure the IP address for the
Firepower SSP, the TFTP server address, the gateway, and the boot image
path and filename. The following example shows the configuration used in
this example:

Click here to view code image

ADDRESS=10.10.1.1

117
SERVER=10.10.1.2
GATEWAY=10.1.1.2
IMAGE= asasfr-5500x-boot-6.0.0-1005.img

In this example, the IP address of the Firepower SSP is 10.10.1.1. The

TFTP server address is 10.10.1.2, and the gateway is set to the TFTP server
address, as well. The boot image is asasfr-5500x-boot-6.0.0-1005.img.
After entering the preceding commands, issue the set command to apply the
configuration.

Step 6. Save the settings by using the sync command.

Step 7. Start the download and boot process by using the tftp command.

Note

The boot takes several minutes. When it is finished, you see a login prompt.

Step 8. Log in as admin, with the password Admin123, which is the default
password.

Step 9. Start configuring the system by issuing the setup command.

Step 10. Configure the hostname, which can be up to 65 alphanumeric

characters, with no spaces (though hyphens are allowed).

Step 11. Configure the IP address. You can configure a static IPv4 or IPv6
address or use DHCP (for IPv4) or stateless autoconfiguration if you are
configuring IPv6.

Step 12. Identify at least one DNS server and set the domain name and
search domain.

Note

The management address, the gateway, and DNS information are the key
settings to configure. Administrators often forget to set up the DNS server
correctly, and this causes problems later in the configuration.

118
Step 13. Optionally, enable NTP and configure the NTP servers to set the
system time.

Step 14. Install the system software image by using the system install
[noconfirm] url command. Here is an example:

Click here to view code image

asasfr-boot> system install http://10.10.1.2/ asasfr-sys-6.0.0-1005.pkg

Note

The noconfirm option skips all the confirmation messages.

The Cisco ASA FirePOWER module reboots when the installation is

complete. This process can take more than 10 minutes. After the Cisco ASA
FirePOWER module boots, you can log in as admin with the password
Sourcefire. You can install the system software image from an HTTP,
HTTPS, or FTP server that is accessible from the ASA SFR management
interface.

Note

Detailed step-by-step configuration options are provided later in this

chapter.

Setting Up the Cisco ASA FirePOWER Module in Cisco

ASA 5500-X Appliances

The following sections cover how to perform the initial setup of the Cisco
ASA FirePOWER module in Cisco ASA 5500-X appliances.

Tip

119
Cisco is always adding new models to its next-generation security
appliances. Visit Cisco’s Firepower compatibility guide to obtain the most
recent information:
www.cisco.com/c/en/us/td/docs/security/firepower/compatibility/firepower-
compatibility.html.

Installing the Boot Image and Firepower System Software in the SSD of
Cisco ASA 5500-X Appliances

As you have already learned in this chapter, if you purchase a new Cisco
ASA 5500-X appliance with the Cisco ASA FirePOWER module, the
module software and required SSDs come preinstalled and ready to
configure. However, you need to install the Cisco ASA Firepower boot
software, partition the SSD, and install the system software if you are
adding a new Cisco ASA FirePOWER software module to an existing Cisco
ASA or if the SSD needs to be replaced.

Tip

The flash (disk0) should have at least 3 GB of free space plus the space
needed for the boot software in order to perform the reimaging process. If
you are running the Cisco ASA in multi-context mode, you need to complete
the reimaging steps in the system execution space. You also need to shut
down any other modules from the Cisco ASA CLI, as shown in Example 3-
1.

Example 3-1 Shutting Down and Uninstalling the IPS Module

Click here to view code image

sw-module module ips shutdown

sw-module module ips uninstall
reload

The commands in Example 3-1 shut down and uninstall the IPS software

120
module (if installed on the Cisco ASA) and reboot the Cisco ASA. If you
have a Cisco ASA CX module, you can use the same commands except use
the cxsc keyword instead of ips.

Note

If you are just reimaging the Cisco ASA FirePOWER module, use the sw-
module module sfr shutdown and sw-module module sfr uninstall
commands.

Complete the following steps to install the boot image and the Firepower
system software in the SSD of a Cisco ASA 5500-X appliance:

Step 1. Download the Firepower boot image and system software packages
from Cisco.com.

Step 2. Transfer the boot image to the ASA. You can do this by using the
CLI or the ASDM. If you select to install the image by using the ASDM, you
can place the boot image on your workstation and upload it from there or
you can place it on an FTP, TFTP, HTTP, HTTPS, SMB, or SCP server. In
the ASDM, select Tools > File Management and choose the appropriate
file transfer command, either Between Local PC and Flash or Between
Remote Server and Flash. Figure 3-3 illustrates how to transfer the file
between the remote server and flash.

121
Figure 3-3 ASDM File Transfer

If you choose to transfer the file by using the CLI, place the boot image on a
TFTP, FTP, HTTP, or HTTPS server and then use the copy command to
transfer it to the Cisco ASA flash. To transfer the file by using TFTP, enter
the following command:

Click here to view code image

RTP-asa# copy tftp://10.10.1.2/asasfr-5500x-boot-5.4.1-69.img

disk0:/asasfr-5500x-boot-5.4.1-69.img

Step 3. Transfer the boot software to disk0 on the ASA.

Step 4. After the boot image is transferred to disk0 (flash), use sw-module
module sfr recover configure image disk0: file to recover the Firepower
module and install the boot image, as demonstrated here:

Click here to view code image

122
NY-asa# sw-module module sfr recover configure image
disk0:asasfr-5500x-boot-5.4.1-69.img

Step 5. Use the sw-module module sfr recover boot command to load the
Firepower boot image. This takes approximately 5 to 15 minutes.

Step 6. Use the session command to connect to the Firepower module from
the Cisco ASA, as demonstrated in the example that follows. The default
username is admin, and the default password is Admin123:

Click here to view code image

RTP-asa# session sfr console

Opening console session with module sfr.
Connected to module sfr. Escape character sequence is 'CTRL-^X'.

Cisco ASA SFR Boot Image 5.4.1

asasfr login: admin
Password: Admin123

Note

The session command fails with a message about not being able to connect
over ttyS1 if the module has not completed the boot process.

Step 7. Configure the module so that you can install the system software
package using the setup command, as shown here:

Click here to view code image

asasfr-boot> setup

Welcome to SFR Setup

[hit Ctrl-C to abort]
Default values are inside []

Enter the hostname, management address, gateway, DNS information, and,

optionally, NTP server. It is very important to enter a correct DNS server to

123
avoid name resolution problems during setup. You can also set the domain
name and search domain.

Step 8. Install the system software image by using the system install
[noconfirm] url command. You can transfer the file using HTTP, HTTPS, or
FTP. The following example demonstrates how to install the system
software image by using HTTP:

Click here to view code image

asasfr-boot> system install http://10.10.1.3/asasfr-sys-5.4.1-211.pkg

Verifying
Downloading
Extracting
Package Detail
Description: Cisco ASA-Firepower 5.4.1-211
System Install
Requires reboot: Yes

Do you want to continue with upgrade? [y]: y

Warning: Please do not interrupt the process or turn off the system.
Doing so might leave system in unusable state.

Upgrading
Starting upgrade process ...
Populating new system image

Reboot is required to complete the upgrade. Press 'Enter' to reboot the

system.
(press Enter)
Broadcast message from root (ttyS1) (Mon Sep 28 12:12:48 2015):

The system is going down for reboot NOW!

Console session with module sfr terminated.

When the Firepower module reboots and you use the session command to
access the module, you see a different login prompt, as shown in Example
3-2.

Example 3-2 A Functional Firepower Module

124
Click here to view code image

RTP-asa# session sfr console

Opening console session with module sfr.
Connected to module sfr. Escape character sequence is 'CTRL-^X'.

RTP-sfr login: admin

Password:
Last login: Sun Sep 27 02:02:28 UTC 2015 on ttyS1

Copyright 2001-2013, Sourcefire, Inc. All rights reserved. Sourcefire is

a registered trademark of Sourcefire, Inc. All other trademarks are
property of their respective owners.

Sourcefire Linux OS v5.4.1 (build 43)

Sourcefire ASA5512 v5.4.1 (build 211)

Last login: Sun Sep 27 02:02:28 on ttyS1

>

Configuring of Cisco ASA 5506-X, 5508-X, and 5516-X Appliances

When the Cisco ASA is booted with no configuration, it offers a setup menu
that enables you to assign the initial parameters, such as the device name
and an address for the management interface. You can choose to go through
the initial setup menu for quick configuration. Example 3-3 shows the boot
process (console output) for an ASA 5508.

Example 3-3 Boot Process of the ASA 5508

Click here to view code image

Rom image verified correctly

Cisco Systems ROMMON, Version 1.1.01, RELEASE SOFTWARE
Copyright (c) 1994-2014 by Cisco Systems, Inc.
Compiled Mon 10/20/2014 15:59:12.05 by builder
Current image running: Boot ROM0

125
Last reset cause: PowerCycleRequest
DIMM Slot 0 : Present
DIMM Slot 1 : Present

Platform ASA5508 with 8192 Mbytes of main memory

MAC Address: 18:8b:9d:ad:79:c1

Use BREAK or ESC to interrupt boot.

Use SPACE to begin boot immediately.

Boot in 10 seconds.
Located '.boot_string' @ cluster 840607.
#
Attempt autoboot: "boot disk0:/asa951-lfbff-k8.SPA"

Located 'asa951-lfbff-k8.SPA' @ cluster 816328.

######################################################################
#####################################################################
#####################################################################
#####################################################################
#####################################################################
#####################################################################
#####################################################################
#####################################################################
####################################################################

LFBFF signature verified.

INIT: version 2.88 booting

Starting udev
Configuring network interfaces... done.
Populating dev cache
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
There are differences between boot sector and its backup.
Differences: (offset:original/backup)
65:01/00
Not automatically fixing this.
Starting check/repair pass.
Starting verification pass.

126
/dev/sdb1: 120 files, 838432/1918808 clusters
dosfsck(/dev/sdb1) returned 0
Processor memory 3754858905

Compiled on Wed 12-Aug-15 12:18 PDT by builders

Total NICs found: 13

i354 rev03 Gigabit Ethernet @ irq255 dev 20 index 08 MAC:
188b.9dad.79c1
ivshmem rev03 Backplane Data Interface @ index 09 MAC:
0000.0001.0002
en_vtun rev00 Backplane Control Interface @ index 10 MAC:
0000.0001.0001
en_vtun rev00 Backplane Int-Mgmt Interface @ index 11 MAC:
0000.0001.0003
en_vtun rev00 Backplane Ext-Mgmt Interface @ index 12 MAC:
0000.0000.0000
Verify the activation-key, it might take a while...
Running Permanent Activation Key: 0x7007c269 0x1098868c 0x54928558
0xa9987ca0
0x081c04af

Licensed features for this platform:

Maximum Physical Interfaces : Unlimited perpetual
Maximum VLANs : 50 perpetual
Inside Hosts : Unlimited perpetual
Failover : Active/Active perpetual
Encryption-DES : Enabled perpetual
Encryption-3DES-AES : Enabled perpetual
Security Contexts :2 perpetual
GTP/GPRS : Disabled perpetual
AnyConnect Premium Peers :4 perpetual
AnyConnect Essentials : Disabled perpetual
Other VPN Peers : 100 perpetual
Total VPN Peers : 100 perpetual
Shared License : Disabled perpetual
AnyConnect for Mobile : Disabled perpetual
AnyConnect for Cisco VPN Phone : Disabled perpetual
Advanced Endpoint Assessment : Disabled perpetual
Total UC Proxy Sessions : 320 perpetual

127
Botnet Traffic Filter : Disabled perpetual
Cluster : Disabled perpetual
VPN Load Balancing : Enabled perpetual

Encryption hardware device : Cisco ASA Crypto on-board accelerator

(revision 0x1)

Cisco Adaptive Cisco ASA Software Version 9.5(1)

****************************** Warning
*******************************
This product contains cryptographic features and is
subject to United States and local country laws
governing, import, export, transfer, and use.
Delivery of Cisco cryptographic products does not
imply third-party authority to import, export,
distribute, or use encryption. Importers, exporters,
distributors and users are responsible for compliance
with U.S. and local country laws. By using this
product you agree to comply with applicable laws and
regulations. If you are unable to comply with U.S.
and local laws, return the enclosed items immediately.

A summary of U.S. laws governing Cisco cryptographic

products may be found at:
http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by

sending email to [email protected].
******************************* Warning
*******************************

libgcc, version 4.8.1, Copyright (C) 2007 Free Software Foundation, Inc.
libgcc comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it under the
General
Public License v.3 (http://www.gnu.org/licenses/gpl-3.0.html)
See User Manual (''Licensing'') for details.

libstdc++, version 4.8.23, Copyright (C) 2007 Free Software Foundation,

128
Inc.
libstdc++ comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it under the
General
Public License v.2 (http://www.gnu.org/licenses/gpl-2.0.html)
See User Manual (''Licensing'') for details.

Mdadm tools, version 3.2.6, Copyright (C) 1989, 1991 Free Software
Foundation, Inc.
Copyright (C) 2002-2009 Neil Brown <[email protected]>
mdadm comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it under the
General
Public License v.2 (http://www.gnu.org/licenses/gpl-2.0.html)
See User Manual (''Licensing'') for details.

Cisco Adaptive Cisco ASA Software, version 9.5

Copyright (c) 1996-2015 by Cisco Systems, Inc.
For licenses and notices for open source software used in this product,
please visit
http://www.cisco.com/go/asa-opensource

Restricted Rights Legend

Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
Rights clause at FAR sec. 52.227-19 and subparagraph
(c) (1) (ii) of the Rights in Technical Data and Computer
Software clause at DFARS sec. 252.227-7013.

Cisco Systems, Inc.

170 West Tasman Drive
San Jose, California 95134-1706

Reading from flash...

!!...
Cryptochecksum (unchanged): e7c1298c 7cf1ea71 242116d3 20270fcc

INFO: Power-On Self-Test in process.

.......................................................................

129
INFO: Power-On Self-Test complete.

INFO: Starting HW-DRBG health test...

INFO: HW-DRBG health test passed.

INFO: Starting SW-DRBG health test...

INFO: SW-DRBG health test passed.
Type help or '?' for a list of available commands.
ciscoasa>

In the first highlighted line in Example 3-3, the Cisco ASA starts loading the
Cisco ASA software image and then verifies the activation key (license
key), as you can see in the other highlighted lines. Then it lists all the open
source licenses used in the software and performs system health checks. At
the end of the boot process you get a prompt, which by default is ciscoasa>;
this prompt changes, however, after you change the device hostname.

In Example 3-4, the Cisco ASA prompts you to specify whether you wish to
go through the interactive menu to preconfigure the device. If you type no,
the interactive menu is not shown, and the Cisco ASA shows the ciscoasa>
prompt. If you type yes, the default option, the Cisco ASA walks you
through the configuration of a number of parameters.

The Cisco ASA shows the default values in brackets ([]) before prompting
you to accept or change them. To accept the default input, press Enter. After
you go through the initial setup menu, the Cisco ASA displays the summary
of the new configuration before prompting you to accept or reject it.

Example 3-4 Cisco ASA Initial Setup Menu

Click here to view code image

Pre-configure Firewall now through interactive prompts [yes]? yes

Firewall Mode [Routed]:
Enable password [<use current password>]: C1$c0123
Allow password recovery [yes]?
Clock (UTC):
Year [2012]: 2016

130
 Month [Jul]: Jan
Day [6]:6
Time [01:08:57]: 21:27:00
Management IP address: 192.168.1.1
Management network mask: 255.255.255.0
Host name: NY-1
Domain name: securemeinc.org
IP address of host running Device Manager: 192.168.1.88

The following configuration will be used:

Enable password: <current password>
Allow password recovery: yes
Clock (UTC): 21:27:00 Jan 6 2016
Firewall Mode: Routed
Management IP address: 192.168.1.1
Management network mask: 255.255.255.0
Host name: NY-1
Domain name: securemeinc.org
IP address of host running Device Manager: 192.168.1.88

Use this configuration and write to flash? yes

Cryptochecksum: 629d6711 ccbe8923 5911d433 b6dfbe0c

182851 bytes copied in 1.190 secs (182851 bytes/sec)

NY-1>

You can assign the initial parameters and features by using either CLI
commands or the ASDM.

Tip

You can rerun the interactive setup process by using the setup command in
configuration mode.

Before you access the ASDM graphical console, you must install the ASDM
software image on the local flash of the Cisco ASA if it is not present
already. The ASDM interface only manages a local Cisco ASA. Therefore,

131
if you need to manage multiple Cisco ASAs, you must install the ASDM
software on all the Cisco ASAs. However, a single workstation can launch
multiple instances of ASDM to manage more than one appliance.

Uploading ASDM

You can use the dir command to determine whether the ASDM software is
installed. If the Cisco ASA does not have an ASDM image, your first step is
to upload an image from an external file server, using one of the supported
protocols. The appliance needs to be set up for basic configuration,
including the following:

Image interface names

Image security levels

Image IP addresses

Image proper routes

After you set up basic information, use the copy command to transfer the
image file, as shown in Example 3-5, where an ASDM file, named asdm-
751.bin, is being copied from a TFTP server located at 172.18.82.10. Verify
the content of the local flash after the file is successfully uploaded.

Example 3-5 Uploading the ASDM Image to the Local Flash

Click here to view code image

NY-1# copy tftp flash

Address or name of remote host []? 172.18.82.10
Source filename []? asdm-751.bin
Destination filename [asdm-751.bin]? asdm-751.bin

Accessing tftp://172.18.82.10/asdm-715.bin...!!!!!!!!!!!!!!!!!!
! Output omitted for brevity.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Writing file disk0:/asdm-715.bin...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

132
! Output omitted for brevity.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
22658960 bytes copied in 51.30 secs (420298 bytes/sec)

NY-1# dir
Directory of disk0:/
135 -rwx 22834188 06:18:02 Jan 06 2016 asdm-715.bin
136 -rwx 37767168 06:22:46 Jan 06 2016 asa951-smp-k8.bin
4118732802 bytes total (3955822592 bytes free)

Setting Up the Cisco ASA to Allow ASDM Access

When the ASDM file is accessed, the Cisco ASA loads the first ASDM
image that it finds from the local flash. If multiple ASDM images exist in the
flash, use the asdm image command and specify the location of the ASDM
image you want to load. This ensures that the appliance always loads the
specified image when ASDM is launched. The following commands sets up
the Cisco ASA to use asdm-715.bin as the ASDM image file:

Click here to view code image

NY-1(config)# asdm image disk0:/asdm-751.bin

The Cisco ASA uses the Secure Sockets Layer (SSL) protocol to
communicate with the client. Consequently, the Cisco ASA acts as a web
server to process the requests from the clients. You must enable the web
server on the appliance by using the http server enable command.

The Cisco ASA discards the incoming requests until the ASDM client’s IP
address is in the trusted network to access the HTTP engine. To enable the
HTTP engine and set up the appliance to trust the 192.168.1.0/24 network
connected to the management interface, enter the following commands:

Click here to view code image

NY-1(config)# http server enable

NY-1(config)# http 192.168.1.0 255.255.255.0 management

133
Note

The SSL VPN implementation on the Cisco ASA requires you to run the
HTTP server on the appliance. Starting with Cisco ASA software version
8.0, you can set up the Cisco ASA to terminate both the SSL VPN and
ASDM sessions on the same interface, using the default port 443. Use
https://<ASAipaddress>/admin to access the GUI for administrative and
management purposes.

Accessing the ASDM

You can access the ASDM interface from any workstation whose IP address
is in the trusted network list. Before you establish the secure connection to
the appliance, verify that IP connectivity exists between the workstation and
the Cisco ASA.

To establish an SSL connection, launch a browser and point it to the

appliance’s IP address. In Figure 3-4, ASDM is accessed by entering
https://192.168.1.1/admin as the URL. The URL is redirected to
https://192.168.1.1/admin/public/index.html.

134
Figure 3-4 Accessing the ASDM URL

The Cisco ASA presents its self-signed certificate to the workstation so that
a secure connection can be established. If the certificate is accepted, the
Cisco ASA prompts you to present authentication credentials. If the ASDM
authentication or enable password is not set up, there is no default username
or password. If the enable password is defined, there is no default
username, and you must use the enable password as the login password. If
user authentication is enabled on the Cisco ASA through use of the aaa
authentication http console command, then those login credentials must be
provided. After a successful user authentication, the appliance presents two
ways to launch ASDM:

Run Cisco ASDM as a local application: The Cisco ASA offers a setup
utility called asdm-launcher.msi, which can be saved to the workstation’s
local hard drive.

135
 Run Cisco ASDM as a Java Web Start application: The Cisco ASA
launches ASDM in the client’s browser as a Java applet. This option is not
feasible if a firewall that filters out Java applets exists between the client
and the Cisco ASA.

Note

Running the ASDM as a local application is currently supported on

Windows-based and OS X–based operating systems.

When the ASDM application is launched, it prompts for the IP address of

the Cisco ASA to which you are trying to connect, as well as the user
authentication credentials.

Note

When you first launch the ASDM, the Cisco Smart Call Home functionality
may prompt you to enable error and health information reporting either
anonymously or by registering the product. You can choose not to enable if
you are not interested.

If the user authentication is successful, the ASDM checks the current version
of the installer application and downloads a new copy, if necessary. It loads
the current configuration from the Cisco ASA and displays it in the GUI, as
shown in Figure 3-5.

136
Figure 3-5 ASDM Home Screen

After you have established connectivity to the Cisco ASA, by using either
the CLI or the ASDM, you are ready to start configuring the device. The
following section guides you through basic setup of the Cisco ASA.

Setting Up a Device Name and Passwords

The default device name (also known as the hostname) of a Cisco ASA is
ciscoasa. It is highly recommended that you set a unique device name to
identify the Cisco ASA on the network. In addition, networking devices
usually belong to a network domain. A domain name appends the
unqualified hostnames with the configured domain name. For example, if the
Cisco ASA tries to reach the host secweb by its hostname and the
configured domain name on the Cisco ASA is securemeinc.org, the fully
qualified domain name (FQDN) of the host is secweb.securemeinc.org.

In a new Cisco ASA, you can configure the Telnet and enable passwords.

137
The Telnet password is used to authenticate remote sessions by using either
the Telnet protocol or SSH. Prior to Cisco ASA software version 9.0(2), the
default Telnet password was cisco. In version 9.0(2) and later, you must
define a Telnet password using the password command. In addition, for an
SSH connection, there is no default username or password in version 8.4(2)
and later. You must configure the aaa authentication ssh console command
to enable AAA authentication.

Example 3-6 shows the configuration you use in the CLI. The hostname is
changed using the hostname command, the domain name is changed using
the domain-name command, and the Telnet and enable passwords are
changed using the password and enable password commands, respectively.

Example 3-6 Setting Up the Hostname, Domain Name, and Passwords

Click here to view code image

ciscoasa# configure terminal

ciscoasa(config)# hostname NY-1
NY-1(config)# domain-name securemeinc.org
NY-1 (config)# password C1$c0123
NY-1 (config)# enable password C1$c0123

Tip

If you view the configuration after adding the passwords, the Cisco ASA
displays the encrypted passwords as follows:

Click here to view code image

NY-1# show running-config | include pass

enable password 9jNfZuG3TC5tCVH0 encrypted
passwd 2KFQnbNIdI.2KYOU encrypted

Configuring an Interface

Cisco ASA appliances come with a number of Fast Ethernet, Gigabit

138
Ethernet, and 10-Gigabit Ethernet interfaces, depending on the platform.
They also include one management interface (Management 0/0) in all one-
rack unit (1 RU) models and two management interfaces (Management 0/0
and Management 0/1) in ASA 5580s and ASA 5585s. In addition, you can
create one or more subinterfaces in each physical interface. The Fast
Ethernet, Gigabit Ethernet, and 10-Gigabit Ethernet interfaces are used to
route traffic from one interface to another, based on the configured policies,
whereas the management interface is designed to establish out-of-band
connections.

The Cisco ASA protects the internal network from external threats. Each
interface is assigned a name to designate its role on the network. The most
secure network is typically labeled as the inside network, whereas the least
secure network is designated as the outside network. For semi-trusted
networks, you can define them as demilitarized zones (DMZs) or any logical
interface name. You must use the interface name to set up the configuration
features that are linked to an interface.

The Cisco ASA also uses the concept of assigning security levels to the
interfaces. The higher the security level, the more protected the interface.
Consequently, the security level is used to reflect the level of trust of this
interface with respect to the level of trust of another interface on the Cisco
ASA. The security level can be between 0 and 100. Therefore, the most
trusted network is placed behind the interface with a security level of 100,
whereas the least protected network is placed behind an interface with a
security level of 0. A DMZ interface should be assigned a security level
between 0 and 100.

Note

When an interface is configured with a nameif command, the Cisco ASA

automatically assigns a preconfigured security level. If an interface is
configured with the name inside, the Cisco ASA assigns a security level of
100. For all the other interface names, the Cisco ASA assigns a security
level of 0.

Cisco ASA enables you to assign the same security level to more than one
interface. If communication is required between the hosts on interfaces at

139
the same security level, use the same-security-traffic permit inter-
interface global configuration command. In addition, if an interface is not
assigned a security level, it does not respond at the network layer.

By default, you do not need to define an access control list (ACL) to permit
traffic from a high security–level interface to a low security–level interface;
however, if you want to restrict traffic flows from a high security–level
interface destined to a low security–level interface, you can define an ACL.
If you configure an ACL for traffic originating from a high security–level
interface to a low security–level interface, it disables the implicit permit
from that interface. All traffic is now subject to the entries defined in that
ACL.

An ACL must explicitly permit traffic traversing the security appliance from
a lower to a higher security–level interface of the firewall. The ACL must
be applied to the lower security–level interface or globally.

The most important parameter under the interface configuration is the

assignment of an IP address. This is required if an interface is to be used to
pass traffic in a Layer 3 firewall, also known as routed mode. An address
can be either statically or dynamically assigned. For a static IP address, you
configure an IP address and its respective subnet mask.

The Cisco ASA also supports interface address assignment through a

Dynamic Host Configuration Protocol (DHCP) server and by using PPPoE.
Assigning an address by using DHCP is a preferred method if an ISP
dynamically allocates an IP address to the outside interface. You can also
inform the Cisco ASA to use the DHCP server’s specified default gateway
as the default route if the Obtain Default Route Using DHCP option is
enabled in the ASDM. You can do this in the CLI by issuing the ip address
dhcp [setroute] interface subcommand.

Note

If a Cisco ASA is deployed in transparent mode, the IP address is assigned

in global configuration mode or on a bridge virtual interface (BVI)
interface, depending of the version of code.

Assigning an interface address through DHCP is not supported if used with

140
failover.

To configure a physical interface on a Cisco ASA by using ASDM, navigate

to Configuration > Device Setup > Interfaces, select an interface, and
click the Edit button.

Example 3-7 shows how to enable the GigabitEthernet0/0 interface as the

outside interface and assigns a security level of 0. The IP address is
209.165.200.225 with a mask of 255.255.255.224.

Example 3-7 Enabling an Interface

Click here to view code image

NY-1# configure terminal

NY-1(config)# interface GigabitEthernet0/0
NY-1(config-if)# no shutdown
NY-1(config-if)# nameif outside
NY-1(config-if)# security-level 0
NY-1(config-if)# ip address 209.165.200.225 255.255.255.224

The ASDM enables you to configure the speed, duplex, and media type on
an interface by opening the Edit Interface dialog box for the interface and
clicking the Configure Hardware Properties button. By default, the speed
and duplex are set to auto and can be changed to avoid link negotiations. If
the speed and duplex settings do not match the speed and duplex settings on
the other end of the Ethernet connection, you may see packet loss and
experience performance degradation. The media type is either RJ-45 for
copper-based interfaces or SFP for fiber-based interfaces. RJ-45 is the
default media type.

Tip

The Ethernet-based interfaces on the Cisco ASA 5500 Series use the auto-
MDI/MDIX (media-dependent interface/media-dependent interface
crossover) feature, which does not require a crossover cable when
connecting interfaces of two similar types. These interfaces perform an
internal crossover when a straight network cable connects two similar

141
interfaces. This feature works only when both the speed and duplex
parameters are set to auto-negotiate.

Example 3-8 shows the outside interface set up with a connection speed of
1000 Mbps, using full-duplex mode.

Example 3-8 Configuring Speed and Duplex on an Interface

Click here to view code image

NY-1# configure terminal

NY-1(config)# interface GigabitEthernet0/0
NY-1(config-if)# speed 1000
NY-1(config-if)# duplex full

The Cisco ASA shows the output of interface-related statistics when you
issue the show interface command from the CLI. Example 3-9 shows
GigabitEthernet0/0 set up as the outside interface and has an IP address of
209.165.200.225 and GigabitEthernet0/1 set up as the inside interface with
an IP address of 192.168.10.1. This command also shows the packet rate
and the total number of packets entering and leaving the interface.

Example 3-9 show interface Command Output

Click here to view code image

NY-1# show interface

Interface GigabitEthernet0/0 "outside", is up, line protocol is up
Hardware is i82574L rev00, BW 1000 Mbps, DLY 10 usec
Full-duplex, 1000 Mbps
MAC address 000f.f775.4b53, MTU 1500
IP address 209.165.200.225, subnet mask 255.255.255.224
70068 packets input, 24068922 bytes, 0 no buffer
Received 61712 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 L2 decode drops
13535 packets output, 7196865 bytes, 0 underruns

142
 0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
0 lost carrier, 0 no carrier
input queue (curr/max packets): hardware (0/1) software (0/11)
output queue (curr/max packets): hardware (0/19) software (0/1)
Traffic Statistics for "outside":
70081 packets input, 23044675 bytes
13540 packets output, 6992176 bytes
49550 packets dropped
1 minute input rate 1 pkts/sec, 362 bytes/sec
1 minute output rate 1 pkts/sec, 362 bytes/sec
1 minute drop rate, 0 pkts/sec
5 minute input rate 1 pkts/sec, 342 bytes/sec
5 minute output rate 1 pkts/sec, 362 bytes/sec
5 minute drop rate, 0 pkts/sec
Interface GigabitEthernet0/1 "inside", is up, line protocol is up
Hardware is i82546GB rev03, BW 1000 Mbps, DLY 10 usec
Auto-Duplex(Full-duplex), Auto-Speed(1000 Mbps)
MAC address 000f.f775.4b55, MTU 1500
IP address 192.168.10.1, subnet mask 255.255.255.0
1447094 packets input, 152644956 bytes, 0 no buffer
Received 1203884 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
20425 L2 decode drops
332526 packets output, 151244141 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
0 lost carrier, 0 no carrier
input queue (curr/max packets): hardware (0/1) software (0/14)
output queue (curr/max packets): hardware (0/26) software (0/1)
Traffic Statistics for "inside":
777980 packets input, 80481496 bytes
151736 packets output, 85309705 bytes
395607 packets dropped
1 minute input rate 0 pkts/sec, 58 bytes/sec
1 minute output rate 0 pkts/sec, 0 bytes/sec
1 minute drop rate, 0 pkts/sec
5 minute input rate 0 pkts/sec, 66 bytes/sec
5 minute output rate 0 pkts/sec, 0 bytes/sec
5 minute drop rate, 0 pkts/sec

143
Configuring the Cisco ASA to Redirect Traffic to the Cisco
ASA FirePOWER Module

As you learned in Chapter 2, you can configure the Cisco ASA FirePOWER
module in inline mode or in monitor-only mode. Follow these steps to
configure the Cisco ASA to redirect traffic to the Cisco ASA FirePOWER
module in inline mode or monitor-only mode:

Step 1. Log in to the ASDM.

Step 2. Navigate to Configuration > Firewall > Service Policy Rules.

Note

If you previously had a legacy IPS module or CX module configured and an

active service policy in the Cisco ASA, you must remove that policy before
you configure the Cisco ASA FirePOWER Services policy. If your Cisco
ASA is running in multiple context mode, you must configure the service
policy within each security context.

Step 3. Click the Add button to add a new service policy rule. The screen
shown in Figure 3-6 appears.

144
Figure 3-6 Adding a New Service Policy

Step 4. Specify whether the policy will apply to a particular interface or

globally and click Next. In this example, the policy will apply globally.

Step 5. After you click Next, the screen shown in Figure 3-7 appears.

145
Figure 3-7 Adding the New Traffic Class

Step 6. Enter the name of the new traffic class (for example, firePOWER-
class).

Step 7. Enter an optional description.

Step 8. Optionally specify criteria for the traffic that will be matched and
sent to the Cisco ASA FirePOWER module or use the default class (class-
default). In this example, the class will match all traffic because the Any
traffic checkbox is checked under the Traffic Match Criteria field.

Step 9. Click Next. The Rule Actions page shown in Figure 3-8 appears.

146
Figure 3-8 The Rule Actions Page

Step 10. Navigate to the ASA Firepower Inspection tab and check the
Enable ASA Firepower for this traffic flow checkbox, as shown in Figure
3-8.

Step 11. Optionally configure the Cisco ASA to pass traffic if the Cisco
ASA FirePOWER module fails (this is referred to as “fail open”) or
configure the Cisco ASA to stop all traffic (or “fail close”). In Figure 3-8,
the Cisco ASA is configured to fail open because the Permit traffic option
is selected in the If ASA Firepower Card Fails area.

Step 12. Optionally check Enable Monitor Only to send a read-only copy
of traffic to the module. This is also referred to as “inline tap mode.” (By
default, the Cisco ASA sends all traffic to the Cisco ASA FirePOWER
module in inline mode.) In Figure 3-8, the Cisco ASA is configured to send
all traffic to the Cisco ASA FirePOWER module, and the module is
configure in inline mode.

Step 13. Click Finish. The new service policy is shown on the Service

147
Policy Rules page in ASDM, as shown in Figure 3-9.

148
Figure 3-9 The New firePOWER-class Traffic Class

Example 3-10 shows the command-line interface (CLI) commands that were
applied on the Cisco ASA by ASDM.

Example 3-10 Configuring the Service Policy Using the CLI

Click here to view code image

! The class map

class-map firePOWER-class
description class to send all traffic to the Firepower module
! Matching all traffic to be sent to the Firepower module
match any
!
! Applying the class to the policy map
policy-map global_policy
class firePOWER-class
! The Firepower module configured to fail open

149
 sfr fail-open
!
! Applying the policy map to the service policy
service-policy global_policy global

Configuring the Cisco ASA FirePOWER Module for the

FMC

You can register the Cisco ASA FirePOWER module to the Firepower
Management Center (FMC). Chapter 12, “Reporting and Troubleshooting
with Cisco Next-Generation IPS,” covers the FMC in detail. Complete the
following steps to register the Cisco ASA FirePOWER module to the FMC:

Step 1. Log in to the Cisco ASA FirePOWER module.

Step 2. Use the configure manager command as shown in the following

example:

Click here to view code image

configure manager add 192.168.1.89 thisISaRegKey

In this example, the IP address of the FMC is 192.168.1.89. You can also
use the DNS hostname or an IPv6 address (if IPv6 is enabled in your
network). If the FMC is not directly addressable, use the DONTRESOLVE
keyword. In this example, the registration key is thisISaRegKey. The
registration key is a unique alphanumeric registration key required to
register a Cisco ASA FirePOWER module to the FMC. You can also enter
an optional alphanumeric string (nat_id) that is used during the registration
process between the FMC and the ASA FirePOWER module. This is
required if the DONTRESOLVE keyword is used. In deployments where
Network Address Translation (NAT) is configured, you must provide a
hostname or an IP address either when you are configuring remote
management or when you are adding the managed appliance. A self-
generated alphanumeric registration key up to 37 characters in length
identifies the connection. You can configure an optional unique
alphanumeric NAT ID (nat_id) that can help the FMC establish
communications in a NAT environment. The NAT ID must be unique among
all NAT IDs used to register managed appliances.

150
Step 3. Type exit to exit the configuration mode.

Configuring the Cisco ASA FirePOWER Module Using the

ASDM

You can use the ASDM to configure the Cisco ASA FirePOWER module in
only certain platforms, including the Cisco ASA 5506-X, 5506H-X,
5506W-X, 5508-X, and 5516-X appliances.

Note

For additional compatibility information, visit

www.cisco.com/c/en/us/td/docs/security/asa/compatibility/asamatrx.html#48552

The following sections covers how to configure the Cisco ASA

FirePOWER module using the ASDM in supported platforms.

Configuring Access Control Policies

To view the access control policies that are applied in the Cisco ASA
FirePOWER module, navigate to Configuration > ASA FirePOWER
Configuration > Policies > Access Control Policy, as shown in Figure 3-
10.

151
Figure 3-10 Firepower Access Control Policy

Creating a New Access Control Policy

Follow these steps to create a new access control policy in the Cisco ASA
FirePOWER module:

Step 1. Click the New Policy button. The dialog shown in Figure 3-11
appears.

152
Figure 3-11 Creating a New Access Control Policy

Step 2. Enter a name for the new access policy. In this example, the name of
the new policy is myPolicy.

Step 3. Enter an optional description for the policy.

Step 4. Set Default Action to either Block all traffic or Intrusion

Prevention. If you select the default action to Block all traffic, all traffic
will be blocked without further inspection. In this example, the default
action is set to Intrusion Prevention. When you first create an access
control policy, you cannot choose to trust traffic as the default action. If you
want to trust all traffic by default, change the default action after you create
the policy. You can also use and modify the initial system-provided policy
named Default Trust All Traffic. Figure 3-12 shows the Default Action
dropdown menu options.

153
Figure 3-12 Default Action Dropdown Menu Options

You can also copy an existing policy from this ASA FirePOWER module or
import a policy from another ASA FirePOWER module.

As previously mentioned, in this example, Intrusion Prevention is set as the

default action. Therefore, the Cisco ASA FirePOWER module creates a
policy with the Intrusion Prevention: Balanced Security and
Connectivity default action.

Step 5. Click Store ASA Firepower Changes.

Adding Rules to the Access Control Policy

You can more granularly control network traffic by adding rules to an access
control policy. The rules within an access control policy are organized
using a numbering scheme starting at 1. The Firepower system matches
traffic to access control rules by ascending rule number. Typically, the
Firepower system process network traffic according to the first access
control rule, where all the rule’s conditions match the traffic. These

154
conditions include the following:

Security zone

Network or geographical location

Ports

Applications

Requested URLs

Users

To add a rule, click the Add Rule button, and the screen shown in Figure 3-
13 appears.

155
Figure 3-13 Adding a New Rule

Each rule also has an action that determines whether you monitor, trust,
block, or allow matching traffic. When you allow traffic, you can specify
that the system first inspect it with intrusion or file policies to block any
exploits, malware, or prohibited files before they reach your assets or exit
your network. On the other hand, after the system trusts or blocks traffic, it
does not perform further inspection. Figure 3-14 shows the Action
dropdown menu options.

156
Figure 3-14 Action Dropdown Menu Options

To configure rules based on security zones, navigate to the Zones tab. You
can also configure rule conditions to match network or geographical
locations. Figure 3-15 shows how to configure a rule condition based on
geographical location of the source and destination networks. For instance,
you can block or allow traffic that is sourced or destined to a given
geographical location. In Figure 3-15, the source networks are based in
North America (geolocation), and the destination networks are in Asia.

Figure 3-15 Rules Based on Geolocation

Cisco Security Intelligence–based traffic filtering and some decoding and

preprocessing occur before network traffic is evaluated by access control
rules. The system matches traffic to access control rules in the order you
specify. In most cases, the system handles network traffic according to the

157
first access control rule where all the rule’s conditions match the traffic.
Some of the filtering capabilities may rely on Layer 7 (application)
information, where the actual flow of the application may not be determined
until a few packets are analyzed in the communication between two or more
hosts. Conditions can be simple or complex; you can control traffic by
security zone, network or geographical location, port, application, requested
URL, and user.

You can also create rules based on the type and the risk of the application.
Figure 3-16 shows how to create a rule based on application conditions, on
the Applications tab.

Figure 3-16 Rules Based on Application Risk and Type

Figure 3-17 shows how to use the Ports tab to create a rule based on given
application ports. You can select predefined ports/applications such as FTP,
Bittorrent, DNS over TCP or UDP, and so on.

158
Figure 3-17 Rules Based on Ports

You can also create rules that match known URLs to sites known to be
hosting pornography, drug content, dating sites, and many other categories.
The URL filtering license is required in order to configure and enable rules
based on URLs. Figure 3-18 shows how to use the URLs tab to configure a
rule based on URL categories.

Figure 3-18 Rules Based on URL Categories

Security Intelligence

Security Intelligence from Cisco is available as a first line of defense

against malicious Internet sites and known malicious IP addresses. You can
configure this feature to instantly blacklist (block) connections based on the

159
latest reputation intelligence from Cisco Talos. You can configure access
control policies with whitelists and blacklists, based on Cisco Talos
Security Intelligence by navigating to the Security Intelligence tab under a
given access policy, as shown in Figure 3-19.

160
Figure 3-19 Security Intelligence Tab

You can override blacklists with custom whitelists in order to ensure

continual access to critical resources. This traffic filtering takes place
before any other policy-based inspection, analysis, or traffic handling,
including rules and the default action.

HTTP Responses

You can customize a web page for blocked URLs. When the system blocks a
given HTTP web request, you can customize what the user sees in a web
browser depending on how the session is blocked. For example, you can
select Block or Block with reset to deny the connection. A blocked session
times out; the system resets Block with reset connections. On the other hand,
for both blocking actions, you can override the default browser or server
page with a custom page that explains that the connection was denied. The
Cisco ASA Firepower system calls this custom page an HTTP response
page.

You can edit the block response page by navigating to the HTTP Responses

161
tab under the access control policy, as shown in Figure 3-20.

162
Figure 3-20 Customizing Block Response Pages

If you set the Cisco ASA FirePOWER module action to Interactive Block
or Interactive Block with reset, you can configure an interactive HTTP
response page that warns users but also allows them to click a button to
continue or refresh the page to load the originally requested site. Users may
have to refresh after bypassing the response page to load page elements that
did not load. You can either display a generic system-provided response
page or enter custom HTML, as shown in Figure 3-21.

163
Figure 3-21 Customizing Interactive Block Response Pages

Access Control Policy Advanced Settings

The advanced access control policy settings typically require little or no

modification because the default settings are appropriate for most
deployments. However, you can also customize the following advanced
settings (see Figure 3-22):

General Settings: You can customize the number of characters you store
in the Cisco ASA FirePOWER module database for each URL requested by
users.

Network Analysis and Intrusion Policies: You can change the access
control policy’s default intrusion policy and associated variable set, which
are used to initially inspect traffic before the system can determine exactly
how to inspect that traffic. You can also change the access control policy’s
default network analysis policy, which administers many preprocessing
options. In addition, you can use custom network analysis rules and network
analysis policies to tailor preprocessing options to specific security zones

164
and networks.

File and Malware Settings: You can set performance options for file
control, file storage, and advanced malware protection.

Transport/Network Layer Preprocessor Settings: You can create

preprocessor settings that are applied globally to all networks, zones, and
VLANs where you apply your access control policy.

Detection Enhancement Settings: You can use adaptive profiles to

improve reassembly of packet fragments and TCP streams in passive
deployments, based on your network’s host operating systems.

Performance Settings and Latency-Based Performance Settings: You

can tune and improve the performance of your system as it analyzes traffic
for attempted intrusions.

165
Figure 3-22 Access Control Rules Advanced Settings

Configuring Intrusion Policies

You can configure intrusion policies by navigating to Configuration > ASA

FirePOWER Configuration > Policies > Intrusion Policy, where you can
view your current custom intrusion policies, edit them, or create new ones.
To create a new intrusion policy, click Create Policy to display the screen
shown in Figure 3-23.

166
Figure 3-23 Creating a New Intrusion Policy

You must provide a name for the new intrusion policy, specify a base policy,
and specify drop behavior.

The Drop when Inline setting defines how the Firepower module handles
drop rules (intrusion or preprocessor rules whose rule state is set to Drop
and Generate Events) and other intrusion policy configurations that affect
traffic. You should enable drop behavior in inline deployments when you
want to drop or replace malicious packets.

Note

In Cisco ASA FirePOWER modules that are configured in passive mode,

the system cannot affect traffic flow, regardless of the drop behavior.

The base policy sets the intrusion policy’s default settings. You can use
either a system-provided or custom policy as your base policy. Figure 3-23

167
shows the Base Policy dropdown menu options.

You can edit an intrusion policy by navigating to Configuration > ASA

FirePOWER Configuration > Policies > Intrusion Policy and clicking the
pencil (edit) button; the screen shown in Figure 3-24 appears.

168
Figure 3-24 Editing an Intrusion Policy

To customize how rules are displayed in the intrusion policy or sort rules by
several criteria, click Manage Rules to display the screen shown in Figure
3-25.

169
Figure 3-25 Managing Rules Under an Intrusion Policy

In the page shown in Figure 3-25, you can also display the details for a
specific rule to see rule settings, rule documentation, and other rule settings.
This page has four key categories:

Filtering features

Rule attribute menus

Rules listing

Rule details

Note

The column headers relate to the menus in the menu bar, where you access
those configuration items.

170
Custom Rules

You can create custom rules or edit or clone existing ones by navigating to
Configuration > ASA FirePOWER Configuration > Policies > Intrusion
Policy > Rule Editor (see Figure 3-26).

171
Figure 3-26 The Rule Editor

To modify an existing rule, click the pencil icon next to the specific rule.
You can also import rules from another system by clicking the Import Rules
button to display the screen shown in Figure 3-27.

172
Figure 3-27 Importing Rules

New vulnerabilities are reported daily by many vendors in the industry.

Cisco Talos releases rule updates that you can first import onto your Cisco
ASA Firepower module and then implement by applying affected access
control, network analysis, and intrusion policies.

Tip

Rule updates are cumulative, and Cisco recommends that you always import
the latest update. You cannot import a rule update that either matches or
predates the version of the currently installed rules. Rule updates may
contain new binaries, so make sure your process for downloading and
installing them complies with your security policies. In addition, rule
updates may be large, so import rules during periods of low network use.

If you are an advanced user, you can create a new rule by clicking Create
Rule in the main rule editor page (refer to Figure 3-26). The screen shown

173
in Figure 3-28 appears.

174
Figure 3-28 Creating a Custom Rule

When creating a custom standard text rule, you set the rule header settings
and the rule keywords and arguments. After you create a custom rule, you
can search for it by using the rule number. The format of the rule number is
as follows:

GID:SID:Rev

The rule number for all standard text rules starts with 1. The second part of
the rule number, the Snort ID (SID), indicates whether the rule is a local
rule or a rule provided by Cisco. Snort IDs for custom rules start at
1,000,000, and the SID for each new local rule is incremented by 1. The last
part of the rule number is the revision number. Each time you edit a custom
rule, the revision number increments by 1.

You enter the message you want displayed with the event in the Message
field. The Classification dropdown menu allows you to select a
classification to describe the type of event. Figure 3-29 shows examples of
the options available in the Classification dropdown menu.

175
Figure 3-29 Event Type Classification

The Action list allows you to define the type of rule you are creating (alert
to create an alert or pass to create a rule that ignores traffic that triggers the
rule). You can select from the Protocol dropdown menu the traffic protocol
(tcp, udp, icmp, or ip) of packets you want the rule to inspect.

The Direction dropdown menu allows you to select the operator that
indicates which direction of traffic you want to trigger the rule.

You can also define the source and destination IP addresses and ports that
should trigger the rule. Select Directional under the Direction dropdown
menu to match traffic that moves from the source IP address to the
destination IP address. Select Bidirectional to match traffic that moves in
either direction.

You can select the detection options under the Detection Options
dropdown menu and click the Add Option button. Figure 3-30 shows
examples of the different detection options available.

176
Figure 3-30 New Rule Detection Option

Configuring File Policies

You can configure file policies in a Cisco ASA FirePOWER module to

perform advanced malware protection and file control. You can configure
file policies by navigating to Configuration > ASA FirePOWER
Configuration > Policies > Files. To create a new file policy, click the New
File Policy button to open the dialog shown in Figure 3-31.

177
Figure 3-31 Creating a New File Policy

Enter the name of the new file policy and a description and then click the
Store ASA FirePOWER Changes button. The screen shown in Figure 3-32
appears.

178
Figure 3-32 The New File Policy

The policy has two access control rules, both of which use the Allow action
and are associated with file policies. The policy’s default action is also to
allow traffic, but without file policy inspection. A file policy, like its parent
access control policy, contains rules that determine how the system handles
files that match the conditions of each rule. You can configure file rules to
take different actions for different file types, application protocols, or
directions of transfer. To add a new file rule, click the Add File Rule button.
The Add File Rule screen shown in Figure 3-33 appears.

179
Figure 3-33 Adding a New File Rule

Note

Each file rule has an associated action that determines how the system
handles traffic that matches the conditions of the rule.

You can set separate rules within a file policy to take different actions for
different file types, application protocols, or directions of transfer.

The rule actions can be configured to the following:

Detect Files: To log the detection of specific file types while still
allowing their transmission

Block Files: To block specific file types

Malware Cloud Lookup: To log the malware disposition of files

traversing the network based on a cloud lookup, while still allowing their
transmission

Block Malware: To calculate the SHA-256 hash value of specific file

types, use a cloud lookup process to first determine whether files traversing
the network contain malware, and block files that represent threats

You can select different file type categories in the File Type Categories

180
section and select or search for specific file types under the File Types
section (refer to Figure 3-33). Click the Add button to add file categories
and file types.

Reusable Object Management

The Cisco ASA FirePOWER module allows you to create named objects,
which are reusable configurations that associate a name with a value so that
a named object is used instead. You can configure the following object
types:

Network-based objects that represent IP addresses and networks,

port/protocol pairs, security zones, and origin/destination country
(geographical location)

Security Intelligence feeds and lists

Application filters

Ports

URLs

File lists

Intrusion policy variable sets

You can use these objects in various places in the ASA FirePOWER
module, including access control policies, network analysis policies,
intrusion policies and rules, reports, dashboards, and so on. You can
configure these objects by navigating to Configuration > ASA
FirePOWER Configuration > Object Management.

Keeping the Cisco FirePOWER Module Up-to-Date

Cisco provides different types of updates for the Cisco ASA FirePOWER
module, including the following:

Major and minor updates to the module software itself (patches, feature
updates, and major updates)

181
 Rule updates

Geolocation database (GeoDB) updates

Vulnerability database (VDB) updates

Patches include a limited range of fixes and usually change the fourth digit
in the version number (for example, 5.4.2.1). Feature updates are more
comprehensive than patches and generally include new features and usually
change the third digit in the version number (for example, 5.4.3). Major
updates include new features and functionality and may involve large-scale
changes and usually change the first or second digit in the version number
(for example, 5.4 or 5.5).

To apply and upload product updates, go to Configuration > ASA

FirePOWER Configuration > Updates, navigate to the Product Updates
tab, and click Upload Update, as shown in Figure 3-34.

182
Figure 3-34 Applying Product Updates

VDB updates affect the database of known vulnerabilities to which hosts

may be susceptible. Intrusion rule updates provide new and updated
intrusion rules and preprocessor rules, modified states for existing rules,
and modified default intrusion policy settings.

Tip

Rule updates may also delete rules, provide new rule categories and default
variables, and modify default variable values.

To configure or upload rule updates, go to Configuration > ASA

FirePOWER Configuration > Updates and navigate to the Rule Updates
tab, as shown in Figure 3-35.

183
Figure 3-35 Applying Rule Updates

Cisco recommends that you always import the latest update. You can apply
one-time rule updates or set the interval of recurring rule update imports.

Note

Rule updates are cumulative. You cannot import a rule update that either
matches or predates the version of the currently installed rules.

Geolocation updates provide updated information on physical locations

with detected routable IP addresses. As you learned earlier in this chapter,
you can use geolocation data as a condition in access control rules. To
configure or upload geolocation updates, go to Configuration > ASA
FirePOWER Configuration > Updates and navigate to the Geolocation
Updates tab, as shown in Figure 3-36.

184
Figure 3-36 Applying Geolocation Updates

You can import a one-time geolocation update or configure recurring

updates, as shown in Figure 3-36.

Firepower Threat Defense

As you learned in previous chapters, the Cisco Firepower Threat Defense

(FTD) software can run on the following Cisco ASA models:

Cisco ASA 5506-X

Cisco ASA 5506H-X

Cisco ASA 5506W-X

Cisco ASA 5512-X

Cisco ASA 5515-X

Cisco ASA 5516-X

185
 Cisco ASA 5525-X

Cisco ASA 5545-X

Cisco ASA 5555-X

Note

Cisco is always adding new models to its next-generation security

appliances. You should visit the Cisco Firepower compatibility guide to
obtain the most recent information:
www.cisco.com/c/en/us/td/docs/security/firepower/compatibility/firepower-
compatibility.html.

Installing FTD Boot Image and Software

FTD provides next-generation firewall services, including stateful

firewalling, dynamic routing, next-generation intrusion prevention systems
(NGIPS), Application Visibility and Control (AVC), URL filtering, and
Advanced Malware Protection (AMP) in a unified system image. You can
use an FTD device in single-context mode and in routed or transparent
mode.

If you are deploying a Cisco ASA 5506-X, Cisco ASA 5508-X, or Cisco
ASA 5516-X, you must run ROMMON version 1.1.8 or later. You can
transfer the new ROMMON image by using the copy command, as
mentioned previously in this chapter. Once you copy the ROMMON image,
you can use the upgrade rommon disk0: rommon-image command to
upgrade the ROMMON in the system. The Cisco ASA then updates the
ROMMON and reboots the system.

To install the FTD software in a supported Cisco ASA, you use the same
procedure you learned earlier: You first install the boot image in ROMMON
by pressing Esc during the boot process, and then, at the ROMMON prompt,
enter set and configure the following parameters to establish temporary
connectivity to the TFTP server:

ADDRESS: The management IP address of the Cisco ASA.

186
 SERVER: The IP address of the TFTP server.

GATEWAY: The gateway address to the TFTP server. If the TFTP server
is directly attached to Management 1/0, use the IP address of the TFTP
server. If the TFTP server and management address are on the same subnet,
do not configure the gateway, or TFTP boot will fail.

IMAGE: The boot image path and image name on the TFTP server. For
example, if you place the file on the TFTP server in
/tftpboot/images/filename, the IMAGE value is images/ftd-boot-
version.cdisk or ftd-boot-version.lfbff.

After you enter that information, use the sync command to save the settings
and issue the tftpdnld command to initiate the download and boot process.
The OS image should begin downloading through TFTP. When the OS
download is complete, the system automatically boots with the image it just
downloaded and stops at the boot CLI prompt.

After installing the boot image, use the setup command to enter the
management IP address, subnet mask, and gateway and then use the system
install [noconfirm] url command (as discussed earlier) to transfer and
install the FTD software:

Click here to view code image

> system install http://10.10.10.123/ftd-6.0.1-123.pkg

After the FTD image is installed, choose Yes when the appliance reboot
option is displayed. The Cisco ASA reboots, and the system prompts you
for a username and password when the reboot is complete. At this point, the
OS and package installation is complete.

FTD Firewall Mode

The FTD software supports routed and transparent firewall modes, just like
the legacy Cisco ASA software. The default is routed. In transparent mode
you can create up to 250 bridge groups, with 4 interfaces per bridge group.
In devices configured in transparent mode, the diagnostic interface updates
the MAC address table in the same manner as a data interface; therefore,
you should not connect both a diagnostic interface and a data interface to the

187
same switch unless you configure one of the switch ports as a routed port.
Otherwise, if traffic arrives on the diagnostic interface from the physically
connected switch, FTD updates the MAC address table to use the diagnostic
interface, instead of the data interface, to access the switch. This action
causes a temporary traffic interruption; the FTD device does not re-update
the MAC address table for packets from the switch to the data interface for
at least 30 seconds for security reasons.

To change the firewall mode in FTD, you can use the configure firewall
[routed | transparent] command, as demonstrated here:

Click here to view code image

> configure firewall transparent

This will destroy the current interface configurations, are you sure that you
want
to proceed? [y/N] y
The firewall mode was changed successfully.

FTD Interface Types

There are three general types of interfaces in FTD:

Management interface

Diagnostic interface

Routed mode deployment

The management interface is a dedicated interface for management tasks and

registering the device to the FMC. It runs a separate SSH server and uses its
own local authentication, IP address, and static routing. To configure its
settings by using the CLI, you can use the configure network command or
change the IP address in the FMC by navigating to Devices > Device
Management > Devices > Management.

The diagnostic interface only allows management traffic and does not allow
through traffic. You can configure the diagnostic logical interface along with
the rest of the data interfaces in the FMC by navigating to Devices > Device
Management > Interfaces. Using the diagnostic interface is optional. The

188
diagnostic interface and data interfaces can be used to communicate with
external LDAP or RADIUS servers for authentication.

Tip

Cisco recommends that you not configure the diagnostic interface and, in
fact, suggests that you remove the name for this interface if you do not have
an inside router. The major benefit of disabling the diagnostic interface is
that you can place the management interface on the same network as any
other data interfaces. If you leave the diagnostic interface configured, its IP
address must be on the same network as the management IP address, and it
counts as a regular interface that cannot be on the same network as any other
data interfaces. Because the management interface requires Internet access
for updates, putting the management interface on the same network as an
inside interface means you can deploy the FTD device with only a switch on
the inside and point to the inside interface as its gateway.

FTD Security Zones

Each interface must be assigned to a single security zone. This is the same
principle you learned earlier, with Cisco ASA running Firepower Services.
You apply security policy based on zones. For instance, you can configure
your access control policy to enable traffic to go from inside to outside but
not from outside to inside, for example. You can create security zones in the
FMC by navigating to the Objects page.

You can also add a security zone can when you are configuring an interface.
You can only add interfaces to the correct zone type for your interface—
either Passive, Inline, Routed, or Transparent zone types.

Note

The diagnostic and management interfaces cannot belong to a security zone.

Static and Dynamic Routing in FTD

189
FTD supports static routes and the following dynamic routing protocols:

OSPF

BGP

RIP

To add a static route, follow these steps:

Step 1. Log in to the FMC, navigate to Devices > Device Management,

and edit the FTD device. Then select the Routing tab.

Step 2. Select Static Route from the table of contents and click Add
Routes.

Step 3. Select IPv4 or IPv6.

Step 4. Enter or select the Interface to which this static route applies. In
the Available Network list, enter or select the destination network. If you
are adding a default route, create an object with the address 0.0.0.0/0 and
select it there.

Step 5. Enter or select the gateway router in the Gateway or IPv6

Gateway field.

Step 6. Enter the number of hops to the destination network in the Metric
field. Valid values range from 1 to 255, and the default value is 1.

Step 7. If you want to monitor route availability, in the Route Tracking

field enter or select the name of a service level agreement (SLA) Monitor
object that defines the monitoring policy. This is only supported in IPv4 and
not in IPv6.

Step 8. Click OK.

To configure OSPF, RIP, or BGP, navigate to Devices > Device

Management and edit the FTD device and then select the routing protocol
in the Routing area.

190
Note

OSPF, RIP, and BGP routing protocol configuration is very similar to the
legacy Cisco ASA software configuration.

The access policy, IPS, AMP, URL filtering, and other configurations in
FTD are the same as the Firepower software options you learned previously
in this chapter.

Summary

In this chapter you have learned how to configure the Cisco ASA and the
Cisco ASA FirePOWER module. You have seen step-by-step examples of
how to set up the Cisco ASA FirePOWER module in Cisco ASA 5585-X
and in Cisco ASA 5500-X appliances. You have also learned how to
configure the Cisco ASA to redirect traffic to the Cisco ASA FirePOWER
module. The Cisco ASA FirePOWER module can be managed and
configured with the FMC. In addition, you have learned how to configure
the Cisco ASA FirePOWER module for the FMC. The Cisco ASA
FirePOWER module can be configured using ASDM in certain platforms
only—the Cisco ASA 5506-X, 5506H-X, 5506W-X, 5508-X, and 5516-X
appliances. In this chapter you have learned how to configure the Cisco
ASA FirePOWER module using the ASDM in the supported platforms. You
have learned how to configure access control, intrusion and file policies,
and custom rules. In addition, you have learned how to configure reusable
objects to ease configuration tasks. You have also learned how to apply
product updates and how to import and schedule rule and geolocation
database updates. Finally, you have gotten an overview of how to install the
FTD software on a Cisco ASA as well as how to configure interfaces,
security zones, and dynamic routing.

191
Chapter 4. Troubleshooting Cisco ASA with
FirePOWER Services and Firepower Threat
Defense (FTD)
This chapter provides step-by-step guidance on how to troubleshoot
common problems you may encounter when deploying the Cisco ASA with
FirePOWER Services module and the Firepower Threat Defense software.
The following topics are covered in this chapter:

Useful show commands

Access control policy details

Network configuration details

Storage usage monitoring

Running process analysis

System log (Syslog)

System task monitoring and troubleshooting

Advanced troubleshooting logs

Useful ASA debugging commands

Useful show Commands

Several show commands can be very helpful when troubleshooting

problems in the Cisco ASA with FirePOWER Services module. These
show commands also apply to Cisco Firepower Threat Defense (FTD).

If you are running the Cisco ASA with FirePOWER Services module,
connect to the module using the session command. Alternatively, you can
connect directly to the module management interface using secure shell
(SSH). Once you are in the module, to get an overview of all the show
commands that are available, log in to the command-line interface (CLI) of

192
the Cisco ASA with FirePOWER Services module and enter the show
command as demonstrated in Example 4-1.

Example 4-1 Available show Commands

Click here to view code image

ASA-1# session sfr console

Opening console session with module sfr.
Connected to module sfr. Escape character sequence is 'CTRL-^X'.RTP-SF
login: admin
Password:
Last login: Fri Jan 22 04:34:20 UTC 2016 on ttyS1
Copyright 2004-2015, Cisco and/or its affiliates. All rights reserved.
Cisco is a registered trademark of Cisco Systems, Inc.
All other trademarks are property of their respective owners.
Cisco Linux OS v5.4.1 (build 12)
Cisco ASA5508 v5.4.1.2 (build 23)
> show
Show>
access-control-config Show Current Access-Control Configuration
audit-log Show audit log
configure Change to Configuration mode
cpu Show CPU utilization
database Change to Show Database Mode
device-settings Show device settings
disk Show disk usage
disk-manager Display current status of local disk(s)
dns Show DNS configuration
end Return to the default mode
exit Exit Show Mode
expert Invoke a shell
help Display an overview of theLI syntax
history Display the current session's command line history
hostname Show hostname
hosts Show hosts
ifconfig Show currently configured interfaces
interfaces Show interface configuration
kdump Display status of kernel crash dump feature
log-ips-connection Display Logging of Connection Events setting

193
logout Logout of the current CLI session
managers Show managing Defense Centers
memory Show available memory
model Show model
netstat Show network connections
network Show configuration of management interface
network-static-routes Show static routes for management interfaces
ntp Show NTP configuration
perfstats Shoperfstats
process-tree Show processes in tree format
processes Show processes
route Show configured routes
serial-number Show serial number
show Change to Show Mode
summary Show summary
system Change to System Mode
time Show time
traffic-statistics Show traffic statistics
user Show specified users
users Show all users
version Show versions

The following sections cover some of the most useful show commands and
when to use them.

Displaying the Access Control Policy Details

In Chapter 3, “Configuring Cisco ASA with FirePOWER Services,” you

learned about the access control policies in the Cisco ASA FirePOWER
module. You may encounter problems related to the configuration of those
policies and perhaps configuration errors in Cisco’s Adaptive Security
Device Manager (ASDM). An alternative way to view the access control
policy configuration is by using the show access-control-config command,
whose output can be useful when you’re troubleshooting configuration
issues related to access control policies. Example 4-2 shows an example of
output from the show access-control-config command.

Example 4-2 show access-control-config Command Output

194
Click here to view code image

Show> show access-control-config

! The following is the policy we already had configured in the system
(myPolicy).
====================[ myPolicy ]====================
Description : my new access control policy
HTTP Block Response : Default
Interactive Block Response: Default
=================[ Default Action ]=================
! In this case, the default action is set to allow the traffic through the device.
Default Action : Allow
Default Policy : Balanced Security and Connectivity
Logging Configuration
DC : Disabled
Beginning : Disabled
End : Disabled
Rule Hits : 45894
Variable Set : Default Set
! The following two sections are the whitelist and blacklist from the global
threat
intelligence coming from Cisco.
=======[ Security Intelligence - Whitelist ]========
Name : Global Whitelist (List)
Zone : any
=======[ Security Intelligence - Blacklist ]========
Logging Configuration : Enabled
DC : Enabled
---------------------[ Block ]----------------------
Name : Malware (Feed)
Zone : any
Name : Tor_exit_node (Feed)
Zone : any
Name : Bogon (Feed)
Zone : any
Name : CnC (Feed)
Zone : any
Name : Global Blacklist (List)
Zone : any

195
 Name : Phishing (Feed)
Zone : any
! The following two main categories (admin_category and root_category)
are default
built-in rules
======[ Category: admin_category (Built-in) ]=======
=====[ Category: standard_category (Built-in) ]=====
------------------[ Rule: rule1 ]-------------------
Action : Block
Source Zones : myNewZone
Destination Zones : myNewZone
Logging Configuration
DC : Disabled
Beginning : Disabled
End : Disabled
Files : Disabled
Rule Hits :0
=======[ Category: root_category (Built-in) ]=======
===============[ Advanced Settings ]================
General Settings
Maximum URL Length : 1024
Interactive Block Bypass Timeout : 600
Network Analysis and Intrusion Policies
Initial Intrusion Policy : Balanced Severity and Connectivity
Initial Variable Set : Default Set
Default Network Analysis Policy : Balanced Security and Connectivity
Files and Malware Settings
File Type Inspect Limit : 1460
Cloud Lookup Timeout :2
Minimum File Capture Size : 6144
Maximum File Capture Size : 1048576
Min Dynamic Analysis Size : 15360
Max Dynamic Analysis Size : 2097152
Malware Detection Limit : 10485760
Transport/Network Layer Preprocessor Settings
Detection Settings
Ignore VLAN Tracking Connections : False
Maximum Active Responses : No Maximum
Minimum Response Seconds : No Minimum
Session Termination Log Threshold : 1048576

196
Detection Enhancement Settings
Adaptive Profile : Disabled
Performance Settings
Event Queue
Maximum Queued Events :5
Disable Reassembled Content Checks: False
Performance Statistics
Sample time (seconds) : 300
Minimum number of packets : 10000
Summary : False
Log Session/Protocol Distribution : False
Regular Expression Limits
Match Recursion Limit : Default
Match Limit : Default
Rule Processing Configuration
Logged Events :5
Maximum Queued Eve :8
Events Ordered By : Content Length
Latency-Based Performance Settings
Packet Handling
Threshold (microseconds) : 256
Rule Handling
Violations Before Suspending Rule : 3
Threshold (microseconds) : 512
Session Time : 10
! The following is the HTML code for the block response after a website or
web
resource is blocked.
============[ HTTP Block Response HTML ]============
HTTP/1.1 403 Forbidden
Connection: close
Content-Length: 506
Content-Type: text/html; charset=UTF-8
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<title>Access Denied</title>
<style type="text/css">body {margin:0;font-family:verdana,sans-serif;} h1
{margi

197
n:0;padding:12px 25px;background-color:#343434;color:#ddd} p
{margin:12px 25px;}
strong {color:#E0042D;}</style>
</head>
<body>
<h1>Access Denied<1>
<p>
<strong>You are attempting to access a forbidden site.</strong><br/><br/>
Consult your system administrator for details.
</p>
</body>
</html>
=============[ Interactive Block HTML ]=============
HTTP/1.1 200 OK
Connection: close
Content-Length: 869
Content-Type: text/html; charset=UTF-8
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8" />
<title>Access Denied</title>
<style type="text/css">body {margin:0;font-family:verdana,sans-serif;} h1
{margi
n:0;padding:12px 25px;background-color:#343434;color:#ddd} p
{margin:12px 25px;}
/head>g {color:#E0042D;}</style>
<body>
<h1>Access Denied</h1>
<p>
<strong>You are attempting to access a forbidden site.</strong><br/><br/>
You may continue to the site by clicking on the button below.<br/>
<em>Note:</em> You must have cookies enabled in your browser to
continue.</br><b
r/>
Consult your system administrator for details.<br/><br/>
<noscript><em>This page uses JavaScript. Your browser either doesn't
support
JavaScript or you have it turned off.<br/>
To continue to the site, please use a Javascript enabled browser.</em>

198
</noscript
>
</p>
</body>
</html>

Displaying the Network Configuration

A good way to display the network configuration in the Cisco ASA

FirePOWER module is by using the show network command, as shown in
Example 4-3.

Example 4-3 show network Command Output

Click here to view code image

Show> show network

===============[ System Information ]===============
Hostname : RTP-SF
Domains : cisco.com
DNS Servers : 208.67.222.222
Management port : 8305
IPv4 Default route
Gateway : 192.168.78.1
======================[ eth0 ]======================
State : Enabled
Channels : Management & Events
Mode :
MDI/MDIX : Auto/MDIX
MTU : 1500
MAC Address : 18:8B:9D:AD:79:C0
----------------------[ IPv4 ]----------------------
Configuration : Manual
Address : 192.168.78.2
Netmask : 255.255.255.0
Broadst : 192.168.78.255
----------------------[ IPv6 ]----------------------
Configuration : Disabled

199
===============[ Proxy Information ]================
State : Disabled
Authentication : Disabled

The show network command displays the system information, including the
module host name, configured domain name, DNS servers, management
port, and default gateway. It also provides the configured IPv4 and IPv6,
netmask, and broadcast addresses. It shows whether the management port is
enabled or disabled, as well as the interface MAC address, configured
MTU size, and other information.

To display the IPv4 and IPv6 routing table, you can use the show route
command, as shown in Example 4-4.

Example 4-4 Displaying the Routing Table

Click here to view code image

Show> show route

Kernel IP routing table
Destination Gateway Netmask Flags Metric Ref Use Iface
192.168.78.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
127.0.0.0 0.0.0.0 255.255.0.0 U 0 0 0 cplane
0.0.0.0 192.168.78.1 0.0.0.0 UG 0 0 0 eth0

Kernel IPv6 routing table

Destination Next Hop Flags Metric Ref Use Iface
::1/128 :: U 0 16 1 lo
fe80::200:ff:fe02:1/128 :: U 0 0 1 lo
fe80::1a8b:9dff:fead:79c0/128 :: U 0 0 1 lo
fe80::/64 :: U 256 0 0 cplane
fe80::/64 :: U 256 0 0 eth0
ff00::/8 :: U 256 0 0 cplane
ff00::/8 :: U 256 0 0 eth0

In Example 4-4 you can see that the IPv4 default gateway is set to
192.168.78.1, and the other two routes are the local networks assigned to
the management interface (eth0) and loopback address. In this example,

200
IPv6 is disabled, and you see only locally specific IPv6 information.

To display configured static routes, you can use the show network-static-
routes command.

The show ifconfig command provides similar output to the Linux ifconfig
command, as shown in Example 4-5.

Example 4-5 show ifconfig Command Output

Click here to view code image

Show> show ifconfig

cplane Link encap:Ethernet HWaddr 00:00:00:02:00:01
inet addr:127.0.2.1 Bcast:127.0.255.255 Mask:255.255.0.0
inet6 addr: fe80::200:ff:fe02:1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1480872 errors:0 dropped:0 overruns:0 frame:0
TX packets:248543 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:88914526 (84.7 Mb) TX bytes:22370811 (21.3 Mb)

eth0 Link encap:Ethernet HWaddr 18:8B:9D:AD:79:C0

inet addr:192.168.78.2 Bcast:192.168.78.255 Mask:255.255.255.0
inet6 addr: fe80::1a8b:9dff:fead:79c0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2562033 errors:0 dropped:0 overruns:0 frame:0
TX packets:284558 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuele1000
RX bytes:1123651792 (1071.5 Mb) TX bytes:102970664 (98.2 Mb)

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.255.255.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX pack:147207 errors:0 dropped:0 overruns:0 frame:0
TX packets:147207 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:59089295 (56.3 Mb) TX bytes:59089295 (56.3 Mb)

201
The output shown in Example 4-5 is very similar to the output of the
ifconfig command in most Linux operating systems. The highlighted lines
show the network configuration of eth0, which is the management interface.
A better way to display the interface configuration is to use the show
interfaces command, as demonstrated in Example 4-6.

Example 4-6 show interfaces Command Output

Click here to view code image

Show> show interfaces

! This is the outside interface of the ASA. It is associated with the "Internet"
security zone.
--------------------[ outside ]---------------------
Physical Interface : GigabitEthernet1/1
Type : ASA
Security Zone : Internet
Status : Enabled
Load Balancing Mode : N/A
! This is the inside interface of the ASA. It is associated with the
"myNewZone"
security zone.
---------------------[ inside ]---------------------
Physical Interface : GigabitEthernet1/2
Type : ASA
Security Zone : myNewZone
Status : Enabled
Load Balancing Mode : N/A
---------------------[ cplane ]---------------------
IPv4 Address : 127.0.2.1
! Ethernet 0 (eth0) is the management interface.
----------------------[ eth0 ]----------------------
Physical Interface : ethType : Management
Status : Enabled
MDI/MDIX : Auto
MTU : 1500
MAC Address : 18:8B:9D:AD:79:C0
IPv4 Address : 192.168.78.2

202
---------------------[ tunl0 ]----------------------
----------------------------------------------------

Monitoring Storage Usage

It is very important to monitor disk/storage usage by module to understand

the available resources. A good CLI command to use to monitor storage
usage and health is the show disk command. Example 4-7 shows an example
of the output generated by this command.

Example 4-7 show disk Command Output

Click here to view code image

Show> show disk

Filesystem Size Used Avail Use% Mounted on
/dev/root 3.7G 692M 2.9G 20% /
devtmpfs 1.7G 60K 1.7G 1% /dev
/dev/sda1 92M 35M 53M 40% /boot
/dev/vda7 65G 9.4G 53G 16% /var
none 1.7G 7.0M 1.7G 1% /dev/shm

The output shown in Example 4-7 includes a few columns: Filesystem

(partition), Used, Avail, Use%, and Mounted on. This is very similar to the
output of the df command in Linux.

You can run out of disk space on the Firepower Management Center, the
Firepower appliances, or the Cisco ASA FirePOWER Services module for
many different reasons. When this happens, the high disk utilization may
trigger a health alert or the system may fail a software update attempt.

Storing large volumes of old backup files on the system can take excessive
space on your disk. In order to correct this, delete the old backup files using
the web management interface under System > Tools > Backup/Restore.

Note

203
As a best practice, you can configure remote storage to store large backup
files.

The system may also run out of space if you always keep the previous
software update, upgrade, and patch files. To correct this, delete the older
update and patch files that are no longer necessary under System >
Updates.

You have to be careful not to oversubscribe the FMC—for instance, if the

module or any other managed device has stopped sending events to the FMC
or if a device is generating more events than the FMC is designed to receive
(per second). Also, if the FMC is unable to receive new IPS events, you
should check to see if there are any communication issues between the
managed device and the management center.

The root (/) partition is a fixed size and is not intended for personal storage.
If the root (/) partition is full, you should check for unnecessary files in the
/root, /home, and /tmp folders. Because these folders are not meant for
personal storage, you can delete any personal files in them by using the rm
command.

In ASDM, you can monitor the disk usage by navigating to Monitoring >
ASA FirePOWER Monitoring > Statistics, as shown in Figure 4-1.

204
Figure 4-1 ASDM FirePOWER Monitoring Statistics

Analyzing Running Processes

In ASDM, you can display and analyze all running processes much the way
you display process information in Linux: just navigate to Monitoring >
ASA FirePOWER Monitoring > Statistics, as shown in Figure 4-1. You
can obtain similar output by using the show processes command in the CLI,
as shown in Example 4-8.

Example 4-8 Displaying the Running Processes in the CLI

Click here to view code image

Show> show processes

PID USER PR NI VIRT RES SHR S %CPU
%MEM TIME+ COMMAND
4203 root 20 0 7964 2120 1024 S 4 0.1 5:02.35 pmmon.sh
4280 root 20 0 140m 7640 1260 S 4 0.2 293:38.98 diskmanager

205
4281 root 20 0 9388 952 700 S 4 0.0 269:27.89 UEChanneld
25195 sfsnort 1 -19 1042m 402m 20m S 4 11.6 15:03.18 snort
4323 root 0 -20 0 0 0 S 2 0.0 254:39.37 kvm_ivshmem_rxt
24135 admin 20 0 17376 1364 984 R 2 0.0 0:00.01 top
25194 sfsnort 1 -19 970m 387m 13m S 2 11 17:52.33 snort
1 root 20 0 4168 640 588 S 0 0.0 0:07.31 init
2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root RT 0 0 0 0 S 0 0.0 0:00.06 migration/0
4 root 20 0 0 0 0 S 0 0.0 0:.54 ksoftirqd/0
5 root RT 0 0 0 0 S 0 0.0 0:00.03 migration/1
6 root 20 0 0 0 0 S 0 0.0 0:12.69 ksoftirqd/1
7 root RT 0 0 0 0 S 0 0.0 0:00.06 migration/2
8 root 20 0 0 0 0 S 0.0 0:05.53 ksoftirqd/2
9 root RT 0 0 0 0 S 0 0.0 0:09.59 migration/3
10 root 20 0 0 0 0 S 0 0.0 0:15.40 ksoftirqd/3
11 root RT 0 0 0 0 S 0 0.0 0:11.04 migration/4
12 root 20 0 0 0 0 0 0.0 0:18.08 ksoftirqd/4
13 root RT 0 0 0 0 S 0 0.0 0:12.15 migration/5
14 root 20 0 0 0 0 S 0 0.0 0:19.53 ksoftirqd/5
<output omitted for brevity>

The show process command output shown in Example 4-8 is very similar to
the output of the ps command in Linux. Understanding what processes are
running on your system and what they are doing is important. You need to
know which processes are using the most memory and which ones are using
the most CPU. You also need to know how to find a particular process. A
key process is the snort process (highlighted in Example 4-8), which is the
IPS engine of the system.

You can also use the show process-tree command to show the processes in
a tree format that indicates which processes are dependent of each other, as
shown in Example 4-9.

Example 4-9 show process-tree Command Output

Click here to view code image

Show> show process-tree

206
init(1)-+-agetty(4199)
|-agetty(4200)
|-agetty(4201)
|-crond(2661)
|-klogd(2651)
|-login(20653)---clish(20656)-+-sh(24269)-+-more(24271)
| | '-pstree(24270)
| '-{clish}(20659)
|-nscd(14774)-+-{nscd}(14777)
| |-{nscd}(14778)
| |-{nscd}(14779)
| |-{nscd}(14780)
| |-{nscd(14781)
| '-{nscd}(14782)
|-pm(4214)-+-ASAConfig.pl(4269)
| |-ActionQueueScra(4277)
| |-CloudAgent(4289)-+-{CloudAgent}(4316)
| | |-{CloudAgent}(4317)
| | |-{CloudAgent}(4318)
| | '-{CloudAgent}(4319)
| |-Pruner.pl(4276)
| |-SFDataCorrelato(4272)-+-{SFDataCorrelato}(4375)
| | |-{SFDataCorrelato}(4376)
| | |-{SFDataCorrelato}(4377)
| | |-{SFDataCorrelato}(4380)
| | |-{SFDataCorrelato}(4382)
| | |-{SFDataCorrelato}(4384)
| | |-{SFDataCorrelato}(4387)
| | |-{SFDataCorrelato}(4469)
| | |-{SFDataCorrelato}(4470)
<output omitted for brevity>

The output shown in Example 4-9 is very similar to the output of the pstree
command in Linux. Example 4-9 shows running processes as a tree so that
you can see what processes are related to each other.

Using the System Log (Syslog)

The syslog is one of the most useful tools for troubleshooting problems you

207
might encounter in the Cisco ASA FirePOWER module. You can view the
syslog in ASDM by navigating to Monitoring > ASA FirePOWER
Monitoring > Syslog, as shown in Figure 4-2.

208
Figure 4-2 ASDM FirePOWER Syslog

You can also view real-time event information of all functions of the Cisco
ASA FirePOWER module by navigating to Monitoring > ASA
FirePOWER Monitoring > Real Time Eventing, as shown in Figure 4-3.
You can see all ASA FirePOWER events by selecting the All ASA
FirePOWER Events tab, as shown in Figure 4-3. You can also see events
related to connections passing through the module, intrusion, file inspection,
or malware file events and security intelligence events by selecting the
corresponding tabs. This screen also allows you to filter by many different
criteria.

209
Figure 4-3 ASDM FirePOWER Real Time Eventing

You can access very detailed logs by using the expert command to go into
the “expert” mode. This command brings you to a Linux prompt, as shown in
Example 4-10.

Example 4-10 Generating Detailed Logs with Expert Mode

Click here to view code image

Show> expert
admin@RTP-SF:~$ cd /
admin@RTP-SF:/$ ls
DBCheck.log boot dyn-preproc-upgrade-log lib mnt sbin upgraded
Volume cisco etc lib64 proc sys usr
Bin dev home lost+found root tmp var

While in expert mode, you can access many logs by changing directories to

210
/var/log/, as shown in Example 4-11.

Example 4-11 Accessing Detailed Logs in Expert Mode

Click here to view code image

admin@RTP-SF:~$ cd /var/log
admin@RTP-SF:/var/log$ ls
SMART_STATUS_sda_20160119050740.txt
action_queue.log
action_queue.log.1.gz
action_queue.log.2.gz
action_queue.log.3.gz
action_queue.log.4.gz
asacx_init.log
audit
btmp
cisco
configure-model.log
configure.log
configure.log.old
cron
cron.1.gz
cron.2.gz
cron.3.gz
cron.4.gz
diskmanager.log
dmesg
eth0.down.log
eth0.down.log.old
th0.up.log.old
faillog
firesight-query.log
firesight-query.log.1.gz
firesight-query.log.2.gz
firesight-query.log.3.gz
firesight-query.log.4.gz
firstboot.S01reset_failopen_if
firstboot.S03install-math-pari.sh

211
firstboot.S04fix-httpd.sh
firstboot.S05set-mgmnt-port
firstboot.6addusers
firstboot.S07uuid-init
firstboot.S09configure_mysql
firstboot.S10database
firstboot.S10database.15vulndb-init.log
firstboot.S12install_infodb
firstboot.S15set-locale.sh
<output omitted for brevity>

You can view each log by using the cat command. For example, to view the
scheduled tasks log, you can use the cat schedule_tasks.log command, as
shown in Example 4-12.

Instead of using the cat command, you can use the tail command, which is
basically the same as the Linux tail command. To view new log lines as they
are generated, you can use the tail -f command.

Example 4-12 Viewing the Scheduled Tasks Log

Click here to view code image

admin@RTP-SF:/var/log$ cat schedule_tasks.log

Jan 17 08:00:01 RTP-SF schedule_wrapper.pl[31159]: Starting run of task
2...
Jan 17 08:00:02 RTP-SF schedule_wrapper.pl[31159]: Task 2 should not
be run now. at
/usr/local/sf/bin/schedule_wrapper.pl line 217.
Jan 17 08:00:02 RTP-SF schedule_wrapper.pl[31159]: Ending run of task 2
().
Jan 17 08:00:02 RTP-SF schedule_wrapper.pl[31159]:
Jan 17 08:00:02 RTP-SF schedule_wrapper.pl[31159]:
Jan 17 09:00:02 RTP-SF schedule_wrapper.pl[2879]: Starting run of task
2...
Jan 17 09:00:03 RTP-SF schedule_wrapper.pl[2879]: Validating task 2...
Jan 17 0:00:03 RTP-SF schedule_wrapper.pl[2879]: VALIDATING 1 1 on
on at /usr/local/

212
 sf/lib/perl/5.10.1/SF/ScheduleTask/UpdateSRU.pm line 47.
Jan 17 09:00:03 RTP-SF schedule_wrapper.pl[2879]: Task 2 was validated
successfully.
Jan 17 09:00:03 RTP-SF schedule_wrapper.pl[2879]: Executing task ..
Jan 17 09:00:03 RTP-SF schedule_wrapper.pl[2879]: RUN UpdateSRU
task...
Jan 17 09:00:03 RTP-SF schedule_wrapper.pl[2879]: ---------------
Jan 17 09:00:03 RTP-SF schedule_wrapper.pl[2879]:
Jan 17 09:00:03 RTP-SF schedule_wrapper.pl[2879]:
https://support.sourcefire.com/
auto-upde/auto-dl.cgi/72:18:8B:9D:AD:79:C0/
Jan 17 09:00:03 RTP-SF schedule_wrapper.pl[2879]:
Jan 17 09:00:03 RTP-SF schedule_wrapper.pl[2879]:
https://support.sourcefire.com/
auto-update/auto-dl.cgi/72:18:8B:9D:AD:79:C0/GetCurrent/sf.xml--------
----------
Jan 17 09:00:03 RTP-SF schedule_wpper.pl[2879]:
Jan 17 09:00:03 RTP-SF schedule_wrapper.pl[2879]:
Jan 17 09:00:05 RTP-SF schedule_wrapper.pl[2879]: We have
SF::System::Md5Sum
--a8ebe509a002cbe7f26a3879eb553d85 ./Sourcefire_Rule_Update-
2016-01-13-002-vrt.
sh.
Jan 17 09:00:16 RTP-SF schedule_wrapper.pl[2879]: CaughSFSystem
Exception!
Jan 17 09:00:16 RTP-SF schedule_wrapper.pl[2879]: System
(/usr/local/sf/bin/
install_rule.pl /var/sf/SRU/Sourcefire_Rule_Update-2016-01-13-002-
vrt.sh) Failed
at /usr/local/sf/lib/perl/5.10.1/SF/System/Privileged.pm line 2636.
Jan 17 09:00:16 RTP-SF schedule_wrapr.pl[2879]:
Jan 17 09:00:16 RTP-SF schedule_wrapper.pl[2879]: Request stdout!
Jan 17 09:00:16 RTP-SF schedule_wrapper.pl[2879]: The package is
/var/sf/SRU//var/
sf/SRU/Sourcefire_Rule_Update-2016-01-13-002-vrt.sh
Jan 17 09:00:16 RTP-SF schedule_wrapper.pl[2879]: Verifying archive
egrity... All
good.
<output omitted for brevity>

213
Monitoring and Troubleshooting System Tasks

You can display complete, pending, or failed jobs (system tasks) by

navigating to Monitoring > ASA FirePOWER Monitoring > Task Status,
as shown in Figure 4-4.

214
Figure 4-4 ASDM FirePOWER Task Status

This screen is useful for viewing and troubleshooting problems with

specific tasks, such as intrusion policy tasks, access policies, device update
downloads and installations, and more.

Generating Advanced Troubleshooting Logs

You can use the system generate-troubleshoot command to generate very

advanced and detailed logs that can be used for troubleshooting, as shown
in Example 4-13.

Example 4-13 The system generate-troubleshoot Command

Click here to view code image

> system generate-troubleshoot

One or more subset options required. Displaying list of options:
ALL - Run ALL Of The Following Options

215
SNT - Snort Performance and Configuration
PER - Hardware Performance and Logs
SYS - System Configuration, Policy, and Logs
DES - Detection Configuration, Policy, and Logs
NET - Interface and Network Related Data
VDB - Discovery,wareness, VDB Data, and Logs
UPG - Upgrade Data and Logs
DBO - All Database Data
LOG - All Log Data
NMP - Network Map Information

Example 4-14 demonstrates the use of the all keyword to generate logs for
all the aforementioned options.

Example 4-14 system generate-troubleshoot all Command Output

Click here to view code image

> system generate-troubleshoot all

Starting /usr/local/sf/bin/sf_troubleshoot.pl...
Please, be patient. This may take several minutes.
The troubleshoot option code specified is ALL.
Troubleshooting information successfully created at /var/common/
results-01-22-2016--184950.tar.gz

The system generate-troubleshoot all command can take several

minutes to run, as the warning message in Example 4-14 indicates. This
command generates and collects an incredible number of logs that are
extremely useful for troubleshooting many problems.

After the command finishes and stores all the logs, you can then transfer the
archive to your local machine or to an admin server using secure copy
(SCP), as shown in Example 4-15.

Example 4-15 Transferring Troubleshooting Logs to a Local

Machine/Admin Server

Click here to view code image

216
System> system file secure-copy omar.cisco.com omar dest_dir
/var/common/
results-01-22-2016--184950.tar.gz
The authenticity of host 'omar.cisco.com (172.18.104.139)' can't be
established.
ECDSA key fingerprint is
9b:f1:b2:62:04:65:be:29:94:af:09:9a:04:50:2c:0a.
Are you sure you want to continue connecting (yes/no)? yes
[email protected]'s password:*******************
copy successful.

You can also generate the troubleshooting files in ASDM by navigating to

Configuration > ASA FirePOWER Configuration > Tools >
Troubleshooting, as shown in Figure 4-5.

217
Figure 4-5 Generating Troubleshooting Files in ASDM

Sometimes you may run into trouble when trying to determine what access
control rule is blocking or allowing traffic. The restricted shell in the
Firepower software provides a utility that can help you determine the status
of each flow as the system receives packets in real time. You can invoke this
utility by using the system support firewall-engine-debug command, which
prompts you to enter the following information:

IP protocol, either TCP or UDP

Client IP

Client port

Server IP

Server port

Example 4-16 shows output from the system support firewall-engine-

debug command after you enter the required information.

218
Example 4-16 system support firewall-engine-debug Command Output

Click here to view code image

10.10.10.123-33533 and 10.20.20.21-80 6 Starting VLan first with intfs 2 -

> 1, vlan
0, svc 0, payload 0, client 0, misc 0, user 0, url
10.10.10.123-33533 and 10.20.20.21-80 6 pending rule order 1, 'Block
social media',
URL
10.10.10.123-33533 and 10.20.20.21-80 6 Starting VLan first with intfs 2 -
> 1, vlan
0, svc 0, payload 0, client 0, misc 0, user 0, url
10.10.10.123-33533 and 10.20.20.21-80 6 pending rule order 1, 'Block
social media',
URL
10.10.10.123-33533 and 10.20.20.21-80 6 Starting VLan first with intfs 2 -
> 1, vlan
0, svc 0, payload 0, client 0, misc 0, user 0, url
10.10.10.123-33533 and 10.20.20.21-80 6 pending rule order 1, 'Block
social media',
URL
10.10.10.123-33533 and 10.20.20.21-80 6 Starting VLan first with intfs 2 -
> 1, vlan
0, svc 676, payload 629, client 638, misc 0, user 0, url http://cisco.com/
10.10.10.123-33533 and 10.20.20.21-80 6 match rule order 1, 'Block social
media',
action Block

The Cisco ASA drops packets if they are not compliant with the enterprise’s
configured security policy or if something is wrong in the system. These
drops could be related to the deny statements in the ACLs, illegitimate VPN
packets, a malformed TCP segment, or a packet with invalid header
information. In some cases, you will want to get the statistical information
about the packets or connections dropped by the security appliance within
its accelerated security path (ASP). You can use the show asp drop ASA
command to view the reasons that a packet was dropped, as shown in
Example 4-17.

219
Example 4-17 show asp drop Command Output

Click here to view code image

ASA# show asp drop

Frame drop:
No route to host (no-route) 618
Interface is down (interface-down) 4
Last clearing: Never
Flow drop:
Last clearing: Never

The highlighted lines in Example 4-17 shows that the frame was dropped
because there was no route to the destination. In this case, it was because
the egress interface was down.

Useful ASA Debugging Commands

A few debugging commands in the Cisco ASA are useful when you’re
troubleshooting problems with the module. The following are the most
popular ones:

debug sfr error: Used to display errors related to the Cisco ASA
FirePOWER module

debug sfr event: Used to display general events related to the Cisco ASA
FirePOWER module

debug sfr message: Used to display hardware messages between the

Cisco ASA and the module

Example 4-18 shows the output of the debug sfr event command.

Example 4-18 Debugging Module Events

Click here to view code image

ASA-1# debug sfr event

220
debug sfr event enabled at level 1
ASA-1# debug sfr event
DP SFR Event: Sending Conn Unique ID (3790083) TLV for
192.168.78.2/123 -
184.105.192.247/123
DP SFR Event: Sending Conn Unique ID (3790084) TLV for
192.168.78.138/59782 -
204.141.57.101/443
DP SFR Event: Sending Conn Unique ID (3790085) TLV for
192.168.78.132/27646 -
208.67.222.222/53
DP SFR Event: Sending Conn Unique ID (3790086) TLV for
192.168.78.132/49148 -
173.194.206.95/443
DP SFR Event: Sending Conn Unique ID (3790089) TLV for
192.168.78.132/12363 -
208.67.222.222/53
DP SFR Event: Sending Conn Unique ID (3790090) TLV for
192.168.78.132/37421 -
74.125.228.243/443
DP SFR Event: Sending Conn Unique ID (3790093) TLV for
192.168.78.135/777 -
8.8.8.8/0
<output omitted for brevity>

Summary

In this chapter, you have learned about several commands and utilities that
are useful when troubleshooting problems in the Cisco ASA FirePOWER
module. These commands are also useful when you’re troubleshooting
problem in FTD software. You have learned how to perform basic
monitoring, and you have learned how to use expert-level commands to
view and analyze detailed logs in the module. You have also learned how to
generate detailed troubleshooting files in the CLI and in ASDM. You have
also learned about the available debugging commands in the ASA for
troubleshooting problems in the module.

221
Chapter 5. Introduction to and Architecture of
Cisco AMP
This chapter covers the following topics:

The architecture, components, and types of AMP

The AMP public cloud architecture

The AMP private cloud architecture

AMP private cloud air gap mode

This chapter provides an introduction to the Cisco Advanced Malware

Protection (AMP) solution, the AMP architecture, and AMP cloud types.

Introduction to Advanced Malware Protection (AMP)

In Chapter 1, “Fundamentals of Cisco Next-Generation Security,” you

learned about the different Cisco next-generation security products and
technologies. You learned that those security technologies and processes
should not only focus on detection but also should provide the capability to
mitigate the impact of an attack. Organizations must maintain visibility and
control across the extended network during the full attack continuum:

Before an attack takes place

During an active attack

After an attacker starts to damage systems or steal information

In Chapter 1 you also learned about the many different types of malicious
software (malware). The AMP solution enables you to detect and block
malware, continuously analyze for malware, and get retrospective alerts. It
has the following features:

File reputation: AMP allows you to analyze files inline and block or
apply policies.

222
 File sandboxing: AMP allows you to analyze unknown files to understand
true file behavior.

File retrospection: AMP allows you to continue to analyze files for

changing threat levels.

There are major architectural benefits to the AMP solution, which leverages
a cloud infrastructure for the heavy lifting.

The architecture of AMP can be broken down into three main components:
the AMP cloud, AMP client connectors, and intelligence sources. AMP
client connectors include AMP for Networks, AMP for Endpoints, and AMP
for Content Security.

Figure 5-1 illustrates the cloud architecture, showing how AMP receives
intelligence from many sources and a variety of client connectors.

Figure 5-1 AMP Architecture

The AMP cloud contains many different analysis tools and technologies to
detect malware in files, including the Threat Grid analysis solution. Cisco’s
research teams, including the Cisco Talos security intelligence and research
group, feed information about malware into the AMP cloud. Threat
intelligence from Cisco products, services, and third-party relationships is

223
also sent to the AMP cloud. The following are some examples:

Snort, ClamAV, and Immunet AV open source communities: Users of

these open source projects contribute threat information daily.

Talos: The Cisco Talos security intelligence and research group is a team
of leading threat researchers that contributes to the threat information
ecosystem of Cisco security products. Talos team members get threat
information from a variety of sources and their own internal research
efforts. Talos maintains the official rule sets of Snort.org, ClamAV,
SenderBase.org, and SpamCop. Talos is also the primary team that
contributes to the Cisco Collective Security Intelligence (CSI) ecosystem.
You can follow Talos on Twitter @talos and subscribe to the official Talos
blog at http://blogs.cisco.com/author/talos.

Threat Grid: This deep threat analysis solution leverages many

identification techniques, including sandboxing. Threat Grid is built as a
cloud architecture and is used to do deep analysis of file samples submitted
to the AMP Threat Grid cloud. The analysis results are fed into the AMP
cloud and can be used to update file disposition (the result).

Over 100 TB of threat intelligence data daily: A variety of sources

contribute to the vast amount of data provided to Cisco through submitted
malware samples, data from the web, and email traffic monitored by Cisco
products and other third-party sources.

1.6 million global sensors: Cisco has programs designed to foster

cooperation and information sharing of threat intelligence data. Cisco
therefore has access to data from more than 1.6 million sensors worldwide.

Advanced Microsoft and industry disclosures: Cisco has cooperative

relationships with many industry-leading vendors of software products that
yield advanced information about vulnerabilities and threats. AMP
customers benefit from access to the vast amount of information gathered by
Cisco through quick release of signature updates and threat protection.

Role of the AMP Cloud

The most critical item of the Cisco AMP architecture is the AMP cloud
itself. The AMP cloud has two deployment methods—public and private—

224
and regardless of the deployment chosen, the role of the cloud is the same.

The AMP cloud houses all the detection signatures. A major benefit of
storing these signatures in the cloud is that it reduces the client connector
size and reduces the processing requirements on the client, since the bulk of
the work is handled in the cloud.

An interesting and fairly unique feature is that AMP administrators can

create custom signatures in the cloud, and then those custom signatures are
pushed to the connectors. In addition, the cross-referencing of files and
signatures is done in the AMP cloud, so the cloud can be self-updating,
without having to constantly communicate updates to the connectors.

The AMP cloud is also responsible for large-scale data processing, or big
data. The data comes to the AMP cloud from multiple sources, including
honeypots, threat feeds, open source communities, AV solutions such as
Immunet AV and ClamAV, and more. File samples are provided to the AMP
cloud, where they are processed. If the disposition of a sample file is
deemed to be malicious, it is stored in the cloud and reported to the client
connectors that see the same file.

Note

AMP customer data is never shared with any other entity.

Advanced analytic engines, including Threat Grid, are part of the AMP
cloud and are constantly correlating the incoming data. The analytical
results are used to update the AMP signatures. In addition to the advanced
analytics, machine-learning engines are employed to further refine
signatures and reevaluate detections that have already been performed. The
cloud is not just a repository of signatures; the decision making is performed
in real time, evolving constantly based on the data received.

Doing Security Differently

There is this brilliant engineer from Cisco SourceFire named Eric Howard.
Eric is one of the world’s foremost experts in AMP, and he presents
security, particularly the AMP solution, in a unique way that brings
tremendous clarity. This section of the book is designed to mirror his
presentation style.

225
Eric talks about the need to “do security differently.” He says that
companies need two security plans: Security Plan A is prevention, and
Security Plan B is retrospection.

The Prevention Framework

Prevention involves keeping malware at bay. With prevention, speed is

critical. It requires real-time, dynamic decisions to be made from real-
world data. The data must have high accuracy, with low false positives and
false negatives. Prevention could also be viewed as the “security control
mode.”

As illustrated in Figure 5-2, the AMP cloud’s prevention framework is

made up of seven core components: 1-to-1 signatures, Ethos, Spero,
indicators of compromise (IOCs), device flow correlation, advanced
analytics, and dynamic analysis.

Figure 5-2 The Protection Framework

1-to-1 Signatures

1-to-1 signatures are a traditional technology that is used all over the
security industry in various forms. With these signatures, a hash is created of
a file, and that hash is compared to a database. If a match is found, the
specific file is known, and a verdict—clean or malicious—is returned. If
the hash has not been seen before, the cloud returns a verdict of unknown.
The benefit of this method is that it can quickly identify and block malicious
files. The downside is that a simple change to a file also changes the hash,
thereby evading the signature.

AMP differentiates itself from other 1-to-1 signature solutions by storing the
signature database in the cloud instead of on the client. The database is quite
large, and many solutions cut corners by including only a subset of the
signatures in the full database. Storing the database in the cloud allows
AMP to leverage the entire database. Comparing the files to the database

226
can be quite resource intensive. AMP does the comparison in the cloud,
freeing those resources from the client connector. AMP is also able to
collect, process, and detect in near real time.

Ethos Engine

The next component of the protection framework is the Ethos engine. Ethos
is a “fuzzy fingerprinting” engine that uses static or passive heuristics. The
engine creates generic file signatures that can match polymorphic variants of
a threat. This is useful because when a threat morphs or a file is changed,
the structural properties of that file often remain the same, even though the
content has changed.

Unlike most other signature tools, Ethos uses distributed data mining to
identify suitable files. It uses in-field data for sources, which provides a
highly relevant collection from which to generate the signatures. Ethos is
completely automated and provides rapid generation of the generic
signatures that are based on in-field data instead of relying on individual
“rockstar” engineers to generate a limited number of generic signatures.

Note

At this writing, Ethos applies only to AMP for Endpoints.

Spero Engine

Spero is a machine learning–based technology that proactively identifies

threats that were previously unknown. It uses active heuristics to gather
execution attributes, and because the underlying algorithms come up with
generic models, it can identify malicious software based on its general
appearance rather than based on specific patterns or signatures.

Indicators of Compromise

If you look up “indicator of compromise” on Wikipedia

(http://en.wikipedia.org/wiki/Indicator_of_compromise), this is what you
see: “an artifact observed on a network or in an operating system that with

227
high confidence indicates a computer intrusion.”

There may be artifacts left on a system after an intrusion or a breach, and

they can be expressed in a language that describes the threat information,
known as indicators of compromise (IOCs). The sets of information
describe how and where to detect the signs of the intrusion or breach. IOCs
can be host-based and/or network-based artifacts, but the scan actions are
carried out on the host only.

IOCs are very high-confidence indicators, and they may describe numerous
specific items, including FileItem, RegistryItem, EventLogItem,
ProcessItem, and ServiceItem. You can lean the IOC language in more detail
at http://www.openioc.org.

Figure 5-3 shows an example of an IOC.

Figure 5-3 Example of an Indicator of Compromise

228
Device Flow Correlation

Device flow correlation provides a kernel-level view into network I/O. It

allows for blocking or alerting on network activity, traced back to the
initiating process itself. It enables internal and external networks to be
monitored, leverages IP reputation data, and offers URL/domain logging.
The flow points are extra telemetry data and are not file disposition
specific.

Cisco provides intelligence on many malicious destinations, including

generic command and control (CnC) servers, phishing hosts, zero-access
CnC servers, and more.

Advanced Analytics

Advanced analytics consists of a set of multifaceted engines that provide big

data context beyond a single host and beyond a single file. Advanced
analytics highlights files executed in an environment, from least common to
most. This can aid in identifying previously undetected threats that may have
only been seen by a small number of users.

Dynamic Analysis with Threat Grid

Cisco AMP Threat Grid is not a single tool. It is a full solution for dynamic
malware analysis and threat intelligence. It performs high-speed, automated
analysis with adjustable runtimes while not exposing any tags or other
indicators that malware could use to detect that it is being observed.

Threat Grid provides video playbacks, a glovebox for malware interaction

and operational troubleshooting, a process graph for visual representation
of process lineage, and a threat score with behavior indicators.

It searches and correlates all data elements of a single sample against

billions of sample artifacts collected and analyzed over years, leveraging
global and historic context. This enables an analyst to better understand the
relevancy of a questionable sample as it pertains to the analyst’s own
environment.

Threat Grid was architected from the ground up as a cloud solution with an
API designed to integrate with existing IT security solutions and to create

229
custom threat intelligence feeds. It can automatically receive submissions
from other solutions and pull the results into your environment.

Many think that Threat Grid is a sandboxing solution. It is much more than
just that, however; sandboxing is a piece of the solution, and Threat Grid’s
sandboxing functions are performed in a way that evades detection by
malware. Threat Grid uses an outside-in approach, with no presence in the
virtual machine. The sandboxing’s dynamic analysis includes an external
kernel monitor, dynamic disk analysis that illuminates any modifications to
the physical disk (such as the master boot record), monitoring user
interaction, video capture and playback, process information, artifacts, and
network traffic.

Threat Grid supports the following samples and object types:

Executable files (.EXE) and libraries (.DLL)

Java archives (.JAR)

Portable document format (.PDF)

Office documents (.RTF, .DOC, .DOCX, .XLS, .XLSX, .PPT, .PPTX)

ZIP containers (.ZIP)

Quarantine containers

URLs

HTML documents

Flash

Note

At this writing, Threat Grid is a key part of the Cisco AMP cloud, but it is
not yet available as part of the private cloud (local/onsite) offering.

The Retrospective Framework

230
Retrospection means taking a look at what has already transpired; it
involves tracking system behavior regardless of disposition, focusing on
uncovering malicious activity. Retrospection could be viewed as the
“incident response mode,” using continuous analysis to reactively act on a
file that was assigned a clean disposition once but was later found to have a
bad disposition.

The retrospective framework is designed to show the trajectory of a

malicious file, with a goal of 30 days of telemetry data, as illustrated in
Figure 5-4. Even files that are originally given a clean verdict are tracked,
and if a clean file is later found to be malicious, all connectors that have
seen the file are notified to quarantine the file retrospectively.

Figure 5-4 Trajectory Illustrated

The Cloud

As you will see throughout this book, the AMP cloud is the centralized
location for all management and reporting. Figure 5-5 shows an example of
an AMP cloud dashboard. The dashboard shows indicators of compromise
and allows you to drill into them.

From the dashboard, you can provision endpoints, download agents, run
reports, and more.

231
Figure 5-5 Example of an AMP Cloud Dashboard

Private Cloud

The AMP cloud is available in a private version. Administrators can run

their own private cloud with many of the features from the public cloud, but
not all. With the private offering, you may choose to host all components
within your own data center or perhaps in another cloud environment, like
Cisco’s InterCloud or Amazon Web Services (AWS).

The option to host the AMP cloud in your own data center is often selected
by organizations that reside outside the United States and have very strict
controls on where data may reside. In addition, some organizations, such as
government agencies, have requirements for data storage being on premises.

The private cloud product is shipped as a virtual machine that you can run in
your own VMware environment. The private cloud may be operated in two
ways: in cloud proxy mode and in air gap mode.

Note

At this writing, the private cloud is available only for AMP for Endpoints

232
and AMP for Networks. In addition, support of Threat Grid with the private
cloud is planned but not yet available.

Cloud Proxy Mode

Cloud proxy mode operates the private cloud within the confines of your
own data center or other cloud infrastructure. The AMP for Networks and
AMP for Endpoints connectors all communicate to the private cloud.
However, the private cloud maintains a connection to the public cloud for
certain communications:

File disposition checks: File disposition is still determined by the public

cloud. The file hashes are passed on to the public cloud over an SSL session
using TCP port 443 or TCP port 32137. The public cloud is known as the
upstream server, and the FQDN that you connect to is cloud-
pc.amp.sourcefire.com.

Product updates: The AMP private cloud can be configured for automatic
or manual updates, leveraging a yum repository named
packages.amp.sourcefire.com that uses an SSL session over TCP port 443.

Support: Cisco TAC is able to remotely access the device for diagnostic
purposes and customer assistance. The remote access uses SSH over TCP
port 443.

Figure 5-6 illustrates the cloud proxy mode.

233
Figure 5-6 Private Cloud Proxy Mode

Air Gap Mode

As its name indicates, air gap mode creates a private cloud instance that is
completely isolated and has no external access to the public cloud. Updates
must be completed manually, and remote support is challenging. However,
this mode provides the highest levels of confidentiality. Figure 5-7
illustrates air gap mode.

234
Figure 5-7 Private Cloud Air Gap Mode

Installing the Cisco AMP Private Cloud

The AMP private cloud is available as an Open Virtualization Archive

(.ova) format file, for import into a VMware virtual environment. At this
writing, the only supported virtual environment for the private cloud is
VMware ESX 5 or newer. Unofficially, however, the virtual appliance
works on VMware Fusion and VMware Workstation, though this is
unsupported.

Installing the private cloud in air gap mode requires more resources than the
cloud proxy mode installation. These are the minimum requirements:

Cloud proxy mode: 32 GB RAM, 8 CPUs, 238 GB minimum free disk

space

Air gap mode: 128 GB RAM, 8 CPUs, 1 TB minimum free disk space

After you deploy the OVA template, you connect to the console of the VM in
order to configure the private cloud, as shown in Figure 5-8. You need to
configure the network so the private cloud configuration can be completed
through its web interface.

235
Figure 5-8 DHCP or Static IP

DHCP is required if you will be installing in demo mode, while a static IP

address and external DNS servers are required for a production install. You
need to click No and provide valid IP stack information, as shown in
Figures 5-9 and 5-10.

Figure 5-9 DHCP or Static IP

236
Figure 5-10 Static IP Interface Configuration

You then click Yes to apply the changes to the interface, as shown in Figure
5-11. The main menu returns, with a randomized password that you use to
administer the private cloud through the web interface, as shown in Figure
5-12.

Figure 5-11 Applying Your Interface Configuration

237
Figure 5-12 AMP Private Cloud Device Management

Connect to your private cloud with a web browser using HTTPS, as shown
in Figure 5-13, and log in with a random password such as the one
displayed in Figure 5-12.

Figure 5-13 Logging into the AMP Private Cloud Web Interface

Once you have successfully logged in, you are prompted to change the one-

238
time password that the system generated, as shown in Figure 5-14, and then
you have to accept the license agreement, shown in Figure 5-15. If you step
away from the browser for an extended period of time, it times out, and you
need to log in with the newly set password of your choosing instead of the
one-time system-generated password.

Figure 5-14 Changing the Password

Figure 5-15 Accepting the License Agreement

At this point, you can restore a previously backed up private cloud or

proceed with a clean installation. To install a new private cloud, you click
Start for a clean installation, as shown in Figure 5-16.

239
Figure 5-16 Choosing a Clean Installation or to Restore from Backup

You are now prompted to choose between air gap and cloud proxy mode, as
shown in Figure 5-17. Cloud proxy mode requires an Internet connection to
send disposition queries to the public cloud and to receive content updates
as well as software updates, as described earlier in this chapter.

240
Figure 5-17 Cloud Proxy Mode or Air Gap Mode

Next, you choose the installation type. In this case, you can choose demo
mode, which requires DHCP to be used rather than a static IP address.
Demo mode also skips some of the installation requirements, so it can be
installed on a laptop or other smaller VM host.

In order to see all the installation options, you click Next under Production,
as shown in Figure 5-18.

241
Figure 5-18 Choosing the Demo or Production Installation Type

For a production installation, a license file is required. Click Browse to

locate the license file, enter the passphrase to decrypt the key, and then click
Upload, as shown in Figure 5-19. The license is then installed.

242
Figure 5-19 Uploading the License File

Next, you are asked to create a console account, which you use to initially
log into the cloud, create additional accounts, and set up groups. Create your
console account and password and click Next, as shown in Figure 5-20.

243
Figure 5-20 Creating the Console Account

After creating the console account, you see a summary screen for your
storage capabilities. There are two main tabs: Automatic Configuration and
Manual Configuration. The automatic configuration adjusts partition sizes
based on the number of connectors that you configure the cloud for and the
number of days of history that you wish to retain. Figure 5-21 shows the
automatic configuration screen. With this mode, you simply state the number
of connectors to plan for and the number of days to store the data. The
connectors are the endpoints or network AMP devices that will be using this
private cloud. Warnings appear for any misconfigurations where not enough
storage is available.

244
Figure 5-21 Automatic Configuration of Storage

As shown in Figure 5-22, the manual configuration gives you more control,
and you can determine how much space to allocate for each of the
collections (archives, default, documents, executables, events, and DFC).
Again, warnings appear for any misconfigurations where not enough storage
is available.

245
Figure 5-22 Manual Configuration of Storage

Note

If you manually misconfigure the file system and the database grows too
large for the disk partition, you will need to do a full backup, reinstallation,
and restoration in order to change the partition sizes. Therefore, it is
recommended that you use the automatic option.

The next screen is the Network Configuration page. The top half of the

246
screen is fairly self-explanatory. Here you see the administrative portal
being hosted on the interface (eth0) and the IP address that you configured at
the command line. What is new here is that the second interface (eth1) needs
to be configured. The eth1 interface is known as the production interface
and is used to connect to the Internet for updates, communication with the
public cloud, and communication with all the connectors (endpoints and
network AMP systems).

Figure 5-23 shows the VMware configuration, where you can see two
network adapters. Both NICs can be on the same network segment, as shown
in Figure 5-23. They do not have to be in the same VLAN, but they can be.
Figure 5-24 shows the top half of the network configuration page, with both
eth0 and eth1 configurations displayed.

Figure 5-23 VMware Configuration Showing Two NICs

247
Figure 5-24 Top Portion of the Network Configuration Page

With the eth1 configuration complete, you come to a rather confusing part of
the setup. You need to enter two required fully qualified domain names
(FQDNs) and one optional one. What confuses people with this portion of
the setup is that the FireAMP Console FQDN, the Cloud Server FQDN, and
the Defense Center FQDN are all referring to exactly the same host—the
host that you are currently configuring. That’s right: You need to have two or
three entries in DNS that all point to the IP address configured for the eth1
interface, as shown for the DNS server displayed in Figure 5-25.

Figure 5-25 DNS A Records for the FQDNs

You need to enter these FQDNs into the corresponding fields of the
configuration screen, as shown in Figure 5-26. When you are sure that the
names exist correctly in both the DNS server and the configuration screen,
click Next (Applies Configuration) to move on.

248
Figure 5-26 Lower Portion of the Network Configuration Page

Note

The endpoints and the private cloud need the ability to resolve these DNS
names. If the endpoints cannot resolve these names, they will fail to register
to the cloud.

When the network configuration is complete, the next step is to select which
upstream cloud should be used, along with the port and security settings
related to that cloud connection, as shown in Figure 5-27.

249
Figure 5-27 Cloud Server Configuration

The upstream server selection can be either the North American cloud, the
European cloud, or a custom cloud name, as shown in Figure 5-28.

Figure 5-28 Upstream Cloud Server Selection Choices

250
Note

The custom server is not used in the majority of deployments because it is

designed for multitiered private cloud deployments, which are rare.

There are no geographical requirements for the upstream public cloud

infrastructure. The cloud server selection that you make should be based on
latency: Choose the one with the lowest latency. The next drop-down is the
protocol selection: either SSL (TCP port 443) or TCP (port 32137). Cisco
best practice is to use TCP port 32137 because the communication is
already encrypted and the SSL port adds additional overhead and uses more
bandwidth. Figure 5-29 shows the drop-down choices.

Figure 5-29 Protocol Selection

The cloud server identity section shown in Figure 5-27 and Figure 5-29 lists
this AMP cloud server’s unique identity and the certificates that represent
this cloud server’s identity for any downstream private clouds.

Click Next to move on from the cloud server configuration and set up a
recipient or recipients of administrative email notifications, as shown in
Figure 5-30. The emails may contain notices of low disk space, backup
success or failure, failed sanity checks, and more items of this nature.

251
Figure 5-30 Setting Notifications

Date and time configuration is next. Network Time Protocol (NTP) plays a
critical role in all network security solutions, ensuring time accuracy and
synchronization. It ensures that log entries will always be accurate and
provide valid, useful reports. All events are stored in UTC time, so
selecting a time zone is not necessary. The time zone will be adjusted upon
display to the console UI, so the admin is not stuck working in UTC. Figure
5-31 shows the date and time configuration screen.

252
Figure 5-31 Setting Date and Time

Note

NTP updates occur through the public interface (eth1), allowing you to
choose an NTP source on the public Internet, if that is preferred.

The next screen is for a recovery file. A recovery file is like a backup, and
it contains all the cloud configuration and the server keys shown in Figure
5-27. You should store the recovery file in a very safe location because if
you lose the recovery key, you will never be able to restore your
configuration. In addition, every one of your FireAMP connectors will need
to be reinstalled. In other words, without the original key, you have to
reinstall the private cloud infrastructure with all new keys.

To complete this step, simply download the backup file through your
browser by clicking the blue Download button (see Figure 5-32) and save
the pre-install-backup.tgz file to your local disk. Then upload it right back to
the server by clicking the Browse button on the same page. You can click

253
Next and proceed with the installation after the file is validated.

Figure 5-32 Setting Up Recovery

Finally, you see the Review and Install screen, as shown in Figure 5-33.
This is your last chance to review all the configuration options before you
install. When you are certain you have selected all the correct options, click
Start Installation, and the installation proceeds, with a status screen like
the one shown in Figure 5-34.

254
Figure 5-33 Review and Install

255
Figure 5-34 Installing the Device

As the screen warns, you should leave your browser on the page and not try
to refresh it manually. As the installation finishes, it sends an email
notification like the one shown in Figure 5-35.

256
Figure 5-35 Email Notification

When the installation is complete, the Reboot button becomes active (see
Figure 5-36). Click Reboot when the process finishes to reboot the
appliance, and the server reboots and displays the message shown in Figure
5-37.

257
Figure 5-36 Successful Installation

Figure 5-37 Rebooting

After the appliance reboots, the web interface for the administrative
interface (eth0) that you were using to configure the appliance displays key
metrics like those shown in Figure 5-38.

258
Figure 5-38 Key Metrics

Now you can connect to the web interface for the eth1 interface by
connecting to the console FQDN that you configured, as shown in Figure 5-
39. You log in using the console account you created during the setup
process.

259
Figure 5-39 Login Screen

The subscription agreement is displayed next. Scroll to the bottom and

select the check box, as shown in Figure 5-40, and click Continue.

260
Figure 5-40 Subscription Agreement

After logging in, you are presented with a setup wizard to configure your
first policies for Windows or Mac AMP connectors. The endpoint policies
are examined in more detail in Chapter 8, “Cisco AMP for Endpoints.”

Summary

In this chapter you have learned all about the role of the AMP cloud for
performing file disposition checks. You have learned about the intelligence
that feeds the AMP cloud and the AMP view of security as including a
prevention framework and a retrospection framework. You have learned
about public and private clouds and seen how to complete an installation of
a private cloud instance.

261
Chapter 6. Cisco AMP for Networks
This chapter dives into the Advanced Malware Protection (AMP) for
Networks connector. The following topics are covered in this chapter:

How AMP for Networks fits in the AMP architecture

The functions of AMP for Networks

The components and configuration of malware and file policies

The types of files and what actions are available for them

Introduction to Advanced Malware Protection (AMP) for

Networks

The network is the best place to see across an organization, uncover, and
discover. It provides unprecedented visibility to activity at a macro-
analytical level. However, to remediate malware, you need to be on the
host. This is why AMP has the following connectors: AMP for Networks,
AMP for Endpoints, and AMP for Content Security Appliances.

What Is That Manager Called, Anyway?

While the AMP connectors are installed differently and act in different
places in networks, they all speak to the AMP clouds. In addition, AMP for
Networks and AMP for Endpoints connectors share a common management
platform that has gone by a few different names since Cisco acquired
SourceFire. Thanks to the acquisition and the branding strategy from Cisco,
you might see the management center being referred to as SourceFire
Defense Center (SFDC), Cisco FireSIGHT Management Center (FMC), or
even Cisco Firepower Management Center (FMC). At this writing, the latest
and hopefully final name for the management system is Cisco Firepower
Management Center (FMC).

Form Factors

You can install AMP for Networks on any Cisco FirePOWER security

262
appliance right alongside the firewall and IPS; however, there are dedicated
AMP appliances as well. When it comes down to it, though, AMP
appliances and FirePOWER appliances are actually the same. They can all
run all the same services. Are you thoroughly confused? Stated a different
way, Cisco AMP for Networks is the AMP service that runs on an appliance
that is examining traffic flowing through a network. It can be installed in a
standalone form or as a service on a FirePOWER IPS or even a Cisco ASA
with FirePOWER Services.

At this writing, the AMP appliance lineup included the AMP7150,

AMP8050, AMP8150, AMP8350, AMP8360, AMP8370, and AMP8390.
These appliances range from 500 Mbps to 20 Gbps of throughput.

What Does AMP for Networks Do?

AMP for Networks and all the AMP connectors are designed to find
malicious files and provide retrospective analysis, illustrate trajectory, and
point out how far malicious files may have spread.

The AMP for Networks connector examines, records, tracks, and sends files
to the cloud. It creates an SHA-256 hash of the file and compares it to the
local file cache. If the hash is not in the local cache, it queries the Defense
Center (DC). The DC has its own cache of all the hashes that it has seen
before, and if it hasn’t previously seen this hash, the DC queries the cloud.
Unlike with AMP for Endpoints, when a file is new, it can be analyzed
locally and doesn’t have to be sent to the cloud for all analysis, and it also
examines and stops the file in flight, as it is traversing the appliance.

Figure 6-1 illustrates the many AMP for Networks connectors sending the
file hash to the DC, which in turn sends it to the cloud if the hash is new.
The connectors could be running on dedicated AMP appliances, as a service
on a SourceFire next-generation IPS (NGIPS), on an ASA with FirePOWER
Services, or even on the newer next-generation firewall (NGFW) known as
Firepower Threat Defense (FTD).

263
Figure 6-1 AMP Connectors Talking to the DC and Then the Cloud

It’s very important to note that only the SHA-256 hash is sent unless you
configure the policy to send files for further analysis in Threat Grid.

AMP can also provide retrospective analysis. The AMP for Networks
appliance keeps data from what occurred in the past. When a file’s
disposition is changed, AMP provides a historical analysis of what
happened, tracing an incident/infection. With the help of AMP for
Endpoints, retrospection can reach out to that host and remediate the bad
file, even though that file was permitted in the past.

This capability of retrospection is useful when a file is considered normal

and then is later reconsidered to be malicious.

AMP for Networks deals with malicious files, and it also allows an
organization to implement file control—even if malware is present.

In order for the AMP policies to be used, you must have at least one
SourceFire device with an active malware license. Figure 6-2 shows an
example of the license screen located at System > Licenses. Notice that
there are two devices listed, an ASA5515-X with FirePOWER Services

264
and a virtual SourceFire NGIPS (NGIPSv), both of which have malware
licenses.

Figure 6-2 Malware Licenses

Where Are the AMP Policies?

When you look at the Firepower Management Center (FMC), you don’t see
the AMP policies named the same way they’re named in other tools. They
are configured under Policies > Access Control > Malware & File, as
shown in Figure 6-3.

265
Figure 6-3 Malware & File Policies Page

Create a new file policy by clicking New File Policy in the upper-right
corner and providing a name in the New File Policy dialog box, as shown in
Figure 6-4. Remember to provide a detailed description that will help you
understand the purpose of the policy. Click Save to create the policy and
move into the configuration.

Figure 6-4 New File Policy Dialog

You now have a brand-new file policy with no rules, as shown in Figure 6-
5. To create your first rule in the new policy, click the Add File Rule button.

Figure 6-5 New File Policy Without Rules

The View File Rule window appears, as shown in Figure 6-6.

266
Figure 6-6 View File Rule Window

To create a file rule, you first select the application protocol to inspect for
files. The more specific your rule, the better the performance will be. As
shown in Figure 6-7, the choices are Any, HTTP, SMTP, IMAP, POP3, FTP,
and NetBIOS-ssn (SMB).

Figure 6-7 Application Protocols

You must also specify the direction of the file transfer through the network
appliance. The choices are Any, Upload, and Download, as shown in Figure
6-8.

267
Figure 6-8 Direction of Transfer

The action you choose next determines what to do with files. As shown in
Figure 6-9, the actions are Detect Files, Block Files, Malware Cloud
Lookup, and Block Malware.

Figure 6-9 File Rule Actions

File Rules

The first traditional file rule action is the Detect Files rule action. Detecting
files logs the detection of the specific files but does not interfere with the
file’s traversal through the network. Think of it as a “monitor mode” or an
audit style rule. You can store the files that meet the rule for further
evaluation.

The next traditional file rule action is the Block Files rule action, which
resets the file transfer connection. Just like the detection rule action, this
blocking action has an option to store the files.

Malware Cloud Lookup is the first of AMP rule actions, and it requires a
valid malware license. This rule action is like a monitor mode or an audit
rule for AMP, where the AMP connector obtains and logs the disposition of
the file but does not stop the transmission of the files. As with the other

268
rules, you have the ability to store the triggering files, only this time the
options are to store file types: Malware, Unknown, Clean, and/or Custom.

Block Malware is the second AMP rule action, and it naturally requires a
valid malware license. This rule action works the same way as Malware
Cloud Lookup, except it adds an option to reset the connection by sending a
TCP reset.

With both malware lookup options you have four choices:

Spero Analysis for EXEs: Spero Analysis is machine learning that

leverages heuristics to determine zero-day malware.

Dynamic Analysis: This sends the files themselves to be analyzed by

Threat Grid.

Capacity Handling: When you use dynamic analysis and the cloud is not
reachable, the files can be stored locally.

Local Malware Analysis: This examines the file using locally installed
antivirus software (at this writing, ClamAV, an open source product owned
by Cisco SourceFire).

File Disposition Types

As mentioned earlier in the chapter, there are four file dispositions:

Malware, Unknown, Clean, and Custom. One other disposition is
Unavailable. The list that follows describes these file dispositions in detail:

Malware: This disposition indicates that the AMP cloud categorized the
file as malware or local malware analysis identified malware during the
file scan, using the local antivirus software. Another possibility for this file
disposition is that the file’s threat score exceeded the malware threshold
defined in the file policy.

Clean: This disposition indicates that the AMP cloud categorized the file
as clean. It is also possible to manually add a file to the clean list, which
shows the file with the Clean disposition.

Unknown: This disposition indicates that the system queried the AMP

269
cloud, but the AMP cloud has not categorized the file.

Custom: This disposition indicates that a user added the file to the custom
detection list, possibly for data loss prevention (DLP) purposes or a static
location of the file instead of a dynamic one.

Unavailable: This disposition might mean the AMP for Networks system
could not query the AMP cloud.

Determining What Files to Match

The file rule must understand what file types to examine. To make it easier,
the system organizes file types into categories. You can use these categories
to help locate certain file types more easily. When you have the file types
you want in the middle column (aptly named File Types) of the View File
Rule dialog, click the Add button to select them for matching in the rule.

You do not have to add the individual file types; you can select the entire
category. Simply select the category on the left, click All types in selected
Categories in the middle, and then click Add. The chosen categories and
file types are maintained in the right column. Click Save to save the final
file rule.

Figure 6-10 shows the file rule with file types and categories mixed together
in the right column.

270
Figure 6-10 What File Types to Match

What About Those “Zippy” Type Files?

Zip and other archive files contain other files within them. The contents of
an archive file are examined, and the disposition of an archive file is
assigned based on the files inside it. If any of the files are determined to be
malware, the archive file is assigned the Malware disposition. If any of the
files are unknown, the archive file is marked as Unknown.

All the files within the archive must be found to be clean in order for the
archive to be assigned the Clean disposition.

Advanced File Policies

A file policy is made up of one or more file rules. In addition to the rules,
you can set some global settings for all the file rules within a file policy. As
shown in Figure 6-11, the advanced options are broken into two different
categories:

General:

First Time File Analysis: If this option is disabled, all files detected for
the first time are marked as Unknown. When this option is enabled, the files
are analyzed based on the options selected in the file rule.

Enable Custom Detection List: If this option is enabled and a file is on

the custom detection list, that file is blocked.

Enable Clean List: If this option is enabled and a file is on the clean list,
that file is allowed.

Mark files as malware based on dynamic analysis threat score: In this

drop-down list you select a threshold score. Files are considered malware
when their score is equal to or worse than the threshold value.

Archive File Inspection:

Inspect Archives: With this option disabled, AMP bypasses inspecting

archive files, even when they are selected in the file rule. If you disable the

271
inspection of archive files, AMP creates a hash of the archive file itself and
performs the lookup for that SHA, which is not very useful.

Block Encrypted Archives: Because you cannot decrypt these archives

and examine the files within the archive, you can simply choose to treat all
encrypted archives as possibly malicious and therefore block them.

Block Uninspectable Archives: This option allows you to block archive

files with contents that the system is unable to inspect for reasons other than
encryption; this could be due to file corruption or an archive within an
archive exceeding the specified maximum archive depth.

Max Archive Depth: This option determines how many levels of archive
stacking the system should decompress and examine. Think of it as a
Russian nesting doll: Files can be in a zip that is within a tar.gz file, which
is in a 7zip compressed archive.

Figure 6-11 File Policy Advanced Settings

When you’re ready to push the policies out to the AMP for Networks–
capable systems, click Deploy, as shown in Figure 6-12. As shown in

272
Figure 6-13, you now see a list of capable devices that can use this file
policy. Select the devices to receive the new policy and then click Deploy.

Figure 6-12 Deploying the Policies

Figure 6-13 Selecting the Appliances to Push Policy To

273
Summary
There are different types of AMP connectors on an endpoint and throughout
a network. AMP for Networks connectors exist on FirePOWER appliances,
ASA with FirePOWER Services, and the newer Firepower Threat Defense
(FTD) appliances.

AMP for Networks policies are configured in the Firepower Management

Center (FMC) with the Malware & File policies and then deployed to
AMP-capable appliances. The file policies determine which types of files
to examine, how to examine them, which protocols to examine for the files,
and what to do with them.

274
Chapter 7. Cisco AMP for Content Security
This chapter dives into the Advanced Malware Protection (AMP) for
Content Security connector. This chapter covers the following topics:

How AMP for Content Security fits in the AMP architecture

The components and configuration of file reputation and file analysis

services

The reporting for file reputation and file analysis services

Introduction to AMP for Content Security

The Cisco Advanced Malware Protection (AMP) architecture uses

connectors that examine files on the endpoint or in transit to and from the
network. AMP for Content Security appliances play a key role in the
perimeter security of a network, examining key traffic flows that represent
common attack vectors; they are therefore a perfect location for detecting
and blocking malware.

Figure 7-1 illustrates a network with many different AMP connectors

existing on endpoints, next-generation intrusion prevention systems
(NGIPS), AMP appliances, and Email Security Appliances (ESAs) and
Web Security Appliances (WSAs).

275
Figure 7-1 Network with AMP Connectors

Content Security Connectors

AMP connectors are implemented in different ways. The AMP for Networks
connectors that you learned about in Chapter 6, “Cisco AMP for Networks,”
are managed by the Firepower Management Center (FMC) and configured
through file policies.

AMP for Content Security appliances rely on a concept called reputation

scoring, which involves reputations of websites, email senders, and files.
Therefore, it shouldn’t come as a surprise that the capabilities on AMP for
Content Security appliances are referred to as file reputation filtering and
file analysis.

Figure 7-2 illustrates the file evaluation used by AMP for Content Security.
If the Web-Based Reputation Score (WBRS) is configured to scan, the
appliance simultaneously scans the file for malware and sends an SHA-256
of the file to the AMP cloud. In addition, if it is a Microsoft executable file,
it sends the Spero fingerprint of the PE header. Spero is a machine learning–

276
based technology that proactively identifies threats that were previously
unknown. If the file’s reputation and scan results are both determined to be
clean, the file is released and delivered to the end user.

Figure 7-2 Content AMP Flows

If the file is deemed to be malicious, either through file reputation or based

on a local scan result, the configured action is taken. If the file reputation is
unknown and it matches the criteria for file upload, the appliance uploads it
to Threat Grid in the cloud for analysis.

Configuring Cisco AMP for Content Security

Before you can configure AMP for Content Security, you must first have the
correct licensing (known as “feature keys”) on your appliances. The feature
keys enable the service on the appliance and allow you to configure the
settings for the AMP services.

Configuring the Web Security Appliance (WSA) for AMP

Two features in the WSA correspond to AMP: file reputation and file
analysis. Figure 7-3 shows the feature keys for a WSA and points out the
file reputation and file analysis feature keys.

277
Figure 7-3 AMP Feature Keys

The WSA must have access to the AMP cloud. Remember that the naming of
each Cisco product may vary (for example, the AMP cloud is sometimes
called File Reputation and Analysis Services). You configure the AMP
cloud settings under Security Services > Anti-Malware and Reputation,
as shown in Figure 7-4.

278
Figure 7-4 Anti-Malware and Reputation Screen

To configure the AMP services, click Edit Global Settings. Figure 7-5
shows the resulting Edit Anti-Malware and Reputation Settings screen. To
enable AMP, simply select the check box next to Enable File Reputation
Filtering.

Clicking Submit takes you to the license agreement page, where you must
click Accept, as shown in Figure 7-6.

279
Figure 7-5 Edit Anti-Malware and Reputation Settings Screen

Figure 7-6 Accepting the License Agreement

280
After you accept to the license agreement, the GUI redirects you back to the
main Anti-Malware and Reputation screen. You need to click Edit Global
Settings again to enable the file analysis service.

When you enable the file analysis service, the GUI asks you to agree to the
license for that service, and after you click Accept, you are redirected to the
main Anti-Malware and Reputation screen again. You must click Edit
Global Settings one more time if you want to change the file types that will
be analyzed.

There is also an area for more advanced configuration, such as changing the
cloud server to use for file reputation and setting the cloud (public or
private) to which to send the file for analysis. You also configure the
reputation threshold here; it defaults to whatever threshold is being
conveyed by the cloud. Normally, you leave these settings at their defaults.

Figure 7-7 shows the final file reputation and file analysis settings for the
WSA.

281
Figure 7-7 Final File Reputation and File Analysis Settings for the WSA

Configuring the Email Security Appliance (ESA) for AMP

Just like the WSA, the ESA has two feature keys: file reputation and file
analysis. Figure 7-8 shows the feature keys for a Cisco ESA and points out
the file reputation and file analysis feature keys, as well as the menu item
for configuring AMP.

Figure 7-8 ESA Feature Keys and Menu

282
The ESA must have the capability to reach the AMP cloud. As you saw in
Figure 7-8, you configure the AMP cloud settings under Security Services
> File Reputation and Analysis. Initially, the service is disabled, as shown
in Figure 7-9.

Figure 7-9 Security Services > File Reputation and Analysis

Configuring file reputation and analysis requires clicking the Enable button
shown in Figure 7-9. The GUI then prompts you to accept the license
agreement, as shown in Figure 7-10.

283
Figure 7-10 Accepting the License Agreement

After you accept the license agreement, the AMP service is enabled for both
file reputation and file analysis, as shown in Figure 7-11.

Figure 7-11 AMP Services Enabled

To configure the enabled services, click Edit Global Settings, and all the
settings for AMP are displayed, as shown in Figure 7-12.

284
Figure 7-12 AMP Settings

There is also an area for more advanced configuration, such as changing the
cloud server to use for file reputation and setting the cloud (public or
private) to which to send the file for analysis. If AMP must go through an
upstream proxy (another proxy server between the ESA and the AMP
cloud), you configure this here as well. You also configure the reputation
threshold here; it defaults to whatever threshold is being conveyed by the
cloud. Normally, you would leave these settings at their defaults.

As with all other configuration changes with AMP for Content Security
appliances, you must click Commit Changes for the configuration to take

285
effect.

AMP Reports

A number of reports show AMP-related activity. Figure 7-13 shows an

example of an AMP report from ESA. Summaries are in the charts at the top,
while the files identified as threats are listed at the bottom. You can see in
the report the file hashes that were matched, the actual name of the threat
observed, and how many threats were detected, monitored, or blocked.

286
Figure 7-13 AMP Report from ESA

Figure 7-14 shows an example of an AMP report from WSA. This report is
called the File Analysis report, and it allows you to search for a specific
file hash at the top, shows the latest analysis in the middle, and shows any
pending files at the bottom.

287
Figure 7-14 AMP Report from WSA

To determine whether a file was successfully sent to the cloud, you can use
the File Analysis report or the tail CLI command. If you use tail, you can
choose option 2 for amp_logs, as shown in Figure 7-15.

288
Figure 7-15 tail amp_logs

Summary

This chapter examines how AMP for Content Security fits into the overall
AMP architecture. You have learned the feature names and how to verify
that feature keys are installed. You have also learned how to enable the file
reputation and file analysis services on the WSA and the ESA. In addition,

289
you have seen a few of the reports that are available in AMP for Content
Security.

290
Chapter 8. Cisco AMP for Endpoints
In this chapter, you will learn the following:

Introduction to Cisco AMP for Endpoints

Custom detections

Application control

AMP for Windows

AMP for Mac

AMP for Linux

AMP for Android

Installing all flavors of AMP for Endpoints

Using the AMP cloud console

This chapter provides an overview of Cisco Advanced Malware Protection

(AMP) for Endpoints. This chapter looks at where AMP for Endpoints fits
into the AMP architecture. You’ll also learn about the types of AMP for
Endpoints connectors, how to create policies for them, and how to install
them. The chapter describes how to use the AMP cloud console, and you
will even get a look at AMP detecting and remediating malware.

After Cisco acquired SourceFire, the solution previously known as

FireAMP was renamed AMP for Endpoints. Throughout the console
interface and even within the connectors, you will see a confusing mix of
terminology, and in a number of place, you will still see the term FireAMP.
The figures in this chapter even show some instances of this. Cisco is
updating its products all the time, though, so expect that the user interface
will be updated at some point.

Introduction to AMP for Endpoints

291
Throughout this book, you have been learning about the various Cisco next-
generation security products and technologies. You have learned that
security technologies and processes should not just focus on detection but
should also provide the capability to mitigate the impact of an attack.
Organizations must maintain visibility and control across the extended
network during the full attack continuum:

Before an attack takes place

During an active attack

After an attacker starts to damage systems or steal information

In Chapter 5, “Introduction to and Architecture of Cisco AMP,” you learned

all about the components that make up the AMP architecture and the AMP
cloud. You learned that the AMP solution enables malware detection,
blocking, continuous analysis, and retrospective views with the following
features:

File reputation: AMP allows you to analyze files inline and block or
apply policies.

File sandboxing: AMP allows you to analyze unknown files to understand

true file behavior.

File retrospection: AMP allows you to continue to analyze files for

changing threat levels.

Remember that the architecture of AMP can be broken down into three main
components: the AMP cloud, AMP client connectors, and intelligence
sources. This chapter focuses on the AMP for Endpoints client connector.

Figure 8-1 illustrates the cloud architecture, showing how AMP receives
intelligence from many sources and a variety of client connectors.

292
Figure 8-1 AMP Cloud Architecture

AMP for Endpoints provides more than just endpoint-level visibility into
files. It also provides cloud-based detection of malware, in which the cloud
constantly updates itself. This enables very rapid detection of known
malware because the cloud resources are used instead of endpoint
resources. This architecture has a number of benefits. With the majority of
the processing power being performed in the cloud, the endpoint software
remains very lightweight. The cloud is able to provide a historical view of
malware activity, segmented into two activity types:

File trajectory: What endpoints have seen the files

Device trajectory: Actions the files performed on given endpoints

With the data storage and processing in the cloud, the AMP solution is able
to provide powerful and detailed reporting, as well as provide very robust
management.

The AMP for Endpoints agent is also able to take action. For example, it can
block malicious network connections based on custom IP blacklists or
intelligent dynamic lists of malicious IP addresses.

What Is AMP for Endpoints?

293
AMP for Endpoints is the connector that resides on—you guessed it—
endpoints. It resides on Windows, Mac, Linux, and Android endpoints.
Unlike traditional endpoint protection software that uses a local database of
signatures to match a known bad piece of software or a bad file, AMP for
Endpoints remains lightweight, sending a hash to the cloud and allowing the
cloud to make intelligent decisions and return the verdicts Clean, Malware,
and Unknown.

Figure 8-2 illustrates the AMP for Endpoints architecture.

Figure 8-2 AMP for Endpoints Architecture

Connections to the AMP Cloud

AMP for Endpoints connectors must be able to reach the AMP cloud. That
means the agents may have to be able to go through firewalls and proxy
servers to reach the Internet.

Firewalls, Destinations, and Ports, Oh My!

If traversing a firewall and/or web proxy to reach the Internet, those

products must allow connectivity from the AMP connector to the following
servers over HTTPS (TCP 443):

Event Server: Enterprise-event.amp.sourcefire.com (for US), enterprise-

event.eu.amp.sourcefire.com (for Europe)

Management Server: Enterprise-mgmt.amp.sourcefire.com (for US),

enterprise-mgmt.eu.amp.sourcefire.com (for Europe)

294
 Policy Server: policy.amp.sourcefire.com.s3.amazonaws.com (for US),
policy.eu.amp.sourcefire.com.s3.amazonaws.com (for Europe)

Error Reporting: crash.immunet.com (for US),

crash.eu.amp.sourcefire.com (for Europe)

Endpoint IOC Downloads: https://endpoint-ioc-prod-

us.s3.amazonaws.com (for US), https://endpoint-ioc-prod-
eu.s3.amazonaws.com (for Europe)

To allow a connector to communicate with Cisco cloud servers for file and
network disposition lookups, a firewall must allow the clients to connect to
the following server over TCP 443 by default or TCP 32137:

Cloud Host: cloud-ec.amp.sourcefire.com (for US), cloud-

ec.eu.amp.sourcefire.com (for Europe)

In order to upload files for analysis, clients must be able to access the
following server over TCP 80:

Submission Server: submit.amp.sourcefire.com (for US),

submit.eu.amp.sourcefire.com (for Europe)

If you have TETRA enabled on any of your AMP Connectors, you must
allow access to the following server over TCP 80 for signature updates:

Update Server: update.immunet.com (for both US and Europe)

Outbreak Control

With a solution as powerful and extensive as AMP for Endpoints, it is

difficult to determine where to start describing how to configure and use the
system; however, it makes logical sense to begin with Outbreak Control
because the objects you create within Outbreak Control are key aspects of
endpoint policies.

Outbreak Control allows you to create lists that customize AMP for
Endpoints to your organization’s needs. You can view the main lists from the
AMP cloud console by clicking the Outbreak Control menu, which offers
options in the following categories: Custom Detections, Application
Control, Network, and Endpoint IOC (indicators of compromise), as shown

295
in Figure 8-3.

Figure 8-3 Outbreak Control Menu

Custom Detections

You can think of custom detections as a blacklist. You use them to identify
files that you want to detect and quarantine. When a custom detection is
defined, not only do endpoints quarantine matching files when they see them,
but any AMP for Endpoints agents that have seen the file before the custom
detection was created can also quarantine the file through retrospection,
also known as cloud recall.

Simple custom detection allows you to add file signatures for files, while
the advanced custom detections are more like traditional antivirus
signatures.

Simple Custom Detections

Creating a simple custom detection is similar to adding new entries to a

296
blacklist. You define one or more files that you are trying to quarantine by
building a list of SHA-256 hashes. If you already have the SHA-256 hash of
a file, you can paste that hash directly into the UI, or you can upload files
directly and allow the cloud to create the SHA-256 hash for you.

To create a simple custom detection, navigate to Outbreak Control >

Custom Detections > Simple, and the list of all existing simple custom
detections appears, as shown in Figure 8-4. To add a new one, you must
type it in the Name box and click Save, as shown in Figure 8-4. The
detection is then added to the list, as shown in Figure 8-5, and automatically
edited—with the contents displayed on the right side.

Figure 8-4 Custom Detections—Simple

297
Figure 8-5 Detection Added and Contents on the Right Side

If you already have the SHA-256 hash of a file, simply paste it in, add a
note, and click Save; otherwise, you can upload a file, add a note, and click
Upload, as shown in Figure 8-5. Once the file is uploaded, the hash is
created and shown on the bottom-right side, as shown in Figure 8-6. You
must click Save, or the hash will not be stored as part of your simple
custom detection.

298
Figure 8-6 Saving a Simple Custom Detection

Advanced Custom Detections

Simple custom detections just look for the SHA-256 hash of a file.
Advanced custom detections offer many more signature types to the
detection, based on ClamAV signatures, including the following:

File body-based signatures

MD5 signatures

MD5, PE section–based signatures

An extended signature format (with wildcards, regular expressions, and

offsets)

Logical signatures

Icon signatures

To create an advanced custom detection, navigate to Outbreak Control >

Custom Detections > Advanced, and the list of all existing advanced
custom detections appears, as shown in Figure 8-7.

299
Figure 8-7 Custom Detections—Advanced

To add a new custom detection, you must type it in the Name box and click
Save, as shown in Figure 8-7, to add it to the list, as shown in Figure 8-8.
Click Edit to display the contents of the new advanced detection object on
the right side.

Figure 8-8 Adding an Advanced Custom Detection

As shown in Figure 8-8, the ClamAV signature types can be auto-detected,

or you can manually select them from the drop-down list. In Figure 8-9, the
ClamAV signature string
5d47b318b55c130ef30702026605ed6b:35411:Exploit.PDF-28520 was
pasted in with a type Auto Detect, and the Create button was clicked. You
can see there that the UI correctly converted it to hdb: Exploit.PDF-
28520.UNOFFICIAL.

300
Figure 8-9 Adding a Signature

Next, you click the Build Database From Signature Set, and a success
message is displayed, showing the successful creation of the advanced
custom detection signature set, as shown in Figure 8-10.

Figure 8-10 Successfully Built Advanced Detection

A View Changes link is visible with every custom detection, both simple
and advanced. The AMP cloud maintains an audit log for each of the
detection lists, and you can view it by clicking that link. Figure 8-11 shows
an example of the audit log.

301
Figure 8-11 Audit Log for an Advanced Custom Detection

Android Custom Detections

Android detections are defined separately from the ones used by Windows
or Mac. These detections provide granular control over Android devices in
an environment. The detections look for specific applications, and you build
them by either uploading the app’s .apk file or selecting that file from the
AMP console’s inventory list.

You can choose to use Android custom detections for two main functions:
outbreak control and application control.

When using an Android custom detection for outbreak control, you are using
the detection to stop malware that is spreading through mobile devices in
the organization. When a malicious app is detected, the user of the device is
notified and prompted to uninstall it.

302
You don’t have to use these detections just for malware, but you can also
use them to stop applications that you don’t want installed on devices in
your organization. This is what SourceFire refers to as application control.
Simply add apps to an Android custom detection list that you don’t want
installed, and APM notifies the user of the unwanted application and
prompts the user to uninstall it, just as if it were a malicious app.

To create an Android custom detection, navigate to Outbreak Control >

Custom Detections > Android to display the list of all existing Android
custom detections, if any exist. Click Create to add a new one, and give it a
name, as shown in Figure 8-12. Then click Save.

Figure 8-12 Custom Detections—Android

Once the new Android detection is created, you click Edit to add the
Android apps that you wish to detect as either malware or unwanted.

IP Blacklists and Whitelists

You can use outbreak control IP lists in conjunction with device flow
correlation (DFC) detections. DFC allows you to flag or even block
suspicious network activity. You can use policies to specify the behavior of
AMP for Endpoints when a suspicious connection is detected and also to
specify whether the connector should use addresses in the Cisco intelligence
feed, the custom IP lists you create yourself, or a combination of both.

303
You use an IP whitelist to define IPv4 addresses that should not be blocked
or flagged by DFC. AMP bypasses or ignores the intelligence feeds as they
relate to the IPv4 addresses in the whitelist.

You use IP blacklists to create DFC detections. Traffic that matches entries
in the blacklist are flagged or blocked, as the DFC rule dictates.

To create an IP list, navigate to Outbreak Control > Network > IP Blacklists

& Whitelists, as shown in Figure 8-13.

Figure 8-13 Network—IP Blacklists & Whitelists

Here you click Create IP List to start a new IP list, and you’re brought to
the New IP List configuration screen, where you can either create an IP list
by typing the IPv4 addresses in classless interdomain routing (CIDR)
notation or by uploading a file that contains a list of IPs. You can also
specify port numbers to block or allow. After the list is created, you can edit
it only by downloading the resulting file and uploading it back to the AMP
console. Figure 8-14 shows the New IP List screen, with a mixture of
entries entered as text.

304
Figure 8-14 New IP List Screen

You name the list, choose whether it is a whitelist or a blacklist, and enter a
series of IPv4 addresses, one line at a time. Each line must contain a single
IP or CIDR. Acceptable formats include the following:

10.1.100.0/24: A standard network range designated by network-/mask-

length CIDR notation

192.168.26.26: A single IPv4 address

10.1.250.254:443: A single IPv4 address with a port specified (UDP and

TCP)

10.250.1.1/16:8443: A CIDR-notated network range with a port specified

(UDP and TCP)

You click Create IP List to create the text file in the cloud console, and
your new IP list is shown on the screen. If you click Edit, you can change
the name of the IP list. To update the contents of the list, you must click
Download and then delete the list. Then you create a new list with the same

305
name and upload the modified file. An IP list can contain up to 100,000
lines or be a maximum of 2 MB in size.

As for custom detections, the AMP console maintains an audit trail for IP
lists that you can view by clicking View Changes.

Application Control

Like files, applications can be detected, blocked, and whitelisted. As with

the other files, AMP does not look for the name of the application but the
SHA-256 hash.

To create a new application control list for blocking an application,

navigate to Outbreak Control > Application Control > Blocking. One
thing you must credit the SourceFire AMP team with is that it sure
understands the concept of consistency in GUIs. This GUI works just like so
many other areas of the interface. If any existing blocking lists exist, they are
displayed here, as shown in Figure 8-15. As you would expect, to create a
new list, you click Create. You must name the list and click Save before
you can add any applications to the blocking list.

Figure 8-15 Outbreak Control > Application Control > Blocking

Once the list has been created and saved, click Edit to add any applications.
If you already have the SHA-256 hash, add it. Otherwise, you can upload
one application at a time and have the AMP cloud console calculate the hash
for you, as long as the file is not larger than the 20MB limit. You can also

306
upload an existing list. Figure 8-16 shows a blocking list with an existing
application hash shown at the bottom of the right-hand column, while
another file is being uploaded for hash calculation.

Figure 8-16 Adding Application Hashes to the Blocking List

Application whitelists work the same way. Navigate to Outbreak Control

> Application Control > Whitelisting to see a list of any existing
whitelists. Click Create to add a new one, provide it a name, and click
Save, as shown in Figure 8-17.

307
Figure 8-17 Outbreak Control > Application Control > Whitelisting

Once the list has been created and saved, click Edit to add any applications.
If you already have the SHA-256 hash, add it. Otherwise, you can upload
one application at a time and have the AMP cloud console calculate the hash
for you, as long as the file is not larger than the 20 MB limit. You can also
upload an existing list. Figure 8-18 shows a whitelist with an existing
application in the list (SafeGuardPDFViewer.exe).

Figure 8-18 Adding Application Hashes to a Whitelist

Don’t forget to click Save after adding the hash to the list.

Exclusion Sets

There is one more object that you should try to create before you build your
policies, and that is an exclusion set. An exclusion set is a list of
directories, file extensions, or even threat names that you do not want the
AMP agent to scan and definitely not to convict as malware.

You can use an exclusion set to resolve conflicts with other security
products or mitigate performance issues by excluding directories that
contain large files that are frequently written to, like databases. If you are

308
running an antivirus product on computers with the AMP for Endpoints
connector, you should exclude the location where that product is installed.

It’s important to remember that any files stored in a location that has been
added to an exclusion set will not be subjected to application blocking,
simple custom detections, or advanced custom detections.

These are the available exclusion types:

Threat: This type excludes specific detections by threat name.

Extension: This type excludes files with a specific extension.

Wildcard: This type excludes files or paths using wildcards for filenames,
extensions, or paths.

Path: This type excludes files in a given path.

For Windows, path exclusions may use constant special ID lists (CSIDL),
which are Microsoft given names for common file paths. For more on
CSIDL, see https://msdn.microsoft.com/en-
us/library/windows/desktop/bb762494%28v=vs.85%29.aspx.

To create a new exclusion set, navigate to Management > Exclusions. Here

you see a list of any existing exclusions and can create new ones. Click
Create Exclusion Set, provide a name, and click Save. The contents of the
exclusion set are automatically listed on the right side.

As shown in Figure 8-19, new exclusion sets are created with some default
exclusions. Many of these exclusions are specific to the default installation
paths of antivirus products and designed to cover a large variety of
installations. Figure 8-19 shows an example of a Windows exclusion set.
Figure 8-20 shows a Mac exclusion set, and Figure 8-21 shows a Linux
exclusion set.

309
Figure 8-19 Creating a Windows Exclusion Set

Figure 8-20 Creating a Mac Exclusion Set

310