June 23, 2015 at 7:24 am #26743
I have a module with a single user defined function inside of it. This is located locally on a remote server I am using to test. I have created an endpoint configuration file and registered the configuration. I have also specified to allow the module I created.
My question is related to how to lock it down as securely as possible while still being able to execute the user defined function within the module.
The function is pretty simple and uses: New-Item, New-SMBShare, CMD.exe (for icacls and dfsutil) and New-DFSNFolder.
If I understand this correctly it would be better to run the Endpoint with a -SessionType of something like RestrictedRemoteServer and set the -LanguageMode to NoLanguage(or Constrained or Restricted). However when I set these values to anything other than totally unrestricted I am no longer able to run my function remotely.
Any guidance is appreciated.
June 23, 2015 at 9:55 am #26760
Define "as secure as possible." The maximum security would be to shut the remote server off completely and disconnect it from the network. That's extremely secure.
What capabilities, specifically, do you want someone to have and not have? What is it, specifically, that you want to work, but isn't working?
For example, your endpoint configuration doesn't "allow" the module you created. There's no place for it to do that. Do you have it importing your custom module by default? It should also be using -VisibleFunctions to make sure your custom function is visible in the endpoint.
June 23, 2015 at 10:47 am #26763
Thanks for the feedback Don. Sorry if I was a little vague.
When I create the PSSessionConfiguration I specify -ModulestoImport to allow the custom module that I have created. If I use -SessionType default then I am able to execute the function within that module successfully from a remote PSSession.
If I specify -SessionType RestrictedRemoteServer when creating the PSSessionConfiguration then I am still able to execute the function within the module I have imported but it blows up utilizing cmd.exe and (I think) a script block.
The help on the -VisibleCmdlets param says: "By default, all cmdlets that modules in the session export are visible in the session. Use the SessionType and ModulesToImport
parameters to determine which modules and snap-ins are imported into the session." So from that I get the impression that I do not have to explicitly allow each function within a module that was loaded via -ModulestoImport. Or am I wrong there? Does it mean that native PS cmdlets are visible, but user defined functions are not?
I'm a neophyte here but I THINK the question I am asking is:
How do I achieve a reasonably high level of security while still being able to execute UDFs from within modules I am explicitly loading via custom endpoint configurations.
June 23, 2015 at 10:53 am #26764
I can post the function if you think that will help.
June 23, 2015 at 11:08 am #26765
So, we can't really discuss "reasonably high level of security" because what's "reasonable" to you might be hilarious to me. What is it you're trying to secure? What don't you want people doing?
June 23, 2015 at 11:35 am #26767
Great point. Secure is very subjective. To be clear I'm not trying to secure state secrets. I'm trying to figure out how to incorporate endpoints in way that makes sense for a fairly standard SMB infrastructure of about 80 heterogeneous servers.
In the scenario I would like to protect against I'm assuming AD credentials for the users who have permissions to access these endpoints have been compromised. I would like to secure the endpoints to the extent that a malicious entity could not wreak havoc by importing potentially dangerous modules and commands into the session and execute them.
June 23, 2015 at 11:46 am #26768
Well, two things.
One, you're *probably* OK leaving the endpoint fairly "open," and only *making visible* the commands you need someone to use. If that list of commands doesn't include Import-Module, then it'll be limited to just the commands you've specified.
Second, if the AD credentials are compromised, you're utterly screwed, and this endpoint isn't going to be how someone attacks you. Once I have someone's AD credentials, there are far more convenient ways to mess with you. Endpoints are *not* a secondary security barrier; they're a mechanism for delegating units of administration.
If you have a malicious entity on your network, then THAT is your problem. Constrained endpoints aren't designed as a protection against that scenario. You've got plenty of other mechanisms that should be protecting against intruders.
June 24, 2015 at 6:34 am #26779
Okay, that was really helpful information.
I was under the impression that constrained endpoint configurations WERE mechanisms to harden infrastructure security. Knowing that they are meant primarily for delegation makes more sense. And what you're saying about compromised AD credentials puts that into perspective.
If I may add, I really appreciate everything this community does as well as how you contribute Don. I've watched your CBT Nuggets videos, been through Powershell in a month of lunches and preach Powershell around the workplace. It really has changed how I view and approach administration. Thanks again.
You must be logged in to reply to this topic.