Figure 1: Scripts must include the path to the script to run successfully
Now, look at what happens when you run the script including the path to the script, as shown in Figure 2.
Figure 2: When the path is included with the script, the script runs without a hitch
Why am I Restricted?
Another default setting that is directly related to security is the fact that all scripts must be run interactively. This is a security measure that ensures that PowerShell scripts cannot be executed from a script based virus. This means that you must be at the PowerShell interface and run the script in real time for it to function.
This default setting is associated with the ExecutionPolicy setting within PowerShell. The ExecutionPolicy by default is set to Restricted, as shown in Figure 3.
Figure 3: The ExecutionPolicy by default is set to Restricted to secure the execution of remote PowerShell scripts
Going Beyond The Defaults :
The default ExecutionPolicy in PowerShell is very secure. It does not allow for any scripts to be run, from anywhere. So, scripts that you create and put on a system won’t run. Scripts that you download from the Internet won’t run. Scripts that you even sign and secure to the nth degree won’t run. Therefore, you will need to reset the level of ExecutionPolicy before you can run your scripts.
Setting the ExecutionPolicy Level
There are four levels of the ExecutionPolicy. These four levels provide you with great security over what scripts can run and what requirements need to be associated with the script to run. The four levels and the requirements include:
This is the default configuration in PowerShell. This setting means that no script can run, regardless of its signature. The only thing that can be run in PowerShell with this setting are individual commands.
This setting does allow scripts to run in PowerShell. The script must have an associated digital signature from a trusted publisher. There will be a prompt before you run the scripts from trusted publishers. This exposes you to running signed, but malicious, scripts.
This setting allows scripts to be run, but requires that the script and configuration files that are downloaded from the Internet have an associated digital signature from a trusted publisher. Scripts run from local computer don’t need to be signed. There are no prompts before running the script. Still exposes you to scripts that are signed, yet malicious.
This is not a suggested setting! This allows unsigned scripts to run, including all scripts and configuration files downloaded from the Internet. This will include files from Outlook and Messenger. The risk here is running scripts without any signature or security.
To set anyone of these levels, just type set-executionpolicy <level>, as shown in Figure 4.
Figure 4: Setting the ExecutionPolicy is as easy as running the set-executionpolicy command.
Using Group Policy
PowerShell is great, but if scripts can’t run on computers in your environment, it does have limitations. First, you must get PowerShell on each computer. Since PowerShell is installed via an EXE, it is very easy to install the application. You can either use a ZAP file and push it out using Group Policy, or you can use your current centralized method of installing applications. Keep in mind that PowerShell is considered a hotfix, so Windows Update can also push out the installation of PowerShell.
After you get PowerShell installed, we just investigated that you need to enable scripts to run. With the ExecutionPolicy set at Restricted as a default, you need to configure every computer to run scripts, that will run scripts. This could take days if you are trying to do this manually.
However, you can also use Group Policy to get this done for you. Of course, you could create your own Administrative Template (ADM file) to make this change, or download the ADM template that Microsoft provides for you. I suggest you do the latter by downloading the ADM template.
After downloading, you will need to install the MSI. I will admit, it is not the cleanest or most efficient install. After installation, the ADM file is shoved under the C:\program files\Microsoft Group Policy folder. If nothing else, this is great security! The file you need to import into the Group Policy Object Editor is PowerShellExtensionPolicy.ADM. After importing, you will have two new nodes in your Group Policy Object. One will be at Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell and the other at User Configuration\Administrative Templates\Windows Components\Windows PowerShell, as shown in Figure 5.
Figure 5: PowerShell ADM template adds settings to Computer Configuration and User Configuration for script execution
When you go to configure this policy, you will see that you have three options for a setting, as shown in Figure 6.
PowerShell is the new kid on the block. With Windows Server 2008 coming out in early 2008, PowerShell will take off like a rocket ship. With all of the attention that PowerShell is getting, everyone is hoping that it comes with security already built-in. Well, the worry is over. PowerShell provides security directly out of the box, with default security features. The fact that the scripts are set to have a restricted execution policy is fantastic. Even if you have created a .PS1 file, that script being associated with Notepad is nice default security. Even if you can get to the PowerShell interface, the fact that the path to the script must be typed in adds value. Beyond the defaults, being able to set the execution policy and control PowerShell through Group Policy gives centralized control over PowerShell security.
Please Leave Your Comments