The IP address is a basic attribute related to computer systems that rely on the TCP/IP protocol stack to establish network connectivity. As a result, the vast majority of access control rules deployed on Stateful Firewalls are based upon parameters present, for instance, in the IP,TCP,UDP and HTTP headers. Although this protocol-based approach has demonstrated to be powerful, the need for networks that are flexible enough to accommodate multiple classes of users (employees, contractors, guests) along with the increasing need for network mobility, has motivated the search for alternative ways of implementing access control.
This article briefly examines the creation of firewall rules that include some sort of Identity-based information for the users initiating connection requests. As we will see later, in some scenarios identity information may also be associated with the servers.
The first generation is centered on the captive portal paradigm, mainly relying on downloadable ACLs to differentiate among users that are connecting through the firewall. The second, normally referred to as the ID Firewall, allows the creation of permissions based on MS AD user/group domain information. The third generation, known as the SGT Firewall, represents a true evolution because it provides integration not only between the firewall with the edge devices (such as wireless APs and LAN switches), which are the main source of user information, but also between the firewall with the switches that reside on the server side (as shown in the figure below).
To read the complete article, follow the link to the Cisco Support Community.
** Additional Reading
- A more detailed description of the first generation (https://alexandremspmoraes.wordpress.com/2012/01/27/cisco-firewalls-and-user-based-access-control/)
- Illustrating the use of RADIUS Authorization Profiles on Cisco IOS (https://alexandremspmoraes.wordpress.com/2012/02/02/cisco-ios-authentication-proxy-and-radius-authorization-profiles/)
The initial articles in the Zone-based Policy Firewall (ZFW) series concentrated on basic ZFW behavior and capabilities. The current post shift gears a little bit, by quickly discussing how the Cisco Security Manager (CSM) software can facilitate the operation and maintenance of a network protected by the Zone Firewall.
As depicted in Figure 1, if you are already acquainted with graphical configuration of firewall policies (for ASA and even other vendors’ products), you will notice that the philosophy is basically the same. The traditional logic for rule construction (involving sources, destinations and services) is still there… Yes, that’s it: benefit from the abstraction provided by CSM to build the logical rules and the software will take care of translating them to the CLI commands that materialize the ZFW functionality.
Figure 1 also illustrates another interesting possibility: you can create a ZFW policy on CSM and assign it to multiple devices. This is really relevant when you need, for instance, to deploy multiple branches that have similar rules.
Figure 1: Zone-based Firewall rule table on CSM
Figure 2 shows that you can import the active settings on a live Cisco IOS device and share it on CSM. It’s important to highlight that you can select the types of settings to be imported for later use (ZFW rules, AAA configuration, general platform information and much more).
Figure 2: Sharing device policies through CSMth
Figure 3 displays the CSM Configuration Archive feature, which allows you to keep track of configuration versions (a kind of information that is certainly useful for auditing and meeting compliance requirements). By selecting a saved configuration you can see the configuration commands delivered to the device (Transcript Viewer).
Figure 3: Configuration Archive and CLI Transcript
This was just a quick review of the CSM capabilities regarding the Zone Firewall. It’s naturally recommended that you review the previous ZFW posts and, if possible, that you navigate through the CSM GUI.
** Related Articles:
** Further Reading:
Convergent networks that convey data, voice and video in an integrated manner are spread all around. And this is not just because people consider convergence something fashionable but, rather, because organizations have realized how the concept of Collaboration can contribute to business efficiency and productivity. Of course this convergence promise sounds appealing but along with business relevance comes the responsibility of providing adequate security…
Network Security principles are well mapped and you might be asking what is so special about integrating voice and video.
I will start by saying that the new service possibilities associated with Collaboration are materialized by a set of application protocols that have specific characteristics and networking requirements and, as such, bring new challenges. As usual, from the perspective of network security professionals, the first step is precisely to understand the protocols involved.
And, please, never forget that there is no magic black box approach… Although firewalls constitute one indispensable protection element of an UC Security solution, there are many other resources that need to be taken into account for any practical implementation. For instance, LAN switch, router and IP Phone security features.
Read the complete article on the Cisco Support Community page…
On our series of articles about ASA NAT, we mentioned that version 8.3 introduced a complete new model for address translation. The main characteristics associated with this new philosophy are summarized in the following:
- NAT is not mandatory anymore (as opposed to the nat-control model).
- NAT table is organized in 03 distinct sections: one for auto-NAT and two for manual NAT (or twice NAT).
- Translation rules that involve source and destination simultaneously are now defined in a single nat statement (using a manual NAT rule). These are the cases of Dual NAT and all the variants of Policy NAT.
- Starting on version 8.3, the Access Control Entries (ACEs) refer to the Real IP Address of the host and not to the translated address.
The figure brings a practical example of an ASA Unified NAT Table that contains rules in each of the three sections. Remember that:
- Object NAT Rules are inserted into section 2
- By default, manual NAT rules are created within section 1. If you want to insert a nat statement into section 3 you will need to use the after-auto parameter.
- The sections in the NAT table are processed in order.
An example of the ASA Unified NAT Table
** Topics for Study:
** Related Posts:
Continuing our series of articles about Network Address Translation (NAT) on Cisco ASA, we will now examine the behavior of Identity NAT.
When the nat-control model is in place (for ASA releases older than 8.3), an explicit answer regarding NAT must be provided to the ASA algorithm, even if this answer is do not translate ( “no nat“). Among the NAT exemption techniques supported by ASA, there is one called Identity NAT, which is typically used when most of the addresses are being translated and you need to avoid translation for just a specific set of hosts.
Starting on 8.3 version, there is no such concept of nat-control, meaning that NAT Exemption is not necessary anymore and the nat 0 (nat zero) configurations are completely banned.
The reference topology shown in the figure was conceived to illustrate NAT Exemption syntaxes for both the current and old (pre 8.3) models. In our environment, hosts belonging to the 10.10.10.128/26 subnet are excluded from translation rules, irrespectively of the destination being accessed. Although the intention here is to keep some source addresses from being translated, the behaviors of the configurations are slightly different:
- The nat zero construction that refers directly to the IP address (instead of an ACL) is unidirectional in essence and is not suited for address publishing. This means that the 10.10.10.128/26 stations will be able to start outbound connections but will not be accessible from the out interface (even if you configure a permission within an ACL).
- Identity Static (static from X to X) is bidirectional and, as such, may be used for address publishing. (You will still need to add a permission so that the real address can be reached from the out interface).
- The NAT flags are distinct: both options have the identity flag set but nat zero is deemed dynamic. (And that reinforces its unidirectional nature).
Identity NAT on ASA: configuration models
- Considering that we are dealing with a source-only translation rule, we employed Object NAT for the 8.3 case. By revisiting the previous posts on the NAT series, can you build an equivalent configuration with Manual NAT ?
- The show commands registered in the figure help characterize that NAT exemption is in place. Can you explain that ?
** Related Posts
As explained in a series of previous posts, it is indispensable to understand the NAT philosophy change introduced by ASA 8.3 in order to profit from the new features (available in 8.3 and higher). While the other articles focused on explaining the correspondence between the pre and post 8.3 models, the current one will demonstrate the automatic migration script in action when you upgrade ASA software on a 8.2 box that already contains NAT rules.
The Static Policy NAT and Static NAT configurations for the reference topology of Figure 1 are described below:
- The dmz client 10.10.10.150 is mapped to 172.18.18.150 when the destination is 172.16.16.200.
- For other out destinations, the same dmz client is statically translated to 172.16.16.150.
Figure 1: ASA NAT - Migration Example 1
If you carefully look at the figure, you will notice that the IP addresses used in the ACL and static rules of the 8.2-style configuration are converted to network objects, which are later employed within the nat statements that characterize 8.3.
Although the migration script may be helpful for simple topologies that contains few categories of NAT, it is really critical that you understand how to manually convert from the original model to the new one. There are situations, such as those registered in Figure 2, in which the script may not work. So do not rely blindly on it. I think it is really advisable to invest some time on getting familiar with building the manual correspondence.
Figure 2: Sample messages from the NAT automatic migration script
- If you plan to use the automatic migration script, it is really recommended that you remove the nat-control command from your pre-8.3 configuration. This will avoid the creation of many network objects during the conversion process.
- From 7.0 to 8.2 the default ASA operation mode is to consider NAT an optional feature. This is accomplished with the no nat-control command, which is not displayed in the show running-config listing. If you want to make sure that no nat-control is in place, issue the show running-config all nat-control command.
** Related Posts:
[ “What is actual is actual only for one time. And only for one place.” – T. S. Elliot ]
As a follow on to our analysis of ASA NAT, the current post examines another important use case scenario: how to simultaneously translate source and destination addresses on a certain connection through your firewall ? As usual, both the pre-8.3 and post-8.3 configurations are covered so that you can use them to help on your migration tasks (in case your are still using 8.2 or earlier releases).
One remarkable difference between the old and new syntaxes resides in the fact that from 8.3 on you just need a single nat statement to produce the dual NAT effect. This is an improvement with reference to the classic model, which required two rules (for instance two static commands) to achieve the same result.
Some other key advantages of the model introduced by ASA 8.3 are listed below:
- When using manual NAT, the use of the sequence number (SEQ#) parameter enables the precise control of the order in which translation rules are inserted in the Unified NAT Table. This renders NAT processing much more predictable than the original implementation.
- The capability of specifying source and destination mappings at once, makes ASA NAT logic more similar to other vendors’, thus facilitating migration from competitive offerings.
Handling dual NAT on ASA: before and after 8.3
** Topics for Study:
- It is very important that you get familiar with the order in which the real and mapped addresses are defined in the nat and static commands.
- Remember that starting on 8.3, ASA ACLs refer to the real IP of the destination host (as opposed to 8.2 and older versions, which use the translated IP).
- The ability to use global ACLs, introduced by version 8.3, is another factor that may decrease the efforts when migrating from other vendors’ firewalls to ASA.
- If you need a detailed coverage of the NAT precedence rules (very important on pre-8.3), please refer to Chapter 08 of the Cisco Firewalls title on the Cisco Press security collection. For information about 8.3 NAT, consult the Appendix, NAT and ACL changes in ASA 8.3, of the same book.
** Related Posts:
This post builds upon the previous discussions on the ASA NAT series to exemplify yet another category of address translation: Dynamic Policy PAT. In this type of scenario, a set of source addresses get mapped into a single global address when they need to reach specific destinations.
In our reference topology, those dmz stations belonging to the 10.10.10.128/27 subnet are port address translated to 172.16.16.125/32 when the destination is the out host 172.16.16.200. For different out hosts, the source IPs are not translated. Some important points to highlight:
- It is important to observe that we are not translating the destination address. We are just using the destination criteria to influence translation of the source addresses.
- In the pre-8.3 CLI the number “1” is the NAT_ID, which creates the relationship between the nat and global commands.
- The original syntax (pre-8.3) employs an Access Control List (ACL) in conjunction with the nat command to insert the destination-based rule.
- In the new model introduced by release 8.3, we use manual NAT to create any rules that concurrently involve source and destination. This is the case for Policy NAT, Policy PAT and Dual NAT. Unless you use the after-auto argument in the nat command, manual translations are inserted in Section 1 of the Unified NAT Table.
Dynamic Policy PAT on ASA
- As in the basic PAT case (which does not take destination addresses into account), ASA combines the global address (172. 16.16.125 in this case) with a source port to correctly identify each internal host and deliver the return packets accordingly.
- Manual NAT allows you to add a sequence number to each manual nat statement, so that you can directly control the order of processing of the translation rules (irrespectively of the NAT category in place). This is a major difference when comparing to releases up to 8.2, for which you needed to know the intrinsic NAT precedence rules.
** Topics for Study:
** Related Posts:
[“All appeared new, and strange at first, inexpressibly rare and delightful and beautiful. I was a little stranger, which at my entrance into the world was saluted and surrounded with innumerable joys.” – Thomas Traherne]
After reading the article “NAT Evolution within Cisco ASA software” and applying that knowledge to build static translations on ASA, it is now time to implement dynamic rules. As we did before, to make life easier on migration tasks, the two configuration modes (pre and post-8.3) are presented.
The figure below brings not only the old-style syntax but also the new options for a simple topology, in which the internal addresses belonging to the 10.10.10.128/25 subnet are translated to the range 172.16.16.129-172.16.16.254. In this arrangement, some facts deserve special mention:
- In the legacy CLI the number “2” is the NAT_ID, which is used to establish the link between the nat and global commands.
- For source-only translations, the nat statement (configured under the network object definition) automatically places the rule in Section 2 of the Unified NAT Table.
- Given that manual NAT allows the creation of rules that simultaneously specify translation of source and destination addresses, manual NAT can be “simplified” to create source-only (or destination-only) rules. In this case the rule will be part of Section 1 and there will be no reference to network object. Considering that the sections in the NAT table are sequentially processed, the equivalent construction with manual NAT takes precedence over Object NAT. (The exception is when you employ the after-auto parameter in the nat command, thus sending the manual rule to Section 3).
Dynamic NAT on Cisco ASA
** Topics for Study:
** Related Posts:
[“Most of the change we think we see in life is due to truths being in and out of favour“. – Robert Frost]
Yes… we know that. Adapting to change is frequently a challenge. If you invested time and effort to learn a certain way of getting stuff to work, it is not that easy to accept newer forms of accomplishing something similar (at least when you first see it).
Despite the reasons presented to justify the new Network Address Translation (NAT) model introduced by version 8.3 of the ASA software, many people will think (and say): “just bring back my static !” I understand that particular perspective but the key fact to be aware of is that getting familiar with the new philosophy is vital to enable your organization to migrate to 8.3 and beyond (and profit from the most recent feature developments…)
While the previous article, “NAT Evolution within Cisco ASA software“, covered the main differences between the three generations of the NAT functionality for ASA, the current post has a simpler objective: to present a basic example of Static NAT, with the two possibles syntaxes (pre and post-8.3). The topology and related commands to illustrate that are summarized in the figure below.
Implementing Static NAT on ASA: pre and post 8.3
If you look carefully at the output of show nat command, you will be able to notice that the translation just configured generated a rule at Section 2 of the Unified NAT Table (an instance of the so called Auto NAT or Object NAT). Some relevant comments about this type of arrangement follow:
- The real address is part of a network object definition. This object can be later employed in other sections of the configuration, such as in an Access Control Entry (ACE) or under an object-group definition.
- The mapped address is created by using a nat statement as a parameter of the network object (previously used for the real address).
- A given Object NAT rule can be employed to translate either the source or the destination address of a packet but not both at the same time. If you need to deal with more complex requirements (Policy NAT or Dual NAT, for instance), Twice NAT will be the adequate choice.
It is really advisable that you compare the old and modern ways of defining static NAT. It is also a good idea to start planning the conversion of the configurations in your specific environment. Future posts will illustrate more situations (dynamic PAT, Policy NAT and dual NAT are planned topics). Stay tuned !
** Topics for Study:
** Related Posts: