CLI Book 2: Cisco ASA Series Firewall CLI Configuration Guide, 9.3

General Information About Rules

This section describes information for both access rules and EtherType rules, and it includes the following topics:

• Interface Access Rules and Global Access Rules
• Inbound and Outbound Rules
• Rule Order
• Implicit Permits
• Implicit Deny
• NAT and Access Rules

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 inbound interface access rules are always processed before the general global access rules. Global access rules apply only to inbound traffic.

Inbound and Outbound Rules

You can configure access rules based on the direction of traffic:

• Inbound—Inbound access rules apply to traffic as it enters an interface. Global and management access rules are always inbound.
• Outbound—Outbound rules apply to traffic as it exits an interface.

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.

Figure 3-1 Outbound ACL

See the following commands for this example:

Rule Order

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.

Implicit Permits

For routed mode, the following types of traffic are allowed through by default:

• Unicast IPv4 and IPv6 traffic from a higher security interface to a lower security interface.

For transparent mode, the following types of traffic are allowed through by default:

• Unicast IPv4 and IPv6 traffic from a higher security interface to a lower security interface.
• ARPs in both directions. (You can control ARP traffic using ARP inspection, but you cannot control it by access rule.)
• BPDUs in both directions.

For other traffic, you need to use either an extended access rule (IPv4 and IPv6) or an EtherType rule (non-IP).

Implicit Deny

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:

1. Interface access rule.

2. Global access rule.

3. Implicit deny.

NAT and Access Rules

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).

Extended Access Rules

This section describes information about extended access rules.

• Extended Access Rules for Returning Traffic
• Allowing Broadcast and Multicast Traffic through the Transparent Firewall Using Access Rules
• Management Access Rules

Extended 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 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).

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.

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.

Management Access Rules

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.

EtherType Rules

This section describes EtherType rules.

• Supported EtherTypes and Other Traffic
• EtherType Rules for Returning Traffic
• Allowing MPLS

Supported EtherTypes and Other Traffic

An EtherType rule controls the following:

• EtherType identified by a 16-bit hexadecimal number, including common types IPX and MPLS unicast or multicast.
• Ethernet V2 frames.
• BPDUs, which are permitted by default. BPDUs are SNAP-encapsulated, and the ASA is designed to specifically handle BPDUs.
• Trunk port (Cisco proprietary) BPDUs. Trunk BPDUs have VLAN information inside the payload, so the ASA modifies the payload with the outgoing VLAN if you allow BPDUs.
• Intermediate System to Intermediate System (IS-IS).

The following types of traffic are not supported:

• 802.3-formatted frames—These frames are not handled by the rule because they use a length field as opposed to a type field.

EtherType 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 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.

Or

Configure an Access Group

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:

Example:

hostname(config)# access-group outside_access in interface outside

For an interface-specific access group:

• Specify the extended or EtherType ACL name. You can configure one access-group command per ACL type per interface per direction, and one control plane ACL. The control plane ACL must be an extended ACL.
• The in keyword applies the ACL to inbound traffic. The out keyword applies the ACL to the outbound traffic.
• Specify the interface name.
• The per-user-override keyword (for inbound ACLs only) allows dynamic user ACLs that are downloaded for user authorization to override the ACL assigned to the interface. For example, if the interface ACL denies all traffic from 10.0.0.0, but the dynamic ACL permits all traffic from 10.0.0.0, then the dynamic ACL overrides the interface ACL for that user.

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.

• The control-plane keyword specifies if the rule is for to-the-box traffic.

For a global access group, specify the global keyword to apply the extended ACL to the inbound direction of all interfaces.

Examples

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.

Configure ICMP Access Rules

By default, you can send ICMP packets to any ASA interface using either IPv4 or IPv6, with these exceptions:

• The ASA does not respond to ICMP echo requests directed to a broadcast address.
• The ASA only responds to ICMP traffic sent to the interface that traffic comes in on; you cannot send ICMP traffic through an interface to a far interface.

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.

Procedure

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.

Example

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.

Examples

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:

Evaluating Syslog Messages for Access Rules

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.