This chapter describes how to control network access through or to the ASA using access rules. You use access rules to control network access in both routed and transparent firewall modes. In transparent mode, you can use both access rules (for Layer 3 traffic) and EtherType rules (for Layer 2 traffic).
Note To access the ASA 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 the general operations configuration guide.
Access rules determine which traffic is allowed through the ASA. There are several different layers of rules that work together to implement your access control policy:
In transparent firewall mode, you can combine extended access rules, management access rules, and EtherType rules on the same interface.
This section describes information for both access rules and EtherType rules, and it includes the following topics:
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 inbound interface access rules are always processed before the general global access rules. Global access rules apply only to inbound traffic.
You can configure access rules based on the direction of traffic:
Note “Inbound” and “outbound” refer to the application of an ACL on an interface, either to traffic entering the ASA on an interface or traffic exiting the ASA on an interface. These terms do not refer to the movement of traffic from a lower security interface to a higher security interface, commonly known as inbound, or from a higher to lower interface, commonly known as outbound.
An outbound ACL 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 ACLs to restrict access, you can create a single outbound ACL that allows only the specified hosts. (See the following figure.) The outbound ACL prevents any other hosts from reaching the outside network.
See the following commands for this example:
The order of rules is important. When the ASA decides whether to forward or drop a packet, the ASA tests the packet against each rule in the order in which the rules are listed in the applied ACL. After a match is found, no more rules are checked. For example, if you create an access rule at the beginning that explicitly permits all traffic for an interface, no further rules are ever checked.
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:
For other traffic, you need to use either an extended access rule (IPv4 and IPv6) or an EtherType rule (non-IP).
ACLs 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 ASA except for particular addresses, then you need to deny the particular addresses and then permit all others.
For EtherType ACLs, the implicit deny at the end of the ACL does not affect IP traffic or ARPs; for example, if you allow EtherType 8037, the implicit deny at the end of the ACL does not now block any IP traffic that you previously allowed with an extended ACL (or implicitly allowed from a high security interface to a low security interface). However, if you explicitly deny all traffic with an EtherType rule, then IP and ARP traffic is denied; only physical protocol traffic, such as auto-negotiation, is still allowed.
If you configure a global access rule, then the implicit deny comes after the global rule is processed. See the following order of operations:
Access rules always use the real IP addresses when determining an access rule match, even if you configure NAT. For example, if you configure NAT for an inside server, 10.1.1.5, so that it has a publicly routable IP address on the outside, 209.165.201.5, then the access rule to allow the outside traffic to access the inside server needs to reference the server’s real IP address (10.1.1.5), and not the mapped address (209.165.201.5).
This section describes information about extended access rules.
For TCP and UDP connections for both routed and transparent mode, you do not need an access rule to allow returning traffic because the ASA allows all returning traffic for established, bidirectional connections.
For connectionless protocols such as ICMP, however, the ASA establishes unidirectional sessions, so you either need access rules to allow ICMP in both directions (by applying ACLs 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) (ASA to host) or echo (8) (host to ASA).
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.
Note Because these special types of traffic are connectionless, you need to apply an access rule to both interfaces, so returning traffic is allowed through.
The following table lists common traffic types that you can allow through the transparent firewall.
|
|
|
---|---|---|
If you enable the DHCP server, then the ASA does not pass DHCP packets. |
||
Multicast streams are always destined to a Class D address (224.0.0.0 to 239.x.x.x). |
||
You can configure access rules that control management traffic destined to the ASA. Access control rules for to-the-box management traffic (defined by such commands as http, ssh, or telnet) have higher precedence than a 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 ACL.
Alternatively, you can use ICMP rules to control ICMP traffic to the device. Use regular extended access rules to control ICMP traffic through the device.
An EtherType rule controls the following:
Because EtherTypes are connectionless, you need to apply the rule to both interfaces if you want traffic to pass in both directions.
If you allow MPLS, ensure that Label Distribution Protocol and Tag Distribution Protocol TCP connections are established through the ASA by configuring both MPLS routers connected to the ASA to use the IP address on the ASA 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 ASA.
Supports IPv6. The source and destination addresses can include any mix of IPv4 and IPv6 addresses.
Additional Guidelines and Limitations
The following topics explain how to configure access control.
Before you can create an access group, create the ACL. See the general operations configuration guide for more information.
To bind an ACL to an interface or to apply it globally, use the following command:
hostname(config)# access-group outside_access in interface outside
For an interface-specific access group:
By default, VPN remote access traffic is not matched against interface ACLs. However, if you use the no sysopt connection permit-vpn command to turn off this bypass, the behavior depends on whether there is a vpn-filter applied in the group policy and whether you set the per-user-override option:
– No per-user-override, no vpn-filter —Traffic is matched against the interface ACL.
– No per-user-override, vpn-filter —Traffic is matched first against the interface ACL, then against the VPN filter.
– per-user-override, vpn-filter —Traffic is matched against the VPN filter only.
For a global access group, specify the global keyword to apply the extended ACL to the inbound direction of all interfaces.
The following example shows how to use the access-group command:
The access-list command lets any host access the host address using port 80. The access-group command specifies that the access-list command applies to traffic entering the outside interface.
By default, you can send ICMP packets to any ASA interface using either IPv4 or IPv6, with these exceptions:
To protect the device from attacks, you can use ICMP rules to limit ICMP access to ASA interfaces to particular hosts, networks, or ICMP types. ICMP rules function like access rules, where the rules are ordered, and the first rule that matches a packet defines the action.
If you configure any ICMP rule for an interface, an implicit deny ICMP rule is added to the end of the ICMP rule list, changing the default behavior. Thus, if you want to simply deny a few message types, you must include a permit any rule at the end of the ICMP rule list to allow the remaining message types.
We recommend that you always grant permission for the ICMP unreachable message type (type 3). Denying ICMP unreachable messages disables ICMP path MTU discovery, which can halt IPsec and PPTP traffic. Additionally ICMP packets in IPv6 are used in the IPv6 neighbor discovery process. See RFC 1195 and RFC 1435 for details about path MTU discovery.
Step 1 Create rules for ICMP traffic.
If you do not specify an icmp_type, the rule applies to all types. You can enter the number or the name. To control ping, specify echo-reply (0) (ASA-to-host) or echo (8) (host-to-ASA).
For the address, you can apply the rule to any address, to a single host, or to a network ( ip_address mask).
Step 2 Create rules for ICMPv6 (IPv6) traffic.
If you do not specify an icmp_type, the rule applies to all types.
For the address, you can apply the rule to any address, to a single host, or to a network ( ipv6-network / prefix-length).
Step 3 (Optional.) Set rate limits on ICMP Unreachable messages so that the ASA will appear on trace route output.
The rate limit can be 1-100, with 1 being the default. The burst size is meaningless, but must be 1-10.
Increasing the rate limit, along with enabling the set connection decrement-ttl command in a service policy, is required to allow a traceroute through the ASA that shows the ASA as one of the hops. For example, the following policy decrements the time-to-live (TTL) value for all traffic through the ASA.
The following example shows how to allow all hosts except the one at 10.1.1.15 to use ICMP to the inside interface:
The following example shows how to allow the host at 10.1.1.15 to use only ping to the inside interface:
The following example shows how to deny all ping requests and permit all packet-too-big messages (to support path MTU discovery) at the outside interface:
The following example shows how to permit host 2000:0:0:4::2 or hosts on prefix 2001::/64 to ping the outside interface:
To monitor network access, enter the following commands:
Clear the hit counts for the access list.
Displays the access lists, including the line number for each ACE and hit counts. Include an ACL name or you will see all access lists.
Displays the current ACL bound to the interfaces.
Use a syslog event viewer, such as the one in ASDM, to view messages related to access rules.
If you use default logging, you see syslog message 106023 for explicitly denied flows only. Traffic that matches the “implicit deny” entry that ends the rule list is not logged.
If the ASA is attacked, the number of syslog messages for denied packets can be very large. We recommend that you instead enable logging using syslog message 106100, which provides statistics for each rule (including permit rules) and enables you to limit the number of syslog messages produced. Alternatively, you can disable all logging for a given rule.
When you enable logging for message 106100, if a packet matches an ACE, the ASA creates a flow entry to track the number of packets received within a specific interval. The ASA generates a syslog message at the first hit and at the end of each interval, identifying the total number of hits during the interval and the time stamp for the last hit. At the end of each interval, the ASA resets the hit count to 0. If no packets match the ACE during an interval, the ASA deletes the flow entry. When you configure logging for a rule, you can control the interval and even the severity level of the log message, per rule.
A flow is defined by the source and destination IP addresses, protocols, and ports. Because the source port might differ for a new connection between the same two hosts, you might not see the same flow increment because a new flow was created for the connection.
Permitted packets that belong to established connections do not need to be checked against ACLs; only the initial packet is logged and included in the hit count. For connectionless protocols, such as ICMP, all packets are logged, even if they are permitted, and all denied packets are logged.
See the syslog messages guide for detailed information about these messages.
Tip When you enable logging for message 106100, if a packet matches an ACE, the ASA creates a flow entry to track the number of packets received within a specific interval. The ASA has a maximum of 32 K logging flows for ACEs. A large number of flows can exist concurrently at any point of time. To prevent unlimited consumption of memory and CPU resources, the ASA places a limit on the number of concurrent deny flows; the limit is placed on deny flows only (not on permit flows) because they can indicate an attack. When the limit is reached, the ASA does not create a new deny flow for logging until the existing flows expire, and issues message 106101. You can control the frequency of this message using the access-list alert-interval secs command, and the maximum number of deny flows cached using the access-list deny-flow-max number command.
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 from the outside for inside server 1.
The following example allows all hosts to communicate between the inside and hr networks but only specific hosts to access the outside network:
For example, the following sample ACL allows common EtherTypes originating on the inside interface:
The following example allows some EtherTypes through the ASA, but it denies all others:
The following example denies traffic with EtherType 0x1256 but allows all others on both interfaces:
The following example uses object groups to permit specific traffic on the inside interface: