ol for each server. As a result, nine access-list entries must be configured to allow each of the three protocols to these three servers: access-list In permit tcp any host 192.168.1.101 eq smtp access-list In permit tcp any host 192.168.1.101 eq WWW access-list In permit tcp any host 192.168.1.101 eq https access-list In permit tcp any host 192.168.1.201 eq smtp access-list In permit tcp any host 192.168.1.201 eq WWW access-list In permit tcp any host 192.168.1.201 eq https access-list In permit tcp any host 192.168.1.228 eq smtp access-list In permit tcp any host 192.168.1.228 eq WWW access-list In permit tcp any host 192.168.1.228 eq https While this may not seem like a big deal, imagine if the firewall had six interfaces, and supported 40 servers. I've seen PIX firewalls that had access lists 17 printed pages long. Figuring out all the permutations of protocols and servers can be maddening. The potential complexity of the access lists has led many businesses to ignore the PIX when considering firewalls. Version 6 of the PIX os introduced the idea of object groups to solve this problem. With the object-group command, you can create a group of protocols, networks, ICMP types, or services that you can reference by a name: PIX(config)# object-group ? Usage: [no] object-group protocol I network I icmp-type <obj_grp_id> [no] object-group service <obj_grp_id> tcp|udp|tcp-udp show object-group [protocol I service icmp-type | network] show object-group id <obj_grp_id> Object Groups clear object-group [protocol I service | icmp-type network] clear object-group counters In the preceding example, each of the web servers is using the same TCP ports. By assigning these common ports to a group, we can make the access list much smaller. Let's create an object group called Webserver-SVCS. This will be a group of TCP services, which we'll define using port-object object-group commands: object-group service Webserver-SVCS tcp description For Webservers port-object eq smtp port-object eq WWW port-object eq https Now, instead of 