Windows Server Security Best Practices: Secure Your Windows Server Environment. Whether we are hand-building physical servers for a small firm or deploying hundreds of Windows servers into the cloud, having a solid procedure to create a secure, stable environment is essential to protecting our ecosystem from data breaches. Of course, everyone knows that an out-of-the-box Windows server may need all the necessary security measures to go right into production. However, Microsoft has been improving the default configuration in every server version.
This article talks about multiple security best practices on how to secure our Windows Server environment.
Windows Server Security Best Practices: Secure Your Windows Server Environment
Specific best practices differ depending on need, but addressing these 10 areas before subjecting a server to the internet protects against the most common exploits. Many of these is general advice that applies to all servers. At the same time, some are Windows-specific, delving into ways we tighten up the Microsoft server platform.
In the following section, we discuss multiple Windows Server concepts and how we secure it accordingly.
User Configuration
Modern Windows Server editions force us to do this, but make sure that we reset the local Administrator password to something secure. Furthermore, disable the local admin 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 to prevent it from being exploited.
Hence, we must set up an admin account. Either add an appropriate domain account if our server is a member of an Active Directory (AD) or create a new local account and put it in the administrator’s group. Either way, we may want to consider using a non-admin account to handle our business whenever possible, requesting elevation using Windows sudo equivalent, “Run As” and entering the password for the admin account when prompted.
Verify that the local guest account is disabled where applicable. No built-in charges are secure, guests perhaps least of all, so just close that door. Double-check our security groups to make sure everyone is where they are supposed to be (adding domain accounts to the remote desktop users group, for example.)
Password Policies
Remember to protect our passwords. Use a strong password policy to ensure accounts on the server can’t be compromised. If our server is a member of AD, we set the password policy at the domain level in the Default Domain Policy. Set the standalone servers in the local policy editor. Either way, a good password policy to last establish the following:
- Complexity and length requirements strength of the password.
- Password expiration – how long the password is valid.
- Password history – how long until we use previous passwords.
- Account lockout – how many failed password attempts before the system suspends the account.
Old passwords account for many successful hacks, so protect against these by requiring regular password changes.
Network Configuration
Up next with Windows Server Security Best Practices: Secure Your Windows Server Environment. If customers locate production servers with confidence, they should have static IP addresses. This IP should be in a protected segment behind a firewall. Configure at least two Domain Name System (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 we want and a PTR record for reverse lookups. DNS changes may take several hours to propagate across the internet, so we should establish production addresses well before a go-live window. Finally, disable any network services the server won’t use, such as IPv6.
This setup depends on our environment, and any changes here should be well-tested before going into production.
Try our Active Directory & Office 365 Reporting & Auditing Tools
Try us out for Free. 100’s of report templates available. Easily customise your own reports on AD, Azure AD & Office 355.
Windows Roles and Features Configuration
Microsoft uses roles and features to manage OS packages. Roles are a collection of features designed for a specific purpose, so generally, we choose roles if the server fits one, and then we customize the features from there. Two equally important things to do:
Install necessary components:
- Ensure the installation of required frameworks like .NET Framework versions or IIS (Internet Information Services).
- These components are essential for the proper functioning of our applications.
Uninstall unnecessary components:
- Remove any software or components that are not needed.
- This helps streamline the system and improve efficiency by eliminating unnecessary clutter.
Extraneous packages unnecessarily extend the server’s attack surface and should be removed whenever possible. This process is equally valid for default applications installed on the server we will not use. Servers should be designed with necessity in mind and stripped lean to make the necessary parts function as smoothly and quickly as possible.
Update Installation
The best way to keep our server secure is to keep it up to date. This process is about having a strategy to ensure updates get applied within a reasonable window. Most exploited vulnerabilities are over a year old, though we should apply the critical updates as soon as possible in testing and then in production, if there are no problems.
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 vulnerabilities.
- Service packs are updates to a wide range of vulnerabilities, comprised of dozens or hundreds of patches.
Each application should be updated regularly and with testing.
Windows OS Patching
Remember that the OS version is a form of an update as well, and running server versions from years ago puts us far behind the curve in terms of security. If our production schedule allows it, we should configure automatic updates on our server. Unfortunately, the workforce to review and test every patch we improve in many IT shops leads to stagnation when installing updates.
It’s much more dangerous to leave a production system unpatched than to automatically update it, at least for critical patches.
The updates should be staggered so test environments receive them a week or so earlier, allowing teams to observe their behaviour. In addition, we apply optional updates manually, as they usually address minor issues. Other MS software updates through Windows Update as well, so make sure to turn on updates for other products, if we are running Exchange, SQL, or another MS server technology.
NTP Configuration
A time difference of merely five (5) minutes completely breaks Windows logons and various other functions that rely on Kerberos authentication. Servers that are domain, members automatically have their time synched with a domain controller upon joining the domain. Still, standalone servers must set up NTP to sync to an external source so the clock remains accurate.
Domain controllers should also have their time synched to a time server, ensuring the entire domain remains within the operational range of actual time.
Firewall Configuration
If we are building a web server, for example, we only want web ports (80 and 443) open to that server from the internet. If anonymous internet clients talk to the server on other ports, that opens a vast and unnecessary security risk. Suppose the server has other management functions, such as remote desktop (RDP).
In that case, 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 firewall is a decent built-in software firewall that allows the configuration of port-based traffic from within the OS. On a standalone server or any server without a hardware firewall in front of it, the Windows firewall at least provides some protection against network-based attacks by limiting the attack surface to the allowed ports.
That said, a hardware firewall is always a better choice because it offloads the traffic to another device and offers more options for handling that traffic, leaving the server to perform its primary duty. Whichever method we use, the critical point is to restrict traffic to only necessary pathways.
Remote Access Configuration
As mentioned above, if we use RDP, be sure it is only accessible via VPN, if possible. Leaving it open to the internet doesn’t mean we get hacked, but it does offer potential hackers another inroad into our server. Make sure RDP is only accessible by authorized users.
In addition to RDP, other remote access mechanisms such as PowerShell and SSH should be carefully locked down, if used and made accessible only within a VPN environment. For example, we should refrain from using telnet, as it passes information in plain text and is woefully insecure in several ways. The same goes for FTP. Instead, use SFTP or SSH (from a VPN) whenever possible and avoid unencrypted communications altogether.
Service Configuration
Several essential services on Windows Server are started 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 server’s attack surface by disabling everything other than primary functionality.
Older versions of MS servers have more unneeded services than newer ones, so carefully check any 2008 or 2003 servers. We should set essential services to start automatically so the server recovers without human interaction after failure. For more complex applications, take advantage of the Automatic (Delayed Start) option to give other services a chance to get going before launching intensive application services.
Also set up service dependencies, in which a service waits for another service or set of services to start successfully before starting. Dependencies also allow us to stop and create an entire chain simultaneously, which is helpful when timing is essential.
Finally, each service operates in a particular user’s security context. We frequently do this as admins as the Local and Network Service accounts for standard Windows services. Most of the time, this setup might be effective.
Still, 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 process keeps malicious actors who have compromised an application from extending that compromise into other areas of the server or domain.
Logging and Monitoring
Finally, we need to monitor the logs and capture the data we want so that in the event of a problem, we quickly find what we need and remediate it. Logging works differently depending on whether our server is part of a domain. Domain controllers process domain logins, so they have the audit logs for that activity, not the local system.
Standalone servers have security audits available, and we configure them to show passes and failures. Check the max size of our logs and scope them to an appropriate size. Log defaults are almost always far too small to monitor complex production applications.
Log Monitoring
As such, we allocate the disk space during server builds for logging, especially for applications like MS Exchange. Logs should be backed up according to our organization’s retention policies and cleared to make room for more current events. Consider a centralized log management solution, if handling logs individually on servers overwhelm us.
Like a Syslog server in the Linux world, a centralized event viewer for Windows servers helps speed up troubleshooting and remediation times for medium to large environments. First, establish a performance baseline and set up notification thresholds for essential metrics. Whether we use the built-in Windows performance monitor or a third-party solution that uses a client or SNMP to gather data, we need to collect performance info on every server.
Things like available disk space, processor and memory use, network activity, and even temperature is constantly analysed and recorded to identify anomalies and deal with them quickly. Admins often need to pay more attention to this step due to the hectic nature of production schedules. Still, it pays dividends in the long run because troubleshooting without established baselines is shooting in the dark.
Thank you for reading Windows Server Security Best Practices: Secure Your Windows Server Environment. We shall conclude the article now.
Also Read Deploy Azure AD Monitoring Solution
Windows Server Security Best Practices: Secure Your Windows Server Environment Conclusion
In conclusion, implementing robust security measures in your Windows Server environment is crucial to safeguarding your data and maintaining the integrity of your systems. By adhering to best practices such as regularly updating and patching the server, employing strong authentication mechanisms, and implementing proper access controls, you significantly enhance the security posture of your Windows Server. Additionally, ongoing monitoring, logging, and regular security audits help detect and mitigate any potential vulnerabilities, ensuring a secure and resilient server environment.
Try InfraSOS for FREE
Invite your team and explore InfraSOS features for free
- Free 15-Days Trial
- SaaS Reporting & Auditing Solution
- Full Access to All Features
