Technical Note PR-TN 2005/00334

Issued: 04/2005

Secure access to intranet applications from the Internet using Citrix Secure Gateway

W.J.O. Teesselink Philips Research Eindhoven

Unclassified ©

Koninklijke Philips Electronics N.V. 2005

PR-TN 2005/00334

Authors’ address

Unclassified

W.J.O. Teesselink

WAY11

[email protected]

© KONINKLIJKE PHILIPS ELECTRONICS NV 2005 All rights reserved. Reproduction or dissemination in whole or in part is prohibited without the prior written consent of the copyright holder .

ii

©

Koninklijke Philips Electronics N.V. 2005

Unclassified

PR-TN 2005/00334

Title:

Secure access to intranet applications from the Internet using Citrix Secure Gateway

Author(s):

W.J.O. Teesselink

Reviewer(s):

Eddy Reniers, IPS Facilities, Noordermeer, R.

Technical Note:

PR-TN 2005/00334

Additional Numbers: Subcategory: Project:

Not project related or related to a New project (None)

Customer:

Keywords:

Terminal server, access, Citrix, secure gateway, secure

Abstract:

The current remote access software supported by Philips (VRAS) has some limitations in usability and supportability. This document handles about the design and implementation of an alternative, secure, way to offer application access on intranet based servers directly from the Internet using the Citrix Secure Gateway.

Conclusions:

Citrix Secure Gateway offers an easy to use, secure a cost effective way to offer access to applications in the intranet from the Internet.

©

Koninklijke Philips Electronics N.V. 2005

iii

Unclassified

PR-TN 2005/00334

Contents

Secure access to intranet applications from the Internet using Citrix Secure Gateway .............................. i 1.

Introduction ..............................................................................................................9 1.1. 1.2. 1.3. 1.4.

2.

What is Citrix Secure Gateway? .......................................................................9 Philips standard connection methods................................................................9 What problem does Citrix Secure Gateway solve?.........................................10 Alternatives .....................................................................................................10

How does CSG work ..............................................................................................11 2.1. Deployment scenarios .....................................................................................11 2.2. The components ..............................................................................................12 2.3. Interaction between the components:..............................................................12

3.

Software versions....................................................................................................15

4.

Scalability ................................................................................................................16

5.

Additions to the Web interface..............................................................................17 5.1. SecurID lookup ...............................................................................................17 5.2. Updated ICA clients........................................................................................17

6.

Implementation plan ..............................................................................................18 6.1. Steps 18 6.1.1. Acquire hardware ................................................................................18 6.1.2. Configure firewall ...............................................................................18 6.1.3. Fill in the Citrix Secure Gateway Checklist........................................19 6.1.4. Install Web Interface server ................................................................19 6.1.5. Install the Secure Ticket Authority .....................................................20 6.1.6. Configure the Secure Ticket Authority ...............................................20 6.1.7. Install Citrix Secure Gateway .............................................................20 6.1.8. Configure the Citrix Secure Gateway .................................................21 6.1.9. Configure Web Interface to support Citrix Secure Gateway ..............21 6.1.10. Test the Citrix Secure Gateway...........................................................21

©

Koninklijke Philips Electronics N.V. 2005

v

PR-TN 2005/00334

Unclassified

7.

Improving the environment...................................................................................22

8.

Conclusion ...............................................................................................................23

References.......................................................................................................................24

vi

©

Koninklijke Philips Electronics N.V. 2005

Unclassified

©

Koninklijke Philips Electronics N.V. 2005

PR-TN 2005/00334

vii

Unclassified

1.

PR-TN 2005/00334

Introduction

With Citrix Secure Gateway we can offer secure application access to applications on a terminal server farm in the Philips intranet from the Internet. In the first part this document describes the business case for using Secure Gateway. Following is a general overview of Citrix Secure Gateway. The final part describes the design and implementation of a Citrix Secure Gateway instance.

1.1.

What is Citrix Secure Gateway?

Citrix Secure Gateway (CSG) is a set of servers and services that enables secure access to intranet resources directly from the Internet. The client only needs a web browser and ICA client software to initiate a connection. All traffic uses http and https, protocol that can traverse all firewalls so the connection can be established from virtually everywhere.

1.2.

Philips standard connection methods

At this moment the standard way to use resources on the Philips intranet (PGN) from the Internet is by establishing a PDS or VRAS (or the PDS/VRAS successor iRAS) connection. PDS is a worldwide dial-in service, used for travelling users. VRAS is a VPN that can be used over any Internet connection. Both connection methods give the user complete IP connectivity to the PGN (except some restrictions due to port blocking and filtering by Corporate IT) PDS is a good working connection method for travelling users. The connection speed is low (56Kbit, restricted by analog telephone connection) but usable for the target group. VRAS is the preferred method for connecting remote workers and home users. It is a fairly stable and good performing connection method but has some restrictions: • Officially it must be installed on a Philips managed PC • In the natlab case we allow VRAS to be installed on a users home PC but: o Problems with many different home installations A lot of different operating systems (the oldest and newest available are used) Many different home network configurations (VRAS does use certain features that do not work in all home network configurations) Remote support from helpdesk is very difficult o VRAS client as offered by Corporate IT does not work on all platforms used at home. We need to find solutions every time a new version is offered. • The iRAS package that is offered for home users by corporate IT uses the same VPN client software as VRAS so has the same problems. • Most users do not need the full TCPIP connectivity as offered by VRAS. A lot of people only want to run applications like email or look up a document. Most users ©

Koninklijke Philips Electronics N.V. 2005

9

PR-TN 2005/00334

Unclassified

use terminal servers for this purpose. The extra functionality offered by the full TCPIP connectivity is a security risk for the PGN.

1.3.

What problem does Citrix Secure Gateway solve?

CSG is a way to connect to a terminal server farm in the intranet using an Internet browser as client device. A user starts his Internet browser, types a URL and is connected. No client configuration necessary. (a browser plug-in is automatically loaded; if the plug-in cannot be installed (Internet café) a java client can be used). After connecting the user must log on with his normal userid and password and the SecurID PIN and token as used with the other access services (PDS, VRAS, iRAS). Only the published applications offered to that user are available, no other connections are possible, which minimizes the security risk. If the CSG solution is in place we are able to offer remote connectivity to applications to most users. If someone has a good reason for having full tcpip connectivity we can provide this user with a Philips managed notebook and VRAS/iRAS so the client configuration can be controlled. CSG can also be a good alternative for Third Party Gateways. Most TPG’s are in use to access a specific application on the PGN. With the CSG we can easily give a user access to the single application he needs. This can sometimes replace a leased line (e.g. the connection from IMEC to the PGN can be removed when the users are using the IMEC internet connection).

1.4.

Alternatives

At this moment a lot of portal like applications that offer access to resources in the intranet from the Internet are offered on the market. Some of these portals have connections to terminal server farms as a standard, other offer only access to files (ftp like functionality) and web applications. CSG is a free product (in the form we are using it). You only need to pay for the (concurrent) connection licenses to the terminal server farm. We use the same Terminal Server farm for remote usages as for internal (PGN) usage, so we make better use of the investment we already have done.

10

©

Koninklijke Philips Electronics N.V. 2005

Unclassified

2.

How does CSG work

2.1.

Deployment scenarios

PR-TN 2005/00334

There are several methods of using a Citrix Secure Gateway. Our goal is to give secure access to applications on a Citrix Metaframe farm. To achieve this goal you can use: • A single-hop Demilitarised Zone (DMZ) with the web interface located behind the secure gateway service. All traffic is intercepted by the secure gateway. This machine works as a web proxy for the web interface that is installed on the same or a separate machine. Advantages: o A single server certificate is required on the server running the secure gateway service o Only one single port has to be opened on the firewall facing the internet o The web interface can not be contacted directly from the internet and is therefore more secure Disadvantages: o Web interface for Metaframe XP functionality is affected o Smart card authentication integrated with web interface is not available o Firewall and Proxy settings requiring knowledge of the client IP address are ineffective. • A single hop DMZ with the web interface parallel to the secure gateway. Users can connect directly to the web interface so the disadvantages of the secure gateway in proxy mode disappear. All the advantages of the previous method are disadvantages of the direct accessible web interface method. Secure Gateway versions previous to version 2.0 used this configuration so this method of operation is primarily used in situation where a Secure Gateway 1.x installation is upgraded to Secure Gateway 2.0. • Double-hop DMZ deployments. In this scenario there is a single secure gateway in the first DMZ. In the second DMZ are the web interface and a secure gateway proxy server. The Metaframe farm is on the secure network. Users connect to the secure gateway server in the first DMZ. This machine forwards all traffic to the web interface and proxy server in the second DMZ. The web interface is responsible for user authentication and authorisation. The secure Gateway proxy is responsible for proxying all data exchanged between the secure gateway and the secure network. This method is used if the network contains a double-hop DMZ. It provides the maximum protection, as an attacker would need to penetrate multiple security zones to reach the servers on the secure network. The same disadvantages as described in “a single-hop DMZ with the web interface located behind the secure gateway service” apply for this method. Also an extra machine has to be used. ©

Koninklijke Philips Electronics N.V. 2005

11

PR-TN 2005/00334

Unclassified

We choose to deploy a single-hop DMZ with the web interface located behind the secure gateway service. The secure Gateway machine is the only machine in the DMZ. We protect all servers with a local firewall in addition to the DMZ firewalls to achieve maximum protection.

2.2.

The components

The Secure Gateway deployment (in a “single-hop DMZ with the web interface located behind the secure gateway service” deployment to access a Metaframe farm) involves the interaction of five Citrix components and an independent authentication service: • A client device with an ICA Client, version 6.30 or later installed • A Secure Gateway server (SG) • A Citrix Web Interface server (WI) • A Secure Ticket Authority server (STA) • A Radius / ACE server • One or more Citrix Metaframe Presentation server(s)

2.3.

Interaction between the components:

The Secure Gateway configuration shown below illustrates how the various components interact to provide secure, encrypted access to published application resources on a secure network. Insecure network

DMZ

External firewall port 80 and 443

PGN

Internal firewall port 443 and 1494

9

7

Client

3b

5 2

6 1

3a Web Interface

8

Terminal server farm

4

Secure Gateway

Ticket authoroty

Radius / ACE

Note: firewalls shown in this illustration are optional, but are used to improve security. Next to the shown firewalls also local firewalls on the Secure Gateway, the Ticket authority and the Web interface server are used. 12

©

Koninklijke Philips Electronics N.V. 2005

Unclassified

PR-TN 2005/00334

1. A remote user launches a Web browser and connects to the Secure Gateway server on port 80 (HTTP) or port 433 (HTTPS). A connection to port 80 is redirected to the secure site automatically. 2. The Secure Gateway server works as a web proxy. It redirects the web traffic to the Web Interface server. The portal on the Web Interface server requires the user to authenticate using valid user credentials. 3a. First the web interface authenticates the user with the Radius / ACE server. We modified the software of the web interface to lookup the SecurID account of a user using the supplied user name and domain name. When the SecurID account lookup was successful, the SecurID account is used in conjunction with the user supplied SecurID PIN and token to authenticate against the Radius / ACE server. 3b. If the authentication with the Radius server was successful the web Interface uses the supplied userid, password and domain to contact the Citrix XML Service, on port 80, running on a Metaframe server and obtains a list of applications that the user is authorized to access. Web Interface populates the Web portal page with the list of published applications that the user is authorized to access. 4. When the user clicks on a link for a published application, Web Interface sends the IP address for the requested Metaframe server to the STA and requests a Secure Gateway ticket for the user. The STA saves the IP address and issues the requested Secure Gateway ticket to Web Interface. 5. Web Interface generates an ICA file containing the ticket issued by the STA, and then sends it to the Secure Gateway server. 6. The Secure Gateway server passes the ica file to the client browser. Note that the ICA file generated by Web Interface contains only the IP address of the Secure Gateway server. The addresses of the Metaframe server(s) that the ICA client eventually connects to is not exposed. 7. The browser passes the ICA file to the ICA client, which launches an SSL connection to the Secure Gateway server. Initial SSL handshaking is performed to establish the identity of the Secure Gateway server 8. The Secure Gateway server accepts the ticket from the ICA client and uses information contained in the Secure Gateway Ticket to identify and contact the STA for ticket validation. If the STA is able to validate the ticket, it returns the IP address of the Metaframe server on which the requested application resides. If the ticket is invalid or has expired, the STA informs the Secure Gateway server, and an error message is displayed on the ICA client device. 9. On receipt of the IP address for the Metaframe server, the Secure Gateway server establishes an ICA connection to the Metaframe server. After the ICA connection is ©

Koninklijke Philips Electronics N.V. 2005

13

PR-TN 2005/00334

Unclassified

established, the Secure Gateway server monitors ICA data flowing through the connection, and encrypts and decrypts client-server communications.

14

©

Koninklijke Philips Electronics N.V. 2005

Unclassified

3.

PR-TN 2005/00334

Software versions

The Citrix Secure Gateway deployment we built is using the following software components: Web Interface: CSG: Windows Web server Virus shield Local firewall

©

Version is 2.1 Version is 2.0 Server 2003 IIS 6.0 McAfee 7.1.0 centrally managed with McAfee e-policy orchestrator (EPO) McAfee personal firewall version 8.0, centrally managed with EPO

Koninklijke Philips Electronics N.V. 2005

15

PR-TN 2005/00334

4.

Unclassified

Scalability

Web Interface servers can be placed in a network load balanced cluster. This is the easiest way to provide fail over. There is no information on the number of concurrent user a Web Interface server can support. A single CSG can support up to 500 or more users. More users can be supported by placing the CSG in a network load balanced cluster. The STA can support far more than 500 users. For fault tolerance you need at least two CSG and STA machines. The CSG machines must be load balanced with Network Load Balancing or a hardware load balancer. The configuration of CSG allows two STA servers for redundancy. The two Web Interface servers can be configured with a different STA for load spreading.

16

©

Koninklijke Philips Electronics N.V. 2005

Unclassified

5.

Additions to the Web interface

5.1.

SecurID lookup

PR-TN 2005/00334

Two-factor authentication must be used to secure a remote access method. Web interface supports Radius/ACE authentication with SecurID tokens. The user must supply: • Windows Userid • Windows password • Windows domain • SecurID user id • SecurID PIN and token In the Philips environment the SecurID user account is stored in the Lotus Notes Names and Address Book. We added some code to the “CExplicitAuthentication.vbs” module in web interface to look up the user’s SecurID account using the Windows user and domain name the user entered in the logon dialog. The code first retrieves the user’s Lotus Notes unique identifier from the CommonData database, which contains records of all Philips employees. This unique identifier is then used to lookup the SecurID account in a database, which contains a local copy of the Notes Names and Address book.

5.2.

Updated ICA clients

We found a problem with the ICA clients prior to version 8.1. We wanted the ICA client to use the proxy configuration of the configured browser. This worked fine as long as no automatic proxy script is defined. When the browser is configured with automatic configuration it uses that configuration if it can be found. If the config file cannot be found (e.g. the client is not on the corporate LAN) the browser uses a direct connection to the Internet. The ICA client prior to version 8.1 would crash if the proxy configuration file is not present. Starting with version 8.1 you tell the ICA client to evaluate the proxy configuration in the same way as the browser. We replaced the installed ICA client installation package in the directory C:\Inetpub\wwwroot\Citrix\ICAWEB\en\ICA32 with the 8.1 client.

©

Koninklijke Philips Electronics N.V. 2005

17

PR-TN 2005/00334

6.

Unclassified

Implementation plan

In the next chapters is a high level description of the procedure to implement a Citrix Secure Gateway environment. The basic idea of this implementation is that it is used to connect to an existing terminal server farm.

6.1.

Steps

Following is a list of steps that must be taken to build a Citrix Secure Gateway environment. 1. 2. 3. 4. 5.

Acquire hardware Configure firewalls, DMZ Fill in the Citrix Secure Gateway Checklist Arrange access to the radius ace infrastructure Install Web Interface server on W2K3 server with IIS6, virus shield and personal firewall 6. Install the Secure Ticket Authority on W2K3 server with IIS6, virus shield and personal firewall 7. Configure the Secure Ticket Authority 8. Install Citrix Secure Gateway on W2K3 server with virus shield and personal firewall 9. Configure the Citrix Secure Gateway 10. Configure Web Interface to support Citrix Secure Gateway 11. Test the Citrix Secure Gateway

6.1.1. Acquire hardware We need at least three servers for the CSG environment. 1

Web interface server

2

Secure Ticket Authority

3

Citrix Secure Gateway

Windows 2003 server with IIS 6.0, virus Shield and firewall Windows 2003 server with IIS 6.0, virus Shield and firewall Windows 2003 server with IIS 6.0, virus Shield and firewall

6.1.2. Configure firewall

We need to configure 2 firewalls 18

©

Koninklijke Philips Electronics N.V. 2005

Unclassified

PR-TN 2005/00334

1. The external firewall. This firewall protects the Citrix Secure Gateway server from the public Internet. Port 80 and 443 must be forwarded from the Internet to the Citrix Secure Gateway server. 2. The internal firewall this firewall protects the intranet from the Demilitarised Zone where the Secure Gateway Server is placed. Port 1494 must be open between the CSG server and all the Metaframe servers in the farm. Port 443 must be open for communication between CSG and the web interface server. Port 443 must be open between CSG and STA. Some other ports for management and working of the CSG (managing virus definitions, firewall settings, DNS, etc.) must be opened between the intranet and the CSG. 6.1.3. Fill in the Citrix Secure Gateway Checklist This list is available from the Citrix website: Installation Checklist, Citrix Secure Gateway(ref. 1) After filling the fields this list contains all necessary information and configuration to implement a CSG environment. Also the certificates that are necessary for the different machines are mentioned.

6.1.4. Install Web Interface server Install Web Interface 2.1 on IIS6.0. Information on installing and setting up Web Interface can be found in the Web Interface Guide on the Citrix website: Administrators Guide, Web Interface for Metaframe XP feature release 3 (ref. 2) Basically you prepare a Windows 2003 server with IIS 6 with all the latest patches. Add a certificate to be able to use secure http. Then install web interface with all the default options and choises. After installation you can configure the web interface using the url: http://localhost/Citrix/MetaframeXP/WIAdmin •

In the section Metaframe Servers Add 2 or more servers from the Metaframe farm

•

In the Authentication section select: Allow users to change password: on expiry

•

In the ICA Client deployment: enable automatic download of ICA WIN32 client

To be able to use 128 bits encryption during logon add in the templace.ica file in the section [[Nfuse_AppName]] the entry: EncryptionLevelSession=ENCRC5-0 Finally, to give users easy access to the logon page you can make a default page with a redirection to the URL: https:///Citrix/MetaFrame/default.htm ©

Koninklijke Philips Electronics N.V. 2005

19

PR-TN 2005/00334

Unclassified

6.1.5. Install the Secure Ticket Authority

The Secure Ticket Authority must be installed on a Windows 2003 server with IIS 6.0 enabled. The install program is part of the secure gateway package. Download the latest version from Citrix and start the CSG_STA.msi. In the Component menu click Citrix Secure Gateway then click Secure Ticket Authority 6.1.6. Configure the Secure Ticket Authority See page 95 of the Citrix Secure Gateway for Windows administrators Guide, (ref. 3) STA ID:

16 alpha numeric characters, no spaces or special characters

Ticket Timeout: Max nr of concurrent tickets: Restart IIS

100000 (msec) 100000

To change configuration parameters for the STA afterwards, run the STA configuration wizard that can be found in the start menu on the STA server. 6.1.7. Install Citrix Secure Gateway Make sure port 443 is free Install server certificate (Appendix A of the Secure Gateway for Metaframe Administrators Guide (ref. 3) contains information on how to obtain and install certificates) The steps required to install a server certificate on a Secure Gateway server are as follows: 1. Create a certificate request. 2. Apply for a server certificate from a valid CA. 3. Save the certificate response file sent by the CA as an X.509 Certificate (CER format). 4. Import the X.509 certificate into the certificate store. 5. Export the certificate into Personal Information Exchange format (PFX, also called PKCS #12). 6. Install the server certificate on the Secure Gateway server. Each of the above steps is described in the manual page 36 and further. Run the CSG_GWY.msi.

20

©

Koninklijke Philips Electronics N.V. 2005

Unclassified

PR-TN 2005/00334

6.1.8. Configure the Citrix Secure Gateway See pages 96 - 97 from: Secure Gateway for Metaframe Administrators Guide (ref. 3) The installation is easy; just follow the instructions of the install wizard, filling in the values from the secure gateway checklist. To change configuration parameters for the Secure Gateway service afterwards, run the configuration wizard that can be found in the start menu. 6.1.9. Configure Web Interface to support Citrix Secure Gateway See page 83. . 85 of the Administrators Guide, Web Interface for Metaframe XP feature release 3 (ref. 2) 6.1.10. Test the Citrix Secure Gateway See page 98 - 99 of the Secure Gateway for Metaframe Administrators Guide (ref. 3) The secure gateway server contains a diagnostic tool in Start All Programs Citrix Secure Gateway Secure Gateway Diagnostics A healthy system gives the following result:

©

Koninklijke Philips Electronics N.V. 2005

21

PR-TN 2005/00334

7.

Unclassified

Improving the environment

After successful implementation the following improvements can be made: • Build network load balanced cluster for the Web Interface server • Build a network load balanced cluster for the CSG server • Add a second STA server and configure the other components to use both

22

©

Koninklijke Philips Electronics N.V. 2005

Unclassified

8.

PR-TN 2005/00334

Conclusion

Citrix Secure Gateway can give a user convenient, secure access to applications on a terminal server in the intranet from the Internet. Building a CSG environment is straightforward.

©

Koninklijke Philips Electronics N.V. 2005

23

PR-TN 2005/00334

Unclassified

References 1. Installation Checklist, Citrix Secure Gateway Version 1.1 Document code: csg.v11.ic.05192002 Filename: Citrix_Secure_Gateway_Checklist.pdf 2. Administrators Guide, Web Interface for Metaframe XP feature release 3 Document code: February 25, 2003 5:52 pm (LM) Filename: Web_Interface_Guide.pdf 3. Administrators Guide, Secure Gateway for Metaframe Version 2.0 Document code: April 29, 2003 4:15 pm (KT) Filename: Windows_Secure_Gateway_Guide.pdf

24

©

Koninklijke Philips Electronics N.V. 2005