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/)
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:
The previous article presented the basic theory behind the Authentication Proxy (Auth-proxy) functionality on Cisco IOS Software. The current post goes one step further, by bringing an example of a simple Authorization Profile that can be passed back to the router after successful authentication.
Figure 1 depicts the reference topology and shows the perspective of the router:
- Auth-proxy is used to obtain the user credentials
- The credentials are sent to the RADIUS Server for validation
- Sample RADIUS Authorization Profile downloaded after Auth-Proxy
Figure 2, the natural companion of the previous one, brings some valuable information:
- It illustrates the authorization task ( a natural follow-on to authentication). Remember that mere authentication (without differentiating users by means of authorization) is virtually meaningless. In our particular scenario, the attributes downloaded (“proxyacl#“), correspond to individual Access Control Entries (ACEs) that have been configured beneath the user group to which user1 belongs.
- It highlights the user to IP mapping obtained after authentication
- It shows how that the router is aware that Auth-proxy was the feature in charge of downloading the per-user ACEs.
Figure 2: Authorization within Auth-proxy environment
- In a very similar fashion, the RADIUS server could had sent a Donwloadable ACL (DACL) to the router (instead of individual ACEs).
- Actually, many other attributes could have been passed to the router during the authorization phase.
- Rigorously speaking, RADIUS does not have a separate authorization process. It simply downloads some sort of authorization profile after successful authentication.
- The baseline router configuration documented in the previous post works for several Auth-proxy environments. The definition of the RADIUS attributes to be sent to the router takes place on the server side (typically Cisco Secure ACS or, more recently, the Identity Services Engine).
** Related Posts:
In a previous article, “Cisco Firewalls and user-based access control“, we revisited the concepts of Authentication, Authorization and Accounting (AAA), and mentioned that both the Cisco ASA and Cisco IOS firewall families can be configured to create connections taking into account some kind of user information.
The current post builds upon that discussion and presents the Authentication Proxy (Auth-proxy) feature, which constitutes the basic instrumentation for user-based features on Cisco IOS routers.
In our particular example, Auth-proxy is triggered by telnet (because it is “a very easy to understand and document” protocol). It is interesting to know, though, that Auth-proxy is also supported over FTP, HTTP and HTTPS.
It is relevant to emphashize that Auth-proxy is actually borrowing the authentication capability embedded in one of these application protocols to obtain user credentials and hand them to the RADIUS process. By intercepting a protocol that natively includes authentication, the router can now talk to the RADIUS server and receive (for valid users) an Authorization Profile that reflects the user privileges. The process is summarized in figure 1.
Figure 1: Summary of IOS Authentication Proxy (Auth-Proxy) operation
Figure 2 documents the basic settings to enable Auth-Proxy (these will be deemed “well-known” on upcoming articles). The basic blocks are:
- Handling of RADIUS Vendor Specific Attributes (VSAs) by the router
- AAA Server and related AAA services (Authentication, Authorization and Accounting)
- The Static ACL to be applied to the interface
- The triggering protocol for Auth-Proxy (telnet in our case)
- Enabling Auth-Proxy at a given interface (always for incoming packets)
Figure 2: Basic Configuration Steps to enable Auth-Proxy
- When used as a standalone feature, Auth-Proxy is stateless in nature.
- Auth-Proxy can be rendered stateful when combined with Context Based Access Control (CBAC) or the Cisco Zone-based Policy Firewall (ZFW). In this last case, we will have the so called user-based Zone Firewall.
** Topics for Study:
- Play with the other triggering protocols (HTTP, HTTPS, FTP). The user experience for HTTP/HTTPS is very similar to that of Wi-fi hot spots: after getting the user credentials (frequently through a web browser prompt), and correctly authenticating the user, access is granted.
- Why should HTTPS be a particularly interesting option ?
- Stay tuned: other articles will cover mode details about Authorization Profiles.
** Related Posts:
The current post concentrates on the creation of rules that may include, not only the IP addresses of source and destination systems interconnected by Cisco firewalls, but also identity information related to the users initiating the connection requests. Before we start creating this new category of rules, it is advisable to get familiar with a set of relevant concepts.
The AAA (Authentication, Authorization and Accounting) architecture defines a modular way for these three security functions to interact. The AAA components may be easier visualized if associated with the questions they were designed to answer:
- Authentication deals with answering the question “who is the user ?”
- Authorization is in charge of defining “what the user (previously authenticated) is allowed to do”
- Accounting relates to the question “what the user did ?”. Through this process, the accounting client collects user activity information and sends it to the accounting server.
The AAA framework may be applied to provide identity-based control on two complementary domains:
- Control of regular users that need to pass traffic through the firewall: the mechanisms employed by Cisco firewalls to materialize this functionality are the Cut-through Proxy (on ASA family) and Authentication Proxy (on IOS). RADIUS is optimized for this type of task.
- Control of administrative users that are required to configure and monitor the devices themselves. TACACS+ is optimized for the tasks that involve command authorization and accounting.
The following figure summarizes typical questions that should be answered before you start configuring user-based access control through the firewall. Other posts will detail some of the available solutions.
The basics of user-based access control through Cisco firewalls
** Related Posts: