Technical White Paper. By Jay Tomlin NFuse Technical Support Team Citrix Systems, Inc.

Transcription

1 Security Guidelines for NFuse 1.0 Technical White Paper By Jay Tomlin NFuse Technical Support Team Citrix Systems, Inc.

2 Notice The information in this publication is subject to change without notice. THIS PUBLICATION IS PROVIDED AS IS WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON- INFRINGEMENT. CITRIX SYSTEMS, INC. ( CITRIX ), SHALL NOT BE LIABLE FOR TECHNICAL OR EDITORIAL ERRORS OR OMISSIONS CONTAINED HEREIN, NOR FOR DIRECT, INCIDENTAL, CONSEQUENTIAL OR ANY OTHER DAMAGES RESULTING FROM THE FURNISHING, PERFORMANCE, OR USE OF THIS PUBLICATION, EVEN IF CITRIX HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES IN ADVANCE. This publication contains information protected by copyright. Except for internal distribution, no part of this publication may be photocopied or reproduced in any form without prior written consent from Citrix. The exclusive warranty for any Citrix products discussed in this publication, if any, is stated in the product documentation accompanying such products. Citrix does not warrant products other than its own. Product names mentioned herein may be trademarks and/or registered trademarks of their respective companies Citrix Systems, Inc. All rights reserved. Version History January 1, 2000 Firstname Lastname Version 1.0 Security Guidelines for NFuse 1.0 ii

3 TABLE OF CONTENTS SECURITY GUIDELINES FOR NFUSE INTRODUCTION...1 NFUSE ARCHITECTURE...1 ICA File Structure and Syntax...2 Example 1: Sample static ICA file...2 NFuse s template.ica file...3 SECURING NFUSE NETWORK TRAFFIC...5 BETWEEN THE CLIENT AND THE WEB SERVER...5 User credentials sent to the web server...5 NFuse Cookies...5 Webmasters can harvest user credentials...6 HTML and ICA files delivered to the client...6 BETWEEN THE WEB SERVER AND THE METAFRAME SERVER...7 Example 2: NFuse XML Protocol traffic...8 BETWEEN THE CLIENT AND THE METAFRAME SERVER...9 Integrating NFuse and Citrix SecureICA Services...9 " Secure Solution...10 " Unsecure Workaround...10 CONCLUSIONS AND RECOMMENDATIONS...11 Security Guidelines for NFuse 1.0 iii

4 Security Guidelines for NFuse 1.0 Introduction With the release of NFuse 1.0, Citrix Systems, Inc. makes it easier than ever to take your company s applications to the Internet. This flexibility brings with it a responsibility to ensure that your data remains secure and impervious to attacks. This document explores some of the security considerations surrounding Citrix NFuse 1.0. It is assumed that the reader is familiar with web server technologies, Citrix MetaFrame 1.8, and NFuse 1.0. NFuse Architecture Citrix NFuse 1.0 consists of a three-tier architecture in which a web browser, web server, and a Citrix MetaFrame 1.8 server work together to provide seamless user access to published applications. Users access an NFuse-driven web server, to enumerate their personal collection of applications, using a standard web browser such as Internet Explorer, or Netscape Navigator. Figure 1 illustrates the architecture of an NFuse-enabled MetaFrame server farm. Figure 1: NFuse Architecture Security Guidelines for NFuse 1.0 1

5 Application access is controlled from the MetaFrame server farm using Citrix Published Application Manager, the same tool used for publishing applications to existing Program Neighborhood clients. Currently, Program Neighborhood functionality is limited to Win32 and Java ICA clients; NFuse 1.0 can be thought of as a Web Program Neighborhood application portal that extends Program Neighborhood functionality to any client device. Access to applications published in Citrix Server Farm scope is controlled via Windows NT group membership. For example, the Citrix MetaFrame administrator may publish the User Manager application and allow only Domain Administrators to connect. If a user logs into Program Neighborhood or NFuse as a member of the Domain Administrators group, an icon for the User Manager published application will appear. Each Citrix server farm user may have a unique set of server-farm applications, referred to as the user s application set. Users receive the same application set whether they access the server farm using Program Neighborhood, or NFuse. If the Citrix MetaFrame administrator publishes a new application across the server farm, an icon for that application will appear automatically (or upon clicking the Refresh button) for all users with permission to access the new published application. ICA File Structure and Syntax To gain access to a MetaFrame published application, ICA web clients utilize small connection files that contain just enough information to connect to the least-busy server and launch the desired application. These ICA files use common INI-file syntax and can be manipulated directly with any text editor to alter the properties of the ICA connection. Example 1 illustrates a sample ICA file that could be used to connect a web client to the MS Excel published application. Example 1: Sample static ICA file [WFClient] Version=2.0 [Application Servers] MS Excel= [MS Excel] Address= InitialProgram=#MS Excel DesiredColor=2 TransportDriver=TCP/IP WinStationDriver=ICA 3.0 Username=johndoe Domain=CITRIX Password=00097d b1e07091f This file connects the user to the MetaFrame server with IP address , and launches the MS Excel published application. The user s credentials are also included in the ICA file, but the password is scrambled using a Citrix-proprietary algorithm. (To generate a scrambled password for inclusion in an ICA file, you can define a connection using any full ICA client and then find the value entered into your client s appsrv.ini file.) Security Guidelines for NFuse 1.0 2

6 Security tip: Inclusion of the user credentials in an ICA file is optional. If the credentials are missing or incorrect, the user will be prompted to enter the information during logon. Note Static ICA files do not require NFuse. The NFuse web server components generate ICA files dynamically, based on the current user and the selected application. NFuse s template.ica file The example below shows a sample template.ica file that an NFuse server could use to generate the static ICA file shown in Example 1. Sample NFuse template.ica [WFClient] Version=2 [ApplicationServers] [NFuse_AppName]= [[NFuse_AppName]] Address=[NFuse_IPv4Address] InitialProgram=#[NFuse_AppName] DesiredColor=[NFuse_WindowColors] TransportDriver=TCP/IP WinStationDriver=ICA 3.0 Username=[NFuse_User] Domain=[NFuse_Domain] Password=[NFuse_PasswordScrambled] All user-specific and application-specific information is generalized by use of [NFuse_variablename] substitution tags. By default, a single template.ica file is used to render static ICA files for all NFuse users. The template.ica file may be modified to increase security. For example, the [NFuse_PasswordScrambled] substitution tag could be deleted, forcing users to re-enter their password at the MetaFrame server. It is important to understand that the NFuse server performs TCP name resolution on behalf of the client for each published application. Without this new feature, the address line in the ICA file shown above would read Address=MS Excel, and the client would need to contact an ICA Master Browser on UDP port 1604 to resolve the name of the published application to the IP Security Guidelines for NFuse 1.0 3

7 address of the least-busy server hosting that application. With NFuse TCP name resolution, the need for UDP traffic between the ICA client and an ICA Master Browser has been eliminated. If your MetaFrame server lies behind a firewall or router performing Network Address Translation (NAT), you will need to modify the template.ica file so that application names are resolved to the server s external (alternate) address rather than the internal (private) address. To achieve this: 1. Issue the ALTADDR.EXE command at each of your MetaFrame servers, 2. Next, change the Address=[NFuse_IPv4Address] line in template.ica to Address=[NFuse_IPv4AddressAlternate]. Note When there are multiple MetaFrame servers behind a NAT firewall, each MetaFrame server must have its own unique external IP address in order for load-balancing to function properly. For a complete reference of possible ICA file entries and NFuse substitution tags, consult the NFuse Administrator s Guide. Security Guidelines for NFuse 1.0 4

8 Securing NFuse Network Traffic As illustrated in Figure 1, NFuse network traffic traverses a total of three network paths: Between the client web browser and the NFuse web server; Between the NFuse web server and the NFuse MetaFrame server; and Between the client and the MetaFrame Server farm. Each of these three paths will be discussed in this section. Note The information presented here is based on the default configurations one would receive when using the NFuse Web Site Wizard to generate an NFuse-driven website. Given a sufficient comfort level with Active Server Pages or Java Server Pages, webmasters are free to modify the default behavior of NFuse to meet the needs of their environment. Between the client and the web server NFuse relies on standard web protocols to exchange information between the client s web browser and the NFuse-enabled web server. This communication can be either standard HyperText Transfer Protocol (HTTP, TCP port 80 by default), or HTTP encrypted with Secure Sockets Layer (SSL, TCP port 443 by default). User credentials sent to the web server If the user is logging into an NFuse website with an explicit username and password (i.e., not a guest login), then the browser must send this information across the network. If standard HTTP (without SSL) is used to host the NFuse login page, then the user credentials will traverse the network in plain text. The login form works like any other HTML form on an Internet website; just as you should be wary of sending your credit card information to an unsecured web site to purchase a book, you should avoid hosting the NFuse login page on an unsecured web site. If the NFuse website was configured to allow guest logins only, no user credentials are required of the client and none are sent to the web server during the initial NFuse request to enumerate the application set. NFuse Cookies By default, NFuse uses a transient client-side cookie to remember the user s credentials. Upon receiving the credentials from the initial login form, the web server returns the credentials back to the client in the form of a transient cookie. As the user browses the NFuse website, this cookie is retransmitted with each HTTP GET request, allowing the user to browse their application set and launch applications without the need to re-enter their credentials. Since the cookie is flagged as transient, it is not saved to the client hard drive and is lost upon closing the browser. For NFuse 1.0, this cookie contains the current username, domain and password in clear text, and is used to initiate a ClearTextCredentials NFuse object on the web server. To encrypt the user credentials between the client s web browser and your NFuse web server, including the cookie mentioned above, SSL should be used. Security Guidelines for NFuse 1.0 5

9 Establishing an SSL-secured website requires an SSL-enabled web server and a digital certificate that can be obtained for Internet use from third-party companies like VeriSign, or created for internal use by Microsoft Certificate Server (when using IIS). SSL-secured web sites are easily identified on the browser by the presence of a padlock icon at the bottom of the browser window when using Microsoft Internet Explorer or Netscape Navigator. The clear-text credentials cookie present in the NFuse wizard-generated examples is optional. Other methods could be used to remember a user s credentials, such as ASP Session variables. Webmasters can harvest user credentials Since the user credentials are posted with HTTP as variables from a standard HTML form, their unencrypted contents are available to the webmaster and could be harvested, even if SSL is used between the web server and web browser. Just as an e- commerce webmaster should be audited to ensure that customer credit card information is not harvested, MetaFrame administrators and NFuse webmasters should work together to ensure that the NFuse webmaster does not abuse this possibility. HTML and ICA files delivered to the client Other data sent across the channel between the web client and web server includes the HTML page containing the user s application set or HTML-embedded application. In the latter case, the web server will deliver a rendered ICA file containing the user credentials in ICA file format (as shown in Example 1). While this information does not reveal the user s password explicitly, an attacker could save this ICA file to disk and execute it with an ICA client to gain access to the MetaFrame server farm. As with client-to-server traffic, SSL is the best way to secure your server-to-client traffic. It is not strictly necessary to return the user s credentials in the ICA file generated for each application. For example, if the [NFuse_PasswordScrambled] tag were removed from template.ica, users would be prompted by the MetaFrame server for their password. Security Guidelines for NFuse 1.0 6

10 Between the Web Server and the MetaFrame Server In order to enumerate the application set for the current user, the NFuse web server must forward the user credentials to a MetaFrame server running the NFuse MetaFrame component, or Citrix NFuse Service. The web server and MetaFrame server communicate using the NFuse XML Protocol. In NFuse 1.0, the network data stream between the Web server and the MetaFrame server is clear-text XML, but the password is scrambled with a Citrix-proprietary algorithm (not the same algorithm used for ICA files). This server-to-server link can be protected by use of a Virtual Private Netowrk (VPN) or by establishing a private subnet for server-to-server traffic. Note In smaller environments, it may be desirable to configure a single MetaFrame server that acts as both the NFuse Web server and the NFuse MetaFrame server. While this configuration may not be suitable in larger networks, it does eliminate the NFuse XML protocol traffic from the network entirely. When configuring the NFuse web server component in this situation, enter (the loopback address) as the address of the Citrix MetaFrame server. When installing the NFuse MetaFrame service, be sure to use a port other than the default port 80 since port 80 will be in use by your web server service. To illustrate the NFuse XML protocol, an excerpt of a network trace of Web server-to-metaframe traffic when a user logs into NFuse is shown below. The trace reveals the username that was entered into the logon HTML page. For this example, the following credentials were used: Username: johndoe Domain: CITRIX Password: saturn99 The authentication packet sent from the Web server to the MetaFrame server would contain the text shown in Example 2. Security Guidelines for NFuse 1.0 7

11 Example 2: NFuse XML Protocol traffic POST /scripts/wpnbr.dll HTTP/1.1 Content-Type: text/xml Host: iis4.citrix.com Content-Length: 554 <?xml version="1.0" encoding="iso "?> <!DOCTYPE NFuseProtocol SYSTEM "NFuse.dtd"> <NFuseProtocol version="1"> <RequestAppData> <Scope.traverse="onelevel"></Scope> <DesiredDetails>defaults</DesiredDetails> <ServerType>win32</ServerType> <ClientType>ica30</ClientType> <Credentials> <UserName>johndoe</UserName> <Password encoding="ctx1">mgalmpbinbblmkblnl</password> <Domain type="nt">citrix</domain> </Credentials> </RequestAppData> </NFuseProtocol> As you can see, the password is not transmitted in clear text, nor is it scrambled with the same algorithm used for ICA files. The password "saturn99" was scrambled as "00097d b1e07091f" in the ICA file shown in Example 1, but scrambled as MGALMPBINBBLMKBLNL within the XML protocol traffic. By intercepting the Web server-to-metaframe server traffic, an attacker may be able to forge a packet that allows him to enumerate the application set for a particular user, but he will not be able to log into any applications using that information. Without access to the cookie containing the user s plain-text credentials, this XML information is not enough to allow an attacker to forge an ICA file that logs into the MetaFrame server farm. Security Guidelines for NFuse 1.0 8

12 Between the client and the MetaFrame server Once the NFuse web server has generated a dynamic ICA file for the user and delivered it to the client web browser, the client uses the ICA file to make an independent TCP/IP connection into the MetaFrame server farm. Technically, this step does not involve NFuse; ICA files can be used to establish client connections without the help of NFuse or even of a web server. If the user credentials are included within the ICA file, the user is authenticated to the MetaFrame server without having to retype their username and password. Currently, the contents of the ICA file are sent in plain text from the client to the server s ICA port (TCP 1494 by default; MetaFrame administrators can change this port assignment using the icaport.exe command-line utility at the MetaFrame server.) Once the ICA session is established, all ICA commands are scrambled using a Basic scrambling algorithm. For higher levels of encryption, SecureICA Services can be used to encrypt the ICA data stream using RC5 key lengths of up to 128 bits. Integrating SecureICA Services with NFuse requires additional configuration described below. Integrating NFuse and Citrix SecureICA Services Citrix SecureICA Services can encrypt ICA session traffic between the ICA client and a WinFrame or MetaFrame server using RC5 key lengths of up to 128 bits. During authentication, the Diffie-Hellman key agreement algorithm is used to generate a pair of symmetric RC5 keys that encrypt the ICA data stream; one key is used to encrypt client-to-server traffic, and a second key is used to encrypt server-to-client traffic. Using SecureICA Services requires a modified ICA client. At the time of this writing, SecureICA clients are available for the following platforms only: Win32 Win16 DOS ActiveX web client Netscape plugin Since the ICA file must be sent to the MetaFrame server before the encrypted ICA session is established, it is not currently possible to encrypt the contents of the ICA file. As a security precaution, SecureICA-enabled MetaFrame servers do not accept ICA file connections that include user credentials. By default, NFuse will supply the user s credentials in the ICA file that is dynamically generated for them. In this case, SecureICA clients receive the following error message when they attempt to connect to a SecureICA published application via NFuse: "Cannot load the Citrix ICA Client drivers. [Error 1079: This connection entry uses RC5 encryption. For enhanced security, please do not specify a User name and Password in the connection properties or on the command line.]" For SecureICA clients to connect successfully, this feature must either be removed from the NFuse Web site, or disabled by use of the "AutoLogonAllowed" tag described below. It should be stressed that using the AutoLogonAllowed tag is an insecure workaround. Security Guidelines for NFuse 1.0 9

13 " Secure Solution To remove the username and password from NFuse-generated ICA files, locate the following lines in the template.ica file on your NFuse web server: Username=[NFuse_User] Domain=[NFuse_Domain] Password=[NFuse_PasswordScrambled] Delete the NFuse substitution tags [NFuse_User] and [NFuse_PasswordScrambled], leaving the following in template.ica: Username= Domain=[CitrixPN_Domain] Password= Users can now connect using SecureICA but must re-enter their username and password during MetaFrame log on. " Unsecure Workaround For a more seamless user experience, it is possible to automate username and password entry when using SecureICA Services by adding the following line to the Template.ica file: AutoLogonAllowed=On This line should be added to the [[NFuse_AppName]] section of template.ica, just after the Username, Domain and Password lines. When this line is added, the SecureICA MetaFrame server overrides its default security precaution and accepts the user credentials in the ICA file; the user is not prompted to re-enter their username and password. However, this poses a security risk because the authentication information contained in the ICA file is not encrypted en route to the Citrix server. If an attacker were to intercept the contents of the ICA file, they would be able to establish a SecureICA connection into the MetaFrame server using those credentials. For this reason, the current recommendation is to remove the [NFuse_User] and [NFuse_PasswordScrambled] tags from the template.ica file. Note Changes made to the template.ica file affect all users of the current NFuse Web directory. For more information about SecureICA Services, see the online documentation at Security Guidelines for NFuse

14 Conclusions and Recommendations As with any other Internet technology, evaluate Citrix NFuse 1.0 from a security aspect before it s put into production. Consider SSL between the web server and web clients a requirement if you plan to use NFuse 1.0 to enable access to your applications from the Internet. The same security technologies and precautions that accompany e-commerce websites should be implemented for NFuse websites. Traffic between the NFuse server and a MetaFrame server has less potential for harm. As mentioned in the Between the Web- Server and the MetaFrame server section, the worst-case scenario should this traffic be intercepted is that an attacker would be able to enumerate the application set for a user. Occasional peer review of the NFuse web pages is recommended to ensure that the webmaster is not harvesting user credentials as mentioned in the Webmasters can harvest user credentials section. When integrating SecureICA Services with NFuse 1.0, remove the username and password from the template.ica file. Security Guidelines for NFuse

15 6400 NW 6 th Way Fort Lauderdale, FL Copyright 2000 Citrix Systems, Inc. All rights reserved. Citrix, WinFrame and ICA are registered trademarks, and MultiWin and MetaFrame are trademarks of Citrix Systems, Inc. All other products and services are trademarks or service marks of their respective companies. Technical specifications and availability are subject to change without prior notice.