The following topics describe how to make your SGD configuration more secure.
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.
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.
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.
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.
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.
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/
on the SGD host.
tomcat-version
/conf/server.xml
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.
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.
SSLCipherSuite HIGH:!SSLv2:!ADH:!aNULL:!eNULL:!NULL
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.
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
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.
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.
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/
on the SGD host.
apache-version
/conf/httpd.conf.secure
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
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 </IfModule> # 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/ </VirtualHost>
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:
<html> <head> <title> SGD Redirect Page</title> <meta HTTP-EQUIV="Refresh" content="0; url=https://server.example.com/sgd"> </head> </html>
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 6.2.10.2, “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.
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.
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/
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”.
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 6.2.10.1, “Use the Secure Apache Configuration File”.
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/
file and change the value of the
tomcat-version
/conf/web.xmldisableloginautocomplete
parameter to
true
. This parameter is
false
by default. Restart the
SGD web server after making changes.
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.
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
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_
,
where locale
.htmllocale
is the language for
the Welcome Page.
Comment out the following code that creates the link to the
Administration Console at /sgdadmin
.
<tr> <td> <p> <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> ... </tr>
Note that after making this change, users can still access
the Administration Console by going to
http://
,
where server.example.com
/sgdadminserver.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 </Location>
Set the SSLCACertificateFile
directive to the location of the CA certificate file.
For example:
SSLCACertificateFile /opt/tarantella/var/tsp/client/CA.crt
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”.
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.