Table Of Contents
Introduction to the Cisco ASA
ASDM Client Operating System and Browser Requirements
Hardware and Software Compatibility
VPN Compatibility
New Features
New Features in ASA 9.1(2)/ASDM 7.1(3)
New Features in ASA 8.4(6)/ASDM 7.1(2.102)
New Features in ASA 9.0(2)/ASDM 7.1(2)
New Features in ASA 9.1(1)/ASDM 7.1(1)
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 the IPS Module
Sending Traffic to the Content Security and Control Module
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
VPN Functional Overview
Security Context Overview
ASA Clustering Overview
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.
This chapter includes the following sections:
•ASDM Client Operating System and Browser Requirements
•Hardware and Software Compatibility
•VPN Compatibility
•New Features
•How the ASA Services Module Works with the Switch
•Firewall Functional Overview
•VPN Functional Overview
•Security Context Overview
•ASA Clustering Overview
ASDM Client Operating System and Browser Requirements
Table 1-1 lists the supported and recommended client operating systems and Java for ASDM.
Table 1-1 Operating System and Browser Requirements
Operating System
|
Browser
|
Java SE Plug-in
|
Internet Explorer
|
Firefox
|
Safari
|
Chrome
|
Microsoft Windows (English and Japanese):
•7
•Vista
•2008 Server
•XP
|
6.0 or later
|
1.5 or later
|
No support
|
18.0 or later
|
6.0 or later
|
Apple Macintosh OS X:
•10.8
•10.7
•10.6
•10.5
•10.4
|
No support
|
1.5 or later
|
2.0 or later
|
18.0 or later
|
6.0 or later
|
Red Hat Enterprise Linux 5 (GNOME or KDE):
•Desktop
•Desktop with Workstation
|
N/A
|
1.5 or later
|
N/A
|
18.0 or later
|
6.0 or later
|
See the following caveats:
•If you upgrade from a previous version to Java 7 update 5, you may not be able to open ASDM using the Java Web Start from an IPv6 address; you can either download the ASDM Launcher, or follow the instructions at: http://java.com/en/download/help/clearcache_upgrade.xml.
•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.
•ASDM requires you to make an SSL connection to the ASA in the following situations:
–When you first connect your browser to the ASA and access the ASDM splash screen.
–When you launch ASDM using the launcher or the Java web start application.
If the ASA only has the base encryption license (DES), and therefore has weak encryption ciphers for the SSL connection, you may not be able to access the splash screen or launch ASDM. See the following issues:
–When using Java 7 when launching ASDM, you must have the strong encryption license (3DES/AES) on the ASA. With only the base encryption license (DES), you cannot launch ASDM. Even if you can connect with a browser to the ASDM splash screen and download the launcher or web start application, you cannot then launch ASDM. You must uninstall Java 7, and install Java 6.
–When using Java 6 for accessing the splash screen in a browser, by default, Internet Explorer on Windows Vista and later and Firefox on all operating systems do not support DES for SSL; therefore without the strong encryption license (3DES/AES), see the following workarounds:
If available, use an already downloaded ASDM launcher or Java web start application. The launcher works with Java 6 and weak encryption, even if the browsers do not.
For Windows Internet Explorer, you can enable DES as a workaround. See http://support.microsoft.com/kb/929708 for details.
For Firefox on any operating system, you can enable the security.ssl3.dhe_dss_des_sha setting as a workaround. See http://kb.mozillazine.org/About:config to learn how to change hidden configuration preferences.
•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 MacOS, 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.
•On MacOS, you may see the following error message when opening the ASDM Launcher:
Cannot launch Cisco ASDM-IDM. No compatible version of Java 1.5+ is available.
In this case, Java 7 is the currently-preferred Java version; you need to set Java 6 as the preferred Java version: Open the Java Preferences application (under Applications > Utilities), select the preferred Java version, and drag it up to be the first line in the table.
•On MacOS 10.8 and later, you need to allow applications that are not signed with an Apple Developer ID. If you do not change your security preferences, you see an error screen.
a. To change the security setting, open System Preferences, and click Security & Privacy.
b. On the General tab, under Allow applications downloaded from, click Anywhere.
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 5500 Series:
http://www.cisco.com/en/US/docs/security/asa/compatibility/asa-vpn-compatibility.html
New Features
•New Features in ASA 9.1(2)/ASDM 7.1(3)
•New Features in ASA 8.4(6)/ASDM 7.1(2.102)
•New Features in ASA 9.0(2)/ASDM 7.1(2)
•New Features in ASA 9.1(1)/ASDM 7.1(1)
Note New, changed, and deprecated syslog messages are listed in syslog messages guide.
New Features in ASA 9.1(2)/ASDM 7.1(3)
Released: May 14, 2013
Table 1-2 lists the new features for ASA Version 9.1(2)/ASDM Version 7.1(3).
Note Features added in 8.4(6) are not included in 9.1(2) unless they are explicitly listed in this table.
Table 1-2 New Features for ASA Version 9.1(2)/ASDM Version 7.1(3)
Feature
|
Description
|
Encryption Features
|
Support for IPsec LAN-to-LAN tunnels to encrypt failover and state link communications
|
Instead of using the proprietary encryption for the failover key, you can now use an IPsec LAN-to-LAN tunnel for failover and state link encryption.
Note Failover LAN-to-LAN tunnels do not count against the IPsec (Other VPN) license.
We modified the following screen: Configuration > Device Management > High Availability > Failover > Setup.
|
Additional ephemeral Diffie-Hellman ciphers for SSL encryption
|
The ASA now supports the following ephemeral Diffie-Hellman (DHE) SSL cipher suites:
•DHE-AES128-SHA1
•DHE-AES256-SHA1
These cipher suites are specified in RFC 3268, Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS).
When supported by the client, DHE is the preferred cipher because it provides Perfect Forward Secrecy. See the following limitations:
•DHE is not supported on SSL 3.0 connections, so make sure to also enable TLS 1.0 for the SSL server.
•Some popular applications do not support DHE, so include at least one other SSL encryption method to ensure that a cipher suite common to both the SSL client and server can be used.
•Some clients may not support DHE, including AnyConnect 2.5 and 3.0, Cisco Secure Desktop, and Internet Explorer 9.0.
We modified the following screen: Configuration > Device Management > Advanced > SSL Settings.
Also available in 8.4(4.1).
|
Management Features
|
Support for administrator password policy when using the local database
|
When you configure authentication for CLI or ASDM access using the local database, you can configure a password policy that requires a user to change their password after a specified amount of time and also requires password standards such as a minimum length and the minimum number of changed characters.
We introduced the following screen: Configuration > Device Management > Users/AAA > Password Policy.
Also available in 8.4(4.1).
|
Support for SSH public key authentication
|
You can now enable public key authentication for SSH connections to the ASA on a per-user basis. You can specify a public key file (PKF) formatted key or a Base64 key. The PKF key can be up to 4096 bits. Use PKF format for keys that are too large to for the ASA support of the Base64 format (up to 2048 bits).
We introduced the following screens:
Configuration > Device Management > Users/AAA > User Accounts > Edit User Account > Public Key Authentication
Configuration > Device Management > Users/AAA > User Accounts > Edit User Account > Public Key Using PKF
Also available in 8.4(4.1); PKF key format support is only in 9.1(2).
|
AES-CTR encryption for SSH
|
The SSH server implementation in the ASA now supports AES-CTR mode encryption.
|
Improved SSH rekey interval
|
An SSH connection is rekeyed after 60 minutes of connection time or 1 GB of data traffic.
|
Support for Diffie-Hellman Group 14 for the SSH Key Exchange
|
Support for Diffie-Hellman Group 14 for SSH Key Exchange was added. Formerly, only Group 1 was supported.
We modified the following screen: Configuration > Device Management > Management Access > ASDM/HTTPS/Telnet/SSH.
Also available in 8.4(4.1).
|
Support for a maximum number of management sessions
|
You can set the maximum number of simultaneous ASDM, SSH, and Telnet sessions.
We introduced the following screen: Configuration > Device Management > Management Access > Management Session Quota.
Also available in 8.4(4.1).
|
Support for a pre-login banner in ASDM
|
Administrator can define a message that appears before a user logs into ASDM for management access. This customizable content is called a pre-login banner, and can notify users of special requirements or important information.
|
The default Telnet password was removed
|
To improve security for management access to the ASA, the default login password for Telnet was removed; you must manually set the password before you can log in using Telnet. Note: The login password is only used for Telnet if you do not configure Telnet user authentication.
Formerly, when you cleared the password, the ASA restored the default of "cisco." Now when you clear the password, the password is removed.
The login password is also used for Telnet sessions from the switch to the ASASM (see the session command). For initial ASASM access, you must use the service-module session command, until you set a login password.
We did not modify any ASDM screens.
Also available in 9.0(2).
|
Platform Features
|
Support for Power-On Self Test (POST)
|
The ASA runs its power-on self-test at boot time even if it is not running in FIPS 140-2-compliant mode.
Additional tests have been added to the POST to address the changes in the AES-GCM/GMAC algorithms, ECDSA algorithms, PRNG, and Deterministic Random Bit Generator Validation System (DRBGVS).
|
Improved pseudo-random number generation (PRNG)
|
The X9.31 implementation has been upgraded to use AES-256 encryption instead of 3DES encryption to comply with the Network Device Protection Profile (NDPP) in single-core ASAs.
|
Support for image verification
|
Support for SHA-512 image integrity checking was added.
We did not modify any ASDM screens.
Also available in 8.4(4.1).
|
Support for private VLANs on the ASA Services Module
|
You can use private VLANs with the ASASM. Assign the primary VLAN to the ASASM; the ASASM automatically handles secondary VLAN traffic. There is no configuration required on the ASASM for this feature; see the switch configuration guide for more information.
|
CPU profile enhancements
|
The cpu profile activate command now supports the following:
•Delayed start of the profiler until triggered (global or specific thread CPU%)
•Sampling of a single thread
We did not modify any ASDM screens.
Also available in 8.4(6).
|
DHCP Features
|
DHCP relay servers per interface (IPv4 only)
|
You can now configure DHCP relay servers per-interface, so requests that enter a given interface are relayed only to servers specified for that interface. IPv6 is not supported for per-interface DHCP relay.
We modified the following screen: Configuration > Device Management > DHCP > DHCP Relay.
|
DHCP trusted interfaces
|
You can now configure interfaces as trusted interfaces to preserve DHCP Option 82. DHCP Option 82 is used by downstream switches and routers for DHCP snooping and IP Source Guard. Normally, if the ASA DHCP relay agent receives a DHCP packet with Option 82 already set, but the giaddr field (which specifies the DHCP relay agent address that is set by the relay agent before it forwards the packet to the server) is set to 0, then the ASA will drop that packet by default. You can now preserve Option 82 and forward the packet by identifying an interface as a trusted interface.
We modified the following screen: Configuration > Device Management > DHCP > DHCP Relay.
|
Module Features
|
ASA 5585-X support for the ASA CX SSP-10 and -20
|
The ASA CX module lets you enforce security based on the complete context of a situation. This context includes the identity of the user (who), the application or website that the user is trying to access (what), the origin of the access attempt (where), the time of the attempted access (when), and the properties of the device used for the access (how). With the ASA CX module, you can extract the full context of a flow and enforce granular policies such as permitting access to Facebook but denying access to games on Facebook or permitting finance employees access to a sensitive enterprise database but denying the same to other employees.
We introduced the following screens:
Home > ASA CX Status
Wizards > Startup Wizard > ASA CX Basic Configuration
Configuration > Firewall > Service Policy Rules > Add Service Policy Rule > Rule Actions > ASA CX Inspection
Also available in 8.4(4.1).
|
ASA 5585-X support for network modules
|
The ASA 5585-X now supports additional interfaces on network modules in slot 1. You can install one or two of the following optional network modules:
•ASA 4-port 10G Network Module
•ASA 8-port 10G Network Module
•ASA 20-port 1G Network Module
Also available in 8.4(4.1).
|
ASA 5585-X DC power supply support
|
Support was added for the ASA 5585-X DC power supply.
Also available in 8.4(5).
|
Support for monitor-only mode for demonstration purposes
|
For demonstration purposes only, you can enable monitor-only mode for the service policy, which forwards a copy of traffic to the ASA CX module, while the original traffic remains unaffected.
Another option for demonstration purposes is to configure a traffic-forwarding interface instead of a service policy in monitor-only mode. The traffic-forwarding interface sends all traffic directly to the ASA CX module, bypassing the ASA.
We modified the following screen: Configuration > Firewall > Service Policy Rules > Add Service Policy Rule > Rule Actions > ASA CX Inspection.
The traffic-forwarding feature is supported by CLI only.
|
Support for the ASA CX module and NAT 64
|
You can now use NAT 64 in conjunction with the ASA CX module.
We did not modify any ASDM screens.
|
Firewall Features
|
EtherType ACL support for IS-IS traffic (transparent firewall mode)
|
In transparent firewall mode, the ASA can now pass IS-IS traffic using an EtherType ACL.
We modified the following screen: Configuration > Device Management > Management Access > EtherType Rules.
Also available in 8.4(5).
|
Decreased the half-closed timeout minimum value to 30 seconds
|
The half-closed timeout minimum value for both the global timeout and connection timeout was lowered from 5 minutes to 30 seconds to provide better DoS protection.
We modified the following screens:
Configuration > Firewall > Service Policy Rules > Connection Settings
Configuration > Firewall > Advanced > Global Timeouts.
|
Remote Access Features
|
IKE security and performance improvements
|
The number of IPsec-IKE security associations (SAs) can be limited for IKE v1 now, as well as IKE v2.
We modified the following screen: Configuration > Site-to-Site VPN > Advanced > IKE Parameters.
|
The IKE v2 Nonce size has been increased to 64 bytes.
There are no ASDM screen or CLI changes.
|
For IKE v2 on Site-to-Site, a new algorithm ensures that the encryption algorithm used by child IPsec SAs is not higher strength than the parent IKE. Higher strength algorithms will be downgraded to the IKE level.
This new algorithm is enabled by default. We recommend that you do not disable this feature.
We did not modify any ASDM screens.
|
For Site-to-Site, IPsec data-based rekeying can be disabled.
We modified the following screen: Configuration > Site-to-Site > IKE Parameters.
|
Improved Host Scan and ASA Interoperability
|
Host Scan and the ASA use an improved process to transfer posture attributes from the client to the ASA. This gives the ASA more time to establish a VPN connection with the client and apply a dynamic access policy.
Also available in 8.4(5).
|
Clientless SSL VPN:
Windows 8 Support
|
This release adds support for Windows 8 x86 (32-bit) and Windows 8 x64 (64-bit) operating systems.
We support the following browsers on Windows 8:
•Internet Explorer 10 (desktop only)
•Firefox (all supported Windows 8 versions)
•Chrome (all supported Windows 8 versions)
See the following limitations:
•Internet Explorer 10:
–The Modern (AKA Metro) browser is not supported.
–If you enable Enhanced Protected Mode, we recommend that you add the ASA to the trusted zone.
–If you enable Enhanced Protected Mode, Smart Tunnel and Port Forwarder are not supported.
•A Java Remote Desktop Protocol (RDP) plugin connection to a Windows 8 PC is not supported.
Also available in 9.0(2).
|
Cisco Secure Desktop:
Windows 8 Support
|
CSD 3.6.6215 was updated to enable selection of Windows 8 in the Prelogin Policy operating system check.
See the following limitations:
•Secure Desktop (Vault) is not supported with Windows 8.
Also available in 9.0(2).
|
Dynamic Access Policies:
Windows 8 Support
|
ASDM was updated to enable selection of Windows 8 in the DAP Operating System attribute.
Also available in 9.0(2).
|
Monitoring Features
|
NAT-MIB cnatAddrBindNumberOfEntries and cnatAddrBindSessionCount OIDs to allow polling for Xlate count.
|
Support was added for the NAT-MIB cnatAddrBindNumberOfEntries and cnatAddrBindSessionCount OIDs to support xlate_count and max_xlate_count for SNMP.
This data is equivalent to the show xlate count command.
We did not modify any ASDM screens.
Also available in 8.4(5).
|
NSEL
|
Flow-update events have been introduced to provide periodic byte counters for flow traffic. You can change the time interval at which flow-update events are sent to the NetFlow collector. You can filter to which collectors flow-update records will be sent.
We modified the following screens:
Configuration > Device Management > Logging > NetFlow.
Configuration > Firewall > Service Policy Rules > Add Service Policy Rule Wizard - Rule Actions > NetFlow > Add Flow Event
Also available in 8.4(5).
|
New Features in ASA 8.4(6)/ASDM 7.1(2.102)
Released: April 29, 2013
Table 1-3 lists the new features for ASA Version 8.4(6)/ASDM Version 7.1(2.102).
Table 1-3 New Features for ASA Version 8.4(6)/ASDM Version 7.1(2.102)
Feature
|
Description
|
Monitoring Features
|
Ability to view top 10 memory users
|
You can now view the top bin sizes allocated and the top 10 PCs for each allocated bin size. Previously, you had to enter multiple commands to see this information (the show memory detail command and the show memory binsize command); the new command provides for quicker analysis of memory issues.
No ASDM changes were made.
This feature is not available in 8.5(1), 8.6(1), 8.7(1), 9.0(1), or 9.1(1).
|
CPU profile enhancements
|
The cpu profile activate command now supports the following:
•Delayed start of the profiler until triggered (global or specific thread CPU %)
•Sampling of a single thread
No ASDM changes were made.
This feature is not available in 8.5(1), 8.6(1), 8.7(1), 9.0(1), or 9.1(1).
|
Remote Access Features
|
user-storage value command password is now encrypted in show commands
|
The password in the user-storage value command is now encrypted when you enter show running-config.
We modified the following screen: Configuration > Remote Access VPN > Clientless SSL VPN Access > Group Policies > More Options > Session Settings.
This feature is not available in 8.5(1), 8.6(1), 8.7(1), 9.0(1), or 9.1(1).
|
New Features in ASA 9.0(2)/ASDM 7.1(2)
Released: February 25, 2013
Table 1-4 lists the new features for ASA Version 9.0(2)/ASDM Version 7.1(2).
Note Features added in 8.4(4.x), 8.4(5), and 8.4(6) are not included in 9.0(2) unless they were listed in the 9.0(1) feature table.
Table 1-4 New Features for ASA Version 9.0(2)/ASDM Version 7.1(2)
Feature
|
Description
|
Remote Access Features
|
Clientless SSL VPN:
Windows 8 Support
|
This release adds support for Windows 8 x86 (32-bit) and Windows 8 x64 (64-bit) operating systems.
We support the following browsers on Windows 8:
•Internet Explorer 10 (desktop only)
•Firefox (all supported Windows 8 versions)
•Chrome (all supported Windows 8 versions)
See the following limitations:
•Internet Explorer 10:
–The Modern (AKA Metro) browser is not supported.
–If you enable Enhanced Protected Mode, we recommend that you add the ASA to the trusted zone.
–If you enable Enhanced Protected Mode, Smart Tunnel and Port Forwarder are not supported.
•A Java Remote Desktop Protocol (RDP) plugin connection to a Windows 8 PC is not supported.
|
Cisco Secure Desktop:
Windows 8 Support
|
CSD 3.6.6215 was updated to enable selection of Windows 8 in the Prelogin Policy operating system check.
See the following limitations:
•Secure Desktop (Vault) is not supported with Windows 8.
|
Dynamic Access Policies:
Windows 8 Support
|
ASDM was updated to enable selection of Windows 8 in the DAP Operating System attribute.
|
Management Features
|
The default Telnet password was removed
|
To improve security for management access to the ASA, the default login password for Telnet was removed; you must manually set the password before you can log in using Telnet. Note: The login password is only used for Telnet if you do not configure Telnet user authentication.
Formerly, when you cleared the password, the ASA restored the default of "cisco." Now when you clear the password, the password is removed.
The login password is also used for Telnet sessions from the switch to the ASASM (see the session command). For initial ASASM access, you must use the service-module session command, until you set a login password.
We did not modify any ASDM screens.
|
New Features in ASA 9.1(1)/ASDM 7.1(1)
Released: December 3, 2012
Table 1-5 lists the new features for ASA Version 9.1(1)/ASDM Version 7.1(1).
Note Features added in 8.4(4.x), 8.4(5), 8.4(6), and 9.0(2) are not included in 9.1(1) unless they were listed in the 9.0(1) feature table.
Table 1-5 New Features for ASA Version 9.1(1)/ASDM Version 7.1(1)
Feature
|
Description
|
Module Features
|
Support for the ASA CX SSP for the ASA 5512-X through ASA 5555-X
|
We introduced support for the ASA CX SSP software module for the ASA 5512-X, ASA 5515-X, ASA 5525-X, ASA 5545-X, and ASA 5555-X. The ASA CX software module requires a Cisco solid state drive (SSD) on the ASA. For more information about the SSD, see the ASA 5500-X hardware guide.
We did not modify any screens.
|
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
•Firewall Mode Overview
•Stateful Inspection Overview
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 the IPS Module
•Sending Traffic to the Content Security and Control Module
•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
Some of the benefits of NAT include the following:
•You can use private addresses on your inside networks. Private addresses are not routable on the Internet.
•NAT hides the local addresses from other networks, so attackers cannot learn the real address of a host.
•NAT can resolve IP routing problems by supporting overlapping IP addresses.
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. We recommend that you use the ASA in conjunction with a separate server running one of the following Internet filtering products:
•Websense Enterprise
•Secure Computing SmartFilter
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 the IPS Module
If your model supports the IPS module for intrusion prevention, then you can send traffic to the module for inspection. The IPS module monitors and performs real-time analysis of network traffic by looking for anomalies and misuse based on an extensive, embedded signature library. When the system detects unauthorized activity, it can terminate the specific connection, permanently block the attacking host, log the incident, and send an alert to the device manager. Other legitimate connections continue to operate independently without interruption. For more information, see the documentation for your IPS module.
Sending Traffic to the Content Security and Control Module
If your model supports it, the CSC SSM provides protection against viruses, spyware, spam, and other unwanted traffic. It accomplishes this by scanning the FTP, HTTP, POP3, and SMTP traffic that you configure the ASA to send to it.
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 5500 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:
•Routed
•Transparent
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. See the "TCP State Bypass" section in the firewall configuration guide.
A stateful firewall like the ASA, however, takes into consideration the state of a packet:
•Is this a new connection?
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
–Performing route lookups
–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.
•Is this an established connection?
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:
–IP checksum verification
–Session lookup
–TCP sequence number check
–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. Some features are not supported, including VPN and dynamic routing protocols.
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.
Feedback
