A Crash Course in the Extreme Importance of Objects and Object Groups
The Cisco ASA appliance is a complex network security device that offers numerous functionalities.
It segments the network into separate zones, controls data traffic based on policies, exchanges routing protocol updates, performs IP address translation with NAT, and provides next-level protection against threats and malicious traffic.
However, as beneficial as the ASA appliance can be, sometimes specific configurations can be cumbersome, too complicated, and complex for everyday management.
Not many configuration lines are needed when the network is small and consists of only several end devices. However, as the number of devices increases, specific configurations, such as ACL and NAT rules, can also increase uncontrollably.
The solution to configuration complexity lies in implementing objects and object groups. This approach allows you to simplify things by using names instead of individual IP addresses and services and group certain hosts, resources, or services that share the same policy.
This article will provide the following:
- An overview of network and service objects.
- An overview of network and service object groups.
- An explanation of the benefits of using objects and object groups.
- Configuration steps for implementing objects and object groups on a Cisco ASA.
Not what you were looking for today? View some of our popular articles:
- The Essentials of ARP Protocol & How To Protect Against Spoofing Attacks
- The Importance of Layer 3 Redundancy: Understanding HSRP – Pt. 1
- What Is Public Key Infrastructure and How Important Is It?
Introducing Network and Service Objects
The configuration process of interface and global access rules, as well as NAT rules, can sometimes be complicated, especially in large enterprises consisting of many networks and end devices.
Using IP addresses as parameters is not always difficult. However, sometimes it is very challenging to remember all IPs in the network or understand what happens to an IP address when it is used in a specific rule just by looking at it.
A simple solution to this problem is to use network objects. They simplify certain configurations and play an essential part in some configuration processes, such as NAT. A network object can represent a host, a network, a range of IP addresses, or a fully qualified domain name (FQDN).
Once configured, a network object can be used as many times as needed in different types of configurations, such as in ACLs or NAT. This way, objects are used instead of focusing on raw IP addresses, usually represented by self-explanatory names.
Another benefit of using network objects is the flexibility they provide. A single change on the network object parameters (for example, changing an IP address) would reflect in all other parts of the configuration where used. This approach saves you from manually modifying the same raw parameter (IP address) several times in the configuration.
The same applies to service objects. You can easily replace a combination of a port number and Layer 4 protocol with a service object and use it in the ACL rules. This provides easier management and a more user-friendly configuration approach at the same time.
__________________
Options That You Can Choose From
PivIT offers a unique and wide selection of hardware and financing options. We also offer OEM options that give you the flexibility you need to develop your network.
__________________
How to Configure Network Objects
The configuration process of network objects on the Cisco appliance is straightforward.
We will use the scenario in the image below to guide the configuration process. The goal is to create four network objects, one representing the IT department and the other three representing the HTTP, FTP, and TFTP servers.
To configure a network object through the Cisco ASDM tool, you must navigate to Configuration>Firewall>Objects>Network Objects. The image below shows the configuration of the network object of type network named “IT_department,” representing the 192.168.1.0/24 network of the IT department.
The rest of the configuration for the rest of the objects would be similar.
Introducing Network and Service Object Groups
As useful as network and service objects are, they are not equally beneficial in all scenarios.
For example, using network objects instead of real IP addresses in an access list would make the configuration more user-friendly but will not decrease the total number of rules in the ACL.
The only solution to this problem is to group specific network objects that share the same policy into a network object group. This way, you can replace several rules in the ACL with just a single rule applying to several network objects (hosts or networks) simultaneously.
The same applies to predefined and custom service objects as well.
When the source and destination IPs are the same in several access rules and only the services are different, you can group those services in a service object group and configure just a single access rule that will use all those services in the service group at the same time.
Like with network and service objects, both the network and service object groups can be reused in the access rules or NAT configuration.
This approach allows you to group hosts, networks, or services that share the same policy, which in the end, dramatically optimizes the access rules while at the same time simplifying and shortening the configuration of the appliance on many different levels.
How to Configure Network and Service Object Groups
Configuring network and service object groups is similar to the configuration process of network and service objects.
To better understand the benefits of implementing network and service objects groups, let’s look at the topology in the image below.
The goal in the use case is to allow users from the IT department to make HTTP, FTP, and Telnet connections to the primary and two backup servers.
To achieve the goal without object groups, the ACL will have to use the following nine access rules, where each source and destination parameter uses the appropriate network object.
Action |
Source IP address |
Destination IP address |
Service |
Permit |
IT_department |
Primary_server |
HTTP |
Permit |
IT_department |
Backup_server1 |
FTP |
Permit |
IT_department |
Backup_server2 |
Telnet |
Permit |
IT_department |
Primary_server |
HTTP |
Permit |
IT_department |
Backup_server1 |
FTP |
Permit |
IT_department |
Backup_server2 |
Telnet |
Permit |
IT_department |
Primary_server |
HTTP |
Permit |
IT_department |
Backup_server1 |
FTP |
Permit |
IT_department |
Backup_server2 |
Telnet |
To simplify the ACL, you must create network and service object groups. Because the same services are used for all three servers, you can group them into a single network object group. At the same time, you can also group the HTTP, FTP, and Telnet services into one service object group.
The image below shows the configuration of the network object group named “Servers,” representing the primary and backup servers.
The image below shows the configuration of the service object group named “Allowed_services_to_servers” using the HTTP, FTP, and Telnet services.
Now, with the help of the object groups, the ACL will have just a single rule instead of nine rules to provide the same result.
This makes the management of ACLs easier for you and optimizes the Cisco ASA appliance at the same time.
Action |
Source IP address |
Destination IP address |
Service |
Permit |
IT_department |
Servers |
Allowed_services_to_servers |
More Than Just a Feature
Although using network and service objects and object groups is optional when configuring a Cisco ASA appliance, they greatly simplify the overall configuration.
This may not be so beneficial for small networks like branch offices. However, they play a crucial role in a large network such as a headquarters or campus.
Instead of using raw parameters, you can replace them with objects and, when necessary, group them into object groups. Keep this guide handy for the next time you decide to use them.
If you need a helping hand to configure your network, consider PivIT's EXTEND SmartHands offering to gain access to engineers around the globe to locally access your infrastructure without ever leaving your desk. But don't take our word for it, here's what one of our clients had to say:
"Great response time by the PivIT team, they came through in a pinch and we really appreciate it." - Jarrod S. (Director of Infrastructure)