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: