In the articles presented so far, we have studied situations in which inspected traffic is crossing the router-based firewall (instead of being directed to any of the router addresses).
The default operation of the Cisco Zone-based Policy Firewall (ZFW) is to allow traffic to an from the router interfaces, irrespectively of zone-pair security settings. If there is a need to modify this behavior, a system-defined zone, whose reserved name is self, must come into the scene.
Although interfaces are not directly assigned to the self zone, this special zone handles packets travelling from any router interface to a non-self zone (and conversely). You should keep in mind, though, that policies involving the self zone are still unidirectional.
Some facts about our reference topology are registered below:
- The policy construction employs the classic building blocks. The only particularity is that one of the interconnected zones is the self zone.
- The OUT-SELF zone-pair security is controlling packets sourced from the OUTSIDE zone and directed to the router interfaces. Packets originated by the router are not being inspected.
- Policies involving the self zone are more meaningful when they include L3 restrictions (materialized by ACLs).
- The activation of logging occurs in the same manner as already analyzed for non-self zones.
Inspecting router-bound traffic with the Cisco Zone-based Policy Firewall
** Topics for Study:
- Make sure you understand the handling of IOS object-groups.
- Revisit the post related to ACL integration into a ZFW scenario.
- Construct a ZFW policy to control traffic originated by the router and destined to the OUTSIDE zone. You should allow only ICMP Echo and Echo Reply messages from interface F0 to the 172.22.22.0/24 subnet.
- Update the ZFW policy analyzed in this post to limit telnet sessions going to the router. Telnet should only be allowed from sources located in the 172.21.21.0/24 subnet and directed to the Fo interface.
- Review the articles related to logging in the ZFW series (both for dropped packets and connection setup/teardown).
** Related Posts:
A previous article about the Cisco Zone-based Policy Firewall (ZFW) exemplified the construction of a simple L4 policy. Several other posts in the ZFW series underlined the fact that we cannot use interface ACLs in a ZFW environment (to avoid breaking the stateful inspection activities).
The current post builds upon our past discussions and documents the correct way of configuring ACLs within a zone-based firewall policy.
The focus of the policy structure depicted below is on the class-map called JOINT1, which specifies two simultaneous conditions that must be met for packets to flow from the INSIDE to the OUTSIDE zone:
- Inspection happens at L4 for application protocols that use either TCP or UDP transport. This is governed by the class-map TOP-CLASS1, already studied in the article Building a simple policy with the Cisco Zone-based Firewall.
- Restrictions that involve combination of source and destination addresses and L4 ports are imposed the extended access-list ACL1. This ACL is called by the match-all class-map JOINT1.
- Sample Zone-based Firewall policy that includes an Access Control List
The figure also shows a simple Syslog message associated with the scenario. An NTP session from the host 172.18.1.10 to the server 172.18.2.20 was allowed by class JOINT1. This means that this particular connection was in accordance with both rules contained in this class.
The object-groups referred to by access-list ACL1 are those defined in the post ‘The use of object-groups in Cisco IOS software’.
There is no interface ACL in this setup. The ACL rules are taken care of as part of one of the building blocks of a Zone-based firewall policy. It is important to emphasize that this is the correct manner of inserting L3/L4 restrictions into a basic ZFW L4 inspection policy.
The log keyword cannot be configured as part of an Access Control Entry (ACE) that is used inside a ZFW class-map.
Newer releases of IOS allow you to list the existent class-maps and policy-maps with the show running-config class-map and show running-config policy-map commands.
** Topics for study:
** Related Posts:
Access Control Lists (ACLs) have been available for quite while and represent a very useful resource for activities such as packet filtering and traffic classification. This latter usage of ACLs has applications in many practical scenarios, some of which are listed below:
- Filtering routing updates
- Defining the interesting traffic to be encrypted by an IPSec tunnel
- Establishing traffic that will undergo Network Address Translation (NAT)
- Differentiate traffic classes using criteria such as source and destination addresses, IP protocol type and L4 ports involved.
Cisco IOS 12.4.20T added support to object-groups, a feature that undoubtedly helps anyone that needs to deal with access-lists. Figure 1 brings a set of sample network and service object-groups and teaches how to display those groups already configured.
Figure 1: Sample IOS object-groups
Figure 2 demonstrates the structure of the IOS Access Control Lists that employ object-groups. It should be observed that the logic of ACL contruction, in this case, is a bit different. Instead of specifying a sequence of sources, destinations and services, this new type of IOS ACL refers to service object-groups, source network object-groups and destination network object-groups (in this order). Figure 2 includes a practical example of IOS ACL that uses the sample object-groups defined in Figure 1.
Figure 2: Structure of IOS Access Control Lists (ACLs) that use object-groups
Figure 2 brings some additional information about Cisco IOS:
The ip access-list logging hash-generation command is used to correlate an Access Control Entry (ACE) enabled for logging with the Syslog message it generates. This important feature was introduced in IOS 12.4.22T and may be used by management tools to locate an entry in the rule table upon receipt of a Syslog message.
The show running-config | section command was used to display the occurrences of access-list statements. Notice that this is more than a simple string match.
** Topics for study:
Investigate how the show running-config | section command compares with other CLI output filtering options such as show run | include and show run | begin.
Contrast the construction logic of IP extended ACLs with the access-lists presented in this post.
Reproduce the network topology shown in Figure 1 ( including the ACL and object-groups) and analyze the log messages issued by the IOS router.
Research the other options available for the object-group command. Is it possible to specify a range of IP addresses ?