Everyone knows that an out-of-the-box Windows server may not have all the necessary security measures in place to go right into production, although Microsoft has been improving the default configuration in every server version. Specific best practices differ depending on need, but addressing these six steps before subjecting a server to the internet will protect against the most common exploits. Many of these are standard recommendations that apply to servers of any flavor, while some are Windows specific, delving into some of the ways you can tighten up the Microsoft server platform.
1. User Configuration and Network Configuration
Modern Windows Server editions force you to do this, but make sure the password for the local Administrator account is reset to something secure. Furthermore, disable the local administrator whenever possible. There are very few scenarios where this account is required and because it’s a popular target for attack, it should be disabled altogether to prevent it from being exploited. With that account out of the way, you need to set up an admin account to use. You can either add an appropriate domain account, if your server is a member of an Active Directory (AD), or create a new local account and put it in the administrators group.
Don’t forget to protect your passwords. Use a strong password policy to make sure accounts on the server can’t be compromised. If your server is a member of AD, the password policy will be set at the domain level in the Default Domain Policy. Stand alone servers can be set in the local policy editor. Either way, a good password policy will at least establish the following:
- Complexity and length requirements – how strong the password must be
- Password expiration – how long the password is valid
- Password history – how long until previous passwords can be reused
- Account lockout – how many failed password attempts before the account is suspended
1.1 Windows Server Network Configuration
Production servers should have a static IP so clients can reliably find them. This IP should be in a protected segment, behind a firewall. Configure at least two DNS servers for redundancy and double check name resolution using nslookup from the command prompt. Ensure the server has a valid A record in DNS with the name you want, as well as a PTR record for reverse lookups. Note that it may take several hours for DNS changes to propagate across the internet, so production addresses should be established well before a go live window. Finally, disable any network services the server won’t be using, such as IPv6. This depends on your environment and any changes here should be well-tested before going into production.
2. Windows Features, Roles Configuration and Update Installation
Microsoft uses roles and features to manage OS packages. Roles are basically a collection of features designed for a specific purpose, so generally roles can be chosen if the server fits one, and then the features can be customized from there. Two equally important things to do are 1) make sure everything you need is installed (f.e. NET framework version or IIS); without the right pieces your applications won’t work. 2) Uninstall everything you don’t need. Extraneous packages unnecessarily extend the attack surface of the server and should be removed whenever possible. Servers should be designed with necessity in mind and stripped lean to make the necessary parts function as smoothly and quickly as possible.
2.1 Update Installation of Windows Server
The best way to keep your server secure is to keep it up to date. This doesn’t necessarily mean living on the cutting edge and applying updates as soon as they are released with little to no testing, but simply having a process to ensure updates do get applied within a reasonable window.
There are different kinds of updates: patches tend to address a single vulnerability; roll-ups are a group of packages that address several, perhaps related vulnerability, and service packs are updates to a wide range of vulnerabilities, comprised of dozens or hundreds of individual patches. Keep in mind that the version of the OS is a type of update too, and using years-old server versions puts you well behind the security curve. If your production schedule allows it, you should configure automatic updates on your server. It’s much more dangerous, however, to leave a production system unpatched than to automatically update it, at least for critical patches. If at all possible, the updates should be staggered, so test environments receive them a week or so earlier, giving teams a chance to observe their behavior.
3. NTP Configuration and Firewall Configuration
A time difference of merely 5 minutes will completely break Windows logons and various other functions that rely on kerberos security. Servers that are domain members will automatically have their time synched with a domain controller upon joining the domain, but stand alone servers need to have NTP set up to sync to an external source so the clock remains accurate.
3.1 Firewall Configuration on Windows Server
If you’re building a web server, for example, you’re only going to want web ports (80 and 443) open to that server from the internet. If the server has other functions such as remote desktop (RDP) for management, they should only be available over a VPN connection, ensuring that unauthorized people can’t exploit the port at will from the net.
The Windows Server firewall is a decent built-in software firewall that allows configuration of port-based traffic from within the OS. On a stand alone server, or any server without a hardware firewall in front of it, the Windows Server firewall will at least provide some protection against network based attacks by limiting the attack surface to the allowed ports.
4. Remote Access and Service Configuration
As mentioned, if you use RDP (Remote Desktop Platform), be sure it is only accessible via VPN. Leaving it open to the internet doesn’t guarantee you’ll get hacked, but it does offer potential hackers another inroad into your server. Make sure RDP is only accessible by authorized users. By default, all administrators can use RDP once it is enabled on the server. Additional people can join the Remote Desktop Users group for access without becoming administrators.
In addition to RDP, various other remote access mechanisms such as Powershell and SSH should be carefully locked down if used and made accessible only within a VPN environment.
4.1 Service Configuration on Windows Server
Windows server has a set of default services that start automatically and run in the background. Many of these are required for the OS to function, but some are not and should be disabled if not in use. Following the same logic as the firewall, we want to minimize the attack surface of the server by disabling everything other than primary functionality. Older versions of MS server have more unneeded services than newer, so carefully check any 2008 or 2003 (!) servers.
Finally, every service runs in the security context of a specific user. For default Windows services, this is often as the Local System, Local Service or Network Service accounts. This configuration may work most of the time, but for application and user services, best practice dictates setting up service specific accounts, either locally or in AD, to handle these services with the minimum amount of access necessary. This keeps malicious actors who have compromised an application from extending that compromise into other areas of the server or domain.
5. Further Hardening
Microsoft provides best practices analyzers based on role and server version that can help you further harden your systems by scanning and making recommendations – server security patching. Although User Account Control (UAC) will prevent applications from running as you without your consent. This prevents malware from running in the background and malicious websites from launching installers or other code. Leave UAC on whenever possible.
The tips in this guide help secure the Windows operating system, but every application you run should be hardened as well. Common Microsoft server applications such as MSSQL and Exchange have specific security mechanisms that can help protect them against attacks like ransomware, be sure to research and tweak each application for maximum resilience. If you’re building a web server, you can also follow our hardening guide to improve its internet facing security.
6. Logging and Monitoring
Finally, you need to make sure that your logs and monitoring are configured and capturing the data you want so that in the event of a problem, you can quickly find what you need and remediate it. Logging works differently depending on whether your server is part of a domain. Domain logons are processed by domain controllers, and as such, they have the audit logs for that activity, not the local system. Stand alone servers will have security audits available and can be configured to show passes and/or failures.
Log defaults are almost always far too small to monitor complex production applications. As such, disk space should be allocated during server builds for logging, especially for applications like MS Exchange. Logs should be backed up – link to back up and disaster recovery landing according to your organization’s retention policies and then cleared to make room for more current events. Consider a centralized log management solution if handling logs individually on servers gets overwhelming. Like a syslog server in the Linux world, a centralized event viewer for Windows servers can help speed up troubleshooting and remediation times for medium to large environments.
Whether you use the built-in Windows performance monitor, or a third party solution that uses a client or SNMP to gather data, you need to be gathering performance info on every server. Things like available disk space, processor and memory use, network activity and even temperature should be constantly analyzed and recorded so anomalies can be easily identified and dealt with.
Windows Server Setup and How Can ITAF Help You?
Each one of these steps can take some time to implement, especially if you are doing this for the first time. But by establishing a routine of initial server configuration and infrastructure, you can ensure that new machines in your environment will be resilient. For any query related to your server-to-server communication setup, please contact us and we will be glad to help you.