Note: It's important to note that the description is based on Cisco ASA version 8.4(1) and ASDM version 6.4(1), during testing I upgraded to 6.4(3). The configuration in older versions may be significantly different.
Port Forwarding
Using Port Forwarding, we can allow access to some applications on servers in the corporate network through the established Clientless VPN. The principle is that a local listener is created on the client, which listens on the specified port and sends everything it receives through the tunnel to the target server and port.
This method ensures port redirection from the local station through the ASA (and Clientless VPN) to the internal network. This allows the operation of some applications that use static TCP ports, without the need for a full-fledged VPN. This is an older method, and Cisco now recommends using Smart Tunnels. The principle of both methods is different, but the advantages of Smart Tunnels prevail.
For operation, we need administrator privileges on the station and because it is a Java Applet, we need an installed Java (Sun JRE at least 1.4). This applet starts listening on the defined port on localhost (i.e., 127.0.0.1). So in the configuration on the ASA, we must set a local port that is not used on the clients. And the received data is forwarded through the SSL tunnel to the target IP address and port.
Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Port Forwarding
We create a Port Forwarding List with a descriptive name and add a Port Forwarding Entry to it, i.e., individual rules where we specify the local and remote TCP port and the IP address of the remote server. Theoretically, both ports can be the same, but if we want to use RDP, i.e., port 3389, we usually have to use a different local port (because RDP also runs on the client).
Configuration > Remote Access VPN > Clientless SSL VPN Access > Group Policies
The created Port Forwarding List is then assigned to a specific Group Policy (another option is Dynamic Access Policy or directly to the user). We edit the policy where we want to assign the Port Forwarding List and on the Portal tab under Port Forwarding Control, we select our list.
We can also check the Auto Applet Download item, then immediately after logging in to the portal, a window will open that will run the Port Forwarding applet. Manual launch is located on the Application Access tab under the Start Applications button (we can have only one list assigned and it is applied in full). When using it, we must direct the communication from the application not to the server IP address, but to the local address and the specified port.
Smart Tunnels
Using Smart Tunnels, we ensure that all traffic from a specified application (process) on the client is sent through the SSL tunnel to the internal network. There are two types, Smart Tunnel Application Access (see previous description) and Smart Tunnel Enabled Bookmark (essentially set for the browser, more on that later).
As we said, when Smart Tunnel is enabled, the traffic of the specified process is redirected into the tunnel to the Cisco ASA. The application then cannot communicate to the local network (or directly to the internet). It is also important that the application gains access to the corporate network wherever the ASA has access (we don't specify the target server). If we want to restrict communication, we must use the Web ACL.
For example, we can ensure access from the MS Outlook Express application to the internal POP3 server. Or access via Remote Desktop Protocol (mstsc.exe application) to a server.
A good feature of the Smart Tunnel is that we don't need administrator rights. For functionality, it first tries to use ActiveX and then Java. Smart Tunnel works for many applications, but not for all (e.g., applications written in .NET). In terms of performance, it is the best option, for example, compared to plugins.
Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Smart Tunnels
Configuring Smart Tunnel is very simple, and so is its use (after enabling, we can use the application the same as if we were in the company, no configuration change is required). We create a Smart Tunnel Application List with some name and add individual Smart Tunnel Entry items to it, where the main thing is the process name by which it is searched for on the client. We can also enter a hash (checksum) by which the application is precisely identified.
Configuration > Remote Access VPN > Clientless SSL VPN Access > Group Policies
To assign the Smart Tunnel Application List to the user, we can set it on a specific Group Policy, Dynamic Access Policy, or directly on the user. In the selected policy, we find the setting on the Portal tab under Smart Tunnel Application.
We can also check the Auto Start item here, then the Smart Tunnel will start automatically after login. Or Smart Tunnel All Applications, then all processes of the logged-in user are sent through the tunnel.
Configuration > Remote Access VPN > Clientless SSL VPN Access > Portal > Bookmarks
A somewhat specific part are the Smart Tunnel Enabled Bookmark. We can access web pages through Smart Tunnel as well. When we check Enable Smart Tunnel on a created Bookmark, we actually create a Smart Tunnel for any web browser. Clicking on such a link on the portal will open a new browser window and we access the internal server web page directly. This is different from the access through the proxy in the classic Clientless SSL VPN option. But the entire traffic from the web browser instance is sent to the tunnel, so if we don't handle it using the Web ACL, the user can enter various internal web addresses.
Configuration > Remote Access VPN > Clientless SSL VPN Access > Advanced > Web ACLs
Here we can create Access Control Lists that restrict traffic. We then assign them to the Group Policy, Dynamic Access Policy, or directly to the user. We create ACL lists and individual ACE (Access Control Entry) records in them. In the rules, we can select the protocol and addresses, which we enter either using the DNS name or IP address. The form of entry is important, as it must be used further (DNS is not converted to IP address). We can use wildcard characters like * and ? in the address.
Cisco Secure Desktop (CSD)
CSD is a feature that we can use with Clientless SSL VPN or with the AnyConnect client. It offers several functions, all of which relate to security on the client side. Most CSD features are available without administrative privileges. They are suitable for use when accessing from unsecured computers. The components are:
- Host Scan - on the client connecting to the VPN, it checks several parameters and allows the connection only if they are met. It can check values in the registry, files, processes, verify antivirus and definition age (for a large number of manufacturers), firewall, etc. The scan result is sent to the ASA, and we can react to it using DAP (e.g., connect to a quarantine network).
- Secure Desktop (Vault) - creates a virtual desktop and an encrypted partition where all data is stored during the VPN session, the entire content is deleted when the session ends
- Cache Cleaner - a small alternative to Secure Desktop, at the end of the session it tries to delete all browser data that was created during the connection (cache, passwords, autocomplete, etc.)
- Keystroke logger detection - detects the presence of suspicious applications that could perform key capture or client emulation, in which case it does not allow access to the VPN
With CSD, there is a problem with supported operating systems. Support varies for individual components. Until recently, the latest version was 3.5.841.0 and it did not support Vault and Keystroke logger detection at all on Windows 7 (it only supports the 32-bit version of Windows XP and Windows Vista). Now the new version 3.6.181.0 supports Windows 7, but only the 32-bit versions. It seems like a security flaw to me that when we enable Vault on a connection and the user has an unsupported OS, they can still normally connect to Clientless VPN (the Vault usage step is simply skipped and it goes on).
As for the other components, Host Scan and Cache Cleaner are supported on various Windows, Mac OS X, and several Linux distributions.
Note: I first tested with version 3.5.841 and then upgraded to 3.6.181. CSD is not tied to the ASA version and can be installed separately.
Configuration > Remote Access VPN > Secure Desktop Manager > Setup
Until we select the CSD image from the ASA flash memory to be used, we only have this option. The page allows us to select an image uploaded to the flash memory or upload a new version from the computer to the ASA.
Another important item is Enable Secure Desktop. If we check it, additional items for configuring the individual features will be displayed in ASDM. And most importantly, CSD will be enabled immediately after applying. This means that when we now open the portal page of Clientless SSL VPN, the CSD WebLaunch will first start. It detects if ActiveX or Java is available, installs the components, and performs the checks (according to what we have configured). Only then, if the checks are successful, the login page will be displayed.
Configuration > Remote Access VPN > Secure Desktop Manager > Prelogin Policy > Default
In the previous step, we enabled CSD, now we need to enable/configure the individual functions. Here we set whether to use Secure Desktop (Vault) or Cache Cleaner, or neither option (only Host Scan will be used). If we check Vault, the fallback works, if Vault cannot be used, at least Cache Cleaner will be used.
Configuration > Remote Access VPN > Secure Desktop Manager > Prelogin Policy
Here we can conveniently create a decision tree, i.e., various pre-login checks, and set under what conditions login is allowed. We can check registry entries, files, certificates, OS version, or IP address.
So we can simply set that the user can only connect from Windows and from a given address range. If the conditions are not met, the login page will not even be displayed.
Configuration > Remote Access VPN > Secure Desktop Manager > Prelogin Policy > Default > Secure Desktop (Vault) General
To access these settings, we must have Secure Desktop (Vault) enabled, then we can configure its options in detail. Here are the global settings, such as whether we can switch from the secure desktop to the standard one or allow the desktop to be reused.
The following image shows what the standard Vault looks like on the client, here almost everything is allowed. With a restrictive setting, we won't see any icons on the desktop or the Start bar, and only the web browser will be available.
Configuration > Remote Access VPN > Secure Desktop Manager > Prelogin Policy > Default > Secure Desktop (Vault) Settings
Here are the security settings, we can restrict access to network and USB drives, disable printing, editing the registry, etc. The image shows the dialog when closing the Vault.
Configuration > Remote Access VPN > Secure Desktop Manager > Host Scan
Host Scan allows us to obtain some information from the client station and decide during login whether access is allowed. We can test for the existence of a file, registry key, or running process. Furthermore, we have the standard Host Scan Extension called Endpoint Assessment. This allows us to test some of the dozens of Antivirus, Firewall, or Antispyware programs. We can test if the process of a given application is running (we can test by manufacturer, product, and version) and how old the definitions are.
The usage is that in the Host Scan, we define the tests we want to use. These are executed on the client in the initial WebLaunch Secure Desktop phase. In contrast to the Prelogin Policy, a decision is not made based on them, and the login dialog is displayed in any case. And it is only used during authentication. To work with the Host Scan result, we must use the Dynamic Access Policy (DAP).
Configuration > Remote Access VPN > Clientless SSL VPN Access > Dynamic Access Policies
We switch the default policy DfltAccessPolicy (Action) to Terminate (deny access) or Quarantine (quarantine - special defined accesses will be applied), because if the conditions of the other policies are not met, this one would be used, and we want the result to be no login.
We create a new policy and set the conditions for who it should apply to (by user name, group policy, etc.). Next to that, we set which endpoint attributes the client must meet, here we can select pre-prepared items from Host Scan. If we want some users to be able to access without meeting these conditions, we must create another policy where we select these users and don't set any other conditions.
Subsequently, when the client authenticates, the DAP that meets the set conditions is searched for. If one is found, we are logged in. If none is found, the DfltAccessPolicy is used, where we have denied access.
Configuration > Remote Access VPN > Secure Desktop Manager > Prelogin Policy > Default > Cache Cleaner
If we enable Cache Cleaner, some parameters can be set here. Theoretically, it should work simply without any configuration. But I was unable to get the Cache Cleaner feature to work. If you have experience with it, I would welcome your advice in the comments.
K endpoint atributum dluzno dodat, ze kontrola certifikatu se v tomto pripadu omezuje na pouhe porovnavani retezcu v nem obsazenych :-(.
Jinymi slovy, muzu zadat podminku ze "cn=xyz" a "ou=123", ale zda-li ten je ten certifikat vubec platny nikoho nezajima. Proste neco na urovni, srovnatelne s vyse zminovanou kontrolou pritomnosti urciteho souboru ve filesystemu ci klice v registrech.