Applies To:

Show Versions Show Versions

Manual Chapter: FirePass® Controller version 5.5 Administrator Guide: Configuring Portal Access
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>


6

Configuring Portal Access



Introducing Portal Access

Portal Access connections enable end users to use a web browser to access specific services on the internal network. With Portal Access, the FirePass controller communicates with back-end servers, and translates the content into HTML pages for the client browser. The advantage is that the client computer requires no client software other than a browser application.

This method of access differs from connections configured for Network Access and App Tunnels, which provide direct access from the client to the internal network. These technologies do not manipulate or analyze the content being passed between the client and the internal network. These technologies do require small, automatically installed client components, but provide the most seamless direct access to internal applications. Portal Access configuration provides an administrator refined control over the applications that a user can access through the FirePass controller, as well as inspection of contents of transferred data.

For more information on connections configured for Network Access and App Tunnels, see Chapter 5, Configuring Network Access and Chapter 7, Configuring Application Access.

The other advantage of Portal Access is security. Because Network Access and App Tunnel connections communicate directly with the server, client connections must come from a trusted computer. Publicly available workstations do not meet this requirement. However, even though a workstation does not meet those requirements, your users should still be able to access certain applications.

In Portal Access connections, the client computer itself never communicates directly with the end-point application. That means that all communication is inspected at a very high level, and any attacks originating on the client computer fail because the attack cannot navigate through the links that have been rewritten by reverse proxy. In Portal Access connections, the FirePass controller communicates with the back-end servers, and then generates the HTML page for presentation in the browser window.

Introducing Portal Access features and operation

Portal Access provides remote users with web-based remote access to a wide variety of network applications and resources, including:

  • Intranet web servers
  • Email servers
  • Windows file servers
  • Terminal servers
  • Legacy, character-based applications.

Portal Access serves the internal resource into and out of the end user's web browser. The application being accessed and the protocol being supported (HTTP and HTTPS) dictate how Portal Access operates. Figure 6.1, following, shows the process that Portal Access follows.

Figure 6.1 The Portal Access functionality of the FirePass controller

Introducing Portal Access application support

You can use Portal Access when users need access but they are away from their regular computers. FirePass provides additional functionality to secure connections from client machines, such as public kiosks or PDAs, which might not have the necessary applications installed or configured, but usually do have browsers installed. In this case, the web browser serves as the interface to the application.

You can set up different types of access for users in different master groups. For example, you can enable Windows Files access to users from one master group, and prevent access by users in another master group. In addition, you can enable browsing of internal web sites by name or IP address, which would be typical for employees, or limit access only to specified favorites, which would be useful in an extranet for partners and customers.

Using Web Applications

Web Applications access allows remote users secure access to internal web servers, such as Outlook Web Access (OWA), Microsoft SharePoint, IBM Domino Web Access (also known as Lotus iNotes), Domino Sametime, and Citrix NFuse. Using Web Application functionality, you can also provide access to most web-based applications and internal web servers. Portal Access provides access to web applications by performing an intelligent proxy of the content through the FirePass controller, so it changes all links to reference the FirePass controller address, rather than the originating server. The high performance, full-content rewrite engine also supports rewriting complex JavaScript™, Java™ applets, and Flash® content. You can use features such as the web cache, minimal content rewriting bypass mode, user-defined content processing scripts, and a number of others, to help refine compatibility and tune performance.

Using Windows Files

Windows Files access allows remote users browser-based access to browse, upload, download, move, copy, or delete files in shared directories. The FirePass controller communicates with file servers using the Server Message Block (SMB) protocol, which can support Windows 2003, Windows 2000, Windows for Workgroups, Windows NT 4.0, Linux, and Novell 5.1/6.0 with the Network File System (NFS) feature.

Using Mobile E-Mail

Mobile E-Mail access provides very lightweight access to POP/IMAP and SMTP email servers and LDAP address books using a standard web browser, or mini browsers on a PDA or smart phone. Users can send and receive messages, download attachments, and attach files from the internal LAN to send email messages. Mobile E-Mail is intended to complement a fat client by optimizing content for low bandwidth, mobile devices.

Using Content Inspection

Content Inspection scans URL arguments and POST data sent by users through Web Applications, and blocks the request if it appears as if it might be an attack. Content Inspection guards against cross-site scripting attacks, SQL injection attacks, buffer overflow attacks, and viruses from files uploaded using Windows Files, Web Applications, or Mobile E-mail.

Configuring web applications on the FirePass controller

You can configure the FirePass controller to provide access to web applications without requiring client configuration changes or software downloads. Typically, you use Portal Access when your users only require access to specific internal web portal-based applications, and do not require full Network Access. The FirePass controller provides security by rewriting links in all requests to internal servers. When the FirePass controller processes the connections, it uses the proxy engine's built-in logic and additional custom-configurable content-processing scripts to modify the URLs and other links in the original HTML document. The controller changes these links by rewriting the path to the URL. You can use stream editor (SED) scripts to modify intranet web pages to handle issues related to the FirePass controller sending custom content through the proxy engine.

F5 Networks has tested the following web applications to ensure that the FirePass controller handles them without client reconfiguration.

  • Microsoft Outlook Web Access (OWA)
  • Microsoft SharePoint
  • IBM Lotus Domino Web Access (also known as Lotus iNotes)
  • Domino Sametime
  • Microsoft file servers configured for Common Internet File System (CIFS), the remote file system that uses the SMB protocol.

Some of your custom web applications will work with Portal Access without you having to make changes to the applications. However, some of your web applications, particularly those that make extensive use of JavaScript, Java applets, ActiveX controls, and Flash components, might require that you use content processing scripts or other configuration changes to enable the user to access them using Portal Access connections.

If you have a specific web application that requires additional configuration to work through Portal Access, you can generally use Application Tunnels or Network Access. These access methods provide a direct connection to the internal network, and do not require proxy-based changes or modification of web application content.

If you cannot use Application Tunnels or Network Access to solve access issues, you can try the proxy feature Minimal Content-Rewriting Bypass. For more information about this feature, see Configuring web applications for minimal rewriting.

Understanding proxy and cache functionality

You can use the FirePass controller Portal Access : Web Applications feature for the following operations:

  • Rewrite of complex HTML, JavaScript, Java applets, and Flash content
  • Dynamic cache of rewritten content
  • Extensive bypass configuration and content pre-processing and post-processing using scripts

The FirePass controller uses a high-performance, full-content rewrite engine to handle complex HTML, JavaScript, Java applets, and Flash. You can also enable a built in dynamic cache, so that the FirePass controller does not have to repeatedly rewrite content for static objects such as HTML, JavaScript, style sheets, and Java applets. Also, the web applications engine supports rewrite of complex applets such as Citrix, VNC (when presented by Java applets), as well as .jar and .cab archive resigning.

In some cases you might want to bypass the FirePass controller's reverse proxy to support some very complex web applications using the Minimal Content-Rewriting Bypass feature. To use this feature, your applications must reside on the single target server. When you use the bypass feature, the proxy engine operates differently.

With the bypass feature, the proxy engine:

  • Uses the FirePass controller name to replace only the originating host name in the address. If the URL also contains a port, then the proxy engine replaces the host name and port with the FirePass controller name and port.
  • Does not rewrite URL references to other servers
  • Does not modify cookies, when you enable the global setting, cookie pass through.
  • Applies minimal content settings at the master group level

You can use the bypass feature by configuring a one-to-one mapping between one of the following options:

  • A URL pattern and an internal intranet host
  • A dedicated FirePass Web service on an alternate port or IP address, and an internal host

You can use SED scripts to rewrite output instead of preventing rewriting by configuring bypass. For information about Web application content processing using SED scripts, see Configuring content processing for web applications.

Setting cookie availability for web bypass

In some cases, for example, if your web application manipulates a client cookie, you want the FirePass controller to pass the cookie to the browser without altering it.

To specify cookie pass through

  1. In the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and click the Global Settings tab.
    The Content Processing : Global Settings screen opens.
  2. Scroll down to the Web Applications Global Settings section.
  3. Check the Do not block cookies at FirePass, pass them to the browser for specified URL patterns check box.
  4. In the box, specify the list of URLs or URL patterns you want the FirePass controller to ignore when performing proxy operations.
  5. To have the FirePass controller add URLs from sites that require cookie manipulation, check the Automatically add websites that require client side cookie manipulation check box.
  6. Click Update.

Defining favorites for Portal Access Web Applications access

To make Portal Access Web Applications available to users, you create favorites to internal web sites and URLs. A favorite is a collection of settings that represents a single link on the user's webtop. When the user clicks a Portal Access Web Application favorite, the FirePass controller opens the connection and runs the configured application.

Understanding Portal Access favorites options

You add new favorites using the Portal Access : Resources screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, and click Resources. When you click the Add new favorite, link, the screen reveals additional options.

  • Type
    Indicates whether the link is a new configuration (Favorite) or a pointer to an existing one in another master group (Alias). Alias is available as an option only when there are Portal Access favorites configured in another resource group.
  • Name
    Contains the name for the intranet site that you are defining as a favorite. This is the name the user sees on the webtop. The string you specify can be any name; field format is not limited. For example:
    Site Request application
  • Web Application Type
    Specifies web servers as generic, Microsoft Outlook Web Access (OWA) or IBM iNotes. For OWA and iNotes, Portal Access automatically selects the optimal caching and compression settings.
  • URL
    Indicates the intranet web server that serves the application. For example:
    http://server.siterequest.com/index.html
  • URL variables
    Contains variables to be either appended to the GET request or sent as data in a POST request to the specified URL. For more information and examples, see Working with URL variables, following.
  • Post URL variables
    Indicates that you want the variables in URL variables to be included in the POST request to the URL specified. For more information and examples, see Working with URL variables, following.
  • Enforce user-agent
    Contains the string you want the FirePass controller to send to the internal web server instead of the browser's actual user-agent identifier. For more information, see Specifying user-agent strings.
  • Open in new window
    Indicates whether the application opens in the existing browser window or in a new browser window.
    Check this option to open the application in a new window, or leave the option cleared to have the application replace the user's webtop.
  • Endpoint protection required
    Provides a list of Protected Configurations defined on the Users : Endpoint Security : Protected Configurations screen. If the user's endpoint protection does not satisfy the defined condition, the FirePass controller does not include this favorite on the webtop or allow access. For more information about protected configurations, see Creating protected configurations, on page 3-21.

Once you have configured all of the necessary parameters for your application, click the Add New button to add the favorite. When you have configured at least one favorite, you can choose which link serves as the default by selecting it from the Default box, and clicking Update.

The default favorite starts automatically when users of the resource group open their web application favorites. With more than one default favorite defined, for example, when a user has multiple resource groups assigned, the FirePass controller starts only one of the defaults.

Working with URL variables

Although they are optional, you can use URL variables to support favorites, such as automatic user logon to intranet web sites, or for customizing intranet content for a user. You can use the %username% and %password% variables as values in a GET request. At logon time, the FirePass controller replaces the parameters with the user's FirePass controller user name and password.

URL variables are specified in the form:

variable1=value1&variable2=value2&variable3=value3

The following is an example of how to build an intranet favorite that contains a URL variable. First you specify the string in the URL box:

http://server.siterequest.com/index.html

Then you specify the variables you want to use in the Url variables box:

show_custom_content=1&user=%username%&password=%password%

For FirePass controller user johndoe with password johndoepassword, using these variables results in the following actual favorite link:

http://server.siterequest.com/index.html?show_custom_content=1& user=johndoe&password=johndoepassword

Alternately, you can specify that the FirePass controller send the variables in a POST request to the configured URL. This is a more secure way to provide a user name and password for logging on to an intranet site, because the variables are not visible on the URL line of the browser for someone to see.

For example, if you have the following form contents on an intranet logon page:

 

<form action=logon.php method=POST>

<input type=TEXT name=user>

<input type=PASSWORD name=password>

<input type=HIDDEN name=do_logon value=1>

<input type=SUBMIT value=Logon>

</form>

First, you specify the string in the URL box:

http://server.siterequest.com/logon.php

Then you specify the variables you want to use in the Url variables box:

user=%username%&password=%password%&do_logon=1

For FirePass controller user johndoe with password johndoepassword, using these variables results in the following actual favorite link:

http://server.siterequest.com/logon.php

The FirePass controller sends the following data directly to the server.siterequest.com site in a POST request:

user=johndoe&password=johndoepassword&do_logon=1

Specifying user-agent strings

The user-agent string identifies what the client's web browser uses with a specific network protocol. Some servers use the user-agent string to determine what content to send to the client browser. Although optional, specifying a user-agent string is useful when you need to simplify FirePass controller content. For example, for a highly complex web application, it might help to downgrade the content supplied by specifying the following user-agent string:

Mozilla/4.7 [en] (Windows NT 4.0; U)

Table 6.1, following, contains a list of common user-agent strings.

Table 6.1 User-agent strings for several browsers
Browser
User-agent string
IE 6.0 on Windows
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
IE 5.5 on Windows
Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
IE 5.0 on Windows
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
IE 4.5 on Windows
Mozilla/4.0 (compatible; MSIE 4.5; Windows NT)
IE 4.01 on Windows
Mozilla/4.0 (compatible; MSIE 4.01; Windows NT)
Mozilla 1.7.8 on Windows
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
Netscape 7.2 on Windows
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
Netscape 4.5 on UNIX
Mozilla/4.5 [en] (Win98; U)
Netscape 3.04 on UNIX
Mozilla/3.04Gold (Win95; U)
Opera 5 on UNIX
Opera/5.12 (Windows 2000; U) [en]
Opera 5 mimicking Netscape on Windows
Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) Opera 5.01 [en]
Safari 2.0 for Macintosh OS X
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412 (KHTML, like Gecko) Safari/412
FireFox 1.0.4 on the Macintosh
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
FireFox 1.0.6 on Windows
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
FireFox 1.0.1 on Linux
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.7.6) Gecko/20050222 Firefox/1.0.1

Tip


An easy way to enter a user-agent string is to copy and paste the string from the Logons report into the Enforce user-agent box. You can find the string on the Reports : Logons screen in the User Agent column.

Configuring web applications for minimal rewriting

You can use the minimal content rewriting feature to prevent rewriting of your web application content. You can define minimal content rewriting operation on the WebApplications : Master Group Settings screen.

There are several configuration requirements for using the Minimal Content-Rewriting Bypass feature:

  • The application must reside on a single server. The FirePass controller cannot process URLs for separate servers when the Minimal Content-Rewriting Bypass feature is enabled.
  • You must configure cookie pass-through on FirePass controller in order to use the Minimal Content-Rewriting Bypass feature if there is client-side JavaScript that directly processes cookies.
  • You cannot use automatic cookie pass-through with Minimal Content-Rewriting Bypass.

You can configure the Minimal Content-Rewriting Bypass feature in only one of two modes:

  • Pattern-based
    Provides a pattern-matching mechanism for URLs. You specify a protocol, host, and path for the FirePass controller to match. If the FirePass controller encounters a URL that has a defined Pattern-based bypass rule, the FirePass controller does not modify URLs on the returned page.
  • Implementing the Pattern-based bypass mode requires no network changes, but you must specify the protocol, host, and path that the application uses so that the FirePass controller can match the incoming URLs.

  • Alternative Host/Port-based
    Provides a dedicated IP address and TCP port through which the FirePass controller proxies connections to the application server. When configuring the FirePass controller in Alternative Host/Port-based mode, you must configure one FirePass controller port for each port the application server uses. If your application uses SSL encryption, you must also install on the FirePass controller the same SSL certificate and private key that is installed on the application server.
Important

When you configure bypass, make sure to clear the box that enables compatibility mode on the Global Settings screen. Minimal content rewriting does not work in compatibility mode. To access the Global Settings screen, in the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and click the Global Settings tab. The option is Compatibility mode (enable legacy version of Web Applications handler), and is provided to support web applications configured using earlier versions (pre-5.4) of the FirePass controller reverse proxy engine.
Note

The Minimal Content-Rewriting Bypass feature is available only if you have the hotfix for FirePass 5.4.2, or if you are using FirePass 5.5.

Configuring pattern-based bypass

Instead of having the FirePass controller reverse proxy rewrite URLs and JavaScript, you can use the pattern-based bypass option. The pattern-based bypass functionality replaces the target server name with a name you specify, and processes requests based on the patterns you list. The pattern searches are case-sensitive, so you might have to specify the same pattern in upper- and lowercase. Patterns must be unique within the intranet to prevent interference with other web applications.

When you use this feature, the FirePass controller replaces all references to the target server's protocol://address:port with the FirePass protocol://address:port. For example, if a Web application consists of URLs starting with /myapp/ and /myimages/, you would associate the patterns /myapp/*,/myimages/* with the server. You must specify the target server in the following form:

protocol://servername[:optional port]

An example target server is http://myserver

Important

The root directory of the server cannot be used as the pattern for the pattern-based bypass mode, for example, you cannot specify http://, /, or /*.

You can find pattern-based bypass settings on the Master Group Settings screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, and click Master Group Settings.

When you configure settings, first select from Master Group the master group you want to have access to the application.

In the Minimal Content-Rewriting Bypass section, you can configure the following options:

  • Comma separated list of patterns
    Contains a list of match patterns for the web application. In this box, specify the application paths that you do not want the FirePass controller to translate. Separate each directory with a comma.
  • For example, if you do not want FirePass to translate a set of URLs, including all pages in the location:

    https://tech.siterequest.com/appdir1/ https://tech.siterequest.com/appdir2/ https://tech.siterequest.com/appdir3/text.html

    Type the following text:

    /appdir1/*,/appdir2/*,/appdir3/text.html
  • http[s]://<IP Address/Name>[:Port]
    Contains the target server. In this box, specify the protocol and host portion of the URL for the application.
  • For example, if you do not want FirePass to translate the URL:

    https://tech.siterequest.com/appdir1/

    Type the following text:

    https://tech.siterequest.com

You can specify a pattern using the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. The patterns must be unique. When you specify a pattern, you must include at least one subdirectory for each application.

Configuring the Alternative Host/Port-based type of bypass

The first step to configuring the Alternative Host/Port-based bypass type of minimal content rewriting is to create a web service and enable WebAccess Bypass. For information about creating web services, see Configuring web services, on page 8-17 . When you create the web service, if you want to use the Alternative Host/Port-based bypass type of minimal content rewriting, you check the WebAccess Bypass check box to indicate that the FirePass controller uses the web service only for proxy pass-through operations. For more information, see the following procedure.

Next, you configure alternative host/port-based minimal content-rewriting. For more information, see Configuring web applications for minimal rewriting .

To enable WebAccess Bypass

  1. In the navigation pane, click Device Management, expand Configuration, click Network Configuration, and then click the Web Services tab.
    The Web Server Configuration screen opens.
  2. From IP, select an available IP address to which users will connect or create a new address using the IP Config tab.
  3. Specify a port that is not already in use by another FirePass controller web service.
  4. Specify a host name.
    If you add the host name to your DNS server, users can connect to the application using the name of the host instead of having to use the IP address.
  5. Check the Enable SSL check box.
  6. Click Add New.
    The Web Service Configuration page opens.
  7. From the Certificate list, select a certificate to use with the new web service.
  8. Check the WebAccess Bypass box.
  9. Note: When you check the WebAccess Bypass check box, the FirePass controller disables the user logon and administrator logon to that service.
  10. Click the Update button.
  11. Click the Finalize tab.
  12. Click the Finalize Changes button.
  13. Wait while the finalize process completes.
  14. If necessary, restart services.
  15. In the navigation pane, click Portal Access, expand Web Applications, and click Master Group Settings, to configure Alternative Host/Port-based bypass options. For more information, see Configuring Alternative Host/Port-based bypass , following.
Note

Depending on how your firewall is configured, if you specify a new port, you might need to configure your firewall to allow communication on that port. You might need to specify a new port if you have one internal side that allows traffic through, or if you use servers outside the company on another network (also known as one-armed configuration).

Configuring Alternative Host/Port-based bypass

When you use the Alternative Host/Port-based bypass feature, the FirePass controller uses the proxy engine to make connections to the application server through specified IP address and port combinations, and replaces a specific internal host name with the name and port number you specify.

The Alternative Host/Port-based section on the Master Group Settings screen contains a list of the web services with a checked WebAccess Bypass option. The Alternative Host/Port-based section is empty if you have not checked WebAccess Bypass for at least one existing web service. In this case, the section contains a message, No Bypass Web Services configured, along with a Click here to configure link that opens the Device Management : Configuration : Network Configuration screen. From there, you can add a new web service or configure an existing one by checking Web Access Bypass on the associated Web Service Configuration screen.

For a procedure of how to configure a web service for minimal-rewriting bypass functionality, see Configuring web applications for minimal rewriting .

In the box under Alternative Host/Port-based, type the URL for your application, using the following format (where [ ] indicate optional values):

http[s]://<IP Address/Name>[:Port]

When you finish, make sure to click the Update button to have your settings take effect.

Configuring NTLM and basic authentication proxy

NTLM uses a challenge-response mechanism for authentication, in which clients prove their identities without sending the server a password. The mechanism consists of three messages: Type 1, negotiation; Type 2, challenge; and Type 3, authentication. Although Windows 2000 continues to support the protocol, Microsoft Kerberos has replaced it as the standard.

You can enable NTLM and basic authentication proxy on the Master Group Settings screen. To access the screen, click Portal Access, expand Web Applications, and click Master Group Settings. The FirePass controller supports sending through the proxy engine NTLM and basic authentication over HTTP on behalf of the user, which provides several benefits:

  • Prevents client browsers from caching basic or NTLM authentication credentials.
  • Allows client browsers not supporting basic or NTLM authentication to authenticate against web sites requiring this, such as Microsoft Internet Information Services (IIS).
  • Allows automatic logon (single sign-on) to sites supporting basic or NTLM authentication with user's FirePass credentials.

There is a security implication to running the FirePass controller without checking the Proxy Basic and NTLM auth using FirePass user login form check box. The implication is that, depending on the application, after logging off of an internal application configured for basic or NTLM authentication, users might be able to regain access to the internal application without entering logon information. This is because web browsers commonly cache basic or NTLM user credentials.

When you configure the FirePass controller to send basic or NTLM user credentials through the proxy engine, the controller replaces the basic or NTLM browser dialog box with a form-based dialog box, which prevents the web browser from caching user credentials.

NTLM and Basic Auth Proxy provides the following options:

  • Proxy Basic and NTLM auth using FirePass user login form
    Indicates whether to use the FirePass controller to proxy HTTP basic and NTLM authentication. If you enable this option, the FirePass controller presents a user logon web form whenever a protected site needs logon credentials. Basic and NTLM authentication proxying is enabled by default.
  • Auto-login to Basic and NTLM protected sites using FirePass user credentials
    Controls whether the FirePass controller can pass along the user's FirePass controller logon credentials to automatically log on to protected sites on the user's behalf. If the user's FirePass controller credentials do not match those required for the protected site and you enabled Proxy Basic and NTLM auth using FirePass user login form, the FirePass controller presents a user logon web form. Otherwise, the FirePass controller presents an authentication dialog box. When you enable this option, you can also configure the following options:
    • NTLM Auth Domain (optional)
      For protected sites requiring NTLM authentication, you can specify a default domain to be used in conjunction with the auto-logon support.
    • Basic Auth Domain (optional)
      For protected sites requiring basic authentication, you can specify a default domain to be used in conjunction with the auto-logon support. When specified, this value is prepended to the user name during basic authentication (for example: BASICDOMAIN\username).

Configuring split tunneling for Portal Access

You can define Portal Access split tunneling functionality on the Master Group Settings screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, and click Master Group Settings. You can use the split tunneling feature to specify which URLs should be processed by the FirePass controller proxy engine and which URLs should not. Split tunneling functionality helps:

  • Improve controller performance by lowering processing overhead
  • Make some web pages available (such as the performance-impacting pages served by many public portal sites) that might not be compatible with reverse-proxy technology

When you check Use URL patterns for split tunneling, the screen reveals additional options.

  • Rewrite
    Contains a comma-separated list of patterns to compare with incoming URLs. The FirePass controller proxies matching URLs. If the box is empty, the FirePass controller rewrites all URLs. You can type an asterisk ( * ) to specify that the FirePass controller rewrite all URLs.
  • Bypass
    Contains a comma-separated list of patterns to compare with incoming URLs. URLs that match are accessed directly, bypassing the FirePass controller reverse-proxy engine. If the box is empty, all URLs bypass the reverse-proxy engine, meaning that rewriting is done for all URLs that pass the test specified by patterns in the Rewrite box.

You can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character, in both the Rewrite and Bypass boxes. The FirePass controller first processes all patterns in the Rewrite box, and then all patterns in the Bypass box.

Example: http://*.siterequest.com/*

The split tunneling filters apply to favorites, to direct browsing, and to the links within a rewritten page. If you enable split tunneling, the FirePass controller presents only web pages that satisfy one of these filters. It blocks the others (although a blocked public site might still be available outside the webtop). If you do not use split tunneling, the FirePass controller processes all URLs through the reverse-proxy engine.

Split tunneling patterns ignore any part of the URL after the first pound sign ( # ) or question mark ( ? ) symbol; that is, anchors and URL variables are ignored.

Note

The Network Access feature also provides split-tunneling functionality. The functionality is slightly different, however. For more information, see Introducing Network Access, on page 5-1 .

Configuring accessibility scope

Even if you limit access to the intranet to favorites only, some links might contain links to other servers. You can define Portal Access Accessibility Scope functionality on the Master Group Settings screen. To prevent this, you can limit access, making available only particular web servers and pages. Specifying accessibility scope provides fine control over which URLs the FirePass controller allows the user to access. When you check Restrict resources accessible via Web Applications, the following options appear:

  • Allow
    Contains a comma-separated list of patterns to compare with incoming URL requests. The FirePass controller allows access to matching URLs. If the box is empty, the FirePass controller allows access to all URLs.
  • Deny
    Contains a comma-separated list of patterns to compare with incoming URLs. URLs that match are not allowed access. If the box is empty, the FirePass controller allows access to all URLs that pass the test specified by patterns in the Allow box.

You can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character, in both the Allow and Deny boxes. Each URL filter must specify a complete protocol and path. The FirePass controller first processes all patterns in the Allow box. If there is no match, the FirePass controller rejects the URL. If there is a match, that URL is then checked against the Deny filters. If there is a match, the URL is rejected, otherwise, it is accepted.

For example, the following specifies two URLs containing wildcards:

http://www.*.com/*.html,http://www.*.com/*.php

Note

A trailing slash ( / ) is often required in a URL filter since this is typically appended by the browser.

For example, you might have to specify: http://server.siterequest.com/ instead of http://server.siterequest.com for the filter to work.

Preserving host names

You can define which host names to preserve on the Master Group Settings screen. You might want to prevent the replacing of host names with the FirePass controller name if you want to provide access to a web application that uses the host name for a specific purpose. For example, preserving the host name is useful for web applications that have JavaScript code that sets a cookie based on the actual server name in the browser.

To access the Master Group Settings screen, click Portal Access, expand Web Applications, and click Master Group Settings.

When you check Preserve FirePass hostname when accessing Web Applications, the screen reveals a box. Into the box you can specify a comma-separated list of patterns to match against URLs. You can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character, in the box. This option instructs the reverse-proxy engine not to replace Host in the HTTP headers.

If the box is empty, the FirePass controller replaces the host name on all URLs. For example, using the typical reverse-proxy operation, the Host value gets replaced, as shown in the following example:

Host: firepass.siterequest.com
(client to FirePass controller)

Host: company_server.siterequest.com
(FirePass controller to internal web application)

When you check the Preserve FirePass hostname when accessing Web Applications check box, the FirePass controller delivers the Host header to the internal web application without alteration, as Host: firepass.siterequest.com.

Configuring content processing for web applications

You can define Portal Access content processing functionality on the Content Processing screen. To access the screen, click Portal Access, expand Web Applications, and click Content Processing.

When sending connections through the proxy engine, the FirePass controller uses an advanced, full-content rewrite engine to modify the URLs and other links in the original HTML document. The modified path begins with f5-w-. For example, The FirePass controller rewrite engine converts the link shown in the following example to the string shown in the following result.

<a href='http://siterequest.com/...'>

<a href='https://firepass.siterequest.com/ f5-w-X8d676sba8c650337ebf0937652fd678ac8a7663628f8a7d9449c9/. '>

If a web site has very complex or poorly written code, it is possible that some links will not be re-written, or will be re-written incorrectly. Additionally, the FirePass controller may not always be able to fully parse and patch advanced JavaScript code, which could result in improper display and loss of functionality.

You can apply the content-processing features to address these conflicts.

Locating proxy conflicts

You can find the source of the problem by comparing a connection made directly between a client and the web application to a connection made through the FirePass controller.

The following tools are helpful in making this comparison:

Configuring processing scripts for content processing

You can use the Preprocessing Scripts screen for modifying web pages as they pass through the reverse proxy. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and then click the Preprocessing Scripts tab.

The FirePass controller can perform special-purpose processing of content passing through Web Applications, using SED-based scripts. You can create specialized SED scripts that modify intranet web pages to address issues related to the proxying of unusual or incorrectly formatted content.

Adding a SED script

You can use SED scripts to modify intranet web pages to handle issues related to proxying unusual or incorrectly formatted content. Here, you can specify a URL pattern and an accompanying SED script for processing content passing through Web Applications. You can specify a single URL match pattern list for each processing type. For example, you can specify response preprocessing, processing that occurs before patching; response postprocessing, processing that occurs after patching; or request processing, processing requests from a user before the FirePass controller sends it to the web site.

The FirePass controller processes URL content using the first match it finds in the list of defined entries (starting at the top of the list).

The first step in configuring content processing by adding a SED script is to create a favorite.

To add a favorite that uses a SED script

  1. In the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and then click the Preprocessing Scripts tab.
    The Preprocessing Scripts screen opens.
  2. Click the Add New Favorite link.
    The screen refreshes to reveal new options.
  3. In Processing script name, type the name of the favorite.
    This can be any string that can help you identify the specified content processing functionality.
  4. In URL match patterns, specify a comma-separated list of patterns to compare with incoming URLs. The FirePass controller processes matching URLs using the specified script.
    If the box is empty, the FirePass controller does not process content from any URL. You can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character, to specify the patterns, for example, http://*.siterequest.com/*
  5. In Content Type, specify the content-type HTTP header that the FirePass controller should process with the script.
    An empty field means that the FirePass controller processes text/* content types, for example, text/plain, text/html, and so on. For SED script processing, you can specify additional types, for example, application/xhtml+xml that the FirePass controller should process using the specified SED script. If a page to be matched does not have a defined Content Type, you can specify application/unknown.
  6. In Sed processing script, specify the SED script the FirePass controller should use for processing the web application request or response data.
    For example, if you specify s|HTTP://|http://|g the FirePass controller performs a global search for HTTP://, and replaces each instance it finds with a http:// string.
  7. You can use much more complex scripts, and include regular expressions, to search for and replace or modify content, and to correct HTML errors on pages.

    You can use the FP_ServiceAddr variable inside SED scripts. Processing replaces this variable with the FirePass controller name. You can also use content processing scripts to insert <FP_DO_NOT_TOUCH> and </FP_DO_NOT_TOUCH> tags around sections of code on pages that you do not want the rewrite engine to rewrite.

    Note: In certain cases, you must use the backslash character to escape forward slash characters in the SED script.
  8. From the Processing list, select where to apply the content processing script. You can apply the SED script to the user request or to the server response. If you choose the response, you can apply the script before or after the reverse proxy engine performs content patching. Options are:
    • Pre-process response data (before content patching): Applies the SED script to response data received from a web site before the content is patched by the reverse proxy engine. In most cases, you should select this default option of Pre-process response data (before content patching).
    • Post-process response data (after content patching): Applies the SED script on response data after the content is patched by web applications.
    • Process request data: Processes request data from a user before it is sent to the web site.
  9. Click the Add New button.

You can find more information about using SED scripts on the AskF5 web site by searching FirePass-controller-related Solutions.

Example 1 of using a SED script

In this example, we use a script to replace an applet. The problem the script is solving is that a page with a video streaming applet does not work as expected through Portal Access Web Applications.

The administrator used the tcpdump command to determine that the problem is that the applet does not rely on URLConnection for streaming, that instead, it uses sockets.

Note

The FirePass controller patches Java applets (when the option is enabled), even those that use sockets, so this example is for illustrative purposes only.

In this case, the administrator developed a SED-based content processing script to replace the applet with an image, using a different CGI for displaying still images, along with a piece of JavaScript to reload the image automatically. You can find the script in the section SED content processing script for example 1 , following.

In the source for the web application, HTML comments take the applet out of the context. Then, the script injects an image named noapplet following the </APPLET> tag, and provides the onload callback im_loaded. The script injects the im_loaded implementation preceding the </HEAD> tag, reloads the image immediately after the implementation loads, and adds a time-based query parameter to ensure that the browser does not cache the image.

The result is that the location that previously contained the non-working applet now shows a static image.

SED content processing script for example 1

This shows a SED script that performs content processing on a page that contains a video streaming applet that does not work in web applications.

s@</HEAD>@ <script>function im_loaded(){d = newDate;document.images['notapplet'].
src="/axis-cgi/jpg/image.cgi
?="+d.getMilliseconds();}</script></HEAD>@

s@<APPLET@<!--<APPLET@s@/APPLET>@/APPLET>--><img onload = 'im_loaded()'name=notapplet src='/axis-cgi/jpg/image.cgi' width='320'height='240'>@

Example 2 of using a SED script

In this example, we describe how to prevent the rewriting of certain URLs by the reverse-proxy engine. The problem the script is solving is that an intranet application dealing with XML data or XSL style sheets does not work properly.

The FirePass controller attempts to determine which links on HTML pages it should rewrite. However, the reverse proxy engine might not always correctly analyze XML or XSL data and pages that make extensive use of JavaScript. If you determine through analysis that proper operation requires the preservation of some links that are being rewritten, you can use a SED script to return content to its original condition.

The result is that the URLs that were previously rewritten are now returned to a usable state.

SED content processing script for example 2

The following section contains a SED script that performs content processing on a page that contains XML or XSL content that does not work in web applications.

To search for certain types of pages, you can specify a match pattern in URL match pattern, for example */pathnet/XSLTS/* Then in the SED processing script box, you can use a SED script such as s|/f5-w-[^/]*|//|g

In this case, the FirePass controller should process content after performing its patching, so from the Processing list on the Preprocessing Scripts screen, select Post-process response.

This script removes the f5-w- information that reverse proxy adds. In general, the page will work correctly after postprocessing, as long as the links on the page are to the same host (or are relative links).

Example 3 of using a SED script

You can also specify a slightly more complex SED script than the one described in Example 2 of using a SED script to remove rewriting from one particular link on a page, or to a more selective set of links. The following script requires a link containing /eerequest/ on the page to remove the f5-w- references.

/eerequest/ {

s|/f5-w-[^/]*|//|g

}

For more information, see the SED man page.

Testing content processing settings

You can test the content of a processed web page under Test Content Processing Settings on the Preprocessing Scripts screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and then click the Preprocessing Scripts tab.

Once you apply the SED scripts you want, you can use this functionality to preview a page's content as it would be delivered from the FirePass controller. To test content, in the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and click the Preprocessing Scripts tab.

When you specify a URL in the box and click the Test button in the Test Content Processing Settings section, the FirePass controller fetches and displays the HTML source that the FirePass controller delivers for the configured URL. When the processing testing mechanism finds and displays the page represented by the URL, the content also reflects any script processing and content cleaning results. You can also click a link, View processed page through Web Applications, to view how the page looks when presented to the end user.

If the page is a valid URL, the results box, labeled Original URL source, contains the page source. If the URL is not valid, the testing functionality returns the message Invalid URL entered or Error fetching URL source. You may also get the Error fetching URL source if the URL you are trying to fetch requires authentication. If that happens, you can specify the authentication you need by viewing the page and then trying the test again.

Troubleshooting web application failures

While there are a number of reasons that SED processing might fail on an application accessed through the FirePass controller, the most common reason is that a JavaScript tested the page's content and either the test failed, or the content did not match the script's expectations. If the content fails the JavaScript test, errors might be reported or the application could refuse to allow further operations.

Some common JavaScript tests perform the following functions:

  • Check the protocol of the URL to make sure it is http://
  • Check the URL to make sure its host name matches the server name sent in the JavaScript
  • Perform a checksum on the page and make sure it matches the original

JavaScript tests frequently fail when the site is accessed through the FirePass controller, because the FirePass controller modifies URLs to use the HTTPS protocol and to contain the host name of the FirePass controller.

You can use one of the following solutions to work around this issue:

  • Modify the application so that the tests allow for the changes made by the FirePass controller.
  • Use a content processing script to modify or remove the JavaScript test.
Note

You can use the Minimal Content Rewriting Bypass feature to avoid the full content rewrite typically needed with Web Applications. Configuring this feature helps deal with complex portal and web application content. For more information, see Configuring the Alternative Host/Port-based type of bypass .

Cleaning web application content

You can have the FirePass controller use the HTML Tidy open-source parser to reformat HTML content passing through Web Applications prior to content patching. This may be necessary for some sites to deal with proxying specially formatted HTML content.

Note

Content cleaning is a very processor-intensive operation. We recommend not enabling this feature except for debugging purposes, to help with troubleshooting content-rewrite issues.

You can specify a list of URLs under Web Applications Content Cleaning on the Preprocessing Scripts screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and then click the Preprocessing Scripts tab.

In the box under Web Applications Content Cleaning, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character, to specify URLs that you want the FirePass controller to process for content cleaning. An empty list means that the FirePass controller does not reformat content from any URL.

Note

The content-cleaning function cannot fix severe coding or content errors.

Configuring global settings for content processing

The FirePass controller rewrites URLs, JavaScript, and Java applets on all Portal Access web pages to resolve internal to external URLs.

You can use options on the Global Settings screen for changing the FirePass controller behavior for processing web pages as they pass through the Portal Access reverse-proxy engine.

Note

Configuration for most global settings requires a service restart.

To access the Global Settings screen, in the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and then click the Global Settings tab.

Configuring enforce-user-agent strings on a per-host basis

The FirePass controller can present a specified User-Agent string to a particular web site instead of the actual browser's User-Agent. An alternative User-Agent string is useful in downgrading content if content patching errors are occurring.

You can also specify a per-host, user-agent string to use with content processing on the Global Settings screen. To access the screen, click Portal Access, expand Web Applications, click Content Processing, and click the Global Settings tab. This feature provides the following options:

  • Intranet Host
    Contains the URL for the intranet server that communicates with the FirePass controller. For example,
    server.siterequest.com.
  • Alternative User-Agent String
    Contains the string the configured intranet host sends to the FirePass controller. The specified user-agent string causes the intranet host to impersonate the specified browser by sending the associated user-agent string.
  • List of browsers
    Contains a list of the common browsers. Selecting a browser from this list populates the associated user-agent-string box, which you can modify, if you wish.

For more information about user-agent strings, see Specifying user-agent strings .

Preventing session update

Some web applications pages loaded through Web Applications connections contain JavaScript code that regularly refreshes the page or sends HTTP requests, regardless of user activity or inactivity. A session that is abandoned at such a site does not time out, because it appears to be active. You can use the session update feature to prevent these sessions from remaining active indefinitely, and you can specify sites whose session activity is to be disregarded for purposes of computing idle time.

In the list, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character, to specify URLs that should not update the FirePass controller session. An empty list means all URLs update a session.

Configuring "Home/Logout" tab injection

The FirePass controller inserts into HTML pages a small amount of HTML that contains the JavaScript that displays the Home and Logout navigation links. In the box in the Home/Logout tab injection section, type the full URL for the page into which you do not want the FirePass controller to insert JavaScript. Pages generated without the JavaScript contain no Home or Logout links.

Preventing Java byte code rewriting

You can use the Java Byte Code Rewriting feature to suspend rewriting of Java classes, or .jar, .cab, or .zip archives for specified match patterns.

By default, the FirePass controller handles Java byte code so that all HTTP, HTTPS, and socket-based network communication is sent to the FirePass controller through secure HTTPS tunneling. This approach provides a secure and portable proxy mechanism for web-based, client-server applications that utilize client Java applets.

The reverse proxy rewriting engine supports most network-related classes and methods. As long as the Java applet uses TCP, and the network traffic is initiated from the client, the applet is supported. If the applet contains server-initiated connections through the use of the ServerSocket class, reverse proxy cannot process the applet. Reverse proxy rewrites and re-signs only those Java applets that require patching.

Since reverse proxy modifies the byte code, the final applet delivered to the end-user is different from the original applet. The FirePass controller re-signs the applet with its own signing certificate. In some cases, this can result in a browser warning being displayed to the client.

To prevent Java modification problems with reverse proxy, ensure that all network-related classes conform to the Sun Java specification. The rewriting functionality might not support class files written in a proprietary format. If the class files do not contain standard byte code, then reverse proxy cannot modify the content.

The FirePass controller caches rewritten Java applet for the next client request. Because of the caching operation, if your application uses Java applets, make sure to check the Enable Dynamic Cache on FirePass. Generally improves WebApplications performance check box on the Portal Access : Web Applications : Caching and Compression screen.

In the box in the Java Byte Code Rewriting section, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character, to specify URLs for which the FirePass controller should not rewrite classes or .jar, .cab, or .zip archives. An empty list means the FirePass controller rewrites all classes or .jar, .cab, or .zip archives. For more information about the process of rewriting, see Configuring web applications for minimal rewriting .

Understanding the Flash rewriting support

The rewrite engine fully supports and rewrites Flash files, .swf, and Flash ActionScript. Because of specific Flash file formatting, web application connections through Portal Access cannot be configured to stream Flash files. Instead, the FirePass controller fully downloads the Flash files from the server, rewrites them, and then sends them to the user. If you plan to deliver large Flash files, for example, Flash files containing a video stream, users might experience a significant delay before the file displays the stream.

Configuring OWA, iNotes, and other specific web applications

For effective access, some web applications, such as Microsoft Outlook Web Access and IBM iNotes, require a special access mode. In the Feature Web Applications section of the Content Processing screen, you can specify the host name or comma-separated list of host names for which you want to switch to special mode.

For each host you specify, the FirePass controller uses the optimal caching and compression settings, overriding the global settings specified on the Portal Access : Caching and Compression screen. You can also check Automatically detect hosts for OWA and iNotes to have the FirePass controller evaluate the hosts and switch to special mode automatically. For more information, see Configuring caching and compression .

Configuring web applications global settings

You can configure cookie pass-through using the box in the Web Applications Global Settings area. You might want to allow cookies to pass from the client to specific web sites. With the setting, you can specify a comma-separated list of patterns to compare with incoming URLs. If there is no pattern, the FirePass controller blocks cookie pass-through for all URLs. You can type an asterisk ( * ) to allow cookies to pass through for all URLs. You can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character.

*://msnbc.msn.com*

*://www.yahoo.com*

*://www.ibm.com*

If your web site includes JavaScript that does any client-side cookie manipulation, you must specify a pattern that allows the cookie to pass through to the client browser. For security reasons, cookies are not passed through by default. When troubleshooting or testing initial support for a web portal or application, check the Do not block cookies at FirePass, pass them to the browser for specified URL patterns check box, and type an asterisk ( * ) in the box. This configuration instructs the FirePass controller to pass all cookies through to the client browser. Then after testing, you can restrict the cookies being passed.

Configuring Content Processing Global Settings requires a service restart, and also provides the following options:

  • Compatibility mode (enable legacy version of Web Applications handler)
    Allows you to continue to use the web applications routines that shipped with earlier versions of the FirePass controller. Select this option only if you have developed SED scripts tuned to the specific requirements of your intranet, and you are satisfied with the functionality of Portal Access Web Applications (formerly MyIntranet).
  • Automatically patch Java Applets
    Intercepts the Java applet and unwraps it if it is a .jar, .cab, or a .zip archive. Next, each class is searched, and when the applet-rewrite functionality finds an Applet, JApplet, Socket, or URL, or InetAddress class, it rewrites it accordingly, along with rewriting its inheritance definitions. Then, the applet is repacked and resigned, if necessary, using the F5 signing certificate. The FirePass controller then passes the transformed applets to the web client, and caches them, if the dynamic cache option is set.
  • By specifying URLs under Java Byte Code Rewriting on the Content Processing Global Settings screen, you can suspend rewriting for specific URLs. For more information, see Preventing Java byte code rewriting and Configuring the Alternative Host/Port-based type of bypass .

  • Block non-HTML data
    Prevents download of files such as .doc and .pdf from being downloaded from web applications. Only HTML content is allowed to pass through the proxy.
  • Remedy IE gzip compression bug by adding leading 2 kilobytes of whitespace to HTML pages
    Compensates for an Internet Explorer bug that strips off the leading two kilobytes of server messages when it accesses a web page compressed using gzip. It does so by adding 2K of leading, padding spaces. Selecting this option does not affect the appearance of the application on other browsers. Select this option if you enable compression on the Caching and Compression screen, and if any of your users might connect using an unpatched version of Internet Explorer 6. To access the Caching and Compression screen, in the navigation pane, click Portal Access, expand Web Applications, and click Caching and Compression.
  • Do not block cookies at FirePass, pass them to the browser for specified URL patterns
    Allows the FirePass controller to pass cookies to the user's web browser. This option is useful for supporting web applications that use JavaScript in the browser to manipulate cookies. We recommend that you specify a pattern or list of patterns that allows cookie pass-through only for web applications with URLs that match the pattern.
  • Automatically add websites that require client side cookie manipulation
    Adds to the list the web sites that require client-side cookie manipulation when the FirePass controller encounters them. By default, this feature is enabled. F5 Networks strongly recommend disabling this option once the learning phase is over.
  • Obfuscate cleartext cookies
    Obscures cookies sent in clear text format so users cannot read them. By default, this feature is enabled.
  • Translate hidden form parameters if they look like URLs
    Select this option to translate hidden form parameters if they appear as a URL, such as http://XXX. This option is useful when you have JavaScript that manipulates hidden form parameters. F5 Networks recommends limiting the effect of this option by specifying a list of URL patterns to match against. In the list, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. An empty list means all URLs are patched.

Configuring caching and compression

You can define caching and compression functionality on the Caching and Compression screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, and click Caching and Compression. Using options on this screen, you can configure settings that determine caching and compression of files sent from the FirePass controller to remote user's web browsers, as well as the transmission of cookies and file downloads from intranet servers to users.

When using dynamic cache, the FirePass controller does not distinguish between static or dynamic content. It distinguishes between objects that the remote server designates as those that the FirePass controller may cache and those it cannot cache. The remote server indicates the object's ability to be cached by setting the appropriate cache control in the response's HTTP headers. If the remote server indicates that an object may be cached, and this option is checked, the FirePass controller caches the object in its dynamic cache.

Note

You should not enable dynamic cache when you are using group-based VLAN to access hosts with the same host name or IP address on different VLANs.

The FirePass controller validates the currentness of cached objects by sending an if-modified-since request-header to the remote server and receiving either a (not modified) response or the modified object. This ensures that objects in the cache remain fresh.

If client browsers request both compressed (gzip) and non-compressed objects simultaneously, the FirePass controller stores each type into the cache for maximum performance.

Caching errors do not affect web application functionality. When the FirePass controller cannot cache an object for any reason, the FirePass controller simply sends the object to the user. In other words, operation is the same as if caching is turned off.

You can determine whether the FirePass controller has presented content to a client from the cache, by checking the response headers in pages returned to the browser for the presence of the following string:

X-Cache: HIT from your.firepass.hostname

Setting caching and compression

The Caching and Compression screen provides the following caching and compression options:

  • Enable Dynamic Cache on FirePass. Generally improves WebApplications performance:
    Caches content to prevent the need for repeated rewriting. You can also clear the dynamic cache by clicking the Clear Cache button.
  • Enable Compression. Saves bandwidth, at the expense of server resources:
    Uses the gzip compression utility to substantially reduce the size of generated content. The most noticeable improvement in speed occur when accessing pages that contain big Java classes or other large elements (images, scripts, and so on), but not when accessing pages that reference Java packages (.jar files), class archives (.zip files), or compressed images (.jpg, .png, and Compressed TIFF files).
  • For iNotes and other Java-based web mail packages, enabling compression vastly improves the speed in which pages are loaded. You can also specify a comma-separated list of URLs for the FirePass controller not to compress, even when compression is turned on. In the list, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. Turning on gzip compression reduces FirePass controller resources, which can affect scalability.

Configuring global caching and compression settings

You can choose from several global caching and compression settings. Each global setting caching option has an inherent trade-off between web application performance and security. The global settings you can select include:

  • Don't cache anything, except Style Sheets and JavaScript includes
    Provides a good compromise between security and performance. By default, web applications mark every screen as non-cacheable with the exception of JavaScript and style-sheet includes. The reason is that typically, these sizeable includes are designed with caching in mind. When caching is turned off, a high percentage of the traffic consists of these includes. Given that the content of these includes is rarely confidential, they are not marked as non-cacheable by default.
  • Don't cache anything, except for images, style sheets and JavaScript includes
    Results in better performance than the first option, but less security.
  • Cache nothing at the remote browser
    Impacts performance more than the first two options, but provides better security. OWA and iNotes require some caching, so select another option when you are serving OWA and iNotes application pages.
  • Don't enforce no-cache
    Provides the best performance of all options, but the least amount of security. Use this option only with trusted terminals such as home computers. This option caches according to the web browser settings. For this setting, you can specify a comma-separated list of URLs for which the FirePass controller should ignore no-cache. If there is no list specified, no URLs are exempt from no-cache. When you specify the list, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. You would use this option in cases where the no-cache header causes problems.
For example, if Cache nothing at the remote browser is set, when proxying HTTP content, The FirePass controller automatically sets a Cache-Control: no-cache header. The Cache-Control: no-cache header can cause problems for some XML applications, mostly on Internet Explorer browsers, because the client does not retrieve XSL files that are not cacheable. When this occurs, the browser displays an error indicating that the XSL file is not cacheable or is not available. You can work around this issue by specifying http://*.siterequest.com/*.xsl in the box so that the FirePass controller does not insert the cache control headers into files that end with an .xsl extension.

Configuring intranet webtop options

You can specify an intranet web page to replace the webtop for a specific master group on the Intranet Webtops screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, and click Intranet Webtops. If you elect to use a web page, no other access functions are available. Configured intranet webtops apply to all users in a master group.

You would configure this feature when you want to replace the standard FirePass controller webtop with an internal intranet portal front-page. An intranet webtop completely replaces the standard FirePass controller webtop, which typically displays administrator and user-defined favorites.

Note

In addition, you can create a custom replacement page that contains JavaScript code that starts FirePass controller favorites. You can store the replacement webtop page on the FirePass controller, using WebDAV, or on an external server. For more information and code samples, see the online help on the Device Management : Customization screen under Advanced WebDAV customization.

Intranet webtops have the following properties and elements.

  • Request
    Indicates whether to transmit the URL and its accompanying arguments in GET, or in a POST request. Using POST is a more secure way to provide a user name and password for logging on to an intranet site, because the variables are not visible on the URL line of the browser for someone to see.
  • URL
    Indicates the intranet web server that serves the application. For example:
    http://server.siterequest.com/index.html
  • URL variables
    Contains variables to be either appended or sent in a GET command to the specified URL. For more information and examples, see Working with URL variables .
  • Enabled
    Indicates whether the web application serves the specified page as the webtop for users in the associated group. For additional information on how to use a page as a customized webtop and run FirePass favorites, see the online help on the Device Management : Customization screen.

Preserving page content

The FirePass controller supports the ability to present favorites on a custom portal page located on the FirePass controller, using WebDAV, or from a custom portal page stored on one of your own internal servers. You can use the portal page as an alternative to the FirePass controller webtop.

For more information about WebDAV functionality, search for WebDAV in the online help.

Once you have the portal page, you can configure it as a FirePass controller webtop or define a reverse-proxy favorite. Then, users who log on to the FirePass controller using that portal page can start favorites, such as AppTunnels or Network Access connections, by clicking portal links.

If you have HTML, JavaScript, or CSS content that you want to preserve, you can do so by placing a <FP_DO_NOT_TOUCH> tag at the beginning and a </FP_DO_NOT_TOUCH> tag at the end of the code. The tags prevent the code inside them from being rewritten.

Note

In earlier versions, the online help for the Device Management : Customization screen in the WebDAV section, contained sample code that you could use for this purpose. The new reverse-proxy engine rewrites some of the content so that pages using the sample code no longer work. If you are using the sample code, you can also use these tags to prevent the rewriting.

Configuring proxy options

You can specify proxy settings on the Proxies screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, and then click Proxies. The FirePass controller can use HTTP and HTTPS proxies for web access. The Set up optional HTTP and SSL proxies for public Internet access section provides options for proxies for HTTP, SSL, or both. In addition, you can elect to use basic proxy authorization, specifying a user name and password to the proxy.

The FirePass controller web-access mechanism requires a proxy if there is no outbound access to the Internet. Also, Web Applications functionality might require proxy settings if the FirePass controller does not have direct access to the web servers on the local network.

Proxy settings consist of an address and port number. You can also specify a comma-separated list of addresses or subnets to which the FirePass controller should allow direct access, that is, not through the proxy server.

When you check Enable HTTP proxy or Enable SSL proxy and click Update and Test, the FirePass controller presents Address and Port boxes for each type of proxy.You can also specify a list of the IP addresses to which the FirePass controller should allow direct access rather than through the proxy.

Note

The FirePass controller makes sure it can connect to a specified proxy before committing the settings. Because of this, testing a new configuration might take a minute or so if the settings are incorrect.

In the No proxy for the following addresses (comma separated) box, you can specify the leading digits for IP addresses for resources to which you want the FirePass controller to allow direct access. Use commas to separate these addresses. You can use the X[.Y[.Z]] format for IP address templates, for example, 19 or 192 or 192.168 or 192.168.200 or 192.168.200.12. If there is no list of addresses, the FirePass controller uses a proxy for all resource access.

Note

The FirePass controller does not support specifying a subnet mask using 24-bit (CIDR) addresses for the proxy exclusion list.

Configuring Windows files

You can configure Windows Files favorites that give users access to files in network shared Windows folders. Once connected, users can view, download, move, rename, and delete files. You can also specify global settings that apply to all Windows files connections through Portal Access.

Configuring Windows Files favorites

You can use the Resources screen to configure favorites for the user's webtop. To access the Resources screen, in the navigation pane, click Portal Access, and click Windows Files. To set other policies and behaviors, you can use the Master Group Settings screen. For more information on master group settings, see the online help.

When you click Add new favorite on the Resources screen, the screen reveals additional options.

  • Type
    Indicates whether the link is a new configuration (Favorite) or a pointer to an existing one in another master group (Alias). Alias is available as an option only when there are Portal Access favorites configured in another master group.
  • Name
    Contains the name for the intranet site that you are defining as a favorite. This is the name the user sees on the webtop. The string you specify can be any name; field format is not limited. For example:
    Project management & "dailies"
  • Path
    Contains the Microsoft Universal Naming Convention (UNC) string. A UNC name typically references a shared folder and file accessible over a network rather than a drive letter and path. You can include path arguments such as %username% to substitute for user's logon and %group% to substitute for the user's master group name. For example \\publicsrv.eng.siterequest.com
  • Endpoint protection required
    Provides a list of Protected Configurations defined on the Users : Endpoint Security : Protected Configurations screen. If the user's endpoint protection does not satisfy the defined condition, the system prevents access to the specified resource. For more information about protected configurations, see Creating protected configurations, on page 3-21 .
Important

The FirePass controller does not verify paths, so make sure the path is specified correctly.

Configuring Windows Files master group settings

You can specify options that apply to all Windows Files users on the Master Group Settings screen. To access the Master Group Settings screen. in the navigation pane, click Portal Access, expand Windows Files, and click Master Group Settings.

Important

To support master group-based policy routing for Windows Files, you must configure a valid WINS server on the Master Group Settings screen. The FirePass controller uses the WINS server for performing NetBIOS name resolution when master group-based policy routing is enabled.

The Master Group Settings screen provides a set of options that govern the operation of Windows Files functionality through Portal Access connections.

  • Limit Windows Files Access to Favorites only (for Extranets, partner and customer access, etc.)
    Prevents master group members from browsing outside of folders specified in favorites.
  • Enable file upload
    Controls the uploading files for users in the associated master group. To specify the maximum file upload size, and set antivirus checks for downloaded files, see Configuring buffer overflow protection .
  • WINS Address
    This setting is necessary for multi-segment networks, when the FirePass controller and the LAN are on different network segments, or when the LAN itself has multiple segments. You must specify WINS Address for networks structured as multi-segment LAN environments. If the routing table assigned to the master group is different from main, you should configure WINS Address to handle NetBIOS name resolution.
  • Default Domain/Workgroup
    Contains the name of the Windows domain or workgroup where the FirePass controller resides. You must specify Default Domain/Workgroup when the FirePass controller unit address is not on the target LAN. We also recommend that you define the Default Domain/Workgroup setting for multi-segment LAN environments.
  • Auto-login to Windows File shares using FirePass user login credentials
    Directs the FirePass controller to use the user's FirePass controller logon name and password to automatically log on to Windows file servers and shares.
  • Click to change the status and/or webifyer position on the webtop
    Opens the User Experience screen for the associated master group, where you can change the location and operation of favorites on the user's webtop. For more information, see the online help for the screen.

Configuring Mobile E-Mail

You can configure the Portal Access : Mobile E-Mail feature to enable users to access email from any client computer. The Mobile E-Mail feature provides very lightweight access to multiple Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) mailboxes and address books, using data from the FirePass controller's internal database or from an LDAP directory. You can configure different Mobile E-Mail settings for each master group. There are several options for configuring logon options:

  • Allowing the user to enter a logon name and password directly
  • Using the FirePass database for logon information
  • Querying an LDAP server to retrieve logon credentials.

Users can use any web browser to access the mailbox. In particular, users who are away from the office can use browsers on mobile devices to quickly browse through emails.

A user can configure any number of email accounts, but you can limit access to only the corporate account you create, by checking the Limit E-Mail Access to Corporate mail account only (for Extranets, partner and customer access, etc.) check box. This limitation is useful for users logging on from extranets, and for partner and customer access. You can also disable the downloading of attachments, which can help prevent introduction of untrusted material onto the client's machine.

Configuring Mobile E-Mail includes the following options:

  • Master Group
    Presents a list of all master groups. Select the one you want to configure.
  • Enable corporate mail account
    Provides access to the user's corporate email account.
  • Account name
    Represents the string users see as the name of the link on their webtop. Corporate Mail is the default.
  • Mail server
    Represents the mail server name or IP address. For example, mailserver.siterequest.com.
  • Type
    Presents the support options: POP and IMAP. Select the one you want.
  • IMAP Folders
    Represents the comma-separated list of folders that you want users to see, if you are using an IMAP mail server. This list prevents the confusion created by mail servers that display items that are not email messages, such as contacts or calendars, as empty email folders. Users can also add to the list themselves.
  • Login Information
    Presents a list of options for logging on to Mobile E-Mail.
    • User supplies display and login information during first login: Gets email information from users when they attempt to use Mobile E-Mail for the first time.
    • Use FirePass database for display and login information: Retrieves email address, logon name, and password from the FirePass controller internal database.
    • Use LDAP query for mail server, display, and login information: Queries an LDAP server to dynamically retrieve each user's email information. When you choose this option, you must configure the LDAP query. For descriptions of the query options, see Configuring the LDAP query , following.
  • Outgoing Mail server
    Represents the outgoing email server name or IP address for the FirePass controller to use when sending email. If you do not specify a server, the FirePass controller uses the settings specified in Primary server on the Device Management : Configuration : SMTP Server screen.

When you finish configuring all of the options, click the Update button.

Important

If you use LDAP authentication over SSL, specify a host name, and be sure that the host name exactly matches the name on your LDAP server's certificate.

Configuring the LDAP query

When you select the Use LDAP query for mail server, display, and login information option on the Login information list in the Corporate email account section of the Mobile E-Mail screen, you must also specify the following options:

  • LDAP server
    Represents the IP address or host name of the LDAP server.
  • Port
    Represents an LDAP port, such as 389.
  • Use SSL connection
    Provides support for using SSL for the connection.
  • Protocol version
    Presents a list of the LDAP protocol version (2 or 3) for you to select. The default protocol version is 3. If you use Active Directory, you must use version 3.
  • Bind DN
    Represents the distinguished name the FirePass controller should use to bind to the LDAP directory.
  • Bind password
    Represents the password for the BIND DN. You can leave the box empty to require no authentication.
  • Search base
    Indicates the level of the entry in the tree to be used for the search, for example:
    cn=Recipients,ou=Exchange,o=FirePass
  • Filter template
    Contains the string to use when searching for the user. You can use %s in the filter expression to have the FirePass controller insert a user logon, for example:
    (&(objectclass=person)(cn=*%s*))
  • Attribute for mail server
    Contains the attribute in the LDAP schema that stores the mail server name.
  • Attributes for user's display name, email address, and login
    Contains the attributes in the LDAP schema that stores the associated information.
  • Attribute for mail server
    Represents the attribute in the LDAP schema that stores the mail server name.
  • Attribute for user's display name
    Represents the attribute in the LDAP schema that stores the name that indicates who sent the email.
  • Attribute for user's email address
    Represents the attribute in the LDAP schema that stores the originating address of the email.
  • Attribute for user's logon
    Represents the attribute in the LDAP schema that stores the name the user types when logging on to the email server.

When you finish configuring all of the options, click the Update button.

Configuring LDAP as the email address source

By default, Mobile E-Mail uses a list of users from the FirePass controller database as an address book. You can choose instead to use an LDAP server as the email address source. When you choose Use LDAP server to obtain addresses, you must also configure the following options:

  • LDAP server
    Represents the IP address or host name of the LDAP server.
  • Port
    Represents an LDAP port, such as 389.
  • Use SSL connection
    Provides support for using SSL for the connection.
  • Protocol version
    Presents a list of the LDAP protocol version (2 or 3) for you to select. The default protocol version is 3. If you use Active Directory, you must use version 3.
  • Bind DN
    Represents the distinguished name the FirePass controller should use to bind to the LDAP directory.
  • Bind password
    Represents the password for the BIND DN. You can leave the box empty to require no authentication.
  • Search base
    Indicates the level of the entry in the tree to be used for the search, for example:
    cn=Recipients,ou=Exchange,o=FirePass
  • Filter template
    Contains the string to use when searching for the user. You can use %s in the filter expression to have the FirePass controller insert a user logon, for example:
    (&(objectclass=person)(cn=*%s*))
  • Name attribute
    Represents the attribute in the LDAP scheme that stores the user's name.
  • Address attribute
    Represents the attribute in the LDAP scheme that stores the user's email address, which is typically mail.

When you finish configuring all of the options, click the Update button.

Disabling email attachments

By default, email attachment downloads are enabled. You can disable downloads by checking the Disable attachment download check box. This can help you protect remote client computers by preventing the introduction of content that may contain viruses.

Changing where Mobile E-Mail links appear on the webtop

You can customize the location of favorites on the user's webtop. To access the customization page, click the Click to change the status and/or webifyer position on the webtop link on the user's home page webtop.

Configuring content inspection

You can configure several kinds of functionality to provide content inspection. These are provided as tabs on the Content Inspection screen. To access the screen, in the navigation pane, click Portal Access, and click Content Inspection, and then click one of the tabs.

  • XSS scripting
    Represents cross site scripting, a type of attack that gathers data from a user for unauthorized use of security vulnerabilities in web applications. You can use options on this screen to aid in preventing such attacks. For more information, see Configuring cross site scripting security , following.
  • SQL injection
    Represents the unauthorized process of introducing SQL commands in the command string to gather database information. You can use options on this screen to test for such activity. For more information, see Configuring SQL injection scanning .
  • Buffer overflow
    Represents a security vulnerability that, when exploited, allows for running unauthorized code on the user's computer. You can use options on this screen to reduce the possibility of this type of activity. For more information, see Configuring buffer overflow protection .
  • Antivirus
    Represents the activity of detecting and preventing the introduction of viruses onto the user's computer. You can use options on this screen to configure virus scanning and to check uploaded files for viruses. For more information, see Configuring anti-virus scanning of uploaded files .

Configuring cross site scripting security

You can use the XSS scripting screen to specify cross site scripting (also called CSS or XSS). To access the screen, in the navigation pane, click Portal Access, click Content Inspection, and then click the XSS scripting tab.

The FirePass controller aids in preventing cross site scripting attacks from vulnerable web servers. This is done by scanning URL arguments and form POST data sent by users through Web Applications, and blocking the request if it looks suspicious.

Note

The FirePass controller user webtop and administrative console interfaces are already protected against cross site scripting attacks.

A web site may inadvertently include malicious HTML tags or script in a dynamically generated web page, based on unvalidated input from untrustworthy sources. This can happen when a web server does not adequately ensure that generated pages are sufficiently encoded to prevent unintended execution of scripts, and when input is not screened to prevent malicious HTML from being presented to the user.

This vulnerability is used as the basis for cross site scripting attacks, and can occur when a user relies on an untrustworthy source of information, such as an external untrusted web site link or a link in an email message. For example, an attacker may construct a malicious link such as:

<A HREF="http://siterequest.com/comment.cgi?mycomment=<SCRIPT>malicious code</SCRIPT>"> Click Here</A>

When a user clicks this link, the URL sent to siterequest.com includes malicious code. If the web server returns to the user a page that includes the value of mycomment, that is, if the web server does not properly filter user input or generated output, a vulnerable client might be able to execute the malicious code.

Scanning for suspicious characters

Options in the Restricting web site input to allowed character set section instruct the FirePass controller to scan user input data for suspicious characters such as less than ( < ) and greater than ( > ), and their URL-encoded equivalents of %3c and %3d. The FirePass controller bases the definition for suspicious characters upon a defined allowed character set.

The default match pattern is:

'[[:space:]+]*(;|or|union|select|insert|update|delete|drop|exec|having|
shutdown|xp_).*--

If the operation detects any suspicious characters, the FirePass controller blocks the user's request.

The FirePass controller provides the following options for restricting input to an allowed character set:

  • Scan URL parameters for restricted characters
    Inspects user input data in HTTP GET for suspicious characters within URL arguments.
  • Scan form POST data for restricted characters
    Inspects user input data within URL-encoded form POST data for suspicious characters.
  • User defined allowed character set (advanced)
    Provides an area for defining your own character set to use for scanning URL arguments and form POST data. Checking this option populates the box with the default list of characters, URL-encoded according to RFC 1738, which you can modify.

Scanning for embedded script code

Options in Scanning web site input for embedded script code instruct the FirePass controller to scan user input data for suspicious strings such as <SCRIPT and javascript: and their URL-encoded equivalents. The FirePass controller bases the definition of suspicious strings on a defined script search element list. If the scan detects any suspicious active elements, the FirePass controller blocks the user's request.

The FirePass controller provides the following options for scanning for embedded code:

  • Scan URL parameters for embedded script code
    Inspects user input data for active elements such as scripts within URL arguments.
  • Scan form POST data for embedded script code
    Inspects user input data within URL-encoded form POST data for active elements, such as scripts.
  • User defined script search elements (advanced)
    Provides an area for defining your own search elements. For example, you can modify the active element set of strings used for scanning of URL arguments and form POST data. Checking this option opens a box containing the default list of elements. You can modify this value or define your own.
  • <script <object <applet <embed <form javascript: vbscript: mocha: livescript: about: onload= onmouseover= text/javascript script> &{ url( expression(

Excluding sites from XSS scanning

You can also specify a comma-separated list of URLs to exempt from scanning operations. In the Web site exceptions list section, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. If the box is empty, it means that the FirePass controller scans requests to all sites. For example, if a particular intranet web site supports entering HTML tags, you should exclude this site from URL argument and form POST data scanning.

Configuring SQL injection scanning

You can use the SQL injection screen to specify virus scanning and database update options. To access the screen, in the navigation pane, click Portal Access, click Content Inspection, and then click the SQL injection tab.

SQL injection exposures allow attackers to modify calls to backend databases by adding to or manipulating SQL statements. To exploit a SQL injection flaw, the attacker embeds malicious SQL commands into the content of a parameter intended to be part of an SQL call. Consequences can range from trivial to severe.

The web application is responsible for detecting and blocking these attacks. However, the FirePass controller offers additional lines of perimeter defense against injection attacks initiated in web applications accessed through Portal Access.

You can:

  • Filter input URL parameters and form POST data for suspicious characters
  • Block requests with suspicious extended content.

Filtering for suspicious characters

Options in Filtering suspicious web site input instruct the FirePass controller to scan and filter user input data for suspicious characters such as apostrophe ( ' ) , number sign ( # ), double-dashes ( -- ), and semi-colons ( ; ) and their URL-encoded equivalents %27, %23, and %3b. (There is no encoding for double-dashes.) Because valid web site input can contain these characters, you might want to limit the web site match list or only enable the more-specific blocking options in Blocking suspicious web site input , following.

The default match pattern is:

'[[:space:]+]*(;|or|union|select|insert|update|delete|drop|exec|having|
shutdown|xp_).*--

If the parser detects any of these characters, it removes the character from the input string. It passes the rest of the string through to the application.

The FirePass controller provides the following options for filtering for suspicious characters:

  • Scan/filter URL parameters for suspicious characters
    Inspects URL variables to determine the presence of suspicious characters.
  • Scan/filter form POST data for suspicious characters
    Inspects form POST data to determine the presence of suspicious characters.
  • User defined block match regular expression (advanced)
    Enables customization of the regular expression used in the filtering operation. When you check this option, you can then modify the text using standard regular expression (regex) syntax. You can restore the default match pattern by clearing the option.
Note

This technique can prevent many attacks, but it also can result in many false positives, and could alter valid input. For example, the name O'Hara would be changed to OHara, and fail to match a valid record.

Blocking suspicious web site input

The blocking option performs a more sophisticated match for particular types of SQL injection attacks, by identifying strings with complex combinations. When the parser finds a match, it displays a warning and blocks the page. The FirePass controller adds a warning message to the FirePass System Log.

The default match pattern is:

'[[:space:]+]*(;|or|union|select|insert|update|delete|drop|exec|having|
shutdown|xp_).*--

You can view and customize the default pattern by checking the User defined block match regular expression (advanced) check box. You can then modify the text using standard regular expression (regex) syntax. You can restore the default match pattern by clearing the check box.

Excluding sites from SQL injection scanning

You can also specify a comma-separated list of URLs to exempt from scanning operations. In the Web site exceptions list section, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. If you select SQL injection filtering or blocking and you leave this list empty, it means that the FirePass controller scans all sites.

Configuring buffer overflow protection

You can use the Buffer overflow screen to specify virus scanning and database update options. To access the screen, in the navigation pane, click Portal Access, click Content Inspection, and then click the Buffer overflow tab.

A buffer overflow attack is an attempt to corrupt the execution stack of a web application by sending input that exceeds the length of the application's data buffer. By sending carefully crafted input to a web application, an attacker could cause the web application to execute arbitrary code, effectively taking over the machine. Even if the input string does not take over the target system, an attacker can use a buffer overflow as a denial-of-service attack.

Buffer overflow attacks exploit inputs of several types.

  • Files uploaded using the Windows or UNIX file access features
  • Form POST data input to web applications
  • GET query strings input to web applications

Web applications, web servers, and the services they use all can contain buffer overflow vulnerabilities. The best defense is to restrict the length of any attempted input string to the appropriate maximum for the application.

While it is the responsibility of the application to parse input, you can specify maximum levels for your environment, providing an outer perimeter of defense against exploits such as these.

The FirePass controller provides the following options for applying buffer overflow protection:

  • Restrict maximum upload size (32-1024 Mb)
    Constrains files that the user uploads to a specific size. The default value is 32 MB.
  • Restrict maximum length of a GET query string
    Constrains the request string to the maximum specified. The default value is 2048 bytes.
  • Restrict maximum length of POST data
    Constrains the response string to the maximum specified. The default value is 16384 bytes.

If you scheck the Restrict maximum length of a GET query string check box or the Restrict maximum length of POST data check box, you can also specify a comma-separated list of URLs to exclude from buffer overflow checks. In the web site exceptions box, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. If you specify buffer overflow options and you leave this list empty, it means that the FirePass controller checks input to all sites accessed through Portal Access.

Configuring anti-virus scanning of uploaded files

You can use the Antivirus screen to configure Portal Access to check uploaded files for virus infections. To access the screen. in the navigation pane, click Portal Access, click Content Inspection, and click the Antivirus tab. When the antivirus feature is active, it scans files that are uploaded using any of the following Portal Access functions:

  • Windows Files
  • Web Applications
  • Mobile E-Mail

The FirePass controller provides the following options for checking uploaded files for viruses:

  • Disable virus scanning
    Does not perform virus scanning of uploaded files. We recommend that you only choose this option if you are sure that you have another service performing virus scanning.
  • Enable ICAP client
    Instructs the FirePass controller to act as an Internet Content Adaptation Protocol (ICAP) client and use it for inspection using the response modification mode. For more information, see Enabling the ICAP client , following.
  • Enable standalone virus scanner
    Activates scanning using the standalone virus scanner, the Open Source Clam Antivirus running locally on the FirePass controller. For more information, see Enabling the standalone virus scanner , following.

Enabling the ICAP client

ICAP is an open standard for Internet proxy servers to communicate with content servers. If your corporate antivirus protection is based on an antivirus service that has ICAP capability, the FirePass controller can use an ICAP client for upload inspection. When you select Enable ICAP Client and click Update, the screen reveals additional options, in which you can specify the host name, IP address, or path and port of the ICAP server.

You specify the path and port of the ICAP server using the following format

[icap: // ]<domain-name > [<:port >][/ path]

Following are some examples of how to specify the path and port of the ICAP server:

  • siterequest_domain.siterequest.com: Specifies the domain name.
  • siterequest_domain.siterequest.com:1345: Specifies the domain name and port.
  • siterequest_domain.siterequest.com:1345/avscan: Specifies the domain name, port, and path.
  • siterequest_domain.siterequest.com/avscan: Specifies the domain name and path.
  • icap://siterequest_domain.siterequest.com:1345/avscan: Specifies the ICAP protocol, domain name, port, and path.

Enabling the standalone virus scanner

You can use the default virus scanner, Clam AntiVirus, to detect viruses in uploaded files. When you select Enable Standalone Virus Scanner and click Update, the screen reveals additional options.

In the Virus DataBase Update section, you can specify how to update the virus scanning files. You can update the Clam AntiVirus database manually, by periodically uploading database files, or automatically, by a process that runs on the FirePass controller to periodically checks the Clam AntiVirus site for database updates.

The Virus Database section shows the most recent updates for the Clam AntiVirus database.

Configuring for manual update

Clam AntiVirus stores virus information in two files: main.cvd and daily.cvd. These are available for download from the following sources: http://database.clamav.net/daily.cvd http://database.clamav.net/main.cvd.

If you are using the manual update method, download these files to your computer, and then upload them to the FirePass controller, using the Browse button to locate the file.

Configuring for automatic update

When you select Automatic update and click Update, the FirePass controller reveals additional options.

In Download site, you can specify a Clam AntiVirus mirror site. You can choose a site from http://www.clamav.net/mirrors.html, or specify database.clamav.net (a round-robin record that allocates traffic among the database mirrors). The default is database.clamav.net.

The update process uses the HTTP protocol. You can specify the frequency of updates (as the number of Updates per day), number of Retry attempts to download an update, and, if you use an HTTP proxy, any needed proxy parameters.




Introducing Portal Access

Portal Access connections enable end users to use a web browser to access specific services on the internal network. With Portal Access, the FirePass controller communicates with back-end servers, and translates the content into HTML pages for the client browser. The advantage is that the client computer requires no client software other than a browser application.

This method of access differs from connections configured for Network Access and App Tunnels, which provide direct access from the client to the internal network. These technologies do not manipulate or analyze the content being passed between the client and the internal network. These technologies do require small, automatically installed client components, but provide the most seamless direct access to internal applications. Portal Access configuration provides an administrator refined control over the applications that a user can access through the FirePass controller, as well as inspection of contents of transferred data.

For more information on connections configured for Network Access and App Tunnels, see Chapter 5, Configuring Network Access and Chapter 7, Configuring Application Access .

The other advantage of Portal Access is security. Because Network Access and App Tunnel connections communicate directly with the server, client connections must come from a trusted computer. Publicly available workstations do not meet this requirement. However, even though a workstation does not meet those requirements, your users should still be able to access certain applications.

In Portal Access connections, the client computer itself never communicates directly with the end-point application. That means that all communication is inspected at a very high level, and any attacks originating on the client computer fail because the attack cannot navigate through the links that have been rewritten by reverse proxy. In Portal Access connections, the FirePass controller communicates with the back-end servers, and then generates the HTML page for presentation in the browser window.

Introducing Portal Access features and operation

Portal Access provides remote users with web-based remote access to a wide variety of network applications and resources, including:

  • Intranet web servers
  • Email servers
  • Windows file servers
  • Terminal servers
  • Legacy, character-based applications.

Portal Access serves the internal resource into and out of the end user's web browser. The application being accessed and the protocol being supported (HTTP and HTTPS) dictate how Portal Access operates. Figure 6.1 , following, shows the process that Portal Access follows.

Figure 6.1 The Portal Access functionality of the FirePass controller

Introducing Portal Access application support

You can use Portal Access when users need access but they are away from their regular computers. FirePass provides additional functionality to secure connections from client machines, such as public kiosks or PDAs, which might not have the necessary applications installed or configured, but usually do have browsers installed. In this case, the web browser serves as the interface to the application.

You can set up different types of access for users in different master groups. For example, you can enable Windows Files access to users from one master group, and prevent access by users in another master group. In addition, you can enable browsing of internal web sites by name or IP address, which would be typical for employees, or limit access only to specified favorites, which would be useful in an extranet for partners and customers.

Using Web Applications

Web Applications access allows remote users secure access to internal web servers, such as Outlook Web Access (OWA), Microsoft SharePoint, IBM Domino Web Access (also known as Lotus iNotes), Domino Sametime, and Citrix NFuse. Using Web Application functionality, you can also provide access to most web-based applications and internal web servers. Portal Access provides access to web applications by performing an intelligent proxy of the content through the FirePass controller, so it changes all links to reference the FirePass controller address, rather than the originating server. The high performance, full-content rewrite engine also supports rewriting complex JavaScript™, Java™ applets, and Flash® content. You can use features such as the web cache, minimal content rewriting bypass mode, user-defined content processing scripts, and a number of others, to help refine compatibility and tune performance.

Using Windows Files

Windows Files access allows remote users browser-based access to browse, upload, download, move, copy, or delete files in shared directories. The FirePass controller communicates with file servers using the Server Message Block (SMB) protocol, which can support Windows 2003, Windows 2000, Windows for Workgroups, Windows NT 4.0, Linux, and Novell 5.1/6.0 with the Network File System (NFS) feature.

Using Mobile E-Mail

Mobile E-Mail access provides very lightweight access to POP/IMAP and SMTP email servers and LDAP address books using a standard web browser, or mini browsers on a PDA or smart phone. Users can send and receive messages, download attachments, and attach files from the internal LAN to send email messages. Mobile E-Mail is intended to complement a fat client by optimizing content for low bandwidth, mobile devices.

Using Content Inspection

Content Inspection scans URL arguments and POST data sent by users through Web Applications, and blocks the request if it appears as if it might be an attack. Content Inspection guards against cross-site scripting attacks, SQL injection attacks, buffer overflow attacks, and viruses from files uploaded using Windows Files, Web Applications, or Mobile E-mail.

Configuring web applications on the FirePass controller

You can configure the FirePass controller to provide access to web applications without requiring client configuration changes or software downloads. Typically, you use Portal Access when your users only require access to specific internal web portal-based applications, and do not require full Network Access. The FirePass controller provides security by rewriting links in all requests to internal servers. When the FirePass controller processes the connections, it uses the proxy engine's built-in logic and additional custom-configurable content-processing scripts to modify the URLs and other links in the original HTML document. The controller changes these links by rewriting the path to the URL. You can use stream editor (SED) scripts to modify intranet web pages to handle issues related to the FirePass controller sending custom content through the proxy engine.

F5 Networks has tested the following web applications to ensure that the FirePass controller handles them without client reconfiguration.

  • Microsoft Outlook Web Access (OWA)
  • Microsoft SharePoint
  • IBM Lotus Domino Web Access (also known as Lotus iNotes)
  • Domino Sametime
  • Microsoft file servers configured for Common Internet File System (CIFS), the remote file system that uses the SMB protocol.

Some of your custom web applications will work with Portal Access without you having to make changes to the applications. However, some of your web applications, particularly those that make extensive use of JavaScript, Java applets, ActiveX controls, and Flash components, might require that you use content processing scripts or other configuration changes to enable the user to access them using Portal Access connections.

If you have a specific web application that requires additional configuration to work through Portal Access, you can generally use Application Tunnels or Network Access. These access methods provide a direct connection to the internal network, and do not require proxy-based changes or modification of web application content.

If you cannot use Application Tunnels or Network Access to solve access issues, you can try the proxy feature Minimal Content-Rewriting Bypass. For more information about this feature, see Configuring web applications for minimal rewriting .

Understanding proxy and cache functionality

You can use the FirePass controller Portal Access : Web Applications feature for the following operations:

  • Rewrite of complex HTML, JavaScript, Java applets, and Flash content
  • Dynamic cache of rewritten content
  • Extensive bypass configuration and content pre-processing and post-processing using scripts

The FirePass controller uses a high-performance, full-content rewrite engine to handle complex HTML, JavaScript, Java applets, and Flash. You can also enable a built in dynamic cache, so that the FirePass controller does not have to repeatedly rewrite content for static objects such as HTML, JavaScript, style sheets, and Java applets. Also, the web applications engine supports rewrite of complex applets such as Citrix, VNC (when presented by Java applets), as well as .jar and .cab archive resigning.

In some cases you might want to bypass the FirePass controller's reverse proxy to support some very complex web applications using the Minimal Content-Rewriting Bypass feature. To use this feature, your applications must reside on the single target server. When you use the bypass feature, the proxy engine operates differently.

With the bypass feature, the proxy engine:

  • Uses the FirePass controller name to replace only the originating host name in the address. If the URL also contains a port, then the proxy engine replaces the host name and port with the FirePass controller name and port.
  • Does not rewrite URL references to other servers
  • Does not modify cookies, when you enable the global setting, cookie pass through.
  • Applies minimal content settings at the master group level

You can use the bypass feature by configuring a one-to-one mapping between one of the following options:

  • A URL pattern and an internal intranet host
  • A dedicated FirePass Web service on an alternate port or IP address, and an internal host

You can use SED scripts to rewrite output instead of preventing rewriting by configuring bypass. For information about Web application content processing using SED scripts, see Configuring content processing for web applications .

Setting cookie availability for web bypass

In some cases, for example, if your web application manipulates a client cookie, you want the FirePass controller to pass the cookie to the browser without altering it.

To specify cookie pass through

  1. In the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and click the Global Settings tab.
    The Content Processing : Global Settings screen opens.
  2. Scroll down to the Web Applications Global Settings section.
  3. Check the Do not block cookies at FirePass, pass them to the browser for specified URL patterns check box.
  4. In the box, specify the list of URLs or URL patterns you want the FirePass controller to ignore when performing proxy operations.
  5. To have the FirePass controller add URLs from sites that require cookie manipulation, check the Automatically add websites that require client side cookie manipulation check box.
  6. Click Update.

Defining favorites for Portal Access Web Applications access

To make Portal Access Web Applications available to users, you create favorites to internal web sites and URLs. A favorite is a collection of settings that represents a single link on the user's webtop. When the user clicks a Portal Access Web Application favorite, the FirePass controller opens the connection and runs the configured application.

Understanding Portal Access favorites options

You add new favorites using the Portal Access : Resources screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, and click Resources. When you click the Add new favorite, link, the screen reveals additional options.

  • Type
    Indicates whether the link is a new configuration (Favorite) or a pointer to an existing one in another master group (Alias). Alias is available as an option only when there are Portal Access favorites configured in another resource group.
  • Name
    Contains the name for the intranet site that you are defining as a favorite. This is the name the user sees on the webtop. The string you specify can be any name; field format is not limited. For example:
    Site Request application
  • Web Application Type
    Specifies web servers as generic, Microsoft Outlook Web Access (OWA) or IBM iNotes. For OWA and iNotes, Portal Access automatically selects the optimal caching and compression settings.
  • URL
    Indicates the intranet web server that serves the application. For example:
    http://server.siterequest.com/index.html
  • URL variables
    Contains variables to be either appended to the GET request or sent as data in a POST request to the specified URL. For more information and examples, see Working with URL variables , following.
  • Post URL variables
    Indicates that you want the variables in URL variables to be included in the POST request to the URL specified. For more information and examples, see Working with URL variables , following.
  • Enforce user-agent
    Contains the string you want the FirePass controller to send to the internal web server instead of the browser's actual user-agent identifier. For more information, see Specifying user-agent strings .
  • Open in new window
    Indicates whether the application opens in the existing browser window or in a new browser window.
    Check this option to open the application in a new window, or leave the option cleared to have the application replace the user's webtop.
  • Endpoint protection required
    Provides a list of Protected Configurations defined on the Users : Endpoint Security : Protected Configurations screen. If the user's endpoint protection does not satisfy the defined condition, the FirePass controller does not include this favorite on the webtop or allow access. For more information about protected configurations, see Creating protected configurations, on page 3-21 .

Once you have configured all of the necessary parameters for your application, click the Add New button to add the favorite. When you have configured at least one favorite, you can choose which link serves as the default by selecting it from the Default box, and clicking Update.

The default favorite starts automatically when users of the resource group open their web application favorites. With more than one default favorite defined, for example, when a user has multiple resource groups assigned, the FirePass controller starts only one of the defaults.

Working with URL variables

Although they are optional, you can use URL variables to support favorites, such as automatic user logon to intranet web sites, or for customizing intranet content for a user. You can use the %username% and %password% variables as values in a GET request. At logon time, the FirePass controller replaces the parameters with the user's FirePass controller user name and password.

URL variables are specified in the form:

variable1=value1&variable2=value2&variable3=value3

The following is an example of how to build an intranet favorite that contains a URL variable. First you specify the string in the URL box:

http://server.siterequest.com/index.html

Then you specify the variables you want to use in the Url variables box:

show_custom_content=1&user=%username%&password=%password%

For FirePass controller user johndoe with password johndoepassword, using these variables results in the following actual favorite link:

http://server.siterequest.com/index.html?show_custom_content=1& user=johndoe&password=johndoepassword

Alternately, you can specify that the FirePass controller send the variables in a POST request to the configured URL. This is a more secure way to provide a user name and password for logging on to an intranet site, because the variables are not visible on the URL line of the browser for someone to see.

For example, if you have the following form contents on an intranet logon page:

<form action=logon.php method=POST>

<input type=TEXT name=user>

<input type=PASSWORD name=password>

<input type=HIDDEN name=do_logon value=1>

<input type=SUBMIT value=Logon>

</form>

First, you specify the string in the URL box:

http://server.siterequest.com/logon.php

Then you specify the variables you want to use in the Url variables box:

user=%username%&password=%password%&do_logon=1

For FirePass controller user johndoe with password johndoepassword, using these variables results in the following actual favorite link:

http://server.siterequest.com/logon.php

The FirePass controller sends the following data directly to the server.siterequest.com site in a POST request:

user=johndoe&password=johndoepassword&do_logon=1

Specifying user-agent strings

The user-agent string identifies what the client's web browser uses with a specific network protocol. Some servers use the user-agent string to determine what content to send to the client browser. Although optional, specifying a user-agent string is useful when you need to simplify FirePass controller content. For example, for a highly complex web application, it might help to downgrade the content supplied by specifying the following user-agent string:

Mozilla/4.7 [en] (Windows NT 4.0; U)

Table 6.1 , following, contains a list of common user-agent strings.

Table 6.1 User-agent strings for several browsers
Browser
User-agent string
IE 6.0 on Windows
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
IE 5.5 on Windows
Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
IE 5.0 on Windows
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
IE 4.5 on Windows
Mozilla/4.0 (compatible; MSIE 4.5; Windows NT)
IE 4.01 on Windows
Mozilla/4.0 (compatible; MSIE 4.01; Windows NT)
Mozilla 1.7.8 on Windows
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511
Netscape 7.2 on Windows
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
Netscape 4.5 on UNIX
Mozilla/4.5 [en] (Win98; U)
Netscape 3.04 on UNIX
Mozilla/3.04Gold (Win95; U)
Opera 5 on UNIX
Opera/5.12 (Windows 2000; U) [en]
Opera 5 mimicking Netscape on Windows
Mozilla/4.0 (compatible; MSIE 5.0; Windows 98) Opera 5.01 [en]
Safari 2.0 for Macintosh OS X
Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/412 (KHTML, like Gecko) Safari/412
FireFox 1.0.4 on the Macintosh
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
FireFox 1.0.6 on Windows
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
FireFox 1.0.1 on Linux
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.7.6) Gecko/20050222 Firefox/1.0.1

Tip


An easy way to enter a user-agent string is to copy and paste the string from the Logons report into the Enforce user-agent box. You can find the string on the Reports : Logons screen in the User Agent column.

Configuring web applications for minimal rewriting

You can use the minimal content rewriting feature to prevent rewriting of your web application content. You can define minimal content rewriting operation on the WebApplications : Master Group Settings screen.

There are several configuration requirements for using the Minimal Content-Rewriting Bypass feature:

  • The application must reside on a single server. The FirePass controller cannot process URLs for separate servers when the Minimal Content-Rewriting Bypass feature is enabled.
  • You must configure cookie pass-through on FirePass controller in order to use the Minimal Content-Rewriting Bypass feature if there is client-side JavaScript that directly processes cookies.
  • You cannot use automatic cookie pass-through with Minimal Content-Rewriting Bypass.

You can configure the Minimal Content-Rewriting Bypass feature in only one of two modes:

  • Pattern-based
    Provides a pattern-matching mechanism for URLs. You specify a protocol, host, and path for the FirePass controller to match. If the FirePass controller encounters a URL that has a defined Pattern-based bypass rule, the FirePass controller does not modify URLs on the returned page.
  • Implementing the Pattern-based bypass mode requires no network changes, but you must specify the protocol, host, and path that the application uses so that the FirePass controller can match the incoming URLs.

  • Alternative Host/Port-based
    Provides a dedicated IP address and TCP port through which the FirePass controller proxies connections to the application server. When configuring the FirePass controller in Alternative Host/Port-based mode, you must configure one FirePass controller port for each port the application server uses. If your application uses SSL encryption, you must also install on the FirePass controller the same SSL certificate and private key that is installed on the application server.
Important

When you configure bypass, make sure to clear the box that enables compatibility mode on the Global Settings screen. Minimal content rewriting does not work in compatibility mode. To access the Global Settings screen, in the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and click the Global Settings tab. The option is Compatibility mode (enable legacy version of Web Applications handler), and is provided to support web applications configured using earlier versions (pre-5.4) of the FirePass controller reverse proxy engine.
Note

The Minimal Content-Rewriting Bypass feature is available only if you have the hotfix for FirePass 5.4.2, or if you are using FirePass 5.5.

Configuring pattern-based bypass

Instead of having the FirePass controller reverse proxy rewrite URLs and JavaScript, you can use the pattern-based bypass option. The pattern-based bypass functionality replaces the target server name with a name you specify, and processes requests based on the patterns you list. The pattern searches are case-sensitive, so you might have to specify the same pattern in upper- and lowercase. Patterns must be unique within the intranet to prevent interference with other web applications.

When you use this feature, the FirePass controller replaces all references to the target server's protocol://address:port with the FirePass protocol://address:port. For example, if a Web application consists of URLs starting with /myapp/ and /myimages/, you would associate the patterns /myapp/*,/myimages/* with the server. You must specify the target server in the following form:

protocol://servername[:optional port]

An example target server is http://myserver

Important

The root directory of the server cannot be used as the pattern for the pattern-based bypass mode, for example, you cannot specify http://, /, or /*.

You can find pattern-based bypass settings on the Master Group Settings screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, and click Master Group Settings.

When you configure settings, first select from Master Group the master group you want to have access to the application.

In the Minimal Content-Rewriting Bypass section, you can configure the following options:

  • Comma separated list of patterns
    Contains a list of match patterns for the web application. In this box, specify the application paths that you do not want the FirePass controller to translate. Separate each directory with a comma.
  • For example, if you do not want FirePass to translate a set of URLs, including all pages in the location:

    https://tech.siterequest.com/appdir1/ https://tech.siterequest.com/appdir2/ https://tech.siterequest.com/appdir3/text.html

    Type the following text:

    /appdir1/*,/appdir2/*,/appdir3/text.html
  • http[s]://<IP Address/Name>[:Port]
    Contains the target server. In this box, specify the protocol and host portion of the URL for the application.
  • For example, if you do not want FirePass to translate the URL:

    https://tech.siterequest.com/appdir1/

    Type the following text:

    https://tech.siterequest.com

You can specify a pattern using the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. The patterns must be unique. When you specify a pattern, you must include at least one subdirectory for each application.

Configuring the Alternative Host/Port-based type of bypass

The first step to configuring the Alternative Host/Port-based bypass type of minimal content rewriting is to create a web service and enable WebAccess Bypass. For information about creating web services, see Configuring web services, on page 8-17 . When you create the web service, if you want to use the Alternative Host/Port-based bypass type of minimal content rewriting, you check the WebAccess Bypass check box to indicate that the FirePass controller uses the web service only for proxy pass-through operations. For more information, see the following procedure.

Next, you configure alternative host/port-based minimal content-rewriting. For more information, see Configuring web applications for minimal rewriting .

To enable WebAccess Bypass

  1. In the navigation pane, click Device Management, expand Configuration, click Network Configuration, and then click the Web Services tab.
    The Web Server Configuration screen opens.
  2. From IP, select an available IP address to which users will connect or create a new address using the IP Config tab.
  3. Specify a port that is not already in use by another FirePass controller web service.
  4. Specify a host name.
    If you add the host name to your DNS server, users can connect to the application using the name of the host instead of having to use the IP address.
  5. Check the Enable SSL check box.
  6. Click Add New.
    The Web Service Configuration page opens.
  7. From the Certificate list, select a certificate to use with the new web service.
  8. Check the WebAccess Bypass box.
  9. Note: When you check the WebAccess Bypass check box, the FirePass controller disables the user logon and administrator logon to that service.
  10. Click the Update button.
  11. Click the Finalize tab.
  12. Click the Finalize Changes button.
  13. Wait while the finalize process completes.
  14. If necessary, restart services.
  15. In the navigation pane, click Portal Access, expand Web Applications, and click Master Group Settings, to configure Alternative Host/Port-based bypass options. For more information, see Configuring Alternative Host/Port-based bypass , following.
Note

Depending on how your firewall is configured, if you specify a new port, you might need to configure your firewall to allow communication on that port. You might need to specify a new port if you have one internal side that allows traffic through, or if you use servers outside the company on another network (also known as one-armed configuration).

Configuring Alternative Host/Port-based bypass

When you use the Alternative Host/Port-based bypass feature, the FirePass controller uses the proxy engine to make connections to the application server through specified IP address and port combinations, and replaces a specific internal host name with the name and port number you specify.

The Alternative Host/Port-based section on the Master Group Settings screen contains a list of the web services with a checked WebAccess Bypass option. The Alternative Host/Port-based section is empty if you have not checked WebAccess Bypass for at least one existing web service. In this case, the section contains a message, No Bypass Web Services configured, along with a Click here to configure link that opens the Device Management : Configuration : Network Configuration screen. From there, you can add a new web service or configure an existing one by checking Web Access Bypass on the associated Web Service Configuration screen.

For a procedure of how to configure a web service for minimal-rewriting bypass functionality, see Configuring web applications for minimal rewriting .

In the box under Alternative Host/Port-based, type the URL for your application, using the following format (where [ ] indicate optional values):

http[s]://<IP Address/Name>[:Port]

When you finish, make sure to click the Update button to have your settings take effect.

Configuring NTLM and basic authentication proxy

NTLM uses a challenge-response mechanism for authentication, in which clients prove their identities without sending the server a password. The mechanism consists of three messages: Type 1, negotiation; Type 2, challenge; and Type 3, authentication. Although Windows 2000 continues to support the protocol, Microsoft Kerberos has replaced it as the standard.

You can enable NTLM and basic authentication proxy on the Master Group Settings screen. To access the screen, click Portal Access, expand Web Applications, and click Master Group Settings. The FirePass controller supports sending through the proxy engine NTLM and basic authentication over HTTP on behalf of the user, which provides several benefits:

  • Prevents client browsers from caching basic or NTLM authentication credentials.
  • Allows client browsers not supporting basic or NTLM authentication to authenticate against web sites requiring this, such as Microsoft Internet Information Services (IIS).
  • Allows automatic logon (single sign-on) to sites supporting basic or NTLM authentication with user's FirePass credentials.

There is a security implication to running the FirePass controller without checking the Proxy Basic and NTLM auth using FirePass user login form check box. The implication is that, depending on the application, after logging off of an internal application configured for basic or NTLM authentication, users might be able to regain access to the internal application without entering logon information. This is because web browsers commonly cache basic or NTLM user credentials.

When you configure the FirePass controller to send basic or NTLM user credentials through the proxy engine, the controller replaces the basic or NTLM browser dialog box with a form-based dialog box, which prevents the web browser from caching user credentials.

NTLM and Basic Auth Proxy provides the following options:

  • Proxy Basic and NTLM auth using FirePass user login form
    Indicates whether to use the FirePass controller to proxy HTTP basic and NTLM authentication. If you enable this option, the FirePass controller presents a user logon web form whenever a protected site needs logon credentials. Basic and NTLM authentication proxying is enabled by default.
  • Auto-login to Basic and NTLM protected sites using FirePass user credentials
    Controls whether the FirePass controller can pass along the user's FirePass controller logon credentials to automatically log on to protected sites on the user's behalf. If the user's FirePass controller credentials do not match those required for the protected site and you enabled Proxy Basic and NTLM auth using FirePass user login form, the FirePass controller presents a user logon web form. Otherwise, the FirePass controller presents an authentication dialog box. When you enable this option, you can also configure the following options:
    • NTLM Auth Domain (optional)
      For protected sites requiring NTLM authentication, you can specify a default domain to be used in conjunction with the auto-logon support.
    • Basic Auth Domain (optional)
      For protected sites requiring basic authentication, you can specify a default domain to be used in conjunction with the auto-logon support. When specified, this value is prepended to the user name during basic authentication (for example: BASICDOMAIN\username).

Configuring split tunneling for Portal Access

You can define Portal Access split tunneling functionality on the Master Group Settings screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, and click Master Group Settings. You can use the split tunneling feature to specify which URLs should be processed by the FirePass controller proxy engine and which URLs should not. Split tunneling functionality helps:

  • Improve controller performance by lowering processing overhead
  • Make some web pages available (such as the performance-impacting pages served by many public portal sites) that might not be compatible with reverse-proxy technology

When you check Use URL patterns for split tunneling, the screen reveals additional options.

  • Rewrite
    Contains a comma-separated list of patterns to compare with incoming URLs. The FirePass controller proxies matching URLs. If the box is empty, the FirePass controller rewrites all URLs. You can type an asterisk ( * ) to specify that the FirePass controller rewrite all URLs.
  • Bypass
    Contains a comma-separated list of patterns to compare with incoming URLs. URLs that match are accessed directly, bypassing the FirePass controller reverse-proxy engine. If the box is empty, all URLs bypass the reverse-proxy engine, meaning that rewriting is done for all URLs that pass the test specified by patterns in the Rewrite box.

You can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character, in both the Rewrite and Bypass boxes. The FirePass controller first processes all patterns in the Rewrite box, and then all patterns in the Bypass box.

Example: http://*.siterequest.com/*

The split tunneling filters apply to favorites, to direct browsing, and to the links within a rewritten page. If you enable split tunneling, the FirePass controller presents only web pages that satisfy one of these filters. It blocks the others (although a blocked public site might still be available outside the webtop). If you do not use split tunneling, the FirePass controller processes all URLs through the reverse-proxy engine.

Split tunneling patterns ignore any part of the URL after the first pound sign ( # ) or question mark ( ? ) symbol; that is, anchors and URL variables are ignored.

Note

The Network Access feature also provides split-tunneling functionality. The functionality is slightly different, however. For more information, see Introducing Network Access, on page 5-1 .

Configuring accessibility scope

Even if you limit access to the intranet to favorites only, some links might contain links to other servers. You can define Portal Access Accessibility Scope functionality on the Master Group Settings screen. To prevent this, you can limit access, making available only particular web servers and pages. Specifying accessibility scope provides fine control over which URLs the FirePass controller allows the user to access. When you check Restrict resources accessible via Web Applications, the following options appear:

  • Allow
    Contains a comma-separated list of patterns to compare with incoming URL requests. The FirePass controller allows access to matching URLs. If the box is empty, the FirePass controller allows access to all URLs.
  • Deny
    Contains a comma-separated list of patterns to compare with incoming URLs. URLs that match are not allowed access. If the box is empty, the FirePass controller allows access to all URLs that pass the test specified by patterns in the Allow box.

You can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character, in both the Allow and Deny boxes. Each URL filter must specify a complete protocol and path. The FirePass controller first processes all patterns in the Allow box. If there is no match, the FirePass controller rejects the URL. If there is a match, that URL is then checked against the Deny filters. If there is a match, the URL is rejected, otherwise, it is accepted.

For example, the following specifies two URLs containing wildcards:

http://www.*.com/*.html,http://www.*.com/*.php

Note

A trailing slash ( / ) is often required in a URL filter since this is typically appended by the browser.

For example, you might have to specify: http://server.siterequest.com/ instead of http://server.siterequest.com for the filter to work.

Preserving host names

You can define which host names to preserve on the Master Group Settings screen. You might want to prevent the replacing of host names with the FirePass controller name if you want to provide access to a web application that uses the host name for a specific purpose. For example, preserving the host name is useful for web applications that have JavaScript code that sets a cookie based on the actual server name in the browser.

To access the Master Group Settings screen, click Portal Access, expand Web Applications, and click Master Group Settings.

When you check Preserve FirePass hostname when accessing Web Applications, the screen reveals a box. Into the box you can specify a comma-separated list of patterns to match against URLs. You can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character, in the box. This option instructs the reverse-proxy engine not to replace Host in the HTTP headers.

If the box is empty, the FirePass controller replaces the host name on all URLs. For example, using the typical reverse-proxy operation, the Host value gets replaced, as shown in the following example:

Host: firepass.siterequest.com
(client to FirePass controller)

Host: company_server.siterequest.com
(FirePass controller to internal web application)

When you check the Preserve FirePass hostname when accessing Web Applications check box, the FirePass controller delivers the Host header to the internal web application without alteration, as Host: firepass.siterequest.com.

Configuring content processing for web applications

You can define Portal Access content processing functionality on the Content Processing screen. To access the screen, click Portal Access, expand Web Applications, and click Content Processing.

When sending connections through the proxy engine, the FirePass controller uses an advanced, full-content rewrite engine to modify the URLs and other links in the original HTML document. The modified path begins with f5-w-. For example, The FirePass controller rewrite engine converts the link shown in the following example to the string shown in the following result.

<a href='http://siterequest.com/...'>

<a href='https://firepass.siterequest.com/ f5-w-X8d676sba8c650337ebf0937652fd678ac8a7663628f8a7d9449c9/. '>

If a web site has very complex or poorly written code, it is possible that some links will not be re-written, or will be re-written incorrectly. Additionally, the FirePass controller may not always be able to fully parse and patch advanced JavaScript code, which could result in improper display and loss of functionality.

You can apply the content-processing features to address these conflicts.

Locating proxy conflicts

You can find the source of the problem by comparing a connection made directly between a client and the web application to a connection made through the FirePass controller.

The following tools are helpful in making this comparison:

Configuring processing scripts for content processing

You can use the Preprocessing Scripts screen for modifying web pages as they pass through the reverse proxy. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and then click the Preprocessing Scripts tab.

The FirePass controller can perform special-purpose processing of content passing through Web Applications, using SED-based scripts. You can create specialized SED scripts that modify intranet web pages to address issues related to the proxying of unusual or incorrectly formatted content.

Adding a SED script

You can use SED scripts to modify intranet web pages to handle issues related to proxying unusual or incorrectly formatted content. Here, you can specify a URL pattern and an accompanying SED script for processing content passing through Web Applications. You can specify a single URL match pattern list for each processing type. For example, you can specify response preprocessing, processing that occurs before patching; response postprocessing, processing that occurs after patching; or request processing, processing requests from a user before the FirePass controller sends it to the web site.

The FirePass controller processes URL content using the first match it finds in the list of defined entries (starting at the top of the list).

The first step in configuring content processing by adding a SED script is to create a favorite.

To add a favorite that uses a SED script

  1. In the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and then click the Preprocessing Scripts tab.
    The Preprocessing Scripts screen opens.
  2. Click the Add New Favorite link.
    The screen refreshes to reveal new options.
  3. In Processing script name, type the name of the favorite.
    This can be any string that can help you identify the specified content processing functionality.
  4. In URL match patterns, specify a comma-separated list of patterns to compare with incoming URLs. The FirePass controller processes matching URLs using the specified script.
    If the box is empty, the FirePass controller does not process content from any URL. You can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character, to specify the patterns, for example, http://*.siterequest.com/*
  5. In Content Type, specify the content-type HTTP header that the FirePass controller should process with the script.
    An empty field means that the FirePass controller processes text/* content types, for example, text/plain, text/html, and so on. For SED script processing, you can specify additional types, for example, application/xhtml+xml that the FirePass controller should process using the specified SED script. If a page to be matched does not have a defined Content Type, you can specify application/unknown.
  6. In Sed processing script, specify the SED script the FirePass controller should use for processing the web application request or response data.
    For example, if you specify s|HTTP://|http://|g the FirePass controller performs a global search for HTTP://, and replaces each instance it finds with a http:// string.
  7. You can use much more complex scripts, and include regular expressions, to search for and replace or modify content, and to correct HTML errors on pages.

    You can use the FP_ServiceAddr variable inside SED scripts. Processing replaces this variable with the FirePass controller name. You can also use content processing scripts to insert <FP_DO_NOT_TOUCH> and </FP_DO_NOT_TOUCH> tags around sections of code on pages that you do not want the rewrite engine to rewrite.

    Note: In certain cases, you must use the backslash character to escape forward slash characters in the SED script.
  8. From the Processing list, select where to apply the content processing script. You can apply the SED script to the user request or to the server response. If you choose the response, you can apply the script before or after the reverse proxy engine performs content patching. Options are:
    • Pre-process response data (before content patching): Applies the SED script to response data received from a web site before the content is patched by the reverse proxy engine. In most cases, you should select this default option of Pre-process response data (before content patching).
    • Post-process response data (after content patching): Applies the SED script on response data after the content is patched by web applications.
    • Process request data: Processes request data from a user before it is sent to the web site.
  9. Click the Add New button.

You can find more information about using SED scripts on the AskF5 web site by searching FirePass-controller-related Solutions.

Example 1 of using a SED script

In this example, we use a script to replace an applet. The problem the script is solving is that a page with a video streaming applet does not work as expected through Portal Access Web Applications.

The administrator used the tcpdump command to determine that the problem is that the applet does not rely on URLConnection for streaming, that instead, it uses sockets.

Note

The FirePass controller patches Java applets (when the option is enabled), even those that use sockets, so this example is for illustrative purposes only.

In this case, the administrator developed a SED-based content processing script to replace the applet with an image, using a different CGI for displaying still images, along with a piece of JavaScript to reload the image automatically. You can find the script in the section SED content processing script for example 1 , following.

In the source for the web application, HTML comments take the applet out of the context. Then, the script injects an image named noapplet following the </APPLET> tag, and provides the onload callback im_loaded. The script injects the im_loaded implementation preceding the </HEAD> tag, reloads the image immediately after the implementation loads, and adds a time-based query parameter to ensure that the browser does not cache the image.

The result is that the location that previously contained the non-working applet now shows a static image.

SED content processing script for example 1

This shows a SED script that performs content processing on a page that contains a video streaming applet that does not work in web applications.

s@</HEAD>@ <script>function im_loaded(){d = newDate;document.images['notapplet'].
src="/axis-cgi/jpg/image.cgi
?="+d.getMilliseconds();}</script></HEAD>@

s@<APPLET@<!--<APPLET@s@/APPLET>@/APPLET>--><img onload = 'im_loaded()'name=notapplet src='/axis-cgi/jpg/image.cgi' width='320'height='240'>@

Example 2 of using a SED script

In this example, we describe how to prevent the rewriting of certain URLs by the reverse-proxy engine. The problem the script is solving is that an intranet application dealing with XML data or XSL style sheets does not work properly.

The FirePass controller attempts to determine which links on HTML pages it should rewrite. However, the reverse proxy engine might not always correctly analyze XML or XSL data and pages that make extensive use of JavaScript. If you determine through analysis that proper operation requires the preservation of some links that are being rewritten, you can use a SED script to return content to its original condition.

The result is that the URLs that were previously rewritten are now returned to a usable state.

SED content processing script for example 2

The following section contains a SED script that performs content processing on a page that contains XML or XSL content that does not work in web applications.

To search for certain types of pages, you can specify a match pattern in URL match pattern, for example */pathnet/XSLTS/* Then in the SED processing script box, you can use a SED script such as s|/f5-w-[^/]*|//|g

In this case, the FirePass controller should process content after performing its patching, so from the Processing list on the Preprocessing Scripts screen, select Post-process response.

This script removes the f5-w- information that reverse proxy adds. In general, the page will work correctly after postprocessing, as long as the links on the page are to the same host (or are relative links).

Example 3 of using a SED script

You can also specify a slightly more complex SED script than the one described in Example 2 of using a SED script to remove rewriting from one particular link on a page, or to a more selective set of links. The following script requires a link containing /eerequest/ on the page to remove the f5-w- references.

/eerequest/ {

s|/f5-w-[^/]*|//|g

}

For more information, see the SED man page.

Testing content processing settings

You can test the content of a processed web page under Test Content Processing Settings on the Preprocessing Scripts screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and then click the Preprocessing Scripts tab.

Once you apply the SED scripts you want, you can use this functionality to preview a page's content as it would be delivered from the FirePass controller. To test content, in the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and click the Preprocessing Scripts tab.

When you specify a URL in the box and click the Test button in the Test Content Processing Settings section, the FirePass controller fetches and displays the HTML source that the FirePass controller delivers for the configured URL. When the processing testing mechanism finds and displays the page represented by the URL, the content also reflects any script processing and content cleaning results. You can also click a link, View processed page through Web Applications, to view how the page looks when presented to the end user.

If the page is a valid URL, the results box, labeled Original URL source, contains the page source. If the URL is not valid, the testing functionality returns the message Invalid URL entered or Error fetching URL source. You may also get the Error fetching URL source if the URL you are trying to fetch requires authentication. If that happens, you can specify the authentication you need by viewing the page and then trying the test again.

Troubleshooting web application failures

While there are a number of reasons that SED processing might fail on an application accessed through the FirePass controller, the most common reason is that a JavaScript tested the page's content and either the test failed, or the content did not match the script's expectations. If the content fails the JavaScript test, errors might be reported or the application could refuse to allow further operations.

Some common JavaScript tests perform the following functions:

  • Check the protocol of the URL to make sure it is http://
  • Check the URL to make sure its host name matches the server name sent in the JavaScript
  • Perform a checksum on the page and make sure it matches the original

JavaScript tests frequently fail when the site is accessed through the FirePass controller, because the FirePass controller modifies URLs to use the HTTPS protocol and to contain the host name of the FirePass controller.

You can use one of the following solutions to work around this issue:

  • Modify the application so that the tests allow for the changes made by the FirePass controller.
  • Use a content processing script to modify or remove the JavaScript test.
Note

You can use the Minimal Content Rewriting Bypass feature to avoid the full content rewrite typically needed with Web Applications. Configuring this feature helps deal with complex portal and web application content. For more information, see Configuring the Alternative Host/Port-based type of bypass .

Cleaning web application content

You can have the FirePass controller use the HTML Tidy open-source parser to reformat HTML content passing through Web Applications prior to content patching. This may be necessary for some sites to deal with proxying specially formatted HTML content.

Note

Content cleaning is a very processor-intensive operation. We recommend not enabling this feature except for debugging purposes, to help with troubleshooting content-rewrite issues.

You can specify a list of URLs under Web Applications Content Cleaning on the Preprocessing Scripts screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and then click the Preprocessing Scripts tab.

In the box under Web Applications Content Cleaning, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character, to specify URLs that you want the FirePass controller to process for content cleaning. An empty list means that the FirePass controller does not reformat content from any URL.

Note

The content-cleaning function cannot fix severe coding or content errors.

Configuring global settings for content processing

The FirePass controller rewrites URLs, JavaScript, and Java applets on all Portal Access web pages to resolve internal to external URLs.

You can use options on the Global Settings screen for changing the FirePass controller behavior for processing web pages as they pass through the Portal Access reverse-proxy engine.

Note

Configuration for most global settings requires a service restart.

To access the Global Settings screen, in the navigation pane, click Portal Access, expand Web Applications, click Content Processing, and then click the Global Settings tab.

Configuring enforce-user-agent strings on a per-host basis

The FirePass controller can present a specified User-Agent string to a particular web site instead of the actual browser's User-Agent. An alternative User-Agent string is useful in downgrading content if content patching errors are occurring.

You can also specify a per-host, user-agent string to use with content processing on the Global Settings screen. To access the screen, click Portal Access, expand Web Applications, click Content Processing, and click the Global Settings tab. This feature provides the following options:

  • Intranet Host
    Contains the URL for the intranet server that communicates with the FirePass controller. For example,
    server.siterequest.com.
  • Alternative User-Agent String
    Contains the string the configured intranet host sends to the FirePass controller. The specified user-agent string causes the intranet host to impersonate the specified browser by sending the associated user-agent string.
  • List of browsers
    Contains a list of the common browsers. Selecting a browser from this list populates the associated user-agent-string box, which you can modify, if you wish.

For more information about user-agent strings, see Specifying user-agent strings .

Preventing session update

Some web applications pages loaded through Web Applications connections contain JavaScript code that regularly refreshes the page or sends HTTP requests, regardless of user activity or inactivity. A session that is abandoned at such a site does not time out, because it appears to be active. You can use the session update feature to prevent these sessions from remaining active indefinitely, and you can specify sites whose session activity is to be disregarded for purposes of computing idle time.

In the list, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character, to specify URLs that should not update the FirePass controller session. An empty list means all URLs update a session.

Configuring "Home/Logout" tab injection

The FirePass controller inserts into HTML pages a small amount of HTML that contains the JavaScript that displays the Home and Logout navigation links. In the box in the Home/Logout tab injection section, type the full URL for the page into which you do not want the FirePass controller to insert JavaScript. Pages generated without the JavaScript contain no Home or Logout links.

Preventing Java byte code rewriting

You can use the Java Byte Code Rewriting feature to suspend rewriting of Java classes, or .jar, .cab, or .zip archives for specified match patterns.

By default, the FirePass controller handles Java byte code so that all HTTP, HTTPS, and socket-based network communication is sent to the FirePass controller through secure HTTPS tunneling. This approach provides a secure and portable proxy mechanism for web-based, client-server applications that utilize client Java applets.

The reverse proxy rewriting engine supports most network-related classes and methods. As long as the Java applet uses TCP, and the network traffic is initiated from the client, the applet is supported. If the applet contains server-initiated connections through the use of the ServerSocket class, reverse proxy cannot process the applet. Reverse proxy rewrites and re-signs only those Java applets that require patching.

Since reverse proxy modifies the byte code, the final applet delivered to the end-user is different from the original applet. The FirePass controller re-signs the applet with its own signing certificate. In some cases, this can result in a browser warning being displayed to the client.

To prevent Java modification problems with reverse proxy, ensure that all network-related classes conform to the Sun Java specification. The rewriting functionality might not support class files written in a proprietary format. If the class files do not contain standard byte code, then reverse proxy cannot modify the content.

The FirePass controller caches rewritten Java applet for the next client request. Because of the caching operation, if your application uses Java applets, make sure to check the Enable Dynamic Cache on FirePass. Generally improves WebApplications performance check box on the Portal Access : Web Applications : Caching and Compression screen.

In the box in the Java Byte Code Rewriting section, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character, to specify URLs for which the FirePass controller should not rewrite classes or .jar, .cab, or .zip archives. An empty list means the FirePass controller rewrites all classes or .jar, .cab, or .zip archives. For more information about the process of rewriting, see Configuring web applications for minimal rewriting .

Understanding the Flash rewriting support

The rewrite engine fully supports and rewrites Flash files, .swf, and Flash ActionScript. Because of specific Flash file formatting, web application connections through Portal Access cannot be configured to stream Flash files. Instead, the FirePass controller fully downloads the Flash files from the server, rewrites them, and then sends them to the user. If you plan to deliver large Flash files, for example, Flash files containing a video stream, users might experience a significant delay before the file displays the stream.

Configuring OWA, iNotes, and other specific web applications

For effective access, some web applications, such as Microsoft Outlook Web Access and IBM iNotes, require a special access mode. In the Feature Web Applications section of the Content Processing screen, you can specify the host name or comma-separated list of host names for which you want to switch to special mode.

For each host you specify, the FirePass controller uses the optimal caching and compression settings, overriding the global settings specified on the Portal Access : Caching and Compression screen. You can also check Automatically detect hosts for OWA and iNotes to have the FirePass controller evaluate the hosts and switch to special mode automatically. For more information, see Configuring caching and compression .

Configuring web applications global settings

You can configure cookie pass-through using the box in the Web Applications Global Settings area. You might want to allow cookies to pass from the client to specific web sites. With the setting, you can specify a comma-separated list of patterns to compare with incoming URLs. If there is no pattern, the FirePass controller blocks cookie pass-through for all URLs. You can type an asterisk ( * ) to allow cookies to pass through for all URLs. You can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character.

*://msnbc.msn.com*

*://www.yahoo.com*

*://www.ibm.com*

If your web site includes JavaScript that does any client-side cookie manipulation, you must specify a pattern that allows the cookie to pass through to the client browser. For security reasons, cookies are not passed through by default. When troubleshooting or testing initial support for a web portal or application, check the Do not block cookies at FirePass, pass them to the browser for specified URL patterns check box, and type an asterisk ( * ) in the box. This configuration instructs the FirePass controller to pass all cookies through to the client browser. Then after testing, you can restrict the cookies being passed.

Configuring Content Processing Global Settings requires a service restart, and also provides the following options:

  • Compatibility mode (enable legacy version of Web Applications handler)
    Allows you to continue to use the web applications routines that shipped with earlier versions of the FirePass controller. Select this option only if you have developed SED scripts tuned to the specific requirements of your intranet, and you are satisfied with the functionality of Portal Access Web Applications (formerly MyIntranet).
  • Automatically patch Java Applets
    Intercepts the Java applet and unwraps it if it is a .jar, .cab, or a .zip archive. Next, each class is searched, and when the applet-rewrite functionality finds an Applet, JApplet, Socket, or URL, or InetAddress class, it rewrites it accordingly, along with rewriting its inheritance definitions. Then, the applet is repacked and resigned, if necessary, using the F5 signing certificate. The FirePass controller then passes the transformed applets to the web client, and caches them, if the dynamic cache option is set.
  • By specifying URLs under Java Byte Code Rewriting on the Content Processing Global Settings screen, you can suspend rewriting for specific URLs. For more information, see Preventing Java byte code rewriting and Configuring the Alternative Host/Port-based type of bypass .

  • Block non-HTML data
    Prevents download of files such as .doc and .pdf from being downloaded from web applications. Only HTML content is allowed to pass through the proxy.
  • Remedy IE gzip compression bug by adding leading 2 kilobytes of whitespace to HTML pages
    Compensates for an Internet Explorer bug that strips off the leading two kilobytes of server messages when it accesses a web page compressed using gzip. It does so by adding 2K of leading, padding spaces. Selecting this option does not affect the appearance of the application on other browsers. Select this option if you enable compression on the Caching and Compression screen, and if any of your users might connect using an unpatched version of Internet Explorer 6. To access the Caching and Compression screen, in the navigation pane, click Portal Access, expand Web Applications, and click Caching and Compression.
  • Do not block cookies at FirePass, pass them to the browser for specified URL patterns
    Allows the FirePass controller to pass cookies to the user's web browser. This option is useful for supporting web applications that use JavaScript in the browser to manipulate cookies. We recommend that you specify a pattern or list of patterns that allows cookie pass-through only for web applications with URLs that match the pattern.
  • Automatically add websites that require client side cookie manipulation
    Adds to the list the web sites that require client-side cookie manipulation when the FirePass controller encounters them. By default, this feature is enabled. F5 Networks strongly recommend disabling this option once the learning phase is over.
  • Obfuscate cleartext cookies
    Obscures cookies sent in clear text format so users cannot read them. By default, this feature is enabled.
  • Translate hidden form parameters if they look like URLs
    Select this option to translate hidden form parameters if they appear as a URL, such as http://XXX. This option is useful when you have JavaScript that manipulates hidden form parameters. F5 Networks recommends limiting the effect of this option by specifying a list of URL patterns to match against. In the list, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. An empty list means all URLs are patched.

Configuring caching and compression

You can define caching and compression functionality on the Caching and Compression screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, and click Caching and Compression. Using options on this screen, you can configure settings that determine caching and compression of files sent from the FirePass controller to remote user's web browsers, as well as the transmission of cookies and file downloads from intranet servers to users.

When using dynamic cache, the FirePass controller does not distinguish between static or dynamic content. It distinguishes between objects that the remote server designates as those that the FirePass controller may cache and those it cannot cache. The remote server indicates the object's ability to be cached by setting the appropriate cache control in the response's HTTP headers. If the remote server indicates that an object may be cached, and this option is checked, the FirePass controller caches the object in its dynamic cache.

Note

You should not enable dynamic cache when you are using group-based VLAN to access hosts with the same host name or IP address on different VLANs.

The FirePass controller validates the currentness of cached objects by sending an if-modified-since request-header to the remote server and receiving either a (not modified) response or the modified object. This ensures that objects in the cache remain fresh.

If client browsers request both compressed (gzip) and non-compressed objects simultaneously, the FirePass controller stores each type into the cache for maximum performance.

Caching errors do not affect web application functionality. When the FirePass controller cannot cache an object for any reason, the FirePass controller simply sends the object to the user. In other words, operation is the same as if caching is turned off.

You can determine whether the FirePass controller has presented content to a client from the cache, by checking the response headers in pages returned to the browser for the presence of the following string:

X-Cache: HIT from your.firepass.hostname

Setting caching and compression

The Caching and Compression screen provides the following caching and compression options:

  • Enable Dynamic Cache on FirePass. Generally improves WebApplications performance:
    Caches content to prevent the need for repeated rewriting. You can also clear the dynamic cache by clicking the Clear Cache button.
  • Enable Compression. Saves bandwidth, at the expense of server resources:
    Uses the gzip compression utility to substantially reduce the size of generated content. The most noticeable improvement in speed occur when accessing pages that contain big Java classes or other large elements (images, scripts, and so on), but not when accessing pages that reference Java packages (.jar files), class archives (.zip files), or compressed images (.jpg, .png, and Compressed TIFF files).
  • For iNotes and other Java-based web mail packages, enabling compression vastly improves the speed in which pages are loaded. You can also specify a comma-separated list of URLs for the FirePass controller not to compress, even when compression is turned on. In the list, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. Turning on gzip compression reduces FirePass controller resources, which can affect scalability.

Configuring global caching and compression settings

You can choose from several global caching and compression settings. Each global setting caching option has an inherent trade-off between web application performance and security. The global settings you can select include:

  • Don't cache anything, except Style Sheets and JavaScript includes
    Provides a good compromise between security and performance. By default, web applications mark every screen as non-cacheable with the exception of JavaScript and style-sheet includes. The reason is that typically, these sizeable includes are designed with caching in mind. When caching is turned off, a high percentage of the traffic consists of these includes. Given that the content of these includes is rarely confidential, they are not marked as non-cacheable by default.
  • Don't cache anything, except for images, style sheets and JavaScript includes
    Results in better performance than the first option, but less security.
  • Cache nothing at the remote browser
    Impacts performance more than the first two options, but provides better security. OWA and iNotes require some caching, so select another option when you are serving OWA and iNotes application pages.
  • Don't enforce no-cache
    Provides the best performance of all options, but the least amount of security. Use this option only with trusted terminals such as home computers. This option caches according to the web browser settings. For this setting, you can specify a comma-separated list of URLs for which the FirePass controller should ignore no-cache. If there is no list specified, no URLs are exempt from no-cache. When you specify the list, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. You would use this option in cases where the no-cache header causes problems.
For example, if Cache nothing at the remote browser is set, when proxying HTTP content, The FirePass controller automatically sets a Cache-Control: no-cache header. The Cache-Control: no-cache header can cause problems for some XML applications, mostly on Internet Explorer browsers, because the client does not retrieve XSL files that are not cacheable. When this occurs, the browser displays an error indicating that the XSL file is not cacheable or is not available. You can work around this issue by specifying http://*.siterequest.com/*.xsl in the box so that the FirePass controller does not insert the cache control headers into files that end with an .xsl extension.

Configuring intranet webtop options

You can specify an intranet web page to replace the webtop for a specific master group on the Intranet Webtops screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, and click Intranet Webtops. If you elect to use a web page, no other access functions are available. Configured intranet webtops apply to all users in a master group.

You would configure this feature when you want to replace the standard FirePass controller webtop with an internal intranet portal front-page. An intranet webtop completely replaces the standard FirePass controller webtop, which typically displays administrator and user-defined favorites.

Note

In addition, you can create a custom replacement page that contains JavaScript code that starts FirePass controller favorites. You can store the replacement webtop page on the FirePass controller, using WebDAV, or on an external server. For more information and code samples, see the online help on the Device Management : Customization screen under Advanced WebDAV customization.

Intranet webtops have the following properties and elements.

  • Request
    Indicates whether to transmit the URL and its accompanying arguments in GET, or in a POST request. Using POST is a more secure way to provide a user name and password for logging on to an intranet site, because the variables are not visible on the URL line of the browser for someone to see.
  • URL
    Indicates the intranet web server that serves the application. For example:
    http://server.siterequest.com/index.html
  • URL variables
    Contains variables to be either appended or sent in a GET command to the specified URL. For more information and examples, see Working with URL variables .
  • Enabled
    Indicates whether the web application serves the specified page as the webtop for users in the associated group. For additional information on how to use a page as a customized webtop and run FirePass favorites, see the online help on the Device Management : Customization screen.

Preserving page content

The FirePass controller supports the ability to present favorites on a custom portal page located on the FirePass controller, using WebDAV, or from a custom portal page stored on one of your own internal servers. You can use the portal page as an alternative to the FirePass controller webtop.

For more information about WebDAV functionality, search for WebDAV in the online help.

Once you have the portal page, you can configure it as a FirePass controller webtop or define a reverse-proxy favorite. Then, users who log on to the FirePass controller using that portal page can start favorites, such as AppTunnels or Network Access connections, by clicking portal links.

If you have HTML, JavaScript, or CSS content that you want to preserve, you can do so by placing a <FP_DO_NOT_TOUCH> tag at the beginning and a </FP_DO_NOT_TOUCH> tag at the end of the code. The tags prevent the code inside them from being rewritten.

Note

In earlier versions, the online help for the Device Management : Customization screen in the WebDAV section, contained sample code that you could use for this purpose. The new reverse-proxy engine rewrites some of the content so that pages using the sample code no longer work. If you are using the sample code, you can also use these tags to prevent the rewriting.

Configuring proxy options

You can specify proxy settings on the Proxies screen. To access the screen, in the navigation pane, click Portal Access, expand Web Applications, and then click Proxies. The FirePass controller can use HTTP and HTTPS proxies for web access. The Set up optional HTTP and SSL proxies for public Internet access section provides options for proxies for HTTP, SSL, or both. In addition, you can elect to use basic proxy authorization, specifying a user name and password to the proxy.

The FirePass controller web-access mechanism requires a proxy if there is no outbound access to the Internet. Also, Web Applications functionality might require proxy settings if the FirePass controller does not have direct access to the web servers on the local network.

Proxy settings consist of an address and port number. You can also specify a comma-separated list of addresses or subnets to which the FirePass controller should allow direct access, that is, not through the proxy server.

When you check Enable HTTP proxy or Enable SSL proxy and click Update and Test, the FirePass controller presents Address and Port boxes for each type of proxy.You can also specify a list of the IP addresses to which the FirePass controller should allow direct access rather than through the proxy.

Note

The FirePass controller makes sure it can connect to a specified proxy before committing the settings. Because of this, testing a new configuration might take a minute or so if the settings are incorrect.

In the No proxy for the following addresses (comma separated) box, you can specify the leading digits for IP addresses for resources to which you want the FirePass controller to allow direct access. Use commas to separate these addresses. You can use the X[.Y[.Z]] format for IP address templates, for example, 19 or 192 or 192.168 or 192.168.200 or 192.168.200.12. If there is no list of addresses, the FirePass controller uses a proxy for all resource access.

Note

The FirePass controller does not support specifying a subnet mask using 24-bit (CIDR) addresses for the proxy exclusion list.

Configuring Windows files

You can configure Windows Files favorites that give users access to files in network shared Windows folders. Once connected, users can view, download, move, rename, and delete files. You can also specify global settings that apply to all Windows files connections through Portal Access.

Configuring Windows Files favorites

You can use the Resources screen to configure favorites for the user's webtop. To access the Resources screen, in the navigation pane, click Portal Access, and click Windows Files. To set other policies and behaviors, you can use the Master Group Settings screen. For more information on master group settings, see the online help.

When you click Add new favorite on the Resources screen, the screen reveals additional options.

  • Type
    Indicates whether the link is a new configuration (Favorite) or a pointer to an existing one in another master group (Alias). Alias is available as an option only when there are Portal Access favorites configured in another master group.
  • Name
    Contains the name for the intranet site that you are defining as a favorite. This is the name the user sees on the webtop. The string you specify can be any name; field format is not limited. For example:
    Project management & "dailies"
  • Path
    Contains the Microsoft Universal Naming Convention (UNC) string. A UNC name typically references a shared folder and file accessible over a network rather than a drive letter and path. You can include path arguments such as %username% to substitute for user's logon and %group% to substitute for the user's master group name. For example \\publicsrv.eng.siterequest.com
  • Endpoint protection required
    Provides a list of Protected Configurations defined on the Users : Endpoint Security : Protected Configurations screen. If the user's endpoint protection does not satisfy the defined condition, the system prevents access to the specified resource. For more information about protected configurations, see Creating protected configurations, on page 3-21 .
Important

The FirePass controller does not verify paths, so make sure the path is specified correctly.

Configuring Windows Files master group settings

You can specify options that apply to all Windows Files users on the Master Group Settings screen. To access the Master Group Settings screen. in the navigation pane, click Portal Access, expand Windows Files, and click Master Group Settings.

Important

To support master group-based policy routing for Windows Files, you must configure a valid WINS server on the Master Group Settings screen. The FirePass controller uses the WINS server for performing NetBIOS name resolution when master group-based policy routing is enabled.

The Master Group Settings screen provides a set of options that govern the operation of Windows Files functionality through Portal Access connections.

  • Limit Windows Files Access to Favorites only (for Extranets, partner and customer access, etc.)
    Prevents master group members from browsing outside of folders specified in favorites.
  • Enable file upload
    Controls the uploading files for users in the associated master group. To specify the maximum file upload size, and set antivirus checks for downloaded files, see Configuring buffer overflow protection .
  • WINS Address
    This setting is necessary for multi-segment networks, when the FirePass controller and the LAN are on different network segments, or when the LAN itself has multiple segments. You must specify WINS Address for networks structured as multi-segment LAN environments. If the routing table assigned to the master group is different from main, you should configure WINS Address to handle NetBIOS name resolution.
  • Default Domain/Workgroup
    Contains the name of the Windows domain or workgroup where the FirePass controller resides. You must specify Default Domain/Workgroup when the FirePass controller unit address is not on the target LAN. We also recommend that you define the Default Domain/Workgroup setting for multi-segment LAN environments.
  • Auto-login to Windows File shares using FirePass user login credentials
    Directs the FirePass controller to use the user's FirePass controller logon name and password to automatically log on to Windows file servers and shares.
  • Click to change the status and/or webifyer position on the webtop
    Opens the User Experience screen for the associated master group, where you can change the location and operation of favorites on the user's webtop. For more information, see the online help for the screen.

Configuring Mobile E-Mail

You can configure the Portal Access : Mobile E-Mail feature to enable users to access email from any client computer. The Mobile E-Mail feature provides very lightweight access to multiple Post Office Protocol (POP) and Internet Message Access Protocol (IMAP) mailboxes and address books, using data from the FirePass controller's internal database or from an LDAP directory. You can configure different Mobile E-Mail settings for each master group. There are several options for configuring logon options:

  • Allowing the user to enter a logon name and password directly
  • Using the FirePass database for logon information
  • Querying an LDAP server to retrieve logon credentials.

Users can use any web browser to access the mailbox. In particular, users who are away from the office can use browsers on mobile devices to quickly browse through emails.

A user can configure any number of email accounts, but you can limit access to only the corporate account you create, by checking the Limit E-Mail Access to Corporate mail account only (for Extranets, partner and customer access, etc.) check box. This limitation is useful for users logging on from extranets, and for partner and customer access. You can also disable the downloading of attachments, which can help prevent introduction of untrusted material onto the client's machine.

Configuring Mobile E-Mail includes the following options:

  • Master Group
    Presents a list of all master groups. Select the one you want to configure.
  • Enable corporate mail account
    Provides access to the user's corporate email account.
  • Account name
    Represents the string users see as the name of the link on their webtop. Corporate Mail is the default.
  • Mail server
    Represents the mail server name or IP address. For example, mailserver.siterequest.com.
  • Type
    Presents the support options: POP and IMAP. Select the one you want.
  • IMAP Folders
    Represents the comma-separated list of folders that you want users to see, if you are using an IMAP mail server. This list prevents the confusion created by mail servers that display items that are not email messages, such as contacts or calendars, as empty email folders. Users can also add to the list themselves.
  • Login Information
    Presents a list of options for logging on to Mobile E-Mail.
    • User supplies display and login information during first login: Gets email information from users when they attempt to use Mobile E-Mail for the first time.
    • Use FirePass database for display and login information: Retrieves email address, logon name, and password from the FirePass controller internal database.
    • Use LDAP query for mail server, display, and login information: Queries an LDAP server to dynamically retrieve each user's email information. When you choose this option, you must configure the LDAP query. For descriptions of the query options, see Configuring the LDAP query , following.
  • Outgoing Mail server
    Represents the outgoing email server name or IP address for the FirePass controller to use when sending email. If you do not specify a server, the FirePass controller uses the settings specified in Primary server on the Device Management : Configuration : SMTP Server screen.

When you finish configuring all of the options, click the Update button.

Important

If you use LDAP authentication over SSL, specify a host name, and be sure that the host name exactly matches the name on your LDAP server's certificate.

Configuring the LDAP query

When you select the Use LDAP query for mail server, display, and login information option on the Login information list in the Corporate email account section of the Mobile E-Mail screen, you must also specify the following options:

  • LDAP server
    Represents the IP address or host name of the LDAP server.
  • Port
    Represents an LDAP port, such as 389.
  • Use SSL connection
    Provides support for using SSL for the connection.
  • Protocol version
    Presents a list of the LDAP protocol version (2 or 3) for you to select. The default protocol version is 3. If you use Active Directory, you must use version 3.
  • Bind DN
    Represents the distinguished name the FirePass controller should use to bind to the LDAP directory.
  • Bind password
    Represents the password for the BIND DN. You can leave the box empty to require no authentication.
  • Search base
    Indicates the level of the entry in the tree to be used for the search, for example:
    cn=Recipients,ou=Exchange,o=FirePass
  • Filter template
    Contains the string to use when searching for the user. You can use %s in the filter expression to have the FirePass controller insert a user logon, for example:
    (&(objectclass=person)(cn=*%s*))
  • Attribute for mail server
    Contains the attribute in the LDAP schema that stores the mail server name.
  • Attributes for user's display name, email address, and login
    Contains the attributes in the LDAP schema that stores the associated information.
  • Attribute for mail server
    Represents the attribute in the LDAP schema that stores the mail server name.
  • Attribute for user's display name
    Represents the attribute in the LDAP schema that stores the name that indicates who sent the email.
  • Attribute for user's email address
    Represents the attribute in the LDAP schema that stores the originating address of the email.
  • Attribute for user's logon
    Represents the attribute in the LDAP schema that stores the name the user types when logging on to the email server.

When you finish configuring all of the options, click the Update button.

Configuring LDAP as the email address source

By default, Mobile E-Mail uses a list of users from the FirePass controller database as an address book. You can choose instead to use an LDAP server as the email address source. When you choose Use LDAP server to obtain addresses, you must also configure the following options:

  • LDAP server
    Represents the IP address or host name of the LDAP server.
  • Port
    Represents an LDAP port, such as 389.
  • Use SSL connection
    Provides support for using SSL for the connection.
  • Protocol version
    Presents a list of the LDAP protocol version (2 or 3) for you to select. The default protocol version is 3. If you use Active Directory, you must use version 3.
  • Bind DN
    Represents the distinguished name the FirePass controller should use to bind to the LDAP directory.
  • Bind password
    Represents the password for the BIND DN. You can leave the box empty to require no authentication.
  • Search base
    Indicates the level of the entry in the tree to be used for the search, for example:
    cn=Recipients,ou=Exchange,o=FirePass
  • Filter template
    Contains the string to use when searching for the user. You can use %s in the filter expression to have the FirePass controller insert a user logon, for example:
    (&(objectclass=person)(cn=*%s*))
  • Name attribute
    Represents the attribute in the LDAP scheme that stores the user's name.
  • Address attribute
    Represents the attribute in the LDAP scheme that stores the user's email address, which is typically mail.

When you finish configuring all of the options, click the Update button.

Disabling email attachments

By default, email attachment downloads are enabled. You can disable downloads by checking the Disable attachment download check box. This can help you protect remote client computers by preventing the introduction of content that may contain viruses.

Changing where Mobile E-Mail links appear on the webtop

You can customize the location of favorites on the user's webtop. To access the customization page, click the Click to change the status and/or webifyer position on the webtop link on the user's home page webtop.

Configuring content inspection

You can configure several kinds of functionality to provide content inspection. These are provided as tabs on the Content Inspection screen. To access the screen, in the navigation pane, click Portal Access, and click Content Inspection, and then click one of the tabs.

  • XSS scripting
    Represents cross site scripting, a type of attack that gathers data from a user for unauthorized use of security vulnerabilities in web applications. You can use options on this screen to aid in preventing such attacks. For more information, see Configuring cross site scripting security , following.
  • SQL injection
    Represents the unauthorized process of introducing SQL commands in the command string to gather database information. You can use options on this screen to test for such activity. For more information, see Configuring SQL injection scanning .
  • Buffer overflow
    Represents a security vulnerability that, when exploited, allows for running unauthorized code on the user's computer. You can use options on this screen to reduce the possibility of this type of activity. For more information, see Configuring buffer overflow protection .
  • Antivirus
    Represents the activity of detecting and preventing the introduction of viruses onto the user's computer. You can use options on this screen to configure virus scanning and to check uploaded files for viruses. For more information, see Configuring anti-virus scanning of uploaded files .

Configuring cross site scripting security

You can use the XSS scripting screen to specify cross site scripting (also called CSS or XSS). To access the screen, in the navigation pane, click Portal Access, click Content Inspection, and then click the XSS scripting tab.

The FirePass controller aids in preventing cross site scripting attacks from vulnerable web servers. This is done by scanning URL arguments and form POST data sent by users through Web Applications, and blocking the request if it looks suspicious.

Note

The FirePass controller user webtop and administrative console interfaces are already protected against cross site scripting attacks.

A web site may inadvertently include malicious HTML tags or script in a dynamically generated web page, based on unvalidated input from untrustworthy sources. This can happen when a web server does not adequately ensure that generated pages are sufficiently encoded to prevent unintended execution of scripts, and when input is not screened to prevent malicious HTML from being presented to the user.

This vulnerability is used as the basis for cross site scripting attacks, and can occur when a user relies on an untrustworthy source of information, such as an external untrusted web site link or a link in an email message. For example, an attacker may construct a malicious link such as:

<A HREF="http://siterequest.com/comment.cgi?mycomment=<SCRIPT>malicious code</SCRIPT>"> Click Here</A>

When a user clicks this link, the URL sent to siterequest.com includes malicious code. If the web server returns to the user a page that includes the value of mycomment, that is, if the web server does not properly filter user input or generated output, a vulnerable client might be able to execute the malicious code.

Scanning for suspicious characters

Options in the Restricting web site input to allowed character set section instruct the FirePass controller to scan user input data for suspicious characters such as less than ( < ) and greater than ( > ), and their URL-encoded equivalents of %3c and %3d. The FirePass controller bases the definition for suspicious characters upon a defined allowed character set.

The default match pattern is:

'[[:space:]+]*(;|or|union|select|insert|update|delete|drop|exec|having|
shutdown|xp_).*--

If the operation detects any suspicious characters, the FirePass controller blocks the user's request.

The FirePass controller provides the following options for restricting input to an allowed character set:

  • Scan URL parameters for restricted characters
    Inspects user input data in HTTP GET for suspicious characters within URL arguments.
  • Scan form POST data for restricted characters
    Inspects user input data within URL-encoded form POST data for suspicious characters.
  • User defined allowed character set (advanced)
    Provides an area for defining your own character set to use for scanning URL arguments and form POST data. Checking this option populates the box with the default list of characters, URL-encoded according to RFC 1738, which you can modify.

Scanning for embedded script code

Options in Scanning web site input for embedded script code instruct the FirePass controller to scan user input data for suspicious strings such as <SCRIPT and javascript: and their URL-encoded equivalents. The FirePass controller bases the definition of suspicious strings on a defined script search element list. If the scan detects any suspicious active elements, the FirePass controller blocks the user's request.

The FirePass controller provides the following options for scanning for embedded code:

  • Scan URL parameters for embedded script code
    Inspects user input data for active elements such as scripts within URL arguments.
  • Scan form POST data for embedded script code
    Inspects user input data within URL-encoded form POST data for active elements, such as scripts.
  • User defined script search elements (advanced)
    Provides an area for defining your own search elements. For example, you can modify the active element set of strings used for scanning of URL arguments and form POST data. Checking this option opens a box containing the default list of elements. You can modify this value or define your own.
  • <script <object <applet <embed <form javascript: vbscript: mocha: livescript: about: onload= onmouseover= text/javascript script> &{ url( expression(

Excluding sites from XSS scanning

You can also specify a comma-separated list of URLs to exempt from scanning operations. In the Web site exceptions list section, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. If the box is empty, it means that the FirePass controller scans requests to all sites. For example, if a particular intranet web site supports entering HTML tags, you should exclude this site from URL argument and form POST data scanning.

Configuring SQL injection scanning

You can use the SQL injection screen to specify virus scanning and database update options. To access the screen, in the navigation pane, click Portal Access, click Content Inspection, and then click the SQL injection tab.

SQL injection exposures allow attackers to modify calls to backend databases by adding to or manipulating SQL statements. To exploit a SQL injection flaw, the attacker embeds malicious SQL commands into the content of a parameter intended to be part of an SQL call. Consequences can range from trivial to severe.

The web application is responsible for detecting and blocking these attacks. However, the FirePass controller offers additional lines of perimeter defense against injection attacks initiated in web applications accessed through Portal Access.

You can:

  • Filter input URL parameters and form POST data for suspicious characters
  • Block requests with suspicious extended content.

Filtering for suspicious characters

Options in Filtering suspicious web site input instruct the FirePass controller to scan and filter user input data for suspicious characters such as apostrophe ( ' ) , number sign ( # ), double-dashes ( -- ), and semi-colons ( ; ) and their URL-encoded equivalents %27, %23, and %3b. (There is no encoding for double-dashes.) Because valid web site input can contain these characters, you might want to limit the web site match list or only enable the more-specific blocking options in Blocking suspicious web site input , following.

The default match pattern is:

'[[:space:]+]*(;|or|union|select|insert|update|delete|drop|exec|having|
shutdown|xp_).*--

If the parser detects any of these characters, it removes the character from the input string. It passes the rest of the string through to the application.

The FirePass controller provides the following options for filtering for suspicious characters:

  • Scan/filter URL parameters for suspicious characters
    Inspects URL variables to determine the presence of suspicious characters.
  • Scan/filter form POST data for suspicious characters
    Inspects form POST data to determine the presence of suspicious characters.
  • User defined block match regular expression (advanced)
    Enables customization of the regular expression used in the filtering operation. When you check this option, you can then modify the text using standard regular expression (regex) syntax. You can restore the default match pattern by clearing the option.
Note

This technique can prevent many attacks, but it also can result in many false positives, and could alter valid input. For example, the name O'Hara would be changed to OHara, and fail to match a valid record.

Blocking suspicious web site input

The blocking option performs a more sophisticated match for particular types of SQL injection attacks, by identifying strings with complex combinations. When the parser finds a match, it displays a warning and blocks the page. The FirePass controller adds a warning message to the FirePass System Log.

The default match pattern is:

'[[:space:]+]*(;|or|union|select|insert|update|delete|drop|exec|having|
shutdown|xp_).*--

You can view and customize the default pattern by checking the User defined block match regular expression (advanced) check box. You can then modify the text using standard regular expression (regex) syntax. You can restore the default match pattern by clearing the check box.

Excluding sites from SQL injection scanning

You can also specify a comma-separated list of URLs to exempt from scanning operations. In the Web site exceptions list section, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. If you select SQL injection filtering or blocking and you leave this list empty, it means that the FirePass controller scans all sites.

Configuring buffer overflow protection

You can use the Buffer overflow screen to specify virus scanning and database update options. To access the screen, in the navigation pane, click Portal Access, click Content Inspection, and then click the Buffer overflow tab.

A buffer overflow attack is an attempt to corrupt the execution stack of a web application by sending input that exceeds the length of the application's data buffer. By sending carefully crafted input to a web application, an attacker could cause the web application to execute arbitrary code, effectively taking over the machine. Even if the input string does not take over the target system, an attacker can use a buffer overflow as a denial-of-service attack.

Buffer overflow attacks exploit inputs of several types.

  • Files uploaded using the Windows or UNIX file access features
  • Form POST data input to web applications
  • GET query strings input to web applications

Web applications, web servers, and the services they use all can contain buffer overflow vulnerabilities. The best defense is to restrict the length of any attempted input string to the appropriate maximum for the application.

While it is the responsibility of the application to parse input, you can specify maximum levels for your environment, providing an outer perimeter of defense against exploits such as these.

The FirePass controller provides the following options for applying buffer overflow protection:

  • Restrict maximum upload size (32-1024 Mb)
    Constrains files that the user uploads to a specific size. The default value is 32 MB.
  • Restrict maximum length of a GET query string
    Constrains the request string to the maximum specified. The default value is 2048 bytes.
  • Restrict maximum length of POST data
    Constrains the response string to the maximum specified. The default value is 16384 bytes.

If you scheck the Restrict maximum length of a GET query string check box or the Restrict maximum length of POST data check box, you can also specify a comma-separated list of URLs to exclude from buffer overflow checks. In the web site exceptions box, you can use the wildcard characters asterisk ( * ), which represents many characters, and question mark ( ? ), which represents a single character. If you specify buffer overflow options and you leave this list empty, it means that the FirePass controller checks input to all sites accessed through Portal Access.

Configuring anti-virus scanning of uploaded files

You can use the Antivirus screen to configure Portal Access to check uploaded files for virus infections. To access the screen. in the navigation pane, click Portal Access, click Content Inspection, and click the Antivirus tab. When the antivirus feature is active, it scans files that are uploaded using any of the following Portal Access functions:

  • Windows Files
  • Web Applications
  • Mobile E-Mail

The FirePass controller provides the following options for checking uploaded files for viruses:

  • Disable virus scanning
    Does not perform virus scanning of uploaded files. We recommend that you only choose this option if you are sure that you have another service performing virus scanning.
  • Enable ICAP client
    Instructs the FirePass controller to act as an Internet Content Adaptation Protocol (ICAP) client and use it for inspection using the response modification mode. For more information, see Enabling the ICAP client , following.
  • Enable standalone virus scanner
    Activates scanning using the standalone virus scanner, the Open Source Clam Antivirus running locally on the FirePass controller. For more information, see Enabling the standalone virus scanner , following.

Enabling the ICAP client

ICAP is an open standard for Internet proxy servers to communicate with content servers. If your corporate antivirus protection is based on an antivirus service that has ICAP capability, the FirePass controller can use an ICAP client for upload inspection. When you select Enable ICAP Client and click Update, the screen reveals additional options, in which you can specify the host name, IP address, or path and port of the ICAP server.

You specify the path and port of the ICAP server using the following format

[icap: // ]<domain-name > [<:port >][/ path]

Following are some examples of how to specify the path and port of the ICAP server:

  • siterequest_domain.siterequest.com: Specifies the domain name.
  • siterequest_domain.siterequest.com:1345: Specifies the domain name and port.
  • siterequest_domain.siterequest.com:1345/avscan: Specifies the domain name, port, and path.
  • siterequest_domain.siterequest.com/avscan: Specifies the domain name and path.
  • icap://siterequest_domain.siterequest.com:1345/avscan: Specifies the ICAP protocol, domain name, port, and path.

Enabling the standalone virus scanner

You can use the default virus scanner, Clam AntiVirus, to detect viruses in uploaded files. When you select Enable Standalone Virus Scanner and click Update, the screen reveals additional options.

In the Virus DataBase Update section, you can specify how to update the virus scanning files. You can update the Clam AntiVirus database manually, by periodically uploading database files, or automatically, by a process that runs on the FirePass controller to periodically checks the Clam AntiVirus site for database updates.

The Virus Database section shows the most recent updates for the Clam AntiVirus database.

Configuring for manual update

Clam AntiVirus stores virus information in two files: main.cvd and daily.cvd. These are available for download from the following sources: http://database.clamav.net/daily.cvd http://database.clamav.net/main.cvd.

If you are using the manual update method, download these files to your computer, and then upload them to the FirePass controller, using the Browse button to locate the file.

Configuring for automatic update

When you select Automatic update and click Update, the FirePass controller reveals additional options.

In Download site, you can specify a Clam AntiVirus mirror site. You can choose a site from http://www.clamav.net/mirrors.html, or specify database.clamav.net (a round-robin record that allocates traffic among the database mirrors). The default is database.clamav.net.

The update process uses the HTTP protocol. You can specify the frequency of updates (as the number of Updates per day), number of Retry attempts to download an update, and, if you use an HTTP proxy, any needed proxy parameters.




Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)