Як легше налаштувати Windows для роботи зі сценаріями PowerShell

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

Як і чому Windows & PowerShell запобігає виконанню сценарію.

PowerShell фактично є командною оболонкою і мовою сценаріїв, яка призначена для заміни CMD і пакетних скриптів на системах Windows. Таким чином, сценарій PowerShell може бути налаштований так, щоб робити все, що можна було зробити вручну з командного рядка. Це прирівнюється до практично будь-яких можливих змін у вашій системі, до обмежень на вашому обліковому записі користувача. Отже, якщо ви можете просто двічі клацнути сценарій PowerShell і запустити його з повною привілеями адміністратора, простий один лайнер на зразок цього може дійсно зруйнувати ваш день:

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

НЕ виконуйте наведену вище команду!

Це просто проходить через файлову систему і видаляє все, що може. Цікаво, що це не може зробити систему непрацездатною так швидко, як ви думаєте - навіть якщо ви працюєте з підвищеної сесії. Але якщо хтось зателефонує вам після запуску цього сценарію, тому що вони раптом не можуть знайти свої файли або запустити деякі програми, "вимкнення і ввімкнення", ймовірно, просто призведе їх до Windows Startup Repair, де їм буде сказано, що є. нічого, що можна зробити, щоб усунути проблему. Що може бути гірше, замість того, щоб отримувати скрипт, який просто переносить їхню файлову систему, ваш друг може бути перехоплений у той, який завантажує та встановлює кейлоггер або службу віддаленого доступу. Тоді, замість того, щоб задавати вам питання про ремонт стартапів, вони можуть в кінцевому підсумку звернутися до поліції з деякими питаннями про банківське шахрайство!

До теперішнього часу має бути очевидно, чому потрібні певні речі, щоб захистити кінцевих користувачів від себе, так би мовити. Але найпотужніші користувачі, системні адміністратори та інші гіки, як правило, (хоча є і винятки) трохи більш обережні до цих загроз, знаючи, як їх помітити і легко уникнути, і просто хочуть продовжувати свою роботу. Для цього їм доведеться вимкнути або заблокувати декілька блоків доріг:

PowerShell не дозволяє виконувати зовнішнє виконання сценарію за замовчуванням.
Параметр ExecutionPolicy в PowerShell запобігає виконанню зовнішніх скриптів за замовчуванням у всіх версіях Windows. У деяких версіях Windows за замовчуванням виконання сценарію взагалі не допускається. Ми показали, як змінити це налаштування в розділі Як дозволити виконання сценаріїв PowerShell на Windows 7, але ми також охопимо його на декількох рівнях.
За промовчанням PowerShell не пов'язаний з розширенням .PS1.
Ми принесли це спочатку в нашій серії PowerShell Geek School. Windows встановлює дію за умовчанням для файлів .PS1, щоб відкривати їх у Notepad, замість того, щоб відправляти їх до інтерпретатора команд PowerShell. Це призначено для безпосереднього запобігання випадковому виконанню шкідливих скриптів, коли вони просто двічі натискаються.
Деякі сценарії PowerShell не працюватимуть без дозволів адміністратора.
Навіть запустивши з обліковим записом на рівні адміністратора, вам все одно потрібно пройти через керування обліковими записами користувачів (UAC) для виконання певних дій. Для інструментів командного рядка це може бути трохи громіздким. Ми не хочемо відключати UAC, але все одно приємно, коли ми можемо зробити це трохи легше.

Ці ж проблеми виникають у розділі Використання пакетного файлу для спрощення виконання сценаріїв PowerShell, де ми проходимо через написання пакетного файлу, щоб тимчасово обійти їх. Зараз ми покажемо вам, як налаштувати систему на більш довгострокове рішення. Майте на увазі, що ви не повинні вносити ці зміни в системи, які не використовуються виключно вами, інакше ви ставите інших користувачів до підвищеного ризику зіткнутися з тими ж проблемами, які ці функції спрямовані на попередження..

Зміна асоціації файлів .PS1.

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

Ви можете змінити асоціацію .PS1-файлів з будь-якою програмою за допомогою панелі керування за замовчуванням, але копання безпосередньо в реєстрі дасть вам трохи більше контролю над тим, як будуть відкриватися файли. Це також дозволяє встановити або змінити додаткові параметри, які доступні в контекстному меню для файлів .PS1. Не забудьте зробити резервну копію реєстру, перш ніж це зробити!

Параметри реєстру, що контролюють відкриття скриптів PowerShell, зберігаються в такому місці:

HKEY_CLASSES_ROOT Microsoft.PowerShellScript.1 Shell

Щоб ознайомитися з цими налаштуваннями перед тим, як ми їх змінюємо, подивіться на цей ключ і його під-ключі за допомогою Regedit. Клавіша Shell повинна мати одне значення "(За замовчуванням)", яке встановлено на "Відкрити". Це покажчик на дію за умовчанням для подвійного клацання на файлі, який ми побачимо в під-ключах.

Розгорніть клавішу Shell, і ви побачите три під-клавіші. Кожен з них представляє дію, яку можна виконати, що стосується сценаріїв PowerShell.

Можна розширити кожну клавішу, щоб дослідити значення в межах, але вони в основному прирівнюються до наступних стандартних значень:

0 - Запуск із PowerShell. “Запустити за допомогою PowerShell” - це фактично назва опції вже в контекстному меню сценаріїв PowerShell. Текст просто витягується з іншого місця, замість того, щоб використовувати ім'я ключа, як інші. І це ще не є типовим двократним дією.
Редагувати - відкрити в PowerShell ISE. Це набагато більше сенсу, ніж Notepad, але ви все одно повинні клацнути правою кнопкою миші на файлі .PS1, щоб зробити це за замовчуванням.
Відкрити - Відкрити в Блокноті. Зверніть увагу, що це ім'я ключа також є рядком, що зберігається у значенні «(за замовчуванням) ключа« Оболонка ». Це означає, що подвійним клацанням по файлу буде відкрито його, і ця дія, як правило, встановлюється для використання Блокнота.

Якщо ви бажаєте, щоб попередньо побудовані рядки команд вже були доступні, ви можете просто змінити значення "(за замовчуванням)" у ключі "Оболонка", щоб відповідати назві ключа, який відповідає тому, що потрібно зробити подвійним клацанням. Це можна легко зробити в межах 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 (за замовчуванням) "Редагувати"

Щоб відновити значення за замовчуванням (встановлює подвійне клацання, щоб відкрити сценарії PowerShell у Notepad):

Set-ItemProperty HKCR: Оболонка Microsoft.PowerShellScript.1 (за замовчуванням) "Відкрити"

Це лише основи зміни типової дії за замовчуванням. Докладніше про налаштування сценаріїв PowerShell під час їх відкриття в PowerShell з Провідника ми розглянемо у наступному розділі. Майте на увазі, що масштабування запобігає збереженню PSDrives через сеанси. Таким чином, ви, ймовірно, захочете включити лінію New-PSDrive на початку будь-якого сценарію налаштування, який ви збираєтеся для цієї мети, або додайте його до свого профілю PowerShell. В іншому випадку, вам потрібно буде запустити цей біт вручну, перш ніж намагатися внести зміни таким чином.

Зміна параметра PowerShell ExecutionPolicy.

ExecutionPolicy PowerShell - це ще один рівень захисту від виконання шкідливих скриптів. Є кілька варіантів для цього, і кілька різних способів його можна встановити. Від більшості до найменш захищених доступні варіанти:

Обмежений - не дозволяється запускати сценарії. (Значення за замовчуванням для більшості систем.) Це навіть перешкоджатиме запуску сценарію вашого профілю.
AllSigned - всі скрипти повинні бути цифрово підписані довіреним видавцем для запуску без запиту користувача. Скрипти, підписані видавцями, явно визначеними як недостовірні, або сценарії, які взагалі не мають цифрового підпису, не запускатимуться. PowerShell запитає користувача про підтвердження, якщо скрипт підписаний видавцем, який ще не визначено як надійний або ненадійний. Якщо ви не підписали цифровий підпис сценарію профілю та не довіряли цьому підпису, він не зможе працювати. Будьте обережні, яким видавцям ви довіряєте, оскільки ви все одно можете запустити шкідливі скрипти, якщо ви довіряєте неправильному.
RemoteSigned - для сценаріїв, завантажених з Інтернету, це дійсно так само, як і "AllSigned". Однак сценарії, створені локально або імпортовані з інших джерел, ніж Інтернет, можуть працювати без будь-якого запиту на підтвердження. Тут ви також повинні бути обережними, яким цифровим підписам ви довіряєте, але навіть будьте обережнішими у непідписаних скриптах, які ви вибрали для запуску. Це найвищий рівень безпеки, за допомогою якого ви можете мати робочий сценарій профілю без необхідності цифрового підпису.
Unrestricted - дозволяється запуск усіх скриптів, але для сценаріїв з Інтернету буде потрібно запит на підтвердження. З цього моменту ви повинні повністю уникнути запуску ненадійних сценаріїв.
Обхід - Все працює без попередження. Будьте обережні з цим.
Не визначено - у поточній області не визначено жодної політики. Це використовується, щоб дозволити повернення до політики, визначеної в нижчих областях (більш детально нижче) або за умовчанням ОС.

Як випливає з опису 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 Restricted Set-ExecutionPolicy Необмежений-Область CurrentUser

Щоб застосувати політику RemoteSigned на скриптах, запущених з Провідника, нам доведеться змінити значення в одному з ключів реєстру, які ми розглядали раніше. Це особливо важливо, оскільки, залежно від вашої версії 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" "-файл" "% 1"

(Видно на Windows 8.1 x64, з PowerShell 4.0)

"C: Windows System32 WindowsPowerShell v1.0" "-Command if ((Get-ExecutionPolicy) -n" AllSigned ") Set-ExecutionPolicy-Обхідний процес обходу; & '% 1 '"

Перший не дуже поганий, оскільки все, що він робить, виконує сценарій під існуючими параметрами ExecutionPolicy. Це можна зробити краще, застосовуючи жорсткіші обмеження для більш схильних до нещасних випадків дій, але це спочатку не було призначене для того, щоб спрацьовувати за допомогою подвійного клацання, і стандартна політика зазвичай обмежена. Другий варіант, однак, є повним обходом будь-якої ExecutionPolicy, яку ви, ймовірно, матимете на місці - навіть обмежений. Оскільки байпас буде застосовано в області Process, він впливає лише на сеанси, які запускаються, коли сценарії запускаються з 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 "" -файл "" % 1 "'

Запускайте сценарії PowerShell як адміністратора.

Так само, як непогано вимкнути UAC повністю, це також погана практика безпеки для запуску скриптів або програм з підвищеними привілеями, якщо ви дійсно не потребуєте їх для виконання операцій, які вимагають доступу адміністратора. Таким чином, не рекомендується створювати запит UAC у дію за умовчанням для сценаріїв PowerShell. Однак, ми можемо додати новий контекстне меню, щоб дозволити нам легко запускати скрипти у підвищених сесіях, коли нам це потрібно. Це схоже на метод, який використовується для додавання "Відкрити за допомогою Блокнота" до контекстного меню всіх файлів, але тут ми будемо орієнтуватися лише на сценарії PowerShell. Ми також будемо переносити деякі методи, використані в попередній статті, де ми використовували пакетний файл замість хакі реєстру, щоб запустити наш сценарій PowerShell.

Щоб зробити це в Regedit, поверніться до ключа "Оболонка" за адресою:

HKEY_CLASSES_ROOT Microsoft.PowerShellScript.1 Shell

Там же створіть новий під-ключ. Назвіть його «Запуск із PowerShell (Admin)». Під ним створіть інший під-ключ під назвою "Команда". Потім, встановіть значення "(за замовчуванням)" під командою ":

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

Виконання цього ж у PowerShell фактично потребує трьох рядків. Один для кожного нового ключа і один для встановлення значення "(за замовчуванням) для команди. Не забувайте про висоту і відображення HKCR.

HKCR для нового елемента: Microsoft.PowerShellScript.1 Shell Запуск за допомогою PowerShell (адміністратора) HKCR: New.PowerShellScript.1 Shell Запуск із PowerShell (адміністратор) Команда 'Set-ItemProperty' HKCR: Microsoft.PowerShellScript.1 Shell Запуск за допомогою PowerShell (Адміністратор) Команда "(за замовчуванням)" "C: Windows System32 WindowsPowerShell v1.0 PowerShell.exe" "-Command" "" &  Start-Process PowerShell.exe -AggumentList "-ExecutionPolicy RemoteSigned -File \ _"% 1 \ t

Крім того, зверніть особливу увагу на відмінності між рядком, що вводиться через PowerShell, та фактичним значенням, яке надходить у реєстр. Зокрема, ми повинні обернути все це в одиночні лапки і подвоїти на внутрішні одинарні лапки, щоб уникнути помилок в розборі команд.

Тепер ви повинні мати нове контекстне меню для сценаріїв PowerShell, що називається "Запуск із PowerShell (адміністратором)".

У новій опції з'являться дві послідовні екземпляри PowerShell. Перший - це просто пускова установка для другого, яка використовує Start-Process з параметром "-Verb RunAs" для запиту висоти для нового сеансу. Звідси ваш сценарій повинен мати змогу запускати з правами адміністратора після натискання рядка UAC.

Закінчує штрихи.

Там тільки ще кілька налаштувань на це, що може допомогти зробити життя трохи легше ще. По-перше, як повністю позбутися функції Notepad? Просто скопіюйте значення "(за замовчуванням)" з клавіші Command під редагуванням (нижче), в тому ж місці під відкритим.

"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" '

Ще одна незначна роздратування - це звичка консолі зникати після завершення сценарію. Коли це станеться, у нас немає жодного шансу переглянути вихідний скрипт на наявність помилок або іншої корисної інформації. Про це можна потурбуватися, зробивши паузу в кінці кожного з ваших сценаріїв, звичайно. З іншого боку, ми можемо змінити значення "(за замовчуванням) для наших ключів команд, щоб включити параметр" -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. Останнє нагадування: Висота & HKCR!

(Без адміністратора)

Set-ItemProperty HKCR: Microsoft.PowerShellScript.1 Shell Command '(За замовчуванням) "" C: Windows System32 WindowsPowerShell v1.0 powerhell.exe "" -NeExit "" -ExecutionPolicy "" RemoteSigned "" -file ""% 1 "'

(Адміністратор)

Set-ItemProperty 'HKCR: Microsoft.PowerShellScript.1 Shell Запуск за допомогою PowerShell (Адміністратор) Команда "(за замовчуванням)" "C: Windows System32 WindowsPowerShell v1.0 powerhell.exe" "-Command" "& Start-Process PowerShell.exe -AggumentList" -NoExit -ExecutionPolicy RemoteSigned -File

Приймаючи його за спину.

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

if (([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity] :: GetCurrent ()). IsInRole ([Security.Principal.WindowsBuiltInRole] "Адміністратор")) Write-Output 'Запуск як адміністратор!' Write-Output 'Running Limited!' Get-ExecutionPolicy -List

Використання дії "Запуск із PowerShell":

Використовуючи дію "Запустити з PowerShell (Admin)", після натискання UAC:

Щоб продемонструвати ExecutionPolicy у дії в області "Процес", ми можемо зробити так, щоб Windows прийшов з Інтернету за допомогою цього коду PowerShell:

Add-Content -Path 'D: сценарій лабораторії MyScript.ps1' -Value [ZoneTransfer] 'nZoneId = 3 "-Stream" Zone.Identifier "

На щастя, у нас був включений -NoExit. Інакше ця помилка могла б мигати, і ми б не знали!

Zone.Identifier можна видалити за допомогою цього:

Clear-Content -Path 'D: сценарій лабораторії MyScript.ps1' -Stream 'Zone.Identifier'

Корисні посилання:

Запуск сценаріїв PowerShell з командного файлу - блог програмування Daniel Schroeder
Перевірка дозволів адміністратора в PowerShell - Гей! Блог