Downloadable ACLs

As seen in earlier chapters, downloadable ACLs can provide a powerful tool to network administrators for the restriction of individual users. In this section, you see more examples of the downloadable ACL and create ACLs that can be assigned to groups and individual users.

Understanding Downloadable ACLs

You don't have a lot to understand about downloadable ACLs. The basic principle behind it is that an access list is configured on the server instead of the PIX. This provides the benefit of a single point of configuration when changes need to be made to the ACL. Additionally, you need to configure the ACL only once, on one device, and you can apply the same ACL on numerous devices.

With authentication configured, when a user establishes a connection and authenticates, the PIX downloads the ACL and applies it to the user's uauth. A uauth is the user's authentication information as stored in the PIX Firewall cache. This access list functions just like a normal access list.

To give you a better understanding of how you use this type of configuration, Figure 10-2 shows the equipment that is involved with the next few examples.

Figure 10-2. Downloadable ACLs

To accomplish a successful configuration, you first determine the policy that you want to have applied to your users. In this example, the users on the 10.1.1.0/23 network are accessing the server 172.26.26.100 and 172.26.26.200 via Hypertext Transfer Protocol (HTTP); however, no other traffic is to be allowed out of the network. A special case has been made by the user "aaauser" to access File Transfer Protocol (FTP) on 172.26.26.100. When this user authenticates, a different access list is applied that allows HTTP and FTP. If the user were to move to another PC on the 10.1.1.0/24 network, the same policy should be applied.

The commands to enable the PIX to perform authentication and download the access list are as follows:

• aaa-server MYRADIUS protocol RADIUS

• aaa-server MYRADIUS (inside) host 10.1.1.100 secretkey

• aaa authentication match AUTHENTICATE-TCP inside MYRADIUS

• access-list AUTHENTICATE-TCP permit tcp any any

Creating an ACL

The next step of the process is to create the access list in the ACS. The way that you create your access list is important to the way that traffic is processed. When an access list is searched, most Cisco devices perform a linear search, as does the PIX. This means that the first match that the PIX comes across in the list is the one that is acted upon, regardless of whether a more specific statement exists later in the list.

Other considerations to building your access list should be the following:

• In an access list, the source IP address comes before the destination IP address.

• The PIX Firewall does not use wildcard masks; rather, a standard subnet mask in the access list does the job.

• The two options that an access list can perform are permit or deny.

• The protocol that you define can be Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP), Encapsulating Security Payload (ESP), Generic Routing Encapsulation (GRE), or any, to name a few. You could also use an IP protocol number here.

• Beyond protocols, you can place port numbers or services in the access list. Some examples of port numbers are 23 (Telnet), 80 (HTTP), 443 (SSL [Secure Sockets Layer]), 500 (Internet Security Association Key Management Protocol [ISAKMP] and 25 (SMTP [Simple Mail Transport Protocol]).

The following is the general PIX syntax of an IP access list:

 access-list acl_ID deny | permit protocol source_addr source_mask [operator   port[port]]destination_addr destination_mask operator port [port] 

It is good to be familiar with this format as the configuration of access lists in the downloadable IP ACL is very similar. The format of a downloadable IP ACL is as follows:

 {Permit|deny} protocol_type source_ip source_mask destination_ip destination_mask   [protocol specific options] 

The major difference here is that in entering the ACL definitions in the ACS interface, you do not use acl_ID; rather, you begin with a permit/deny.

An example of a downloadable IP ACL is shown in Example 10-1.

Example 10-1. Downloadable IP ACL

 permit udp any host 11.0.0.254 permit icmp any host 11.0.0.254 permit tcp any host 11.0.0.253 permit tcp any host 11.0.0.254 

Using standard RADIUS Cisco AV pairs permits you to enter a maximum of 4 kilobytes of ACLs; the downloadable PIX ACLs can be of unlimited size. This 4-kilobyte limit is a RADIUS limitation.

Working with ACLs After They Are Created

Access lists entered into ACS are protected by whatever backup or replication regime you have established for the ACS. Chapter 11, "System Configuration," discusses this in detail.

After you configure an access list as a named shared profile component, you can include that access list in any Cisco Secure ACS (CSACS) user, or user group, profile. This feature makes for a very modular configuration. This also saves configuration time when the access list applied is common to numerous users or groups.

When CSACS returns an attribute with a named access list as part of a user session RADIUS access accept packet, the PIX Firewall applies that access list to the session of that user. CSACS employs a versioning stamp for ensuring that the PIX Firewall has cached the latest access list version. If a PIX Firewall responds that it does not have the current version of the named access list in its cache, CSACS automatically uploads the current version of the access list to the PIX Firewall cache. When this ACL is downloaded to the PIX Firewall, it is applied to a user's uauth; however, if an ACL exists on an interface, the interface ACL takes precedence over the ACL applied to the uauth.

After you configure a downloadable PIX ACL, it can be applied against any number of single users or user groups. The option needs to be enabled in interface configuration to make this visible in the interface.