CCNP Security FIREWALL 642-618 Official Cert Guide (2012)

---

1. Which protocol cannot be used to trigger the user-based proxy capability on the ASA?

a. HTTP

b. TFTP

c. HTTPS

d. FTP

e. TELNET

2. Which of these is not a typical use of AAA on the Cisco ASA?

a. To control administrative access

b. To enable remote-access VPNs

c. To enable IPS capabilities on the ASA

d. To control user sessions across the device

3. Which of these is not typically considered prior to configuring user-based proxy?

a. The Modular Policy Framework Global Policy configuration

b. Information about the AAA infrastructure

c. The user-specific policies

d. Which traffic passing through the device you want to integrate with AAA

4. Which of the following are valid deployment guidelines for user-based proxy services? (Choose all that apply.)

a. Avoid in cases where IP addresses are shared.

b. Consider an external AAA server for scalability.

c. Remove any interface ACLs in place on the inside interface.

d. Engage in these policies only over trusted networks.

5. Which method of authentication presents to the user a web page from the ASA to input credentials?

a. Virtual HTTP

b. HTTP redirection

c. AAA Local

d. AAA External

6. In which situation would you recommend the direct Telnet authentication method?

a. You are using local AAA services.

b. You are using an external AAA service.

c. You are using traffic for which the ASA does not have an authentication proxy.

d. Traffic through the ASA is unusually high in volume.

7. Which of the following is not optional when configuring user-based proxy?

a. Configure accounting rules.

b. Change authentication prompts and timeouts.

c. Configure authentication rules on the ASA.

d. Configure authorization.

8. Which ASA verification command displays a Most Seen column?

a. show aaa users

b. show aaa

c. show users

d. show uauth

9. You need to test your AAA configuration on your Cisco ASA. You want to confirm that a particular server is configured correctly with the correct protocol. You also want to verify that a particular user account and password entry will successfully authenticate. What command should you use?

a. show aaa test

b. test aaa-server

c. test user

d. show aaa user test

Foundation Topics

You might be in an environment where you want to configure different network access policies based on the identity of the user who is attempting to communicate through your Cisco ASA. This capability is termed user-based policies. Cisco also calls this cut-through proxy in some of its documentation. This text will use both terms interchangeably. What is a proxy in this context? It is a device that has the capability to terminate and then reoriginate a connection between some client device in the network and a device acting as a server. This chapter provides all the details of this cut-through proxy configuration, including important information you should consider before and after deploying this Cisco ASA functionality.

This chapter also provides details regarding Cisco Unified Communications proxy features. These features enable the Cisco ASA to terminate encrypted communications, apply a security policy of the organization, and then forward the information along in a re-encrypted form. This not only ensures that no prying eyes can see the original information, but also ensures that your organization can enforce its prescribed access and threat defense policies.

User-Based (Cut-Through) Proxy Overview

User-based or cut-through proxy capabilities are possible on the Cisco ASA thanks to the tight integration with authentication, authorization, and accounting (AAA) services. If you properly configure this feature, when a user attempts to transit your Cisco ASA and access a resource, the ASA will check the user’s identity against a local or remote user database. This is the authentication aspect of the process. Next, user-specific policies can be applied (authorization). Finally, information about user-specific traffic can be sent to a server set up to collect this information (accounting). Although this process sounds lengthy, most of these mechanics take place only once, after which the traffic of the user is “cut through” efficiently.

User Authentication

Here is a more detailed look at the mandatory user authentication process used in cut-through proxy:

• A user of your network attempts to access a resource that requires authentication. The ASA provides a username/password prompt. You configure exactly which resources you want to trigger this authentication behavior.

• This authentication process needs to occur only once per source IP address for all the authentication rules that you configure on the Cisco ASA. This is where the cut-through part of the name originates. The credentials of the user are cached on the Cisco ASA so that subsequent authentication requests do not have to transpire. You can control the timeout behavior of this process.

• Initial authentication can be triggered only by one of the following protocols: HTTP, HTTPS, FTP, or TELNET.

User Authentication and Access Control

Notice that this user authentication described in the preceding list is an additional layer of access control that the Cisco ASA can provide. For example, you know that interface access rules (access control lists [ACL]) form the basis for access control with the Cisco ASA. In fact, you need to carefully consider this in your design. As you plan for user authentication, realize that interface access rules must also permit the sessions that will require user authentication.

The section, “Configuring User Authorization,” covers per-user authorization. This powerful capability allows you to change the default Cisco ASA behavior and have it dynamically download interface access rules on a per-user basis. This could obviously override your need to explicitly permit sessions under the typical interface access rules policy.

Implementation Examples

Perhaps there are ten users in your network that you need to permit to use FTP and HTTPS. There users are located off of the outside interface of your Cisco ASA. The FTP and HTTPS services that they need are located in the inside interface portion of the network. Deploying user-based policies, you can configure the Cisco ASA and the internal AAA server to authenticate these ten users and permit their access. Other end users in your organization can attempt this access through the ASA, but will be denied by the Cisco ASA and the AAA server.

Perhaps this is all working perfectly when it is decided that you do not want one of these ten users to be able to access the FTP services in the inside network. Now, you can add authorization into the mix. The Cisco ASA informs the AAA server that this user is specifically attempting FTP, and the AAA server can fail to authorize such access. As you can see, these per-user policy capabilities add flexibility to the overall Cisco ASA design.

AAA on the ASA

Authentication, authorization, and accounting (AAA) services are used for a variety of purposes on the Cisco ASA. The main three are the following:

• Administrative access: Controlling who can access the ASA from an administrative perspective is a key function of AAA services. Often called console access, this is usually the first (and only) job that many administrators think about when they think AAA.

• Cut-through proxy: Obviously, the focus of this chapter and the controlling of user sessions that transpire “across” the Cisco ASA.

• Remote-access VPNs: AAA also plays a key role when the Cisco ASA participates in the creation of remote-access virtual private networks (VPN) for remote devices to gain secure and managed connectivity to a remote location.

AAA Deployment Options

A key decision that you face when planning to implement cut-through proxy is exactly how you are going to implement the AAA server. You can rely on the Cisco ASA itself to function as the AAA server (using its local authentication database) or you can rely on an external server, such as Cisco Secure Access Control Server (Cisco ACS). There are many versions of the Cisco ACS product, including software-based versions that run on Windows and UNIX platforms.

You should consider using the Cisco ASA local authentication database under the following conditions:

• You require only a single device (the Cisco ASA itself) to provide authentication of network users.

• You have a manageable number of user accounts.

• You require user authentication only in your network environment. You do not need the additional power given to you by authorization and accounting services. (If you also require authorization and accounting, you must have an external server that supports the RADIUS or TACACS+ security protocol.)

• The use of user accounts with static passwords is acceptable under your organization’s security policy.

You should consider using an external AAA server when any of the following conditions is met:

• Your environment features several devices and several existing user credential databases that you want to participate in cut-through proxy.

• You want to require stronger passwords than simple, static strings. An example of enforcing stronger password is the use of one-time passwords.

• You want to take advantage of authorization and accounting services in addition to authentication.

User-Based Proxy Preconfiguration Steps and Deployment Guidelines

Like many of the advanced features of the Cisco ASA, user-based proxy requires important planning before it can be successfully implemented. This section examines the information you should collect prior to deployment and the key criteria you should consider before implementation.

User-Based Proxy Preconfiguration Steps

Before you attempt to deploy user-based proxy configuration on the Cisco ASA, complete the following steps. How long it will take to complete these steps depends on the complexity of your deployment:

Step 1. Determine which traffic flowing through your Cisco ASA you want to control with AAA settings. Specifically, determine which traffic you need to authenticate and then, additionally, which traffic you need to authorize and provide accounting services for. Gathering this data is absolutely critical so that you can create the appropriate AAA rules on the Cisco ASA.

Step 2. Gather all the appropriate information regarding your AAA infrastructure. You need the names and IP addresses of servers, and details regarding the exact AAA services that are configured and available.

Step 3. Document all information regarding user-specific policies that you want to implement. This information is critical so that you can configure the Cisco ASA to enact the appropriate per-user authorization rules you want.

User-Based Proxy Deployment Guidelines

There are several important deployment guidelines that you need to consider prior to implementing cut-through proxy on the Cisco ASA.

The first deployment guideline is to consider using an external AAA server. The main reason to consider using an external AAA server is scalability. Should your implementation need to grow dramatically in the future, an external server ensures that you can minimize the number of changes necessary to accommodate the larger environment. Another important reason is that the external server allows much more manageability in the AAA implementation. For example, specific management applications and methodologies exist for Cisco ACS that can help you gain control over the network infrastructure and its access. Finally, an external AAA server provides a valuable central store of accounting information regarding user activities. For companies that are interested in storing this information, this external server is absolutely critical.

Another key deployment guideline is that the cut-through proxy feature should not be used over untrusted networks. Because the Cisco ASA tracks authenticated users by their IP address, a man-in-the-middle or spoofing attack could compromise resource access. In fact, the exchange of credential information from your end users and the Cisco ASA is carried out in clear text. This exchange should take place only over a trusted network.

The final deployment guideline is to avoid user-based proxy in any environment where users share IP address information. A classic example of such an environment is one that uses Port Address Translation (PAT, a form of Network Address Translation [NAT]). When two users share the same IP address (as in PAT), the Cisco ASA will authenticate the first user, and then allow subsequent users access based on that IP address. Typically, allowing this type of access is not desired, of course, so be careful implementing cut-through proxy in such environments.

Direct HTTP Authentication with the Cisco ASA

In some environments, sending an internal user’s credentials to a remote web server is not desirable. In such an environment, you can configure direct HTTP authentication with the Cisco ASA. This is recommended if your internal users’ credentials would be passed over an untrusted network to the remote web server. This is often the case in deployments where the Cisco ASA protects your internal network from the public Internet. Another case in which you might need to configure direct HTTP authentication with the Cisco ASA is where the remote web server requires different username and password credentials using a separate authentication process.

The Cisco ASA provides two solutions for direct HTTP authentication:

• HTTP redirection

• Virtual HTTP

HTTP Redirection

With the HTTP redirection method, the Cisco ASA actively listens for HTTP requests on TCP port 80. When the Cisco ASA detects such requests, it redirects internal users to a local web page that is a form for the user to input their appropriate credentials. If the user is authenticated properly with these credentials, the user is then directed to access the external web server. If the external web server requires its own separate authentication process and credentials, it can challenge the user directly at that time. This method nicely accommodates an external web server that has its own authentication scheme. Of the two solutions, HTTP redirection is the newer of the methods and does not require an allocated IP address.