-
Cisco ASA Services Module CLI Configuration Guide, 8.5
-
About This Guide
-
Index
-
Glossary
- Getting Started with the ASA
- Configuring Firewall and Security Context Modes
- Configuring Interfaces
- Configuring Basic Settings
- Configuring Objects and Access Lists
- Configuring IP Routing
- Configuring Network Address Translation
- Configuring Service Policies Using the Modular Policy Framework
- Configuring Access Control
- Configuring Application Inspection
- Configuring Connection Settings and QoS
- Configuring Advanced Network Protection
- Configuring High Availability
- Configuring Logging, SNMP, and Smart Call Home
- System Administration
- Reference
-
Feedback
Table Of Contents
Information About Access Rules
General Information About Rules
Information About Interface Access Rules and Global Access Rules
Using Access Rules and EtherType Rules on the Same Interface
Information About Extended Access Rules
Access Rules for Returning Traffic
Allowing Broadcast and Multicast Traffic through the Transparent Firewall Using Access Rules
Information About EtherType Rules
Supported EtherTypes and Other Traffic
Access Rules for Returning Traffic
Licensing Requirements for Access Rules
Configuration Examples for Permitting or Denying Network Access
Feature History for Access Rules
Configuring Access Rules
This chapter describes how to control network access through the ASASM using access rules and includes the following sections:
•
Information About Access Rules
•
•
•
Note
To access the ASASM interface for management access, you do not also need an access rule allowing the host IP address. You only need to configure management access according to Chapter 34, "Configuring Management Access."
Information About Access Rules
You create an access rule by applying an extended or EtherType access list to an interface or globally for all interfaces.You can use access rules in routed and transparent firewall mode to control IP traffic. An access rule permits or denies traffic based on the protocol, a source and destination IP address or network, and optionally the source and destination ports.
For transparent mode only, an EtherType rule controls network access for non-IP traffic. An EtherType rule permits or denies traffic based on the EtherType.
This section includes the following topics:
•
•
•
General Information About Rules
This section describes information for both access rules and EtherType rules, and it includes the following topics:
•
•
Implicit Permits
For routed mode, the following types of traffic are allowed through by default:
•
•
For transparent mode, the following types of traffic are allowed through by default:
•
•
•
Note
•
For other traffic, you need to use either an extended access rule (IPv4), an IPv6 access rule (IPv6), or an EtherType rule (non-IPv4/IPv6).
Information About Interface Access Rules and Global Access Rules
You can apply an access rule to a specific interface, or you can apply an access rule globally to all interfaces. You can configure global access rules in conjunction with interface access rules, in which case, the specific interface access rules are always processed before the general global access rules.
Note
Using Access Rules and EtherType Rules on the Same Interface
You can apply one access rule and one EtherType rule to each direction of an interface.
Implicit Deny
Access lists have an implicit deny at the end of the list, so unless you explicitly permit it, traffic cannot pass. For example, if you want to allow all users to access a network through the ASASM except for particular addresses, then you need to deny the particular addresses and then permit all others.
For EtherType access lists, the implicit deny at the end of the access list does not affect IP traffic or ARPs; for example, if you allow EtherType 8037, the implicit deny at the end of the access list does not now block any IP traffic that you previously allowed with an extended access list (or implicitly allowed from a high security interface to a low security interface). However, if you explicitly deny all traffic with an EtherType ACE, then IP and ARP traffic is denied.
If you configure a global access rule, then the implicit deny comes after the global rule is processed. See the following order of operations:
1.
2.
3.
Inbound and Outbound Rules
The ASASM supports two types of access rules:
•
•
Note
An outbound access list is useful, for example, if you want to allow only certain hosts on the inside networks to access a web server on the outside network. Rather than creating multiple inbound access lists to restrict access, you can create a single outbound access list that allows only the specified hosts. (See Figure 32-1.) The outbound access list prevents any other hosts from reaching the outside network.
Figure 32-1 Outbound Access List
See the following commands for this example:
hostname(config)# access-list OUTSIDE extended permit tcp host 10.1.1.14 host 209.165.200.225 eq wwwhostname(config)# access-list OUTSIDE extended permit tcp host 10.1.2.67 host 209.165.200.225 eq wwwhostname(config)# access-list OUTSIDE extended permit tcp host 10.1.3.34 host 209.165.200.225 eq wwwhostname(config)# access-group OUTSIDE out interface outsideInformation About Extended Access Rules
This section describes information about extended access rules and includes the following topics:
•
•
Access Rules for Returning Traffic
For TCP and UDP connections for both routed and transparent mode, you do not need an access rule to allow returning traffic because the ASASM allows all returning traffic for established, bidirectional connections.
For connectionless protocols such as ICMP, however, the ASASM establishes unidirectional sessions, so you either need access rules to allow ICMP in both directions (by applying access lists to the source and destination interfaces), or you need to enable the ICMP inspection engine. The ICMP inspection engine treats ICMP sessions as bidirectional connections. To control ping, specify echo-reply (0) (ASASM to host) or echo (8) (host to ASASM).
Allowing Broadcast and Multicast Traffic through the Transparent Firewall Using Access Rules
In routed firewall mode, broadcast and multicast traffic is blocked even if you allow it in an access rule, including unsupported dynamic routing protocols and DHCP (unless you configure DHCP relay). Transparent firewall mode can allow any IP traffic through. This feature is especially useful in multiple context mode, which does not allow dynamic routing, for example.
Note
Table 32-1 lists common traffic types that you can allow through the transparent firewall.
Management Access Rules
You can configure access rules that control management traffic destined to the ASASM. Access control rules for to-the-box management traffic (defined by such commands as http, ssh, or telnet) have higher precedence than an management access rule applied with the control-plane option. Therefore, such permitted management traffic will be allowed to come in even if explicitly denied by the to-the-box access list.
Information About EtherType Rules
This section describes EtherType rules and includes the following topics:
•
•
Supported EtherTypes and Other Traffic
An EtherType rule controls the following:
•
•
•
•
The following types of traffic are not supported:
•
Access Rules for Returning Traffic
Because EtherTypes are connectionless, you need to apply the rule to both interfaces if you want traffic to pass in both directions.
Allowing MPLS
If you allow MPLS, ensure that Label Distribution Protocol and Tag Distribution Protocol TCP connections are established through the ASASM by configuring both MPLS routers connected to the ASASM to use the IP address on the ASASM interface as the router-id for LDP or TDP sessions. (LDP and TDP allow MPLS routers to negotiate the labels (addresses) used to forward packets.)
On Cisco IOS routers, enter the appropriate command for your protocol, LDP or TDP. The interface is the interface connected to the ASASM.
hostname(config)# mpls ldp router-id interface forceOr
hostname(config)# tag-switching tdp router-id interface forceLicensing Requirements for Access Rules
The following table shows the licensing requirements for this feature:
Prerequisites
Before you can create an access rule, create the access list. See Chapter 14, "Adding an Extended Access List," and Chapter 15, "Adding an EtherType Access List," for more information.
Guidelines and Limitations
This section includes the guidelines and limitations for this feature.
Context Mode Guidelines
Supported in single and multiple context mode.
Firewall Mode Guidelines
Supported in routed and transparent firewall modes.
IPv6 Guidelines
Supports IPv6.
Per-User Access List Guidelines
•
•
•
Default Settings
See the "Implicit Permits" section.
Configuring Access Rules
To apply an access rule, perform the following steps.
Detailed Steps
access-group access_list {{in | out} interface interface_name [per-user-override | control-plane] | global}
Example:hostname(config)# access-group acl_out in interface outside
Binds an access list to an interface or applies it globally.
Specify the extended, EtherType, or IPv6 access list name. You can configure one access-group command per access list type per interface. You cannot reference empty access lists or access lists that contain only a remark.
For an interface-specific rule:
•
•
•
For VPN remote access traffic, the behavior depends on whether there is a vpn-filter applied in the group policy and whether you set the per-user-override option:
–
–
–
See the "Configuring RADIUS Authorization" section on page 35-14 for more information about per-user access lists. See also the "Per-User Access List Guidelines" section.
•
For a global rule, specify the global keyword to apply the access list to the inbound direction of all interfaces.
Examples
The following example shows how to use the access-group command:
hostname(config)# access-list acl_out permit tcp any host 209.165.201.3 eq 80hostname(config)# access-group acl_out in interface outsideThe access-list command lets any host access the global address using port 80. The access-group command specifies that the access-list command applies to traffic entering the outside interface.
Monitoring Access Rules
To monitor network access, enter the following command:
Displays the current access list bound to the interfaces.
Configuration Examples for Permitting or Denying Network Access
This section includes typical configuration examples for permitting or denying network access.
The following example adds a network object for inside server 1, performs static NAT for the server, and enables access to from the outside for inside server 1.
hostname(config)# object network inside-server1hostname(config)# host 10.1.1.1hostname(config)# nat (inside,outside) static 209.165.201.12hostname(config)# access-list outside_access extended permit tcp any object inside-server1 eq wwwhostname(config)# access-group outside_access in interface outsideThe following example allows all hosts to communicate between the inside and hr networks but only specific hosts to access the outside network:
hostname(config)# access-list ANY extended permit ip any anyhostname(config)# access-list OUT extended permit ip host 209.168.200.3 anyhostname(config)# access-list OUT extended permit ip host 209.168.200.4 anyhostname(config)# access-group ANY in interface insidehostname(config)# access-group ANY in interface hrhostname(config)# access-group OUT out interface outsideFor example, the following sample access list allows common EtherTypes originating on the inside interface:
hostname(config)# access-list ETHER ethertype permit ipxhostname(config)# access-list ETHER ethertype permit mpls-unicasthostname(config)# access-group ETHER in interface insideThe following example allows some EtherTypes through the ASASM, but it denies all others:
hostname(config)# access-list ETHER ethertype permit 0x1234hostname(config)# access-list ETHER ethertype permit mpls-unicasthostname(config)# access-group ETHER in interface insidehostname(config)# access-group ETHER in interface outsideThe following example denies traffic with EtherType 0x1256 but allows all others on both interfaces:
hostname(config)# access-list nonIP ethertype deny 1256hostname(config)# access-list nonIP ethertype permit anyhostname(config)# access-group ETHER in interface insidehostname(config)# access-group ETHER in interface outsideThe following example uses object groups to permit specific traffic on the inside interface:
!hostname (config)# object-group service myacloghostname (config-service)# service-object tcp source range 2000 3000hostname (config-service)# service-object tcp source range 3000 3010 destinatio$hostname (config-service)# service-object ipsechostname (config-service)# service-object udp destination range 1002 1006hostname (config-service)# service-object icmp echohostname(config)# access-list outsideacl extended permit object-group myaclog interface inside anyFeature History for Access Rules
Table 32-2 lists each feature change and the platform release in which it was implemented.
