Server hardening is a set of disciplines and techniques which improve the security of an ‘off the shelf’ server.  Server Hardening is requirement of security frameworks such as PCI-DSS and is typically included when organisations adopt ISO27001.

What is the attack surface

The aim of server hardening is to reduce the attack surface of the server.  The attack surface is all the different points where an attacker can to attempt to access or damage the server.  This includes all network interfaces and installed software.  By removing software that is not needed and by configuring the remaining software to maximise security the attack surface can be reduced. As a result, an attacker has fewer opportunities to compromise the server.

Create configuration standards to ensure a consistent approach

It is rarely a good idea to try to invent something new when attempting to solve a security or cryptography problem.  Proven, established security standards are the best choice – and this applies to server hardening as well.  Start with industry standard best practices

The CIS Benchmarks are a comprehensive resource of documents covering many operating systems and applications.

openSCAP is a good starting point for Linux systems. It provides open source tools to identify and remediate security and compliance issues against policies you define.

For Windows systems, Microsoft publishes security baselines and tools to check the compliance of systems against them.

These baselines are a good starting point, but remember they are a starting point and should be reviewed and amended according to the specific needs of your organisation and each server’s role.

How separating server roles improves security

The goal of sever hardening is to remove all unnecessary components and access to the server in order to maximise its security.  This is easiest when a server has a single job to do such as being either a web server or a database server.   A web server needs to be visible to the internet whereas a database server needs to be more protected, it will often be visible only to the web servers or application servers and not directly connected to the internet.

If a single server is hosting both a webserver and a database there is clearly a conflict in the security requirements of the two different applications – this is described as having different security levels.

It is best practice not to mix application functions on the same server – thus avoiding differing security levels on the same server. (It is a requirement under PCI-DSS 2.2.1).

Using virtual servers, it can be cost effective to separate different applications into their own Virtual Machine. For larger networks with many virtual machines, further segregation can be applied by hosting all servers with similar security levels on the same host machines.

How vulnerability scans can help server hardening

Vulnerability Scans will identify missing patches and misconfigurations which leave your server vulnerable. Ports that are left open or active subsystems that respond to network traffic will be identified in a vulnerability scan allowing you to take corrective action.  A vulnerability scan will also identify new servers when they appear on your network allowing the security team to ensure the relevant configurations standards are followed in line with your Information Security Policy.

Server hardening checklist

This checklist provides a starting point as you create or review your server hardening policies.

Accounts and logins

Change default credentials and remove (or disable) default accounts – before connecting the server to the network (PCI requirement 2.1).

Disable guest accounts and vendor remote support accounts (Vendor accounts can be enabled on demand).

Components and subsystems

Turn off services that are not needed – this includes scripts, drivers, features, subsystems, file systems, and unnecessary web servers.

On Windows systems only activate the Roles and Features you need, on Linux systems remove package that are not required and disable daemons that are not needed

Updates and vulnerabilities

Install security updates promptly – configure for automatic installation where possible.

Ensure applications as well as the operating system have updates installed.

Clocks and Timestamps

Accurate time keeping is essential for security protocols like Kerberos to work. Active Directory domain controllers provide time synch for members of the domain, but need an accurate time source for their own clocks.  Configure NTP servers to ensure all servers (and other network devices) share the same timestamp.  It is much harder to investigate security or operational problems if the logs on each device are not synchronised to the same time.

Networks and firewalls

Only publish open network ports that are required for the software and features active on the server.  If the server has connections to several different subnets on the network, ensure the right ports are open on the correct network interfaces.  For example, an administrative web-portal may be published onto the internal network for support staff to use, but is not published onto the public facing network interface.

Configure perimeter and network firewalls to only permit expected traffic to flow to and from the server.

Remote access security

RDP is one of the most attacked subsystems on the internet – ideally only make it available within a VPN and not published directly to the internet.

For Linux systems, remote access is usually using SSH.  Configure SSH to whitelist permitted IP addresses that can connect and disable remote login for root.  If possible, use certificate based SSH authentication to further secure the connection.

Logging and SIEM

Configure operating system and application logging so that logs are captured and preserved.  Consider a SIEM solution to centralise and manage the event logs from across your network.

Application hardening

When considering server hardening, remember the applications that will run on the server and not just the operating system.

For well known applications, such as SQL Server, security guidelines are available from the vendor.  Check with your application vendor for their current security baselines.

For custom developed and in-house applications, an application penetration test is a good starting point to identify any vulnerabilities or misconfigurations that need to be addressed.