Advanced WebVPN Features

Once the applet is loaded on the client, the user can establish a Telnet connection to the server by using the loopback IP address of 127.0.0.1 on the local port 1100. This will redirect the connection over the WebVPN tunnel to the server at 192.168.10.20 on port 23.

Note

It is recommended to use a local port between 1024 and 65535 to avoid conflicts with the existing network services.

The port list can then be mapped to a default, user group, or user policy. In Example 16-71, the port list telnet_inside is mapped to a user group-policy named SecureMeWebGrp under the WebVPN submenu. Mapping of the list to a policy is done by using the port-forward value command followed by the name of the list.

Example 16-71. Port-Forwarding List Mapping

Chicago(config)#

group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)#

vpn-tunnel-protocol webvpn

Chicago(config-group-webvpn)#

webvpn

Chicago(config-group-webvpn)#

functions port-forward

Chicago(config-group-webvpn)#


port-forward value telnet_inside

The login page shows a default link of "Start Application Access" to launch the port-forwarding applet. This link can be renamed to accommodate the security policy of an organization. In Example 16-72, the link for the port-forwarding applet on the main login page is changed to " SecureMe Port-Forwarding".

Example 16-72. Configuration of Port-Forwarding Applet name

Chicago(config)#

group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)#

vpn-tunnel-protocol webvpn

Chicago(config-group-policy)#

webvpn

Chicago(config-group-webvpn)#

functions port-forward

Chicago(config-group-webvpn)#

port-forward value telnet_inside

Chicago(config-group-webvpn)#


port-forward-name value SecureMe Port-Forwarding

Configuring URL Mangling

Using WebVPN, remote users can browse their internal websites . Cisco ASA terminates the HTTPS connections on the public interface, and then forwards the HTTP or HTTPS requests to the specified server. The response from the web server is then encapsulated into HTTPS and forwarded to the client. This feature, known as URL mangling, is illustrated in Figure 16-19. The following sequence of events takes place when UserA tries to connect to a web server located at 192.168.10.10:

With URL mangling, the original protocol, host address, port number, and path get manipulated to establish connectivity to the Cisco ASA. The original protocol field is replaced with https, while the original address and port are replaced with the IP address and port of the security appliance. The mangled path in the URL is augmented with the protocol, port, and host elements of the original URL. Figure 16-20 shows the original and the modified URLs.

Table 16-6 lists four examples of the original and the mangled URLs. The Cisco ASA IP address is 209.165.200.225.

Table 16-6. Original and Mangled URLs in WebVPN

The flags parameter, shown in Figure 16-20, integrates the original port number and a set of other flag values. It is the ASCII representation in decimal, with the lower 16 bits reserved for the port and the upper 16 bits reserved for flags. Port 0 is used if the original URL either contains 80 (for HTTP) or 443 (for HTTPS). The upper 16 bits are currently not used.

Note

The current implementation of WebVPN cannot modify Java and ActiveX coding in a web page. Additionally, Cisco ASA does not mangle non-HTTP-based URLs such as ftp:// or telnet://.

The configuration of URL mangling involves setting up a URL list to specify the IP address of the web server(s). The command syntax to define a URL list is as follows :

url-list


listname displayname url

where:

• listname is the name that is then used to map the url-list to a user or group-policy.

• displayname is the name that is shown to the WebVPN user after a successful user authentication.

• url is the actual URL to a web-server that resides toward the inside interface.

In Example 16-73, a URL list named HTTP_Link is set up with a displayname of Internal and the host URL of http://192.168.10.10.

Example 16-73. URL Mangling List

Chicago(config)#

url-list HTTP_Link "Internal" http://192.168.10.10

The URL list is then linked to a user or group-policy by using the url-list command followed by the name of the URL list. In Example 16-74, the URL list HTTP_Link is applied to the SecureMeWebGrp group under the webvpn submenu.

Example 16-74. URL List Mapping to a Group-Policy

Chicago(config)#

group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)#

webvpn


Chicago(config-group-webvpn)#

url-list value HTTP_Link

Cisco ASA can optionally forward HTTP WebVPN sessions to either an HTTP or HTTPS server. These proxy servers act as the intermediary servers between the WebVPN users and the Internet. This greatly enhances network security by filtering unnecessary web traffic in the network. Example 16-75 shows the configuration for Cisco ASA to be set up as an HTTP server located at 192.168.10.100 and as an HTTPS server with an IP address of 192.168.10.200.

Example 16-75. HTTP/HTTPS Proxy Configuration

Chicago(config)#

webvpn

Chicago(config-webvpn)#

http-proxy 192.168.10.100 80

Chicago(config-webvpn)#

https-proxy 192.168.10.200 443

As a security device, Cisco ASA has the capability to filter out Java or ActiveX applets, script tags, display images, and delete cookies from the HTML pages when they are sent over a WebVPN connection. This is done by using the html-content-filter command followed by the selected parameter to filter. The Cisco ASA configuration in Example 16-76 sets up the capability to filter out Java/ActiveX and display images when the HTML pages are sent to the client.

Example 16-76. HTML Content Filtering

Chicago(config)#

group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)#

vpn-tunnel-protocol webvpn

Chicago(config-group-webvpn)#

webvpn

Chicago(config-group- webvpn)#


html-content-filter java images

E-Mail Proxy

WebVPN provides a way for the remote users to check e-mail using the secure HTTP connection. This feature, known as e-mail proxy, provides a seamless connection from an e-mail client to the server. Users have the option to either authenticate themselves to the GUI WebVPN authentication screen or set up the e-mail client for automatic user authentication.

Cisco ASA supports three types of e-mail proxies: SMTP, IMAP4, and POP3. All of these proxies use their own unique SSL/TLS ports. Cisco ASA uses the default TCP ports of 988, 993, and 995 for SMTP, IMAP4, and POP3, respectively. All of these proxies are disabled until explicitly enabled on the physical interface by configuring the enable command, followed by the name of the interface terminating the connections, under the e-mail proxies' subconfiguration menu. The Cisco ASA configuration in Example 16-77 enables the security appliance to accept IMAP4, POP3, and SMTP proxies on the outside interface.

Example 16-77. Enabling E-Mail Proxy on the Outside Interface

Chicago(config)#

imap4s

Chicago(config-imap4s)#

enable outside

Chicago(config-imap4s)#

pop3s

Chicago(config-pop3s)#

enable outside

Chicago(config-pop3s)#

smtps

Chicago(config-smtps)#

enable outside

Cisco ASA provides protection against denial of service (DoS) attacks against the e-mail servers when deployed as an e-mail proxy. The user has to be authenticated first by the security appliance before the session is opened for e-mail transfer, as illustrated in Figure 16-21. After a successful user authentication, Cisco ASA opens a session to the e-mail server and forwards the user credentials for validation.

Once the WebVPN session is authenticated, the Cisco ASA's default behavior is to apply the attributes configured under the DfltGrpPolicy group-policy. However, a user group-policy can be applied to the e-mail proxies by configuring the default-group-policy command followed by the name of the user group-policy. In Example 16-78, the IMAP4 proxy is associating the SecureMeWebGrp user group-policy with the authenticated IMAP4 sessions.

Example 16-78. Mapping of User Group-Policy on the IMAP4 Proxy

Chicago(config)#

imap4s

Chicago(config-imap4s)#

enable outside

Chicago(config-imap4s)#

default-group-policy SecureMeWebGrp

Authentication Methods for E-Mail Proxy

Cisco ASA supports three methods for e-mail proxy authentication:

• Piggyback authentication

• AAA authentication

• Certificate authentication

Piggyback Authentication

With piggyback HTTPS, a user is required to have a WebVPN session already established before connecting to the e-mail server. The user provides their e-mail username and passwords for authentication. If the VPN and e-mail usernames are different, the user is required to provide both of them, separated by a VPN delimiter (discussed later in this chapter). The VPN user credentials are used to verify only that the WebVPN session is already established. If the session is not established, the user is not allowed to connect to the e-mail server.

Caution

Due to an inherit flaw in SMTP, if piggyback authentication is used with SMTP, an attacker can potentially send spam e-mail messages using any name and using a legitimate user account. This typically happens when the attacker spoofs the IP address and the VPN name of the legitimate user. To remedy this problem, consider using IMAP4 or POP3 for piggyback authentication. Alternatively, you can use certificate authentication for SMTP.

Example 16-79 shows that piggyback authentication is enabled for users who use IMAP4 for e-mail messages.

Example 16-79. Piggyback Authentication for IMAP4

Chicago(config)#

imap4s

Chicago(config-imap4s)#

enable outside

Chicago(config-imap4s)#

authentication piggyback

AAA Authentication

AAA authentication is a way to authenticate the VPN users using either the internal or external database. For AAA authentication, users do not need to have a pre-established WebVPN session. When a user checks e-mail, the e-mail client opens the secured connection to Cisco ASA and presents the VPN user credentials. Cisco ASA checks the configured user database and authenticates the user if credentials are valid. After a successful authentication, Cisco ASA forwards the e-mail user credentials to the e-mail server. If the VPN and e-mail usernames are different, a VPN delimiter is used to differentiate them.

Cisco ASA uses an authentication server to validate user accounts. Example 16-80 shows the AAA authentication configuration for RADIUS users who use POP3 for e-mail. The RADIUS server is defined under tag Rad and is located at 192.168.10.30. This tag is then mapped to the POP3 proxy by using the authentication-server-group Rad command.

Example 16-80. AAA Authentication for POP3

Chicago(config)#

aaa-server Rad protocol radius

Chicago(config-aaa-server-group)#

exit

Chicago(config)#

aaa-server Rad host 192.168.10.30

Chicago(config-aaa-server-host)#

exit

Chicago(config)#

pop3s

Chicago(config-pop3s)#

enable outside

Chicago(config-pop3s)#

authentication aaa


Chicago(config-pop3s)#

authentication-server-group Rad

Certificate Authentication

Certificate authentication requires the e-mail user to present the certificate to the security appliance for validation. If the certificate authentication is unsuccessful , the secured connection is terminated , and the e-mail client fails to connect to the server. This method requires two certificates to be installed on the devices:

• A certificate authority (CA) certificate on Cisco ASA and on the e-mail client

• An identity certificate on the client machine that is signed by a CA and authenticated by Cisco ASA

Example 16-81 shows that certificate authentication is enabled for users who check their e-mail using SMTPS.

Example 16-81. Certificate Authentication for SMTPS

Chicago(config)#

smtps

Chicago(config-smtps)#

enable outside

Chicago(config-smtps)#

authentication certificate

Note

SMTP e-mail proxy allows mailhost authentication for additional security. Mailhost authentication requires the use of username, password, and server information. Cisco ASA does not allow the configuration of mailhost authentication for POP3 and IMAP4, because they always perform mailhost authentication. SMTP e-mail proxy is enabled by configuring authentication mailhost under the SMTP proxy.

Identifying E-Mail Servers for E-Mail Proxies

After you configure the authentication methods, the next step is to identify the e-mail servers to be used for each proxy. To specify an e-mail server, you can use the server command followed by the IP address or the host name of the server. In the configuration in Example 16-82, one email server, called secureme-email, is set up to serve both IMAP and POP3 users. The server is defined under both the IMAP and POP3 configuration menus .

Example 16-82. Configuration of E-Mail Proxy Servers

Chicago(config)#

imap4s

Chicago(config-imap4s)#

enable outside

Chicago(config-imap4s)#

server secureme-email

Chicago(config-imap4s)#

authentication piggyback

Chicago(config-imap4s)#

pop3s

Chicago(config-pop3s)#

enable outside

Chicago(config-pop3s)#

server secureme-email

Chicago(config-pop3s)#

authentication aaa

Delimiters

Cisco ASA can differentiate the WebVPN username from the e-mail username by using specific delimiters for each of the e-mail proxies. There are two types of supported delimiters:

• Username delimiter

• Server delimiter

Username Delimiter

A username delimiter is used to separate out the VPN username from the e-mail username in the username string when configuring the e-mail client. However, this delimiter is necessary only when both usernames are different from each other. The same username delimiter is used to differentiate the user password from the e-mail server password. The username delimiter can be specified by using the name-separator command followed by the actual delimiter. Cisco ASA supports the following valid username delimiters:

• hash (#)

• comma (,)

• colon (:)

• semicolon (;)

• at (@)

• pipe ()

The Cisco ASA configuration in Example 16-83 specifies the use of # for the username delimiter for the IMAP4 and POP3 proxies. The default username delimiter on Cisco ASA is the colon (:).

Example 16-83. Configuration of E-Mail Proxy Username Delimiter

Chicago(config)#

imap4s

Chicago(config-imap4s)#

enable outside

Chicago(config-imap4s)#

server secureme-email

Chicago(config-imap4s)#

name-separator #

Chicago(config-imap4s)#

authentication piggyback

Chicago(config-imap4s)#

pop3s

Chicago(config-pop3s)#

enable outside

Chicago(config-pop3s)#

server secureme-email

Chicago(config-pop3s)#

name-separator #

Chicago(config-pop3s)#

authentication aaa

Note

You cannot have a username delimiter as a valid character in the user password.

Server Delimiter

A server delimiter is used to differentiate the username from the e-mail server name when the username string is entered in the e-mail client. A server name can be either the host name or the IP address of the e-mail server. The server delimiter can be specified by using the server-separator command followed by the actual delimiter. Cisco ASA supports the following valid server delimiters:

• hash (#)

• comma (,)

• colon (:)

• semicolon (;)

• at (@)

• pipe ()

However, the server delimiter must be different from the username delimiter. Example 16-84 demonstrates the Cisco ASA configuration to use as the server delimiter for the IMAP4 and POP3 proxies. The default server delimiter on Cisco ASA is at (@).

Example 16-84. Configuration of E-Mail Proxy Server Delimiter

Chicago(config)#

imap4s

Chicago(config-imap4s)#

enable outside

Chicago(config-imap4s)#

server secureme-email

Chicago(config-imap4s)#

name-separator #

Chicago(config-imap4s)#


server-separator


Chicago(config-imap4s)#

authentication piggyback

Chicago(config-imap4s)#

pop3s

Chicago(config-pop3s)#

enable outside

Chicago(config-pop3s)#

server secureme-email

Chicago(config-pop3s)#

name-separator #

Chicago(config-pop3s)#


server-separator


Chicago(config-pop3s)#

authentication aaa

Tip

The e-mail client must be properly configured for the e-mail proxy feature to work. Consult the following link for an e-mail client sample configuration:

http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2284/products_configuration_guide_chapter09186a00801f1fb6.html

Windows File Sharing

Cisco ASA supports network file sharing using Common Internet File System (CIFS), a file system that uses the original IBM and Microsoft networking protocols. Using CIFS, users can access their file shares located on the file servers, as illustrated in Figure 16-22. Users can download, upload, delete, or rename the files under the shared directories, but only if the file system permissions allow them to perform those actions.

To access the shared resources, users can click the Browse Network link and select the proper domain or workgroup. They can browse to the desired shared resource and take the appropriate actions (read, write, delete, rename filename). They can even create subdirectories, assuming that they are allowed to do so. Alternatively, they can enter the NetBIOS name of the server in the Enter Network Path field to display all the shared resources available for that server, as depicted in Figure 16-23.

The configuration of CIFS requires the use of a NetBIOS Name Server (NBNS), also known as Windows Internet Naming Server (WINS). When a WebVPN user queries to browse the network, the Cisco ASA contacts the WINS server and acquires the list of available domains, workgroups, and workstations. The command syntax to configure an NBNS server is as follows:

nbns-server


ipaddr

[

master

] [

timeout


timeout

] [

retry


retries

]

The nbns-server command can be found under webvpn subconfiguration mode. The ipaddr is the IP address of the NBNS server for CIFS name resolution. The master keyword specifies that the configured NBNS server acts as the master browser in addition to being a WINS server. The timeout value instructs an appliance to wait for the configured number of seconds (default is 2 seconds) before sending another query to the next server. The retry option is used to specify the number of times Cisco ASA has to go through the list of the configured NBNS servers. The default retries is 2, and it ranges from 0 to 10.

Note

You can specify up to three WINS servers in the current version.

The configuration in Example 16-85 sets up Cisco ASA to use three NBNS servers. The first server, 192.168.10.50, acts as a master browser rather than a WINS server. The other two servers, 192.168.10.51 and 192.168.10.52, are the WINS servers. The timeout and retry values are set to their defaults.

Example 16-85. CIFS—NBNS Server Configuration

Chicago(config)#

webvpn

Chicago(config-webvpn)#

nbns-server 192.168.10.50 master timeout 2 retry 2

Chicago(config-webvpn)#

nbns-server 192.168.10.51 timeout 2 retry 2

Chicago(config-webvpn)#

nbns-server 192.168.10.52 timeout 2 retry 2

Cisco ASA does not enable CIFS functionality until the functions parameter is set up to allow file browsing, file access, and file entry. The configuration in Example 16-86 sets up Cisco ASA with a user group-policy named SecureMeWebGrp, which allows users to browse, access, and enter file information using the functions attribute.

Example 16-86. Configuration of User Group Attributes

Chicago(config)#

group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)#

webvpn

Chicago(config-group-webvpn)#

functions file-access file-entry file-browsing

WebVPN Access Lists

Cisco ASA enables network administrators to further their WebVPN security by configuring WebVPN access control lists (ACLs) to manage access to web, file, and e-mail servers. These ACLs affect only the WebVPN traffic and are processed in sequential order until there is a match. If there is an ACL defined but no match, the default behavior on Cisco ASA is to drop the packets. On the other hand, if there is no ACL defined, Cisco ASA allows all traffic to pass through it.

Moreover, this robust WebVPN feature allows these ACLs to be downloaded from a Cisco Secure Access Control Server (CS-ACS) by using the vendor specific attributes (VSAs). This allows central control and management of user access into the corporate network by offloading ACL definitions locally on the security appliance.

Tip

Using CS-ACS Server, a WebVPN ACL can be configured by specifying the webvpn:inacl# prefix in the downloadable ACLs, where # indicates the sequence number of an access control entry (ACE).

The command syntax to create a WebVPN ACL is as follows:

access-list


id


webtype

{

deny


permit

}

url

[

url_string


any

] [

log

[[

disable


default

]

level

][

interval


secs

] [

time_range


name

]]

and

access-list


id


webtype

{

deny


permit

}

tcp

[

host ip_address


ip_address subnet_mask


any

] [

oper port

[

port

]] [

log

[[

disable


default

]

level

] [

interval


secs

]

  [

time_range


name

]]

A URL-based WebVPN ACL is used to filter out WebVPN packets if they contain a URL such as http://. A TCP-based WebVPN ACL is used to filter out WebVPN packets if they use TCP encapsulation based on the IP address and the Layer 4 port number.

Table 16-7 describes all the options available in the WebVPN ACL.

Table 16-7. WebVPN ACL Parameters

Note

If you want to include all URLs that are not explicitly matched in the ACL, you can include an asterisk (*) as a wildcard. The following example shows how to block POP3 e-mail access and allow all other protocols:

access-list blockpop3 webtype deny url pop3://*


access-list blockpop3 webtype permit url any

Chicago(config)#

access-list HTTP webtype deny url http://wwwin.securemeinc.com log


debugging interval 60

Chicago(config)#

access-list HTTP webtype permit url any

Chicago(config)#

group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)#

webvpn

Chicago(config-group-webvpn)#


filter value HTTP

Chicago(config)#

group-policy SecureMeWebGrp attributes

Chicago(config-group-policy)#

webvpn

Chicago(config-group-webvpn)#


functions filter


Chicago(config-group-webvpn)#

filter value HTTP