|
|
Firewall security policies are heavily based on strict access control. Network access can be controlled using access lists on the Security Appliance. Access lists can be configured to filter network traffic as it passes through the firewall.
Access lists specify criteria for a packet to be permitted or denied and are based on a protocol, a source and destination IP address or network, and optionally, the source and destination ports. Refer to Chapter 2, "Access Control," for more details on using access lists for traffic filtering.
Access lists have many applications and can be used in a variety of functions on the Security Appliance, including the following. The first is the most important:
ACLs can be used to control traffic flow in both routed and transparent firewall modes. The following section describes the difference between inbound and outbound ACL in the context of the Security Appliance and how to control network access through the appliance using access lists.
Note
Transparent mode supports two types of access lists: Extended ACLs used for Layer 3 traffic filtering and EtherType ACLs used for Layer 2 traffic filtering.
Traffic can be examined in either direction on an interface, by using an inbound ACL for traffic entering into the Security Appliance and an outbound ACL for traffic exiting the Security Appliance. The main things to understand about the access list application on Security Appliance are the following:
For traffic originating from a lower-level interface to a higher-level interface, an inbound ACL is required on the source interface to specifically allow the traffic (or else the packet will be dropped). An optional outbound ACL can be configured on the destination interface. Refer to Figure 6-19.
For traffic originating from a higher-level to a lower-level interface, no access list is required, because traffic is permitted by default. This is also true for all returning traffic originally initiated from a higher-level to a lower-level interface, which is allowed through dynamically. An optional inbound ACL on the source interface and outbound ACL on the destination interface can be configured. Refer to Figure 6-19.
By default, traffic can exit the Security Appliance on any interface unless it is restricted through the use of an outbound ACL, which provides more granular access control in addition to the inbound ACL.
The access list architecture on the Security Appliance is similar to the IOS ACL operation.
To enable an access list for network access control on the Security Appliance, perform the following two steps. Configuring an access list on Security Appliance is similar to Cisco IOS.
Using the access-list command from the global configuration mode, define access control entries (ACE) for a specific host, network, protocol, or ports. When defining an ACL on a Security Appliance, use a subnet mask rather than a wildcard mask on the IOS device. This works in a manner that is similar to the IOS, in that there is an implicit deny at the end of all access lists.
Apply the access list to the interface in an inbound or outbound direction by using the access-group {name | number} {in | out} interface interface_name command. One access list of each type (Extended and EtherType) can be applied to both directions of an interface.
Example 6-20 shows how to configure an inbound ACL for network access from the lower level (outside interface) to a higher level (inside interface) to a web server with IP address 209.165.201.1. (This is a statically translated address that is visible on the outside interface.) ACL is applied to the outside interface filtering inbound traffic through the firewall.
|
Code View: hostname(config)# static (inside,outside) 209.165.201.1 10.1.1.1 netmask 255.255.255.255 hostname(config)# access-list 101 extended permit tcp any host 209.165.201.1 eq www hostname(config)# access-group 101 in interface outside |
Example 6-21 shows how to configure an outbound ACL for granular network access control from a higher level (inside interface) to a lower level (outside interface), thereby preventing internal hosts 10.1.1.0/24 from accessing the external 209.165.202.128/27 network. All other traffic is explicitly permitted. The access list is applied on the outbound direction to the outside interface (destination interface for exiting packets). Alternatively, the same access list can be applied on the inbound to the inside interface (source interface for arriving packets) to achieve the same results.
hostname(config)# access-list 102 extended deny tcp 10.1.1.0 255.255.255.0 209.165.202.128 255.255.255.224 hostname(config)# access-list 102 extended permit ip any any hostname(config)# access-group 102 out interface outside ! or apply inbound on source interface hostname(config)# access-group 102 in interface inside |
Tip
Remember that configuring outbound ACL is optional and not required, as shown in Figure 6-19.
Access lists can be long and cumbersome to create and maintain for medium-to-large enterprise networks. ACL configuration can be repetitive and difficult to troubleshoot when a problem occurs. A simpler and more effective approach is to group like objects together and reference them in the ACL. Object grouping simplifies access list creation and maintenance.
Following are four types of object groups:
Protocol: A protocol-type object group is used to define the protocols (for example, ICMP, TCP, or UDP). Use the object-group protocol grp_id command and define the protocols by using the protocol-object {protocol} in the object-group submode. The protocol is the numeric identifier of the specific IP protocol (1 to 254) or a keyword identifier (example TCP, UDP). To include all IP protocols, use the keyword IP.
Network: To add a network group, use the object-group network grp_id command and define the hosts or networks by using network-object {host host_addr | net_addr mask} in the object-group submode.
Service: To add a service group, use the object-group service grp_id {tcp | udp | tcp-udp} command. Specify the protocol for the services (ports) you want to add, by using either tcp, udp, or tcp-udp keywords. Enter the tcp-udp keyword if your service uses both TCP and UDP with the same port number—for example, DNS (port 53). Define the ports or range of ports by using port-object in the object-group submode.
ICMP type: To add an ICMP type group, use the object-group icmp-type grp_id command. Define the ICMP types by using icmp-object icmp_type (example, echo or echo-request) in the object-group submode.
To use object groups in an access list, replace the normal protocol (protocol), network (source_address mask, and so on), service (operator port), or ICMP type (icmp_type) parameter with object-group grp_id parameter.
It is not compulsory to use object groups for all parameters within the access list. For example, object groups can be used to group certain hosts/networks to be referenced in the source address parameter, or group like services together to reference in the operator port parameter, and so on. Object groups simplify configuration and allow easy modifications to add, update, and remove entries at a later stage.
To illustrate the benefit of using an object group, observe the access list 101 shown in Example 6-22, which has 10 lines of deny statements to web servers from selected hosts and networks. There are many repetitive entries that could be grouped together. Example 6-23 creates two object groups to cover the repetitions in these 10 lines, consolidating it into one single access list line by referencing these object groups, condensing the configuration as shown in Example 6-24.
access list 101 remark - ACL with no object groups access-list 101 deny tcp host 10.1.1.52 host 209.165.201.1 eq www access-list 101 deny tcp host 10.1.1.52 host 209.165.201.2 eq www access-list 101 deny tcp host 10.1.1.13 host 209.165.201.1 eq www access-list 101 deny tcp host 10.1.1.13 host 209.165.201.2 eq www access-list 101 deny tcp host 10.1.1.15 host 209.165.201.1 eq www access-list 101 deny tcp host 10.1.1.15 host 209.165.201.2 eq www access-list 101 deny tcp 10.1.2.0 255.255.255.0 host 209.165.201.1 eq www access-list 101 deny tcp 10.1.2.0 255.255.255.0 host 209.165.201.2 eq www access-list 101 deny tcp 10.1.5.0 255.255.255.0 host 209.165.201.1 eq www access-list 101 deny tcp 10.1.5.0 255.255.255.0 host 209.165.201.2 eq www access-list 101 permit ip any any |
Example 6-23 shows creating two network-type object groups named denyhosts that include the host and network addresses used in the source address parameter and object group named webserver, which defines the two web servers used in the destination address parameter.
! Define Network Object Group denyhosts hostname(config)# object-group network denyhosts hostname(config-network)# description Deny Addresses hostname(config-network)# network-object host 10.1.1.13 hostname(config-network)# network-object host 10.1.1.15 hostname(config-network)# network-object host 10.1.1.52 hostname(config-network)# network-object 10.1.2.0 255.255.255.0 hostname(config-network)# network-object 10.1.5.0 255.255.255.0 ! Define Network Object Group webserver hostname(config-network)# object-group network webserver hostname(config-network)# description Web Servers hostname(config-network)# network-object host 209.165.201.1 hostname(config-network)# network-object host 209.165.201.2 |
As shown in Example 6-24, you should reference these network object groups in the access list, thereby consolidating the deny statements into one single line.
|
Code View: hostname(config)# access-list 101 deny tcp object-group denyhosts object-group webserver eq www hostname(config)# access-list 101 permit ip any any |
Use the show object-group [protocol | network | service | icmp-type | id grp_id] command to display a list of the currently configured object groups.
|
|