6.2. SGD Configuration

The following topics describe how to make your SGD configuration more secure.

6.2.1. Install SGD in Secure Mode

By default, SGD is installed in secure mode. This means that the SGD server is configured automatically to use secure connections between client devices and the SGD server, and to use secure connections between the SGD servers in the array.

During installation, you can specify your own security certificate for securing connections to SGD.

See Chapter 2, Secure Installation and Configuration of SGD for more details.

6.2.2. Use a Non-Root Administrator Account

Always use a non-root account to administer the SGD array. See Section 4.2.2, “SGD Administrators” for details of how to create SGD Administrators.

Disable root user logins for the SGD host. Administrators who need root access should log in using a non-root account and use the su command or equivalent.

Note that some tarantella commands, such as those that control the SGD server and SGD web server can be run only by the root user. See The tarantella Command.

6.2.3. Use Firewall Traversal

Firewall traversal is the multiplexing of both the HTTPS and Adaptive Internet Protocol (AIP) protocols onto a single TCP port (port 443). Using this technique means that you do not have to reconfigure your firewalls to allow SGD to operate across them.

SGD supports the following methods of firewall traversal:

  • The SGD Gateway. The SGD Gateway is a reverse proxy server that can be used to provide an increased level of security between client devices and SGD servers. All client connections to the Gateway are made on port 443. The Gateway is included in the SGD distribution.

  • Firewall forwarding. For firewall forwarding, you configure the SGD server to listen on port 443. The SGD server then forwards all traffic that is not AIP traffic to the SGD web server.

6.2.4. Do Not Use Self-Signed Certificates

Self-signed server certificates are for testing purposes only. Because client computers do not recognize the Certificate Authority (CA) used to sign the presented server certificate, the browser shows a security warning and gives the user the option to override the warning. Instruct users that they should never override such security warnings.

SGD does include a host verification sequence for the client device. When the X.509 server certificate installed on the SGD server changes, users are warned that they may be victims of a host spoofing attack. This is because a fingerprint of each SGD server's X.509 certificate is stored on the client device whenever a user allows a connection to an SGD host. On subsequent connections, the stored fingerprint is compared to the certificate fingerprint presented by the server. If they are not the same, a dialog box warning the user of a possible spoofing attack is displayed.

Instruct your users to never proceed if such a message is displayed. When you are going to replace a server certificate, be sure to warn your users in advance.

6.2.5. Use SSL and TLS

Always secure connections between client devices and SGD servers using Secure Sockets Layer (SSL) or Transport Layer Security (TLS). Both HTTP and AIP connections should be secured.

For a default installation, an SGD server is configured automatically to use SSL or TLS for all connections with the client device.

6.2.6. Use Secure Session Cookies

By default, if secure connections are being used, SGD marks all user session cookies as secure. This prevents transmission of the cookie over a non-secure connection.

Wherever possible, you should always use secure connections for your SGD deployment. However, in some circumstances you might want cookies to be marked as secure, even though the connection is not secure. For example:

  • In a SGD Gateway deployment, if you are using unencrypted connections to the SGD array

  • If you are using an SSL accelerator that connects to SGD using HTTP

To mark all cookies as secure, edit the Tomcat configuration file /opt/tarantella/webserver/tomcat/tomcat-version/conf/server.xml on the SGD host.

Add the attribute secure="true" to the AJP and HTTP Connector elements. For example:

  <!-- Define an AJP 1.3 Connector on port 8009 -->
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443"
     secure="true" allowTrace="false" />

Following this change, all requests made using these Connectors will appear to be secure, meaning that Tomcat's JSessionID cookie and all SGD user session cookies will be marked as secure.

See the Apache Tomcat documentation for more details about the secure attribute.

6.2.7. Restrict the Use of Weak SSL Ciphers

By default, the SGD web server is configured to use only strong cipher suites.

The supported OpenSSL cipher suites are configured by the SSLCipherSuite directive in the httpd.conf file for the SGD web server.


This setting means that browsers must support higher-grade encryption.

By default, the SGD Gateway is configured to use only high grade ciphers for SSL connections.

To configure the cipher suites used by the Gateway, you must edit the configuration file called ciphersuites.xml in the /opt/SUNWsgdg/etc/ directory on the Gateway. See Configuring Ciphers for the SGD Gateway for more details.

6.2.8. Disable Unencrypted AIP Communications

In a default installation, the SGD Client uses encrypted connections when connecting to the SGD server. To make certain that only encrypted AIP connections are used, you can disable unencrypted connections. Unencrypted connections are also called standard connections.

In the SGD Administration Console, click on the SGD server name in the Secure Global Desktop Servers tab and deselect the Standard check box in the Security tab.

Alternatively, use the following command:

# tarantella config edit --security-connectiontypes ssl

6.2.9. Enable Secure Intra-Array Communication

When you create an SGD array, the traffic replicated between SGD servers might not be encrypted. To encrypt this traffic, enable secure intra-array communication for all SGD servers in the array.

For a default installation, secure intra-array communication is enabled automatically for an SGD server.

6.2.10. Securing the SGD Web Server

The SGD web server is an Apache web server preconfigured for use with SGD. The following topics describe how to enhance security for the SGD web server. Use the Secure Apache Configuration File

The httpd.conf.secure file is an Apache server configuration file that configures the SGD web server for enhanced security. The file is included with the SGD software, at /opt/tarantella/webserver/apache/apache-version/conf/httpd.conf.secure on the SGD host.

The httpd.conf.secure file provides the following additional security features, compared to the standard httpd.conf file used by the SGD web server:

  • Apache modules that are not used by SGD are disabled

  • Access to the /cgi-bin directory on the SGD web server is not allowed Redirect Connections to a Secure Port

When a user connects to the unencrypted HTTP port (TCP port 80), the connection should be redirected automatically to the HTTPS port (TCP port 443).

You might want to disable connections on port 80. But this can cause problems, as any user that forgets to specify https:// in the URL will see an error message.

The following are some mechanisms that you can use to redirect users to a secure port.

  • Install in secure mode. For a default installation, SGD is configured automatically to redirect HTTP connections to port 443.

    The SGD web server has a preconfigured rule that uses the Apache mod_rewrite module to redirect users. The following rule is enabled automatically when you install in secure mode.

     # SGD BEGIN AUTO-FORWARD TO HTTPS (don't delete this line!)
        <IfModule rewrite_module>
          RewriteEngine On
          RewriteCond %{SERVER_PORT} !^443$
          RewriteRule (/.*) https://%{SERVER_NAME}$1
     # SGD END AUTO-FORWARD TO HTTPS (don't delete this line!)
  • Use a VirtualHost directive. Connections can be redirected using an httpd.conf entry such as:

     <VirtualHost *:80>
          Redirect / https://sgd-server.example.com/
  • Use the Load Balancing JSP. If you are using the Load Balancing JSP to distribute user sessions, specify https URLs for your target servers, for example:

    hosts[0] = "https://www1.example.com"
    hosts[1] = "https://www2.example.com"
  • Use a redirection page. Replace the default SGD web server Welcome Page index.html, as follows:

            <title> SGD Redirect Page</title>
            <meta HTTP-EQUIV="Refresh" content="0; url=https://server.example.com/sgd">
      </html> Hide Links That Are Not Required

The SGD web server Welcome Page contains a number of links for logging in to the Administration Console, downloading software, and viewing user documentation. You might want to hide these links from users.

The technique for specifying a redirection page described in Section, “Redirect Connections to a Secure Port” redirects the connection to the SGD login page https://server.example.com/sgd. This prevents the user from seeing the SGD web server Welcome Page.

By redirecting users directly to the SGD login page, you remove the temptation for users to try other links. This helps to avoid problems such as users changing their locale to one which their application is not configured for. Display Legal Warnings

Some people may interpret the presence of the Log In link on the SGD web server Welcome Page as an invitation to log in, even if they have no business in doing so. The reasoning is that, because they were invited to log in, the owner of the site has no basis for taking action against an unwanted visitor.

If you are publishing applications on the Internet, you might want to alter the default SGD web server Welcome Page to include an appropriate legal warning. Eliminate Unnecessary Web Server Content

The Apache Axis distribution included with SGD includes some example code and scripts meant to assist web services developers. To restrict access to these files, move unnecessary files from the /axis web directory, as follows:

# cd /opt/tarantella/webserver/tomcat/tomcat-version/webapps/axis 
# mv *.jsp WEB-INF/
# mv *.html WEB-INF/ Reduce Web Server Response Information

By default, the Apache web server used by SGD returns information such as the version number in the server response header. This information could be used by scanning scripts to fingerprint the web server.

You can reduce the amount of information returned in the response headers by using the following directives in the httpd.conf file.

 ServerTokens Prod 
 ServerSignature Off

Note that ServerTokens Prod still returns the web server name (Server: Apache). If you wish to further obscure your web server identity, install the mod_security Apache module, and set the SecServerSignature string to an arbitrary identifier.

mod_security contains a number of other useful logging and intrusion prevention features. See Section 6.3.3, “Intrusion Detection and Prevention Systems”. Disable Unused Apache Modules

The version of Apache web server supplied with SGD includes a number of Dynamic Shared Objects (DSO) to provide optional extensions to the web server.

Some of these modules are not needed by SGD. For example, mod_dav, mod_dav_fs, and mod_userdir can be removed by commenting out the relevant LoadModule directive in the httpd.conf file. Note that when removing such modules, any directives in the httpd.conf file that the module handles will no longer be recognized.

Where possible, use the secure Apache configuration file httpd.conf.secure. Apache modules that are not used by SGD are disabled in this file. See Section, “Use the Secure Apache Configuration File”. Disable Autocomplete for Web Pages

Autocompletion of user input can be disabled for the SGD login page and the Administration Console login page. Disabling autocomplete prevents browser caching of sensitive data, such as user names and password.

To disable autocomplete, edit the /opt/tarantella/webserver/tomcat/tomcat-version/conf/web.xml file and change the value of the disableloginautocomplete parameter to true. This parameter is false by default. Restart the SGD web server after making changes. Control Web Server Log File Sizes

The Apache and Tomcat log files can, over time, become quite large. To avoid consuming excessive amounts of disk space, consider putting these logs under the control of logadm (Oracle Solaris platforms) or logrotate (Linux platforms).

Be aware that attackers can use log files to compromise systems. For example, deliberately generating repeated log file entries can fill up a file system, and can act as a Denial Of Service (DOS) attack. Similarly, attackers might generate seemingly innocuous log file entries to overload an administrator with data, and thus obscure log file entries that might point to more nefarious activities.

6.2.11. Disable "Show Details" for Application Launches

Displaying launch details can be useful when diagnosing launch failures. However, it is sometimes possible for the user password sent to the application server to be displayed in the Launch Details window.

In practice this issue rarely occurs, as only UNIX application servers might be affected, the details shown are transient in nature, and the information is not logged. However, if you have pre-populated user password caches and have not revealed the credentials to your users, a user may see details when starting an application .

To prevent launch details from being displayed, go to the Global Settings → Application Authentication tab in the Administration Console. Deselect the following settings for the "Launch Details Pane" attribute:

  • Showed by Default

  • Showed When Launch Fails

  • Show/Hide By User Enabled

6.2.12. Restrict Access to the Administration Console

The Administration Console is a web application running on the SGD web server which is used by SGD Administrators to configure and control the SGD servers in an array.

The following methods can be used to restrict access to the Administration Console:

  • Remove the Administration Console link from the SGD web server Welcome Page. Edit the following HTML file for the SGD web server Welcome Page, at:

    /opt/tarantella/webserver/apache/apache-version/htdocs/webtop_locale.html, where locale is the language for the Welcome Page.

    Comment out the following code that creates the link to the Administration Console at /sgdadmin.

        <a href="/sgdadmin" 
        alt="Launch the Oracle Secure Global Desktop Administration Console" 
        title="Launch the Oracle Secure Global Desktop Administration Console">Launch the 
        Oracle Secure Global Desktop Administration Console</a>

    Note that after making this change, users can still access the Administration Console by going to http://server.example.com/sgdadmin, where server.example.com is the name of the SGD server.

  • Restrict access by IP address. Use the Apache <Location> directive to only allow access to the /sgdadmin URL from specific client IP addresses. This is described in Securing Access to the Administration Console.

  • Use client certificates. A client certificate is an SSL certificate that is installed in the browser on the client device. You can restrict access to only those browsers which have a valid client certificate.

    To configure the SGD server for client certificates, do the following:

    • Copy the CA certificate file for the client certificate to a location on the SGD server.

    • Add the following to the SSL Virtual Host Context section of the httpd.conf file:

      <Location /sgdadmin/*>
       SSLVerifyClient require
       SSLVerifyDepth 1
    • Set the SSLCACertificateFile directive to the location of the CA certificate file. For example:

      SSLCACertificateFile /opt/tarantella/var/tsp/client/CA.crt

6.2.13. Restrict Access to Client Device Features

You might want to limit the ability of users to transfer information from an application displayed using SGD to their client devices.

Mechanisms for transmitting data include printing, copy and paste, and client drive mapping. You might want to consider disabling or otherwise restricting the ability of users to use these client device features. See Section 4.3, “Client Device Security”.

6.2.14. Create an Audit Trail

To record what users are doing, and attempting to do, you can enable audit logging for an SGD server. Audit logging records system events such as starting and stopping the SGD server, configuration changes, user logins, and running applications.

Audit logging is configured using a */*/*auditinfo log filter. See Using Log Filters for Auditing.

You use the tarantella query audit command to view audit log files.