Microsoft's Windows Management Instrumentation, better known as WMI, is powerful remote API that's available with all Windows desktop and server operating systems since Windows NT 4.0. It's enabled by default and requires no configuration to utilize. It's this simplicity, coupled with the vast array of valuable system information that makes it invaluable for agentlessly monitoring Windows performance and collecting system inventory information remotely.
However, WMI is not all rainbows and lollipops. There are a few notable areas lacking in its implementation. For example, unlike SNMP, WMI is not very latency friendly. It's a protocol best suited to local area networks, or WANs where latency normally averages less than 100ms. That makes the WMI protocol less than ideal for remotely monitoring hosts via satellite, or heavily congested and highly latent, long distance, low bandwidth WAN links. In these scenarios it's recommended to monitor these remote hosts using SNMP, or deploy a dedicated Orion Instance to this remote location where polling can occur locally; leveraging the Enterprise Operations Console to provide a single pane of glass view for your entire organization.
I'm often asked about the security of the WMI protocol. While it's true that the majority of implementations lack payload encryption, the most meaningful component, the credentials used to gain access to the remote computer are fully encrypted using NTLM, or Kerberos. This means that even in the most insecure environment, the most sensitive information a potential hacker intercepting your packets is likely to uncover is your servers' current CPU or memory utilization. Hardly top secret stuff. The image below shows what a raw WMI packet looks like when SAM is monitoring the IIS World Wide Publishing Service "W3SVC" remotely.
In the packet capture above you can see the actual WMI query starting with "SELECT", all the way down to the name of the service being monitored by SAM. Again, this isn't really anything to be too concerned about. After all, 294 billion emails, many of which contain far more sensitive information than how much free disk space you have remaining on your server C:\ drive, are sent completely unencrypted via the internet every day.
However, for environments where regulatory mandate dictates the highest standard of network encryption requirements, such as the Department of Defense, there are a variety of different methods for encrypting WMI communications. Most commonly used are IPSEC Policies built into Windows, which serve to ensure that each and every packet communicated between these two hosts are fully encrypted, and safe from prying eyes. It's not something I'd recommend for every environment, but chances are good that if you fall under a similar regulatory mandate then you're already all too familiar with many of the options available to you for encrypting communications between two hosts.
Undoubtedly the most common question posed to me as Product Manager of both Server & Application Monitor, and Patch Manager, both of which heavily utilize WMI, is what port WMI uses to communicate with a remote host over the network? This is a somewhat loaded question, since WMI isn't limited to any particular port at all. In fact, the closest, best, and most accurate answer I can provide is that WMI is built on DCOM, and leverages the RPC Portmapper service for dynamic port allocation. Put simply, this means that WMI uses TCP Port 135 to initiate communication with the remotely managed host, then switches to any random high port anywhere between TCP port 1024-65535.
This is normally the point in the conversation where the person I'm speaking with grimaces and moans, uttering that there's no way the individual in charge of network security is going to be "okay" with opening 64512 TCP ports on the Firewall or router's access control list, simply to monitor their servers or push patches. Essentially this would be the equivalent of having no firewall at all!
Not to worry, there are a variety of different methods that can be used to limit the range of ports WMI uses to a much more meager number. It's important to note however, that Microsoft recommends that you don't limit your WMI port range down too tightly. Each allowed port in the designated port range allows one concurrent WMI connection. So the more applications you have that leverage WMI, the more ports you're likely to consume. I've personally had long-term success limiting the WMI port range down on SAM managed nodes to as few as 10 ports, but your mileage may vary. So for the purposes of this blog post I'll stick with Microsoft's recommended 100 ports. There are some additional notes you should keep in mind while reading this post and before implementing any changes.
Perhaps the simplest, and most straightforward way to limit the port range WMI uses is directly through the registry of the remotely managed host. This can be done manually following the steps below.
In this example ports 5000 through 5100 inclusive have been arbitrarily selected to help illustrate how the new registry key can be configured. For example, the new registry key appears as follows:
Ports: REG_MULTI_SZ: 5000-5100
PortsInternetAvailable: REG_SZ: Y
UseInternetPorts: REG_SZ: Y
I’ve also attached the WMI Ports 5000-5100.zip that packages these changes into an easy to use single registry file. Simply extract the archive, and double click on the "WMI Ports 5000-5100.reg" file to make the above changes on the machine and reboot.
Alternatively, these settings can be centrally configured and deployed via group policy to any machine within the domain. While the manual method referenced above may be suitable for a small handful of machines, such as those in your DMZ, it simply doesn't scale should you need to make these changes to hundreds or possibly thousands of managed hosts.
For instances such as this I’ve packaged an Active Directory Administrative Template, WMI Group Policy.zip,that can be used to configure the WMI port range through Active Directory. It's important to note that this Administrative Template can only be used with Windows 2008 and greater functional role level domains, though any machine joined to the domain, from Windows 2000, XP, through Windows 8 and Server 2012 will respect these policy settings.
Once extracted, copy the “WMI.ADMX” file to the “%systemroot%\PolicyDefinitions” directory on your domain controller. Then copy the “WMI.ADML” file to the “%systemroot%\PolicyDefinitions\en-US” directory. If you share your administrative templates across multiple domain controllers and would like these to be available to all DCs you can alternatively place WMI.ADMX in the “%systemroot%\sysvol\domain\policies\PolicyDefinitions” and the “WMI.ADML” in the “%systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US” directories.
Now that you've extracted the Administrative Template into the appropriate directories, you can utilize it in the same manner as any other group policy setting. From within the Group Policy Management Editor, either open an existing group policy that’s already applied to the devices you’d like this change applied to, or create a new group policy. Right Click on the Group Policy and click “Edit”.
Within the Group Policy Management Editor expand “Administrative Templates” – “Networking” – “RPC Static Pool” and double click on “RPC Static Pool Definition”.
Inside the RPC Static Pool Definition select the “Enabled” radio button to apply the following settings to the objects this group policy applies to.
“Use Internet Ports” = “Y”
“Ports Internet Available” = “Y”
“Define Internet ports for RPC below” = “5000-5100”
When done click “Apply”. This group policy change should take effect within 90 minutes for all nodes contained in the OU.
The last method for distributing these policy changes that I'll discuss in this blog post is creating your very own Group Policy setting. It's perhaps not as elegant or neatly packaged as the Administrative Template method above, but it does have the distinct advantage of working on older Windows 2003 Domain Controllers. Also, unlike Administrative Templates you can follow essentially the very same steps below on any Windows machine that's handy and define a local RPC port range for that workstation. This means you can play around using this method without needing to implement any changes on your Domain Controller. Once you're comfortable with these settings however, you can implement them via Group Policy in a similar manner to distribute them across your domain.
“RPC_Ports” = “Y”
“RPC_PortsInternetAvailable” = “Y”
“RPC_Ports” = “5000-5100”
Regardless of which method you choose, the end result is essentially the same. Instead of WMI using any random TCP port greater than 1024, it's now confined to a limited range of ports that both you and the security czar will unanimously agree strikes the perfect balance of safe and functional. The image below demonstrates this result in a packet capture. You can still see the initial request via TCP Port 135 then switch to TCP Port 5002. This is because there are already two other WMI connections to this host using TCP Port 5000 and 5001. The WMI port range recycles ports as connections are terminated or timeout; therefore, provided your port range is adequately sized, there should be no concern of port exhaustion.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process. Learn more today by joining now.