Hardening Your Servers against Attack

Status:	Published
Version:	1.3
Authors:	HTL QA
Applies to:	Supportworks ESP

Hardening Your Servers against Attack

Server hardening is often a trade-off between security and usability. A truly secure server will allow you little functionality beyond the basics and will require multiple password-protected accounts to administer, with most actions being permitted only when you are physically logged into the server. You can harden a particular server in a number of ways, but this individual hardening must always be associated with a thorough security policy applied to the entire network, domain and company. It is important to be aware that the first thing to look at when securing your Supportworks server will always be the Windows/network environment rather than Supportworks itself.

This document outlines the specific areas in which security could be an issue, and what you can do to address those issues in each case.

Accounts

Access to the Supportworks SQL Server (SwSqlServer)

By default, Supportworks services use the "root" account on SwSqlServer for all communication to the database. The root account can only be used locally and not remotely, which means that an unauthorised user would need physical access to the machine on which SwSqlServer is hosted in order to perform any SQL actions. You can change the account used if required and you can also set a password for it (as detailed in the FAQ entitled Changing the SwSQL Account Password). However, if an unauthorised user did get access to the physical machine, then you would have far greater issues than just the visibility of SwSQL data - and no amount of passwords on the SwSqlServer could prevent the malicious deletion or acquisition of that data. The best way to prevent access to data by remote unauthorised users is by ensuring that the Windows Server is secure.

Access to Other Database Servers

If you have chosen to use MS SQL or Oracle as your application database, then the security for access depends on the connection type chosen. Connections can be made more secure by using Windows authentication rather than plain text - your organisation's database administrator should be able to assist.

Access to the Main Server (SwServerService) and Other Supportworks Services

For logging into Supportworks, we provide the default "admin" account, which has all user permissions and rights within Supportworks. This account has a default password of "Password", and we strongly recommend you to change that at the earliest opportunity after installation of the system. Once you have started using Supportworks, you will create accounts for all users and grant appropriate rights/privileges to these.

Although there is no harm in deleting the default account (assuming you retain at least one other with the System Administrator role), we would normally recommend that if it is not required, you simply set the password to something other than the default - still using Supportworks Authentication - and hide the account from the Service Desk (Helpdesk) view by moving it to an unused group and then filtering that group out within each data dictionary. That way, you will always have a fallback login should any Active Directory or other integrated authentication fail.

On the Communications tab of the Supportworks Server Configuration utility, there are access-control facilities that allow you to deny access to Supportworks from any workstations other than those belonging to your team. Access can also be tied in with Windows accounts to enforce time restrictions. However, if an unauthorised user is able to access Windows on the Supportworks server, then they would potentially be able to alter the Supportworks access-control settings by editing the underlying configuration file.

Access to Low-Level Documentation

Any Supportworks system (Version 7.4.1 and above) with an Enterprise or Professional licence ships with XMLMC API documentation to which access can be enabled or disabled. This documentation is as useful to unauthorised users as it is to developers, since it lists all entry points to the XMLMC and indicates how to use the APIs/methods, along with providing usage examples. For a live server, it is recommended that the documentation be disabled. This is done via the Server Configuration utility (Start > Programs > Supportworks Server > Supportworks Server Configuration) - by unchecking the Enable XMLMC API Documentation option on the Communications tab.

You should also note that, if you are running a remote Web server, then all of its documentation should be disabled or made unavailable unless the user is authorised.

Access to Windows

By default, Windows comes shipped with a number of predefined accounts that everyone knows and whose passwords are often not changed. Windows passwords are also easily cracked by anyone with access to your network (using L0phtCrack, for example), which means that you should take care to reconfigure any default accounts. To ensure that your network is as secure as possible, you could, for example, prevent unauthorised users (non-domain administrators) from browsing/downloading the SAM database, which is where Windows stores the account passwords.

Services

Supportworks Services

By default, SwServerService and all other Supportworks Services run in the context of the local system account. This is a possible problem, depending on what you have configured Supportworks to do. If you have a default application template and do not allow end users to customise Supportworks, the risks are minimal; however, if you have added form functionality that invokes Windows elements such as account control, password reset or network administration, then the risks are high. The most secure solution would be to run the Supportworks services in the context of an account that only has permissions to perform the basic tasks and to access the required folders/files on the server, and have the rest of the tasks performed in the user's context locally, rather than on the server.

The most secure way of running the Supportworks services would be firstly to create three local Windows accounts: SwSQL, SwHTTP and SwServer. You would then set SwSqlServer to run in the context of the SwSQL account and set the permissions on the SwSqlServer folders (using the Windows cacls command). Next, you would set SwHttpServer to run in the context of the SwHTTP account and ensure (using cacls again) that this account can access the SwHttpServer folders only minimally. Finally, you would set all of the remaining Supportworks services to run in the context of the SwServer account and again set the folder permissions. Once you have completed these actions, you should remove all other Windows accounts from the changed folders (again using cacls). Note that this level of security will make the administration and maintenance of the server more difficult due to the restrictions.

Windows Services

By default, the Windows Server runs over 60 services, most of which are not needed for Supportworks or normal day-to-day functionality. However, precisely which services are required depends on your network and how you wish to administer/maintain the server. For example, you can disable Terminal Services and Telnet but then you have to be physically logged in at the server to perform administration tasks. The easiest way to decide on what services are required for your site is to disable a different service each day and then see what errors/issues arise.

Removal of SwAdminService

In conjunction with certain network configuration settings, the service SwAdminService can expose a directory traversal file access vulnerability. This service is deployed with Core Services version 3.1.0 to 3.1.4 and does not provide any operational functionality. You should therefore remove the service in order to eliminate the risk. This can be done as follows.

1. Locate the SwAdminService within the Windows Services control
2. Stop and disable the service
3. Locate the folder "Hornbill\Core Services" folder within the installation path of Core Services
4. Delete the folder "SwAdminService"

At this point vulnerability will have been mitigated, however the Service will still be viweable within the Services display. To remove the service configuration completely there are a number of options available dependant on your OS. The following methods should be available on most OS versions, choose one of the following that you are comfortable with (We recommend a registry backup is performed before attempting).

Removing the service using Powershell:

1. Open Powershell Console and type the following commands:

   $service = Get-WmiObject -Class Win32_Service -Filter "Name='SwAdminService'"

   $service.delete()

Removing the service via the Registry:

1. Open regedit.exe
2. Locate the Key: [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SwAdminService]
3. Right click SwAdminService and click Delete
4. Restart the Server

Please note that this service is deprecated within Core Services v6.0 and above. This vulnerability therefore does not apply to customers running Supportworks ESP v8.

Rights/Roles

Supportworks Privileges

Within Supportworks, there are three user levels (or "roles"): System Administrator, Group Manager and Support Analyst. Along with these levels, there are multiple granular rights that can be set, allowing you to grant only the required capabilities for any given analyst to perform his or her duties. You should ensure that you only grant the minimum rights/roles required for a given analyst.

Windows Privileges

Within Windows, there are multiple roles and numerous rights. These can be set, via either policies or the registry, to lock down the server and, depending on how restrictive you wish the server installation to be, you can remove/prevent most capabilities.

Firewall

Supportworks Ports

There are various services that Supportworks loads and runs. Each service is provided as a TCP protocol connection from the Supportworks server on specific ports - which you have to ensure your firewall keeps open. The following table shows the services provided, the name of the module that provides each one, the port that each service is provided on and the versions of Supportworks to which those ports apply:

Service	Module Name	Port	Versions
Supportworks services via binary requests	SwServerService	5001 (Default)	All
Supportworks SQL server	SwSqlServer	5002 (Default)	Up to 7.5
KnowledgeBase index server	SwIndexServer	5003 (Default)	Up to 7.4.1
Supportworks mail services	SwMailService	5004	Up to 7.4.1
Supportworks services via text-based requests	SwServerService	5005	All
Supportworks Messenger services	SwMessengerService	5006	All
Supportworks calendar services	SwCalendarService	5008	Up to 7.4.1
Supportworks calendar services over XMLMC	SwCalendarService	5013	From 7.4.0
Supportworks mail services over XMLMC	SwMailService	5014	From 7.4.0
Supportworks services over XMLMC	SwServerService	5015	From 7.4.0
Supportworks FTP services (My Library)	SwFileService	21/5021 (Default)	Up to 7.4.1
Supportworks HTTP services with HTTP configured	SwHttpServer	80 (Default)	All
Supportworks HTTP services with HTTPS configured	SwHttpServer	443 (Default)	All

For firewall configuration purposes, you can ignore any services/ports that do not apply to your particular Supportworks version.

Any port shown above as the default for a given set of Supportworks services is changeable, which means that an alternative port may have been chosen by your organisation if they wanted to use the original for something else. Such a change, however, will have been highly unlikely - except to HTTP port 80, which is commonly used by Web servers in general.

Note that the default port for Supportworks FTP services changed from 21 to 5021 in Version 7.4.0.

Windows Ports

Windows and its associated services have many open ports; which of these are required depends on which services you enable. The easiest way to ensure a secure server is to set the firewall to allow nothing to begin with and then enable ports one by one as you find problems/restrictions that you cannot work around. ICMP (ping) and Telnet are examples of service protocols whose ports you would need to block.

Configuration and Customisation

Supportworks Customisation

Since Supportworks is highly customisable, you can quickly add functions to perform Windows user account administration or other dangerous actions. Care should be taken to ensure that these additional actions are performed in a safe manner and, where possible, using local accounts or analysts' own accounts rather than domain accounts.

Windows Configuration

The default Windows installation is not secure and therefore attention should be paid to reducing the number of permitted operations that a user can perform. This can be done via polices or rights control - for example, preventing access to the registry and file system.

Separation from the Main Server

Remote Database

If you have chosen a remote application database for Supportworks to use, then the server on which this runs must be as secure as the machine on which the Supportworks server is run.

Remote Web Server

It is possible to configure the Web components of Supportworks (SelfService, Analyst Portal, and so on) to be hosted either remotely (in a DMZ) or, via firewall/SwHttpServer configuration, within a "sealed" virtual host. If your customers are external to your company, then one of these strategies should be considered.

Note that the configuration for a machine in a DMZ should be considered in even greater detail than one located within your internal network, as these bastion servers are most likely to be attacked. Rather than just disabling services, they should be removed and the entire server configured for just one application/purpose. This should, if the server is configured correctly, prevent access by unauthorised users.

"Honey Trap"

Often, a good way to prevent unauthorised access to confidential data and prevent attack is to provide a means of letting the unauthorised user think they have access and give them dummy data. Most of the time, this would prevent them from going further, as they would believe that they have already reached their goal. The trap could also be monitored and alerts sent, so you could quickly identify who is attempting access. Since the system concerned would only be used as a trap, all access should be considered a threat, whereas on a real system, you would have to differentiate between valid and invalid requests, which can be difficult.

Useful Links and Tools

For detailed discussions and actual procedures/tools relating to server hardening, please see the following Web pages:

http://technet.microsoft.com/en-us/library/cc771361%28WS.10%29.aspx - MS TechNet article on Windows Server 2008 hardening

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=15910 - MS document on Windows 2000 security

http://technet.microsoft.com/en-us/library/cc163140.aspx - MS TechNet article on Windows 2003 Security Baseline

http://technet.microsoft.com/en-us/library/cc514539.aspx - MS TechNet article on Windows 2008 Security Baseline

http://technet.microsoft.com/en-us/library/bb490872.aspx - MS TechNet Cacls command reference

http://technet.microsoft.com/en-us/library/cc163158.aspx - MS TechNet article on security monitoring and attack detection

http://technet.microsoft.com/en-us/library/dd349791%28WS.10%29.aspx - MS TechNet article on bastion hosts

http://technet.microsoft.com/en-us/library/cc722940.aspx - MS TechNet article on defending your Web server (including a section on bastions)

http://www.sans.org/reading_room/whitepapers/basics/hardening-bastion-hosts_420 - White Paper on hardening bastion hosts

http://technet.microsoft.com/en-us/library/cc758219%28WS.10%29.aspx - MS TechNet article on the Security Configuration Manager

http://technet.microsoft.com/en-us/library/cc785357%28WS.10%29.aspx - MS TechNet article on general Windows security