Traditional IPv4 ACLs are typically written as a sequence of permit statements that include an implicit deny clause as their last line. Although this implicit deny is also present on IOS IPv6 ACLs, there are some additional facts to be aware of:
- There are other implicit (permit) statements designed to allow two of the main Neighbor Discovery (ND) messages: permit icmp any any nd-na (which handles Neighbor Advertisement messages) and permit icmp any any nd-ns (which takes cares of Neighbor Solicitation messages).
- If your environment requires Router Advertisement (RA) and Router Solicitation (RS) messages to be allowed, these lines will need to be configured explicitily (in the same way as the regular permits).
- In the event you add an explicit deny as the last line of the V6 ACL, this statement will take precedence over the implicit permits earlier described (for nd-na and nd-ns).
Now that you are aware of these characteristics of IPv6 ACLs with regards to Neighbor Discovery, don’t forget to add the following lines before the explicit deny (“deny ipv6 any any“):
permit icmp any any nd-na
permit icmp any any nd-ns
permit icmp any any router-advertisement
permit icmp any any router-solicitation
After all, as seen on a previous article, ND messages are necessary for the correct operation of IPv6 networks…
** Related Posts:
IPv6 Series: https://alexandremspmoraes.wordpress.com/tag/ipv6/
ACL Series: https://alexandremspmoraes.wordpress.com/tag/acl/
This post quickly discusses simple Cisco IOS IPv6 Access Control Lists (ACLs). As summarized in the figure, the construction logic of the ACL is basically identical to the classic v4 ACLs (those that do not use object-groups). The permit (or deny) statements are created by specifying the following elements (in this order):
- source of the traffic
- destination of the traffic
- services involved (from source to destination)
One noticeable difference refers to the way in which v6 ACLs are applied to interfaces: the correct command to accomplish that task is the ipv6 traffic -filter (and not something such as “ipv6 access-group”).
Basic Description of simple IOS IPv6 ACLs
** Related Posts:
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:
After presenting the correct way of adding ACL restrictions to a Cisco Zone-based firewall policy, it is time to examine how Network Address Translation (NAT) interacts with a Cisco ZFW deployment. Our particular environment (Figure 1) actually contains a combination of stateful inspection, an L3 rule (ACL) and NAT.
To facilitate understanding, we start by briefly describing our reference scenario:
- Inspection (controlled by class-map TOP-CLASS2) defines that only those application protocols carried over TCP are allowed from the OUTSIDE to the INSIDE zone.
- The ACL2 access-list limits the source hosts (subnet 172.18.2.0/24) that can initiate inbound connections to the server 10.5.5.5.
- The two previous conditions are united under the match-all class-map JOINT2.
- The server address 10.5.5.5 is seen on the global address space (after source NAT) as 172.18.2.5.
Figure 1: Reference scenario combining Cisco Zone-based Firewall, ACLs and NAT
If you ever integrated Cisco IOS regular interface ACLs with NAT, you will notice that the ACL used by ZFW now refers to the real address of the destination host (instead of the mapped address). This is a critical change to be aware of.
Figure 2 provides further visibility for the topology under analysis, in the specific case of a telnet session initiated by the outside client (172.18.2.20) and bound to the translated address of the server (172.18.2.5):
- The first Syslog message shows how the address translation is created.
- The audit-trail log message highlights that the responder is 10.5.5.5 (real address), meaning that the ZFW process understands NAT.
- The show policy-firewall session command confirms that the inbound connection is established with the real address (from the ZFW standpoint).
Figure 2: Details about the Zone-based Firewall, ACLs and NAT integration
** Topics for Study:
- Think about the integration of a classic IOS interface access-list with NAT. What is the advantage of referring to the real address (as done by ZFW) ?
- Revisit some other categories of IOS NAT (for instance, destination NAT and Port Address Translation). How can you display the active translations ? Can you have more than one interface configured with the ip nat outside command ?
- Consider the integration of CBAC with NAT and ACLs. Does CBAC refer to the real address ? Or to the mapped address ? (Why ?)
- Rebuild the ACL shown in this example using the concept of object-group.
** 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 ?