Object Grouping

Object Grouping

The concept of grouping or forming groups isn’t new to network or even human interaction. Groups can be given special privileges or restrictions, and those privileges or restrictions then apply to all members of the group. In the networking world, creating groups—such as employees or marketing employees—is common, and then assigning permission to the group to access certain services, such as department servers and printers. A new employee needs only to be placed in the appropriate group to share the permissions granted that group. By the same token, if a group is denied access to a resource, such as a color printer, then everyone in the group is denied.

Overview of Object Grouping

PIX Firewall version 6.2 introduced grouping to help reduce the complexity of configuration and to improve scalability for large or complex networks. Object Grouping allows the definition of groups, and then application of commands or features to a group. This process can reduce the number and the complexity of configuration statements and, thereby, reduce the amount of time spent configuring and troubleshooting large or complex networks.

An example of using Object Grouping would be to group objects of a similar type, so a single access list could apply to all the member objects. Review the following object groups and visualize how they might be used with ACL statements to manage network access.

  • DMZServers The IP addresses of the shared servers in the DMZ network.

  • Partners The host and network addresses of trading partners allowed the greatest access to the organization services and servers.

  • DMZServices Those TCP/UDP port numbers and ICMP message types allowed access to the DMZ network.

Creating a single access rule to allow partner hosts to use the DMZServices with the DMZServers should be possible. If four DMZ servers need to be shared with the current pool of 40 business partner organizations, it’s conceivable that, without object groups, hundreds of commands (40 ? 4 ? the number of ports) might be necessary.

Getting Started with Group Objects

An object group is created with the command mode command object-group. After the object-group command creates the group, the mode changes to a corresponding Subcommand mode. The object group is then defined in the Subcommand mode. The command prompt indicates the Active mode. The object group can neither be created empty nor removed or emptied if it’s being used by another command. Use the no form of the command to remove the group. The first line is the basic syntax to create an object group. The last two lines are the actual syntax with options.

Pix(config)# object-group object-type grp-id
Pix(config)# no object-group object-type grp-id
Pix(config)# object-group {protocol|network|icmp-type} grp-id
Pix(config)# object-group service grp-id {tcp|udp|tcp-udp}

grp-id

Descriptive name for the group (1 to 64 characters). Can be any combination of letters, digits, dash (-), underscore (_), and period (.) characters.

object-type

Use one of the following object types:

Network—Group of hosts or subnets

Service—Group of TCP or UDP port numbers port service literal (www, ftp)

ICMP-type—Group of ICMP message types

Protocol—Group of IP protocols. This can be keywords icmp, ip, tcp, or udp, or an IP protocol number (1 to 254). Use IP to include IP, ICMP, TCP, and UDP

Subcommand Mode

The prompt changes to the appropriate Subcommand mode once the object-group command is complete. Commands available in the Subcommand mode apply to the object type and group name identified in the object-group command. The prompts in each Subcommand mode are as follows:

Pix(config-protocol)#
Pix(config-service)#
Pix(config-icmp-type)#
Pix(config-network)#

Use exit, quit, or any valid config-mode command, such as access list, to close an Object-Group Subcommand mode, and then exit the object-group creation process.

Any PIX Firewall command using the keyword object-group and followed by the group name applies to every item in that group.

Pix# show object-group group_name

Removing Object Groups

Use the no object-group object-type grp-id command to remove a group of previously defined object-group commands. The clear object-group command form can also be used. Beware, the clear object-group command without any parameter removes all defined object groups that aren’t being used in a command. Adding the object_type parameter removes only the defined object groups that aren’t being used in a command.

Verifying Object Groups

Use the show object-group command to display a list of the currently configured object groups. The command syntax is

Pix# show object-group [ protocol | network | service | icmp-type ] | [id grp_id]

The show object-group command offers the following choices:

  • show object-group id grp_id—Displays all defined object groups by their grp_id

  • show object-group object_type—Displays all defined object groups by group type

  • show object-group—Displays all defined object groups

The following output demonstrates the show object-group command.

Pix(config)# show object-group
object-group network dmz_servers
 ?description: The DMZ shared servers
 ?network-object host 192.168.2.3
 ?network-object host 192.168.2.4
 ?network-object host 192.168.2.5
object-group network Partners
 ?description: The dealer and supplier partners
 ?network-object host 172.16.21.119
 ?network-object 192.168.7.0 255.255.255.0
 ?network-object 192.168.12.0 255.255.253.0

Configuring Object Groups with ACLs

The access-list command offers an Object Group option for each of the variable choices. The following syntax is the previous basic ACL command with an alternative to having to define each element explicitly for what could be many configurations.

Pix(config)# access-list acl_id {deny | permit}{protocol | object-type protocol-grp-id {source_addr | local_addr} {source_mask | local_mask} | object-type network-grp-id [operator port [port] | object-type service-grp-id] {dest_addr | remote_addr} {dest_mask | remote_mask} | object-type network-grp-id [operator port [port] | object-type service-grp-id]}

The following example creates a service object group to define the DMZ resources you’re willing to share. The ACL allows the Partners from the last example to use the services on the DMZ servers defined in the last example.

Pix(config)# object-group service dmz_service tcp
Pix(config-service)#port-object eq www
Pix(config-service)#port-object eq ftp
Pix(config-service)#port-object eq smtp
Pix(config-service)#exit
Pix (config)# access-list 101 permit tcp object-group partners dmz_servers eq dmz_service

Nested Object Groups

An object group can contain or be contained by other object groups. For example, Partners, from the earlier example, could contain the groups AsiaPartners, EuroPartners, AfricaPartners, and NorthAmericaPartners. Each of those groups could contain other groups, such as NorthAmericaPartners might contain CanadaPartners, MexicoPartners, and USPartners. Each of the smaller subgroups only makes sense if additional resources were limited to each group. The following example demonstrates part of the previous nesting:

Pix(config)# object-group network MexicoPartners
Pix (config-network)#network-object 192.168.151.0 255.255.255.0
Pix (config-network)#network-object 192.168.159.0 255.255.255.0
Pix (config-network)#network-object 192.168.210.0 255.255.255.0
Pix(config)# object-group network CanadaPartners
Pix(config-network)# network-object 192.168.251.0 255.255.255.0
Pix(config-network)# network-object 192.168.237.0 255.255.255.0
Pix(config-network)# network-object 192.168.216.0 255.255.255.0
 ? ?(additional lines omitted)
Pix(config)# object-group network NorthAmericaPartners
Pix(config-network)# network-object CanadaPartners
Pix(config-network)# network-object MexicoPartners
Pix(config-network)# network-object USPartners
Pix(config-network)# exit
Pix(config)# access-list 101 permit tcp object-group NorthAmericaPartners any
Pix(config)# access-group 101 in interface outside

Object Grouping dramatically reduces the number of access list statements required to implement a particular security policy. The last line shows that the NorthAmericaPartners networks are allowed to have TCP access to the network.




Part III: Virtual Private Networks (VPNs)