![]() |
|
||||
|
|
Securing PowerShell: Code Signing Made SimpleDecember 17, 2008
By Richard Siddaway
Security must be at the top of every administrators list. Security and usability can pull you in opposite directions. Automation by PowerShell, or any other scripting tool, is a definite move to the ease-of-use side of the balance. How can we keep our automation and make sure that we are secure? PowerShell has a number of designed-in security features including:
We will look at some other techniques for keeping our scripts secure and finish off by looking at script signing. Script SecurityWe need to keep our scripts secure for two reasons. One, we don't want anyone running them that shouldn't. No telling what damage could be done by someone running your admin scripts "just to see what happened." Secondly we don't want anyone getting access to the scripts and altering them. That could be even nastier! So how do we keep our scripts secure? How many people need access to the scripts? Restrict access to only the administrators that need them. Use NTFS permissions to secure the scripts. Put the scripts on an administration machine rather than a file server to which everyone has access. Severely restrict the number of people who can modify scripts. In many organizations there is often only one person creating or modifying scripts. This is usually because they are the only one interested or the only one with the skills. Consider using PowerGUI for running scripts. It can provide a friendly front end enabling administrators to run scripts that cannot necessarily develop scripts. The maximum security for scripts is created by using the AllSigned execution policy and digitally signing your scripts. At this point in talks when I mention this a lot of people go pale at the thought. Script signing is not a scary subject as we will see. Script SigningPowerShell is most secure when used with the AllSigned execution policy. This requires that all scripts are digitally signed using a code signing certificate from a trusted Certificate Authority. Digitally signing a script identifies the source of the script or at least who signed it. If your execution policy is set to Allsigned and a signed script is changed it will not be allowed to be executed until it is resigned. Code signing certificates can be supplied by one of the commercial Certificate Authorities for a fee or a "self-signed" certificate for which your computer is the Certificate Authority. At this point you may think that this is too hard. Believe me, it's not. NOTE Create certificateWe can create a "self-signed" certificate using the makecert.exe utility. The bad news is that it is not part of Windows or PowerShell. You need to download and install the Windows SDK from the Microsoft web site. Alternatively, makecert is available if you have Visual Studio installed. Once makecert is installed we can create a certificate root and then make the code signing certificate. We create the root using this syntax.
It is not quite as bad as it looks, as the following table explains. Table 1 - Syntax explanation for creating a certificate root
Our syntax can be read as make a "self-signed" certificate root called "PowerShell Local CertificateRoot" using the Sha1 algorithm and an Object Identifier of 1.3.6.1.5.5.7.3.3. The pvk file is called root and is stored in the Root certificate store on the local machine. Easy. Full syntax details of makecert can be found by using makecert /? for the basic options and makecert /? for the advanced options. The next stage is to run this code
This is explained in table 2. Table 2 - Syntax explanation for creating a certificate
Working with PowerShell we have an advantage. We can look directly into the certificate store. The following code will show us the relevant information about the certificate. Listing 1 - Viewing code signing certificate
Having created our certificate we should secure it. We don't want the bad guys getting access to it, automatically signing scripts and doing nasty things to your machine now do we? Page 2: Secure Certificate
|
|