Object Groups for ACLs - At last!

If someone was telling you that's it's possible to enable the following communication using an access-list (ACL) with only 5 ACL entries (ACEs), you would probably laugh!

hosts 10.10.10.1, 20.10.20.1, 30.10.30.1 40.10.40.1 should be able to telnet to any host
hosts 10.10.10.1, 20.10.20.1, 30.10.30.1 40.10.40.1 should be able send mail
hosts 10.10.10.1, 20.10.20.1, 30.10.30.1 40.10.40.1 should be able to ping anyone
hosts 10.10.10.1, 20.10.20.1, 30.10.30.1 40.10.40.1 should be able to send tcp/udp packets at ports 1000-2000

hosts in the range 10.20.20.1 10.20.20.20 should be able to telnet to any host
hosts in the range 10.20.20.1 10.20.20.20 should be able send mail
hosts in the range 10.20.20.1 10.20.20.20 should be able to ping anyone
hosts in the range 10.20.20.1 10.20.20.20 should be able to send tcp/udp packets at ports 1000-2000

hosts in the network 10.30.30.0 255.255.0.0 should be able to telnet to any host
hosts in the network 10.30.30.0 255.255.0.0 should be able send mail
hosts in the network 10.30.30.0 255.255.0.0 should be able to ping anyone
hosts in the network 10.30.30.0 255.255.0.0 should be able to send tcp/udp packets at ports 1000-2000

everything else should be denied


The conventional way of accomplishing the above would probably include around 30-40 ACEs (by aggregating some hosts and possibly using more than 1 ports at the same ACE) and a lot of copy/edit/paste, but you'll never be able to make it using only 5 entries.

You don't want to imagine what would happen if instead of "any" as destination you had another group of host/ranges/networks.

Welcome to ACL Object Groups (or object group-based ACLs); a new -much requested- feature of IOS, available in latest 12.4(20)T.

The Object Groups for ACLs feature lets you classify users, devices, or protocols into groups and apply them to access control lists (ACLs) in order to create access control policies for those groups. This feature lets you use object groups instead of individual IP addresses, protocols, and ports, which are used in conventional ACLs. It also allows multiple access control entries (ACEs), but now you can use each ACE to allow an entire group of users to access a group of servers (or services) or to deny them from doing so.

These are the main characteristics of ACL Object Groups:

1) Ease security-policy management by introducing level of abstraction in security policies
2) Classifies users/devices/applications into groups allowing you to apply policies based on the group classification
3) Allows use of group names in ACEs instead of IP addresses and protocol ports - reduces configuration size


Back to our example and let the fun begin....

Using Network Object Groups you can decrease the number of ACEs to just 5:

object-group network ACL-OGN
description ** Object Group Network **
 host 10.10.10.1
 host 20.10.20.1
 host 30.10.30.1
 host 40.10.40.1
 range 10.20.20.1 10.20.20.20
 10.30.30.0 255.255.0.0
!
ip access-list extended ACL-1
 permit tcp object-group ACL-OGN any eq telnet
 permit tcp object-group ACL-OGN any eq smtp
 permit icmp object-group ACL-OGN any echo
 permit tcp object-group ACL-OGN any range 1000 2000
 permit udp object-group ACL-OGN any range 1000 2000

A network object group is a group of any of the following objects:

• Single IPs or Hostnames
• Subnets
• Ranges of IP addresses
• Other network object groups (nested object groups)

A conventional ACE could allow a group of users to have access only to a specific group of servers. In an object group-based ACL, you can create a single ACE that uses an object group name instead of creating many ACEs (which would require each one to have a different IP address/range/network). These ACEs can have object groups for the source only, destination only, none, or both.


Ok, let's push it a little more. What about if someone was telling you that's it's possible to enable the above communication using an access-list with only 1 entry? Still listening?

Using Network and Service Object Groups you can decrease the number of ACEs to just 1:

object-group network ACL-OGN
 description ** Object Group Network **
 host 10.10.10.1
 host 20.10.20.1
 host 30.10.30.1
 host 40.10.40.1
 range 10.20.20.1 10.20.20.20
 10.30.30.0 255.255.0.0
!
object-group service ACL-OGS
 description ** Object Group Service **
 tcp eq telnet
 tcp eq smtp
 icmp echo
 tcp-udp range 1000 2000
!
ip access-list extended ACL-2
 permit object-group ACL-OGS object-group ACL-OGN any

A service object group is a group of any of the following objects:

• Source and destination protocol ports (such as Telnet, SMTP, etc.)
• ICMP types (such as echo, echo-reply, etc.)
• Top-level protocols (such as TCP, UDP, ESP, OSPF, etc.)
• Other service object groups (nested object groups)

This is another object group (imagine it like a protocol/service port group) that can be extended to provide access only to a set of applications for a user group to a server group.


The general idea of ACL Object-Groups is "define access from user-group A to X services of server-group B".

ip access-list extended ACL-1
 permit IP object-group user-grp object-group serv-grp

ip access-list extended ACL-2
 permit object-group apps-grp object-group user-grp object-group serv-grp

Where:
apps-grp = application ports (Service Object Group)
user-grp = user (client) IP addresses (Network Object Group)
serv-grp = server IP addresses (Network Object Group)


Generally, you can use ACL Object-Groups with QoS match criteria, Cisco IOS Firewall and many other features that use extended ACLs. I think you understand the unlimited new prospects.

According to Cisco, when there are many inbound and outbound packets, using object group-based ACLs increases performance when compared to conventional ACLs (probably a faster lookup happens?). Also, in large configurations, this feature reduces the storage needed in NVRAM, because using object groups in ACEs means that you do not need to define an individual ACE for every address-protocol pair.


Note 1 : An ACE that you define using a group name is equivalent to multiple conventional ACEs (one applied to each entry in the object group). The router expands automatically the object group-based ACL ACE into multiple ACEs (one ACE for each entry in the group) and populates the ACEs in the TCAM of the router. Therefore, the Object Groups for ACLs feature reduces the number of entries that you need to configure, but it does not reduce TCAM usage. So, you might want to be careful when configuring this on HW switching platforms.

Note 2 : Ranges under Network Object Groups don't seem to work as described (i'm still investigating this). Also i couldn't find any command that displays the expanded ACL, although on CCO there is such an output using "sh ip access-list" (probably a bug?).


So next time you're asked a similar question, give them a surprise!