Portocalypse - WMI Demystified

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.

WMI Protocol Security

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.

Restricting WMI Port Usage

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.

Prerequisites

• Consider your port range carefully before proceeding to ensure there are no conflicts with ports already in use by critical business applications in your environment. For instance, if you plan to use ports 5000-5100 as provided in these examples, you might not realize that some of these ports overlap with other applications such as FileMaker Pro. While this shouldn't be a major issue, it will reduce the total number of ports available to WMI for concurrent connections. This however does become vitally important to pay close attention to if you have plans to reduce the WMI port range to only a handful of ports. It's probably worth spending a little time determining which ports are being used in your environment by monitoring your network traffic using something like our NetFlow Traffic Analyzer. Similarly, you could use the Network Configuration Manager to report on all open ports that your Windows hosts are listening on.

• Group policy can take as long as 90 minutes to update a clients configuration. If you plan to use method #2, or implement method #3 below via group policy, it's important to remain patient. You can always verify a clients configuration using Regedit and validating the contents of the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet key. If you have easy access to the machines receiving their configuration settings via group policy, you can also force a policy refresh by opening a command prompt on the host and running the "gpupdate /force" command.

• These changes require rebooting the remote host before they take effect. In the case of workstations, you may be able to rely on your users to shutdown their machines at the end of the day and turn them back on when they return. For servers, you will more than likely have to wait for a maintenance window, such as Patch Tuesday before you're allowed to reboot and these changes take effect.

• Neither SAM nor Patch Manager require WMI. It's a powerful, but completely optional component to both products. In the case of SAM, there are SNMP and RPC alternatives for almost every instance where WMI is available. Patch Manager includes optional WMI Providers that allow for the immediate deployment of patches to end hosts, eliminating the need to wait for a regularly scheduled phone home event from the client to check for new updates. Regularly scheduled patch deployments however, have no reliance on WMI.

• WMI Ports are opened (listening) only as needed, based on an initial request sent via TCP 135. So while the examples below demonstrate allocating a range of 100 ports to WMI, a port will only be opened for use once the connection has been properly authorized and authenticated during that initial RPC request.

• Be sure you've made provisions for allowing TCP Port 135, as well as, the range of ports you've chosen to allocate to WMI to the Windows Firewall exclusion list. For added security, you can optionally limit this exclusion to the source IP address of your SAM or Patch Manager server.

Method 1 - Modify The Registry Directly

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.

• Add the Internet key under:  HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc
• Under the Internet key, add the values "Ports" (MULTI_SZ), "PortsInternetAvailable" (REG_SZ), and "UseInternetPorts" (REG_SZ).

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

• Restart the server. All applications that use RPC dynamic port allocation use ports 5000 through 5100, inclusive. In most environments, a minimum of 100 ports should be opened, because several system services rely on these RPC ports to communicate with each other.

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.

Method 2 - Active Directory Group Policy Administrative Template

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.

Method 3 - Create Your Own Group Policy Setting

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.

• Before we begin you'll first want to make a backup copy of the "sceregvl.inf" file located in "C:\WINDOWS\INF". This will allow you to quickly and easily revert any changes made should you need to for any reason.
• Next, you'll need to take ownership of the "sceregvl.inf" file by right clicking on the file, selecting "Properties", then selecting the "Security" tab and clicking "Advanced". Inside the "Advanced Security Settings", select the "Owner" tab click the "Edit" button to select your Domain "Administrators" group, for which you should already be a member. Lastly, click "Apply" and "OK" to save these settings.
• While still inside the security properties of the file we need to ensure the Domain Administrators group has all the necessary permissions required to modify the file. To do so, select your Domain Administrators group from the list of "Group or user names" and select both "Allow" check boxes next to "Modify" and "Write" under "Permissions for Administrators" as pictured below.

• Now that security permissions have been properly modified, it's time to get down to business. Start with launching Notepad as the Administrator by holding down the "Control" key on your keyboard while right clicking on Notepad and selecting "Run as administrator". Once launched, open "C:\WINDOWS\INF\sceregvl.inf" from within Notepad using the "File" menu.

• Next we'll need to add a few lines to the top section of the "sceregvl.inf"configuration file, just above the other registry keys as pictured below. These configuration settings can be copied as written here, then pasted directly into the "sceregvl.inf" configuration file. Once completed don't forget to save the file.

MACHINE\SOFTWARE\Microsoft\Rpc\Internet\Ports,7,RPC_Ports,4

MACHINE\SOFTWARE\Microsoft\Rpc\Internet\PortsInternetAvailable,1,RPC_PortsInternetAvailable,2

MACHINE\SOFTWARE\Microsoft\Rpc\Internet\UseInternetPorts,1,RPC_UseInternetPorts,2    

• Before we can start playing with our new policy settings we first need to re-register the "scecli.dll" with Windows. To do this, you'll first need to open a command prompt window as Administrator in the same manner we launched Notepad in the previous step. Right click on the "Command Prompt" while holding down the "Control" key and select "Run as administrator". Then run the command "regsvr32 scecli.dll' to re-register "scecli.dll". When executed, you should receive confirmation that the DLL was successfully registered.

• Similar to the Administrative Template method above you can now configure these settings in the same manner as any other group policy. From within the Group Policy Management Editor, either open an existing group policy to an organizational unit that already contains 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 “Windows Settings” – “Security Settings” - "Local Policies"  and select "Security Options". There you will find these new configuration options which can be defined using the following suggested settings.

“RPC_Ports” = “Y”

“RPC_PortsInternetAvailable” = “Y”

“RPC_Ports” = “5000-5100”

Show me the Money

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.