Infrastructure needs to be able to leverage scripting automation to perform Vulnerability Remediation, Resource Provisioning, and Streamlined Patching. Similar to other organizations in our industry, we have been using scripts within our environment to achieve efficiency in executing repeated tasks as well as ad-hoc systems administration.
1. Security Considerations:
It’s a known issue that WinRM client/server model involves the client to directly connect to the server’s svchost.exe process (using Kerberos encrypting/ticketing sessions for domain accounts). Script execution can be difficult to trace. The way it works is that svchost.exe automatically spawns many instances of wmiprvse.exe as a parent of an executable being invoked from the client. To mitigate these potential untraceable script executions, it is necessary to only allow WinRM connections from only trusted machines, colloquially known as “jump boxes.” Here’s a quick illustration of this concept:
Jumpbox1 (trusts Jumpbox2) <——> Jumpbox2 (trusts Jumpbox1 and Jumpbox3) <——> Jumpbox3 (trusts Jumpbox2)
In the quick drawing above, Jumpbox1 cannot connect directly to Jumpbox3. It must have a session with Jumpbox2, and then it may connects to Jumpbox3 from Jumpbox2. In our environment, we seem to have a Business Continuity server named JUMP01 as a Jumpbox. Next, we should setup some AD servers to allow WinRM connection from this trusted node as precursor to allow remote PowerShell executions for the purposes mentioned above.
The three-point jumpboxes configuration is to encompass out of band sessions. Currently, we only need a two-point configuration. Simply, a few trusted machines located in the internal network to be able to access domain joined machines via WinRM. Hence, this drawing is more practical for our purposes:
Domain Machines (trusted specific machine(s)) <—— JUMP01
Another concern is whether WinRM accepts NTLM authentication. By default Kerberos and NTLM are both set to True. Moreover, the server will select Kerberos protocol if a domain account is used to authenticate, and NTLM is chosen for local server accounts. In other words, NTLM will not be selected by the server for domain accounts. Hence, it is important to either disable local accounts or turn off NTLM on servers to mitigate this potential vulnerability. Once that is done, Kerberos will be forced and it is more secured than NTLM. Following are some simple methods to achieve this objective:
Set Group Policy to Disable NTLM & Set WinRM Authentication Methods
Run: gpedit.msc to configure these settings:
Computer > Policies > Administrative Templates > Windows Settings > Security Settings > Local Policies > Security Options > Deny All
Computer > Policies > Administrative Templates > Windows Components > Windows Remote Management > WinRM Service > Set these:
| Allow Basic authentication | Disabled |
| Allow CredSSP authentication | Disabled |
| Disallow Digest authentication | Enabled |
| Disallow Kerberos authentication | Disabled |
| Disallow Negotiate Authentication | Disabled |
2. Working with WinRM:
Source: https://docs.microsoft.com/en-us/windows/desktop/winrm/installation-and-configuration-for-windows-remote-management
Installation:
The “winrm quickconfig” is the normal method of enabling this service on a Windows machine. It performs the following operations:
– Sets WinRM to auto-start and starts that service
– Configures listener to accept HTTP port 5985 (and HTTPS on port 5986 if host machine has a valid Certificate) to ANY client ip addresses
– Opens the local machine’s firewall port for the WinRM service
# On client side: Set Trusted server(s)
winrm quickconfig
winrm set winrm/config/client’@{TrustedHosts=”SERVER1,SERVER2″}’
# On client side: Set Trusted server(s) Alternative method
Set-Item WSMan:\localhost\Client\TrustedHosts -Value ‘SERVER1,SERVER2’
# On server side
Enable-PSRemoting -Force
winrm quickconfig
# To enable HTTPS Automatically
winrm quickconfig -transport:https
# To enable HTTPS Manually
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=”_____”;CertificateThumbprint=”_____”}
netsh firewall add portopening TCP 5986 “WinRM over HTTPS”
# Show Trusted Servers
Get-Item WSMan:\localhost\Client\TrustedHosts
# Add more trusted clients
Set-Item WSMan:\localhost\Client\TrustedHosts -Value ‘SERVER3’ -Concatenate
3. Other considerations
Scripts signing and related infrastructure to enable that functionality is also encouraged. In addition, code quality control and peer review would ensure that we increase the level of quality and security of scripted automation within our systems.