VPN 4 - Configuration Cisco Clientless SSL VPN on Cisco ASA

Clientless SSL VPN, previously called WebVPN, is a technology that offers limited secure access to some corporate resources. Because the capabilities are limited, it is suitable only for a certain type of deployment. On the other hand, the given limitations can be an advantage in many cases (we can greatly restrict client access). Another positive is that no client, administrative rights on the station, or special firewall traversal is required, as access is done using a web browser standard on HTTPS port 443 (data flows through an SSL tunnel).

The protocols and theory behind Clientless SSL VPN are much simpler than those for IPsec VPN. The user accesses the portal via a web browser. Access is via the encrypted HTTPS protocol, typically on port 443. First, form-based authentication must be performed, and then the portal with the set options is accessible. It allows access to internal web applications (http, https), file servers (CIFS, FTP), server consoles (RDP, SSH, telnet, VNC). Cisco ASA acts as a secure proxy, so all traffic from the client is routed to this device and a new connection is established from here to the target application. This can cause problems for some applications, but it ensures higher security. For example, if an infected client connects, the virus cannot spread (in the usual way) to the company.

If we're dealing with https web applications, we might consider the use of SSL VPN as unnecessary and duplicative. But this is not always the case, and the ASA increases security. Web applications often have several pages that are publicly accessible and can be attacked. Web and application servers also have various vulnerabilities that can be exploited.

Through Clientless SSL VPN, we can set access to a pre-selected group of resources on the corporate network (which is a more secure option). Or we can allow access to all resources of a given protocol (a field for entering the address is available). The officially supported clients are Internet Explorer 6, 7, 8, and Firefox 3 from various Windows, Linux, and Mac OS versions.

The above are the basic options for Clientless SSL VPN, which we will focus on in this article. Next time, we'll look at additional options that will allow even wider use of this type of VPN. Mainly, these are Smart Tunnel and Cisco Secure Desktop.

In older Cisco materials, SSL VPN is divided into three options:

• Clientless SSL VPN (WebVPN) - access through a web browser
• Thin-Client SSL VPN (Port Forwarding) - uses a Java applet that maps a static server port to a local one, i.e., port tunneling
• SSL VPN Client (Tunnel Mode) - full VPN access using a client, either pre-installed or downloaded from the web only for the duration of the connection

What We Will Configure

We will create a portal, accessible via the https protocol, that will allow access to the internal web server and corporate file server. Users will authenticate via the RADIUS server (to Active Directory).

We will perform almost the entire configuration using the Java application Cisco Adaptive Security Device Manager (ASDM).

Note: It's important to note that the description is based on Cisco ASA version 8.4(1) and ASDM version 6.4(1). The configuration in older versions may be significantly different.

What the Clientless SSL VPN Configuration on Cisco ASA Consists Of

We could use the wizard in the menu Wizards - VPN Wizards - Clientless SSL VPN Wizard to set it up, but we'll proceed manually. The basic configuration is much simpler than for IPsec VPN. But if we want to set everything up nicely and securely, we need to modify the individual portal pages in detail and specify the accessible resources in the corporate network. It's also a good idea to prepare an SSL certificate for the portal in advance. If we don't have a Certificate Authority available, we can use a self-signed certificate generated by the ASA.

The main objects we need to configure are:

• Portal - the entire group of settings (portal resources) that define how the web portal will look, we select here the resources that will be accessible, and define the appearance (either by modifying existing templates or by performing a complete modification by uploading HTML code)
  • Bookmarks - predefined links to resources
  • Client-Server Plugins - allow access to special services (e.g., RDP, SSH) using a plugin through a web browser (Java)
  • Smart Tunnels - create a tunnel for a specific application on the client, all traffic from the application is then routed through the tunnel and through the ASA to the corporate network, so we can use applications other than just a web browser
  • Port Forwarding - redirects the user's local port to an application on the server (e.g., localhost:9025 routes to mail.firma.local:25), so it allows access to an application, today it is recommended to use Smart Tunnels
  • Customization - allows configuring the appearance of the logon, logout, and portal pages
• Group Policies - policies control user access to resources (resource control) and connection behavior (session control), i.e., what and how the user sees, we assign Portal modifications
• Connection Profiles (previously Tunnel Group) - determines the parameters for creating the session, mainly controls user authentication, we assign the Group Policy to it

The Process of Establishing a Clientless SSL VPN

• the Connection Profile is selected
• the Group Policy (or user attributes from other locations) is assigned
• user authentication is performed (according to the settings in the Connection Profile) and the portal page is displayed (according to the defined parameters)

The principles here are similar to those of IPsec VPN, so we can also use Dynamic Access Policy (DAP), which has greater weight than the Group Policy. For security on the client-side, we can use the Secure Desktop Manager (SDM).

Again, it's important how a particular Connection Profile is assigned. The options are probably not many. Either we allow the user to choose the profile on the login page. Or the default DefaultWEBVPNGroup profile is used automatically. So in practice, we'll probably often use the default profile and control the policies at the level of assigning the Group Policy (and similarly).

Group Policy can be assigned from the Connection Profile or assigned to the user (for local users, we can set all Clientless SSL VPN parameters in detail) perhaps from the RADIUS server using attribute 25. The default Group Policy DfltGrpPolicy and DAP are also used in this location.

Practical Steps for Configuring Clientless SSL VPN

We'll assume that the basic configuration of the Cisco ASA is already done. It was described in the paragraph 1. Configuring the ASA Device of the article VPN 3 - Configuration IPsec Remote Access VPN on Cisco ASA. But we don't need to deal with IP address assignment from DHCP, as we use our own address for communication. It's important not to forget the routing configuration. In contrast to IPsec VPN, where traffic passes through the Tunnel interface, in Clientless VPN it is initiated directly from the ASA, so it must have access to all resources in the corporate network.

We'll draw a brief schematic diagram of the connection and identify the applications we want to make accessible.

1. Basic Clientless SSL VPN Configuration

Configuration > Remote Access VPN > DNS

To be able to access internal servers by DNS name, the ASA must know the corresponding (internal) DNS server. This is set here. Configure one DNS server group means that one group with DNS servers will be created with the name DefaultDNS.

• Primary DNS Server: IP address of the primary DNS server
• Secondary Servers: IP address of the backup DNS server
• Domain Name: internal domain

At the same time, we must enable on which interface DNS queries are allowed. In the DNS Lookup section, we'll enable DNS for the inside interface.

Configuration > Remote Access VPN > Clientless SSL VPN Access > Group Policies

We can create one or more policies for access or just edit the default DfltGrpPolicy (we'll at least check it, because Inherited values will be used from it). We decide to create a new policy Clientless_policy. We'll leave most of the values Inherited, but in the General tab, we'll expand More Options and check tunneling protocols Clientless SSL VPN. This will allow users assigned this policy to access Clientless SSL VPN.

Configuration > Remote Access VPN > Clientless SSL VPN Access > Connection Profiles

At the top of the page in the Access Interfaces section, we must enable clientless SSL VPN for a specific interface. Ours is called outside. With the Device Certificate button, we should assign an SSL certificate.

Then we can create a new profile or edit the default one. As we said above about assigning Connection Profiles to users, we'll use the default DefaultWEBVPNGroup. We'll set a few properties:

• Method: AAA
• AAA Server Group: our AAA group
• DNS Server Group: DefaultDNS
• Default Group Policy: Clientless_policy
• Enable clientless SSL VPN protocol

If we want to use a profile other than the default, we need to enable a setting on the page that allows the profile to be selected. Only profiles with the Aliases value set will appear in the selection.

Allow user to select connection, identified by alias in the table above, at login page.

Via CLI - Setting a parameter for the Connection Profile

Just like with IPsec VPN (because the method is the same), we need to make the following settings on the profile via the command line if we want to use MS-CHAPv2 on the RADIUS server.

ASA(config)#tunnel-group DefaultWEBVPNGroup general-attributes
ASA(config-tunnel-general)#password-management

Until we do this, authentication on RADIUS will go through PAP. And if we have only MS-CHAPv2 enabled on RADIUS, it won't work for us. On the RADIUS server, it will be logged that the request came through the unsupported PAP. I would expect some error during login to be written to the log on the ASA, but it is only written as Information (6) AAA user authentication Rejected, so we can easily overlook it (if we're, for example, sending errors to syslog).

2. Advanced Clientless SSL VPN Settings

After the previous setup, we could already log in to the portal and see the default items, so the VPN is functional. But we probably want to increase security by restricting access and modify the appearance of the portal pages in a corporate way.

Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Bookmarks

Bookmark list contains a list of resources that are accessible from the Portal page. We assign it using the Group Policy, to the user, or using DAP. We create a named list and place links of various protocols in it.

Configuration > Remote Access VPN > Clientless SSL VPN Access > Group Policies

Assigning the Bookmark List is most common through the Group Policy. We open the selected policy and switch to the Portal tab, and in the Bookmark List item, we enter our list.

For greater security, it is recommended to perform additional settings and that is to disable manual server address entry and leave only the Bookmarks option. The setting is also (among others) in the Group Policy on the Portal tab, the URL Entry item. In practice, I had to set the File Server Entry item, which should only concern file servers, to Disabled as well.

Configuration > Remote Access VPN > Clientless SSL VPN Access > Advanced > Web ACLs

For better security, it is further recommended to create a Web ACL where the allowed addresses (using URL or service address) are listed. We create an ACL and enter the individual ACE records in it. We then assign the Web ACL to the Group Policy on the General tab, expand More Options and the Web ACL item.

Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Web Contents

At this point, we can import files on the ASA that we will use to modify the portal pages. An example is the company logo or a page in HTML.

Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Customization

Again, we need to consider whether we will modify the default object or create a new one and assign it to a specific Group Policy/Connection Profile. Using Customization, we can relatively easily modify the appearance of the portal pages. If we want to make a complete change to the portal, we perform a so-called Full Customization, the description maybe in Replacing the Logon Page with your own Fully Customized Page.

On the main page, we can also enable the use of an OnScreen Keyboard for the login page (or all where authentication is performed). Then the password must be entered with the mouse on the graphical keyboard on the screen, preventing it from being captured by a Keylogger.

Note: We can also create various language versions of the pages Configuration > Remote Access VPN > Language Localization.

Configuration > Device Management > Advanced > SSL Settings

For the security of SSL VPN, it is important which version of SSL/TLS is used and which encryption algorithms are used (for example, not using RC4-MD5). We can control the settings here.

3. Different Policies for Users from the RADIUS Server

I think a situation often arises where we need to set different permissions for different users. Along with the fact that user authentication is against the RADIUS server (which uses some directory service, for us MS Active Directory). We have several options for control, but Group Policy seems to me the main one.

For IPsec VPN, we can assign Group Policy according to the Connection Profile and that based on the information in the certificate installed for the user. Alternatively, when using PSK, the user must know the profile name and enter it (something like a password), but this is not as secure, because they can find out the name of another profile and nothing prevents them from using it. For Clientless VPN, either the default profile is used (so nothing is divided) or the user is shown a combo where they can select a profile, but again nothing prevents them from choosing any one.

The only option for control is therefore to assign the Group Policy firmly to the user. For local users, this would be simple, but we're interested in the RADIUS server. Of course, this option is there and is not even complicated. The following description gives the standard option, many things can be set up differently. We use MS Active Directory and RADIUS, which is part of Windows Server 2008, i.e., Network Policy and Access Services (NPS).

• in AD, we must divide the users into groups (Group) according to how we want to assign different policies to them
• on NPS, we create the same number of Network Policies and set the client (Cisco ASA) and Windows Group (one group from AD for each policy) as the Conditions
• in each Network Policy, we set Settings - RADIUS Attributes - Standard a new attribute number 25 (name Class) as a string with the value OU=Policy_group (always the name of the policy on the ASA corresponding to the user group, must exist)

Then, when the user logs in, they use some Connection Profile, perhaps even the default one, and from it, the Group Policy is assigned to them. After authentication, they receive a different Group Policy attribute from the RADIUS server, and that overwrites the previously assigned value.