Dear security experts, PowerShell is not a vulnerability, in fact its your friend in keeping environments secure. I know it can be scary cause PowerShell is pretty damn powerful, but disabling remote PowerShell is not the answer.
Whats this all about? In December I received an email about changes to an environment I help manage. The email contained this sentence: “new rules are going to be applied to limit the ability for any window server from being able to use remote powershell to other window servers”
*Record scratch* Say what? In this environment we have 3 Hyper-V clusters. We have all of System Center deployed. We also make heavy use of PowerShell with our Orchestrator server to do everything from provision new servers to checking service account password expiration. You can imagine my terror after reading this. It would essentially break our entire environment.
Now that you’re caught up, I’ll go over why this is a terrible idea, like I did in my emailed response back to this person.
PowerShell Remoting
Lets talk about the main crux of their complaint, PowerShell Remoting. To execute remote PowerShell against a computer you need to be a member of the local administrators group on that server. So that’s one real quick way to limit who has access to execute remote PowerShell. Beyond that, traffic is encrypted from end to end. Even when using HTTP, credentials are not transmitted over the network. While executing remote PowerShell, credentials are never stored in any persistent storage. That said, there is a big, big problem with turning off PowerShell Remoting and I’ll let Don Jones explain from his post here:
“As of Windows Server 2012, PowerShell Remoting is enabled by default and is mandatory for server management. Even when running a graphical management console locally on a server, the console still “goes out” and “back in” via Remoting to accomplish its tasks. Without Remoting, server administration is impossible. Organizations are therefore well-advised to start immediately finding a way to include Remoting in their permitted protocols. Otherwise, critical services will not be able to be managed, even through Remote Desktop or directly on the server console.
This approach actually helps better secure the data center. Because local administration is exactly the same as remote administration (via Remoting), there’s no longer any reason to physically or remotely access server consoles. The consoles can thus remain more locked down and secured, and Administrators can stay out of the data center entirely.”
So, reading into that, even using consoles like Hyper-V or Failover Cluster manager on the local host itself still require PowerShell remoting to work correctly.
Summary of PowerShell Remoting:
- One Port 5985 or 5986
- encrypted by default
- Requires Admin rights
- Turning off will break your environment
PowerShell Security
There’s a whole lot of good you can do for PowerShell Security, I’ll quote Ashley McGlone PFE at MS.
https://blogs.technet.microsoft.com/ashleymcglone/2016/06/29/whos-afraid-of-powershell-security/
“The improvements in WMF 5.0 (or WMF 4.0 with KB3000850) make PowerShell the worst tool of choice for a hacker when you enable script block logging and system-wide transcription. Hackers will leave fingerprints everywhere, unlike popular CMD utilities. For this reason, PowerShell should be the only tool you allow for remote administration. These features allow you to answer the classic questions who, what, when, where, and how for activities on your servers.”
If you do nothing else, upgrade all versions of PowerShell to the latest release. But several of the blogs I link to have a lot more recommendations for securing PowerShell. Even further than it already is.
So did my response correct their thinking? Not yet. We had a follow up call in early January. In which one of the key stakeholders hadn’t even seen my email. Multiple people disputed my claims of PowerShell Remoting being on by default. The next steps were to continue to talk about it.
Further reading, these are all the blogs and articles I found when researching this. In addition to the posts already linked to.
https://blogs.msdn.microsoft.com/powershell/2015/06/09/powershell-the-blue-team/
https://dbatools.io/secure/ – credit the Featured Image used on this blog to DBATools.io
https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/winrmsecurity?view=powershell-6