Chalk Talk: The Evolution of Identity Services on Firewalls

Julie Burruss · ‎09-04-2013

Editor’s note: Special thanks for Alexandre Moraes for writing this month’s Chalk Talk article! See the end of this article for a list of additional resources from Alexandre. Click here for a list of all of all Tech Insight articles featured in the TS Newsletter.

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.

Even though Cisco offers two families of firewalls (ASA and IOS), we will concentrate our discussion on the ASA platform, which supports three generations of Identity-based access control.

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.

The First Generation – Cut-through Proxy

The ASA Cut-through Proxy feature leverages the authentication functionality embedded on a set of protocols (HTTPS, HTTP, Telnet and FTP) to intercept connection attempts (through the firewall) and extract user credentials. The user information obtained is forwarded to the AAA Server for validation. The most interesting use cases are those in which an authorization profile in the form of a downloadable ACL (dACL) is received from the AAA Server (Cisco ACS or Cisco Identity Services Engine are the most common options). It is important to emphasize that the dACL may specify permissions for any application protocol and not only those that natively support authentication.

Among the triggering protocols available, HTTPS is the most suitable option not only for its encryption support but also because the standard user is familiar with browser interfaces.

The Cut-through Proxy process is summarized on figure 1.

Figure 1 - click to enlarge

The Second Generation – Identity Firewall

The Identity Firewall (ID-FW) approach allows ASA to integrate with Microsoft Active Directory (MS AD) and create access rules based on domain membership information. To accomplish this mapping of user and groups from MS AD, ASAs makes use of an auxiliary element called the AD agent.

One important aspect of the ID-FW solution is that the lists of user and groups are readily available for the firewall administrator, thus significantly facilitating policy creation and making it more suitable for modern corporations, which need to guarantee access to resources regardless of user location in the network (figure 2).

It is interesting to notice that since the introduction of the ID-FW, a “user” column is present in the firewall rules table as a possible source criterion (figure 2). This second generation solution renders policy creation a more logical (and intuitive) process. For instance, it is much easier to understand a rule that states “do not allow sales personnel to connect to the Engineering servers” than to look up tables of IP assignment to extract information about the pertinent users and servers.

Figure 2 - click to enlarge

The Third Generation – SGT Firewall

Even though the ID FW is already more flexible (in terms of policy creation) than simply using IP/Port combinations, this model is quite dependent on domain integration, which is not an option for many use cases.

With that in mind, and knowing that valuable user and device information is available on the network edge devices (such as WLAN APs and LAN switches), Cisco decided to build a truly innovative method of defining access rules on firewalls. This brand new architecture is called the SGT Firewall (SGT FW) and builds upon Cisco’s TrustSec framework.

The main aspects of the ASA-Trustsec integration are listed as follows:

ASA downloads from ISE a list of SGTs that may be assigned to the various elements in the infrastructure under control (both on ingress and server sides). Eventually, there may also exist static IP/SGT bindings defined on ISE, but this scenario will not be covered in our analysis. It is interesting to notice that, even though the actual SGT value is a number, the ASA administrator a meaningful name associated to it (figure 4).
Edge devices classify users or devices by integrating with the Identity Services Engine (ISE). After ISE’s policy decision, which may be based on factors that go beyond user identity (posture, device profile, time of the day and the like), an attribute called Security Group TAG (SGT) is assigned to the user or endpoint session. SG tagging is an authorization service (similar to VLAN or dACL assignment) and the selected SGT reflects the privileges associated with the authenticating element. (Notice that the AAA tasks that involve ISE employ the RADIUS protocol, as represented in figure 3).
Data center switches (either physical or virtual) statically create IP/SGT associations for the servers. For physical servers this is typically done at the port level, whereas for virtual machines the SGT is configured within a port-profile in the Nexus1000V VSM (figure 3). It is interesting to underline that the tasks of the VM admins do not change. They will just need to use a drop-down menu to assign a port profile (that contains an SGT parameter) to a virtual machine. Nexus 1000V employs a mechanism called device tracking to build the IP/SGT mappings.
Both edge devices and server switches communicate IP/SGT bindings to ASA using a TCP-based protocol named SGT Exchange Protocol (SXP), as depicted in figure 3.
Because ASA has received the IP/SGT bindings from servers and edge devices, the firewall policies can be significantly simplified, thus potentially bringing a drastic reduction on the number of Access Control Entries (ACEs). To illustrate that fact, imagine that all edge devices have been instructed by ISE to apply the SGT “HR-USERS” to all users classified as members of HR department. Moreover, consider that the Data Center switches have also identified all HR Servers with an SGT called “HR-HOSTS”. The SGT Firewall architecture would allow you to define ACEs as simple as “permit traffic from HR-USERS to HR-HOSTS” (figure 4).

Figure 3 - click to enlarge

It is very important to observe that the SGT FW architecture promotes cooperation among devices. Edge equipment (which know a lot about users and endpoints) dynamically pass information to a central enforcement element, which is close to the servers (where the actual data resides). At this point, it is worth comparing this with a pure 802.1x environment (even those in which ACLs are downloaded to the switches and Access Points):

The ACLs downloaded to the ingress devices (after the Dot1X process) are stateless filters as opposed to ASA rules, which are stateful by definition. Moreover, it is important not to forget, that ASA supports advanced inspection services for many application protocols (instead of just filtering at Layer 4).
Instead of being focused on applications and protocols, the typical Dot1x logging is more user and physical port centric. These AAA reports (authentication, accounting and non-authorized attempts) are very useful for locating the user within the infrastructure (down to the access port level), whereas the classic firewall logs are more helpful for auditing purposes related to acceptable use policies and compliance with standards and regulations. (The good news here is that you still have both categories of logs).
The number of sources in the firewall policy table becomes much smaller using the SGT FW. To see how this is achieved, consider three roles (employees, contractors and guests) and 100 edge devices. If you use VLAN assignment (and correspondent L3 subnet association), you would end up with 300 possible sources. By creating rules based on the dynamic SGT (informed by edge elements), the correspondent policy will include only 3 sources. At this point, you are encouraged to do some calculations for your corporate network, taking into account the number of access switches and APs and the possible user roles (use an SGT per department, for example).
Enforcement is configured centrally. This not only contributes for policy consistency (irrespectively of the underlying network topology) but also reduces the configuration burden for firewall administrators. Another bonus of this new approach is that switch administrators do not need to worry about handling complex filtering rules on a large amount of access devices.
If you do not own ingress equipment which is Dot1x-ready, you may enable credential gathering at Layer 3, by means of the authentication proxy instrumentation available on IOS routers (figure 3). The process employed by IOS devices to challenge the user at the application level is very similar to the Cut-though proxy functionality, earlier described in this article. It is important to observe that SGT/SXP feature set requires ISR G2 platforms (or ASR1000).

Figure 4 - click to enlarge

Conclusion

Even though all 3 forms of Identity-based control are simultaneously available on recent versions of the ASA platform, the third generation represents a huge progress in terms of security and ease of operations. This happens not only because the SGT-FW makes the process of rule maintenance much simpler but also for the optimization it provides with respect to device assignment (each element in the network is being used in a way it can add more value to the overall infrastructure). Another interesting advantage of the SGT FW model is that it is equally applicable to physical and virtual Data Center switches, thus allowing an unprecedented level of integration in the network.

Notes and References

The SGT FW is available on the ISR G2 and ASR1000 router platforms. In the former, source SGT filtering is supported in conjunction with a Zone-based firewall policy.
For more information about Trustsec: http://www.cisco.com/go/trustsec
For a configuration example of the ID Firewall, consider the following article:

https://supportforums.cisco.com/docs/DOC-20366