Win2016 outbound firewall for Get-WmiObject

Need help determining the OUTBOUND Windows firewall rule(s) necessary to allow the following command to be run FROM a Win2016 server. The issue goes away if the Windows firewall is set to "Allow" all OUTBOUND connections.

Get-WmiObject -ComputerName $RemoteComputer -namespace "ROOT\Cimv2" -Class Win32_ComputerSystem

Open in new window

When the outbound firewall is enabled, the result of this command is a "No such interface supported" error, and the firewall log shows "DROP TCP x.x.x.x y.y.y.y 50011 49154 0 - 0 0 0 - - - SEND". The "Windows Management Instrumentation (WMI-Out)" is enabled with it's default settings and being respected, as it's visible in the "Monitoring" rules. I've also pretty much tried all available predefined outbound rules with no success.
FCOASystems AdminAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Why not unblock the port 50011 (or is it 49154)? That will be high ports being used for that and those might vary each time, but still worth a try - that's what the firewall log is good for.
Why you would disallow outgoing traffic at all is questionable. Microsoft themselves don't do it by defaut since they see no security implications.
FCOASystems AdminAuthor Commented:
Yes, these are dynamic ports, so that change wouldn't hold.
So you will need o allow all high ports.
The Five Tenets of the Most Secure Backup

Data loss can hit a business in any number of ways. In reality, companies should expect to lose data at some point. The challenge is having a plan to recover from such an event.

FCOASystems AdminAuthor Commented:
Thanks, but that would sort of defeat the purpose of using the firewall. I'm looking for the specific rule(s) that would permit this.

I believe the rule in question will be tied to a specific service (and/or exe) that then permits traffic on "any" port, similar to how the predefined "Windows Management Instrumentation (WMI-Out)" rule, and rules like it, are configured. I've been surprised that I haven't found a predefined rules to do the job.

Thanks again for brainstorming with me.
FCOASystems AdminAuthor Commented:
Since the service or EXE info isn't included in the firewall log, anyone have any suggestions on how one might track this down?

The steps on this article did not resolve the issue.
FCOASystems AdminAuthor Commented:
RESOLVED!  I sorted it. PowerShell.exe needed to be excluded.  

After ruling out all services by setting the rule to "Apply to services only" --rather than "Apply to all programs and services"-- that eliminated services from consideration and had me focus on EXE's instead. PowerShell was naturally the first to come to mind.  

To address the matter via OUTBOUND rule:

1. Right-click Outbound Rules, and then click New Rule.
2. On the Rule Type page, click Custom, and then click Next.
3. On the Program page, select This program path, and then type %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe. There are no services to customize in this case so click Next.
4. On the Protocol and Ports page, change Protocol type to TCP, and then click Next.
5. On the Scope page, click Next.
6. On the Action page, select Allow the connection, and then click Next.
7. On the Profile page, clear the Private and Public check boxes, and then click Next.
8. On the Name page, type PowerShell , and then click Finish.

If you also use the x86 version or PowerShell ISE, you will need to exclude these files as well. Windows Server 2016 (build 1607) does not support partial paths or wildcards in firewall rules.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Is that your solution?
Excluding powershell will exclude any powershell script, malicious or not.

But honestly, it won't get much better and as I said, even microsoft does by defaut allow all outgoing traffic, so they don't see a security problem.
FCOASystems AdminAuthor Commented:
I'd say it's a substantially more restrictive solution then your suggestion, so I'm not sure why the snark is needed. Nor is your opinions on our security decisions necessary.

FWIW, here's Microsoft's statement on the topic:
By default, outbound filtering is disabled... However, it is a best practice for an administrator to create outbound allow rules for those applications that are approved for use on the organization’s network.

Sorry, what snark? No, not at all, I would have recommended the same, but I was pretty sure that you wouldn't want that.
And, although dated 2008, please read what MS has to say about "How Much Security Can Outbound Filtering Provide?"
Old, but worth reading and stilll applying.
FCOASystems AdminAuthor Commented:
Thanks for the read. Good stuff.

This gives me a good reason to also force the firewall enabled and force traffic blocks via GPO. We're already doing both these things on workstations, and we also force the force the firewall enabled on servers, but have thus far left the servers open to allow admins to stop blocking in or out traffic for troubleshooting purposes. While this will make it a tad more cumbersome for troubleshooting purposes (i.e. a GPO change will be required to allow traffic), it should help reduce risks further.

PS- We also have a custom script via Scheduled Task that will send IT Admins email alerts if a firewall is not set as expected. This was mostly for as a reminder for admins, in the event the failed to return the firewall back to blocking.
FCOASystems AdminAuthor Commented:
In conjunction with the rule mentioned in comment a42492885 above, it appear a rule to "%SystemRoot%\system32\svchost.exe" on Remote Port TCP 135 is also required for the outbound remote command in question.

I wasn't able to further reduce this rule to a specific service. In fact, failures still occurred when the rule was set to anything other than "Apply to all programs and services".
FCOASystems AdminAuthor Commented:
No other relevant suggestions made.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Software Firewalls

From novice to tech pro — start learning today.