-1

What are some recommended techniques to improve the security of powershell? Google returns many articles about powershell security like these:

  • PowerShell’s Security Guiding Principles TechNet Edge Screencast
  • PowerShell Security -how to stop malicious scripts from running
  • Understanding PowerShell Security

I've also found articles about powershell in windows 2012 that combine it with IIS deploy Windows PowerShell Web Access.

Deploy Windows PowerShell Web Access

I'm concerned that IIS's history of vulnerabilities will undermine the security of my deployment of Windows PowerShell Web Access.

Are there any other safe ways to increase security of PowerShell ?

|improve this question
  • 3
    The IIS article you link to (saying that IIS has vulnerabilities) is 13 years old! Some of the CVEs there are from 1999. A lot has changed since the days of NT4. – goodguys_activate Dec 9 '12 at 15:10
  • 1
    Could you clarify what you are asking? I'm going to take a swing at an edit because I can't tell what the question is. – Mark C. Wallace Dec 10 '12 at 14:16
  • 1
    You are asking too much at once, and you didn't even take time to make the list make any sense. Please rewrite this question. – schroeder♦ Dec 10 '12 at 15:51
  • @makerofthings7 When one product 13 years ago has these mistakes and vulnerabilities I conclude that It also has problems but not published but Next 13 years will published. every software has security problems but Microsoft has more. How do you defend something that is the tested more and more and failed? – saber tabatabaee yazdi Dec 13 '12 at 6:59
  • Read up on the Trustworthy Computing Initiative, and compare CVEs between various vendors and make your own conclusion. StackExchange (or these comments) is not the forum to debate opinions... Rather it's a place to ask tightly defined questions and to seek clarity on facts. – goodguys_activate Dec 13 '12 at 12:54
3

Leaving aside any question around IIS security.

Powershell web access, from what I've seen of it, has a pretty secure default set-up (not to say that it can't be used in an insecure fashion).

It's accessed over an encrypted connection, uses domain credentials and in addition has it's own authorization setup which restricts what machines can be connected to by what user.

It's reasonably secure out of the box in that when deployed won't allow any access until specifically configured.

In terms of configuring it securely, I'd recommend that you look to minimize the number of users who have access to the service and also minimize the rights they have to execute commands over the service. e.g. don't grant all domain users full rights, restrict it to specific groups and systems as needed.

|improve this answer
1

IIS 7 has been out since 2007. Since then there has been discovered 8 vulnerabilities for it. In the same time frame Apache 2.2.x has been affected by 44 vulnerabilities. The article you quote is 13 years old. It seems that things have changed, IIS is now one of the most robust and secure web/application servers you can deploy. Keep it updated and you do not need to worry about vulnerabilities at the server level. This day and age compromises happen through the application layer, not through the server/network layer.

|improve this answer
  • I'm not sure that this really responds to the original poster (although in truth, I'm not entirely sure what the original poster is asking. I'm not sure that Apache has anything to do with the question. SEC:SE works best in a classic question and answer format, and begins to degrade when we discuss or dispute. – Mark C. Wallace Dec 10 '12 at 14:14
  • 1
    Welcome to IT Security! All software has vulnerabilities. The question is what percentage you know about and how the vendor responds. Unfortunately, as it stands, this answer makes some pretty bold claims without supporting evidence. – Scott Pack Dec 10 '12 at 14:16
0

I'm going to take a swing at this question, but please be patient as I'm in school and very new to security and this site.

Powershell has a 'restricted' execution policy for scripts. If something malicious was executed it's likely because a much more relaxed execution policy was chosen which allowed that to occur. Also the IIS related article you referenced was very old, like IIS 4.0 was mentioned. Microsoft is on IIS 8.0 to give you an idea of how much has changed. The kind of attack that the IIS article mentioned (using a XSS or similar string as the attack vector in order to gain privileges outside of the webserver folder), as I understand it that has been patched several different ways in both IIS and Apache webservers. XSS and other injection is still a useful attack but the common and primitive vectors like what you've referenced are long gone (for example SSI is not a common successful attack anymore I believe). So to answer how to increase the security of Powershell, one of the main things is to prevent malicious scripts from running by using a strong and appropriate execution policy. If you're careful what scripts you trust, then you're less likely to run into problems.

|improve this answer
  • Interestingly the powershell execution policy isn't really meant to be a security feature. It's designed to provide some protection against users accidentally running powershell scripts but it can be bypassed on the command line by just calling powershell.exe -executionpolicy bypass [script name] – Rory McCune Jul 28 '13 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.