- AccessChk: View effective permissions on files and folders - Thu, Apr 13 2023
- Read NTFS permissions: View read, write, and deny access information with AccessEnum - Wed, Mar 29 2023
- Kill Windows a process with Tskill and Taskkill - Mon, Mar 13 2023
Over the past few weeks, I wrote several posts about Windows Server security. The first post introduced built-in features you can leverage to add extra security to your environment, like AppLocker, Credential Guard, and others.
After that, I started a mini-series about Windows security options available under Local Policies in Group Policy. A post called User rights assignment in Windows Server 2016 explained how to configure important system privileges. Another post called Security options in Windows Server 2016: Accounts and UAC explained settings that affect the behavior of built-in accounts, interactive logons, and the User Account Control (UAC) feature.
This is the last post in this series, showing how you can learn to configure network security options.
For each setting, the following format is used:
Name of the setting: Recommended value or values
Microsoft network client
Microsoft network client: Digitally sign communications (always): Enabled
When enabled, the Server Message Block (SMB) client requires packet signing. SMB is one of the core protocols in the Windows operating system. Session hijacking tools allow attackers (assuming they already have access to your network) to modify unsigned data, potentially force the server to perform unwanted actions, or gain unauthorized access to data. Note that with this setting enabled, setting Microsoft network server: Digitally sign communications (always) must also be enabled on those servers, otherwise the data transmission will not take place. The default value here is disabled, meaning that SMB packet signing is not required.
Microsoft network client: Digitally sign communications (if server agrees): Enabled
This is a default value. SMB packet signing is negotiated with the remote server, and if the server agrees, packets are signed. Otherwise it is allowed without signature (unless the setting described above is enabled).
Microsoft network client: Send unencrypted password to third-party SMB servers: Disabled
Some older third-party SMB servers (devices) do not support password encryption. Transmitting plaintext passwords across the network is obviously a significant security risk, therefore this setting is disabled by default, and communication with such SMB devices will not work.
Microsoft network server
Microsoft network server: Amount of idle time required before suspending session: 15 or lower
This determines the timeout before inactive SMB sessions are suspended. As each session consumes server resources, an attacker could cause a Deny of Service (DoS) situation by flooding the server SMB packets.
Microsoft network server: Digitally sign communications (always): Enabled
Microsoft network server: Digitally sign communications (if client agrees): Enabled
These two settings have the same purpose at their as the corresponding options for the Microsoft network, as explained above. Both settings should be enabled.
Note: For servers hosting multiple roles (like a small business server hosting Active Directory, file and print services) and others, SMB packet signing may reduce server performance due to the signing overhead. If you run in such situation, keep in mind that SMB signing might be the cause.
Microsoft network server: Disconnect clients when logon hours expire: Enabled
If you use logon hours for your users, this policy has to be enabled to ensure they are effective. You should also enable Network security: Force logoff when logon hours expire.
Network access: Allow anonymous SID/Name translation: Disabled
Network access: Do not allow anonymous enumeration of SAM accounts: Enabled
Network access: Do not allow anonymous enumeration of SAM accounts and shares: Enabled
These three settings determine whether an anonymous user can request SID translation of accounts and shares. If configured differently, malicious users could, for example, use a well-known SID of the Administrator’s account to learn its real name or list your user’s account names to perform social engineering attacks.
Network access: Do not allow storage of passwords and credentials for network authentication: Enabled
Passwords saved in Windows Credential Manager can be read by malicious code and exposed to attackers. Users will be forced to prompt their password if they access resources not accessible with their domain account.
Network security: Do not store LAN Manager hash value on next password change: Enabled
LAN Manager (LM) hashes are relatively weak and stored in a local computer security database. This database can be attacked with special tools and allow malicious user to gain access to resources. Enabling this setting makes such attacks more difficult, but it does not completely prevent them.
Network security: Force logoff when logon hours expire: Enabled
As mentioned earlier, if you have user logon hours configured in your domain, this setting is required for their proper enforcement.
Network security: LAN Manager authentication level: Send NTLMv2 response only. Refuse LM & NTLM
In an Active Directory (AD) environment, Kerberos’ protocol is the default authentication method. If, for some reason, Kerberos is not negotiated, AD will attempt to use LM, NTLM or NTLMv2 protocols. An example is a domain join operation. NTLMv2 is the most secure protocol of those.
Network security: Minimum session security for NTLM SSP based (including secure RPC) clients: Require NTLMv2 session security, Require 128-bit encryption
Network security: Minimum session security for NTLM SSP based (including secure RPC) servers: Require NTLMv2 session security, Require 128-bit encryption
These two settings affect the NTLM Security Support Provider (SSPI) settings used by applications that need authentication services. Configuring these settings as described above helps to protect network traffic with encryption, protecting against man-in-the-middle attacks.
Settings described in this post are the most important ones affecting network client/server behavior and security. There are also other settings available, but most of them are well-configured by default, so I consider them less important to mention here.
If you have followed all the posts in this series and added the recommended settings to your security baseline, you already made a great step to harden your servers and increase your Windows Server environment default security. If you would like to add even more security, follow the CIS Benchmarks mentioned in this post where you will find a very detailed description of all available settings.