Various researches reveal that a staggering 80% of reported breaches involve exploiting vulnerabilities in the configurations of IT systems. To proactively block attacks and thereby prevent costly downtime and data breaches, experts recommend implementing a server hardening policy, which is a specify type of system hardening policy.
A server hardening policy is a set of guidelines, procedures and controls designed to protect systems from unauthorized access and exploitation. Indeed, a server deployed in its default state is at risk of compromise and malware attacks. But by removing unnecessary software and features, properly configuring security settings, and implementing best practices for access control, auditing and incident response, you can dramatically reduce your attack surface area.
The following tips and examples can serve as a starting point for your hardening efforts.
User Accounts and Passwords
- Is the account lockout duration and threshold set?
- Is Kerberos encryption activated, and are the types selected strong enough?
- Are default local accounts, such as the built-in Administrator and Guest accounts on Windows systems, disabled or renamed?
- Are user password requirements in line with best practices, such as NIST guidelines?
Example: Set up an account password policy with the following parameters:
- Minimum password age: 1 or more days
- Minimum password length: 14 or more characters
- Account lockout threshold: 10 or fewer attempts (but not 0)
- Reset account lockout counter: 15 minutes or longer
Operating Systems
- Is every operating system (OS) fully supported by the vendor and patched to the latest levels? And is this reviewed at least once a month?
- Have all unnecessary services and daemons been removed or disabled? Have web, FTP, telnet and remote desktop access been removed? The best tip is to disable everything you know is not required (like Themes service) and then carefully experiment one at a time with other services you feel are unnecessary. If disabling a service compromises business operations, keep it enabled.
- Do you know which ports are open? Is there a good reason for them to remain open or can they be removed? Can you detect new open ports when they appear?
- Has the Local Security Policybeen fully leveraged? Exploitable vulnerabilities can be mitigated using this policy, which offers hundreds of fine-grained security configuration controls to strengthen security.
Example: Define the following settings for Windows operating systems:
- Allow UIAccess applications to prompt for elevation without using secure desktop: Disabled
- Elevation prompt for administrators in Admin Approval Mode: Prompt for consent on the secure desktop
- Elevation prompt for standard users: Automatically deny elevation requests
- Detect application installations and prompt for elevation: Enabled
- Only elevate UIAccess applications that are installed in secure locations: Enabled
- Run all administrators in Admin Approval Mode: Enabled
- Virtualize file and registry write failures to per-user locations: Enabled
File Systems
- For Unix and Linux servers, are permissions on key security files (such as /etc/password and /etc/shadow) set in accordance with best practice recommendations? Is sudo being used? If so, are only root wheel members are allowed to use it?
- For Windows servers, are the key executables, DLLs and drivers protected in the System32 and SysWOW64 folder, along with the Program Files/(x86)?
Example: Apply file integrity monitoring to the following files and folders:
- %PROGRAMFILES%: Use SHA1 hash, system file changes, exclude log files, recursive
- %PROGRAMFILES(x86)%: Use SHA256 hash, system file changes, exclude log files, recursive
- %SYSDIR%: Use SHA256 hash, system file changes, exclude log files, recursive
- %WINDIR%SysWOW64: Use SHA256 hash, system file changes, exclude log files, recursive
Client/Server Network
- Is the built-in software firewall enabled and configured as “Deny All”?
- On Linux, have the TCP Wrappers been configured for “Deny All”?
- Have remotely accessible registry paths and shares been restricted appropriately for your environment? This will be different for a member server versus a domain controller.
Example: In your security policy, specify the following network client and network server settings:
- Digitally sign communications (if server agrees): Enabled
- Send unencrypted password to third-party SMB servers: Disabled
- Digitally sign communications (always): Enabled
- Digitally sign communications (if client agrees): Enabled
- Disconnect clients when logon hours expire: Enabled
Auditing and Change Control
- Are audit trails enabled for all access, use of privilege, configuration changes, and object access, creation and deletion?
- Are audit trails securely backed up and retained for at least 12 months?
- Is a central, protected NTP source configured and in use?
- Is file integrity monitoring (FIM) used to maintain your secure build standards?
- Is there a defined change management process that includes change proposal (covering impact analysis and rollback provisions), change approval, QA testing and post-implementation review?
- Are logged events securely backed up to a central server? This requires a means of forwarding events from monitored servers to the log server (usually a Syslog forwarding agent or a more comprehensive solution like Netwrix Change Tracker) as well as a structured audit policy.
Example: Define the following settings in your Advanced Audit Policy:
- Audit Logoff: Success
- Audit Logon: Success and Failure
- Audit Other Logon/Logoff Events: Success and Failure
- Audit Special Logon: Success
Software and Applications
- Which packages and applications are defined by your secure build standard? For example, do you have standards for your anti-virus, data leakage prevention, firewall and FIM tools? What is the process for periodically updating the baselines with any approved changes?
- Is there a process to ensure you have the latest versions and that patches have been tested and applied?
- Are automated updates to packages disabled in favor of scheduled update deployment?
Choosing a Server Hardening Policy and Tailoring It to Your Organization
Getting a hardening checklist or server hardening policy is easy enough. For example, the Center for Internet Security (CIS) provides hardening checklists; Microsoft offers checklists for Windows devices; Cisco provides checklists for its routers; and the National Vulnerability Database hosted by NIST provides checklists for a wide range of Linux, Unix, Windows and firewall devices. NIST also provides the National Checklist Program Repository, which is based on the SCAP and OVAL standards.
These are great starting points, but you need to tailor any checklist based on a server’s operation and role. For example, an internet-facing server needs stronger access control than a database server that’s behind your firewall.
Once you have established your server hardening policy and applied the best-practice checklists to your standard build, you need to continuously audit all devices for any configuration drift. Your change management process should define how changes are assessed and then either remediated or promoted to the configuration baseline. Netwrix Change Tracker provides intelligent change control, so changes need to be approved only once for one server, and then any other occurrences of the same change will automatically be approved. This removes the biggest problem with most FIM and SIEM systems, which is that change noise can easily become overwhelming.
Summary
The most effective first step in any data security strategy is to prevent security breaches. By proactively addressing configuration vulnerabilities through hardening, servers can be made more secure and resistant to attacks. Change management and file integrity monitoring solutions then watch for any deviation from your baseline so you ensure that all servers remain securely configured.
FAQ
What is server hardening?
Server hardening is the proactive process of disabling unused programs and functionality, tightening up server security settings, and enforcing auditing and incident response best practices in order to make servers less vulnerable to attack.
What is a hardening policy?
A hardening policy is a set of guidelines and procedures implemented to reduce a system’s attack surface area. The policy should be based on for access control, logging and incident response. A policy can be specific to a particular system, like Linux or Windows Server, or generalized like a database hardening policy.
What is a system hardening policy template?
A system hardening policy template is a document that outlines the guidelines and procedures to be followed in order to secure and protect systems. It typically includes a list of best practices and security controls to be implemented for specific assets. The template can be used as a starting point for creating a custom hardening policy for various systems.
How do I harden my server security?
Key steps typically include:
- Removing unnecessary software and services to reduce the attack surface area
- Configuring firewalls and intrusion detection/prevention systems to block unauthorized access
- Enabling security features such as encryption and secure boot
- Implementing best practices for access control, such as multifactor authentication and least privilege
- Regularly updating software and applying security patches
- Implementing robust event logging and traffic monitoring to detect and respond to possible security incidents
- Regularly testing and reviewing the server hardening policy to identify and address any vulnerabilities.
