Packet Filtering

Cisco ASA can protect the inside network, the demilitarized zones (DMZs) and the outside network by inspecting all traffic that passes through it. You can specify policies and rules that identify what traffic should be permitted in or out of an interface. The security appliance uses access control lists (ACLs) to drop unwanted or unknown traffic when it attempts to enter the trusted networks. An ACL is a list of security rules or policies grouped together that allows or denies packets after looking at the packet headers and other attributes. Each permit or deny statement in the ACL is called an access control entry (ACE). These ACEs can classify packets by inspecting up to Layer 4 headers for a number of parameters, including the following:

• Layer 2 protocol information such as EtherTypes
• Layer 3 protocol information such as ICMP, TCP, or UDP
• Source and destination IP addresses
• Source and destination TCP or UDP ports

Once an ACL has been properly configured, you can apply it to an interface to filter traffic. The security appliance can filter packets in both the inbound and outbound direction on an interface. When an inbound ACL is applied to an interface, the security appliance inspects packets against the ACEs after receiving or before transmitting them. If a packet is allowed in, the security appliance continues to process it by sending it through the other configured engines. If a packet is denied by the ACL, the security appliance discards the packet and generates a syslog message indicating that such an event has occurred. In Figure 5-1, the security appliance administrator has applied to the outside interface an inbound ACL that permits only HTTP traffic destined for 209.165.202.131. All other traffic will be dropped at the interface by the security appliance.

Figure 5-1. Inbound Packet Filtering

If an outbound ACL is applied on an interface, the security appliance processes the packets by sending them through the different processes (NAT, QoS, and VPN) and then applies the configured ACEs before transmitting the packets out on the wire. The security appliance transmits the packets only if they are allowed to go out. If the packets are denied by even one of the ACEs, the security appliance discards the packets and generates a syslog message indicating that such an event has occurred. In Figure 5-2, the security appliance administrator has applied to the inside interface an outbound ACL that permits only HTTP traffic destined for 209.165.202.131. All other traffic gets dropped at the interface by the security appliance.

Figure 5-2. Outbound Packet Filtering

 

Types of ACLs

The security appliance supports five different types of ACLs to provide a flexible and scaleable solution to filter unauthorized packets into the network:

• Standard ACLs
• Extended ACLs
• IPv6 ACLs
• EtherType ACLs
• WebVPN ACLs

The following sections describe each type in turn.

Standard ACLs

Standard ACLs are used to identify packets based on the destination IP addresses. These ACLs can be used in scenarios such as split tunneling for the remote-access VPN tunnels (discussed in Chapter 16, "Remote Access VPNs") and route redistribution using the route maps. These ACLs, however, cannot be applied on an interface to filter packets. A standard ACL can be used only if the security appliance is running in routed mode. In routed mode, the Cisco ASA routes packets from one subnet to another subnet by acting as an extra layer 3 hop in the network.

Extended ACLs

Extended ACLs, the most commonly deployed ACLs, can classify packets based on the following attributes:

• Source and destination IP addresses
• Layer 3 protocols
• Source and/or destination TCP and UDP ports
• Destination ICMP type for ICMP packets

An extended ACL can be used for interface packet filtering, QoS packet classification, packet identification for NAT and VPN encryption, and a number of other features listed shortly in the "Comparing ACL Features" section. These ACLs can be set up on the security appliance in the routed and the transparent mode.

IPv6 ACLs

An IPv6 ACL functions similarly to an extended ACL. However, it only identifies IPv6 traffic passing through a security appliance in routed mode.

EtherType ACLs

EtherType ACLs can be used to filter IP- and non-IP-based traffic by checking the Ethernet type code field in the Layer 2 header. IP-based traffic uses an Ethernet type code value of 0x800, whereas Novell IPX uses 0x8137 or 0x8138 depending on the Netware version.

An EtherType ACL can be configured only if the security appliance is running in transparent mode, covered in Chapter 10, "Transparent Firewalls."

Note

The security appliance does not allow IPv6 traffic to pass through it, even if it is allowed to pass through an IPv6 EtherType ACL.

 

WebVPN ACLs

A WebVPN ACL allows security appliance administrators to restrict traffic coming through the WebVPN tunnels (discussed in Chapter 16). In the case where there is a WebVPN ACL defined but there is no match for a packet, the default behavior is to drop the packet. On the other hand, if there is no ACL defined, the security appliance allows traffic to pass through it.

Comparing ACL Features

Table 5-1 compares the ACLs. It also specifies whether they can be used in conjunction with supported features on the security appliance.

Table 5-1. ASA Features and Support of ACL Types

Feature	Standard	Extended	IPv6	EtherType	WebVPN
Layer 2 packet filtering	No	Yes	No	Yes	No
Layer 3 packet filtering	No	Yes	Yes	No	Yes
Capture	No	Yes	Yes	Yes	No
AAA	No	Yes	Yes	No	No
Time range	No	Yes	Yes	No	Yes
Object grouping	No	Yes	Yes	No	No
NAT 0	No	Yes	No	No	No
PIM	Yes	No	No	No	No
Packet inspection	No	Yes	No	No	No
IPS inspection	No	Yes	No	No	No
VPN encryption	No	Yes	No	No	Yes[1]
Remarks	Yes	Yes	Yes	Yes	Yes
Line numbers	No	Yes	Yes	No	No
Logging	No	Yes	Yes	No	Yes
QoS	No	Yes	No	No	No
Policy NAT	No	Yes	No	No	No
OSPF route-map	Yes	Yes	No	No	No

[1] Only WebVPN encrypted traffic.

Configuring Packet Filtering

The packet filtering on the security appliance requires three configuration steps:

Step 1.	Set up an ACL.
Step 2.	Apply an ACL to an interface.
Step 3.	Set up an IPv6 ACL (optional).

Step 1: Set Up an ACL

The ACL identifies traffic that needs to be allowed or dropped when it tries to go through the security appliance. An ACE can be as simple as permitting all IP traffic from one network to another, to as complicated as permitting traffic originating from a unique source IP address on a particular port destined for a specific port on the destination address. An ACE is defined by using the access-list command. For interface filtering, you can define an extended ACL, an IPv6 ACL, or an EtherType ACL, as mentioned in the previous section. The command syntax to define an extended ACE is as follows:

 access-list id [extended][line line-num] {deny | permit}{protocol | object-group

 protocol_obj_grp_id {source_addr source_mask} | object-group network_obj_grp_id|

 host src_host_addr [operator port [port] | object-group service_obj_grp_id]

 {destination_addr destination_mask} | object-group network_obj_grp_id| host

 dst_host_addr [operator port [port] | object-group service_obj_grp_id]} [log

 [[disable | default] | level] [interval secs] [time_range name]] [inactive]



 access-list id [line line-num] remark text

 access-list alert-interval secs

 access-list deny-flow-max flow_num

Note

The interface ACL does not block packets destined for the security appliance's IP addresses.

Table 5-2 lists and defines the arguments used in an ACE.

Table 5-2. ACE Definition

Syntax	Description
access-list	Keyword used to create an ACL.
id	Name or number of an ACL.
extended	Optional argument, used to specify an extended IP ACL.
line line-num	Optional argument, used to specify the line number at which to insert an ACE.
deny	Discards the packet if it matches the configured conditions.
permit	Allows the packet if it matches the configured conditions.
protocol	Name or number of an IP protocol.
object-group[1]	Grouping of different objects in a list.
protocol_obj_grp_id[1]	An object name containing the list of protocols to be filtered.
source_addr	Network or host address from which the packet is being sent.
source_mask	Network mask applied to source_addr. If an src_host_addr is used, this argument is optional.
network_obj_grp_id[1]	An object name containing the list of networks to be filtered.
host	A keyword used to specify a single IP address for traffic filtering.
src_host_addr	Specifies the source IP address to be filtered.
operator	An optional keyword used to compare the source or destination ports. Possible operands include lt for less than, gt for greater than, eq for equal, neq for not equal, and range for an inclusive range.
port	Name or number of TCP or UDP port to be filtered.
service_obj_grp_id[1]	An object name containing the list of services to be filtered.
destination_addr	Network or host address to which the packet is sent.
destination_mask	Network mask applied to destination_addr. If a dst_host_addr is used, this argument is optional.
dst_host_addr	Specifies the destination IP address to be filtered.
log	Generates a syslog message 106100 if a packet matches the ACE.
level	Specifies the logging level, 0 through 7, where: 0 = emergencies 1 = alerts 2 = critical 3 = errors 4 = warnings 5 = notifications 6 = informational (default) 7 = debugging
disable	Does not send syslog message if packets hit the configured ACE.
default	Uses the default behavior which generates a syslog 106023 message whenever packet matches a deny in the ACE.
interval	A keyword to specify the time interval to generate the subsequent new syslog messages.
secs	The actual time interval in seconds. The default time interval is 300 seconds.
time range[1]	A keyword to specify the time-range name.
name	A predefined time-range name.
inactive	Keyword to disable an ACE.
remark	Keyword to specify remarks on an ACL.
text	Actual text, up to 100 characters, to be added as remarks.
alert-interval	Keyword to specify the number of seconds to generate a 106101 syslog message when the maximum number of deny flows is reached.
deny-flow-max	Keyword to limit the maximum number of concurrent deny flows allowed.
flow_num	Actual number of deny flows that can be created. This can be between 1 and 4096 (the default).

[1] These options are discussed in the "Object Grouping" section.

Note

The security appliance restricts the logging option to be implemented for interface filtering only. The logging option will be ignored if an ACL is used with another feature.

In Figure 5-3, SecureMe, the fictional company used in examples throughout this book, hosts a web server and an e-mail server at its location in Chicago. Both servers allow traffic to be destined for 209.165.202.131 on port 80 (HTTP) and 209.165.202.132 on port 25 (SMTP). However, the security appliance allows only two client hosts209.165.201.1 and 209.165.201.2to initiate the traffic. All other traffic passing through the security appliance will be dropped.

Figure 5-3. Inbound Traffic Filtering

Example 5-1 shows the related configuration. An extended ACL called inbound_traffic_on_outside is set up with four ACEs. The first two ACEs allow HTTP traffic destined for 209.165.202.131 from the two client machines, while the last two ACEs allow SMTP access to 209.165.202.132 from both machines. Adding remarks to an ACL is recommended, because it helps other to recognize its function. The system administrator has added This is the interface ACL to block inbound traffic as the remark on this ACL.

Example 5-1. Configuration of an Extended ACL

Chicago# configure terminal

Chicago(config)# access-list inbound_traffic_on_outside remark This is the

 interface ACL to block inbound traffic

Chicago(config)# access-list inbound_traffic_on_outside extended permit tcp host

 209.165.201.1 host 209.165.202.131 eq www

Chicago(config)# access-list inbound_traffic_on_outside extended permit tcp host

 209.165.201.2 host 209.165.202.131 eq www

Chicago(config)# access-list inbound_traffic_on_outside extended permit tcp host

 209.165.201.1 host 209.165.202.132 eq smtp

Chicago(config)# access-list inbound_traffic_on_outside extended permit tcp host

 209.165.201.2 host 209.165.202.132 eq smtp

Note

The security appliance drops a packet if it does not find an ACE to explicitly permit the packet. There is an implicit deny at the end of all ACLs.

The security appliance software allows you to stop processing an ACE temporarily without removing the entry from the configuration. This is helpful if you are troubleshooting a connection issue through the security appliance and want to disable the entry. You do so by adding the inactive keyword at the end of the ACE.

Step 2: Apply an ACL to an Interface

After configuring an ACL to identify traffic allowed or denied by the security appliance, the next step is to apply the ACL to an interface in either the inbound or the outbound direction. You can apply the ACL by using the access-group command followed by the name of the ACL, as shown in the following syntax:

 access-group access-list {in | out} interface interface_name [per-user-override]

Table 5-3 lists and defines the arguments used in the access-group command.

Table 5-3. access-group Command Definition

Syntax	Description
access-group	Keyword used to apply an ACL to an interface.
access-list	The name of the actual ACL to be applied to an interface.
in	The ACL will be applied in the inbound direction.
out	The ACL will be applied in the outbound direction.
interface	Keyword to specify the interface to which to apply the ACL.
interface_name	The name of the interface to which to apply an ACL.
per-user-override	Option that allows the downloadable ACLs to override the entries on the interface ACL. Downloadable ACLs are discussed later in this chapter.

Chapter 4 "Initial Setup and System Maintenance" discussed the concept of assigning security levels to an interface. In traffic filtering, the security appliance does not block the return TCP or UDP traffic on the lower security interface if the traffic is originated from a host on the higher security interface. For other protocols, such as GRE or ESP, you need to permit the return traffic in the ACL applied on that interface. For the ICMP, you can either allow the return traffic in the ACL or enable ICMP inspection (discussed in Chapter 8, "ASA Application Inspection").

In Example 5-2, an ACL called inbound_traffic_on_outside is applied to the outside interface in the inbound direction.

Example 5-2. Applying an ACL on the Outside Interface

Chicago# configure terminal

Chicago(config)# access-group inbound_traffic_on_outside in interface outside

Note

You can only apply one extended ACL in one direction. However, an inbound and an outbound extended ACL can be applied simultaneously on an interface.

You can, however, apply an extended and an IPv6 ACL in the same direction if the security appliance is set up to be in routed mode. In transparent mode, you can apply an extended and an EtherType ACL in the same direction.

 

Step 3: Set Up an IPv6 ACL (Optional)

As discussed previously in the "Types of ACLs" section, the security appliance supports filtering IPv6 traffic that is passing through interfaces. An IPv6 ACL is defined by using the ipv6 access-list command followed by the name of the ACL. Like an extended ACL, the IPv6 ACL uses similar command options, as shown in the following syntax:

 ipv6 access-list id [line line-num] {deny | permit} {protocol | object-group

 protocol_obj_grp_id} {source-ipv6-prefix/prefix-length | any | host source-ipv6-

 address | object-group network_obj_grp_id} [operator {port [port] | object-group

 service_obj_grp_id}] {destination-ipv6-prefix/prefix-length | any | host

 destination-ipv6-address | object-group network_obj_grp_id} [{operator port [port] |

 object-group service_obj_grp_id}] [log [[level] [interval secs] | disable |

 default]]

 ipv6 access-list id [line line-num] {deny | permit} icmp6 {source-ipv6-prefix/prefix-

 length | any | host source-ipv6-address | object-group network_obj_grp_id}

 {destination-ipv6-prefix/prefix-length | any | host destination-ipv6-address |

 object-group network_obj_grp_id} [icmp_type | object-group icmp_type_obj_grp_id]

 [log [[level] [interval secs] | disable | default]]

 ipv6 access-list id [line line-num] remark text

Table 5-4 defines the unique arguments of an IPv6 ACE that are different from the ones listed in Table 5-2.

Table 5-4. IPv6 ACE Definition

Syntax	Description
ipv6	Keyword used to create an IPv6 ACL.
source-ipv6-prefix	Network or host IPv6 address from which the packet is being sent.
prefix-length	Network mask applied to an IPv6 address. It specifies how many higher-order bits compromise an IPv6 network address.
source-ipv6-address	Specifies the source IPv6 address to be filtered.
destination-ipv6-prefix	Network or host IPv6 address to which the packet is sent.
destination-ipv6-address	Specifies the destination IPv6 address to be filtered.
icmp6	Specifies that the protocol used is ICMPv6.

In Example 5-3, an ACL called inbound-ipv6-traffic-on-outside consists of two ACEs. The first ACE denies traffic from an IPv6 source fedc:ba98:1:3210:fedc:ba98:1:3210 if it is destined for a mail server (TCP port 25) located at 1080::8:800:200c:417a. The second ACE permits all mail traffic from the fedc:ba98:1:3210::/64 network if it is destined for 1080::8:800:200c:417a. The ACL is applied to the outside interface in the inbound direction.

Example 5-3. Configuring and Applying an IPv6 ACL on the Outside Interface

Chicago# configure terminal

Chicago(config)# ipv6 access-list inbound-ipv6-traffic-on-outside permit tcp host

 fedc:ba98:1:3210:fedc:ba98:1:3210 host 1080::8:800:200c:417a eq smtp

Chicago(config)# ipv6 access-list inbound-ipv6-traffic-on-outside permit tcp

 fedc:ba98:1:3210::/64 host 1080::8:800:200c:417a eq smtp

Chicago(config)# access-group inbound-ipv6-traffic-on-outside in interface

 outside