Protect Your PowerShell Scripts

When running scripts in Windows PowerShell, an important security consideration that you should take into account is how to prevent unauthorized scripts from running on your system. By default, you can't run scripts in PowerShell. However, scripts provide an effective tool in Windows administration, so if you're using PowerShell, chances are you'll want to run scripts.

A PowerShell script is simply a text file with a .ps1 extension. The file contains one or more PowerShell statements that run when you call the script file at the console. PowerShell lets you control whether scripts can run, and if so, which scripts can run. To control script execution and help to protect your system, you need to

1. Set PowerShell's execution policy.
2. Create an X.509 certificate.
Digitally sign your scripts.

By taking these precautions, only the scripts that you digitally sign will be permitted to run in PowerShell, thus helping to prevent malicious attacks on your system. Note that I assume you're already familiar with the PowerShell environment. If you're new to PowerShell, see the PowerShell 101 and PowerShell 201 series. For information about these series, go to "New to Scripting? Check Out These Series".

Setting the Execution Policy
The PowerShell execution policy controls whether you can run scripts and whether configuration files will be loaded when you start PowerShell. To set the execution policy, you must use the Set-ExecutionPolicy cmdlet to specify one of the following execution options:

• Restricted: PowerShell configuration files won't be loaded and scripts won't run. This is the most restrictive option and is the default. As a result, when you first install PowerShell, no unintended scripts will run or configurations will load. However, you can still run individual commands in the PowerShell console.
• AllSigned: All scripts and configuration files must be digitally signed by a trusted publisher. To sign a script, you must use a code-signing certificate. As you'll see later, you can create the certificate yourself.
• RemoteSigned: All scripts and configuration files downloaded from the Internet must be digitally signed. However, scripts on your local computer can run and local configuration files can be loaded without being digitally signed.
• Unrestricted: All scripts will run and all configuration files will be loaded. This is the least restrictive option and subsequently the riskiest.

As you can see, if you want to protect your system and still allow scripts to run and configuration files to load, you should set the execution policy to AllSigned. To set the policy, run the following command at the PowerShell command prompt:

Set-ExecutionPolicy AllSigned

You can verify PowerShell's current execution policy (always a good idea after changing the policy) by running the Get-ExecutionPolicy cmdlet (without any parameters). For more details about the Set-ExecutionPolicy and Get-ExecutionPolicy cmdlets, see the PowerShell Help files available for each cmdlet. For information about configuration (i.e., profile) files, see "Save Your PowerShell Code in Profile and Script Files" and the MSDN article "Windows PowerShell Profiles".

Creating an X.509 Certificate
After you set the execution policy to AllSigned, you must sign your files, which means you need a code-signing X.509 certificate. X.509 is a cryptography standard that defines the format for such security-related devices as public key certificates and certificate revocations lists. You can either purchase an X.509 certificate issued by a public certificate authority or you can create your own certificate authority and certificate. A full discussion of the X.509 standard and public certificate authorities is beyond the scope of this article. However, I'll explain how you can create your own local certificate authority and certificate.

To create a certificate authority and certificate on the local computer, you can use the Makecert utility that's included in the Microsoft .NET Framework SDK. (It's also available in Microsoft Visual Studio 2008 or Visual Studio 2005.) Note, however, that Makecert is meant for testing only. In a production environment, you should use a public key infrastructure (PKI) such as Microsoft Certificate Services to create certificate authorities and certificates.