......update soon ......
----------------------------------------------------------------------------------------------------------------------
6-3: Controlling Access with Access Lists
On a Cisco firewall, you can use access lists to filter traffic coming into or out of a firewall interface. Access lists that are applied to interfaces become an integral part of the traffic inspection mechanism.
Access lists can be defined using the familiar Cisco IOS Software ACL format. However, one important difference exists between the firewall and IOS ACL formats: Firewalls use real subnet masks (a 1-bit matches, a 0-bit ignores), while IOS platforms use a wildcard mask (a 0-bit matches, a 1-bit ignores). For example, the subnet 192.168.199.0/24 would be configured as 192.168.199.0 255.255.255.0 on an ASA or FWSM, and as 192.168.199.0 0.0.0.255 on an IOS platform.
Access lists are configured one line at a time; every line that makes up a single access list must have an identical ACL name. Each line of an access list is called an Access Control Entry (ACE).
Cisco firewalls also offer an ACL configuration feature not found in the IOS Software. Access lists can be configured in a modular fashion, using defined object groups as a type of macro. Object groups are discussed in detail in the “Defining Object Groups” section.
Compiling Access Lists
Access lists are normally evaluated in sequential order, as they appear in the firewall configuration. As access lists grow in length, the amount of time needed to evaluate the ACEs in sequence can also grow. Fortunately, the ASA and FWSM platforms compile access lists into a more efficient Turbo ACL format. On a PIX platform, you can compile ACLs beginning with release 6.2. Once compiled, access lists can be evaluated in a deterministic fashion, without the need to work through each ACE in sequence. In other words, the time required to find and evaluate any specific ACE within the entire access list is more or less constant.
In PIX releases 6.2 and 6.3, access lists must have at least 19 ACEs before they can be compiled into the Turbo ACL format. If they have less than 19 entries, it becomes more efficient for the firewall to evaluate them sequentially. As well, compiled ACLs are stored in Flash memory so that they can be retrieved in their native compiled format even after a reboot.
On a PIX platform, TurboACLs can be compiled when they are first configured, and at most every time when they are edited thereafter. ASAs running 7.0 or later automatically compile access lists immediately after they are edited or configured—usually after every ACE is entered. This is important because any configuration changes you make to ACLs take effect right away. This process is completely hidden, so that you are never aware that an ACL is compiled or not. It simply exists in human-readable form in the firewall configuration.
A FWSM automatically compiles and applies ACLs in real-time by default too. However, you can configure it to use manual compilation instead.
Recompiling an ACL is a silent process, but can burden an already loaded firewall CPU. For this reason, you might choose to manually compile and apply ACL changes so that the only occur at predetermined times. For example, you might plan on making changes to large ACLs during a time of low traffic through the firewall or during a scheduled maintenance window.
On a FWSM, you can use the following command to see whether ACLs are compiled automatically or manually:
You can use the following command to configure whether access lists will be compiled automatically (the default) or manually:
In the manual-commit mode, you have to manually compile and commit ACLs to FWSM memory after they are edited, in order for them to be updated and used. If you forget to commit the ACL changes, the FWSM keeps using the previously compiled ACL contents it already has in memory. The following configuration command can be used to commit all access lists configured on the FWSM:
Configuring an Access List
You can use the steps presented in this section to configure a firewall access list. The access list exists in the firewall configuration, but does not actively do anything until you apply it to a firewall interface or to some other firewall function.
Access lists are defined simply by entering ACE commands in global configuration mode. There is no need to define the access list name first; just the action of entering an ACE with an ACL ID acl_id (an arbitrary text name) is enough to make it a part of that access list. However, as soon as an access list is defined with at least one ACE, the order the ACEs are entered becomes important.
When you enter a new ACE into the configuration, it is always appended to the end or bottom of the access list. Therefore, the order that ACEs appear in an access list is important. This is because access lists are evaluated line-by-line, in sequential order. To designate an ACE’s exact position within a whole access list, you can specify a line number as part of the ACE configuration.
In addition, every access list ends with an implicit, hidden deny ip any any ACE. Even though a newly configured ACE is appended to the bottom of the access list, the implicit deny ACE always comes after that. In effect, anything that is not explicitly permitted by an ACE somewhere in the access list will be denied by this final implicit ACE.
Adding an ACE to an Access List
You can define an access list entry with the following configuration command:
Although the command syntax looks complex, the concept is simple: Either permit or deny traffic from a source (using an optional source port) to a destination (using an optional destination port). An access list can be built from many different keywords and parameters. You might find Figure 6-11 helpful, as it shows the basic ACE syntax and how each portion can be configured.
To simplify complex traffic definitions, you can also define groups of parameters as object groups; the object groups are then referenced in the ACE configurations. (Object groups are covered in the “Defining Object Groups” section in this chapter.)
| Tip | You can use a similar ACE command syntax to create an access list for IPv6 traffic. Use the following guidelines when you adapt the syntax for IPv6: |
-
Use the ipv6 access-list command keywords instead of access-list.
-
Whenever an IP subnet is given with source_addr source_mask or destination_addr destination_mask, substitute the IPv6 address prefix as source_ipv6_prefix/prefix_length or destination_ipv6_prefix/prefix_length.
-
Whenever specific host addresses are needed, substitute host ip_address with host ipv6_address.
First, begin by identifying the protocol of interest. The matched protocol can be ip (any IP protocol), icmp (1), tcp (6), udp (17), ah (51), eigrp (88), esp or ipsec(50), gre or pptp(47), igmp (2), igrp (9), ipinip (4), nos (94), ospf (89), pim (103), pcp (108), or snp (109). You can also specify the protocol as a decimal number (0-255) to identify a protocol that does not have a predefined keyword.
Source and destination addresses can be explicit IP addresses or subnets, and the masks are regular subnet masks.
| Tip | Cisco firewalls do not use the “inverted” masks required by routers running Cisco IOS Software. Instead, think of a firewall mask as a normal IP subnet mask, where a 1 bit matches a bit value and a 0 bit ignores it. |
If you need to identify a specific host in an access list, you can give its IP address and a host mask (255.255.255.255). You can also specify the same thing by using the host keyword followed by the IP address.
To specify a wildcard or “any” IP address, you can use IP address 0.0.0.0 and mask 0.0.0.0 (0 bits in the mask ignore the value). You can also do the same thing by using the any keyword in place of an address and mask.
| Tip | For inbound firewall rules, ACEs are usually concerned with the destination address and destination port values. This would be useful to allow outside hosts to connect to inside web or email servers, for example. You should always define an ACE with as specific source and destination information as possible. The goal is to define the most strict security policy while allowing users to connect to necessary resources. As well, you should always include access list rules that filter out attempts to spoof legitimate IP addresses (RFC2827) or use IP addresses set aside for private network use (RFC1918). For example, the following ACEs can be used to deny RFC1918 source addresses: |
If you need to match against a source or destination port number, you can add one of the following keywords as an optional operator:
The operator compares the port number to the value given by port (a single decimal number; for a range, give two numbers for lower and upper limits). Port numbers can be given as predefined keywords or as decimal numbers. The keywords supported by Cisco firewalls are listed in Appendix A: “Well-Known Protocol and Port Numbers.”
In the case of an ICMP (protocol icmp) ACE, no operator keyword is used. Instead, the ICMP message type is given alone, in place of the port number.
By default, each ACE is enabled and actively used when it is configured. However, individual ACEs can be disabled without removing them from the configuration. This might be handy if you need to troubleshoot or temporarily deactivate a firewall rule. To do this, reenter the ACE configuration command along with the inactive keyword. To reenable an ACE, reenter it without the inactive keyword.
You can also configure individual ACEs so that they are active and evaluated only during a predefined time range. Time-based ACEs can be useful if you have security policies that change, based on the time of day, day of the week, and so on. After an access list is configured, you can always remove an ACE or insert an ACE at a specific location within the access list. These tasks are covered in the next section.
| Tip | ASA and FWSM access lists are always assumed to use the “extended” format, where both source and destination addresses and ports can be specified. This is very similar to extended IP access lists on IOS router and switch platforms. However, the ASA and FWSM firewalls can support both “standard” and “extended” forms, although standard ACLs are reserved for use with routing protocols. You might be wise to get into the habit of using the extended keyword when you configure, edit, or delete ACE commands. Even if you do not specify the keyword when an ACE is entered, it is automatically inserted into the configuration. The extended keyword becomes important when you need to remove an ACE, as it must be given from the command line. |
Remember that even though an access list is properly configured, it will not be used until it is applied to a firewall function. Access lists are most often used by applying them to firewall interfaces. Access lists can be applied to interfaces in the inbound and outbound directions independently.
Manipulating Access Lists
Every access list contains statements that are internally numbered. If you type in a new ACE without using a line number, it is simply added to the end of the list (just prior to the implicit deny ip any any ACE). If you do include a line number, the new ACE is inserted into the list just prior to the current ACE at that position. The current ACE is not replaced; rather, it and all ACEs below it are moved down one line to make room for the new ACE.
| Tip | Prior to FWSM 2.3, line numbers were not used at all. In that case, you would have to edit an ACL simply by adding new ACEs or deleting existing ones. |
Typically, a firewall numbers ACEs in an ACL with incremental values: the first ACE is line 1, the second ACE is line 2, and so on. However, the ACL line numbers are not shown in the configuration. To see them, you can use the show access-list [acl_id] command. For example, suppose the following ACL has been configured in a firewall:
When the running-configuration is displayed, the access list is shown just as it was entered. Notice that the final implicit deny any any is not shown, although it is actually present.
No line numbers are shown, though the extended keyword has been added even though the ACE lines were not manually entered that way. To see the ACL line numbers, use the show access-list command, as follows:
If a new ACE is entered without specifying a line number, it simply goes to the end of the ACL:
Finally, suppose another new ACE is configured so that it appears at ACL line 2. Notice how the ACEs that were previously at lines 2 and 3 are moved down in the following output, to make room for the new ACE at line 2:
Beginning with ASA 7.0 and FWSM 2.2, you can make an existing ACE inactive without removing it from the ACL configuration. To do this, enter the complete ACE command again, followed by the inactive keyword. The ACE will still be included in the running configuration, but will not be evaluated in the ACL as long as it is inactive. To make the ACE active again, reenter the whole ACE command without the inactive keyword.
To remove an existing ACE, use the no keyword followed by the complete ACE command line. For example, suppose the following access list has been configured on a firewall (notice the extended keyword present in the output):
Obviously, the first ACE could pose a security risk because it might allow all types of traffic to pass. Therefore, you could delete that ACE by using the following command:
Remember to include the extended keyword, so that the entire ACE syntax is matched. No ACL line numbers can be specified when you delete an ACE.
You can also remove an entire access list, including each of its ACE lines, from the running configuration. However, it is a good idea to first make sure the access list is no longer referenced in any other firewall feature or applied to any firewall interface. This prevents a feature from trying to reference an access list that no longer exists.
Then you can use the following command syntax to remove the access list:
Notice how the clear configure access-list command is quite different from the no access-list acl_name that you might have expected—the difference in syntax might just prevent you from accidentally deleting a very large or important access list someday!
Suppose you configure an ACL with a name, and you decide that you need to change its name at a later date. Normally, this would be a cumbersome process. You would have to create a new ACL by reentering each of the ACE lines along with the new ACL name and then delete the old ACL.
Beginning with ASA 8.0, you can easily rename an ACL with just one configuration command. Use the following command syntax to change the ACL name from old_acl_name to new_acl_name:
Adding Descriptions to an Access List
Access lists can become very large, especially if your network has many security policies, many hosts, and many types of traffic to protect with a firewall. Large access lists can be difficult to read (for a human) because it might not be clear what a particular ACE is doing or what its original purpose was.
You can add access list entries that contain text descriptions or remarks to provide some readable clues. Remark ACEs can be added anywhere within an access list, provided you can supply a line number when you configure them. As well, you can configure as many remark ACEs as necessary in an access list.
To add a remark ACE to an access list, use the following command:
A new ACE is added to the access list named acl_id and contains only the word remark followed by the description text (arbitrary text string, 1 to 100 characters). If the line keyword is used, the remark is added just prior to the current ACE at line line-num.
| Tip | Remark ACEs are useful as descriptions or reminders of the purpose for the ACE or group of ACEs that follow them. Keep in mind that the remark lines are not tied to actual ACEs; they only occupy space in the ACL. If you remove or relocate an ACE, a remark line might be left behind in its original position. In other words, unless you remove or relocate remark lines and their associated ACEs, the remarks might become confusing or meaningless. |
Defining a Time Range to Activate an ACE
Once configured, access list entries are active all the time. Beginning with ASA 7.0 and FWSM 3.1(1), you can use two mechanisms to control whether an ACE is actively being evaluated or not:
-
Adding the inactive keyword to an ACE configuration disables it until the keyword is removed.
-
Adding a defined time range to an ACE configuration, during which the ACE will be actively used. Outside the time range, the ACE will be inactive.
To control an ACE with a time range, you must configure the time range itself first. You can use the steps that follow to configure a time range. Once configured, the time range must also be applied to specific ACEs, as discussed in the section, “Adding an ACE to an Access List.”
| Tip | Because a time range controls the state of access list entries, you should make sure the firewall’s internal clock is set to the correct date and time. Otherwise, the firewall might not provide the proper security policies at the expected times. To learn more about setting the firewall clock and synchronizing it with an accurate, external source, refer to Section “10-1: Managing the Firewall Clock,” in Chapter 10, “Firewall Logging.” |
-
Create the time range definition:
The time range is referenced by its name (arbitrary text string, up to 64 characters).
-
(Optional) Define a recurring time period:
You can define the time period in two ways. In the first form of the command, a continuous time period is defined. This begins on start-day at time hh:mm (24-hour format) and ends on end-day at time hh:mm (24-hour format). The day parameters can be one of the following: Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, or Saturday. These are not case sensitive and can be abbreviated, as long as they are not ambiguous.
In the second form, the period lasts from hh:mm to hh:mm (24-hour format, both within the same day), only on the days listed in days-of-the-week. This is one of the following keywords: daily (Monday-Sunday), weekdays(Monday-Friday), or weekends (Saturday-Sunday). You can also use a list of one or more of the following day keywords separated by spaces: Sunday, Monday, Tuesday, Wednesday, Thursday, Friday, or Saturday.
You can repeat either of these commands in the same time range definition to add more time periods.
As an example, a time range is configured to define “after hours”. For the weekday (Monday through Friday) period between 5:00pm until 8:00am the following morning, two separate periodic commands must be used. This is because the time between the start and end times cannot cross midnight and into the following day. A third periodic range is given for weekends, from midnight Saturday until 11:59pm Sunday using the following commands:
-
(Optional) Define an absolute time period:
The time period has an absolute starting time and date and an ending time and date. The times are given as hh:mm (24-hour format), and dates as day (1-31), month name, and year (1993-2035).
If you omit the start limit, the time range begins immediately and runs until the end limit. If you provide a start limit, but omit the end limit, the time range runs indefinitely as soon as the start limit occurs.
As an example, in the configuration that follows, one time range named Dec2010 is configured to define the entire month of December, 2010. A second time range named End_2010 is configured to start immediately and end at the very end of December, 2010.
-
Reference the time range in an ACE.
In the ACE configuration, add the time-range name keyword and argument to the access-list ACE command.
Access List Examples
A firewall connects an inside network (192.168.17.0/24) to an outside network. Inside hosts include a DNS server, a mail server, and two other servers that support extranet services. Assume that the inside hosts have a NAT exemption to the outside, such that they maintain their same IP addresses. The outside hosts include two extranet servers on the 172.22.10.0/24 network.
The following rules should be configured on the firewall, as shown by the actual configuration commands:
-
ICMP traffic from the outside should be limited to only ICMP echo (ping) requests, ICMP time-exceeded replies (needed for traceroute support), and ICMP unreachables (needed for path MTU discovery).
-
Only DNS traffic from the outside is permitted to inside host 192.168.17.21.
-
Only SMTP, POP3, and NNTP traffic from the outside is permitted to inside host 192.168.17.22.
-
Outside hosts 172.22.10.41 and 172.22.10.53 are allowed to send SQLnet and FTP packets toward the two inside hosts 192.168.17.100 and 192.168.17.114.
| Tip | Notice that only the FTP control port (TCP 21) is specified in the access list, even though a separate FTP data connection is opened on a different port. As long as FTP inspection is enabled with the inspect ftp command, you do not have to explicitly configure the data port in the access list. Instead, the firewall automatically permits the additional inbound FTP data connection when it is negotiated dynamically. |
Finally, the access list must be applied to the outside interface, in the inward direction:
Most of the security policies or rules in this example can be easily configured. The final rule, however, requires a bit more work defining a one-to-one relationship between outside and inside hosts, along with a combination of TCP ports that will be permitted. The more hosts and services you have on each side, the more complicated and lengthy the access list gets. ACL complexity can be greatly reduced by using object groups, as discussed in the following section.
Defining Object Groups
Object groups can be thought of as a type of macro used within access lists. Object groups can contain lists of IP addresses, ICMP types, IP protocols, or ports. You can define several different types of object groups, each containing a list of similar values, as follows:
-
Network object group— Contains one or more IP addresses.
-
Protocol object group— Contains one or more IP protocols.
-
ICMP object group— Contains one or more ICMP types.
-
Basic service object group— Contains one or more UDP or TCP port numbers.
-
Enhanced service object group— Beginning with ASA 8.0, service object groups can contain any mix of protocols, ICMP types, UDP ports, and TCP ports. Enhanced service object groups can be used for either source or destination services, or both, in the access list configuration.
Object groups can also be nested; that is, one object group can contain members that are themselves object groups of the same type.
| Tip | When object groups are configured, it is possible to use the same name for object groups of different types. For example, a network object group might be called “Engineering” and contain IP addresses of hosts in the engineering department. A service (application port) object group could also be called “Engineering”, and contain a set of TCP ports needed in the engineering department. While the firewall might be able to sort out the object groups into the correct types, name duplication can be confusing for human users. It is usually a good idea to add a little tag into each object group’s name to help differentiate their purposes. For example, you could use “Engineering_hosts” and “Engineering_ports”. In fact, beginning with ASA 7.0, all object groups are required to have unique names. |
The steps needed to configure each type of object group are presented in the sections that follow. The command syntax is identical on the ASA and FWSM firewall platforms. As soon as an object group is defined or configured, it can be referenced within one or more access lists.
Defining Network Object Groups
You can use the following steps to configure a network object group containing a list of IP addresses.
-
Name the object group:
The group is named group_id (arbitrary text string, 1 to 64 characters).
-
(Optional) Add a description:
You can add a descriptive string text (up to 200 characters) to help explain the purpose of the object group.
-
Add an IP address to the list:
or
The IP address can be given as the host keyword with a single address ip_addr. If you have preconfigured a hostname with the host command, the hostname can be used here. You can also define an IP subnet with a subnet mask, if needed.
You can repeat this command to define more IP addresses in the object group.
-
(Optional) Reference another network object group:
Sometimes you might define a network object group for one purpose and need to include it in a larger object group. You can include another object group by referencing its group name group_id. This group must be configured before including it here.
As an example, suppose you need to configure the same access list statement for a list of three IP addresses (192.168.1.10, 192.168.1.20, and 192.168.1.30) and one IP subnet (192.168.2.0/24), all assigned to hosts in the Accounting department. The following network object group could be configured with the list of addresses, prior to applying it within an access list.
Now suppose that list of addresses is also a part of a larger list containing the hosts of a remote site. A new object group could be configured for the remote site, containing other object groups defined for various departments. You could use the following commands:
Defining Protocol Object Groups
You can use the following steps to configure a protocol object group, containing a list of IP protocols.
-
Name the object group:
The group is named group_id (arbitrary text string, 1 to 64 characters).
-
(Optional) Add a description:
You can add a descriptive string text (up to 200 characters) to help explain the purpose of the object group.
-
Add an IP protocol to the list:
The IP protocol can be given as protocol, a decimal number (1 to 255), or one of the names listed in Table 6-2. To match any IP protocol, use the value ip.
Table 6-2: IP Protocol Names/Numbers
Open table as spreadsheet | Protocol Name | Protocol Number |
| icmp | 1 |
| igmp | 2 |
| ipinip | 4 |
| tcp | 6 |
| igrp | 9 |
| udp | 17 |
| gre or pptp | 47 |
| esp or ipsec | 50 |
| ah | 51 |
| icmp6 | 58 |
| eigrp | 88 |
| ospf | 89 |
| nos | 94 |
| pim | 103 |
| pcp | 108 |
| snp | 109 |
You can repeat this command to define more IP protocols in the group.
-
(Optional) Reference another protocol object group:
Sometimes you might define a protocol object group for one purpose and need to include it in a larger protocol object group. You can include another object group by referencing its group name group_id. You must configure this group prior to referencing it.
As an example, a protocol object group named Tunnels_proto is configured to contain a list of tunneling protocols (GRE, IP-in-IP, ESP, and AH). A second group named Routing_proto contains a list of routing protocols (IGRP, EIGRP, and OSPF). These object groups can then become a part of a larger list called Group1_proto, using the following commands:
Defining ICMP Type Object Groups
You can use the following steps to configure an ICMP type object group, containing a list of ICMP type values.
-
Name the object group:
The group is named group_id (arbitrary text string, 1 to 64 characters).
-
(Optional) Add a description:
You can add a descriptive string text (up to 200 characters) to help explain the purpose of the object group.
-
Add an ICMP type to the list:
The ICMP type can be given as icmp_type, a number from 0 to 255, or one of the decimal numbers or names listed in Table 6-3.
Table 6-3: ICMP Type Names/Numbers
Open table as spreadsheet | ICMP Type Name | Number |
| echo-reply | 0 |
| unreachable | 3 |
| source-quench | 4 |
| redirect | 5 |
| alternate-address | 6 |
| echo | 8 |
| router-advertisement | 9 |
| router-solicitation | 10 |
| time-exceeded | 11 |
| parameter-problem | 12 |
| timestamp-request | 13 |
| timestamp-reply | 14 |
| information-request | 15 |
| information-reply | 16 |
| mask-request | 17 |
| mask-reply | 18 |
| traceroute | 30 |
| conversion-error | 31 |
| mobile-redirect | 32 |
You can repeat the icmp-object icmp_type command to define more ICMP types in the group.
-
(Optional) Reference another ICMP object group:
Sometimes you might define an icmp-type object group for one purpose and need to include it in a larger object group. You can include another object group by referencing its group name group_id. You must configure this group before referencing it with the preceding command.
As an example, an icmp-type object group named “Ping” is configured to contain ICMP types echo and echo-reply. Then that object group is included as a part of a more encompassing icmp-type object group that also contains the unreachable, redirect, and time-exceeded types. You can use the following commands to accomplish this:
Defining Basic Service Object Groups
You can use the following steps to configure a service object group, containing a list of port numbers.
-
Name the object group:
The group is named group_id (arbitrary text string, 1 to 64 characters). Ports defined in the group can be used in access list statements that match TCP ports (tcp), UDP ports (udp), or either TCP or UDP port numbers (tcp-udp).
| Tip | Object groups configured for tcp can be used only in access list statements that match TCP port numbers. Likewise, udp object groups can match only UDP port numbers. If you need to match an application that uses the same port number over both TCP and UDP, you can use the tcp-udp object group. You still need to have separate TCP and UDP access list statements, but they can both reference the same object group. |
-
(Optional) Add a description:
You can add a descriptive string text (up to 200 characters) to help explain the purpose of the object group.
-
Add a port number to the list:
or
A specific port number can be given with the eq keyword as port, a decimal number or name. With the range keyword, you can also specify a range of port values from begin_port to end_port. Refer to Appendix A for a complete list of well-known protocol and port number keywords supported by Cisco firewalls.
You can repeat this command to define more IP addresses in the group.
-
(Optional) Reference another basic service object group:
Sometimes you might define a service object group for one purpose and need to include it in a larger object group. You can include another object group by referencing its group name group_id. You must configure this group prior to referencing it.
As an example, one object group is defined to contain the HTTP and HTTPS TCP ports for web services. A second group is defined to contain the SMTP, POP3, and IMAP4 TCP ports for e-mail services. A third object group is defined to contain both of the other groups, in addition to the TCP port range 2000 through 2002. You can use the following commands to accomplish this:
Defining an Enhanced Service Object Group
Beginning with ASA 8.0, you can define a single enhanced service object group that can contain any combination of protocols, ICMP types, UDP ports, and TCP ports. This is important because it greatly simplifies object group configuration and use.
Use the following steps to configure an enhanced service object group:
-
Name the object group:
The group is named group_id (an arbitrary string of 1 to 64 characters). Notice that no other keywords are used to identify the group as a specific type.
-
(Optional) Add a description:
You can add a descriptive string text (up to 200 characters) to help explain the purpose of the object group.
-
Add a service object to the list:
In one service object definition, you can identify the protocol, source port, and destination port. The source port information is optional; if you do not provide the source keyword, only the destination port is assumed. If you do provide the source keyword, you need to also supply the source and destination parameters.
You can use the keywords listed in Table 6-4 when you configure the protocol and port parameters:
Table 6-4: protocol/port/type Parameter Keywords for Enhanced Service Objects
Open table as spreadsheet | protocol Keyword | port or type Keyword |
| ah | |
| eigrp | |
| esp (same as ipsec) | |
| gre | |
| icmp type | 0–255 alternate-address, conversion-error, echo, echo-reply, information-reply, information-request, mask-reply, mask-request, mobile-redirect, parameter-problem, redirect, router-advertisement, router-solicitation, source-quench, time-exceeded, timestamp-reply, timestamp-request, traceroute, unreachable |
| icmp6 type | 0–255 echo, echo-reply, membership-query, membership-reduction, membership-report, neighbor-advertisement, neighbor-redirect, neighbor-solicitation, packet-too-big, parameter-problem, router-advertisement, router-renumbering, router-solicitation, time-exceeded, unreachable |
| igmp | |
| igrp | |
| ip | |
| ipinip | |
| ipsec (same as esp) | |
| nos | |
| ospf | |
| pcp | |
| pim | |
| pptp | |
| snp | |
| udp port | 0–65535 biff, bootpc, bootps, cifs, discard, dnsix, domain, echo, http, isakmp, kerberos, mobile-ip, nameserver, netbios-dgm, netbios-ns, nfs, ntp, pcanywhere-status, pim-auto-rp, radius, radius-acct, rip, secureid-udp, sip, snmp, snmptrap, sunrpc, syslog, tacacs, talk, tftp, time, who, www, xdmcp |
| tcp port | 0–65535 aol, bgp, chargen, cifs, citrix-ica, cmd, ctiqbe, daytime, discard, domain, echo, exec, finger, ftp, ftp-data, gopher, h323, hostname, http, https, ident, imap4, irc, kerberos, klogin, kshell, ldap, ldaps, login, lotusnotes, lpd, netbios-ssn, nfs, nntp, pcanywhere-data, pim-auto-rp, pop2, pop3, pptp, rsh, rtsp, sip, smtp, sqlnet, ssh, sunrpc, tacacs, talk, telnet, uucp, whois, www |
| tcp-udp port | 0–65535 cifs, discard, domain, echo,http,kerberos, nfs,pim-auto-rp,sip,sunrpc,tacacs, talk,www |
The source and destination operators, src_op and dest_op, can be given as one of the following keywords:
-
Less Than: lt port
-
Greater Than: gt port
-
Equal To: eq port
-
Not Equal To: neq port
-
Range: range lower upper
-
(Optional) Reference another service object group:
Sometimes you might define a service object group for one purpose and need to include it in a larger object group. You can include another object group by referencing its group name group_id. You must configure this group prior to referencing it.
As an example of an enhanced service object group, suppose you would like to identify packets containing ICMP echo and echo-reply, IPsec ESP (IP protocol 50), ISAKMP (UDP port 500), UDP port 10000, and HTTP. With object groups on a FWSM or an ASA prior to ASA 8.0, you would have to configure individual object groups for each type of traffic, as shown in the following example:
In contrast, with ASA 8.0, all of the traffic types can be identified using a single enhanced service object group as demonstrated in the configuration that follows. Notice how the configuration is smaller and that only a single object group needs to be referenced.
Using Object Groups in an Access List
After you have defined an object group, it must be referenced in an access list before it can be used. You can substitute the object group in place of the appropriate protocol, address, or port parameters within the access-list command syntax. In the complete command syntax that follows, notice the location of each of the regular object group keywords:
You can substitute the following regular ACE parameters with the object group syntax shown:
As you begin to use object groups, think of the common things in security policies that can be grouped together: ICMP packet types, inside and/or outside host addresses, protocols, and port numbers. Consider the following example, which is identical to the scenario presented in the “Access List Examples” section.
Now the actual access list is configured, including any references to the object groups that have been configured:
This time, the number of object group commands seems to be lengthy but the access list is rather short. The idea is to make the ACL as short as possible to become more abstract and readable. If you have defined your object groups with meaningful names, you begin to see the access list defined with abstract functions or quantities.
You can always make adjustments to the security policies by adding or deleting lines from object groups. Even if the object group definitions become very lengthy, it does not really impact the firewall’s performance—the overall access list is compiled so that it can match traffic in a consistent amount of time, regardless of the actual ACL length.
Although the access list is much shorter in the running-configuration when it includes object group references, this is primarily for a firewall administrator’s benefit.
Internally, the firewall expands the object groups (even nested ones) out into the full access list configuration. If the firewall is configured to compile ACLs, then the expanded result is compiled and used. You can display the full access list with the show access-list command, as in the following example:
Even though this access list was reported to have 15 elements (ACEs), notice what has happened with the line numbers. The line numbers follow the ACL in the running configuration, where the object groups have not been expanded. However, in this output, the line numbers do not increment as long as the ACEs are part of the same object-group expansion. This is shown by the shaded text, where “line 1” represents all of the ACEs from the object-group allowed-icmp.
The real beauty of object groups can be seen when you need to make changes to existing firewall rules. For example, suppose you have a host on the DMZ (10.1.1.1) that needs to communicate with another host on the inside (192.168.10.30). With an access list, you might configure these ACEs:
That seems straightforward enough, until you need to add a second DMZ host at a later date. You could replicate the four ACE command lines to permit traffic from the new DMZ server, as follows:
Replicating ACEs might become cumbersome if you continue to add even more DMZ hosts that need the same rules. Even worse, what if you begin adding hosts on the inside that need to receive the same types of traffic from the DMZ hosts?
Instead, you can use object groups to work smarter. Define one network object group for the DMZ hosts and another for the inside hosts:
Now when you need to add a new DMZ host, you simply make one addition to the dmz_hosts object group:
The firewall automatically expands the object group within the ACL, and the necessary rules are replicated with the new DMZ host address! You can easily add new addresses to the list of inside hosts as well.
You could also carry this idea one step further by creating a service object group that contains all of the TCP ports that are common to the groups of hosts. To do this, you could enter the following configuration commands:
The basic service object group must be referenced in the place of source or destination ports in the ACE.
Beginning with ASA 8.0, you have the advantage of defining an enhanced service object group that can contain any combination of protocol, source port, and destination port parameters. After you configure an enhanced service object group, you need reference it only once in the access-list command. The firewall takes care of expanding the object group into all of the appropriate parameter locations in the ACE.
This makes the access-list command syntax a little simpler:
Notice that the enhanced service object group completely takes the place of the protocol, source port, and destination port parameters.
The following example shows the configuration of an enhanced service object group to identify the ESP protocol; ISAKMP (UDP destination port 500); UDP destination ports 10000 through 10001; TCP destination port 10000; ICMP echo, echo-reply, and time-exceeded types; and connections from TCP source port 5000 to destination port 6970. Then the object group is applied to access list acl_outside from any source address to destination host 10.10.10.10.
Because an enhanced service object group is referenced only once in an ACE, it might be confusing how it actually expands within the access list. You can see the final results with the show access-list command:
Logging ACE Activity
By default, no syslog messages are generated for permit ACEs, but each traffic flow that matches a deny ACE triggers a syslog 106023 message (default severity level 4, warnings). If you want to disable syslog completely for an individual ACE, add the log disable keywords. For example, by adding log disable to the following command, the firewall will not generate a syslog message:
| Tip | You can also change the severity level of the 106023 message, if the default level 4 is not appropriate. Use the following command: The new level is one of the following keywords or numbers: emergencies (0), alerts (1), critical (2), errors (3), warnings (4), notifications (5), informational (6), or debugging (7). |
You can also enable syslog activity for both permit and deny conditions. When the log keyword is added to an access-list command, it will enable syslog 106100 messages (default severity 6, informational) for each connection that is permitted or denied by the ACE. Subsequent flows or connections cause the ACE hit count to be incremented.
After a time interval, another syslog 106100 message is generated for the connection, showing the updated hit count. You can use the interval keyword to alter this syslog hold interval to secs (1 to 600 seconds, default 300).
You can also change the syslog severity level for message 106100 by adding the level value (0 to 7, default 6 or “informational”).
| Tip | Syslog usage on a Cisco firewall is covered in more detail in Chapter 10. |
If the ACE with the log keyword is denying packets, the firewall caches the denied flow so that it can be tracked. Because of this, there must be a limit to the number of cached denied flows to keep the firewall’s memory from becoming exhausted.
After the limit is reached, syslog message 106101 is generated. You can limit the number of cached denied flows with the following command:
This sets the maximum number of flows denied by an ACE to n flows. The maximum limit is dependent upon the amount of firewall RAM: 4096 flows (more than 64 MB RAM), 1024 flows (16 MB to 64 MB RAM), or 256 flows (less than 16 MB RAM). On a firewall running PIX 7.0 or later, you can use the access-list deny-flow-max ? command to display the maximum limit value for that platform.
You can also set the cache limit syslog interval with the following command:
Syslog message 106101 is generated each time the cache limit is reached, but only at an interval of secs (1 to 3600 seconds, default 300).
Monitoring Access Lists
You can review an access list definition by displaying the firewall configuration with this EXEC command:
or
To jump right to the access-list in the configuration, you can use this variation:
Or to display only the lines of the access-list configuration and nothing else, you can use a further variation:
Beginning with ASA 7.0, you can display an access-list configuration with this command:
Object groups and access list contents are shown exactly as they were configured. In fact, only the object group references are shown in the ACL configuration; the actual object group definitions are shown in a different point in the configuration. This makes it difficult to review a large access list because you have to refer back and forth between the ACL and any object groups.
After an access list has been configured and applied to an interface, you can monitor its use. Use this EXEC command to see a breakdown of ACL contents and activity counters:
Each line of the ACL is shown, along with a hit counter indicating how many connections or flows (or packets for ICMP) have been matched by that line. This is shown as “(hitcnt=n)” at the end of each ACE. For example, an access list configured to permit inbound HTTP connections to several web servers is shown to have the following contents and hit counters:
From this information, it is clear that host 192.168.3.19 (line 2) is receiving the greatest volume of inbound HTTP connections.
| Tip | Beginning with ASA 7.3(1) and FWSM 3.1, each line of the show access-list command output ends with a unique string of hex numbers. For example, see how the following line ends with 0xa2294c03: The hex string listed is the same string that is generated in syslog messages 106023 (deny packet by ACL, default warnings level) and 106100 (deny/permit packet by ACL, default informational level). This does not mean much for human readers, but it gives Adaptive Security Device Manager (ASDM) an easy way to reference syslog messages it collects with the actual ACL lines that generated the messages. |
Now suppose that an object group has been configured to list the web servers with the following commands:
Using the show access-list command also expands any object groups that are referenced in an ACL. This allows you to see the actual ACEs that the firewall is evaluating. In this example, the ACL would be expanded as follows:
Notice that each line of the output is shown as line 1 of the ACL. Although the object group is expanded and evaluated as sequential ACEs, it appears as the one ACE that referenced it.
| Tip | You can reset the hit counters of an ACL by using this command: In releases prior to ASA 7.0, be careful when you use this command—if you omit the counters keyword, the entire ACL named acl_id is removed from the firewall configuration! ASA 7.0 and later, as well as all releases of FWSM, do not allow this command to be executed unless the counters keyword is included, so you are in no danger of deleting any configuration. |
No comments:
Post a Comment