Как да конфигурирате Windows да работи с PowerShell скриптове по - лесно

Windows и PowerShell имат вградени функции за сигурност и конфигурации по подразбиране, предназначени да предпазят крайните потребители от случайно стартиране на скриптове в хода на ежедневните си дейности. Ако обаче ежедневните ви дейности редовно включват писане и изпълнение на собствени скриптове PowerShell, това може да бъде повече неудобство, отколкото полза. Тук ще ви покажем как да обновите тези функции, без да правите компромиси със сигурността.

Как и защо Windows & PowerShell предотвратяват изпълнението на скриптове.

PowerShell е ефективно командния четец и скриптовия език, предназначен да замени CMD и партидните скриптове на системите на Windows. Като такъв, скриптът PowerShell може да бъде конфигуриран да прави всичко, което можете да направите ръчно от командния ред. Това означава, че правите практически всяка промяна, която е възможна във вашата система, до ограниченията на вашите потребителски акаунти. Така че, ако можете просто да кликнете два пъти върху PowerShell скрипт и да го изпълнявате с пълни администраторски права, обикновен модул като този може наистина да разруши вашия ден:

Get-ChildItem "$ env: SystemDrive \" -Рекусия -ErrorAction Безшумно прекратяване | Премахване на елемент -Force -Recurse -ErrorAction SilentlyContinue

НЕ изпълнявайте горната команда!

Това просто минава през файловата система и изтрива каквото може. Интересното е, че това може да не направи системата неработеща толкова бързо, колкото си помислите - дори когато се движите от повишена сесия. Но ако някой ви се обади след стартирането на този скрипт, защото внезапно не може да намери файловете си или да стартира програми, "да го изключите и отново да включите" вероятно ще ги доведе само до Windows Startup Repair, където ще им се каже, нищо, което може да се направи, за да се реши проблемът. Това, което може да е по-лошо, е, вместо да получите скрипт, който просто срива файловата си система, вашият приятел може да бъде подмамен да стартира такъв, който изтегля и инсталира услугата keylogger или отдалечен достъп. След това, вместо да ви задават въпроси относно поддръжката при стартиране, те могат в крайна сметка да поискат от полицията някои въпроси за банкови измами!

Досега трябва да е очевидно защо са необходими някои неща, за да се защитят крайните потребители от себе си, така да се каже. Но потребителите на власт, системните администратори и други ентусиасти обикновено (макар да съществуват изключения) малко по-предпазливи от тези заплахи, знаят как да ги разпознават и лесно ги избягват и просто искат да продължат работата си. За да направите това, те ще трябва или да забранят или да работят около няколко пътни блока:

• PowerShell не позволява по подразбиране изпълнението на външни скриптове.
  Настройката ExecutionPolicy в PowerShell предотвратява изпълнението на външни скриптове по подразбиране във всички версии на Windows. В някои версии на Windows, по подразбиране не се допуска изобщо изпълнение на скриптове. Ние ви показахме как да промените тази настройка в "Как да разрешите изпълнението на PowerShell Scripts в Windows 7, но ще я покрием и на няколко нива тук.
• PowerShell не е свързан по подразбиране с разширението .PS1.
  Първоначално го направихме в нашата серия PowerShell Geek School. Windows настройва действието по подразбиране за файловете .PS1, за да ги отвори в Notepad, вместо да ги изпрати на PowerShell командния интерпретатор. Това е прякото предотвратяване на случайно изпълнение на злонамерени скриптове, когато те просто са щракнали двукратно.
• Някои скриптове PowerShell няма да работят без разрешения от администратора.
  Дори да се изпълнява с профил на ниво администратор, все пак трябва да преминете през Управление на потребителски акаунт (UAC), за да извършвате определени действия. За инструментите на командния ред това може да е малко тромаво, за да кажем най-малкото. Не искаме да деактивираме UAC, но все още е хубаво, когато можем малко по-лесно да се справим.

Тези същите проблеми са повдигнати в "Как да използвате пакетен файл, за да направят PowerShell скриптове по-лесни за изпълнение", където ще ви преведем в писането на партиден файл, за да ги преместите временно. Сега ще ви покажем как да настроите системата си с по-дългосрочно решение. Имайте предвид, че обикновено не трябва да правите тези промени на системи, които не се използват изключително от вас - в противен случай поставяте други потребители на по-висок риск да се появят същите проблеми, които тези функции са предназначени да предотвратят.

Промяна на свързването на файла .PS1.

Първото, а може би и най-голямото неприятно разстройство, е асоциацията по подразбиране за .PS1 файлове. Свързването на тези файлове с нещо различно от PowerShell.exe има смисъл за предотвратяване на случайно изпълнение на нежелани скриптове. Но, като се има предвид, че PowerShell идва с интегрирана среда за скриптове (ISE), която е специално създадена за редактиране на PowerShell скриптове, защо бихме искали да отворим .PS1 файлове в Notepad по подразбиране? Дори и да не сте готови да превключите напълно към активирането на функцията за двойно щракване, можете да промените тези настройки.

Можете да промените свързването на файловете .PS1 с каквато програма искате с контролния панел по подразбиране, но копането директно в регистъра ще ви даде малко повече контрол върху това как точно ще се отворят файловете. Това също така ви позволява да зададете или промените допълнителни опции, които са налице в контекстното меню за файлове .PS1. Не забравяйте да направите резервно копие на системния регистър, преди да направите това!

Настройките на системния регистър, които контролират начина на отваряне на PowerShell скриптовете, се съхраняват на следното място:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

За да проучите тези настройки, преди да ги променим, погледнете този ключ и неговите под-клавиши с Regedit. Ключът Shell трябва да има само една стойност, "(по подразбиране)", която е настроена на "Open".Това е указание за действието по подразбиране за двойно кликване върху файла, което ще видим в под-клавишите.

Разгънете клавиша Shell и ще видите три подключа. Всяко от тях представлява действие, което можете да изпълните, което е специфично за PowerShell скриптове.

Можете да разгънете всеки ключ, за да изследвате стойностите в него, но те основно се приравняват към следните стойности по подразбиране:

• 0 - Стартирайте с PowerShell. "Изпълнение с PowerShell" е всъщност името на опция, вече в контекстното меню за PowerShell скриптове. Текстът просто е изтеглено от друго местоположение, вместо да използва името на клавиша като другите. И това все още не е стандартното действие с двойно кликване.
• Редактиране - Отваряне в PowerShell ISE. Това прави много по-смисъл от Notepad, но все пак трябва да кликнете с десния бутон върху файла .PS1, за да го направите по подразбиране.
• Отваряне - Отваряне в Notepad. Обърнете внимание, че това име на клавиш е и низът, запазен в стойността "(по подразбиране)" на клавиша Shell. Това означава, че двукратно щракване върху файла ще го "отвори" и това действие обикновено е зададено да използва Notepad.

Ако искате да се придържате към вече създадените командващи низове, можете просто да промените стойността "(по подразбиране)" в клавиша "Shell", за да съответства на името на ключа, съответстващо на това, което искате да направите с двоен клик. Това може лесно да бъде направено от Regedit, или можете да използвате извлечените поуки от нашия урок за изследване на регистъра с PowerShell (плюс малък PSDrive tweak), за да започнете да създавате скрипт за повторно използване, който да конфигурира вашите системи за вас. Командите по-долу трябва да се изпълняват от повишена PowerShell сесия, подобна на изпълняващата CMD като администратор.

Първо, ще искате да конфигурирате PSDrive за HKEY_CLASSES_ROOT, тъй като това не е зададено по подразбиране. Командата за това е:

Нов PSDrive HKCR регистър HKEY_CLASSES_ROOT

Сега можете да навигирате и да редактирате ключове и стойности на регистър в HKEY_CLASSES_ROOT, точно както бихте направили в обикновените HKCU и HKLM PSDrives.

За да конфигурирате двойно кликване, за да стартирате директно PowerShell скриптове:

Настройка на елементна собственост HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(по подразбиране)' 0

За да конфигурирате двойно кликване, за да отворите PowerShell скриптове в PowerShell ISE:

Настройка на елемента на елемента HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(по подразбиране) "Edit"

За да възстановите стойността по подразбиране (задайте двойно кликване, за да отворите скриптовете PowerShell в Notepad):

Настройка на елементна собственост HKCR: \ Microsoft.PowerShellScript.1 \ Shell '(по подразбиране) "Open"

Това са само основите на промяната на действието по подразбиране с двойно щракване. Ще разгледаме по-подробно как се обработват PowerShell скриптовете, когато се отворят в PowerShell от Explorer в следващия раздел. Имайте предвид, че обхватът не позволява на PSDrives да продължи да съществува в сесиите. Така че, вероятно ще искате да включите линията New-PSDrive в началото на всеки скрипт за конфигуриране, който създавате за тази цел или да го добавите към вашия PowerShell профил. В противен случай ще трябва да изпълните ръката, преди да се опитате да направите промени по този начин.

Промяна на настройката PowerShell ExecutionPolicy.

PowerShell's ExecutionPolicy е друг защитен слой срещу зловреден скрипт. Има няколко опции за това и няколко различни начина, по които може да се зададе. От най-малко до най-малко сигурни, наличните опции са:

• Ограничено - не се разрешава да се изпълняват скриптове. (Настройка по подразбиране за повечето системи.) Това дори ще попречи на скрипта на потребителския ви профил да се показва.
• AllSigned - Всички скриптове трябва да бъдат подписани цифрово от надежден издател, който да се изпълнява, без да ги подканя. Скриптовете, подписани от издатели, изрично дефинирани като невярващи, или скриптове, които изобщо не са подписани дигитално, няма да се изпълняват. PowerShell ще подкани потребителя за потвърждение, ако даден скрипт е подписан от издател, който още не е дефиниран като надежден или неверен. Ако не сте подписали цифрово скрипта за потребителски профили и сте установили доверие в този подпис, той няма да може да се стартира. Бъдете внимателни към кои издатели имате доверие, тъй като все пак можете да престанете да изпълнявате злонамерени скриптове, ако вярвате в грешния.
• RemoteSigned - За скриптове, изтеглени от интернет, това е действително същото като "AllSigned". Въпреки това скриптове, създадени на местно ниво или импортирани от източници, различни от Интернет, могат да се изпълняват без никакви потвърждаващи подкана. Тук ще трябва да сте внимателни кои цифрови подписи имате доверие, но дори да сте по-внимателни с не-подписаните скриптове, които изберете да изпълните. Това е най-високото ниво на защита, при което можете да имате работен скрипт на профила, без да го подлагате на цифрово подписване.
• Неограничено - всички скриптове могат да се изпълняват, но за скриптове от интернет се изисква потвърждаване. От тази гледна точка зависи изцяло от вас да избягвате да вършите невероятни скриптове.
• Байпас - Всичко върви без предупреждение. Бъдете внимателни с тази.
• Недефиниран - в настоящия обхват не е определена политика. Това се използва, за да се даде възможност за спад в правилата, дефинирани в по-ниски обхвати (повече подробности по-долу) или по подразбиране за OS.

Както се предлага от описанието на Undefined, горепосочените правила могат да бъдат зададени в един или повече от няколко области. Можете да използвате Get-ExecutionPolicy с параметъра -List, за да видите всички сфери и текущата им конфигурация.

Сферите са изброени по ред на приоритет, като най-горният дефиниран обхват заменя всички останали. Ако не са дефинирани никакви правила, системата се връща към стандартната си настройка (в повечето случаи това е ограничено).

• MachinePolicy представлява групова политика в сила на ниво компютър. Това обикновено се прилага само в даден домейн, но може да се направи и на местно ниво.
• UserPolicy представлява групова политика в сила за потребителя. Това обикновено се използва само в корпоративни среди.
• Процесът е обхват, специфичен за този случай на PowerShell. Промените в правилата в този обхват няма да се отразят на други процеси на PowerShell и ще бъдат неефективни след прекратяването на тази сесия. Това може да бъде конфигурирано от параметъра -ExecutionPolicy при стартиране на PowerShell или може да бъде зададено със съответния синтаксис Set-ExecutionPolicy от сесията.
• CurrentUser е обсег, който е конфигуриран в локалния регистър и се отнася за потребителския акаунт, използван за стартиране на PowerShell. Този обхват може да бъде променен със Set-ExecutionPolicy.
• LocalMachine е обсег, конфигуриран в локалния регистър и приложим към всички потребители на системата. Това е стандартният обхват, който се променя, ако се изпълни Set-ExecutionPolicy без параметъра -Scope. Тъй като това се отнася за всички потребители на системата, то може да бъде променено само от повишена сесия.

Тъй като тази статия се отнася основно до намирането на охрана за улесняване на ползваемостта, ние сме загрижени за ниските три обхвата. Настройките на MachinePolicy и UserPolicy са наистина полезни само ако искате да наложите ограничителна политика, която не е толкова заобиколена. Като запазим промените ни на ниво Процес или по-долу, можем лесно да използваме всякакви правила, които считаме за подходящи за дадена ситуация по всяко време.

За да запазите известно равновесие между сигурността и използваемостта, правилата, показани на скрийншота, вероятно са най-добри. Настройването на правилата на LocalMachine на Restricted обикновено предотвратява изпълнението на скриптове от никой друг освен вас. Разбира се, това може да бъде заобиколено от потребители, които знаят какво правят без много усилия. Но той трябва да държи всички потребители, които не са от технолози, от случайно да задействат нещо катастрофално в PowerShell. Наличието на CurrentUser (т.е. вие), зададено като неограничено, ви позволява ръчно да изпълнявате скриптове от командния ред, колкото искате, но запазва напомняне за предпазливост за скриптове, изтеглени от Интернет. Настройката RemoteSigned на ниво процес трябва да се извърши в пряк път до PowerShell.exe или (както ще направим по-долу) в стойностите в регистъра, които контролират поведението на PowerShell скриптове. Това ще ви позволи лесно да използвате функцията за двойно кликване за изпълнение на скриптове, които пишете, като същевременно създавате по-силна бариера срещу непреднамерено изпълнение на (потенциално злонамерени) скриптове от външни източници. Искаме да направим това тук, тъй като е много по-лесно случайно да кликнете два пъти върху даден скрипт, отколкото да го наречете ръчно от интерактивна сесия.

За да зададете правилата CurrentUser и LocalMachine, както е показано на екрана по-горе, изпълнете следните команди от повишена PowerShell сесия:

Set-ExecutionPolicy Ограничен Set-ExecutionPolicy Неограничено -Scope CurrentUser

За да приложим правилата на RemoteSigned за скриптове, които се изпълняват от Explorer, ще трябва да сменим стойността на един от клавишите на системния регистър, на които разгледахме по-рано. Това е особено важно, тъй като в зависимост от версията ви PowerShell или Windows, конфигурацията по подразбиране може да е заобикаляща всички настройки на ExecutionPolicy, с изключение на AllSigned. За да видите каква е текущата конфигурация за вашия компютър, можете да изпълните тази команда (като се уверите, че HKCR PSDrive е настроено първо):

Получаване на елемент на елемент HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command | Избор на обект (по подразбиране)

Конфигурацията по подразбиране вероятно ще бъде един от следните два струни или нещо съвсем подобно:

(Видян на Windows 7 SP1 x64, с PowerShell 2.0)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-файл" "% 1"

(Видян на Windows 8.1 x64, с PowerShell 4.0)

"(C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "ако ((Get-ExecutionPolicy) -ne 'AllSigned') Set-PecutionPolicy -Scope Process Bypass ""

Първият не е много лош, тъй като всичко, което прави, е да изпълни скрипта под съществуващите настройки на ExecutionPolicy. Това би могло да стане по-добро, като се наложат по-строги ограничения за действие, по-податливо на злополуки, но първоначално това не беше предназначено да бъде задействано с двоен клик, а стандартната политика обикновено е Ограничена. Вторият вариант обаче е пълен байпас на каквато и да е ExecutionPolicy, която е вероятно да има на място - дори Restricted. Тъй като байпасът ще бъде приложен в обхвата на процеса, той засяга само сесиите, които се стартират, когато скриптовете се изпълняват от Explorer. Това обаче означава, че бихте могли да завършите стартирането на скриптове, които иначе бихте очаквали (и искате) правилата ви да забраняват.

За да настроите Процедура за изпълнение на ниво процес за скриптове, стартирани от Explorer, в съответствие с екранната снимка по-горе, ще трябва да промените същата стойност на регистъра, която току-що зададохме. Можете да го направите ръчно в Regedit, като го промените на следното:

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "Изпълнение на политиката" "RemoteSigned" "-file" "% 1"

Можете също така да промените настройката от PowerShell, ако предпочитате. Не забравяйте да направите това от повишена сесия, като се преобразува HKCR PSDrive.

Настройка на елементна собственост HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command (по подразбиране) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe "" Изпълнение "" RemoteSigned " % 1 ""

Стартирайте PowerShell скриптове като администратор.

Точно както е лоша идея да деактивирате изцяло UAC, това е също така лоша практика за сигурност за стартиране на скриптове или програми с повишени привилегии, освен ако действително не е необходимо да изпълняват операции, изискващи достъп от администратора. Така че не се препоръчва изграждането на подкана на UAC в действието по подразбиране за PowerShell скриптове. Въпреки това, можем да добавим ново опция за контекстно меню, за да можем лесно да изпълняваме скриптове в повишени сесии, когато е необходимо. Това е подобно на метода, използван за добавяне на "Open with Notepad" в контекстното меню на всички файлове - но тук ще се насочим само към PowerShell скриптове.Също така ще пренесем някои техники, използвани в предходната статия, където използвахме партиден файл вместо хакове за регистрация, за да пуснем нашия скрипт PowerShell.

За да направите това в Regedit, върнете се обратно в клавиша Shell на адрес:

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

В него създайте нов под-ключ. Наречете го "Стартирайте с PowerShell (Admin)". Под него създайте друг под-ключ, наречен "Команда". След това задайте стойността "(по подразбиране)" под командата:

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "" & Стартиране на процеса PowerShell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File \ "% 1 \"'  "

Правейки същото в PowerShell, ще са ви необходими три реда този път. Един за всеки нов ключ и един за задаване на стойността "(по подразбиране)" за командата. Не забравяйте издигането и картографирането на HKCR.

HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run със PowerShell (Admin) \ Command "Set-ItemProperty" (" HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Run с PowerShell (Admin) \ Command "(по подразбиране)" "C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" Стартиране на процеса PowerShell.exe -ArgumentList "-ExecutionPolicy RemoteSigned -Файл \"% 1 \ "" - Verb RunAs "'

Също така обърнете специално внимание на разликите между низа, която се вкарва чрез PowerShell, и действителната стойност, която се вписва в регистъра. Особено трябва да обвием всичко в единични цитати и да удвоим вътрешните единични кавички, за да избегнем грешки в командния анализ.

Сега трябва да имате нов запис в контекстното меню за PowerShell скриптове, наречен "Run with PowerShell (Admin)".

Новата опция ще зареди две последователни PowerShell копия. Първият е само стартер за втория, който използва "Старт-Процес" с параметъра "-Verb RunAs", за да поиска повишение за новата сесия. Оттам, скриптът ви трябва да може да се изпълнява с администраторски права, след като кликнете върху подкана на UAC.

Довършителни щрихи.

Има само още две подобрения, които могат да помогнат за още по-лесен живот. За една, какво ще кажете да се отървете от функцията на Notepad изцяло? Просто копирайте стойността "(по подразбиране)" от клавиша "Команда" под "Редактиране" (по-долу) в същото място под Отвори.

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe" "% 1"

Или можете да използвате този бит на PowerShell (с Admin & HKCR разбира се):

Настройка на елементна собственост HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Open \ Command (по подразбиране) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell_ise.exe "

Още едно незначително дразнене е навикът на конзолата да изчезне, след като сценария е завършен. Когато това се случи, нямаме шанс да прегледаме изхода на скрипта за грешки или друга полезна информация. Това може да се погрижи, като поставите пауза в края на всеки от скриптовете си, разбира се. Алтернативно, можем да променим стойностите "(по подразбиране)" за командите, за да включим параметъра "-NoExit". По-долу са модифицираните стойности.

(Без администраторски достъп)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-NoExit" "ИзпълнениеПолитика" "Отдалечен подпис" ""

(С администраторски достъп)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Command" "&" Стартиране на процеса PowerShell.exe -ArgumentList "-NoExit -ExecutionPolicy RemoteSigned -File \"% 1 \ Verb RunAs "

И, разбира се, ще ви дадем и тези в PowerShell команди. Последно напомняне: Надморска височина & HKCR!

(Non-Администриране)

Задаване на елементна собственост HKCR: \ Microsoft.PowerShellScript.1 \ Shell \ Command (по подразбиране) "" C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe "" -NoExit ""-ExecutionPolicy" "RemoteSigned" -файл ""% 1 "

(Admin)

"C: \ Windows \ System32 \ WindowsPowerShell \ v1.0 \ powershell.exe" "-Сомпютър" \ n "" Изпълнява се с PowerShell (Admin) \ Command " "" & Стартиране на процеса PowerShell.exe -ArgumentList "-NoExit -ExecutionPolicy Отдалечен подпис -Файл \"% 1 \ "" - Verb RunAs "'

Вземете го за завъртане.

За да изпробваме това, ще използваме скрипт, който може да ни покаже настройките за ExecutionPolicy на място и дали скриптът е бил стартиран с разрешения от Administrator. Сценарият ще се нарича "MyScript.ps1" и ще се съхранява в "D: \ Script Lab" в нашата примерна система. Кодът е по-долу, за справка.

ако (([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity] :: GetCurrent ()) IsInRole ([Security.Principal.WindowsBuiltInRole] "Administrator")) Write-Output 'Running as Administrator! Write-Output 'Running Limited!' Get-ExecutionPolicy-Списък

Използване на действието "Стартиране с PowerShell":

Използвайки действието "Пусни с PowerShell (Admin)", след като кликнеш през UAC:

За да демонстрираме ExecutionPolicy в действие в обхвата на процеса, можем да направим Windows да мисли, че файлът идва от Интернет с този бит от PowerShell код:

Добавяне на съдържание - Път "D: \ Лаборатория на скрипта \ MyScript.ps1" -Value "[ZoneTransfer] 'nZoneId = 3" -Стрийм' Zone.Identifier '

За щастие, ние бяхме активирани с "-NoExit". В противен случай, тази грешка би трябвало да мига и не бихме знаели!

Зоната.Идентификатор може да бъде премахната с това:

Clear-Content -Path "D: \ Лаборатория на скрипта \ MyScript.ps1" -Stream "Zone.Identifier"

Полезни референции:

• Стартиране на PowerShell скриптове от пакетен файл - Блогът за програмиране на Даниел Шрьодер
• Проверка за разрешения за администратор в PowerShell - хей, скриптов човек! Блог