Sysadmins of the North
Share now!





What are 4 important security measures for Windows Server & IIS?

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 shows 3 4 key steps in securing your Windows Server web (IIS) or file server.

In this post I address three (3) 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):

  1. Extended Protection for Authentication
  2. Hardened UNC Paths
  3. SMB Signing
  4. Remote Desktop Services (bonus tip!)

There are more security measurements of course, maybe more on that in a later post.

Protip: 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,\ 
  00

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.
This may interest you:   SSL in WordPress: how to move WordPress to HTTPS? The definitive guide

Enable this one.

Hardened UNC Paths

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 \\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 \\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.

This may interest you:   How to hide the .php file extension with IIS URL Rewrite Module

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.
PolicySetting
Microsoft network client: Digitally sign communications (always)Enabled
Microsoft network client: Digitally sign communications
(if server agrees)
Disabled
PolicySetting
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?

This may interest you:   Enable NTFS long paths in Windows Server 2016 by Group Policy

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.

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\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…

Any more security tips for Windows Server?

Well, don’t forget to disable SSLv3 and TLS 1.0, and to disable SMBv1. Straighten out your supported Cipher Suites in TLS/SSL (Schannel SSP) too. Speaking of IIS security, Acunetix provides you with 8 tips to secure your IIS installation! Also, have a look at Windows Server 101: Hardening IIS via Security Control Configuration for a long list of security controls.

I hope you’ve enjoyed this post and could implement the tips provided, let me know with a comment! 🙂


buy me a coffee
Buy Me A Coffee

About the Author Jan Reilink

My name is Jan. I am not a hacker, coder, developer, programmer or guru. I am merely a system administrator, doing my daily thing at Vevida in the Netherlands. With over 15 years of experience, my specialties include Windows Server, IIS, Linux (CentOS, Debian), security, PHP, WordPress, websites & optimization. Want to support me and donate? Use this link: https://paypal.me/jreilink.

follow me on:


Thank you!

Leave a Comment:

Skip to content