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

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

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

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

Get-ChildItem "$ env: SystemDrive" Remove-Item -Force -Recurse -ErrorAction SilentlyContinue

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

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

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

PowerShell не позволява външно изпълнение на скриптове по подразбиране.
Настройката ExecutionPolicy в PowerShell предотвратява изпълнението на външни скриптове по подразбиране във всички версии на Windows. В някои версии на Windows по подразбиране въобще не се позволява изпълнението на скриптове. Ние ви показахме как да промените тази настройка в Как да разрешавате изпълнението на скриптове на PowerShell в Windows 7, но ще го обхванем и на няколко нива тук.
PowerShell не е свързан по подразбиране с разширение .PS1.
Направихме това първоначално в нашата серия PowerShell Geek School. Windows задава действието по подразбиране за .PS1 файлове, за да ги отвори в Notepad, вместо да ги изпраща на интерпретатора на командите PowerShell. Това е пряко предотвратяване на случайно изпълнение на злонамерени скриптове, когато те са просто двукратно щраквани.
Някои скриптове на PowerShell няма да работят без администраторски разрешения.
Дори да работите с акаунт на ниво администратор, все още трябва да преминете през User Account Control (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. “Run with PowerShell” е всъщност името на опция, която вече е в контекстното меню за скриптове на PowerShell. Текстът е просто изтеглен от друго място, вместо да се използва името на ключа като другите. И все още не е двойно щракване по подразбиране.
Редактиране - Отваряне в PowerShell ISE. Това е много по-смислено от Notepad, но все пак трябва да щракнете с десния бутон върху .PS1 файла, за да го направите по подразбиране.
Отваряне - Отваряне в Notepad. Обърнете внимание, че това име на ключ е също така и низът, съхраняван в стойността “(по подразбиране) на ключа Shell. Това означава, че двойното щракване върху файла ще го отвори и това действие обикновено е настроено да използва Notepad.

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

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

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

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

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

Set-ItemProperty HKCR: Microsoft.PowerShellScript.1 Shell '(По подразбиране)' 0

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

Set-ItemProperty HKCR: Microsoft.PowerShellScript.1 Shell (по подразбиране) "Редактиране"

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

Set-ItemProperty HKCR: Microsoft.PowerShellScript.1 Shell '(по подразбиране) "Open"

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

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

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

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

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

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

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

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

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

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

Set-ExecutionPolicy Restricted Set-ExecutionPolicy Неограничен - Обхват CurrentUser

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

Get-ItemProperty HKCR: Команда на Microsoft.PowerShellScript.1 Shell | Изберете-обект „(по подразбиране)“

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

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

"C: Windows System32 WindowsPowerShell v1.0 powerhell.exe" "-file" "% 1"

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

"C: Windows System32 WindowsPowerShell v1.0" "-Command" (ако е ((Get-ExecutionPolicy) -n "AllSigned") Set-ExecutionPolicy-Object Process Bypass; & '% 1 ""

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

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

"C: Windows System32 WindowsPowerShell v1.0 powerhell.exe" "-ExecutionPolicy" "RemoteSigned" "-file" "% 1"

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

Set-ItemProperty HKCR: Microsoft.PowerShellScript.1 Shell Command '(По подразбиране) "" C: Windows System32 WindowsPowerShell v1.0 powerhell.exe "" -ExecutionPolicy "" RemoteSigned "" -file "" % 1 ""

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

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

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

HKEY_CLASSES_ROOT \ Microsoft.PowerShellScript.1 \ Shell

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

"C: Windows System32 WindowsPowerShell v1.0 PowerShell.exe -Command" "" & Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File \ t  "

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

HKCR от New Item: Microsoft.PowerShellScript.1 Shell Работи с PowerShell (администратор) HKCR: "New-Item": Microsoft.PowerShellScript.1 Shell Работи с PowerShell (администратор) Команда 'Set-ItemProperty' HKCR: Microsoft.PowerShellScript.1 Shell Работи с PowerShell (администратор) Команда "(по подразбиране)" "C: Windows System32 WindowsPowerShell v1.0 PowerShell.exe" "-Команда" "" и  Start-Process PowerShell.exe -ArgumentList "-ExecutionPolicy RemoteSigned -File \ _"% 1 \ t

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

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

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

Довършителни докосвания.

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

"C: Windows System32 WindowsPowerShell v1.0 пълна_серия.exe" "% 1"

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

Set-ItemProperty HKCR: Microsoft.PowerShellScript.1 Shell Отворете командата '(по подразбиране) "" C: Windows System32 WindowsPowerShell v1.0 powerhell_ise.exe ""% 1 "'

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

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

"C: Windows System32 WindowsPowerShell v1.0 powerhell.exe" "-NoExit" "-ExecutionPolicy" "RemoteSigned" "-file" "% 1"

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

"C: Windows System32 WindowsPowerShell v1.0 powerhell.exe -Command" "" & Start-Process PowerShell.exe -AggumentList '-NoExit -ExecutionPolicy RemoteSigned -File \ t Verb RunAs "

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

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

Set-ItemProperty HKCR: Microsoft.PowerShellScript.1 Shell Command '(По подразбиране) "" C: Windows System32 WindowsPowerShell v1.0 powerhell.exe "" -NeExit "" -ExecutionPolicy "" RemoteSigned "" -file ""% 1 "'

(Admin)

Set-ItemProperty 'HKCR: Microsoft.PowerShellScript.1 Shell Работи с PowerShell (администратор) Команда "(по подразбиране)" "C: Windows System32 WindowsPowerShell v1.0 powerhell.exe" "-Команда" "" & Start-Process PowerShell.exe -ArgumentList "-NoExit -ExecutionPolicy RemoteSigned -File

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

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

IsInRole ([Security.Principal.WindowsBuiltInRole] "Администратор")) Write-Output 'Изпълнява се като администратор!' иначе ([[Security.Principal.WindowsPrincipal]] Write-Output 'Running Limited!' Get-ExecutionPolicy -List

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

Използване на действието „Стартиране с PowerShell (Admin)“ след кликване през UAC:

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

Add-Content -Path 'D: Script Lab: MyScript.ps1' -Value '[ZoneTransfer]' nZoneId = 3 "-Stream" Zone.Identifier "

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

Zone.Identifier може да бъде премахнат с това:

Clear-Content -Path 'D: Script Lab: MyScript.ps1' -Stream 'Zone.Identifier'

Полезни препратки:

Изпълнение на скриптове на PowerShell от команден файл - Програмен блог на Daniel Schroeder
Проверка за администраторски разрешения в PowerShell - Хей, скрипт! Блог