Access Control Lists (ACLs)

Access Control Lists (ACLs)

Since version 5.3 of the PIX Firewall OS, ACLs similar to the extended ACLs used on all Cisco IOS-based devices are used to control connections between inside and outside networks. Firewall access lists are created using the access-list command and applied to an interface with the access-group command.

These ACL commands replace the conduit and outbound commands used in earlier PIX Firewall versions. Remember, any access-list and access-group command statements take precedence over any conduit/outbound commands in the configuration.

Conduits are still supported in current OS versions for backward compatibility, but they’re discouraged because they offer less-specific control. A brief introduction to conduits is at the end of this section. More detailed information is available online.

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]

acl_id

ACL name. This can be either a name or a number.

permit

Used with the access-group command, permit allows the packet to traverse the PIX Firewall. Default is to deny all inbound or outbound traffic.

Used with a crypto map command, permit selects a packet for IPSec protection using the policy described by the corresponding crypto map command statements.

deny

Used with the access-group command, deny doesn’t allow a packet to traverse the PIX Firewall. Default is to deny all inbound or outbound traffic.

Used with a crypto map command statement, deny prevents the traffic from being protected by IPSec in the context of that particular crypto map entry.

protocol

Name or number of an IP protocol. Choices include one of the keywords ip, tcp, udp, icmp, or an integer (1 to 254) representing an IP protocol number. Use keyword ip to include IP, ICMP, TCP, and UDP.

source_addr

Source network or host address. Use for ACL statement with access-group, the aaa match access-list command, and the aaa authorization command.

local_addr

Network or host address local to the PIX Firewall. Use local_addr with ACL statements for a crypto access-list statement, a nat 0 access-list statement, or a vpngroup split-tunnel statement.

source_mask

Netmask mask to be applied to source_addr.

local_mask

Netmask mask to be applied to local_addr.

operator

Comparison operator: lt—less than, gt—greater than, eq—equal, neq—not equal, and range—inclusive range. ACL command without an operator and port indicates all ports by default.

port port_id

Keyword followed by port identifier. Can be a number (0 to 65,535) or a literal, such as www (port 80) or smtp (port 25).

dest_addr

Destination network or host address. Use for ACL statement with access-group, the aaa match access-list, and aaa authorization commands.

remote_addr

Network or host address remote to the PIX Firewall. Use local_addr with ACL statements for a crypto access-list statement, a nat 0 access-list statement, or a vpngroup split-tunnel statement.

dest_mask

Netmask mask to be applied to dest_addr.

remote_mask

Netmask mask to be applied to remote_addr.

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

icmp_type

Non-IPSec implementations only: to permit or deny specific ICMP message types. See the following table for a list of message types.

?

No ICMP types are supported for use with IPSec.

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.

Type

Literal

?

Type

Literal

0

echo-reply

?

12

parameter-problem

3

unreachable

?

13

timestamp-reply

4

source-quench

?

14

timestamp-request

5

redirect

?

15

information-request

6

alternate-address

?

16

information-reply

8

echo

?

17

mask-request

9

router-advertisement

?

18

mask-reply

10

router-solicitation

?

31

conversion-error

11

time-exceeded

?

32

mobile-redirect

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.

Global Compiling

TurboACL can either be configured globally, in which case it tags all ACLs with 19 elements or more for compiling, or it can be configured on a per ACL basis. Use the following syntax to configure the feature globally. Use the no form of the command to turn off the feature.

Pix(config)# access-list compiled
Pix(config)# no access-list compiled the default status

Individual ACL Compiling

Use the following command syntax to enable/disable compiling individual ACLs when TurboACL isn’t globally enabled or, if globally configured, to disable compiling individual ACLs.

Pix(config)# access-list [acl_id] compiled
Pix(config)# no access-list [acl_id] compiled

The following output shows enabling global TurboACL, and then turning the feature off specifically for ACL 105. Any ACLs with less than 19 elements also wouldn’t be compiled.

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)

Verifying and Monitoring TurboACL

The standard show access-list command displays the memory use of each compiled ACL and the shared memory use for all the turbo-compiled ACLs. The command shows the number of ACEs, the individual ACEs, and activity. The hit count (hitcnt=) is the same information as the “matches” displayed for regular ACLs. The debug access-list turbo command allows real-time monitoring.

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.

Cisco Secure ACS Configuration

Remember, as a new feature in the PIX Firewall v6.2 and Cisco Secure ACS v3.0 for Windows, changes and additional options can be expected. Be sure to check the Cisco web site for the latest instructions.

Downloading an ACL

The actual ACL entries can be named or unnamed ACLs, depending on whether the ACL will ultimately be used by multiple users. A named ACL should be used when frequent requests occur for downloading a large access list. With a named ACL, after authentication, the ACS server sends the ACL name to the PIX Firewall to see if the ACL already exists. If not, the PIX Firewall requests the ACL to be downloaded. A named ACL isn’t down loaded again as long as it exists on the PIX Firewall. Unnamed ACLs are always downloaded, so they should be used for unique or short ACLs.

Recognize that not all ACL statements supported by the Cisco IOS software are implemented the same on the PIX Firewall and vice versa. Because no immediate error or typo feedback exists when configuring an ACL on a AAA server, double-checking your work and testing your results is important.

Downloadable Named ACL

The basic Cisco Secure ACS configuration for a named downloadable ACL includes

  1. On the Shared Profile Component (SPC) menu, select Downloadable PIX ACLs.

  2. Click Add to create an ACL definition with the acl_name, description, and the ACL definition. The ACL definition consists of one or more valid PIX Firewall ACL statements, each on a separate line. Each command is entered without the keyword access-list and the acl_name (acs_1, as you see in the following). The following is an example:

    Shared profile Components
    Name: acs_1
    Description: ?Basic PIX access example
    ACL Definitions
    permit tcp any host 10.1.2.3
    permit udp any host 10.1.2.3
    permit icmp any host 10.1.2.3
     ?? (balance omitted)

    Because more than one user or group on the PIX Firewall could have the same ACL lines, the firewall creates a unique acl_id by concatenating #ACSACL#-PIX- + acl_name- + unique_num. Acl_name is the ACL name from the SPC and unique_num is a unique version ID. The following sample is downloaded from the previous entries:

    access-list #ACSACL#-PIX-acs_1-4b4119d5 permit tcp any host 10.1.2.3
    access-list #ACSACL#-PIX-acs_1-4b4119d5 permit udp any host 10.1.2.3
    access-list #ACSACL#-PIX-acs_1-4b4119d5 permit icmp any host 10.1.2.3
     ? ?(balance omitted)
  3. Use User Setup or Group Setup to include the ACL in the user/group settings.

    Next, enable downloadable ACLs by following these steps:

  4. From the ACS main menu, choose Interface Configuration.

  5. Choose Advanced Options from the resulting Interface Configuration menu.

  6. Depending on how the ACL is to be applied, check either or both of the following:

    User-Level Downloadable ACLs

    Group-Level Downloadable ACLs

Downloadable Unnamed ACL

To create a user authentication profile for downloadable unnamed ACLs, perform the following steps on the AAA RADIUS server:

  1. On Group Setup or User Setup, choose Cisco IOS/PIX RADIUS Attributes.

  2. In the cisco-av-pair field, type the ACL entries, using the following syntax:

    ip:inacl#nnn=acl_command

    ip:inacl#

    Keyword string that specifies an input ACL.

    nnn

    Integer (0 to 999999999) that creates a final sequence order for the ACL statements on the PIX Firewall. Any command with the same nnn, including the default 0, will appear in the order created.

    acl_command

    One or more ACL statements without keyword access-list or acl_name.

The PIX Firewall assigns a name to a downloaded, unnamed ACL, using the following syntax where username is the user name of the authenticated user.

AAA-user-username

The following entries demonstrate the syntax and the capability to manage the sequence of statements. This latter feature would be a tremendous improvement to regular ACLs.

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

The downloaded ACEs on a PIX Firewall would look like the following. Notice that the permit udp statement precedes the permit icmp statement because of the sequence numbers.

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

At a later time, you could add the following line to the configuration. The sequence number 3 would make it the first statement in the downloaded ACL the next time it’s called.

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



Part III: Virtual Private Networks (VPNs)