S 5.123 Securing network communication in Windows

Initiation responsibility: Administrator, IT Security Officer

Implementation responsibility: Administrator

The security of a Windows infrastructure is not only determined by the secure configuration and the secure operation of individual systems. The overall security is also highly dependent on the security of the network communication, which is determined by the security of the lines of communication (signatures, encryption) and the authentication mechanisms used, among other things.

In general, network components that are not used (e.g. File and Printer Sharing for Microsoft Networks) should be removed from existing interfaces. The decision as to which network protocols should be removed must be made based on the specific circumstances and on a case-by-case basis.

Secure Channel

Communication between a client and a domain controller is performed using a so-called Secure Channel used for the transmission of authentication data, among other things. The data of the Secure Channel is encrypted with a session key. The corresponding computer account of the client (automatically administered by Windows) is used to open this channel. It is therefore essential to the security of the Secure Channel to change the password of the computer account regularly (see S 5.89 Configuration of the Secure Channel in Windows).

Signing and encrypting communication

All data transmitted using the Secure Channel should be signed and encrypted. By default, the data is only signed and encrypted when both communication partners use the same procedures. If one of the two partners does not support encryption or signatures, then the communication is unprotected (the corresponding policies are Domain Member: Digitally sign secure channel data (when possible) and Domain Member: Digitally encrypt secure channel data (when possible) in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options). If the Domain Member: Digitally encrypt or sign secure channel (always) policy is enabled, then communication must be signed or encrypted. If the two partners do not support the same procedures, then a connection is not established. The use of this option is recommended when all domain controllers of the domain and all trusted domains run Windows 2000 or higher.

The SMB (Server Message Block) protocol does not only support mutual authentication, but also allows the SMB packets to be signed. The use of authentication and signatures prevents man-in-the-middle attacks.

The SMB signatures are configured using the following policies in Computer Configuration | Windows Settings | Security Settings | Locale Policies | Security Options:

The use of signatures for SMB packets is not mandatory in Windows by default, and only the policy Microsoft network (client): Digitally sign communications (if server agrees) is enabled. The communication is only signed if signing is enabled for the packets on the SMB server. However, it is possible to force the use of signatures. To force their use, the other policies listed above need to be enabled as well.

Enabling the policies mandating SMB communication to be signed can affect the compatibility with clients, services, and applications. For this reason, compatibility tests must be conducted before enabling these settings.

Not all SMB servers from third-party manufacturers support password encryption during authentication. If such a server is accessed using the SMB protocol, then the password may be transmitted unencrypted if the policy Microsoft network (client): Send unencrypted password to connect to third-party SMB servers is enabled. However, the transmission of unprotected passwords should be prohibited, which means this policy must not be enabled.

Windows allows the definition of a minimum session security level for communication at the application level (e.g. between RPC components). The following options can be selected in the two policies Network Security: minimum session security for NTLM SSP based (including secure RPC) clients and Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options:

The default settings do not contain minimum option settings. If all clients are running the Windows XP (or higher) operating system, all servers are running the Windows Server 2003 (or higher) operating system, and 128-bit encryption is enabled on all IT systems, the options for NTLMv2 authentication and 128-bit encryption must be enabled.

Strong authentication mechanism

The quality of the authentication method used when logging in to the network also plays an important role in guaranteeing security. A total of four authentication mechanisms can be used: LM, NTLMv1, NTLMv2, and Kerberos. The LM method was initially used in versions prior to Windows 2000, and the NTLM method (two different versions) is used in Windows NT and higher. However, these older methods have their weaknesses, and it is possible to determine the password from the authentication value transmitted. Version 2 of the NTLM protocol, as well as Kerberos, offer the best protection. Kerberos is implemented as the standard protocol for authentication during user login. NTLM allows for compatibility with older systems.

Kerberos is a cryptographic network protocol for distributed authentication. Kerberos implements an authentication within a network, including key exchange, without the participating locations knowing a joint key. This is achieved by introducing another protocol instance.

If possible, Kerberos should be used in networks containing Windows computers only (running the Windows 2000 or higher client or server operating systems) since this method is the most secure. If using Kerberos is not possible, the authentication is automatically implemented using NTLMv2. Using the older protocols should be avoided due to their inherent weaknesses. To prevent their use, the corresponding policy in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options | Network security: LAN Manager authentication level should be set to the value Send NTLMv2 response only\refuse LM & NTLM.

Storing LAN Manager hash values when changing passwords should be disabled. This is accomplished by enabling the policy Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options | Network security: Do not store LAN Manager hash value on next password change.

If even older systems are still in use (Windows 9x or Windows NT 4.0 prior to Service Pack 4), then it may be necessary for compatibility reasons to allow other authentication mechanisms, although this is not recommended from a security perspective. It is generally recommended to update the older systems by installing the corresponding service packs (Windows NT 4.0 Service Pack 4 or higher) or to use additional software (NTLMv2 is also available for Windows 95/98 together with the optional client for directory services).

Anonymous access

It should be impossible to gain anonymous access over the network (referred to as NULL SESSIONS). In Windows XP, certain activities such as enumerating SAM accounts anonymously are permitted by default. This functionality must be disabled explicitly by enabling the policies Network access: Prohibit anonymous SID/Name translation, Network access: Do not allow anonymous enumeration of SAM accounts and Network access: Do not allow anonymous enumeration of SAM accounts and shares (in Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options). The policy Network access: Let "Everyone" authorisations apply to anonymous users must be disabled. In Windows Vista and Windows 7, this policy is already disabled by default.

Securing the network communication using DirectAccess

In Windows 7 and Windows Server 2008 R2 and higher, the DirectAccess function allows permanent logical connection of a client to the network of the information system, regardless of the type of network connection. This procedure establishes the network communication via a tunnel connection between the client and other computers of the Windows domain. The tunnel can be used both by external networks and within the network of the information system. It remains as long as the Windows system is connected to the network.

Using DirectAccess, the client already establishes a connection to the network of the information system before the user logs in using a certificate. This way, GPO updates and new policies are accepted before the user logged in with his/her account, for instance. The basic configuration does not provide for any security measures regarding data transmission upon user login. Only the computer authentication of the clients is encrypted. Therefore, the transmission should be secured with certificate-based IPSec. For this, a PKI is required that should be established within the network of the information system. S 5.90 Using IPSec in Windows must be implemented in order to configure IPSec.

By default, no uniform security logging is pre-set in Windows clients for DirectAccess. Among other things, monitoring options can be found here:

- gpedit.msc | ... | Advanced Monitoring Policy Configuration | Login/Logout | IPSec ...

- perfmon.exe | Performance Monitoring | Performance Indicators (e. g. IP-HTTPS, Teredo, IPSec, WFP)

These protocols can grow very quickly and may affect the functionality of the computer. Therefore, the monitoring settings should be aligned carefully with the requirements of the information system together with the server components of DirectAccess. Client-side logging must be ensured.

Review questions:

© Federal Office for Information Security. All rights reserved.