Any traffic that crosses a computer network is susceptible to being captured and viewed by unauthorized people. Because of this, the networks must be secured. There are two ways that this can be done:
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
- Protect the physical network connections so that no one can access the network to compromise the data.
- Protect the logical data on the network so that if the data is compromised it is meaningless to the person who found it.
Protecting physical connections is not really practical in today's world, especially over the Internet. When addressing network security, most people focus on protecting the data that crosses the network. The common approach is "I don't care if you actually capture my data, because if you do, it will be totally meaningless to you." The networks over which MetaFrame XP traffic flows are no different than any other computer networks in the world. To secure your MetaFrame XP network, you need to look at two components:
- Network data security. (Encryption)
- Network perimeter security. (Firewalls)
Let's begin by examining your MetaFrame XP network's data security.
MetaFrame XP Network Data Security / Encryption
In MetaFrame XP environments, there are multiple types of network communications that need to be secured. Figure 15.6 shows all of the various network communications that take place in a standard MetaFrame XP environment. Each of the five arrows in that diagram represents a network segment that has data that must be protected. As we analyze the security of these links, we'll break them down into "front-end" and "back-end" network communications.
Figure 15.6: MetaFrame XP Network Segments
As you can see in Figure 15.6, the front-end communication includes all of the traffic that travels between client devices and the servers; the back-end communication includes all of the network traffic that travels between the various server components. Let's analyze the security needs of each of these network communication links, starting with the front-end. As we analyze these, we will refer to each network segment by its number in Figure 15.6.
Segment 1. Client Device Web Browser to NFuse Web Server
The network connection between the end user's web browser and the web server is usually a very susceptible connection because it often travels the public Internet. When we look at security on this connection, we're only concerned with the actual NFuse web traffic. We are not concerned about ICA traffic because after an ICA session is launched via NFuse the network connection moves from the web server (Segment #1 in Figure 15.6) to the MetaFrame XP server (Segment #2 in Figure 15.6). We'll study Segment 2 later.
Even though the client device web browser to the NFuse web server network communication takes place before the ICA session is started, there are several security risks at this point. The main risk stems from the fact that standard web server to web browser HTTP traffic is not secure. When a user logs in to an NFuse web server, his credentials are passed over the standard web connection. If that connection is not secure, the credentials are not secure. When a user clicks a hyperlink on an NFuse web page to launch a published application, the information for that published application is sent down to the client's web browser. Again, the standard web connection is used and it must be secure to protect the data. Anything else that traverses this connection, including application set lists, HTML forms data, clear text credentials for launching ICA sessions, and cookies are not secure.
Fortunately, the World Wide Web and web security have been around a lot longer than NFuse and MetaFrame XP. This means that there are standard ways to address this problem. The easiest and most effective way to secure this network segment is to use Secure Socket Layers, or SSL. SSL is a form of encryption used to secure TCP/IP-based communications in everything from online banking to book selling. The encryption process is transparent to the end user.
An Overview of Secure Socket Layers (SSL)
Using SSL is pretty straightforward. As an administrator, you must first purchase an X.509 digital certificate for your web server which contains the web server's DNS name. This digital certificate is nothing more than a bit of information that positively binds the details of your web server (such as its name) to a public key. As long as the client's web browser trusts the holder of your public key, then it will trust your web server. This will allow the client to send and receive encrypted information.
In order for client web browsers to trust that your X.509 digital certificate is real, you need to obtain it from a Certificate Authority (CA) that the client web browsers already trust. Examples of widely-trusted CAs include Baltimore, Equifax, GTE, Thawte, and VeriSign. By default, most client web browsers are configured to trust all of the big-name CAs. You can check this out yourself. For example, in Internet Explorer 6 there are dozens of "pre-trusted" CAs (IE6 | Tools | Internet Options | Content Tab | Certificates Button | Trusted Root Certification Authorities).
In order to purchase the X.509 digital certificate from a "pre-trusted" CA, specify the DNS name of your web server, choose the encryption strength (such as 40- or 128-bit), and select the expiration date. After you purchase the X.509 digital certificate, install it on your web server. The exact process varies depending on your web platform, but it usually involves cutting and pasting a really long certificate number into your web server's administrative console. Once you have installed the certificate, you can enable secure communications on specific (or all) directories for your website. This will allow your web server to securely communicate with your web users, causing the little padlock icon to appear in the corner their IE web browsers.
Because your website will now be secure, your users will need to access it using an address that begins with an https: prefix instead of http:. This is something that you'll need to think about because in the real world, most users will access your website by typing www.yourcompany.com without any prefix. Today's web browsers will automatically add the http:// prefix when the user presses enter. However, if the user is trying to access your secure website, they will get an error if they enter the address without the https: prefix. This error occurs because the web browser automatically adds the http:// prefix, creating http://www.yourcompany.com. But, because your web server is now secure, it needs the address in the secure format, https://www.yourcompany.com.
To alleviate this problem, you can create a non-secure web page that automatically forwards users to the secure web page. In our example, we could create a non-secure page called default.asp that contained the one line of code that would forward users to the secure page, complete with the prefix, to https://www.yourcompany.com/secure/login.asp. By doing this, your users can simply type www.yourcompany.com into their browsers and be connected to the secure page. For the non-programmers out there, the default.asp page on an IIS web server would only need a single line of code:
Using SSL encryption will not require you to change your NFuse web site in any way. NFuse does not know (or care) whether or not the connection is secure. You should also keep in mind that once the ICA session is started on the MetaFrame XP server, NFuse, the web server, and the client's web browser all drop out of the picture-the ICA session is a direct connection between the MetaFrame XP server and the ICA client.
By using SSL encryption on your NFuse web server, anyone, even attackers, will be able to establish a secure connection with your web server. In this case, the SSL encryption is designed to prevent attackers from reading user credentials as they pass by on the network. It is not designed to only allow certain users to connect to your web server.
However, even if an attacker established a secure session with your web server, they would still not be able to get anywhere because the only web page that they would be able to see is the secure NFuse login page that asks them to enter their user credentials. The attacker won't have any valid user credentials, and so they will not be able to continue. Furthermore, the attacker won't be able to read anyone else's credentials because the other users' credentials are encrypted with SSL as they are passed over the network to the web server. This SSL encryption is the same method that every commercial site uses, including online banks, brokers, and the Social Security Administration.
Advantages of Protecting Web Traffic with an X.509 Certificate
- SSL is the industry standard for TCP/IP web site encryption.
- Users can use any standard web browser. No specialized VPN client software is needed.
- X.509 Certificates are available from several vendors.
- The complete process is transparent to the end user.
Disadvantages of Protecting Web Traffic with an X.509 Certificate
- X.509 certificates can be expensive, anywhere from US$100 to US$1000 per year.
- Requires extra configuration of the web server.
- Multiple web servers with their own addresses each require their own X.509 digital certificates.
Segment 2. PN Agent Client to NFuse Web Server
32-bit Windows clients that use the Program Neighborhood Agent ICA client get all of their configuration information from the config.xml file located on an NFuse web server. By default, this communication is an unencrypted HTTP transfer. If the PN Agent clients must cross public networks to receive their configuration information, it is possible to configure them to use SSL encryption. Configuring SSL encryption for the PN Agent clients can be done in two simple steps:
- Secure the NFuse Web Server. Because the PN Agent uses NFuse, you must configure your NFuse web server to be able to use SSL encryption. This means that you must have an X.509 certificate for your web server, as outlined in the previous section. Once you have this, you can configure the "PNAgent" web directory to only be accessed via secure sessions. This directory contains all of the PN Agent files.
- Change the PN Agent configuration URL prefixes to "https." The easiest way to do this is to edit the config.xml file. Full details of that file are covered in Chapter 11, but for the purposes of security, all you need to do is find all of the URL links and change the prefixes from http to https. You can use your text editor's "find and replace" function to do this. All in all, there should be a total of four URLs that you need to update. Each of the following sections of config.xml has a "Location" tag that contains the URL:
- FolderDisplay | DesktopDisplay | Icon
- Request | Enumeration
- Request | Resource
Once you make these updates, the Program Neighborhood Agent client devices will begin using SSL to download their configurations. As with the SSL used in other areas, each client device must have a root certificate installed for the certificate authority that generated the X.509 certificate for you NFuse web server.
Segment 3. ICA Client Device to MetaFrame XP Server
The ICA session communication usually travels across public networks. In order to secure this network link, there are two aspects of ICA session traffic that we need to look at: ICA session creation and ICA session use.
- Session creation. When an ICA session is created, the user credentials are passed from the client device to the MetaFrame XP server. This poses a security risk because stolen user credentials could be used to invoke pirated ICA sessions. Even worse, because many companies are consolidating their user directories, stolen user credentials from an ICA session could most likely be used to access email or other network resources.
- Session use. While an ICA session is in use, a packet sniffer could be used to capture the ICA session packets. Because these packets contain all the keystrokes that a user types, anything that the user types could be compromised, including passwords.
Incidentally, you'll notice that during an ICA session, we're only really worried about the keystrokes, not the screen display data. It is highly unlikely that an attacker could capture the screen shot information from ICA session packets. Screen shot captures would require that the attacker crack the binary ICA protocol, which is highly unlikely. Of course, there are many hacker websites and the Citrix SDK that could change this in the future.
Either way, ICA session traffic must be protected. As with HTTP web traffic, the most effective way to do this is with encryption. Encrypting ICA traffic does not make it any harder for an attacker to obtain, but it does render the data unreadable to an attacker. There are four methods that can be used to encrypt ICA session traffic:
- Create an encrypted tunnel (VPN) between the end user and the server, through which ICA session data flows.
- Encrypt only the ICA traffic with the SecureICA protocol extensions.
- Use the Citrix SSL Relay service to encrypt the ICA traffic with SSL or TLS encryption.
- Use Citrix Secure Gateway to encrypt the ICA traffic with SSL or TLS encryption.
Segment 3 Method 1. Encrypt ICA Traffic with a VPN Tunnel
Third party Virtual Private Networking (VPN) software can be used to create a secure, encrypted "tunnel" from the client device to the MetaFrame XP servers. In these scenarios, each user has VPN client software installed locally on his client machine. This software utilizes the user's local ISP and the Internet to connect to the corporate office. Once this secure connection is established, a private tunnel is created that connects the local user to the corporate network. The local user can access the corporate network as if he was attached to the network locally. In actuality, the VPN software on the user's client device connects to the VPN software at the corporate office via the Internet. All traffic that flows back and forth is encrypted by the VPN software. Through this VPN tunnel, the user can launch MetaFrame XP ICA sessions. The ICA protocol itself is not encrypted directly; rather, it is encrypted by the VPN software automatically.
Figure 15.7: An ICA session encrypted via a VPN tunnel
Many companies choose to use VPNs like this for their users to access MetaFrame XP applications from remote locations. In most instances, VPN access to MetaFrame XP applications is chosen because the company already has an existing VPN solution in place for remote access to other applications. They can easily extend their existing VPN environment to support MetaFrame XP ICA session traffic from remote users.
The major downfall to these types of VPNs is that the VPN client software must be installed on every single client device. Often the configuration of this client software is complex and users are not able to do it on their own. Also, the platforms on which VPN software runs is usually limited. Many times users with Macintosh computers are not able to use the VPN software. Lastly, because the VPN software must be physically installed before it can be used, it is often difficult to use it on a guest computer.
For example, imagine you were at a friend's house when your pager went off, notifying you that there was an urgent work-related matter that needed to be addressed immediately. Fortunately for you, your company built MetaFrame XP servers that will allow you to connect from home. You can go to your friend's PC, log onto the Internet, and begin accessing your MetaFrame XP applications. But, because your company chose to secure their MetaFrame XP servers with a VPN, before you can connect you must first go to your company's intranet site to download and install the VPN software. Only after this is configured are you able to access your MetaFrame XP applications. When you are done, you uninstall the VPN software from your friend's computer.
Advantages of Using VPN Tunnels
- All traffic is encrypted.
- Users are not limited to accessing only MetaFrame XP applications.
- If the VPN is already in place, it can be easily extended to support MetaFrame XP.
Disadvantages of Using VPN Tunnels
- VPN software must be installed on every client device.
- VPN software must be configured before it can be used.
- Some clients are not compatible with VPN software.
- Many corporate firewalls block VPN traffic.
- The VPN software costs money, and may be very expensive.
- Some bandwidth is wasted by the VPN tunnel overhead.
Ultimately, VPNs are good solutions if you have users that will use the same computer over and over to remotely connect to your MetaFrame XP servers. VPNs are not good solutions if remote users will need to connect from many different random computers.
In case you are wondering, Citrix used to sell their own VPN software solution called "Citrix Extranet." While the name of this product suggests that it was a fully integrated solution that combines the benefits of ICA clients and VPN software, Citrix Extranet is little more than a third-party VPN software tool that Citrix OEM'ed from a VPN vendor (V-ONE). Citrix Extranet has been discontinued now that there are better ways of securely accessing remote MetaFrame XP servers. (Keep reading for details.)
Segment 3 Method 2. Encrypt ICA Traffic with SecureICA
Instead of encrypting the entire ICA client to MetaFrame XP server network connection with a VPN solution, it is possible to encrypt just the ICA session traffic itself, as shown in Figure 15.8.
Figure 15.8: Encrypting the ICA session
One method that can be used to encrypt ICA traffic is Citrix's SecureICA protocol extensions. All Citrix ICA clients version 6.01 and above have the native capability to encrypt ICA sessions with SecureICA. For those of you who remember, this used to be a separate purchase option, but it is now a built-in feature in all versions of MetaFrame XP.
The built-in ICA session encryption uses the RSA RC5 encryption model to encrypt ICA session traffic. This encryption scheme uses a 1024-bit key to generate a pair of RC5 keys. From there, 128-bit encryption is used for authentication, with the rest of the ICA session encrypted in both directions at the 40-, 56-, or 128- bit levels (depending on your requirements).
This ICA session encryption can be configured at the server, connection, application, or client device layer. When you configure it, you can choose to enforce minimum encryption levels. For example, you might have a MetaFrame XP server configured to allow users to connect with any level of encryption, but you may publish one sensitive application for which you choose to enforce 128-bit encryption. If a user attempts to connect to that application without an ICA client that can support 128-bit encryption, they will be refused a connection.
This encryption is completely transparent to the user. It does not add any overhead to the ICA network traffic, although it does add a touch of overhead to the server and client processors as they encrypt and decrypt all ICA session data.
If you configure ICA encryption, you will not be able to configure your ICA clients for automatic logon. This is by design, because when automatic logon is used the user credentials are stored locally on the client device and passed to the MetaFrame XP when the session is initiated. This session initiation occurs before the server and client negotiate the secure session so that the credentials are passed in clear text. Citrix figures that if you have configured encryption, there must be a reason, so they don't let you pass credentials in clear text, which means they don't let you configure automatic logon when ICA encryption is used.
Advantages of Citrix SecureICA Session Encryption
- Works on any ICA client platform.
- Transparent to the user.
- Easy to configure.
- Can be configured at multiple layers.
- Does not require an X.509 certificate.
The only real disadvantage to using Citrix's SecureICA encryption is that you need to open a nonstandard port (TCP port 1494, for the ICA session) on your firewall to receive the ICA traffic from the outside clients. This topic will be covered in greater detail in the "Perimeter Security" section of this chapter.
Disadvantages of Citrix SecureICA Session Encryption
- Requires nonstandard ports to be opened on the firewall when ICA clients connect across the Internet.
- Does not verify the identity of the MetaFrame XP server.
Segment 3 Method 3. Encrypt ICA Traffic with the Citrix SSL Service
If you're using Feature Release 1 for MetaFrame XP and your ICA clients are at least version 6.20, you can use Citrix SSL Relay Service to enable the industry standard SSL encryption to secure your ICA session traffic. With Feature Release 2, this service can also be used to encrypt your ICA sessions with TLS.
This encryption has the same effect as the proprietary Citrix SecureICA encryption except that everything conforms to industry standards when SSL or TLS is used. You'll probably have more success implementing SSL or TLS ICA encryption than the native ICA encryption because it can communicate via TCP port 443, which is open on most firewalls.
However, with SSL and TLS encryption, the client device must support the level of encryption that you want to use. For example, Windows 2000 clients will need to download and install the Windows 2000 High Encryption Pack in order to use 128 bit encryption.
Advantages of SSL/TLS Encryption with the Citrix SSL Relay
- Industry standard encryption algorithm.
- Does not require any nonstandard ports to be opened on the firewall.
- Supports verification of the identity of MetaFrame XP servers.
- Each MetaFrame XP server can run its own Citrix SSL Service
- Transparent to the end user.
Disadvantages of SSL/TLS Encryption with the Citrix SSL Relay
- Requires Feature Release 1 for SSL and Feature Release 2 for TLS.
- Requires that the client device supports encryption.
- All traffic must flow through a Citrix SSL Relay server which acts like a SOCKS proxy,
- You must add every SSL Relay Server to each client's server list.
- Requires a dedicated port which cannot be shared with any other SSL services on a MetaFrame XP server.
- Requires an X.509 certificate for each MetaFrame XP server.
- Requires that the client device supports encryption.
- Requires ICA clients version 6.20 or newer for SSL and 6.30 or newer for TLS.
Segment 3 Method 4. Encrypt ICA Traffic with Citrix Secure Gateway
If you're using Feature Release 2 and NFuse, you can use Citrix Secure Gateway 1.1 to encrypt the ICA sessions with SSL or TLS encryption.
Citrix Secure Gateway is a stand-alone gateway server that acts as the liaison between your ICA clients and your MetaFrame XP servers. ICA clients securely communicate with the Citrix Secure Gateway server (which usually sits behind a firewall) and the Citrix Secure Gateway server communicates with the MetaFrame XP servers.
Advantages of Citrix Secure Gateway
- One X.509 digital certificate can be used for multiple MetaFrame XP servers.
- MetaFrame XP server addresses are hidden from the outside world.
- Industry standard SSL or TLS encryption.
- Does not require any nonstandard ports to be opened on the firewall.
- Supports verification of the identity of the MetaFrame XP servers.
- Transparent to the end user.
Disadvantages of Citrix Secure Gateway
- Requires Feature Release 2.
- Requires that the client device supports encryption.
- Requires ICA clients version 6.30 or newer.
- The ICA session path between the Citrix Secure Gateway server and MetaFrame XP server is unencrypted.
- All ICA session traffic must flow through a gateway server.
How to Use the Citrix SSL Relay Service to Encrypt ICA Traffic
The Citrix SSL Relay Service is a Citrix service that acts as a SOCKS proxy. It receives SSL- or TLS-encrypted data from the ICA clients, decrypts it, and forwards it on to the MetaFrame XP ICA session components of the server. When the MetaFrame XP server needs to send ICA session traffic back to the ICA client, the traffic is routed back through the SSL Relay Service to be encrypted. The SSL Relay Service then sends it on to the ICA client.
Figure 15.9: The Citrix SSL Relay Service in action
Let's look at the steps needed to configure the Citrix SSL Relay Service. Once this is configured, your clients can begin to use SSL- or TLS-encrypted ICA sessions. There are seven steps that you need to perform to make this happen:
Step 1. Obtain an X.509 digital certificate.
First obtain an X.509 digital certificate for each MetaFrame XP server that will use SSL or TLS-encrypted ICA sessions.
If the MetaFrame XP server that you are using for the Citrix SSL Relay Service is also running an SSL-secured web server, you can use the same X.509 digital certificate that your web server uses. However, if you already purchased an X.509 digital certificate for your web server but your web server is not the same physical server that you are using for the Citrix SSL Relay, then you will need to purchase an additional X.509 digital certificate for the SSL Relay server, because each digital certificate is server-specific.
You have two options for obtaining the X.509 digital certificates needed for the SSL Relay service on your MetaFrame XP servers. You can either purchase a certificate from a professional certificate authority or you can build your own certificate authority and issue you own certificates.
Option 1. Buy a Digital Certificate
Your first option is to buy an X.509 digital certificate from a real certificate authority. Send the details of each of your SSL Relay servers to the certificate authority and give them some money. They will send you back a digital certificate which will be nothing more than a computer file that contains some information about your server and a very long string of numbers. Because you bought this certificate from a real certificate authority, most client devices or web browsers worldwide will trust that your certificate is valid. Windows clients automatically trust almost every big-name certificate authority. For non-Windows clients, Citrix includes the root certificates (trust) for VeriSign and Baltimore Technologies in the ICA client software.
Advantages of Buying a Certificate from a Real Certificate Authority
- If you buy your certificate from a big name certificate authority, all of your clients will trust it without any additional configuration on your part.
- Clients can connect from guest computers and begin using secure applications immediately.
Disadvantages of Buying a Certificate from a Real Certificate Authority
- You must pay for each certificate.
- There may be a delay in receiving new certificates.
Option 2. Create your own Certificate Authority
Instead of buying certificates from someone else, you can create your own root certificate authority and issue your own X.509 digital certificates. Pick a server in your environments and install a certificate authority service. For example, in a Windows 2000 server, you install a certificate authority just like any other Windows component (Control Panel | Add/Remove Programs | Add/Remove Windows Components | Certificate Services). When you install this component, it will ask you for the details of your certificate authority, including your name, its name, and the desired expiration period for the certificates that you will issue. (See Microsoft article Q231881 for a Certificate Services "How-To" guide.) It doesn't really matter what you enter into these fields. They don't affect anything except the data contained in the certificates that your server issues.
The certificates that you issue with your certificate authority are technically no different than the certificates that a real certificate authority would issue. The only difference is the source. Instead of being issued by "VeriSign," your certificate would be issued by "Brian's Citrix Certificates," or whatever name you choose when installing your certificate authority service.
This is important because every client device in the world trusts "VeriSign," but no client device in the world trusts "Brian's Citrix Certificates." In order to get a client device to trust you, you must install your root certificate (or your new certificate authority's root certificate, in this case). Windows 32-bit ICA clients automatically use the root certificates that are installed into Internet Explorer. Other platforms require that you install the root certificates into the ICA client software itself. Once your root certificate is installed on a client, the client device will trust you, which means that it will trust any certificates that you create. Therefore you can use your certificate authority to mass-produce the X.509 certificates that you need for each MetaFrame XP server that will run the Citrix SSL Relay Service.
Advantages of Creating your own Certificate Authority
- No cost for your certificates.
- You can configure the expiration date and encryption strength of each certificate.
- Fast turnaround time when new certificates are needed.
- You can push your certificate authority's root certificate out with an Active Directory policy or the Internet Explorer Administration Kit.
Disadvantages of Creating your own Certificate Authority
- Your certificates will not be automatically trusted.
- If you lose your certificate server, no new clients will be able to trust the old certificates.
- If a user connects from a new machine, they will have to first install your root certificate before they can securely communicate with you.
Now that you've decided how you will obtain your X.509 digital certificates, let's continue stepping through the process needed to use SSL to encrypt ICA sessions.
Step 2. Configure the SSL Relay TCP listener port.
Configure the TCP port that the Citrix SSL Relay Service will listen on (Start | Programs | Citrix | MetaFrame XP | Citrix SSL Relay Configuration Tool | Connection Tab | Relay Listening Port). By default, this port is 443, which is the industry standard SSL port. In most situations, 443 should work fine. However, the Citrix SSL Relay Service cannot share its port with any other service. This means that if the SSL Relay is installed on the same server that hosts secure web pages via port 443, you will have to change one of them. If you choose to change the Citrix SSL Relay port, you will need to configure your client devices to use the nonstandard port. If you change the web servers SSL port, then your users or hyperlinks will have to refer to the new port in the web address when they request secure pages. For example, if you change the SSL web server port from 443 to 4443, you users will need to request the port number when opening a web page, such as https://www.yourcompany.com:4443.
Step 3. Copy the digital certificate to the SSL Relay server.
Once you configure the SSL Relay port, copy your X.509 digital certificate onto the MetaFrame XP server that is running the SSL Relay Service. Remember that each digital certificate is server-specific and tied to that server's DNS name, so you can't use the same certificate twice and you can't mix them up.
Copy the certificate to the SSL Relay certificate directory on your MetaFrame XP server. By default, this directory is %systemroot%\sslrelay\ keystore\certs. You can change this path with the SSL Relay Configuration Tool (Citrix SSL Relay Configuration Tool | Relay Credentials Tab | Key Store Location). When you specify the path in the configuration tool, you must specify a directory that has two subdirectories under it: \cacerts and \certs. You need to copy your certificate into the \certs directory.
The Citrix SSL Relay Service needs to have a certificate that is in the Personal Electronic Mail (PEM) format. A PEM certificate will have the file extension .pem.
Often , you will receive certificates that are not in the PEM format. They may be in other formats that have different file extensions, such as .CER or .PFX. In order to use these types of certificates, you will need to convert them into the PEM format. You can convert certificates to the PEM format with the keytopem.exe utility, located in the %systemroot%\sslrelay directory of your MetaFrame XP server. To use the conversion utility, open a command prompt and type:
keytopem sourcecertificate.cer newcertificatename.pem
Sourcecertificate.cer is the name of your existing certificate and newcertificate.pem is the name you want for the newly-converted PEM certificate. When you convert your certificate to PEM format, you should always specify the file extension PEM.
If your MetaFrame XP server running the SSL relay is also running an IIS web server that already has an X.509 digital certificate, you can export IIS's certificate for use by the SSL Relay Service (MMC | Add Snap-In | Certificates (for the local computer) | Double click certificate | Details tab | Copy to File button). You must remember to convert the certificate to PEM format after you copy it. Also, remember to configure either the SSL Relay or IIS so that they are both not trying to use port 443.
Step 4. Configure the SSL Relay to use the digital certificate.
Once the digital certificate is copied to the MetaFrame XP server, configure the Citrix SSL Relay Service to use your new certificate (Citrix SSL Relay Configuration | Relay Credentials). Choose your certificate from the drop-down list and enter the password if needed. Once you click "OK," the Citrix SSL Relay Service will be installed and started on that server. This service works just like any other service. It will show up in the list of Windows services.
Step 5. Verify the SSL Relay Cipher Suites.
After the certificate is installed, you should verify that you have the correct cipher suites enabled (Citrix SSL Relay Configuration Tool | Ciphersuites tab). A cipher suite is a specific encryption/decryption algorithm. When using SSL, the client and server look at all the available cipher suites and mutually agree on one. Different cipher suites have different properties, such as encryption strength or speed. Any client that connects to the Citrix SSL Relay Service must support at least one of the cipher suites that you have enabled. There is no way to add additional cipher suites. By default, the Citrix SSL Relay Configuration enables all of the available cipher suites, which should be fine for most environments.
Step 6. Configure SSL Relay target addresses.
Once the certificate is installed and the service is running, you need to edit the target addresses for the SSL Relay Service (Citrix SSL Relay Configuration Tool | Connection Tab). The SSL Relay only sends decrypted packets to IP addresses and ports listed here. By default, the local server's primary IP address and the Citrix XML service port are listed.
Since you want to use the SSL Relay Service to send decrypted ICA packets to the local MetaFrame XP server, you need to add the TCP port that ICA uses, which is 1494 unless you changed it (Highlight the IP Address | Click "Edit" | Type in new destination port 1494 | Click "Add" | Click "OK"). When done, you should see both the XML service port (default 80) and the ICA service port listed next to your server's IP address.
Configure the SSL Relay service to forward packets to any host or any port by clicking the corresponding "Any" button when you are adding an address or port. However, by doing this you increase the risk that unencrypted data will be sent to the wrong location.
Step 7. Configure your ICA client devices to use SSL for ICA encryption.
After you'ave performed the previous six steps, your MetaFrame XP server will be ready to support SSL- or TLS-encrypted ICA sessions. The only thing left to do is configure your ICA clients to connect via SSL. For information regarding specific client configurations, refer to Chapter 10. If you're using NFuse Classic or the Program Neighborhood Agent to provide access to your MetaFrame XP servers, you are in luck because you can change the ICA client settings centrally. Once you make the change, all client devices automatically receive the new settings the next time they connect. Let's take a look at what it takes to configure NFuse Classic and the Program Neighborhood Agent to communicate via SSL-encrypted ICA sessions. We'll start with NFuse.
Configuring NFuse to use SSL Encrypted ICA Sessions
Remember that NFuse Classic's main role is getting ICA sessions started. You can enable SSL encryption of your ICA sessions by setting just one configuration item. Edit the NFuse.conf file on your NFuse web server. Refer to Chapter 11 for details on this file. Locate the "AddressResolution Type" setting. Ensure that its value is set to DNS (or DNS-port if your ICA protocol is configured for a port other than 1494). The new line should look like this:
As with all NFuse settings, you will need to stop and start the web server service for this change to take effect. This change will ensure that the MetaFrame XP server addresses passed to clients are the full DNS names instead of the IP addresses.
Configuring the PN Agent to use Encrypted ICA Sessions
Configuring the Program Neighborhood Agent to use SSL encryption for ICA sessions is easy. If the published application is configured to use SSL (CMC | Right-click Published Application | Properties | ICA Client Settings Tab | Enable SSL), the PN Agent will automatically use SSL.
How to use Citrix Secure Gateway to Encrypt ICA Traffic
A Citrix Secure Gateway (CSG) server can support thousands of users simultaneously accessing multiple MetaFrame XP servers as seen in Figure 15.10.
Figure 15.10: How CSG is used
Using CSG is completely transparent to your users. In fact, because it's so easy to use, CSG is widely thought of as the "VPN" killer. In order to understand CSG, let's take a look at how it works.
How Citrix Secure Gateway Works
Citrix Secure Gateway is made up of two components: the Citrix Secure Gateway server and the optional Secure Ticket Authority:
- Citrix Secure Gateway server. This is a dedicated server that acts as the proxy between users and MetaFrame XP servers. Since a single CSG server can interface to multiple MetaFrame XP servers, you can have a fully SSL/TLS-encrypted environment without needing certificates for all of your individual MetaFrame XP servers.
- Secure Ticket Authority. The Secure Ticket Authority (STA) is an optional component of CSG that runs on a separate server. The STA can be used to generate tickets that are sent to the user instead of credentials and server information. Using a STA renders an intercepted packet useless, since it would only contain a temporary ticket number instead of real data. To see how this works, let's take a detailed look at how CSG functions.
In most environments, CSG is used in combination with NFuse Classic. For this reason, you'll notice that the first several steps that take place to start an application in a CSG environment are identical to when they are started in NFuse Classic environments.
Figure 15.11: Citrix Secure Gateway in action
- A user with a web browser and an ICA client requests the NFuse Classic portal web page by typing in a URL.
- The web server sends down the HTML login page via the HTTP protocol. In secure environments, this can be via the HTTPS protocol.
- The web user types in their credentials and clicks the "Submit" button which sends them to the web server.
- The web server forwards the user's information to a MetaFrame XP server running the Citrix XML service.
- The MetaFrame XP server validates the credentials and retrieves the user's list of applications for the server farm.
- The MetaFrame XP server sends the application list to the NFuse web server.
- The NFuse web server builds a web page that contains all of the user's application icons. Each icon is hyperlinked with its application properties.
- The web page is sent to the user's browser via the HTTP or HTTPS protocol.
- The user selects an application to run by clicking on an icon in the web browser.
- The web browser sends a request to the web server for the link that the user selected.
- The NFuse Java Objects on the web server receive the request for the application. They forward the request on to the Citrix XML service running on a MetaFrame XP server.
- The Citrix XML service returns the IP address of the least-loaded server.
- The NFuse Java Objects send the IP address to the Secure Ticket Authority (STA).
- The STA saves the IP address into memory and generates a random ticket number.
- The STA sends the ticket number to NFuse.
- NFuse retrieves the ICA file template. The ticket number is added to the ICA file in place of the user's credentials. The fully qualified domain name or DNS name of the Citrix Secure Gateway is added in place of the MetaFrame XP server.
- The custom-built ICA file is sent to web browser on the client device.
- The web browser receives the ICA file and passes it to ICA client software that is also loaded on the ICA client device.
- The user's local ICA client starts the MetaFrame XP session with the information contained in the custom ICA file. Since the server specified is the Citrix Secure Gateway, the client contacts the CSG.
- The SSL/TLS handshaking process takes place. The ICA client verifies that the CSG is valid based on its installed root certificate.
- The CSG passes the ticket number to the STA.
- The STA examines ticket and (if it's valid), sends the IP address of the MetaFrame XP server to the CSG.
- The CSG establishes an ICA session with the MetaFrame XP server. The CSG then encrypts and decrypts the ICA session traffic, passing decrypted traffic to the MetaFrame XP server and encrypted traffic to the ICA client.
As you can see, the way that the Citrix Secure Gateway works is pretty simple. Let's now take a look at how you can get it installed in your environment.
Step 1. Install the (Optional) Secure Ticket Authority
We mentioned previously that using the STA with CSG is optional. While this is true, the advantages of using the STA far outweigh the disadvantages. Before we look at how the STA is installed, let's take another look at how CSG works with a focus on how the STA helps to secure the environment.
Think back to how NFuse works. After a user logs in, they click a hyperlink to launch an ICA session. The NFuse web server builds a custom, dynamic, behind-the-scenes ICA file and sends it down to the client. That ICA file has the user's credentials imbedded into it since the NFuse server remembered the user's credentials because an NFuse Session Object was set when the user logged into the NFuse web page. The user's local ICA client software then launches the ICA session with the information (and credentials) from that ICA file.
This leaves a gaping security hole. Instead of clicking an NFuse application hyperlink to launch an application, a savvy end user could right-click the link, choose "Save target as..." from the context menu, and save a local copy of the ICA file. That ICA file could then be used to access the application at any time. Even worse, because that ICA file contains that user's credentials, it could be passed around and used by any user.
To combat this shortcoming, Citrix Secure Gateway uses the Secure Ticket Authority to create tickets. Ticketing was first introduced with NFuse 1.5 several years ago, and CSG ticketing is still based on that technology. Remember from Figure 15.11 that when CSG and STA are used, the user clicks on a hyperlink to launch an ICA session from the NFuse web page and the NFuse server builds a custom ICA file for the user, as usual.
However, instead of placing the user's credentials and the target MetaFrame XP server in the ICA file, NFuse sends the information to the STA. The STA then creates a totally random 30-character string called a "ticket" that it associates with those specific credentials. The STA maintains a list in memory that maps authenticated users, their servers, and their ticket numbers. It then returns the ticket to the NFuse web server.
When the ICA file is created and sent down to the user's client device, it contains the 30-character ticket instead of the actual user credentials. It also contains the name of the CSG as the server instead of the actual MetaFrame XP server. When the client device receives the ICA file, an ICA session is launched as usual. The ticket number is sent to the CSG server, and that server communicates with the STA to retrieve the actual user credentials based on the user's ticket number.
By using ticketing, a user's real credentials are not sent across the network multiple times and they are not placed in the ICA file. But wait! It gets even cooler for the following two reasons:
- Tickets are configured with a timeout period.
- Tickets are only valid for one time use.
Every ticket is configured with a timeout period (based on settings of the STA server). Once a certain amount of time passes after the ticket has been created, the STA destroys the ticket along with the associated user credentials. For example, if the timeout is set for 100 seconds, a user that "right-click" captures the dynamic ICA file from the NFuse web page will not be able to use that file after 100 seconds have passed because the STA server would not have the user credentials associated with the ticket number contained in the ICA file.
One of the great things about this timeout feature is that the ticket timeout period begins when the ticket is created. The ticket is created when a user clicks a hyperlink to launch an ICA session, not when the user first accesses the application list webpage. Because of this, there is no risk that a user will log in to the web page and then wait too long, causing the ticket to expire.
The other major advantage to using the STA for ticketing is that each ticket can only be used once. After a user logs on with a ticket, the STA destroys the 30-character ticket and the associated user credentials. Therefore, even if the timeout for tickets has not expired, a single NFuse-generated ICA file cannot be used by multiple users.
Advantages of STA Ticketing
- Very cool.
- Protects ICA files from users' friends.
- Tickets are only valid once.
- Tickets expire after a configurable amount of time.
- Clear text user credentials are not placed in the ICA files.
- Clear text user credentials are not passed across the network when ICA sessions are launched.
Disadvantages of STA Ticketing
- Unencrypted data is still sent over the network once.
- NFuse is required.
In reality, the Secure Ticket Authority is nothing more than a DLL installed into the \scripts\ directory of an IIS web server running on Windows 2000 with Service Pack 2 or newer. When you install it (from the "Components" section of the main MetaFrame XP SP-2/FR-2 splashscreen), you will need to know the path to your IIS scripts folder (%systemroot%\inetpub\ scripts by default).
As soon as the STA is installed, the STA configuration tool is launched. You will need to specify an STA ID that is a unique character string made up of a maximum of 16 uppercase and numeric characters. This ID is used to differentiate multiple STA servers in your environment. This name doesn't really matter, and the default of "STA01" should be fine.
If you click the "advanced options" of the STA configuration screen, you are also given the option to specify the timeout period of the tickets that this STA generates and the maximum number of concurrent tickets that can be generated.
By default, the ticket timeout is 10000 milliseconds, or 100 seconds. This should be acceptable for most environments, although you can change it at any time if you need to (Start | Programs | Citrix | Citrix Secure Gateway | Secure Ticket Authority Configuration).
The STA is configured by default for a maximum of 100,000 tickets. You can drop this number considerably. Since this number only affects concurrent tickets (not total), it should roughly correspond to the number of users you have. Even with a few users, you can safely drop this number to about 1,000. An entry of 1,000 will be enough tickets that you will never run out but not enough that a brute-force attacker could find a way into your server.
If you use the IIS Lockdown Tool on to secure IIS on your STA server, you should use the same settings that you did for NFuse as outlined earlier in this chapter.
Step 2. Build your Citrix Secure Gateway Server
Once your STA is up and running you can build your CSG server. This server can just be a standard Windows 2000 server with Service Pack 2, although it must be a physically different server from the STA.
The exact hardware requirements vary depending on your exact environment and how bust your users are. However, you'll be pleasantly surprised to know that CSG scales fairly well. In the real world, you can fit 700-1000 users on a dual 1.0GHz processor CSG server.
Step 3. Obtain and Apply a Digital Certificate
The CSG server is the one that needs a digital certificate. (The STA does not need one, since it doesn't communicate directly with clients.) Follow Step #1 from the previous section ("How to Use the Citrix SSL Relay Service to Encrypt ICA Traffic") for detailed instructions about obtaining and installing this certificate.
Step 4. Install the Citrix Secure Gateway Service
You can install CSG from the SP-2/FR-2 splashscreen or by running "csg_gwy.msi." If you've decided to use CSG without using a STA, the CSG will operate in "Relay Mode." To configure your CSG for Relay Mode, install it using the following command:
Msiexec.exe /i csg_gwy.msi RELAYMODE=1
Step 5. Configure the Citrix Secure Gateway
Similar to the STA installation, the CSG configuration wizard launches as soon as the CSG installation is complete. The main option that you need to configure is the address or addresses of the STA servers that you will use. From a sizing standpoint, even the largest environments only need a single STA server. However, for purposes of redundancy, you can have multiple STA servers. (See Chapter 17 for more information.)
Keep the following points in mind as you configure CSG:
- You need to specify the IP addresses and ports that the CSG will watch. Ordinarily this would be the external interface of the server over port 443.
- The "Worker Threads" option allows you to specify how many threads the CSG service will use. The default value of 8 should work for up to two processors. You should double this to 16 on quad-processor servers.
- The connection timeout that you specify in milliseconds only affects the timeout of the security handshaking process. It does not affect overall session times. The default value of 10,000 (100 seconds) should be sufficient for most environments.
- You should also specify a connection limit to ensure that you do not get too many users on your CSG server. You can specify a connection limit and a resume limit. When the number of concurrent users hits the connection limit, all new connections will be refused until the number of connections falls to the resume limit.
- When you configure CSG, a single server can only support one secure protocol. If you want to support both TLS and SSL, you'll have to add another CSG server.
- Like the SSL Relay Service, CSG has the ability to use multiple cipher suites. Unless you have direction from your internal security team, you should keep the cipher suite settings configured for "all."
- When asked to exclude certain IP addresses from the CSG activity log file, think about anything in your environment that might access the server that you do not want to log. You don't want your CSG logs filling up because someone's copy of "What's Up Gold" keeps pinging your CSG server every three minutes.
- When you configure error logging, keep in mind that CSG errors are written to the Windows event log, not to standard log files. If you select one of the more robust logging options, be sure that your Windows event logs can handle the amount of information.
- After you finish configuring CSG, you should reboot it for the changes to take affect.
Step 6. Configure NFuse Classic for use with CSG
If you're using CSG as it was fully intended (complete with the STA), you'll need to configure NFuse so that it knows that it should use CSG. As with the other NFuse Classic 1.7 options, you can configure NFuse CSG options via the administrative web pages (NFuse Admin Web Pages | Server-Side Firewall | Secure Gateway Server) or by editing the NFuse.conf file directly. See Chapter 11 for more information about configuring NFuse.
First put the NFuse web server into CSG operating mode. This is done with the following line in the NFuse.conf file:
Then, to complete the configuration of NFuse, you need to know the addresses of both the STA and the CSG. You can point a single NFuse web server to up to 256 different Secure Ticket Authorities (in case you want a really redundant environment). This is done via the NFuse session field called "NFuse_CSG_STA_URLx." (The "x" is a number from 1 to 256.)
For example, to configure two STAs, add or modify the following two lines in the NFuse.conf file:
Then, use these two lines in the NFuse.conf file to specify the name and port of the CSG server:
After you enter these settings, you're all set. Stop and start the web server service and you can begin using CSG. As you use CSG, you'll notice that your NFuse web pages (and the entire experience) is the same as when CSG was not used. While this is convenient for your users, you may wonder if CSG is actually doing anything. The easiest way to check this is to go into the ICA connection manager on your client device while you have an ICA session opened. You should see that your session is encrypted via 128-bit encryption.
Securing Back End Network Communications
Thinking back to Figure 15.6, we can now start to look at what needs to be done to secure the back-end network communications. In MetaFrame XP server farms, IMA and XML traffic is passed between various servers. By default, all of this communication is in clear text, unencrypted and unsecured.
Most administrators ignore the back-end network segments when evaluating security. This is usually because they don't think that there is a need to secure those segments since all of the servers are located in the same data center or within the same corporate network and so are generally considered secure.
However, there are many environments in which a single MetaFrame XP server farm will span multiple locations, causing back-end server communication security to be an issue. Within MetaFrame XP environments, there are four types of backend network communications that can be secured:
- Segment 4. NFuse web server to the MetaFrame XP XML server.
- Segment 5. MetaFrame XP farm servers to the IMA data store.
- Segment 6. MetaFrame XP farm servers to the zone data collector.
- Segment 7. The Citrix Management Console to the MetaFrame XP host server.
Segment 4. NFuse Web Server to MetaFrame XP Server
NFuse web servers must communicate with the MetaFrame XP IMA service in order to build lists of published applications and content for users that log in. The NFuse servers access this data from the MetaFrame XP servers via the Citrix XML service. Much of this data is sensitive in nature, including user credentials and application set information. By default, this information is not encrypted (with the exception of passwords, which are encrypted at a basic level). Because this is standard XML information, it can be very easy to read if intercepted.
If you determine that the network segment between your NFuse web server and your MetaFrame XP server is not secure, there are two things that you can do:
- Encrypt the Citrix XML traffic on the network segment with SSL or TLS.
- Remove the network segment by running the NFuse web server on a MetaFrame XP server.
Method 1. NFuse Web Server to MetaFrame XP Server SSL Encryption
In scenarios in which a public, unsecured network separates the NFuse web server and the MetaFrame XP server, you can configure NFuse so that all traffic traveling between the two servers is encrypted. Remember that NFuse 1.7 can be configured to communicate with multiple MetaFrame XP servers for load balancing. In this case, X.509 digital certificates service must be installed and configured on each MetaFrame XP server that communicates with the NFuse web server.
To allow NFuse to use SSL encryption for its communication with the Citrix XML service, all you have to do is edit the NFuse.conf file on your NFuse web server. See Chapter 11 for detailed information about NFuse and the use of this file.
With NFuse 1.7, you have two choices for encrypting this traffic. If you're running the Citrix SSL Relay service, locate the following line in the NFuse.conf file:
Change the "HTTP" to "SSL," so that the line looks like this:
Then, in order to specify your Citrix XML servers running the Citrix SSL Relay service, add the following two lines:
Alternately, if you are not using the Citrix SSL Relay service, you can change the transport setting to "HTTPS," so that the line looks like this:
With the "HTTPS" setting, NFuse will use the regular Citrix XML servers and ports that you specified in the SessionField.NFuse_CitrixServer and SessionField.NFuse_CitrixServerPort lines.
Just as with any other changes that you make to the NFuse.conf file, you must stop and start the web server service for these changes to take affect.
Advantages of Encrypting the NFuse to MetaFrame XP Link
- Ultimate security.
- Works well when NFuse and MetaFrame XP servers are on opposite sides of an unsecured network.
Disadvantages of Encrypting the NFuse to MetaFrame XP Link
- Extra configuration is needed.
- One X.509 certificate is needed for each MetaFrame XP server that communicates with NFuse.
- Security is usually not needed at this level because most communication is intra-site, or site-to-site with private, secure lines.
Method 2. Use the Same Server for NFuse and MetaFrame XP
A simple way to eliminate the risk of a network segment attack between the NFuse web server and the MetaFrame XP server is to eliminate that network segment altogether. You can do that by running the NFuse web server on the same physical machine as the MetaFrame XP server. When you do this, the Citrix XML service is still used, but there is no need for its data travel to across the network.
Advantages of Running NFuse on a MetaFrame XP server.
Disadvantages of Running NFuse on a MetaFrame XP server.
- Does not scale very well.
- Single point of failure.
- Does not allow the web pages and the SSL encrypted ICA sessions to both use the default TCP port 443.
Segment 5. MetaFrame XP Server to the IMA Data Store
All communication between MetaFrame XP servers and the IMA Data Store is done via standard database communication traffic. There is nothing of particular value in this communication, but it can be encrypted if needed. If you decide to encrypt, you must do it with the native ODBC database tools and software. The database communication encryption is not a feature of MetaFrame XP.
Segment 6. MetaFrame XP Server to Zone Data Collector
All zone update information is transferred between zone data collectors and MetaFrame XP servers via TCP port 2512. This communication is also done in clear text. However, this information does not contain any potentially dangerous information; it is not valuable to attackers. If you must encrypt it, then do it with non-MetaFrame products, such as a VPN or IPSec.
Segment 7. CMC to MetaFrame XP Host Server
The CMC communicates over TCP port 2513. This communication is done in clear text, and it contains logon information including the CMC user's name and password as well as any configuration done through the CMC, such as group rights and published applications.
This security risk can be avoided by running the Citrix Management Console locally on MetaFrame XP servers. It can be made available to remote administrators by publishing the CMC itself as an explicit ICA application. In doing so, the standard ICA session security procedures will be used. See Chapter 16 for details about publishing the CMC.
Network Perimeter Security / Firewall Configuration
In this section, we won't spend time talking about the importance of firewalls and why you need them. The truth is that most environments have them. We only care about using them with MetaFrame XP. There are really three questions that get asked when using firewalls in MetaFrame XP environments:
- Where should I put the MetaFrame XP servers in relation to the firewall?
- What ports do I need to open on the firewall?
- How do I make the MetaFrame XP servers work if the firewall is using Network Address Translation (NAT)?
Let's examine each of these questions.
MetaFrame Server Placement in Relation to the Firewall
When deciding where to put MetaFrame XP application servers that will provide ICA access to applications across the Internet, there are three basic options:
- MetaFrame XP servers outside the firewall.
- MetaFrame XP servers inside the firewall.
- MetaFrame XP servers in a DMZ.
Option 1. MetaFrame XP Servers outside the Firewall
Placing your MetaFrame XP servers outside of the firewall exposes them to all the attackers on the Internet. However, if a server is breached, it remains on the outside of the firewall, severely limiting any potential damage to sensitive resources on the inside of the firewall.
Figure 15.12: A MetaFrame XP server outside the firewall
This configuration is primarily used when MetaFrame XP applications are stand-alone (do not need to access any data from the inside of the firewall).
A major downside to putting MetaFrame servers on the outside of the firewall is that any MetaFrame XP application that accesses resources from servers on the inside of the firewall will need to have a port opened on the firewall. The more ports that are opened increase the likelihood that a breach of the firewall could occur.
Another thing that people worry about is that Microsoft software is not exactly known for being bulletproof. Very few organizations feel comfortable having unprotected Windows servers sitting on the Internet.
Putting MetaFrame XP servers on the outside of the firewall raises complexities if you have users on the inside that need to access the MetaFrame XP servers. Should they go through the firewall in the opposite direction? Should you have a MetaFrame XP server farm that has some servers on the inside and others on the outside? When users from both inside and outside need to access MetaFrame XP application servers, the servers are usually not put on the outside of the firewall.
Advantages of Placing MetaFrame XP Servers Outside the Firewall
- Works well if no internal users will need to access the servers.
- If the MetaFrame XP server is compromised, the inside network is not affected.
Disadvantages of Placing MetaFrame XP Servers Outside the Firewall
- Application holes need to be opened in the firewall.
- It can be difficult for some applications on the MetaFrame XP server to get through the firewall to the resources they need on the inside.
- If users connect to the MetaFrame XP servers with the same user accounts that they use on the inside, they must authenticate to the MetaFrame XP server through the firewall.
Option 2. MetaFrame XP Servers inside the Firewall
Most companies choose to place their MetaFrame XP servers inside the firewall. By doing this, they are leveraging the true definition of the "firewall," as it will take the brunt of all Internet traffic and attacks.
Figure 15.13: A MetaFrame XP Server behind the firewall
This tends to be the most secure of all possible configurations because the only holes that need to be opened on the firewall are for ICA traffic to MetaFrame XP servers.
Advantages of Placing MetaFrame XP Servers Inside the Firewall
- Only the MetaFrame server addresses and ports need to be opened on the firewall.
- Very Secure.
Disadvantages of Placing MetaFrame XP Servers Inside the Firewall
- If the MetaFrame server is compromised, other servers behind the firewall could be compromised.
- The firewall must be configured to allow ICA traffic to flow to the MetaFrame XP servers.
Option 3. MetaFrame XP server in a DMZ
Some firewalls allow for the configuration of a DMZ (Demilitarized Zone). A DMX can also be created with a pair of firewalls. This DMZ is like a combination of the two above methods. The MetaFrame XP servers aren't totally exposed on the outside of the firewall, but they also do not have free access to devices on the inside of the firewall. In this configuration, no outside traffic has direct access to devices on the inside of the firewall. Instead, the firewall is configured so that outside clients can access only the MetaFrame XP servers in the DMZ. Those MetaFrame XP servers, in turn, can access (through the firewall) network resources on the inside.
Figure 15.14: A MetaFrame XP server in the DMZ
Advantages of Placing MetaFrame XP Servers in the DMZ
- Balance between no access and all access.
Disadvantages of Placing MetaFrame XP Servers in the DMZ
- Most complex firewall configuration.
Firewall Ports Configuration for MetaFrame XP Environments
If you decide to put your MetaFrame XP server behind a firewall or in a DMZ, there are several TCP ports that must be configured on the firewall (if you're not using Citrix Secure Gateway).
- Port: 1494
- Direction: Inbound
- Destination: All MetaFrame Servers
- Description: ICA port needed for ICA sessions
- Port: 1023 and above
- Direction: Outbound
- Destination: ICA Client
- Description: MetaFrame XP will dynamically select a unique port for each ICA session. This port configuration is standard practice on firewalls.
- Port: 80
- Direction: Inbound
- Destination: NFuse Web Server
- Description: If you are using NFuse, and your NFuse server is behind the firewall, you will need this port to allow users to access the website.
- Port: 80
- Direction: Inbound
- Destination: Citrix XML Service on at least one MetaFrame XP Server
- Description: This port is needed on one or more MetaFrame XP servers that will be providing the application lists to external clients. If all external clients will use NFuse, this port will not be needed.
- Port: 443
- Direction: Inbound
- Destination: NFuse Web Server or MetaFrame XP Server
- Description: If you are using an SSL connection to an internal NFuse server, or you are encrypting ICA traffic via SSL, then this port is needed. SSL session encryption uses this port in place of 1494.
Figure 15.5: Firewall port usage
Network Address Translation at the Firewall
Most companies that use firewalls configure them to do Network Address Translation (NAT). This allows internal servers to be configured with private IP addresses that are not valid to the outside world. Because all network traffic between the inside servers and the outside world is channeled through the firewall, the firewall maintains two addresses for each server. One address is valid to the outside world; the other address is valid to the inside network. When a request for the server hits the firewall from the outside, the firewall translates the address to the internal address of the server before passing it on to that server. Just the same, when the internal server sends network data to an external address, the firewall changes the existing sender's address (the server's internal address) to the server's valid external address. The server has no idea that its address is not valid to the outside world. Using NAT allows servers on the inside to be protected from the outside world by forcing all communication to travel through the firewall.
Figure 15.16: Network address translation at the firewall
The advantage to using NAT is that because the internal IP addresses of the servers are not valid on the outside, it is technically impossible for an attacker to find a "back door" into the network. All traffic must flow through the firewall because the internal addresses are not valid to the rest of the world. Also, by using NAT, companies do not have to register the IP addresses for all of their internal devices.
In non-MetaFrame XP environments there are usually no issues with NAT because the internal server has no need to know that its IP address is being changed by the firewall. This is not the always the case in MetaFrame XP environments. To understand why, let's consider the following scenario.
A Citrix ICA client device connects to a MetaFrame XP server via the Internet. The MetaFrame XP server is accessible to the Internet via the IP address 188.8.131.52. A firewall running NAT sits between the Internet and the MetaFrame XP server. The MetaFrame XP server's IP address is configured to be 10.1.1.1. The firewall automatically translates between the two IP addresses for traffic going between the Internet and the MetaFrame XP server. This scenario is outlined in Figure 15.17 (facing page).
Figure 15.17: The firewall translates the ICA client's: request
If an ICA client on the outside of the firewall connects directly to the MetaFrame XP server, there will be no issues. The firewall will use NAT to translate between the internal and external addresses of the MetaFrame XP server. In this case, the ICA client and the MetaFrame XP server do not know that the address is being translated. All translation occurs transparently at the firewall, and all is well.
However, if the external ICA client queries the MetaFrame XP server farm (via the Citrix XML service) to connect to a load-balanced published application, the user's request is sent in the form of data from his client's IP address to the server, at 184.108.40.206. The firewall gracefully intercepts that data and sends it on to the MetaFrame XP server's actual address, 10.1.1.1.
The MetaFrame XP server receives the data at its address of 10.1.1.1. It looks at which published application the user wants to connect to, queries the zone data collector, and finds the IP address of the MetaFrame XP server with the least load. In this case, the server with the least load is 10.1.1.1. The MetaFrame XP server sends this information back to the client, letting the client know that he can connect to 10.1.1.1.
The firewall will also intercept this data on its way to the client before it is sent back across the Internet. The firewall will change the sender server's address (the return address) from 10.1.1.1 to 220.127.116.11. However, the firewall will not change the actual content of the data itself. Think of it like this: A firewall running NAT will always translate the "to" and "from" addresses of the data. It will not scan the data to see if there is anything else that needs to be changed.
In this case, the ICA client will receive the data from the MetaFrame XP server without incident. That data will show a return address of 18.104.22.168. However, the content of the data will contain instructions for the client to connect to the server via 10.1.1.1. This IP address is not valid to the outside world. The ICA client will not be able to connect.
In order for the ICA client to connect to a MetaFrame XP server behind a firewall using NAT, the MetaFrame XP server needs to know that the firewall is translating its IP address via NAT. It also needs to know what the translated address is. This "alternate" translated address can be configured on the MetaFrame XP server with the altaddr command-line utility.
Using the ALTADDR command
The altaddr command-line utility is used to inform the MetaFrame XP server that some clients may request information about the server requiring an address other than the server's real IP address. This command has the following syntax:
altaddr /set ipaddress
You can use "altaddr /?" to view the full options and syntax of the command. You can specify different alternate addresses for different NICs for servers that have multiple NICs.
In our example from the previous page, we would execute the following command from the command prompt of the MetaFrame XP server:
altaddr /server:ourservername /set 22.214.171.124
After this command has been executed (and after the server has been rebooted or the IMA service stopped and started), the MetaFrame XP server will determine which address ICA clients are looking for and return either the "real" IP address (in this case 10.1.1.1) or the "alternate" IP address (in this case 126.96.36.199).
The altaddr command line utility stores the alternate address in the registry in the following location.
Key: HKLM\system\CurrentControlSet\Services\ICABrowser\ Parameters\AlternateAddress\TCP
Data: IP address of the alternate address.
It is important to note that the altaddr command is used to configure IP addresses that are not local on the MetaFrame XP server. There is no need to open the network properties dialog box of the MetaFrame XP server to add another IP address to the network card. Remember that the firewall running NAT will make sure that the traffic gets to the proper server. All the altaddr command does is enable the MetaFrame XP server to provide an additional alias address to ICA clients. Configuring alternate addresses will not break any internal clients that already connect via the real IP address.
You may be wondering how the server knows when to provide the alternate address or the standard address. In actuality, it's the ICA client configuration that dictates whether the client will request the server to return to the standard address or the alternate address. For example, in the Windows ICA client, the "server location" section of a connection's properties has a "Firewalls..." button. This button leads to a screen that has a checkbox labeled "Use alternate address for firewall connection."
It is easy to be confused as to exactly which situations require the configuration of an alternate address. For example, if you have users that connect directly to one server via an IP address, the alternate address is not needed. An easy way to remember it is that the alternate address is only needed if the MetaFrame XP server will be providing its own IP address to the ICA client through a NAT firewall. The alternate address is not needed if the ICA client already knows the IP address of the MetaFrame XP server.
Some firewalls can also be configured for port translation in addition to address translation. This can be used if you have multiple MetaFrame XP servers that you would like to make available via the Internet on a single IP address. Look at the environment in Figure 15.18.
Figure 15.18: Port translation at the firewall
This company has three MetaFrame XP servers. All of them have private IP addresses and host ICA sessions via port 1494. When this company extended their environment to the Internet, they only had a single external IP address available: 188.8.131.52. Since they would like external users to be able to access all of their servers, they configured different ports on the firewall to map to different servers. For example, port 5000 on the firewall maps to port 1494 on Server 1 at 10.1.1.1 on. Port 5001 maps to 10.1.1.2 port 1494 and port 5002 maps to 10.1.1.3 port 1494.
In this situation, the altaddr command is also used. If you're using it to map a port, simply append the port number to the end of the IP address. For example:
altaddr /server:server1 /set 184.108.40.206:5000
In this situation, you wouldn't have to configure the server for port 1494 since that's the port that the ICA sessions are already using. (You would, of course, still need to manually configure the 220.127.116.11:5000 to 10.1.1.1:1494 mapping on the firewall.)
While this solution may not be pretty, it does allow users from outside the network to access any MetaFrame XP server via that single 18.104.22.168 IP address. Of course all of the users inside the network continue to access the servers as usual.
Advantages of Port Translation
- Multiple MetaFrame XP servers can share the same external IP address.
- The servers' real IP addresses are not exposed to the outside world.
Disadvantages of Port Translation
- It requires a firewall that can support address and port mapping.
- Client devices must be configured to connect to the non-standard port.
Port translation is not common in the real world, because most people in this situation use Citrix Secure Gateway.
Using NFuse with Alternate Address Mapping
Since it's up to the client device to determine whether it needs the "alternate" address or the "standard" address from a MetaFrame XP server, the NFuse web pages must be configured to tell the ICA client which address to ask for. In the past, you had to manually modify the default NFuse web pages to use different ICA template files depending on the IP addresses of the clients. With NFuse 1.7, this functionality is built in.
Configuring Default Address Behavior
On the "Server-Side Firewall" configuration page (NFuse Admin Web Pages | Server-Side Firewall), the first section titled "Default address translation setting" allows you to specify what type of address is provided to NFuse clients for the MetaFrame XP servers. There are four options:
- Normal Address.
- Alternate Address.
- Citrix Secure Gateway.
- Translated Address.
The Normal Address setting causes the NFuse server to send the client the actual address of the MetaFrame XP server. As detailed in Chapter 11, the exact format of that address (IP address or fully qualified domain name) and whether a TCP port is supplied is dictated by the "AddressResolution Type" entry in the NFuse.conf file.
The Alternate Address setting causes the NFuse server to send the client the alternate address of the MetaFrame XP server as configured on each server via the altaddr command.
The Citrix Secure Gateway setting causes the NFuse server to send the client the address of the Citrix Secure Gateway server instead of the MetaFrame XP server's address. In order for this option to work, NFuse must be configured for use with CSG as previously detailed in this chapter.
The Translated Address option uses a network address mapping table to map specific external IP addresses or server names to specific internal IP addresses or server names. This table is maintained by NFuse. Conceptually, this mapping is identical to the "alternate" address mapping, except that translated addresses are managed centrally on the NFuse web server whereas alternate addresses are manually configured at each server. If you plan on using NFuse for outside clients exclusively, you will not need to use the altaddr command. (If you plan to use CSG and NAT together you'll still have to use the altaddr command.)
In order for the translated address option to function, Enter at least one pair of translated addresses. (This is done further down the "Server-Side Firewall" NFuse admin web page via the "MetaFrame server address translation map" section.) To use this map, simply specify the actual MetaFrame XP server address and port and the associated translated (or external) address and port. These addresses must be fully qualified domain names or IP addresses, again depending on the "AddressResolutionType" entry in the NFuse.conf file.
For example, if you flip back to the altaddr diagram in Figure 15.17, you would add a translation entry of 10.1.1.1:1494 for the server address and port and 22.214.171.124:1494 for the translated address and port. You can add as many entries as you want, which is a good thing since you'll need one for each MetaFrame XP server that is accessible from the outside if your firewall is using NAT.
Applying Conditional Address Translation based on Client Address
Now that you've configured your default address types and your translation maps, you can set specific rules that will override these default settings based on the actual IP address of each client.
Take one last look at Figure 15.17. If NFuse Classic was used in that environment, you would have specified a "translated address mapping" that mapped 10.1.1.1 to 126.96.36.199. Then, you would also have configured NFuse's default address setting to use the "translated" address. However, internal users would need the server's actual IP address, not the translated address. Therefore, you would configure the "Specific address translation settings" section of NFuse so that the client address prefix of your users ("10." in this case) would use the normal address.
When you configure "specific address translation settings," the NFuse server searches through its list of IP address prefixes every time a client user connects. If that user's IP address prefix is on the list, NFuse sends the client the address of the MetaFrame XP server in the format that is configured for that prefix. Otherwise, it sends the address to the MetaFrame XP server in the format specified by the default address translation setting.
You can configure client address prefixes for the level of detail you require. For example, you could specify "10." or "10.1.2." for whatever you need in your situation. The important thing is that client IP addresses are matched to this list based on identical patterns in the client address and the address on the list. Therefore, you cannot specify addresses based on subnet masks or wildcards.
Advantages of NFuse Classic's Specific Address Translation
- Very easy to apply
- Works well
- Can also translate ports
Disadvantages of NFuse Classic's Specific Address Translation
- Wildcards cannot be used in addresses.
- Client address searching is only based on pattern matches, not IP subnets.