Object Groups
In version 6.2, Cisco introduced a feature that simplifies the management of ACLs, called object groups. Object groups allow you to create groups of related information that you apply to your filtering policies, thereby reducing the number of filtering commands that you have to enter. This eases your ACL implementation and maintenance, and also ensures that you apply the same policy to every device when a policy needs to be applied across a group of devices.
Object groups allow you to create the following object types:
- Protocols TCP/IP protocols, like TCP, UDP, GRE, and others
- Services Types of TCP and UDP services (port names and/or numbers)
- ICMP Types of ICMP messages
- Networks Network numbers and host addresses
Once you have created your various groups of objects, you can include them in your ACL commands to permit or deny packets based on matches in the object groups.
Advantages of Object Groups
I’ll outline some situations where object groups do and do not make sense. For example, if you need to define a filtering policy that denies telnet traffic from 192.168.1.1 to 192.168.2.2, you could easily accomplish this with a single ACL command. However, if you have a list of ten clients trying to access three servers for both telnet and e-mail, the filtering configuration becomes very complex when using ACLs alone. Alternatively, you could use object groups to create a network group for the ten clients, a network group for the three servers, and a service group for telnet and e-mail, and then use these groupings in a single ACL command.
Another nice feature of object groups is that you can embed an object group within another object group; this is called nesting. As an example, you might have two network object groups, and want to create a filter that includes both groups. Originally, this would require two ACL statements. To solve this problem, you can create a third object group and can include the first two network object groups within this new group. Then create a single ACL statement that references the object group that includes the nesting of the two specific object groups.
Creating Object Groups
The general syntax for creating an object group is very simple, as shown here:
ciscoasa(config)# object-group type_of_object group_ID [protocol_name] You can specify four different object types for the type_of_object parameter. Table 6-2 lists the valid object types.
| | |
|---|---|
| | |
| | |
| | |
| | |
Once you have specified an object type, you need to follow it with an ID for the group—this is a name that groups together the various object types that you will create. If you specified service as the type of object, you need to tell the appliance which protocols to include in the list of applications, where your options are tcp, udp, or tcp-udp (for both).
Descriptions
When you execute the object-group command, you are taken into a Subconfiguration mode (commonly called a subcommand mode), where the appliance prompt changes to reflect the type of object group you are configuring. Some commands are specific to one type of object group, and others can be used in any type of object group. For example, the description command can be used in any object group. The description command allows you to enter up to 200 characters as a description for an object group. The syntax of the description command is
In this example, I’m in Protocol Subconfiguration mode; however, this command works in all Subconfiguration modes for object groups.
Nesting Object Groups
Another command common to all object groups is the group-object command. The group-object command allows you to add a previously created group to a group of the same type. This process is referred to as nesting. The syntax of this command is
To use the group-object command, you need to create an object group with your included services, protocols, networks, or ICMP message types. You can then create a new object group of the same type, and use the group-object command to reference your already created object group. You need to use the group_ID number of the previous group when using the group-object command.
| Note | |
Network Object Groups
You can create an object group to specify host addresses and/or network numbers that you use in your ACL commands. To create a network object group, use the commands shown here:
ciscoasa(config-network)# network-object host host_address
ciscoasa(config-network)# network-object network_address subnet_mask
The first command, object-group network, creates a network object group and takes you into the Network Subconfiguration mode. The second and third commands allow you to specify the devices in the object group—the first is for a specific host, and the second is for a network or subnet number. You can use a combination of networks and hosts in an object group.
Protocol Object Groups
You can create an object group for IP protocols that you use in your ACL commands. To create a protocol object group, use these commands:
ciscoasa(config-protocol)# protocol-object protocol_name_or_number
The first command, object-group protocol, creates a protocol object group and takes you into the Protocol Subconfiguration mode. The second command allows you to specify the TCP/IP protocol name or number in the object group. You can specify a protocol name, like tcp, udp, or icmp, or you can give the IP protocol number instead, like 6 for TCP or 17 for UDP.
Service Object Groups
You can create an object group for TCP and UDP applications that you use in your ACL commands. To create a service object group, use these commands:
ciscoasa(config-service)# port-object eq port_name_or_number
ciscoasa(config-service)# port-object range first_port last_port
The first command, object-group service, creates a services object group and takes you into the Service Subconfiguration mode. You need to specify either TCP, UDP, or both protocols—this refers to the types of ports within this object group. The second command, the one with the eq parameter, specifies a specific port number (or name) in the object group. You can also specify a range of port names and/or numbers—you need to use the keyword range followed by the first number in the list and the last number.
ICMP Object Groups
You can create an object group for ICMP messages that you use in your ACL commands. To create an ICMP object group, use these commands:
ciscoasa(config-icmp-type)# icmp-object ICMP_message
The first command, object-group icmp-type, creates an ICMP message type object group and takes you into the ICMP Subconfiguration mode. The second command specifies the ICMP message type (like the ICMP name or number) in the object group.
Examining Your Object Groups
Once you have configured your object groups, you can display them with the show object-group command. The following is the syntax of this command:
icmp-type] | [group_ID]}
If you only type in the show run object-group command and do not specify any parameters, the appliance will display all of your object groups. You can limit this by specifying a specific type of object group, or a specific object group. Here’s an example of this command:
object-group network web_servers
description: This is a list of Web servers
network-object host 200.200.200.2
network-object host 200.200.200.9
object-group network trusted_web_servers
network-object host 192.199.1.7
network-object 201.201.201.0 255.255.255.0
group-object web_servers
This example has two object groups. The first one is called web_servers and contains two hosts: 200.200.200.2 and 200.200.200.9. The second object group is called trusted_web_servers and contains one host (192.199.1.7), one network (201.201.201.0/24), and one embedded, or nested, object group called web_servers.
Deleting Object Groups
To remove all object groups on your appliance, use the clear configure object-group command. Optionally, you can remove all of the object groups of a specific type by adding the type to the end of the clear configure object-group command. The following is the syntax of this command:
services | icmp-type]
If you only want to remove a specific object group, use this syntax:
| Note | |
Using Object Groups
To help you understand how object groups are used by ACL commands, I’ll now examine how they are used in the access-list command. The following is the syntax for the two variations of using object groups, where the first is for ICMP and the second for anything else:
{source_address_and_mask |
object-group network_object_group_ID}
{destination_address_and_mask |
object-group network_object_group_ID}
[{icmp_type |
object-group icmp_type_object_group_ID}]
ciscoasa(config)# access-list ACL_ID {deny | permit}
{IP_protocol |
object-group protocol_object_group_ID}
{source_address_and_mask |
object-group network_object_group_ID}
[{operator source_port |
object-group service_object_group_ID}]
{destination_address_and_mask |
object-group network_object_group_ID}
[{operator destination_port |
object-group service_object_group_ID}]
As you can see, you can use object groups where they suit you. For example, you could list a network object group for the source address information, but list a specific host address for the destination—you can mix and match object groups and specific ACL protocol information based on your configuration needs.
Once you have referenced your object groups in ACL commands, you can see the commands you entered and the expansion of the object group references:
<--output omitted-->
access-list ACLOUT; 9 elements
access-list ACLOUT line 1 extended permit tcp any
object-group DMZ_HOSTS object-group DMZ_PORTS 0x959c5b39
access-list ACLOUT line 1 permit tcp any host 192.168.1.1
eq 80 (hitcnt=0)
access-list ACLOUT line 1 permit tcp any host 192.168.1.1
eq 443 (hitcnt=0)
access-list ACLOUT line 1 permit tcp any host 192.168.1.1
eq 21 (hitcnt=0)
<--output omitted-->
Notice that in the preceding example, the first listing of line 1 is the command I typed in. The second, third, and fourth appearance of line 1 is the expansion of the object group references that the appliance created. Note that when you execute the write memory command, the expanded statements are not saved to flash: only the commands you physically entered are saved to flash.
| Note | |
Object Group Configuration Example
To help illustrate the use of object groups with ACLs, I’ll use the network shown in Figure 6-3. In this example, I will allow outside access to the internal servers, but only for web and FTP access to the specific servers.
Listing 6-7 has the configuration, including address translation, for the appliance.
Listing 6-7: The configuration object groups with ACLs  |
netmask 255.255.255.0
ciscoasa(config)# nat (inside) 1 0.0.0.0 0.0.0.0
ciscoasa(config)# static (inside,outside) 200.200.200.2 192.168.1.2
ciscoasa(config)# static (inside,outside) 200.200.200.3 192.168.1.3
ciscoasa(config)# static (inside,outside) 200.200.200.4 192.168.1.4
ciscoasa(config)# static (inside,outside) 200.200.200.5 192.168.1.5
ciscoasa(config)# static (inside,outside) 200.200.200.6 192.168.1.6
ciscoasa(config)#
ciscoasa(config)# object-group network web_servers
ciscoasa(config-network)# network-object host 200.200.200.2
ciscoasa(config-network)# network-object host 200.200.200.3
ciscoasa(config-network)# network-object host 200.200.200.4
ciscoasa(config-network)# exit
ciscoasa(config)# object-group network ftp_servers
ciscoasa(config-network)# network-object host 200.200.200.4
ciscoasa(config-network)# network-object host 200.200.200.5
ciscoasa(config-network)# network-object host 200.200.200.6
ciscoasa(config-network)# exit
ciscoasa(config)# access-list PERMIT_IN permit tcp
any object-group web_servers eq 80
ciscoasa(config)# access-list PERMIT_IN permit tcp
any object-group ftp_servers eq 21
ciscoasa(config)# access-list PERMIT_IN deny ip any any
ciscoasa(config)# access-group PERMIT_IN in interface outside
|
Two network object groups are here, one for web servers and one for FTP servers. Two ACL statements allow access to these web servers and FTP servers, but deny everything else. If you didn’t use object groups, you would need six statements for the servers and then the deny ip any any if you wanted to view the hit counts of all dropped packets.
ICMP Filtering
Many people understand how IOS routers deal with ACLs and apply this knowledge to the appliances, expecting them to behave the same way as the routers; however, this is not correct. I’ll deal with two issues concerning ICMP in this chapter: ICMP traffic passing through the appliance and ICMP traffic directed at the appliance.
ICMP Traffic Through the Appliances
As I mentioned in Chapter 5, ICMP traffic is not stateful by default on the appliances. ICMP messages by default are permitted when traveling from a higher-security-level interface to a lower-level one. However, ICMP traffic is denied by default from a lower-security-level interface to a higher-level one, even if it is an ICMP message response to a user’s ICMP query.
Typically you should allow the following ICMP message types into your network to help provide some basic management and troubleshooting abilities for your internal devices: echo reply, source quench, unreachable, and time exceeded. For external devices to test connectivity to your network, you might also want to permit the ICMP echo message, but I would definitely restrict what ICMP messages Internet users can generate and what destinations in your network can receive these messages.
To allow ICMP traffic to travel from a lower-level to a higher-level interface, you need to enable one of two things:
- Stateful processing of ICMP
- An ACL entry or entries for the ICMP messages
| Note | |
Starting in version 7.0 of the OS, you can enable stateful processing of ICMP traffic using the Cisco Modular Policy Framework (MPF), discussed in Chapters 10 and 11. However, as you will see in these chapters, enabling stateful processing of ICMP traffic has its own set of problems. And stateful processing of ICMP is only new as of version 7.0 of the appliances; in prior versions, you had to use the second option: ACLs.
I’ll use the network shown previously in Figure 6-3 to illustrate what an ACL to allow returning ICMP traffic to your users would look like. I’ll build upon the Listing 6-7 example that I covered in the previous section. Here’s an example of the configuration to allow returning ICMP traffic:
ciscoasa(config-icmp-type)# icmp-object echo-reply
ciscoasa(config-icmp-type)# icmp-object source-quench
ciscoasa(config-icmp-type)# icmp-object unreachable
ciscoasa(config-icmp-type)# icmp-object time-exceeded
ciscoasa(config-icmp-type)# exit
ciscoasa(config)# object-group network ALL_servers
ciscoasa(config-network)# group-object web_servers
ciscoasa(config-network)# group-object ftp_servers
ciscoasa(config-network)# exit
ciscoasa(config)# access-list PERMIT_IN permit tcp
any object-group web_servers eq 80
ciscoasa(config)# access-list PERMIT_IN permit tcp
any object-group ftp_servers eq 21
ciscoasa(config)# access-list PERMIT_IN permit icmp
any any object-group icmp_traffic
ciscoasa(config)# access-list PERMIT_IN permit icmp
any object-group ALL_servers echo
ciscoasa(config)# access-list PERMIT_IN deny ip any any
ciscoasa(config)# access-group PERMIT_IN in interface outside
I’ve created two additional object groups: one for allowing ICMP returning traffic, and one that puts the web and FTP servers into a network group so that you can specifically allow ICMP echo messages to them. The first two entries in the ACL are the same as in the previous section. The two ACL entries after those are new. The first one allows ICMP traffic from anywhere and to anywhere if it matches the ICMP message types in the ICMP icmp_traffic object group. The entry after this allows any echoes from anywhere if they are destined to the devices specified in the ALL_servers object group.
ICMP Traffic Directed at the Appliances
Until version 5.2.1 of the OS, any ICMP traffic destined for any of the interfaces of the appliances would be allowed, and the appliances would automatically respond. One unfortunate drawback of this process is that an attacker could use ICMP to learn that a security appliance existed, and possibly learn some basic information about it. Up until version 5.2.1, you could not disable this function and make the appliance invisible to other devices. Starting with version 5.2.1, you now have the option of making the appliance stealthy—you can control how the appliance itself will respond to ICMP messages, or prevent them altogether.
Until version 8.0, you only had one option for controlling this, ICMP filtering. Starting in version 8.0, you have a second option with the use of an ACL applied to the appliance itself (not an interface), referred to as control plane filtering. With the former, you can control what ICMP messages the appliance will process when directed to one of its interfaces; with the latter, you can control any type of traffic that the appliance will process when directed to itself. With the second option, you create your ACL and apply it to the appliance with the access-group command, using the control-plane parameter (instead of applying it to an interface).
| Note | |
Restricting ICMP Traffic Directed at the Appliance
The remainder of this section will focus on using the ICMP filtering feature. To control ICMP messages destined to an interface on the appliance, use the icmp command:
src_IP_address src_subnet_mask
[ICMP_message_type] logical_if_name
You must specify a source IP address and a subnet mask. Unlike with an extended ACL, there is no destination IP address, because the security appliance, itself, is the destination.
You can qualify which ICMP messages are allowed or denied by entering a value for the ICMP_message_type parameter. The message types can be entered as either a name or a number. If you omit the message type, the appliance will assume that you want to allow or deny all ICMP messages. The last parameter is the name of the interface for which you want to restrict ICMP messages.
The appliance processes the icmp commands top-down for an interface. In other words, when the appliance receives an ICMP packet destined to one of its interfaces, it checks to see if any icmp commands are associated with the interface. If none is defined for the interface, the appliance processes the ICMP message and responds with the appropriate ICMP response. If an ICMP filter is on the interface, the appliance processes the icmp commands based on the order in which you entered them. If the appliance goes through the entire list and doesn’t find a match, the appliance drops the ICMP message; this is like the implicit deny statement at the end of an ACL.
To remove a specific icmp command, preface it with the no parameter. To delete all the icmp commands that you have configured, use the clear configure icmp command.
| Note | |
ICMP Filtering Example
Now let’s take a look at an example on how to use the icmp command to restrict ICMP messages directed at an appliance interface. In this example, you want to be able to test connectivity from the appliance to other destinations on the Internet, and you want the appliance to process only certain ICMP packets to aid in connectivity testing—all other ICMP messages should be dropped. Here’s an example of how to accomplish this:
ciscoasa(config)# icmp permit any echo-reply outside
ciscoasa(config)# icmp permit any parameter-problem outside
ciscoasa(config)# icmp permit any source-quench outside
ciscoasa(config)# icmp permit any time-exceeded outside
ciscoasa(config)# icmp permit any unreachable outside
ciscoasa(config)# icmp deny any outside
As you can see, only certain items are permitted—basically ICMP replies to ICMP messages that the appliance generates, as well as to any error messages.
