Chapter 6: Access Control (Part 1)
[4/04/2011 02:59:00 PM | ]

Overview

In the previous chapter, I talked about some of the security appliance commands to perform address translation, like global, nat, and static. This chapter will expand on the topic of controlling traffic through the appliance, discussing these topics:

  • Using access control lists (ACLs) to filter traffic through the appliance

  • Using object groups to simplify the management of ACLs

  • Filtering ICMP packets destined to an appliance

  • Troubleshooting connections using the packet tracer and packet capture features


Access Control Lists (ACLs)

Add a note hereBeginning with version 5.3, Cisco introduced ACLs to standardize the implementation of filters on the appliances. The term “ACLs,” even though it is an acronym, is sometimes pronounced as a word: “ackles.” Before ACLs, Cisco PIXs used conduits and outbound filters. Conduits were used to allow inbound connections, and outbound filters were used to restrict outbound connections. Conduits and filters had some major limitations in their filtering abilities. Therefore, Cisco ported their ACL technology from the IOS-based routers to the PIX platform. All three filtering features—ACLs, conduits, and outbound filters—were supported through version 6. Starting in version 7, conduits and outbound filters are no longer supported: you must use ACLs to filter traffic through your appliances.

Add a note hereAs you will see throughout this section of the book, ACLs have many components in common with the implementation of ACLs on Cisco IOS routers. For example, you’ll have to go through two steps to set up and activate your ACLs—create the ACL and apply it to an interface. However, differences exist in the configuration and operation of ACLs on the appliances when compared with IOS routers.

Add a note here Introduction to ACLs

Add a note hereACLs on Cisco IOS-based routers and on the appliances are very similar in their function, processing, and configuration. Since conduits and outbound filters are no longer supported on the appliances, you must use ACLs to exempt inbound connections and to control outbound connections.

Appliance and IOS Router ACL Comparison

Add a note hereCisco is attempting to move to a more uniform command-line interface across its networking products, which you can see with the ACL commands on the appliances. This section will cover both the many similarities and a few differences between ACLs on the appliances and ACLs on IOS routers.

Add a note here If you’ve configured ACLs on IOS routers in the past, learning to use ACLs on the appliances will be easy. Here are some of the ACL features the two products have in common:

  • Add a note hereA grouping of ACLs is labeled with a group identifier.

  • Add a note hereBoth standard and extended ACLs are supported (standard ACLs are new in version 7.0).

  • Add a note hereACLs are activated on an interface in either an inbound or outbound direction.

  • Add a note hereThe general syntax of the statements is the same.

  • Add a note hereEach statement has a counter that keeps track of the number of matches on the statement.

  • Add a note hereEach statement can have logging enabled, displaying a summary of the packet that matched on the statement.

  • Add a note hereStatements are processed in a top-down order, starting with the first statement, until a match is found.

  • Add a note hereAn invisible statement, called the implicit deny statement, is at the end of the list and will drop traffic if it doesn’t match any other statement in the list.

  • Add a note hereWhen adding statements to a list, statements are added at the end of the list by default.

  • Add a note hereWhen editing ACLs, you can delete specific statements and insert statements into the list.

  • Add a note hereYou can have multiple remarks in your ACLs.

  • Add a note hereACL statements can be enabled or disabled based on the current date and time (referred to as a timed ACL entry).

  • Add a note hereACLs can be used for functions other than filtering, such as classifying traffic for other features like address translation, VPNs, and so on.

Add a note here Table 6-1 covers some of the differences between ACLs on appliances and IOS routers.

Add a note here Table 6-1: Comparing ACLs on Appliances and IOS Routers

Add a note hereComponent

Add a note hereAppliances

Add a note hereIOS Routers

Add a note hereACL identification

Add a note hereACLs can be identified with a name or number.

Add a note hereNamed ACLs must use names, and numbered ACLs must use numbers.

Add a note hereActivating ACLs

Add a note hereA global command is used to activate an ACL.

Add a note hereACLs are activated in an interface subcommand mode.

Add a note hereMatching on a range of addresses

Add a note here Subnet masks are used.

Add a note here Wildcard masks are used.

Add a note hereLogging of statement matches

Add a note hereWhen the same source is continually matching on a statement, you can control the period that a message should be regenerated as well as controlling the number of log messages generated by a statement within a period, no matter how many sources are matching on it.

Add a note hereWhen the same source is continually matching on a statement, a message is generated either every 5 minutes or every x packets that match.

Add a note hereInserting ACL statements

Add a note hereACL statements are numbered sequentially from 1 (1, 2, 3, 4...); to insert a statement, specify the exact line number the statement should be placed in.

Add a note hereACL statements are numbered in increments (like 10, 20, 30, 40...); to insert a statement, use a line number that doesn’t currently exist in the ACL.

Add a note hereFiltering traffic

Add a note hereACLs applied to interfaces filter traffic flowing through the appliance, not to the appliance.

Add a note hereACLs applied to interfaces filter traffic to and through the router.

Security Alert!

Add a note hereThere are two main differences between ACLs on appliances and those on IOS routers. First, remember that appliance ACLs use subnet masks, not wildcard masks, when matching on packet addressing contents. Second, appliance ACLs filter traffic flowing through the appliance, not to it. Other commands on the appliance filter traffic sent to an IP address on the appliance.

Processing of ACLs

Add a note hereIn Chapter 5, I went through a simple example of TCP traffic flowing through the appliance in the “TCP Connection Example” section. I’ll build on this topic to give you a better understanding of what the appliance is doing to packets as they enter and leave its interfaces. Here are the steps that a packet will go through upon entering an interface:

  1. Add a note hereThe appliance compares the packet information to the existing connections to the state table to determine if the packet is a new, or is part of an existing, connection. If it’s an existing connection, the packet is allowed through, and the remainder of the ACL checks listed here are bypassed.

  2. Add a note here Assuming address translation is enabled, this step is performed. For inbound connections, the destination address is compared with the translation policies to make sure that it can be translated. For outbound connections, the destination address is compared with the translation policies to make sure that it can be translated. If there is no matching translation policy, the packet is dropped. Note that translation doesn’t actually occur at this step.

  3. Add a note hereIf this is an inbound packet, the packet must match a permit ACL statement applied inbound on the incoming interface; otherwise the packet is dropped. If this is an outbound packet and no ACL exists, traffic is allowed to go from a higher to a lower security level by default; otherwise, if an ACL exists inbound on the interface, the packet must match a permit ACL statement or it is dropped.

  4. Add a note hereThe appliance then does a route lookup to determine the exit interface the appliance should use. This is necessary to determine the ACLs to process and to perform address translation, if enabled.

  5. Add a note hereAssuming that address translation has been configured, the destination addressing information is untranslated with a static command or translated with the nat and global commands.

  6. Add a note hereIf an ACL exists outbound on the exit interface, then this is processed.

  7. Add a note hereAt this point the connection is added to the conn table and is tracked.

Add a note hereThe appliance might perform additional steps on the packet, but I’ll discuss these in Part III of the book concerning the implementation of policies.

Add a note here Creating and Activating ACLs

Add a note hereThe configuration of ACLs on your appliance is very similar to configuring ACLs on an IOS-based router. The configuration process involves two steps: create your filtering rules with the access-list commands, and activate your filtering rules on an interface with the access-group command. The following sections cover the configuration of standard and extended ACLs, as well as some ACL features like timed ACL entries, logging matches on ACLs, and updating ACLs.

Standard ACLs

Add a note hereLike IOS routers, appliances support standard ACLs, which filter packets based on only an address or addresses. However, standard ACLs on appliances cannot be used to filter traffic entering or leaving an interface; instead, standard ACLs are used with other features, like split tunneling with remote access VPNs, or filtering routes when performing redistribution, and many others. Only extended and EtherType ACLs can be used on the appliances to filter traffic through the appliance interfaces.

Add a note hereHere is the syntax for creating a standard ACL:

Add a note hereciscoasa(config)# access-list ACL_ID standard [line line_#]
                       {deny | permit} {any | host IP_addr |
                       IP_addr subnet_mask}

Add a note here On the appliance, each ACL is differentiated from other ACLs by a unique identifier (ACL_ID): this can be a name, number, or mixture of characters and numbers. You must use the standard parameter; otherwise the ACL type defaults to an extended ACL. If you don’t tell the appliance what line number to use for the statement, the statement is added at the end of the existing ACL statements. Next you need to specify what should happen when there is a match on the condition: allow (permit) or drop (deny) the packet. Last, you specify the address you want to match on:

  • Add a note here any Any packet matches.

  • Add a note here host IP_addr Only that particular IP address matches.

  • Add a note here IP_addr subnet_mask Only the specified range of addresses matches.

Add a note hereRemember that you need to configure a subnet mask, not a wildcard mask, when matching on a range of addresses.

Extended ACLs

Add a note hereThe primary use of extended ACLs is to filter traffic, but they can be used for other features on the appliances. Here is the syntax for configuring an extended ACL:

Add a note hereciscoasa(config)# access-list ACL_ID [extended] {deny | permit]
                       IP_protocol
                       {src_addr subnet_mask | host src_addr |  any}
                            [protocol_info]
                       {dst_addr subnet_mask | host dst_addr |  any}
                            [protocol_info]
                       [disable | default]

Add a note hereThe first part of the ACL syntax is similar to a standard ACL. If you omit the extended parameter, the ACL defaults to an extended ACL. Unlike with a standard ACL, you must specify either the name or number of the TCP/IP protocol you want to filter, like tcp, udp, icmp, and others. If Cisco doesn’t have a name for a particular protocol, you can enter a number instead. To match on any TCP/IP packet, use a protocol name of ip. For a complete listing of IP protocol numbers, visit http://www.iana.org/assignments/protocol-numbers.

Add a note hereFollowing the IP protocol designation, you need to specify the source IP addressing information that you want to match on. The syntax for this was discussed previously in the “Standard ACLs” section. If you are filtering on TCP or UDP traffic, you can also specify the source port or ports you are interested in matching on. Following this is the destination address and, optionally, destination protocol information.

Add a note hereIf you are filtering TCP or UDP traffic, you can specify an operator and a port number or name to be specific about the traffic that is to be filtered. You can specify an operator and the port name or number, or a range of numbers. Operators include eq (equal to), neq (not equal to), lt (less than), gt (greater than), and range. To specify a range of port numbers or names, enter the beginning and ending port numbers or names, and separate them with a hyphen with no spaces between the hyphens and the ports. If you omit the port information, the appliance assumes that you are talking about all ports for the specified protocol and address. For information about valid port numbers, visit http://www.iana.org/assignments/port-numbers.


Tip

Add a note hereRemember that the appliances process filter functions like ACLs before any address translation is performed, so you should place the source address in the ACL that the appliance will see in the actual packet header. For example, if a server has a private address of 192.168.1.1, but is represented by a public address of 200.1.1.1, and the appliance is doing translation, then your ACL needs to permit traffic to 200.1.1.1. Here would be the static configuration: static (inside,outside) 200.1.1.1 192.168.1.1. In this example, when traffic enters the outside interface, the appliance is looking at a destination address of 200.1.1.1. Once passed the ACL check, the appliance will translate it to the server local address, 192.168.1.1.

Add a note hereFor ICMP traffic, you can specify an ICMP message type (either by name or number) following the destination address. If you omit the message information, the appliance assumes that you are talking about all ICMP messages. Remember that for ICMP traffic, the appliance is not stateful by default; in version 6 and earlier, the PIXs were never stateful for ICMP. Therefore, if you want ICMP replies to your users’ traffic and tests, and stateful processing of ICMP is disabled or unavailable, then you need to explicitly permit ICMP traffic with an ACL applied on the interface where the returning replies are received. Typically you’ll want to allow echo reply, unreachable, time exceeded, and TTL exceeded messages. For information about ICMP message types, visit http://www.iana.org/assignments/icmp-parameters.

Add a note hereThe disable parameter allows you to disable the specified ACL statement while still keeping it in the ACL—this is handy if you want to temporarily disable a statement to allow (or deny) certain connections, but then want to re-enable the statement once the connection(s) complete. The default parameter sets the ACL statement back to its default configuration.

ACL Activation

Add a note hereOnce you have created your ACL, you need to activate it on an interface. The following is the syntax of the access-group command that you need to use to activate your ACL:

Add a note hereciscoasa(config)# access-group ACL_ID {in | out}
                       interface logical_if_name
                       [per-user-override | control-plane]

Add a note hereThe ACL_ID specifies which ACL you are activating. Before version 7.0, you could only activate an ACL inbound on an interface (in parameter). Starting in version 7.0, you can activate an ACL inbound (in— as traffic enters the interface) and/or outbound (out—before traffic leaves the interface). After the interface parameter, you need to specify the logical name of the interface where this ACL is to be activated. To remove an ACL applied to an interface, precede the access-group command with the no parameter.

Add a note hereThe per-user-override parameter is used with downloadable ACLs (discussed in Chapter 8). The control-plane parameter is used to restrict traffic to the appliance itself: the latter is new in version 8.0.