Best Practice - Secure Deployment Checklist - (V. 4.41)

Best Practice Checklist for Deploying SGD Securely

This document provides a checklist of common techniques and strategies that some administrators have  used in support of secure SGD deployments. This is not meant to be an all-inclusive list, and many of these may not be appropriate for your environment. This is written with SGD version 4.41 in mind, but most items are applicable to other versions of SGD.   

Operating System Environment

It does little good SGD if the server(s) on which it runs are compromised. The specific techniques and tools used will vary by operating system and your specific requirements, but this list can serve as a starting point. 

Install Off-Network - Install, patch, and configure your server operating systems "off-network" - your system can be detected, attacked, and compromised before you've finished your installation.  It's happened before. 

Disk Partitioning - Use separate partitions for directory structures that may fill up your root filesystem, which can be a form of a Denial Of Service (DOS) attack.  For example, if you use the default SGD installation point, "/opt/tarantella", create a separate /opt partition to store the SGD binaries and logfiles.  You may also wish to consider relocating the SGD, Apache, and Tomcat logfile locations to separate partitions as well.   Similarly, consider moving "/var" to a separate partition. 

Minimize OS Installation - It's always a good practice to avoid installing unnecessary / unneeded software and services on your servers.  In particular, avoid installing tools that an attacker can use to further their attacks, such as 'C' compilers (to compile rootkits), and network utilities such as ping, nslookup, and telnet.

Minimize Network Services Footprint - Eliminate unnecessary network services to reduce the number of attack points that an attacker may try to exploit.   Solaris 10 11/06 and later provides "Secure By Default" at installation time which has a reduced network services footprint.  This can also be enabled after the fact with the command:

Solaris Containers - Create a non-global Solaris zone to install and run SGD in.  Even if the manages to compromise the SGD zone, forensic evidence of the attack should still be available in the global zone.   See "Solaris Containers How To Guide"  and "Solaris 10 Security How To Guide" for tutorials on creating and using Solaris Zones. 

Time Source Synchronization - Using a synchronized time source will make it easier to correlate security event logs, and is further a requirement of SGD Array functionality as well as requirements of some authentication authorities, such as Kerberos/Active Directory. 

Disable Routing / Forwarding -  On a multi-homed system, disable routing functions.

SGD Policies

Re-map Administrator account from root - Create a non-root account to administer your SGD system (and do not permit root logins on your server.) 

Use Firewall Traversal - Firewall Traversal is the multiplexing of both the https and AIP protocols onto a single TCP port (443).   Using this technique usually eliminates the requirement to change firewall configurations to permit SGD to operate across them. 

Do Not Use Self-Signed Certificates - Self-Signed server certificates are for testing purposes only.  Because client computers won't recognize the Certificate Authority used to sign the server certificate presented, client browsers will notify the user of that fact, and do they wish to override?  Training users to override such security warnings is always a bad idea; you're teaching users a very bad habit. SGD does include a host verification sequence in the client. When the X.509 server certificate installed on your SGD server changes, users will be warned that they may be victims of a host spoofing attack. This is because a fingerprint of each servers' X.509 certificate is stored on the client whenever a user allows a connection to a host. On subsequent connections, the stored fingerprint is compared to the certificate fingerprint being presented by the server, and if they're not the same, a dialog box warning the user of a possible spoofing attack is displayed. Educate your users to never proceed if such a message is displayed. When you are to replace a server certificate, be sure to warn your users ahead of time.  

Use SSL / TLS for both http and AIP connections - See "Securing Connections between Client Devices and SGD Servers"

Restrict Weak SSL Ciphers - You may wish to eliminate support for browsers with weak encryption schemes.   By default, the Apache webserver in SGD 4.41 includes support for the following OpenSSL cipher suites (see "SSLCipherSuite" for more information):

This includes browsers with only 40-bit export grade encryption; you'll likely want to increase this to require client browsers with higher-grade encryption.  To change this, edit Apache's httpd.conf file, (for version 4.41, located in /opt/tarantella/webserver/apache/2.2.8_openssl-0.9.8g_jk1.2.25/conf), and change the SSLCipherSuite directive to:

Disable Unencrypted AIP Communications - The SGD client will always "prefer" to use encrypted connections, if available. But to be certain that only encrypted AIP connections will be used, you can disable "Standard" Connections. In the SGD Administrative console, select/click on the SGD servername, then the "Security" tab, then de-select the "Standard" checkbox. Alternatively, from the command-line, you can run:

# tarantella config edit --security-connectiontypes ssl

Redirect Connections to Secure Port - If a user connects to the unencrypted webserver port (port 80), you probably want to force this connection to the secure port (port 443 or https).  Note that some administrators choose to disable Port 80 connections altogether, and that's certainly an alternative. But since any user that forgets to specify https on their URL will get an error message, this approach may be more trouble than its worth.

There are a number of mechanisms to do this redirection, some examples of which are detailed in the following:

mod_rewrite - in SGD 4.41, there's a pre-configured rule that uses mod_rewrite to redirect users as mentioned. It's not enabled by default, because SSL must first be enabled, and SOAP connections secured. Once these steps are complete, then you can enable this code. At approximately line 1149 of httpd.conf is a block of code that looks like:

# 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\!)

 Once you've enabled secure connections, uncomment the lines between "SGD BEGIN" and "SGD END", i.e.

# 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\!)

And restart the webserver.

There are many alternatives for redirecting connections, depending on your specific requirements. Connections can be redirected using an httpd.conf entry like:

<VirtualHost *:80>
    Redirect / https://sgd-server.yourdomain.com/
</VirtualHost> 

If you're using the Load Balancing script to distribute user sessions, simply use https as your target servers, for example:

Another alternative replaces the default index.html page with something like:

<html>
<head>
<title> SGD Redirect Page</title>
<meta HTTP-EQUIV="Refresh" content="0; url=https://servername/sgd">
</head>
</html> 

Hide Unneeded Links

Note that the above redirection page not only forces the connection to the secure port, but also redirects the connection to the login link ("/sgd"). This will prevent the user from seeing the default index page. The default index page contains a number of links beyond just logging in to SGD, such as logging into the Administrative console, downloading software, and so on, as shown here:

By redirecting users directly to the login page, administrators remove the temptation for users to try other links, which often leads to trouble for the administrator (such as users changing their locale to one their application isn't configured for.)

Display Legal Warning - Some interpret the presence of the "Log In" anchor on the default landing page as an invitation to users to login, even those who have no business doing so. The reasoning goes that, because they were "invited" to login, the owner of the site has no basis for taking action against the would-be hacker, (or other unwanted visitor.) If you're publishing applications on the Internet, it's recommended that you alter the default "landing" page to include an appropriate legal warning.

Enable Secure Intra-Array Communications - if you have created an SGD array, the traffic replicated between SGD servers in not strongly encrypted by default.  To encrypt this traffic, see "Securing Connections Between SGD Servers. "

Disable "Show Details" on Application Launches  - Displaying launch details on launch failures can be useful for diagnosing launch failures, but the administrator should be aware that under certain circumstances, it's possible for the user password sent to the application server to be displayed here.  While this rarely occurs, (generally, only Unix application servers are affected), and are transient in nature (this information isn't logged), if you've pre-populated user password caches and haven't revealed the credentials to your users, a user may see them here.  You can disable this from the Administrator's Console by accessing "Global Settings" --> "Application Authentication".  Under "Launch Dialog",  there are three settings for "Launch Details Pane":

• Showed by Default

• Showed When Launch Fails

• Show/Hide By User Enabled

 Clear the checkboxes by each to prevent launch details from being displayed.

Restrict Access to Administrator's Console - You may want to limit access to your administration console.  Some techniques to do this can be found here.

Eliminate Unnecessary Webserver Content - By default, SGD includes some example code and scripts meant to assist the webservices developer.  To restrict this information, you can remove this information: 

Comment out the "mount" directive of the "examples" directory in httpd.conf, e.g.:

Move unnecessary files from /axis web directory

Reduce Webserver Information -By default, the Apache webserver returns a fair amount of information in the server response header about its version number, etc.  This information is commonly used by scanning scripts to fingerprint your webserver.  You can reduce the amount of information returned by changing the following entries in your httpd.conf file:

Note that "ServerTokens Prod" still returns the webserver name ("Apache") - if you wish to further obscure your webserver identity, you can use install the mod_security module, and set the "SecServerSignature" string to any arbitrary identifier, such as "Microsoft-IIS/5.0". The value of the particular alteration is debatable – but mod_security contains a number of other worthwhile logging and intrusion prevention features, and is worth evaluation.

Disable Indexes - to disable directory listings in Apache, edit the httpd.conf file, and around line 189, change the "Options" entry to "-Indexes", e.g.:

# This should be changed to whatever you set DocumentRoot to.
#
<Directory "/opt/tarantella/webserver/apache/2.2.8_openssl-0.9.8g_jk1.2.25/htdoc
s">
    #
    # Possible values for the Options directive are "None", "All",
    # or any combination of:
    #   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
    #
    # Note that "MultiViews" must be named *explicitly* --- "Options All"
    # doesn't give it to you.
    #
    # The Options directive is both complicated and important.  Please see
    # http://httpd.apache.org/docs/2.2/mod/core.html#options
    # for more information.
    #
    Options -Indexes FollowSymLinks

To disable indexes in Tomcat, edit the file '/opt/tarantella/webserver/tomcat/5.0.28_axis1.2/conf/web.xml', and locate the following text:

Change the line:

<param-value>true</param-value> to read:

<param-value>false</param-value> 

Note the "Indexes" are disabled

Turn Off User Directories in Apache - By default, the "UserDir" variable is enabled in Apache. This can be used by an attacker to determine which user-id's are present on your system. To disable, in the httpd.conf file, change the value of "UserDir" to 'disabled'.

Turn Off Apache Tracing - The Apache webserver supports a built-in HTTP method called "TRACE", used to debug browser connections. There have been reports of vulnerabilities that exploit this method, so it should be disabled unless you have a specific need for it. In your httpd.conf "main" section, add the line:

TraceEnable off

Disable WebDAV in the Webserver - WebDAV is enabled by default. If not needed by your installation, disable by locating the line "Dav on" in your httpd.conf, and changing it to "off".

Disable Unneeded Apache Modules - The default distribution of Apache in SGD includes a number of Dynamic Shared Objects (DSO) to provide a number of optional extensions to the webserver. Many of these are not necessary to the operation of SGD; for example, "mod_dav", "mod_dav_fs", and "mod_userdir" could probably be removed (actually, by commenting out the relevant "LoadModule" directive in httpd.conf.) Note that by removing such modules, any directives in the httpd.conf that the module handles will no longer be recognized. Documentation on Apache 2.0 modules may be found here.

Control Webserver Logfile Sizes - The Apache and Tomcat logfiles can, over time, become quite large.  To avoid consuming excessive amounts of diskspace, consider putting these logs under control of logadm (Solaris) or logrotate (Linux.) Be aware that attackers can use logfiles to compromise systems. For example, deliberately generating repeated logfile entries can fill up a filesystem, and can act as a Denial Of Service (DOS) attack. Similarly, attackers will sometimes deliberately generate seemingly innocuous logfile entries to overload the administrator with data, and thus helping obscure logfile entries that might point to more nefarious activities with sheer "noise." Generating gigabytes of audit trail data per day will do you little good if you can't routinely and conscientiously do data reduction on 

Restricting Information  - You may wish to consider limiting the ability of users to retrieve information from your hosted applications to their clients.  Mechanisms for transmitting data include printing, clipboard mapping, and client drive mapping.  You may wish to consider disabling or otherwise restricting the ability of users to use these features.   

Audit Trail - To record what users are doing, (and attempting to do), you may wish to enable audit logging, as described here.

Supporting Services Policies

Firewall Policies

For internal-facing deployments, you'll generally want two firewalls, as shown here:

The external firewall when firewall traversal is enabled need only be configured to pass encrypted traffic on port 443 to the SGD servers in the array.  The internal firewall will need to be configured to pass traffic on specific ports, to specific destinations, depending on the specific needs of your configuration.  Examples include RDP, for RDP connections, LDAP, if LDAP authentication is needed, and so on.  The source IP address for these connections should only be for SGD servers, and limit destinations to specific servers.  The TCP ports that may be required are documented here and here. 

Your firewall should also provide basic protection against Denial Of Service Attacks, (DoS) and Distributed Denial of Service (DDoS) such as "Ping of Death", SYN Flood, Ping Flood, smurfd, and similar attack types.

Note that most "application firewall" technologies aren't that useful until the traffic is decrypted.

Use Two-Factor Authentication for Internet Deployments

If you are going to publish applications to users on the Internet, it's strongly advised you use a two-factor authentication system, such as RSA SecurID.  This is because if a user uses an uncontrolled PC, such as one at an Internet cafe, Business Center, or Kiosk, it's possible that such systems may be compromised by a keylogger; that is, software (or hardware) that captures the users keystrokes.  In such a scenario, a user may inadvertently divulge their username and password when using such a compromised system.  Use of a two-factor authentication with a one-time password component will prevent such stolen credentials from being used successfully in an attack.

Intrusion Detection / Prevention Systems

Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) are designed to monitor network traffic and look for patterns and behaviors that may indicate an unwanted intrusion is being attempted. The IPS differs from the IDS in that the IPS will take active measures to immediately counter the perceived attack, by blocking the offending source IP address, resetting the connection, or through other mechanisms.

IDS and IPS systems can generally be broken down into host-based solutions, and network-based solutions. Host-based solutions install on the systems they're meant to protect, while network-based solutions will usually monitor traffic at one or more points "in front of" the host or hosts being protected. These devices may act in-line, so that all traffic must pass through them, or may simply act as passive sensors, often with no assigned IP address, which monitor traffic by setting its network interface in promiscuous mode.

Some IDS / IPS systems perform protocol decoding, while others do not. Protocol decoding for SGD would primarily examine http traffic. In order to do this effectively, the IDS/IPS must be able to view the traffic in unencrypted mode.

One mechanism to do this is to use an SSL accelerator, which decrypts the SGD / HTTP traffic, and forwards it onto the SGD server. The network sensor would be placed on the network between the accelerator and the SGD server. For more information on configuring SGD for an SSL Accelerator, see: "Using External SSL Accelerators" in the SGD Administrator's Guide.

The subject of IDS/IPS systems are far too large to discuss in detail here. Two tools that can prove useful for SGD deployments are:

mod_security - This is an example of a host-based IPS, more specifically, a web application firewall, because it specifically monitors and evaluates web traffic. mod_security is a plug-in to the Apache webserver, and comes with a set of "Core" rules that detect protocol violations and known attack signatures to prevent web-based attacks. For more info, visit the mod_security home page.

SNORT - SNORT has a variety of modes, including packet decoding, but is most commonly deployed as a network-based IDS/IPS tool. SNORT is claimed to be the most widely deployed IDS in the world, and is an open-source project. See the SNORT home page for more information.

Perform Penetration Testing

When deploying SGD on the public internet, it's highly recommended that you perform active penetration testing to ensure you've covered the most obvious issues. Penetration testing is often performed by outside consultants, while some organizations have their own internal test teams.

If you wish to perform some basic tests on your own, consider some of the following tools:

nmap - nmap is commonly used to scan for hosts, determine OS determine what services a host may be offering. The would-be intruder would use a tool like this to perform network reconnaissance, the first step in attempting to break-in. Be sure to provide as little information about your installation to would-be intruders.

nessus - nessus is an automated vulnerability scanner which uses plug-ins to test for specific types of vulnerabilities, such as Cross-Site Scripting vulnerabilities, known webserver bugs, and so on. This is free for home use only.

nikto - nikto is a automated webserver scanner, and tests for a variety of webserver problems.

firewalk - firewalk is a firewall reconnaissance tool, which tries to determine what access control lists you have on your firewall.