Sure! AppLocker can block specific classes of files. The 4 classes it can currently block are Executables, Windows Installers, Scripts and Packages Apps (i.e. Metro apps).
In our environment, "Script rules" is configured to be enforced/activated. Then, the default rules were applied, which whitelists all scripts in the Program Files and Windows folders. We also then whitelist specific server paths (and all of its subfolders) where we host scripts for various purposes (the Netlogon folder is one of these paths). These paths are restricted so that users only have Read access to these locations and only admins can write to these folders. IT staff (includes developers) also have a special local folder that has been whitelisted where they can test and run PoSh scripts. With this approach, if anyone attempts to run any PoSh scripts in any other location, it will be denied. We currently only enforce this protection on workstations, but at some point in the future, I may look into applying this to servers too (not a priority right now). Please let me know if you have any other questions and I'll be happy to answer them. -Aakash Shah From: [email protected] [mailto:[email protected]] On Behalf Of Trevor Sullivan Sent: Wednesday, November 6, 2013 12:40 PM To: [email protected] Subject: RE: [powershell] Argument in favor of a non-unrestricted Execution Policy? Aakash, Could you provide some more detail about how you've configured the AppLocker rules to restrict the locations where PowerShell scripts can be executed from? I'd love the feedback. Cheers, Trevor Sullivan From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Aakash Shah Sent: Wednesday, November 6, 2013 1:16 PM To: [email protected]<mailto:[email protected]> Subject: RE: [powershell] Argument in favor of a non-unrestricted Execution Policy? We also set the execution policy to unrestricted. However, to add protection like the seatbelt analog Michael gave, we combine it with AppLocker. With AppLocker, PoSh scripts can only run from trusted locations from user workstations (admins have additional locations where they can develop and run scripts from too). This has worked well for us so far. -Aakash Shah From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Trevor Sullivan Sent: Wednesday, November 6, 2013 10:20 AM To: [email protected]<mailto:[email protected]> Subject: RE: [powershell] Argument in favor of a non-unrestricted Execution Policy? Michael, How does the PowerShell script execution policy act as a seatbelt? All someone has to do, to run a PowerShell script, is bypass the execution policy. It doesn't matter what the operating system's execution policy is set to, or how it's configured. You can bypass it no matter what. That's why I'm seeking out compelling reasons to not just leave it at "unrestricted." Cheers, Trevor Sullivan From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Michael B. Smith Sent: Wednesday, November 6, 2013 12:02 PM To: [email protected]<mailto:[email protected]> Subject: RE: [powershell] Argument in favor of a non-unrestricted Execution Policy? I have no desire to change someone's bias, but I favor RemoteSigned. Think of ExecutionPolicy as a seatbelt. It can help you. Oh, and if ExecutionPolicy is set via GPO, you can't override it. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Mark Stang Sent: Wednesday, November 6, 2013 8:46 AM To: [email protected]<mailto:[email protected]> Subject: Re: [powershell] Argument in favor of a non-unrestricted Execution Policy? Agreed. Restricted is useless. I'm sure developers are all gung ho about signing their 1000 line script masterpieces, but as a sysadmin, signing scripts is too onerous for my 10-20 line throw together scripts to solve an immediate problem. Unrestricted is the way to go. On Tue, Nov 5, 2013 at 12:26 PM, Trevor Sullivan <[email protected]<mailto:[email protected]>> wrote: Hey folks, Can anyone make a specific and compelling argument for why the PowerShell execution policy should be configured to anything *except* "unrestricted? In other words, is there any *solid* reason why one of these values should be configured instead? * RemoteSigned * AllSigned * Restricted As best I can tell, there is no apparent benefit of configuring one of the above, bulleted items, since you can simply call PowerShell.exe -ExecutionPolicy Bypass to work around it. Cheers, Trevor Sullivan ================================================ Did you know you can also post and find answers on PowerShell in the forums? http://www.myitforum.com/forums/default.asp?catApp=1 ================================================ Did you know you can also post and find answers on PowerShell in the forums? http://www.myitforum.com/forums/default.asp?catApp=1 ================================================ Did you know you can also post and find answers on PowerShell in the forums? http://www.myitforum.com/forums/default.asp?catApp=1 ================================================ Did you know you can also post and find answers on PowerShell in the forums? http://www.myitforum.com/forums/default.asp?catApp=1 ================================================ Did you know you can also post and find answers on PowerShell in the forums? http://www.myitforum.com/forums/default.asp?catApp=1 ================================================ Did you know you can also post and find answers on PowerShell in the forums? http://www.myitforum.com/forums/default.asp?catApp=1 ================================================ Did you know you can also post and find answers on PowerShell in the forums? http://www.myitforum.com/forums/default.asp?catApp=1
