Tag Archives: Firewalls

NAT Evolution within Cisco ASA Software

[ “There is nothing permanent except change” – Heraclitus ]

Given that Network Address Translation (NAT) is a baseline functionality on most firewall implementations, it is really critical to understand NAT behavior (on your particular release) before you start configuring access control rules. To help you in this task, the current post briefly reviews how the NAT philosophy has changed through the history of Cisco Adaptive Security Algorithm (ASA) software.

  1. Before release 7.0 (PIX product line) the only available option was the “nat-control” model. When this model is in place, you are supposed to provide an explicit answer regarding the use of NAT (even when you do not want the firewall to perform address translation).
  2. From 7.0 to 8.2, the default operation mode is no nat-control, meaning that NAT  is not mandatory anymore. If the intention is to restore the pre-7.0 behavior, you can still issue the nat-control command.
  3. Starting on ASA 8.3 release the NAT model was completely redesigned. The most significant changes are listed below:
  • There is no concept of nat-control anymore. NAT is simply an optional feature.
  • 8.3 and newer releases employ a brand new NAT syntax.
  • NAT table is now divided in 03 sections, thus allowing a better control of NAT precedence rules. These 03 sections (and their main characteristics) are illustrated in the figure.
  • Dual NAT rules (those that translate both source and destination simultaneously) are now defined as a single statement.
  • When NAT is in place, Access Control Entries (ACEs) refer to the Real Address (as opposed to previous models which considered the translated address). This is a very important difference to be aware of before you migrate to 8.3 and beyond.

The Unified NAT table introduced by ASA 8.3

It is important to emphasize that if you are using a pre-8.3 ASA release, and need new features that were added on 8.3 (or later), you will need to understand the newest NAT model (and convert the rules accordingly). On the other hand, if you have a brand new appliance, it is advisable to start with 8.3 (or 8.4) so that you avoid migrating NAT rules later…

More posts on this topic, presenting practical configuration (and conversion) examples, will come soon. Stay tuned !

** Related Posts:


Filed under English, Firewalls, Security

How IOS IPv6 ACLs handle ICMPv6 Neighbor Discovery messages

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:

  1. 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).
  2. 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).
  3. 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/

Leave a comment

Filed under English, Firewalls, IPv6, Security

Cisco IOS Zone-based Policy Firewall: L7 inspection for FTP over IPv6

In a previous post we examined the main usages of L7 inspection on a stateful firewall (IPv4 perspective):

  1. Fixing up misbehaved protocols, such as those that dynamically negotiate data connections inside the control channel. Classic examples are FTP and the telephony signaling protocols (SIP, H.323 framework, SCCP, MGCP).
  2. Perform Network Address Translation (NAT) at the application level for those protocols that embed the IP address in the L7 messages. This is critical within NAT and Port Address Translation (PAT) environments.
  3. Use the application knowledge to filter based on additional criteria pertaining to the specific L7 protocol, rather than just L4/L3.

On another article of the IPv6 series, we analyzed a basic L4 inspection policy for a v6 environment. Now we will apply the Cisco Zone-based Policy Firewall (ZFW) L7 awareness to a simple FTP scenario built upon IPv6. But, before we jump to the example itself, there are some relevant facts to highlight :

  • Current support for IPv6 in the ZFW covers case 1 of the main usages of L7 inspection listed before.
  • If you need to fixup an application protocol that is running over non-standard ports, you can leverage the ipv6 port-map command (pretty much in the same fashion we employed  the ip port-map command before).
  • The application knowledge is not used for filtering purposes yet.

The figure below depicts not only the ZFW policy structure but also the audit-trail logs for the FTP session (both the control and thedynamically  negotiated data channels). Notice that the match protocol statement uses the ftp keyword, which instructs the ZFW to use its understanding of the FTP application to handle this session. (It is not generic TCP !)

Sample Zone-based Policy Firewall scenario for FTP over IPv6 inspection

** Topics for Study:

  • What are the FTP over IPv6 commands that correspond, respectively, to the PORT and PASV commands ?
  • Examine the output of the show ipv6 port-map command
  • Play with the appropriate show commands for this setup. Good starting points are show zone security and show policy-firewall config zone-pair.

** Related Posts:

Leave a comment

Filed under English, Firewalls, IPv6, Security

Sample Configuration of the Cisco IOS Zone-based Policy Firewall with IPv6

Now that we have studied several practical scenarios for the Cisco IOS Zone-based Policy Firewall (ZFW), it is time to apply this knowledge to IPv6 environments. It is very important to emphasize that the logic of policy construction (as well as the building blocks) are identical to those employed for IPv4.
Our reference topology brings a simple network containing two security zones and an L4-only policy that defines the rules to allow the initiation of  outbound connections. The figure also documents the output of a typical debug command used to gain visibility about session creation.

Basic Zone-based Firewall configuration for IPv6

** Topics for Study:

  • By reviewing the contents of previous posts in the ZFW series, would you be able to insert L3 restrictions in this scenario ? (For example, the client host in the INSIDE should only be able to access FTP and HTTP on the OUTSIDE server).
  • How can you enable logging ? (both for connection setup/teardown and dropped packets)
  • What are the commands used to display information about existent security zones and structure of policy elements ?

** Related Posts:

Leave a comment

Filed under English, Firewalls, IPv6, Security

Introduction to IOS IPv6 ACLs

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

** Notes:

  • Object-groups for v6 elements are not supported on IOS yet.
  • IOS supports IPv6 ACLs that allow filtering based on the v6 extension headers.

** Related Posts:

Leave a comment

Filed under English, Firewalls, IPv6, Security

User-based Access Control with the Cisco IOS Zone-based Policy Firewall

So far we have had some discussions about both the Zone-based Policy Firewall (ZFW) and user-based access control (as powered by IOS Auth-proxy functionality). It is now time to mix these two technologies to render auth-proxy stateful and produce the so-called User-based ZFW behavior.

Figure 1 summarizes the relevant settings to build such a scenario:

  • A Zone-based firewall policy is constructed using the classic ZFW building blocks. One noteworthy difference here is that the class-maps are also matching on the “user-group” parameter.
  • This user information is obtained after the router receives the “supplicant-group” Vendor Specific Attribute (VSA) from the RADIUS server. (The router learned the user credentials using Auth-proxy, pretty much in the same way as already examined in previous posts).

Figure 1: Combining the Cisco IOS Zone-based Policy Firewall with Auth-proxy

Figure 2 shows the details of Auth-proxy and RADIUS for this environment:
  • Instead of an ACE (or a DACL), the router now receives the supplicant-group
  • The router now has a local knowledge of user-to-group mappings

Figure 2: Auth-proxy and RADIUS information in the user-based ZFW scenario

** Topics for Study:

  • Contrast the pure auth-proxy diagrams of previous articles with the current post: can you spot the differences ? (What about the similarities ?)
  • Compare the RADIUS interactions between router (AAA client) and CS-ACS (AAA Server)
  • Notice that one of the class-maps now includes a “police” action. What does that mean ?

** Related Posts:


Filed under English, Firewalls, Identity, Security