• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 82
  • Last Modified:

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.
0
FCOA
Asked:
FCOA
  • 8
  • 4
1 Solution
 
McKnifeCommented:
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.
0
 
FCOASystems AdminAuthor Commented:
Yes, these are dynamic ports, so that change wouldn't hold.
0
 
McKnifeCommented:
So you will need o allow all high ports.
0
Simple Misconfiguration =Network Vulnerability

In this technical webinar, AlgoSec will present several examples of common misconfigurations; including a basic device change, business application connectivity changes, and data center migrations. Learn best practices to protect your business from attack.

 
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.
0
 
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?

STATUS UPDATE:
The steps on this docs.microsoft.com article did not resolve the issue.
0
 
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.
0
 
McKnifeCommented:
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.
0
 
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.

SOURCE: https://docs.microsoft.com/en-us/windows/security/identity-protection/windows-firewall/checklist-creating-outbound-firewall-rules
0
 
McKnifeCommented:
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?"
https://technet.microsoft.com/en-us/library/2008.06.security.aspx
Old, but worth reading and stilll applying.
0
 
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.
0
 
FCOASystems AdminAuthor Commented:
IMPORTANT UPDATE:
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".
0
 
FCOASystems AdminAuthor Commented:
No other relevant suggestions made.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

  • 8
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now