Introduction to Cisco ASA Firewall Services
Firewall services are those ASA features that are focused on controlling access to the network, including services that block traffic and services that enable traffic flow between internal and external networks. These services include those that protect the network against threats, such as Denial of Service (DoS) and other attacks.
The following topics provide an overview of firewall services.
How to Implement
The following procedure provides a general sequence for
implementing firewall services. However, each step is optional, needed only if
you want to provide the service to your network.
Before You Begin
Configure the ASA according to the general operations
configuration guide, including at minimum basic settings, interface
configuration, routing, and management access.
Access rules, applied per interface or globally, are your first
line of defense. You can drop, upon entry, specific types of traffic, or
traffic from (or to) specific hosts or networks. By default, the ASA allows
traffic to flow freely from an inside network (higher security level) to an
outside network (lower security level).
You can apply an access rule to limit traffic from inside to
outside, or allow traffic from outside to inside.
Basic access rules control traffic using a “5-tuple” of source
address and port, destination address and port, and protocol. See
Access Rules and
Access Control Lists.
You can augment your rules by making them identity aware. This
lets you configure rules based on user identity or group membership. To
implement identity control, do any combination of the following:
Install Cisco Context Directory Agent (CDA), also known as AD
agent, on a separate server to collect user and group information already
defined in your Active Directory (AD) server. Then, configure the ASA to get
this information, and add user or group criteria to your access rules. See
Install Cisco Identity Services Engine (ISE) on a separate
server to implement Cisco Trustsec. You can then add security group criteria to
your access rules. See
ASA and Cisco TrustSec.
Install the ASA FirePOWER module on the ASA and implement
identity policies in the module. The identity-aware access policies in ASA
FirePOWER would apply to any traffic that you redirect to the module. See
ASA FirePOWER Module.
The wide-spread use of web-based applications means that a lot
of traffic runs over the HTTP or HTTPS protocols. With traditional 5-tuple
access rules, you either allow or disallow all HTTP/HTTPS traffic. You might
require more granular control of web traffic.
You can install a module on the ASA to provide application
filtering to selectively allow HTTP or other traffic based on the application
being used. Thus, you do not have to make a blanket permit for HTTP. You can
look inside the traffic and prevent applications that are unacceptable for your
network (for example, inappropriate file sharing). When you add a module for
application filtering, do not configure HTTP inspection on the ASA.
To implement application filtering, install the ASA FirePOWER
module on the ASA and use application filtering criteria in your ASA FirePOWER
access rules. These policies apply to any traffic that you redirect to the
ASA FirePOWER Module.
URL filtering denies or allows traffic based on the URL of the
The purpose of URL filtering is primarily to completely block or
allow access to a web site. Although you can target individual pages, you
typically specify a host name (such as www.example.com) or a URL category,
which defines a list of host names that provide a particular type of service
(such as Gambling).
When trying to decide whether to use URL filtering or
application filtering for HTTP/HTTPS traffic, consider whether your intention
is to create a policy that applies to all traffic directed at a web site. If
your intention is to treat all such traffic the same way (denying it or
allowing it), use URL filtering. If your intention is to selectively block or
allow traffic to the site, use application filtering.
To implement URL filtering, do one of the following:
Install the ASA FirePOWER module on the ASA and use URL
filtering criteria in your ASA FirePOWER access rules. These policies apply to
any traffic that you redirect to the module. See
ASA FirePOWER Module.
Subscribe to the Cloud Web Security service, where you configure your filtering policies in ScanCenter, and then configure the ASA to send traffic to your Cloud Web Security account. See ASA and Cisco Cloud Web Security
You can implement a number of measures to protect against
scanning, denial of service (DoS), and other attacks. A number of ASA features
help protect against attacks by applying connection limits and dropping
abnormal TCP packets. Some features are automatic, others are configurable but
have defaults appropriate in most cases, while others are completely optional
and you must configure them if you want them.
Following are the threat protection services available with the
IP packet fragmentation protection—The ASA performs full
reassembly of all ICMP error messages and virtual reassembly of the remaining
IP fragments that are routed through the ASA, and drops fragments that fail the
security check. No configuration is necessary.
Connection limits, TCP normalization, and other
connection-related features—Configure connection-related services such as TCP
and UDP connection limits and timeouts, TCP sequence number randomization, TCP
normalization, and TCP state bypass. TCP normalization is designed to drop
packets that do not appear normal. See
For example, you can limit TCP and UDP connections and embryonic
connections (a connection request that has not finished the necessary handshake
between source and destination). Limiting the number of connections and
embryonic connections protects you from a DoS attack. The ASA uses the
embryonic limit to trigger TCP Intercept, which protects inside systems from a
DoS attack perpetrated by flooding an interface with TCP SYN packets.
Threat detection—Implement threat detection on the ASA to
collect statistics to help identify attacks. Basic threat detection is enabled
by default, but you can implement advanced statistics and scanning threat
detection. You can shun hosts that are identified as a scanning threat. See
Next-Generation IPS—Install the ASA FirePOWER module on the ASA
and implement Next Generation IPS intrusion rules in your ASA FirePOWER. These
policies would apply to any traffic that you redirect to ASA FirePOWER. See
ASA FirePOWER Module.
One of the main functions of Network Address Translation (NAT)
is to enable private IP networks to connect to the Internet. NAT replaces a
private IP address with a public IP address, translating the private addresses
in the internal private network into legal, routable addresses that can be used
on the public Internet. In this way, NAT conserves public addresses because you
can advertise at a minimum only one public address for the entire network to
the outside world.
Other functions of NAT include:
Security—Keeping internal IP addresses hidden discourages direct
IP routing solutions—Overlapping IP addresses are not a problem
when you use NAT.
Flexibility—You can change internal IP addressing schemes
without affecting the public addresses available externally; for example, for a
server accessible to the Internet, you can maintain a fixed IP address for
Internet use, but internally, you can change the server address.
Translating between IPv4 and IPv6 (Routed mode only)—If you want
to connect an IPv6 network to an IPv4 network, NAT lets you translate between
the two types of addresses.
NAT is not required. If you do not configure NAT for a given set
of traffic, that traffic will not be translated, but will have all of the
security policies applied as normal.
Application inspection engines are required for services that
embed IP addressing information in the user data packet or that open secondary
channels on dynamically assigned ports. These protocols require the ASA to do a
deep packet inspection, to open the required pinholes and to apply network
address translation (NAT).
The default ASA policy already applies inspection globally for
many popular protocols, such as DNS, FTP, SIP, ESMTP, TFTP, and others. The
default inspections might be all you require for your network.
However, you might need to enable inspection for other
protocols, or fine-tune an inspection. Many inspections include detailed
options that let you control packets based on their contents. If you know a
protocol well, you can apply fine-grained control on that traffic.
You use service policies to configure application inspection.
You can configure a global service policy, or apply a service policy to each
interface, or both.
Use Case: Expose a Server to the Public
You can make certain application services on a
server available to the public. For example, you could expose a web server, so
that users can connect to the web pages but not make any other connections to
To expose a server to the public, you typically
need to create access rules that allow the connection and NAT rules to
translate between the server’s internal IP address and an external address that
the public can use. In addition, you can use port address translation (PAT) to
map an internal port to an external port, if you do not want the externally
exposed service to use the same port as the internal server. For example, if
the internal web server is not running on TCP/80, you can map it to TCP/80 to
make connections easier for external users.
The following example makes a web server on the
inside private network available for public access.
Figure 1. Static NAT for an Inside Web
||Create a network object for the internal web
hostname(config)# object network myWebServ
hostname(config-network-object)# host 10.1.2.27
||Configure static NAT for the object:
hostname(config-network-object)# nat (inside,outside) static 22.214.171.124
||Add an access rule to the access group
attached to the outside interface to permit web access to the server.
hostname(config)# access-list outside_access_in line 1 extended
permit tcp any4 object myWebServ eq http
||If you do not already have an access group
on the outside interface, apply it using the access-group command:
hostname(config)# access-group outside_access_in in interface outside