- ASDM Requirements
- Hardware and Software Compatibility
- VPN Compatibility
- New Features
- How the ASA Services Module Works with the Switch
- Firewall Functional Overview
- Security Policy Overview
- Permitting or Denying Traffic with Access Rules
- Applying NAT
- Protecting from IP Fragments
- Using AAA for Through Traffic
- Applying HTTP, HTTPS, or FTP Filtering
- Applying Application Inspection
- Sending Traffic to Supported Hardware or Software Modules
- Applying QoS Policies
- Applying Connection Limits and TCP Normalization
- Enabling Threat Detection
- Enabling the Botnet Traffic Filter
- Configuring Cisco Unified Communications
- Firewall Mode Overview
- Stateful Inspection Overview
- Security Policy Overview
- VPN Functional Overview
- Security Context Overview
- ASA Clustering Overview
- Legacy Features
Introduction to the Cisco ASA
The Cisco ASA provides advanced stateful firewall and VPN concentrator functionality in one device, and for some models, integrated services modules such as IPS. The ASA includes many advanced features, such as multiple security contexts (similar to virtualized firewalls), clustering (combining multiple firewalls into a single firewall), transparent (Layer 2) firewall or routed (Layer 3) firewall operation, advanced inspection engines, IPsec VPN, SSL VPN, and clientless SSL VPN support, and many more features.
Note
ASDM supports many ASA versions. The ASDM documentation and online help includes all of the latest features supported by the ASA. If you are running an older version of ASA software, the documentation might include features that are not supported in your version. Similarly, if a feature was added into a maintenance release for an older major or minor version, then the ASDM documentation includes the new feature even though that feature might not be available in all later ASA releases. Please refer to the feature history table for each chapter to determine when features were added. For the minimum supported version of ASDM for each ASA version, see Cisco ASA Compatibility.
ASDM Requirements
ASDM Client Operating System and Browser Requirements
Table 1-1 lists the supported and recommended client operating systems and Java for ASDM.
|
|
|
|
|||
|---|---|---|---|---|---|
|
|
|
|
|
||
Java and Browser Compatibility
Table 1-2 lists compatibility caveats for Java, ASDM, and browser compatibility.
|
|
|
|
|---|---|---|
To continue using the Launcher, do one of the following:
Note ASDM 7.1(5) and earlier are not supported with Java 7 update 51. If you already upgraded Java, and can no longer launch ASDM in order to upgrade it to Version 7.2, then you can either use the CLI to upgrade ASDM, or you can add a security exception in the Java Control Panel for each ASA you want to manage with ASDM. See the “Workaround” section at: http://java.com/en/download/help/java_blocked.xml After adding the security exception, launch the older ASDM and then upgrade to 7.2. |
||
In rare cases, online help does not load when using Java Web Start |
In rare cases, when launching online help, the browser window loads, but the content fails to appear. The browser reports an error: “Unable to connect”. a. d. |
|
ASDM shows a yellow warning about the missing Permissions attribute when using an untrusted certificate |
Due to a bug in Java, if you do not have a trusted certificate installed on the ASA, you see a yellow warning about a missing Permissions attribute in the JAR manifest. It is safe to ignore this warning ; ASDM 7.2 includes the Permissions attribute. To prevent the warning from appearing, install a trusted certificate (from a known CA); or generate a self-signed certificate on the ASA by choosing Configuration > Device Management > Certificates > Identity Certificates. Launch ASDM, and when the certificate warning is shown, check the Always trust connections to websites check box. |
|
ASDM requires an SSL connection to the ASA. If the ASA has only the base encryption license (DES), and therefore has weak encryption ciphers for the SSL connection, you cannot launch ASDM. You must uninstall Java 7, and install Java 6 ( http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-javase6-419409.html). Note that a workaround is required for weak encryption and Java 6 (see below, in this table). |
||
Due to a Java bug, ASDM does not support usernames longer than 50 characters when using Java 6. Longer usernames work correctly for Java 7. |
||
Requires strong encryption license (3DES/AES) on ASA or workaround |
When you initially connect a browser to the ASA to load the ASDM splash screen, the browser attempts to make an SSL connection to the ASA. If the ASA has only the base encryption license (DES), and therefore has weak encryption ciphers for the SSL connection, you may not be able to access the ASDM splash screen; most current browsers do not support weak encryption ciphers. Therefore, without the strong encryption license (3DES/AES), use one of the following workarounds:
|
|
When the ASA uses a self-signed certificate or an untrusted certificate, Firefox 4 and later and Safari are unable to add security exceptions when browsing using HTTPS over IPv6. See https://bugzilla.mozilla.org/show_bug.cgi?id=633001. This caveat affects all SSL connections originating from Firefox or Safari to the ASA (including ASDM connections). To avoid this caveat, configure a proper certificate for the ASA that is issued by a trusted certificate authority. |
||
If you change the SSL encryption on the ASA to exclude both RC4-MD5 and RC4-SHA1 algorithms (these algorithms are enabled by default), then Chrome cannot launch ASDM due to the Chrome “SSL false start” feature. We suggest re-enabling one of these algorithms (see the Configuration > Device Management > Advanced > SSL Settings pane); or you can disable SSL false start in Chrome using the --disable-ssl-false-start flag according to http://www.chromium.org/developers/how-tos/run-chromium-with-flags. |
||
For Internet Explorer 9.0 for servers, the “Do not save encrypted pages to disk” option is enabled by default (See Tools > Internet Options > Advanced). This option causes the initial ASDM download to fail. Be sure to disable this option to allow ASDM to download. |
||
On OS X, you may be prompted to install Java the first time you run ASDM; follow the prompts as necessary. ASDM will launch after the installation completes. |
||
You need to allow ASDM to run because it is not signed with an Apple Developer ID. If you do not change your security preferences, you see an error screen. 
1. 
2. 
|
Hardware and Software Compatibility
For a complete list of supported hardware and software, see the Cisco ASA Compatibility :
http://www.cisco.com/en/US/docs/security/asa/compatibility/asamatrx.html
VPN Compatibility
See Supported VPN Platforms, Cisco ASA Series :
http://www.cisco.com/en/US/docs/security/asa/compatibility/asa-vpn-compatibility.html
New Features
- New Features in ASA 9.2(3)/ASDM 7.3(1.101)
- New Features in ASA 9.2(2.4)/ASDM 7.2(2)
- New Features in ASA 9.2(1)/ASDM 7.2(1)
Note New, changed, and deprecated syslog messages are listed in syslog messages guide.
New Features in ASA 9.2(3)/ASDM 7.3(1.101)
Table 1-3 lists the new features for ASA Version 9.2(3)/ASDM Version 7.3(1.101).
New Features in ASA 9.2(2.4)/ASDM 7.2(2)
Table 1-4 lists the new features for ASA Version 9.2(2.4)/ASDM Version 7.2(2).
Note Version 9.2(2) was removed from Cisco.com due to build issues; please upgrade to Version 9.2(2.4) or later.
New Features in ASA 9.2(1)/ASDM 7.2(1)
Table 1-5 lists the new features for ASA Version 9.2(1)/ASDM Version 7.2(1).
Note The ASA 5510, ASA 5520, ASA 5540, ASA 5550, and ASA 5580 are not supported in this release or later. ASA Version 9.1 was the final release for these models.
How the ASA Services Module Works with the Switch
You can install the ASASM in the Catalyst 6500 series and Cisco 7600 series switches with Cisco IOS software on both the switch supervisor and the integrated MSFC.
Note The Catalyst Operating System (OS) is not supported.
The ASA runs its own operating system.
The switch includes a switching processor (the supervisor) and a router (the MSFC). Although you need the MSFC as part of your system, you do not have to use it. If you choose to do so, you can assign one or more VLAN interfaces to the MSFC. You can alternatively use external routers instead of the MSFC.
In single context mode, you can place the router in front of the firewall or behind the firewall (see Figure 1-1).
The location of the router depends entirely on the VLANs that you assign to it. For example, the router is behind the firewall in the example shown on the left side of Figure 1-1 because you assigned VLAN 201 to the inside interface of the ASASM. The router is in front of the firewall in the example shown on the right side of Figure 1-1 because you assigned VLAN 200 to the outside interface of the ASASM.
In the left-hand example, the MSFC or router routes between VLANs 201, 301, 302, and 303, and no inside traffic goes through the ASASM unless it is destined for the Internet. In the right-hand example, the ASASM processes and protects all traffic between the inside VLANs 201, 202, and 203.
Figure 1-1 MSFC/Router Placement
For multiple context mode, if you place the router behind the ASASM, you should only connect it to a single context. If you connect the router to multiple contexts, the router will route between the contexts, which might not be your intention. The typical scenario for multiple contexts is to use a router in front of all the contexts to route between the Internet and the switched networks (see Figure 1-2).
Figure 1-2 MSFC/Router Placement with Multiple Contexts
Firewall Functional Overview
Firewalls protect inside networks from unauthorized access by users on an outside network. A firewall can also protect inside networks from each other, for example, by keeping a human resources network separate from a user network. If you have network resources that need to be available to an outside user, such as a web or FTP server, you can place these resources on a separate network behind the firewall, called a demilitarized zone (DMZ). The firewall allows limited access to the DMZ, but because the DMZ only includes the public servers, an attack there only affects the servers and does not affect the other inside networks. You can also control when inside users access outside networks (for example, access to the Internet), by allowing only certain addresses out, by requiring authentication or authorization, or by coordinating with an external URL filtering server.
When discussing networks connected to a firewall, the outside network is in front of the firewall, the inside network is protected and behind the firewall, and a DMZ, while behind the firewall, allows limited access to outside users. Because the ASA lets you configure many interfaces with varied security policies, including many inside interfaces, many DMZs, and even many outside interfaces if desired, these terms are used in a general sense only.
This section includes the following topics:
Security Policy Overview
A security policy determines which traffic is allowed to pass through the firewall to access another network. 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 actions to traffic to customize the security policy. This section includes the following topics:
- Permitting or Denying Traffic with Access Rules
- Applying NAT
- Protecting from IP Fragments
- Using AAA for Through Traffic
- Applying HTTP, HTTPS, or FTP Filtering
- Applying Application Inspection
- Sending Traffic to Supported Hardware or Software Modules
- Applying QoS Policies
- Applying Connection Limits and TCP Normalization
- Enabling Threat Detection
- Enabling the Botnet Traffic Filter
- Configuring Cisco Unified Communications
Permitting or Denying Traffic with Access Rules
You can apply an access rule to limit traffic from inside to outside, or allow traffic from outside to inside. For transparent firewall mode, you can also apply an EtherType access list to allow non-IP traffic.
Applying NAT
Protecting from IP Fragments
The ASA provides IP fragment protection. This feature performs full reassembly of all ICMP error messages and virtual reassembly of the remaining IP fragments that are routed through the ASA. Fragments that fail the security check are dropped and logged. Virtual reassembly cannot be disabled.
Using AAA for Through Traffic
You can require authentication and/or authorization for certain types of traffic, for example, for HTTP. The ASA also sends accounting information to a RADIUS or TACACS+ server.
Applying HTTP, HTTPS, or FTP Filtering
Although you can use access lists to prevent outbound access to specific websites or FTP servers, configuring and managing web usage this way is not practical because of the size and dynamic nature of the Internet.
You can configure Cloud Web Security on the ASA, or install an ASA module that provides URL and other filtering services, such as ASA CX or ASA FirePOWER. You can also use the ASA in conjunction with an external product such as the Cisco Web Security Appliance (WSA).
Applying Application Inspection
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.
Sending Traffic to Supported Hardware or Software Modules
Some ASA models allow you to configure software modules, or to insert hardware modules into the chassis, to provide advanced services. These modules provide additional traffic inspection and can block traffic based on your configured policies. You can send traffic to these modules to take advantage of these advanced services.
Applying QoS Policies
Some network traffic, such as voice and streaming video, cannot tolerate long latency times. QoS is a network feature that lets you give priority to these types of traffic. QoS refers to the capability of a network to provide better service to selected network traffic.
Applying Connection Limits and TCP Normalization
You can limit TCP and UDP connections and embryonic connections. 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. An embryonic connection is a connection request that has not finished the necessary handshake between source and destination.
TCP normalization is a feature consisting of advanced TCP connection settings designed to drop packets that do not appear normal.
Enabling Threat Detection
You can configure scanning threat detection and basic threat detection, and also how to use statistics to analyze threats.
Basic threat detection detects activity that might be related to an attack, such as a DoS attack, and automatically sends a system log message.
A typical scanning attack consists of a host that tests the accessibility of every IP address in a subnet (by scanning through many hosts in the subnet or sweeping through many ports in a host or subnet). The scanning threat detection feature determines when a host is performing a scan. Unlike IPS scan detection that is based on traffic signatures, the ASA scanning threat detection feature maintains an extensive database that contains host statistics that can be analyzed for scanning activity.
The host database tracks suspicious activity such as connections with no return activity, access of closed service ports, vulnerable TCP behaviors such as non-random IPID, and many more behaviors.
You can configure the ASA to send system log messages about an attacker or you can automatically shun the host.
Enabling the Botnet Traffic Filter
Malware is malicious software that is installed on an unknowing host. Malware that attempts network activity such as sending private data (passwords, credit card numbers, key strokes, or proprietary data) can be detected by the Botnet Traffic Filter when the malware starts a connection to a known bad IP address. The Botnet Traffic Filter checks incoming and outgoing connections against a dynamic database of known bad domain names and IP addresses (the blacklist), and then logs any suspicious activity. When you see syslog messages about the malware activity, you can take steps to isolate and disinfect the host.
Configuring Cisco Unified Communications
The Cisco ASA series is a strategic platform to provide proxy functions for unified communications deployments. The purpose of a proxy is to terminate and reoriginate connections between a client and server. The proxy delivers a range of security functions such as traffic inspection, protocol conformance, and policy control to ensure security for the internal network. An increasingly popular function of a proxy is to terminate encrypted connections in order to apply security policies while maintaining confidentiality of connections.
Firewall Mode Overview
The ASA runs in two different firewall modes:
In routed mode, the ASA is considered to be a router hop in the network.
In transparent mode, the ASA acts like a “bump in the wire,” or a “stealth firewall,” and is not considered a router hop. The ASA connects to the same network on its inside and outside interfaces.
You might use a transparent firewall to simplify your network configuration. Transparent mode is also useful if you want the firewall to be invisible to attackers. You can also use a transparent firewall for traffic that would otherwise be blocked in routed mode. For example, a transparent firewall can allow multicast streams using an EtherType access list.
Stateful Inspection Overview
All traffic that goes through the ASA is inspected using the Adaptive Security Algorithm and either allowed through or dropped. A simple packet filter can check for the correct source address, destination address, and ports, but it does not check that the packet sequence or flags are correct. A filter also checks every packet against the filter, which can be a slow process.
Note The TCP state bypass feature allows you to customize the packet flow.
A stateful firewall like the ASA, however, takes into consideration the state of a packet:
If it is a new connection, the ASA has to check the packet against access lists and perform other tasks to determine if the packet is allowed or denied. To perform this check, the first packet of the session goes through the “session management path,” and depending on the type of traffic, it might also pass through the “control plane path.”
The session management path is responsible for the following tasks:
– Performing the access list checks
– Allocating NAT translations (xlates)
– Establishing sessions in the “fast path”
The ASA creates forward and reverse flows in the fast path for TCP traffic; the ASA also creates connection state information for connectionless protocols like UDP, ICMP (when you enable ICMP inspection), so that they can also use the fast path.
Note For other IP protocols, like SCTP, the ASA does not create reverse path flows. As a result, ICMP error packets that refer to these connections are dropped.
Some packets that require Layer 7 inspection (the packet payload must be inspected or altered) are passed on to the control plane path. Layer 7 inspection engines are required for protocols that have two or more channels: a data channel, which uses well-known port numbers, and a control channel, which uses different port numbers for each session. These protocols include FTP, H.323, and SNMP.
If the connection is already established, the ASA does not need to re-check packets; most matching packets can go through the “fast” path in both directions. The fast path is responsible for the following tasks:
– NAT translations based on existing sessions
– Layer 3 and Layer 4 header adjustments
Data packets for protocols that require Layer 7 inspection can also go through the fast path.
Some established session packets must continue to go through the session management path or the control plane path. Packets that go through the session management path include HTTP packets that require inspection or content filtering. Packets that go through the control plane path include the control packets for protocols that require Layer 7 inspection.
VPN Functional Overview
A VPN is a secure connection across a TCP/IP network (such as the Internet) that appears as a private connection. This secure connection is called a tunnel. The ASA uses tunneling protocols to negotiate security parameters, create and manage tunnels, encapsulate packets, transmit or receive them through the tunnel, and unencapsulate them. The ASA functions as a bidirectional tunnel endpoint: it can receive plain packets, encapsulate them, and send them to the other end of the tunnel where they are unencapsulated and sent to their final destination. It can also receive encapsulated packets, unencapsulate them, and send them to their final destination. The ASA invokes various standard protocols to accomplish these functions.
The ASA performs the following functions:
- Establishes tunnels
- Negotiates tunnel parameters
- Authenticates users
- Assigns user addresses
- Encrypts and decrypts data
- Manages security keys
- Manages data transfer across the tunnel
- Manages data transfer inbound and outbound as a tunnel endpoint or router
The ASA invokes various standard protocols to accomplish these functions.
Security Context Overview
You can partition a single ASA into multiple virtual devices, known as security contexts. Each context is an independent device, with its own security policy, interfaces, and administrators. Multiple contexts are similar to having multiple standalone devices. Many features are supported in multiple context mode, including routing tables, firewall features, IPS, and management; however, some features are not supported. See the feature chapters for more information.
In multiple context mode, the ASA includes a configuration for each context that identifies the security policy, interfaces, and almost all the options you can configure on a standalone device. The system administrator adds and manages contexts by configuring them in the system configuration, which, like a single mode configuration, is the startup configuration. The system configuration identifies basic settings for the ASA. The system configuration does not include any network interfaces or network settings for itself; rather, when the system needs to access network resources (such as downloading the contexts from the server), it uses one of the contexts that is designated as the admin context.
The admin context is just like any other context, except that when a user logs into the admin context, then that user has system administrator rights and can access the system and all other contexts.
ASA Clustering Overview
ASA Clustering lets you group multiple ASAs together as a single logical device. A cluster provides all the convenience of a single device (management, integration into a network) while achieving the increased throughput and redundancy of multiple devices.
You perform all configuration (aside from the bootstrap configuration) on the master unit only; the configuration is then replicated to the member units.
Legacy Features
The following features are covered in the legacy feature guide:
- URL Filtering
- IP Audit
- IP spoofing prevention
- Fragment size
- Connection shunning
- AAA for network access
- RIP
While you can use these features in your configuration, there may be better alternative features described in the main configuration guides.
For deprecated features such as the ASA CSC module for legacy platforms, see the configuration guide for your ASA version. Similarly, for redesigned features such as NAT between Version 8.2 and 8.3 or transparent mode interfaces between Version 8.3 and 8.4, refer to the configuration guide for your version.
Feedback