Access Control Lists (ACLs)

Using Access Lists

If internal users could be allowed to venture unrestricted into less-secure areas, bringing back whatever they find, and outside access to the network was absolutely forbidden, it might be possible to get by without using ACLs.

The PIX Firewall is designed around the default of absolute security, but it does allow for exceptions to be specifically configured using access lists. By default, traffic can flow freely from inside to outside, or from higher security to lower, except that specifically denied by an access list. Also, by default, all traffic from the outside toward the inside, lower security to higher, is blocked except that permitted by access lists.

Properly crafted access lists, applied to the proper interfaces, should allow for creating just the right exceptions to maintain acceptable security, while enabling activities that are required to further the organization’s mission. All exceptions created with access lists should conform to the security policy. In the next sections, you see a variety of access list implementations.

Access-Group Statement

Use the configuration mode access-group command to apply an access list to an interface. The ACL is applied to inbound traffic of the interface. If the matching ACL statement is a Permit option, PIX allows the packet. If the matching ACL statement is a Deny option or no matching statement exists, PIX discards the packet and generates a syslog message. Use the no form of the command to remove the entry. The syntax is

Pix(config)# access-group acl_id in interface int_name
Pix(config)# no access-group acl_id in interface int_name

An access-group command always overrides the conduit and outbound command statements for the specific interface.

The show access-group command displays the current access list applied to interfaces.

In the following example, the static command creates a global address of 1.1.1.3 for a DMZ web server at 192.168.2.3. The access-list statement allows any outside host to access the global address for the web server using port 80 (www). The access-group command applies the access list to traffic entering the outside interface.

Pix(config)# static (dmz,outside) 1.1.1.3 192.168.2.3
Pix(config)# access-list www_ok permit tcp any host 1.1.1.3 eq www
Pix(config)# access-group www_ok in interface outside

Basic ACL Statements

PIX ACLs can be used to control connections based on source address, destination address, or protocol information. Because many ACLs are created to allow outside access into the more secure areas of the network, configuring them carefully to allow only the minimum access required is important. Whenever possible, configure ACLs more restrictively by specifying a remote source address, local destination address, and the protocol used, thereby reducing the likelihood of unwanted additional traffic. The any and host keywords are implemented the same as in IOS ACLs. Use the no form of the command to remove the ACL entry. The basic syntax is

Pix(config)# access-list acl_id {deny | permit} protocol {source_addr | local_addr}
{source_mask | local_mask}[operator port [port_id] {dest_addr | remote_addr}
{dest_mask | remote_mask} [operator port [port_id]

In the following example, a static mapping is created for a server, and then outside users are allowed to access that global address for web and FTP activities.

Pix(config)# static (dmz,outside) 1.1.1.3 192.168.2.3
Pix(config)# access-list tcp_ok permit tcp any host 1.1.1.3 eq www
Pix(config)# access-list tcp_ok permit tcp any host 1.1.1.3 eq ftp
Pix(config)# access-group tcp_ok in interface outside

ICMP ACL Statements

ASA prohibits ICMP traffic through the firewall by default. The last chapter covered managing ICMP traffic and specifically targeting interfaces on the PIX device. In this chapter, you learn about Access-List options used to allow specific ICMP traffic to pass through the PIX Firewall.

Use the following form of the access-list command to allow specific ICMP traffic. The any and host keywords are implemented the same as in IOS ACLs. Use the no form of the command to remove the ACL entry. The basic syntax is

pix(config)# access-list acl_id {deny | permit} icmp {source_addr | local_addr}
{source_mask | local_mask} {dest_addr | remote_addr} {dest_mask | remote_mask}
icmp_type

The following table lists possible ICMP type values and their literal equivalents. Either form can be used, but the literal list is easier for the humans to interpret.

The following example creates three static mapping for servers, allows three types of ICMP messages, and then allows outside access to the server global addresses.

Pix(config)# static (dmz,outside) 1.1.1.3 192.168.2.3 netmask 255.255.255.255
Pix(config)# static (dmz,outside) 1.1.1.4 192.168.2.4 netmask 255.255.255.255
Pix(config)# static (dmz,outside) 1.1.1.5 192.168.2.5 netmask 255.255.255.255
Pix(config)# access-list 101 permit icmp any any echo-reply
Pix(config)# access-list 101 permit icmp any any time-exceeded
Pix(config)# access-list 101 permit icmp any any unreachable
Pix(config)# access-list 101 permit tcp any host 1.1.1.3 eq www
Pix(config)# access-list 101 permit tcp any host 1.1.1.4 eq ftp
Pix(config)# access-list 101 permit tcp any host 1.1.1.5 eq smtp
Pix(config)# access-group 101 in interface outside

TurboACL

Traditional ACLs are composed of a series of permit or deny statements each with one or more test criteria, such as source and destination addresses and possibly protocols. These statements are processed sequentially from top to bottom, based on the order of creation. Logically, the longer the list of statements and the more elements that must be matched, the longer it can take to process. When an ACL statement is processed by the device, each line must be processed by a command interpreter that converts the text into computer code.

Long ago, programmers learned that text instructions can be compiled by a computer one time to put the same information in a form that can be processed much more quickly. The real benefit to compiling is when the same instructions are used frequently. The PIX Firewall version 6.2 introduced TurboACL, which compiles ACLs into a set of binary lookup tables, while maintaining first-match requirements. Because compiling only makes significant improvements on larger ACLs, TurboACL only works on ACLs with 19 or more statements and supports access lists with up to 16,000 statements.

The TurboACL feature requires significant memory resources, including a minimum of 2.1MB, plus approximately 1MB of memory for every 2,000 ACL statements. The feature requiring a minimum of 16MB of Flash combined with the memory requirements is designed for the high-end PIX Firewall models, such as the PIX 525 or the PIX 535.

Pix(config)# access-list compiled
Pix(config)# no access-list 105 compiled 
Pix(config)# access-list 101 permit icmp any any echo-reply
Pix(config)# access-list 101 permit icmp any any time-exceeded
Pix(config)# access-list 101 permit icmp any any unreachable
Pix(config)# access-list 101 permit tcp any host 1.1.1.3 eq www
Pix(config)# access-list 101 permit tcp any host 1.1.1.4 eq ftp
Pix(config)# access-list 101 permit tcp any host 1.1.1.5 eq smtp
Pix(config)# access-group 101 in interface outside
 ? ??(additional lines omitted)

Pix# show access list
TurboACL statistics:
ACL ???? ? ?? ?? ? ? ?State ?? ? ?Memory (KB)
--------------------- ----------- ----------
test1_acl ? ?? ??? ???Operational ??5 ????? ? 
test2_acl ?? ? ??? ?? Operational ??2 ? ? ??? 
Shared memory usage: 2046 KB
access-list compiled
access-list test1_acl turbo-configured; 19 elements
access-list test1_acl permit tcp any host 10.1.2.3 (hitcnt=19) 
access-list test1_acl permit tcp any host 10.1.2.4 (hitcnt=7) 
access-list test1_acl permit tcp any host 10.1.2.5 (hitcnt=0) 
access-list test1_acl permit tcp any host 10.1.1.1 eq telnet (hitcnt=8) 
access-list test1_acl permit udp any host 10.1.2.3 (hitcnt=4)
 ? ??(additional lines omitted)

Downloadable ACLs

In Chapter 8, you learned about the CBAC Authentication Proxy feature of the Cisco Secure IOS PIX feature set. This feature allowed ACEs to be downloaded on a per-user or a per-group basis from an AAA server. These ACEs were based on either user or group profile entries added to the Cisco Secure ACS configuration.

The PIX Firewall version 6.2 introduced a similar feature when using a RADIUS server for AAA and Cisco Secure ACS 3.0 or later (Windows). Access lists are configured on the AAA server, and then downloaded to a PIX Firewall during user authentication, eliminating the need to be configured separately on the PIX Firewall. This feature improves scalability when using access lists for individual users. Currently, the feature isn’t supported for TACACS+ servers or UNIX ACS.

No additional configuration is needed for the firewall once AAA authorization is configured. The next chapter looks at configuring the Cisco Secure ACS server. Adding downloadable ACLs is covered briefly then.

ip:inacl#5=permit tcp any host 10.1.2.3
ip:inacl#15=permit icmp any host 10.1.2.3
ip:inacl#10=permit udp any host 10.1.2.3
ip:inacl#100=deny tcp any any
ip:inacl#100=deny udp any any

access-list aaa-user-jkeely permit tcp any host 10.1.2.3
access-list aaa-user-jkeely permit udp any host 10.1.2.3
access-list aaa-user-jkeely permit icmp any host 10.1.2.3
access-list aaa-user-jkeely deny tcp any any
access-list aaa-user-jkeely deny udp any any

ip:inacl#3=deny tcp 10.5.5.0 255.255.255.0 host 10.1.2.3