Windows
Power-Shell ?Windows PowerShell is Microsoft's task automation framework, consisting of a command-line shell and associated scripting language built on top of, and integrated with, the .NET Framework. PowerShell provides full access to COM and WMI, enabling administrators to perform administrative tasks on both local and remote Windows systems.
In PowerShell, administrative tasks are generally performed by cmdlets (pronounced command-lets), specialized .NET classes implementing a particular operation. Sets of cmdlets may be combined together in scripts, executables (which are standalone applications), or by instantiating regular .NET classes (or WMI/COM Objects). These work by accessing data in different data stores, like the file system or registry, which are made available to the PowerShell runtime via Windows PowerShell providers.
Windows PowerShell also provides a hosting mechanism with which the Windows PowerShell runtime can be embedded inside other applications. These applications then leverage Windows PowerShell functionality to implement certain operations, including those exposed via the graphical interface. This capability has been utilized by Microsoft Exchange Server 2007 to expose its management functionality as PowerShell cmdlets and providers and implement the graphical management tools as PowerShell hosts which invoke the necessary cmdlets. Other Microsoft applications including Microsoft SQL Server 2008 also expose their management interface via PowerShell cmdlets. With PowerShell, graphical interface-based management applications on Windows are layered on top of Windows PowerShell. In the future all Microsoft applications running on the Windows platform are to be PowerShell aware.
Windows PowerShell includes its own extensive, console-based help, similar to man pages in Unix shells via the Get-Help cmdlet.
PowerShell Default Security
Just getting to the PowerShell interface can be a task for some. Not that this is security related, just that you must be in the PowerShell interface before you can do much of anything. This in itself is security. There are however, some default security measures that are there by design to help ensure that anyone with malicious intent is denied their efforts.
What is in a path?
The first default security measure that you will encounter is that fact that PowerShell won’t run scripts that are in the current folder. This is so that malicious scripts attempting to intercept cmdlets and command names will fail.
For example, if you wanted to run a script named Example.ps1 from the C:\scripts folder, you would need to include the full path to the script, even if you were in the C:\scripts folder within PowerShell. Figure 1 illustrates what happens when you just try to run Example.ps1 without a path.
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:
Restricted
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.
All Signed
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.
Remote Signed
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.
Unrestricted
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.
Summary
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
