When you have just installed your new Windows Server, with or without IIS as web server, it is important to take a few extra security measurements. Securing your server is important to keep hackers out and your data safe. This article provides 4 key steps in strengthening your Windows Server web (IIS) or file server security.
In this post I address four (4) important security steps for you, for servers running Windows Server (AD DS, DFS, IIS) and RDP.
Set security measures through Group Policy Objects (GPO's) in Windows Server
Where possible, we'll pursue the road of Group Policy Objects, or GPO's. You can use a GPO to roll out a security measurement across your entire network.
The four hardening techniques I'm going to show you are (in random order):
- Extended Protection for Authentication
- Hardened UNC Paths
- SMB Signing
- Remote Desktop Services (bonus tip!)
There are more security measurements of course, maybe more on that in a later post.
Talking about GPO's, did you know you can disable SMB1 and enable NTFS long paths support in Windows Server 2016 using GPO's?
Extended Protection for Authentication
Extended Protection for Authentication is a new feature introduced in the Windows platform since Windows Vista. This feature enhances the protection and handling of credentials when authenticating network connections by using Integrated Windows Authentication (IWA).
When Extended Protection for Authentication is enabled, authentication requests are bound to both the Service Principal Names (SPN) of the server the client tries to connect to and to the outer Transport Layer Security (TLS) channel over which the IWA authentication occurs. This is a base update that enables applications to opt in to the new feature.
You can read more about Extended Protection for Authentication on Microsoft Knowledge Base article 968389.
Regkey to add Extended Protection for Authentication Group Policy
To be able to configure Extended Protection for Authentication through Group Policy, you'll need to add the option to the Group Policy Management. This is easily done with a registry key.
Copy and paste the following contents into a new text file, save it as secpoladd.reg and import it into your Windows Server registry. A server reboot is not necessary.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SeCEdit\Reg Values\MACHINE/System/CurrentControlSet/Control/Lsa/SuppressExtendedProtection]
"ValueType"=dword:00000004
"DisplayType"=dword:00000003
"DisplayName"="Network Security: Extended Protection for Authentication"
"DisplayChoices"=hex(7):30,00,7c,00,45,00,6e,00,61,00,62,00,6c,00,65,00,64,00,00,00,33,00,7c,00,44,00,69,00,73,00,61,00,62,00,6c,00,65,00,64,00,00,00,00,00Learn how to silently import .reg files.
Now you have a Group Policy Object Network Security: Extended Protection for Authentication available at:
- Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options.
Enable this one.
Hardened UNC Paths
Enabling Hardened UNC Path is a security recommendation, but it is essential to ensure no application is dependent on the UNC path. Hardened UNC Paths must be defined to require mutual authentication and integrity for at least the \\*\SYSVOL and \\*\NETLOGON shares. The Hardened UNC Paths is a GPO available at:
- Computer Configuration > Policies > Administrative Templates > Network > Network Provider
When enabled, you have to specify hardened network paths, for example \\*\NETLOGON or \\*\SYSVOL, and a value such as RequireMutualAuthentication=1, RequireIntegrity=1.
You should require both Integrity and Mutual Authentication for any UNC paths that host executable programs, script files, or files that control security policies. Consider hosting files that do not require Integrity or Privacy on separate shares from those that absolutely need such security for optimal performance.
The Group Policy service on domain-joined Windows-based computers automatically tries to download updated security policies from Universal Naming Convention (UNC) paths that begin with \\domain\SYSVOL. It will run any scripts that are configured to run in the applicable Group Policy Objects (GPOs). Typically, these are stored in UNC paths that being with \\domain\NETLOGON.
When applications make I/O requests that contain Uniform Naming Convention (UNC) paths, these requests are passed to the Multiple UNC Provider (MUP). The MUP selects a UNC provider to handle the I/O request and forwards the request to the selected UNC provider. The selected UNC provider handles the request and passes the results back to the application that issued the request.
If a malicious party can spoof, tamper with, or redirect communications between the UNC provider and the target server, the malicious party may be able to cause Group Policy to execute programs or scripts with malicious intent instead of or in addition to scripts that are selected by system administrators.
Microsoft is announcing the availability of UNC Hardened Access, a new feature on the Windows platform. To provide mitigations against this and related attacks, this feature improves the protection and handling of data when Windows-based computers access UNC paths.
When MUP receives an I/O request for a UNC path that is configured to require UNC Hardened Access, MUP will consider only UNC providers that support the security properties that are required according to the UNC Hardened Access configuration.
For more information and details, see https://support.microsoft.com/kb/3000483.
SMB Signing
The Server Message Block (SMB) protocol provides the basis for Microsoft file and print sharing and many other networking operations, such as remote Windows administration. To prevent man-in-the-middle attacks that modify SMB packets in transit, the SMB protocol supports the digital signing of SMB packets.
Server Message Block (SMB) signing is a security mechanism that attempts to prevent man-in-the-middle attacks. If a network administrator configures SMB signing on clients and servers, signatures are added to the packet header. A decrypted signature by the recipient server or client indicates a valid packet. If the signature is malformed or not present, or if the SMB packet is compromised, the client or server rejects and drops the packet.
SMB signing is available in all currently supported versions of Windows, but it's only enabled by default on Domain Controllers. This is recommended for Domain Controllers because SMB is the protocol used by clients to download Group Policy information. SMB signing provides a way to ensure that the client is receiving genuine Group Policy.
With the introduction of SMB2 in Windows Vista and Windows Server 2008, signing was improved by using a new hashing algorithm (HMAC SHA-256 replaced the old MD5). SMB3 uses AES-CMAC for signing instead of HMAC SHA-256 in SMB2.
You can configure SMB Signing in a Group Policy Object through the following path:
- Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options.
| Policy | Setting |
|---|---|
| Microsoft network client: Digitally sign communications (always) | Enabled |
| Microsoft network client: Digitally sign communications (if server agrees) | Disabled |
| Policy | Setting |
|---|---|
| Microsoft network client: Digitally sign communications (always) | Enabled |
| Microsoft network client: Digitally sign communications (if server agrees) | Disabled |
Secure Remote Desktop Services (RDP) connections - bonus tip!
It is very important to secure incoming Remote Desktop Services (RDP) connections! Let me repeat that: it is very important to secure incoming RDP connections!
From time tot time vulnerabilities in the Remote Desktop Protocol are disclosed. Often these are heavily abused, sometimes they're also wormable. We all remember BlueKeep (CVE-2019-0708), and I'm sure you don't want an evil third party logging on to your Windows Server as an administrator, now do you?
To secure RDP on your servers, it is important to stay up to date with Microsoft security updates - through Windows Update and WSUS.
There are other ways to mitigate most RDP vulnerabilities. They are so trivial they already must be deployed in your Windows Server environment. One of such a mitigation is NLA, or Network Level Authentication.
Network Level Authentication (NLA) for Remote Desktop Services (RDP)
What is NLA? Network Level Authentication(NLA) is a technology used in Remote Desktop Services (RDP Server) or Remote Desktop Connection (RDP Client) that requires the connecting user to authenticate themselves before a session is established with the server.
Here is how to batch delete saved RDP credentials from Windows 10 Credentials Manager.
So by using NLA, you basically eliminated the possibility for attackers to brute-force your RDP servers, because NLA forces users to authenticate before connecting. Requiring NLA in your network dramatically decreases the chance of success for RDP-based worms.
Fortunately, you can force NLA through a Group Policy Object (GPO) easily. In Group Policy Management, create a GPO and enable the setting Require user authentication for remote connections by using Network Level Authentication.
- Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security
While you're at it, also enable Set client connection encryption level, and set it to High Level.
Please note that enabling Network Level Authentication provides no protection if an attacker has credentials...
I hope you've enjoyed this post and could implement the tips provided Let me know with a comment! :-)
Thank you very much! <3 ❤️
Hi, my name is Jan. I am not a hacker, coder, developer or guru. I am merely an application manager / systems administrator, doing my daily thing at Embrace – The Human Cloud. In the past I worked at CLDIN (CLouDINfra) and Vevida. With over 20 years of experience, my specialties include Windows Server, IIS, Linux (CentOS, Debian), security, PHP, websites & optimization. I blog at https://www.saotn.org.
