Powershell and security

[#1]

We are looking at the powershell toolkit and I already had quite some fun playing around with it.

Typically I don't like security based on a userID/password combination as it can be misused easily from any location in the network. For ssh there is a simple way around that by setting the option ssh.access and build aditional security layers around the hosts specified. Does something exist for the Powershell toolkit as well? Can we limit powershell access either directly or indirectly (e.g. limiting powershell to be used via http in combination with the http.admin.access option)?

(I know we have issues with security around cifs, Ijust want to know if I can plug this hole)

thanks for any good ideas

maarten

[#2]

By default if you don't specify credentials to the Connect-NaController cmdlet, it will use RPC communications and your current Windows security token for authentication (without any password needed).  Domain administrators should already have full control of the storage controller, for other domain users you can add them to an appropriate group (such as the built-in "Administrators" group) on the storage controller.

[#3]

Can you help me understand your question?

Are you asking us to restrict the ability of Administrators?  or simply bad actors who attempt to hack the windows box?

If you choose not to store credentials locally on the windows host, then bad actors who gain access to your windows host will not be able to take control of the NetApp controller.

If you are running RPC and the bad actor gains control of an authorized windows account then you are compromised.  This is true no matter what your front end.  This will work for System Manager, PS toolkit or anything else.

Or are you asking about restricting stored credentials on the Windows host?

Alex

[#4]

I guess my problem is I don't like security based on userID/password as it is a rather weak authentication mechanism. It is good to see I can limit some of the access here by the same mechanism I am limiting the ssh/http access. To me it is unfortunate that I don't see a way someone can be stopped using powershell via RPC. It would be easy if I could specify something like certain functionality (rights, groups) only being available from certain systems or on certain interfaces.

By default I am taking away all capabilities from the local administrators group (to limit the access of domain admins managing the files on the shares), but there will always be a group that has all capabilities on a filer. The risk is that if someone obtains a userID in there and knows the password they can still use tools like the Powershell toolkit.

I am aware this is more of an Ontap restriction than Powershell but I hoped someone using the Powershell Toolkit had found a workable solution for this.

Thanks for the answers anyway. Much appreciated

maarten

[#5]

Hi Alex,

That's not entirely accurate, I can see where he's coming from. In our environment in order to get to the management interfaces you need to pass through dual-factor authentication. So getting control of a privileged user account and password is not a complete compromise in our security model (imagining that the PS toolkit didn't exist). However now that we have the PS Toolkit (which is awesome by the way) that is no longer the case, you can't secure it with dual-factor authentication for management to my knowledge. So depending on how you're setup his point is valid, I too would like to be able to shutoff the ability to manage the device through PS by restricting it to a VLAN or Host.

-Philip

[#6]

That's a good point Philip.  In those sorts of environments, it's really important to think about securing your storage system rather than the toolkit.  As Alex pointed out, the PowerShell Toolkit doesn't expose any new storage access (although it certainly does make it easier/simpler).  Instead you need to look at securing your storage management network just like you would secure the actual data network.  VLANs may be a good choice to restrict access to the Data ONTAP management functions to only those Windows clients where you are guaranteed either secure physical or two-factor access. 

Here are a couple good places to start:

• Data ONTAP Network Management Guide
• TR-3649 - Best Practices for Secure Configuration of Data ONTAP 7G

I hope that helps!

[#7]

Hi,

For secure connection into PowerShell script I use the following procedure:

1. I run the following commands manually :

# $PASSWORD="password"

# $KEY=ConvertTo-SecureString "$PASSWORD" -AsPlainText -Force | ConvertFrom-SecureString

#$KEY=01000000d08c9ddf0115d1118c7a00c04fc297eb010000001df078edba0b8644a18c9c7a0921f1e00000000002000000000003660000c000000010000000664e1f7379031a569622b57d4b044f200000000004800000a0000000100000007528676d35e19049608e5bf2026d2f3d1800000038ef3efcefe8ac0119b4bc1070f41cb1bd680ba14e557a9f140000008a916156eb775211d68e4c9ba32aa07d64bcf9ad

2. After that i insert the KEY varibale into my script:

$USER="root"

$KEY="01000000d08c9ddf0115d1118c7a00c04fc297eb010000001df078edba0b8644a18c9c7a0921f1e00000000002000000000003660000c000000010000000664e1f7379031a569622b57d4b044f200000000004800000a0000000100000007528676d35e19049608e5bf2026d2f3d1800000038ef3efcefe8ac0119b4bc1070f41cb1bd680ba14e557a9f140000008a916156eb775211d68e4c9ba32aa07d64bcf9ad"

$SECUREPASSWORD = "$KEY" | ConvertTo-SecureString

$IP_CONTROLER = "192.168.0.10"

#

# Secure Connexion to Controller

#

$CREDENTIAL=New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "$USER",$SECUREPASSWORD

Connect-NaController -credential $CREDENTIAL $IP_CONTROLER | out-null

[#8]

Why not simply use the Toolkit's built in credential store? 

Add-NaCredential -Controller 192.168.0.10

Once the credentials are stored you simply connect, and the toolkit will retrieve the credentials from the store.

As for the use of usernames and passwords.  That's more of a philisophical question, personally I don't find keys any more secure than passwords.  As has already been mentoned a defence in depth with several different layers, using different types of authentication is required to secure any enviornment.  The tool used is far less important than the connection itself.

[#9]

Keys in itself do not solve the issue, agreed. But passwords are fairly weak; when someone has got hold of my password I wouldn't notice. That is why we prefer to work with physical tokens containing keys. (Loosing a physical item you need in everyday's life will be noticed)

As to the original question I posed I am considering to solve it in the following way (the layered approach indeed):

• all data sits in vfilers.
• The filers themselves (vfiler0) will not be using cifs.
• By using https I plan to limit the amount of systems that can use Powershell on these controllers to the ones I choose.
• Logging in to these Powershell systems will then be secured by a stronger authentication mechanism

Now back to testing whether this works and does not break anything in our landscape.

Thanks all for the thoughts and ideas

maarten