PowerShell Remoting — настройка и удаленное управление. Знакомимся с удаленным управлением в PowerShell – Hey, Scripting Guy! Blog Powershell выполнить сценарий на удаленной машине
Одна из самых популярных задач у системных администраторов это запуск, какой либо команды на удалённом компьютере, не вставая со своего места. Это может быть необходимо для установки программы или утилиты, изменения каких либо настроек, или для чего угодно ещё. И конечно, редко речь идёт лишь об одном компьютере, чаще команду нужно выполнить на множестве рабочих станций или серверов.
Так как задача эта популярная, то и способов её решения существует множество. Начиная от групповых политик (в которых можно применять для этой цели сценарии входа в систему или автозагрузки), и заканчивая мощными системами управления, вроде System Center Essentials или System Center Configuration Manager. Но я в этой статье хочу рассмотреть методы, которые доступны сразу из командной строки или файлов сценариев, а так же не требуют предварительной установки агентов и прочей суматохи. Впрочем, какие-то предварительные требования конечно есть. Например, у вас должны быть административные полномочия на том компьютере, на котором вы хотите выполнить команду (за исключением сценария с «проксированием», но об этом позже).
PsExec.exe
Один из моих любимых способов для решения этой задачи это утилита командной строки PsExec.exe написанная Марком Руссиновичем, которую вы можете свободно скачать с сайта Windows SysInternals. Ссылку на неё вы можете найти в конце статьи. Она не требует установки в систему, вы можете просто скопировать её в одну из папок, содержащихся в переменной окружения %path% и вызывать из любой оболочки командной строки: Cmd или PowerShell.
Использовать PsExec очень просто. Например, чтобы выполнить ipconfig /flushdns на компьютере main, достаточно запустить следующую команду:
psexec \\main ipconfig /flushdns
Команда ipconfig будет запущена на компьютере main под вашими учетными данными. После завершения работы ipconfig весь текстовый вывод будет передан на ваш компьютер, а кроме того будет возвращён код выхода команды (error code). В случае если команда выполнилась успешно, он будет равен 0.
Разумеется, на этом возможности PsExec не заканчиваются. Вызвав утилиту без параметров, можно посмотреть другие доступные опции. Я обращу внимание лишь на некоторые из них.
Ключ -d говорит PsExec что ненужно дожидаться выполнения команды, а достаточно лишь запустить её, и забыть. В этом случае мы не получим выходных данных от консольной утилиты, но зато сможем не дожидаясь завершения предыдущей команды запускать другие. Это очень полезно, если вам необходимо запустить, например установщик программы на нескольких компьютерах.
По умолчанию PsExec выполняет команды в скрытом режиме, то есть на системе где выполняется команда, не будут выводиться никакие окна или диалоги. Однако есть возможность изменить это поведение, с помощью ключа -i . После него можно указать номер сессии, в которой выводить окна, а можно и не указывать, тогда интерфейс будет отображен в консольной сессии.
Таким образом, чтобы вывести окно с информацией о версии операционной системы на компьютере main, следует запустить PsExec таким образом:
psexec -i \\main winver.exe
Если вы хотите выполнить команду сразу на нескольких компьютерах, вам пригодится возможность прочитать их имена из текстового файла списка.
psexec @c:\comps.txt systeminfo.exe
Ну и одной из самых полезных способностей PsExec является возможность интерактивного перенаправления ввода/вывода между компьютерами, что позволяет нам запустить, например cmd.exe на удалённом сервере, а давать ему команды и получать результаты на локальном компьютере.
Каким образом работает PsExec?
Всё гениальное просто. В ресурсах исполняемого файла PsExec.exe находится другой исполняемый файл – PSEXESVC, который является службой Windows. Перед выполнением команды, PsExec распаковывает этот ресурс на скрытую административную общую папку удалённого компьютера, в файл: \\ИмяКомпьютера\Admin$\system32\psexesvc.exe. Если вы с помощью ключа -c указали что необходимо скопировать исполняемые файлы на эту систему, они тоже скопируются в эту папку.
По завершению подготовительных действий, PsExec устанавливает и запускает службу, используя API функции Windows для управления службами. После того как PSEXESVC запустится, между ним и PsExec создаётся несколько каналов для передачи данных (вводимых команд, результатов, и т.д.). Завершив работу, PsExec останавливает службу, и удаляет её с целевого компьютера.
Windows Management Instrumentation (WMI)
Следующий способ реализации этой популярной задачи, о котором я хочу поведать – использование Windows Management Instrumentation. WMI присутствует во всех операционных системах Microsoft, начиная с Windows 2000, и даже на Windows 9x его можно установить из отдельного пакета. WMI включён по умолчанию, и не требует дополнительной настройки. Для его использования достаточно административных прав, и разрешенного на брандмауэре протокола DCOM. WMI предоставляет огромные возможности для управления системами, но нас сейчас интересует лишь одна из них.
Для запуска процессов нам потребуется метод Create класса Win32_Process. Использовать его достаточно несложно. В PowerShell это делается следующим образом:
$Computer = "main"
$Command = "cmd.exe /c systeminfo.exe >
("\\$Computer\root\cimv2:Win32_Process").create($Command)
Здесь в качестве запускаемого процесса я указал cmd.exe, а уже ему, в качестве аргументов передал нужную команду. Это необходимо в случае если вам нужно использовать переменные окружения удалённого компьютера или встроенные операторы cmd.exe, такие как «> » для перенаправления вывода в файл. Метод Create не дожидается завершения процесса, и не возвращает результатов, но зато сообщает нам его идентификатор – ProcessID.
Если вы используете компьютер, на котором пока не установлен PowerShell, вы можете вызвать этот метод WMI и из сценария на VBScript. Например вот так:
Листинг №1 – Запуск процесса используя WMI (VBScript)
Computer = "PC3"
Command = "cmd.exe /c systeminfo.exe > \\server\share\%computername%.txt"
Set objWMIService = GetObject("winmgmts:\\" & Computer & "\root\cimv2:Win32_Process")
Result = objWMIService.Create("calc.exe", Null, Null, intProcessID)
Но гораздо проще воспользоваться утилитой командной строки wmic.exe которая предоставляет достаточно удобный интерфейс для работы с WMI и входит в состав операционных систем, начиная с Windows XP. В ней чтобы запустить, например калькулятор на компьютере main достаточно выполнить следующую команду:
wmic /node:main process call create calc.exe
Разумеется, возможности WMI не ограничиваются только запуском процессов. Если вам интересно дальнейшее изучение этой технологии, я рекомендую ознакомиться со статьями Константина Леонтьева, посвященными WMI, ссылки на которые вы можете найти в конце статьи.
WSH Remote Scripting
Да, как ни странно у Windows Script Host тоже есть возможность запуска сценариев на других компьютерах. Правда эта функция не получила большой популярности, и скорее всего из-за того что требует слишком много подготовительных мероприятий, а взамен предоставляет совсем немного возможностей. Но я все равно расскажу об этом методе, так как и он может пригодиться.
Итак, для запуска сценария на другом компьютере с помощью WSH нам понадобится сделать следующее:
DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax
Выдать группам Anonymous Logon и Everyone разрешения Allow Local и Allow Remote AccessDCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax
Выдать группе Administrators разрешения Allow Local Launch, Allow Remote Launch, Allow Local Activation, Allow Remote Activation
Группе Everyone – Allow Local Launch, Allow Local Activation
Права администратора на удалённом компьютере. Это само собой разумеется, и требуется почти для всех остальных методов запуска перечисленных в этой статье.
Разрешить WSH Remote Scripting создав в системном реестре строковой параметр Remote равный "1" в ключе реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings
Из за ошибки описанной в статье базы знаний Microsoft с номером 311269, на системах с Windows XP может понадобиться выполнить команду wscript –regserver
Если на компьютерах используется брандмауэр, то в нём необходимо разрешить обращения к DCOM. Причем сделать это надо не только на управляемом компьютере, но и на том с которого вы хотите запускать сценарий.
В системах Windows XP с пакетом обновлений 2 и выше, необходимо изменить параметры безопасности DCOM. Это можно сделать с помощью групповой политики. В узле Computer Configuration \ Windows Settings \ Security Settings \ Local Policies \ Security Options следует установить разрешения следующим образом:
Ну и после всех этих процедур, можно попробовать запустить свой сценарий на другом компьютере.
Пример сценария, который использует эту технологию:
Листинг №2 – WSH remote scripting (VBScript)
Set objController = CreateObject("WshController")
Set objRemoteScript = objController.CreateScript("C:\test.vbs", "PC5")
WScript.ConnectObject objRemoteScript, "remote_"
objRemoteScript.Execute
Do While objRemoteScript.Status <> 1
WScript.Sleep 1000
Loop
MsgBox "Script complete"
Sub remote_Error
Dim objError
Set objError = objRemoteScript.Error
WScript.Echo "Error – Line: " & objError.Line & _
", Char: " & objError.Character & vbCrLf & _
"Description: " & objError.Description
WScript.Quit –1
End Sub
На второй его строчке, в качестве параметров для функции CreateScript указывается путь к файлу сценария, который будет выполнен на удаленном компьютере и собственно имя этого компьютера.
Более подробную статью об этой технологии можно прочитать в статье Advanced VBScript for Microsoft Windows Administrators – Chapter 6: Remote Scripting (см. Ссылки).
Планировщик заданий (Task Scheduler)
Планировщиком заданий можно управлять из командной строки используя две утилиты – at.exe и schtasks.exe. Обе эти утилиты позволяют указать имя удалённого компьютера для создания задания, и, следовательно, позволяют решить нашу задачу. Но подробно мы рассмотрим лишь schtasks.exe, так как она предоставляет гораздо больше возможностей.
Хотя выполнение команд на других компьютерах не является основным предназначением планировщика, тем не менее он позволяет реализовать немало интересных сценариев. Например, с его помощью можно включить установку программного обеспечения в период обеденного перерыва. Или если ваши пользователи обедают в разное время, запуск можно выполнять после определённого периода бездействия компьютера.
schtasks /create /s server6.td.local /tn install /tr \\main\data\install.cmd /sc once /st 13:00 /ru system
Важно понимать от имени какой учетной записи будет выполняться задача. В этом примере я указал для параметра /ru значение system, следовательно, для выполнения установки учетной записи компьютера будет необходим доступ на чтение в сетевую папку с дистрибутивом программы.
Еще полезным решением, мне кажется запланировать какое либо действие, на ежедневное выполнение, и удалять задачу лишь при подтверждении его успеха. То есть вы можете создать простой командный файл, который сначала запускает установщик программы, дожидается его завершения, и проверяет – успешно ли установилась программа. Если это так, то он удаляет задание из планировщика на этом компьютере. Пример такого файла:
Листинг №3 – Установка программы с последующим удалением задания (Windows Batch)
msiexec /qn /package \\server\share\subinacl.msi
if exist "c:\program files\Windows Resource Kits\Tools\subinacl.exe" (
subinacl /tn Install_Subinacl /f
WinRM (WS-Management)
WinRM – это реализация открытого стандарта DMTF (Distributed Management Task Force) от Microsoft, которая позволяет управлять системами с помощью веб-служб. Углубляться в устройство технологии я не буду, а лишь кратко опишу, что необходимо для её использования.
Версия WinRM 1 и выше входит в состав операционных систем, начиная с Windows Vista и Windows Server 2008. Для Windows XP и Windows Server 2003 можно установить WinRM в виде отдельного пакета (см. ссылки).
Для того чтобы быстро настроить компьютер для подключений к нему используя стандартные порты и разрешив подключения административным учетным записям, достаточно выполнить команду:
winrm quickconfig
Чтобы winrm не спрашивал подтверждения, можно добавить к вызову ключ -quiet. Узнать информацию о более тонкой настройке можно посмотреть встроенную справку winrm:
winrm help config
Если на управляемом компьютере работает веб-сервер, WinRM никак ему не помешает, хоть и использует по умолчанию стандартные порты HTTP. Он будет перехватывать лишь подключения предназначенные специально для него.
Разумеется необязательно выполнять эту команду вручную, на каждом компьютере которым вы хотите управлять. Все необходимые настройки легко сделать с помощью групповых политик. Для этого нужно:
- Настроить службу WinRM (Windows Remote Management)на автоматический запуск
- Настроить элемент групповой политики Computer Configuration \ Administrative Templates \ Windows Components \ Windows Remote Management (WinRM) \ WinRM Service \ Allow automatic configuration of listeners. Тут нужно указать диапазоны IP-адресов с которых разрешаются подключения.
- Разумеется, еще вам будет необходимо разрешить подключения на соответствующие порты (по умолчанию 80) в брандмауэре Windows.
Независимо от того используется ли порт HTTP (80) или HTTPS (443) трафик передаваемый WinRM шифруется (если конечно вы не отключите эту опцию). Для аутентификации по умолчанию используется протокол Kerberos.
Но хватит о настройках, лучше перейдем непосредственно к использованию. Хоть утилита winrm позволяет настраивать службу WinRM, а так же выполнять например WMI запросы, нам более интересна другая – winrs. Буквы RS тут означают Remote Shell. WinRS работает очень похоже на PsExec хотя и использует технологию WinRM. Имя компьютера задаётся ключом -r, а после него следует команда которую нужно выполнить. Вот несколько примеров:
winrs -r:Core ver.exe
Так как winrs и так использует cmd.exe в качестве удалённой оболчки, в командах можно легко обращаться к удалённым переменным окружения, или использовать другие встроенные команды cmd.exe:
winrs -r:Core "dir c:\temp > c:\temp\list.txt"
Как и PsExec, утилита winrs позволяет открыть интерактивный сеанс на удалённом компьютере:
winrs -r:main cmd.exe
Эта функция аналогична telnet сессии, но использование winrs однозначно лучше telnet и даже PsExec, с точки зрения безопасности. Независимо от того используется ли порт HTTP (80) или HTTPS (443), трафик передаваемый WinRM шифруется (если конечно вы не отключите эту опцию). Для аутентификации по умолчанию используется протокол Kerberos.
Windows PowerShell 2.0 Remoting
Хотя вторая версия Windows PowerShell на момент написания статьи находится еще в состоянии бета тестирования, о её возможностях в области удалённого выполнения команд определённо стоит рассказать уже сейчас. Попробовать его своими руками вы можете либо загрузив предварительную версию (см. ссылки) либо в составе бета-версии Windows 7 или Windows Server 2008 R2.
Инфраструктура PowerShell Remoting основана на WinRM версии 2.0, и поэтому наследует все преимущества этой технологии, такие как шифрование передаваемых данных, и возможность работать по стандартным портам HTTP/HTTPS. Но благодаря богатым возможностям языка Windows PowerShell, и его способностям работы с объектами, мы получаем еще большие возможности. На данный момент пакет WinRM2.0 тоже находится в состоянии бета-тестирования, и доступен для загрузки только для систем Windows Vista и Windows 2008. В системы Windows 7 и Windows Server 2008R2 он будет встроен изначально, как и PowerShell 2.0.
Обновление: К моменту публикации статьи на сайт, финальные версии PowerShell 2.0 и WinRM 2.0 доступны уже для всех поддерживаемых платформ. В состав Windows Server 2008R2 и Windows 7 они уже включены как неотъемлемые компоненты системы, а для Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008 все необходимые компоненты можно получить в виде пакета называемого Windows Management Framework .
Перед тем как воспользоваться всеми этими преимуществами, PowerShell Remoting необходимо активизировать, на управляющем, и управляемых компьютерах. Сделать это просто, запустив командлет (команду Windows PowerShell) Enable-PSRemoting. Причем если добавить ключ -Force то никаких подтверждений запрошено не будет. Этот командлет при необходимости вызовет winrs quickconfig, и создаст исключения в брандмауэре Windows, так что никаких дополнительных действий выполнять не нужно.
После этого вы сможете легко выполнять команды на других компьютерах используя командлет Invoke-Command (или его псевдоним icm):
Invoke-Command -ComputerName Main -ScriptBlock {netsh interface dump > c:\ipconfig.txt}
Разумеется команду можно заранее поместить в переменную, а для параметра -ComputerName указать имена не одного, а сразу нескольких компьютеров. Следующая последовательность позволяет вывести версию файла Explorer.exe сразу с трех компьютеров.
$Command = {(get-item c:\Windows\explorer.exe).VersionInfo.FileVersion}
Invoke-Command -ComputerName Main, Server7, Replica -ScriptBlock $Command
Как видно на, можно передавать сразу несколько команд в одном блоке, помещать их результаты выполнения на нескольких компьютерах в переменную, а затем обрабатывать на рабочей станции используя возможности Windows PowerShell по работе с объектами.
Впрочем возможности PowerShell Remoting на этом только начинаются. С помощью командлета Enter-PSSession вы можете войти в интерактивную сессию Windows PowerShell на удалённом компьютере. Выйти из такого сеанса можно использовав командлет Exit-PSSession, или просто exit.
Командлет New-PSSession создает сессии на удалённых компьютерах, указатели на которые можно поместить в переменную, а затем передавая её как аргумент для Invoke-Command выполнять команды сразу на нескольких компьютерах, в постоянном окружении. Пример вы можете увидеть на скриншоте, где я выполняю последовательность команд сразу на нескольких компьютерах из списка c:\computers.txt.
Проксирование
Этот метод отличается от всех вышеперечисленных, и служит совсем для других задач, но не менее актуален. Когда делегирование полномочий невозможно, или предоставляет слишком большие возможности, он позволяет разрешить обычному пользователю выполнять некую команду, требующую административных привилегий, никаким образом не выдавая дополнительных полномочий и не подставляя под угрозу пароль администратора.
Чаще всего такие проблемы люди решают с помощью утилит вроде cpau.exe (см. ссылки) которые создают файл с зашифрованным паролем административной учетной записи, позволяющий запускать определённую программу. Проблема, однако, в том, что хоть пароль и зашифрован, перед запуском программы утилите придётся его расшифровать. А соответственно пользователь может использовать утилиту повторяющую алгоритм расшифровки пароля, и узнать его, чтобы затем использовать для запуска других программ или получения дополнительных привилегий. Практически это конечно достаточно сложно для обычных пользователей, не обладающих специальными знаниями, но, тем не менее, вполне возможно. Еще раз уточню, это не беда конкретной утилиты, а проблема такого подхода вообще.
Еще может показаться, что для решения задачи подойдет параметр /savecred утилиты runas. Но тут есть даже две проблемы. Во-первых, как и вышеописанном случае, пароль сохраняется на компьютере пользователя, а, следовательно, может быть расшифрован, хотя в случае с runas для этого и понадобятся права локального администратора. Во-вторых, runas сохраняет учетные данные, не связывая их с конкретной командой, а, следовательно, пользователь сможет запустить с завышенными правами не только ту команду, доступ к которой вы хотели ему предоставить, но и любую другую.
Чтобы избежать этих проблем, но, тем не менее, разрешить выполнение конкретной команды, можно использовать методику, которая называется "проксированием".
Работает она следующим образом. На компьютере постоянно работает сценарий с высокими привилегиями. Например, в нашем случае он будет запущен из-под учетной записи, обладающей правами администратора на файловом сервере. По сигналу пользователя он будет выполнять одну, заранее определённую команду. В этом примере – закрывать все файлы, открытые по сети.
Для организации этой системы мы поместим на сервере, например в папке c:\scripts\ командные файлы Server.cmd и Action.cmd .
Листинг №4 – Server.cmd (Windows Batch)
set trigger=c:\commandShare\trigger.txt
set action=c:\scripts\action.cmd
set log=c:\scripts\log.txt
:start
if exist %trigger% start %action% & echo %time% %date%>>%log% & del %trigger%
sleep.exe 5
goto start
Листинг №5 – Action.cmd (Windows Batch)
for /f "skip=4 tokens=1" %%a in (‘net files’) do net files %%a /close
exit
Server.cmd будет ждать знака от пользователя (создание файла в определенном месте), и получив его, запускать файл с командами – Action.cmd. Разумеется, в эту папку пользователи не должны иметь никакого доступа. Автоматический запуск Server.cmd при запуске компьютера можно организовать, просто создав соответствующую задачу в планировщике:
schtasks /create /ru domain\administrator /rp /sc onstart /tn ProxyScript /tr c:\scripts\server.cmd
После параметра /ru указывается учетная запись, под которой будет выполняться сценарий (в нашем случае она обладает правами администратора на сервере), так как после параметра /rp пароль не указан – он будет запрошен при создании задачи. Параметр /sc позволяет указать момент запуска сценария, в нашем случае – при включении компьютера. Ну а /tn и /tr позволяют указать имя задачи, и исполняемый файл.
Теперь, для того чтобы пользователь мог подать сценарию сигнал, мы создадим папку c:\commandShare и сделаем её доступной по сети. Доступ на запись в эту папку должен быть только у тех пользователей, которые будут запускать команду.
После этого достаточно будет поместить пользователю на рабочий стол файл Run.cmd.
Листинг №6 – Run.cmd (Windows Batch)
echo test > \\server\commandShare\trigger.txt
При его выполнении, от имени пользователя, будет создаваться файл \\server\commandShare\trigger.txt. Сценарий Server.cmd, заметив его, запустит на выполнение со своими привилегиями файл Action.cmd, добавит запись в файл c:\scripts\log.txt о текущем времени, а затем удалит trigger.txt чтобы не выполнять команду снова до следующего сигнала пользователя.
В сценарии Server.cmd используется утилита Sleep.exe, позволяющая сделать паузу в выполнении сценария на заданный в секундах промежуток времени. Она не входит в состав операционной системы, но её можно взять из набора Resource Kit Tools (см. ссылки) и просто скопировать на любой компьютер.
powershell удаленный запуск приложения
Запуск интерактивного сеанса
Чтобы запустить интерактивный сеанс с одним удаленным компьютером, используйте командлет Enter-PSSession. Например, чтобы запустить интерактивный сеанс с удаленным компьютером Server01, введите:
enter-pssession Server01
В командной строке отобразится имя компьютера, к которому вы подключены. В дальнейшем все команды, введенные в командной строке, будут запускаться на удаленном компьютере, а результаты отобразятся на локальном компьютере.
Чтобы завершить интерактивный сеанс, введите:
exit-pssession
Выполнение удаленной команды
Чтобы выполнить любую команду на одном или нескольких удаленных компьютерах, используйте командлет Invoke-Command. Например, чтобы выполнить команду Get-UICulture на удаленных компьютерах Server01 и Server02, введите:
Invoke-command -computername Server01, Server02 {get-UICulture}
Выходные данные будут возвращены на ваш компьютер.
Чтобы запустить сценарий на одном или нескольких удаленных компьютерах, используйте параметр FilePath командлета Invoke-Command. Сценарий должен быть включен или доступен для локального компьютера. Результаты будут возвращены на локальный компьютер.
Например, следующая команда выполняет сценарий DiskCollect.ps1 на удаленных компьютерах Server01 и Server02.
invoke-command -computername Server01, Server02 -filepath c:\Scripts\DiskCollect.ps1
Установка постоянного подключения
Чтобы выполнить ряд связанных команд с общими данными, создайте сеанс на удаленном компьютере, а затем используйте командлет Invoke-Command для выполнения команд в созданном сеансе. Чтобы создать удаленный сеанс, используйте командлет New-PSSession.
Например, следующая команда создает удаленный сеанс на компьютере Server01 и другой удаленный сеанс на компьютере Server02. Она сохраняет объекты сеанса в переменной $s.
$s = new-pssession -computername Server01, Server02
После установки сеансов в них можно выполнить любую команду. Так как сеансы являются постоянными, вы можете собирать данные в одной команде и использовать их в последующей.
Например, следующая команда выполняет команду Get-Hotfix в сеансах в переменной $s и сохраняет результаты в переменной $h. Переменная $h создается в каждом сеансе в $s, но она не существует в локальном сеансе.
invoke-command -session $s {$h = get-hotfix}
Теперь данные в переменной $h можно использовать в последующих командах, таких как следующая. Результаты отобразятся на локальном компьютере.
Invoke-command -session $s {$h | where {$_.installedby -ne "NTAUTHORITY\SYSTEM"}
Всё взято с https://technet.microsoft.com/ru-ru/library/dd819505.aspx
Я часто работаю с командами на удаленных системах через PowerShell как во время пентестов, так и при решении повседневных задач. Запуска удаленных команд происходит через протокол WinRM (Windows Remote Management), который, насколько мне известно, поддерживается в Windows Vista SP 1, Windows 7, Windows Server 2008 и Windows Server 2012.
Введение
Я часто работаю с командами на удаленных системах через PowerShell как во время пентестов, так и при решении повседневных задач. Запуска удаленных команд происходит через протокол WinRM (Windows Remote Management), который, насколько мне известно, поддерживается в Windows Vista SP 1, Windows 7, Windows Server 2008 и Windows Server 2012.
Первоначальные настройки
Перед тем как начать работу с удаленной системой, необходимо выполнить настройку.
1. Запустите консоль PowerShell от имени администратора и выполните следующую команду:
Enable-PSRemoting -force
Команда выше разрешает запуск команд на удаленных системах. Если у вас возникли проблемы, используйте команды ниже:
2. Убедитесь в том, что служба WinRM запускается автоматически.
# Устанавливаем нужный режим
Set-Service WinRM -StartMode Automatic
# Проверяем, что служба запущена
Get-WmiObject -Class win32_service | Where-Object {$_.name -like "WinRM"}
3. Устанавливаем у всех хостов статус «достоверный» (можно сделать позже).
# Доверяем всем хостам
Set-Item WSMan:localhost\client\trustedhosts -value *
# Проверяем настройку достоверных хостов
Get-Item WSMan:\localhost\Client\TrustedHosts
Примеры работы с удаленными системами
Запуск одиночной команды на удаленной системе
Команда "Invoke-Command" предназначена для запуска команд на удаленных системах. Можно работать от имени текущего пользователя, либо использовать стороннюю учетную запись, если вы работаете в системе, которая не является частью домена:
Invoke-Command –ComputerName MyServer1 -ScriptBlock {Hostname}
Invoke-Command –ComputerName MyServer1 -Credentials demo\serveradmin -ScriptBlock {Hostname}
Если установлен модуль для работы с ActiveDirectory, становится возможным запуск команд на множестве систем при помощи каналов (pipeline):
Get-ADComputer -Filter * -properties name | select @{Name="computername";Expression={$_."name"}} |
Invoke-Command -ScriptBlock {hostname}
Иногда на удаленной системе требуется запустить скрипт, хранящийся локально:
Invoke-Command -ComputerName MyServer1 -FilePath C:\pentest\Invoke-Mimikatz.ps1
Invoke-Command -ComputerName MyServer1 -FilePath C:\pentest\Invoke-Mimikatz.ps1 -Credentials demo\serveradmin
Если вы генерируете команды или функции динамически, которые затем передаются на удаленную систему можно использовать связку команд invoke-expression и invoke-command:
$MyCommand = "hostname"
$MyFunction = "function evil {write-host `"Getting evil...`";iex -command $MyCommand};evil"
invoke-command -ComputerName MyServer1 -Credentials demo\serveradmin -ScriptBlock
{Invoke-Expression -Command "$args"} -ArgumentList $MyFunction
Организация интерактивной консоли на удаленной системе
Организовать интерактивную консоль в PowerShell на удаленной системе можно при помощи команды "Enter-PsSession" (немного похожа на SSH). Команда "Enter-PsSession" также запускается либо от имени текущего пользователя, либо при помощи альтернативной учетной записи:
Enter-PsSession –ComputerName server1.domain.com
Enter-PsSession –ComputerName server1.domain.com –Credentials domain\serveradmin
Закрытие сессии выполняется при помощи команды "Exit-PsSession":
Создание фоновых сессий
Еще одна полезная возможность позволяет создавать фоновые сессии (команда "New-PsSession"). Фоновые сессии могут оказаться полезны при запуске множества команд во множестве систем. Как и предыдущие команды, команда "New-PsSession" запускается от имени текущего пользователя, либо при помощи альтернативной учетной записи:
New-PSSession -ComputerName server1.domain.com
New-PSSession –ComputerName server1.domain.com –Credentials domain\serveradmin
Если установлен модуль для работы с ActiveDirectory, становится возможным единовременное создание фоновых сессий для множества систем (этот трюк можно выполнить различными способами). Ниже показан пример создания фоновых сессий для всех систем, входящих в домен. В примере создание сессий происходит в системе, не входящей в домен, при помощи альтернативной учетной записи домена.
New-PSDrive -PSProvider ActiveDirectory -Name RemoteADS -Root "
" -Server a.b.c.d -credential domain\user
cd RemoteADS:
Get-ADComputer -Filter * -Properties name | select @{Name="ComputerName";Expression={$_."name"}}
| New-PSSession
Вывод перечня фоновых сессий
Как только создано несколько фоновых сессий, можно просмотреть их перечень при помощи команды "Get-PsSession".
Взаимодействие с фоновыми сессиями
Первое время у меня было ощущение схожее с тем, как я работал с сессиями в MetaSploit. Однако фоновые сессии в PowerShell чуть более стабильны. Ниже показан пример взаимодействия при помощи идентификатора сессии:
Enter-PsSession –id 3
Для выхода из сессии используйте команду "Exit-PsSession". Сессия перейдет обратно в фоновый режим.
Запуск команд через фоновые сессии
Если вы хотите выполнить команду во всех активных сессиях, используйте связку команд "Invoke-Command" и "Get-PsSession".
Invoke-Command -Session (Get-PSSession) -ScriptBlock {Hostname}
Удаление фоновых сессий
Для удаления всех активных сессий используйте команду "Disconnect-PsSession"
Get-PSSession | Disconnect-PSSession
Заключение
Удаленные команды в PowerShell открывают огромные возможности, как для администраторов, так и для пентестеров. Вне зависимости от ситуации, как вы будете работать с удаленными системами, все сводится к следующему:
- Для запуска одиночной команды на удаленной системе используйте "Invoke-Command".
- Для взаимодействия с одиночной системой используйте "Enter-PSSession".
- Если вы хотите запускать множество команд во множестве систем, используйте фоновые сессии.
Надеюсь, эта статья оказалась для вас полезной.
В данной статье подробно объясняется тема удалённого взаимодействия с использованием PowerShell 2.0. Первым делом нам необходимо запустить службу, с помощью которой будет осуществляться удалённое взаимодействие.
Запускаем службу WinRm
Для удалённого взаимодействия в PowerShell 2.0 используется служба WinRM, которая по умолчанию предустановлена на Windows 7 и Windows 2008 R2. Для более ранних версий операционной системы её требуется устанавливать дополнительно. Указанная служба устанавливается на машину при установке PowerShell 2.0. Для того, чтобы убедиться, в наличии WinRM, запустите консоль PowerShell 2.0 и выполните в ней команду:
Get-Service WinRm
Результат будет выглядеть следующим образом:
Status Name DisplayName ------ ---- ----------- Stopped winrm Windows Remote Management (WS-Manag...
Как видим – служба присутствует, однако не запущена. Для того, чтобы запустить WinRm, необходимо с правами администратора, из консоли PowerShell 2.0, выполнить команду:
Enable-PSRemoting
На запрос о подтверждении запуска службы, нажимаем кнопку «Y». Теперь службе WinRM назначен тип запуска «Автоматический», т.е. она будет запускаться каждый раз при старте компьюрета. Команда Enable-PSRemoting не только запускает службу и меняет её тип запуска, но и настраивает должным образом брандмауэр, для её корректной работы. Служба WinRm принимает запросы с любого IP-адреса.
Запрашиваем имена всех подключенных провайдеров:
Get-PSProvider
Как видим, у нас теперь появился ещё один провайдер под именем WSMan.
Назначение доверенных узлов
В консоли PowerShell 2.0 запускаем с правами администратора команды:
Set-Location –Path WSMan: Set-Location –Path localhost\client Get-ChildItem
Примечание
Обратите внимание на то, что в первой команде значение параметра –Path завершается двоеточием, поскольку это провайдер.
На том компьютере, с которым вы желаете удалённо работать, следует указать, каким серверам позволено подключение к этой машине. Такие серверы известны как "доверенные узлы". Таким образом, если вы находитесь на сервере "MyServer", то прежде чем вы сможете удалённо работать с компьютером "MyComputer", следует настроить доверенные узлы (TrustedHosts). Указанный ниже способ назначения доверенных узлов используется в том случае, когда компьютер не входит в состав домена Active Directory. Если же компьютер входит в состав домена Active Directory, то настройки TrustedHosts можно сконфигурировать через групповую политику (Group Policy).
Важно!
Приведённая ниже команда не будет работать, если текущим каталогом не установлен WSMan:\localhost\client (см. вызов команд, выполненный нами выше).
Set-Item TrustedHosts *
Можно запустить команду из другого каталога, но тогда потребуется указать полный путь к TrustedHosts:
Set-Item WSMan:\localhost\Client\TrustedHosts *
На запрос о подтверждении жмём клавишу «Y».
Для того, чтобы PowerShell увидел изменения, выполненные нами в настройках TrustedHosts - необходимо перезапустить службу WSMan. Это делается с помощью следующей команды:
Restart-Service winrm
Аналогичное действие можно выполнить из под DOS. Запустите команду winrm -?. Вы увидите общую справку по команде. Для того, чтобы посмотреть текущее значение TrustedHosts, следует выполнить команду:
winrm get winrm/config/client
а для того, чтобы установить значение - следует выполнить:
winrm set winrm/config/client/ @{TrustedHosts="*"}
В приведённых выше командах, для TrustedHosts, в качестве значения указывался символ «*», однако, вместо него можно указывать имена конкретных серверов. Управление TrustedHosts является классическим случаем, для применения PowerShell-глаголов "Get" и "Set" в связке: вы используете Get-Item и Set-Item.
Создание и завершение удалённого сеанса PowerShell 2.0
В приведённых ниже командах, вместо "IpAddress" следует указывать нужный IP-адрес, а вместо "FQDN " - полностью определённое имя домена (Fully Qualified Domain Name):
Enter-PSSession IpAddress
Enter-PSSession FQDN
Для завершения сеанса удалённой работы, следует выполнить команду:
Команде Enter-PSSession требуется полностью.определённое.доменное.имя. Например, в случае MyServer.domain.local, простое указание MyServer не сработало бы, однако использование IP-адреса всегда хорошо работает в подобных ситуациях. Альтернативный метод PSSession:
New-PSSession -computername testMachine2 Get-PSSession
Завершить работу этой сессии можно так:
Get-PSSession | remove-PSSession
Если вы хотите протестировать удалённую работу, но не имеете второй машины, тогда создайте "удалённое подключение" вашего компьюетера к себе самому. Например, если ваша машина называется "MyMachine", тогда попробуйте это:
New-PSSession -computername MyMachine
Возможно это покажется вам странно и не логично, однако таким способом вы всё же сможете опробовать удалённую работу в PowerShell 2.0.
Работа в удалённом сеансе PowerShell 2.0
После создания удалённого подключения, вы можете организовывать конвейры команд, запуская их в консоли PowerShell 2.0, но при этом выполняться они будут на удалённой машине, как будто вы находитесь за её клавиатурой и набираете команды там, а не здесь. Например, запустите такую команду и посмотрите результат её работы:
Set-Location c:\ | Get-childitem
Поскольку основная задача данного учебного руководства состоит в том, чтобы помочь вам создать сессию удалённого подключения PowerShell 2.0 и показать, как её закрыть, то вам самим придётся решать, какие операции вы желаете выполнить в ходе удалённого подключения.
Примечание
Если вам кажется, что сессии удалённого подключения у вас не работает какая-то команда - протестируйте её сначала на своей локальной машине.
Как только удалённое подключение у вас заработает, это сразу даёт вам возможность использовать PowerShell 2.0 для управления компьютерами, подключенными к вашей сети. Теперь вы можете выполнять сценарии на других машинах. В PowerShell 2.0 многие командлеты поддерживают параметр "-computerName", но удалённое подключение позволяет вам использовать команды семейства PSSession, а так же вызывать Invoke-Command (т.е. вы можете делать всё что угодно).
Поиск и устранение проблем, возникающих в процессе удалённой работы PowerShell 2.0
Одна типичная проблема – ОШИБКА «Access is denied» (доступ запрещён).
Решение:
Запустите PowerShell 2.0 с правами администратора. Попробуйте на обоих машинах (на той, с которой подключаетесь, и на той, к которой подключаетесь) задать настройке "TrustedHosts" значение * (звёздочка). Только не забывайте, что такой вариант разрешает подключения отовсюду.
Не забудьте перезапустить службу WinRm, иначе выполненные вами для "TrustedHosts" изменения не вступят в силу. Для перезапуска службы следует в консоли PowerShell 2.0 выполнить команду: Restart-Service WinRm
Кроме того, будьте внимательней и не путайте имя провайдера WSMan с именем службы WinRm.
Ещё один странный, но порой помогающий совет: Попытайтесь повторить попытку удалённого подключения. Странно, но это может не сработать с первой попытки, но сработать со второй или третьей. Т.е. вам нужно повторно выполнить команду: Enter-PSSession -computerName myOtherMachineName
Брандмауэры, PowerShell 2.0 и «The rpc server is unavailable» (Сервер RPC не доступен)
Специалисты по безопасности в ужасе поднимут руки от такого предложения, однако в случае получения указанной выше ошибки, я предлагаю вам отключить брандмауэр на обоих компьютерах. Если после отключения всё заработает - это хорошо, значит нужно проверить задействованность портов 135 и 445. Настройте для этих портов исключения в брандмауэрах - это даст возможность PowerShell 2.0 работать удалённо и при этом брандмауэр защитит компьютер от угроз.
P.S. я читал, что команда Enable-PSRemoting должна брать на себя автоматическое внесение изменений в настройки брандмауэра, но по моему опыту это не всегда так.
О том, как с помощью групповой политики отключить брандмауэр в Windowws 8, читайте .
Два типа, использующихся для удалённой работы в PowerShell 2.0
Пора сообщить, что существуют два варианта удалённой работы в PowerShell 2.0.
Первый способ - это более изощрённая вариация, в которой используются командлеты, создавая устойчивый канал ко второй машине. Имена таких команд содержат в качестве существительного слово "PSSession" (напоминаю, что имена командлетов строятся по правилу "Глагол-Существительное"). Получить перечень этих командлет можно с помощью такой команды:
Get-Command -noun PSSession
Второй способ - это так же более каноническая форма удалённой работы PowerShell 2.0. Данный способ просто расширяет локальные команды, добавляя к ним параметр "-computerName", с помощью которого указывается удалённо расположенный компьютер, на котором необходимо выполнить операцию. В результате, такие команды будут запущены на другой машине, находящейся в сети:
Get-Process -computerName machine2
Перечень командлет, которые можно использовать таким простым способом (т.е. тех, что имеют в своём составе параметр "-computerName") можно получить с помощью такой команды:
Get-command | where { $_.parameters.keys -contains "ComputerName"}
Полный же перечень командлет, которые могут работать по второму способу, можно получить так:
Get-command | where { $_.parameters.keys -contains "ComputerName" -and ($_.parameters.keys -notContains "Session")}
Подводим итог об удалённой работе в PowerShell 2.0
Секрет в том, чтобы удалённо работать с помощью PowerShell 2.0 в том, что нужно понять основные вещи:
Следует установить WinRm.
С помощью команды Enable-PSRemoting необходимо разрешить удалённое взаимодействие.
Нужно выполнить настройку TrustedHosts (например задать ей в качестве значения *).
В случае использования команды Enter-PSSession, следует не забывать указывать полностью определённое имя узла или же его IP-адрес.
Англоязычный источник изложенной и немного переработанной мною информации .
# Создаём новую сессию подключения к удалённой машине $s = New-PSSession -computername TestComputer
# Выполняем на удалённой машине произвольные действия, например - смотрим содержимое каталога C:
Invoke-Command -Session $s -ScriptBlock {ls c:\}
# Создаём на удалённой машине каталог "%ProgramFiles%\MyCompany\MySoft"
Invoke-Command -Session $s -ScriptBlock {New-Item -Path "$env:ProgramFiles\MyCompany\MySoft" -ItemType directory}
# Однако, гораздо удобней не вручную вбивать команды, а запускать на удалённой машине уже готовый скрипт:
Invoke-Command -Session $s -FilePath "\\ServerDir\Common Scripts\MyScript.ps1"
# Завершаем сессию
$s | remove-PSSession
Резюме : Знакомство с удаленным управлением в Windows PowerShell.
Weekend Scripter: Включаем удаленное управление Windows.
Microsoft Scripting Guy, Ed Wilson на связи. Сегодня я собираюсь опубликовать отрывок из моей новой книги Windows PowerShell 3.0 Step by Step , издаваемой Microsoft Press. Сейчас эта книга доступна для предварительного заказа.
WinRM – Удаленное управление Windows
В Windows Server 2012 WinRM запущен по умолчанию для поддержки выполнения удаленных команд Windows PowerShell. WinRM это имплементация корпорацией Microsoft промышленного стандарта WS-Management Protocol. Поэтому WinRM предоставляет удобный способ доступа к удаленным системам с точки зрения требований к настройке файрвола. Это тот механизм, который используют новые CIM-командлеты. Таким образом, вы можете в любое время подключиться к работающей машине на Windows Server 2012 для запуска команд или открытия интерактивной консоли Windows PowerShell. На Windows 8, с другой стороны, WinRM по умолчанию отключена. Это означает, что первое, что необходимо сделать, это запустить командлет Enable-PSRemoting . При запуске этого командлета происходят следующие шаги:
1. Запускается или перезапускается служба WinRM.
2. Тип запуска службы WinRM устанавливается в автоматический.
3. Создается прослушиватель (listener) для приема подключений по всем IP-адресам.
4. Включается исключение файрвола для трафика WS-Man.
5. Активируется конфигурация Microsoft.powershell
6. Активируется конфигурация Microsoft.powershell.workflow
7. Активируется конфигурация Microsoft.powershell32
В течение этого процесса, функция запрашивает подтверждения на выполнение каждого из действий. Если вы знакомы с действиями, выполняемыми функцией и не собираетесь вносить в ее работу каких-либо изменений, вы можете запустить эту команду с ключом –Force и в этом случае запросы подтверждений выводиться не будут. Синтаксис этой команды приведен ниже.
Enable-PSRemoting –Force
Теперь приведем пример использования функции Enable-PSRemoting в интерактивном режиме, включая всю выводимую информацию.
PS C:\> Enable-PSRemoting
WinRM Quick Configuration
Running command «Set-WSManQuickConfig» to enable remote management of this computer by using the Windows Remote Management (WinRM) service. This includes:
1. Starting or restarting (if already started) the WinRM service
2. Setting the WinRM service startup type to Automatic
3. Creating a listener to accept requests on any IP address
4. Enabling Windows Firewall inbound rule exceptions for WS-Management traffic (for http only).
Do you want to continue?
WinRM has been updated to receive requests.
WinRM service type changed successfully.
WinRM service started.
WinRM has been updated for remote management.
Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
WinRM firewall exception enabled.
microsoft.powershell SDDL:
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is «Y»):y
Are you sure you want to perform this action?
Performing operation «Set-PSSessionConfiguration» on Target «Name:
microsoft.powershell.workflow SDDL:
O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD). This will
allow selected users to remotely run Windows PowerShell commands on this computer».
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is «Y»):y
Are you sure you want to perform this action?
Performing operation «Set-PSSessionConfiguration» on Target «Name:
microsoft.powershell32 SDDL:
O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD). This will
allow selected users to remotely run Windows PowerShell commands on this computer».
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is «Y»):y
После того как конфигурация выполнена, можно проверить работоспособность WinRM при помощи командлета Test-WSMan . Если система сконфигурирована верно, выводится информация, подобная следующей.
PS C:\> Test-WSMan -ComputerName w8c504
ProductVersion: OS: 0.0.0 SP: 0.0 Stack: 3.0
Этот командлет также работает с компьютерами с Windows PowerShell 2.0. Пример, приведенный ниже, иллюстрирует запрос к контроллеру домена на Windows Server 2008 с установленным Windows PowerShell 2.0, на котором был сконфигурирован WinRM.
PS C:\> Test-WSMan -ComputerName dc1
wsmid: http: //schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion: http: //schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor: Microsoft Corporation
ProductVersion: OS: 0.0.0 SP: 0.0 Stack: 2.0
Если WinRM не сконфигурирован, будет возвращено сообщение об ошибке. В случае операционной системы Windows 8, сообщение будет следующим.
PS C:\> Test-WSMan -ComputerName w8c10
Test-WSMan:
xmlns:f=»http: //schemas.microsoft.com/wbem/wsman/1/wsmanfault» Code=»2150859046″
Machine=»w8c504.iammred.net»>WinRM cannot complete the operation. Verify
that the specified computer name is valid, that the computer is accessible over the
network, and that a firewall exception for the WinRM service is enabled and allows
access from this computer. By default, the WinRM firewall exception for public
profiles limits access to remote computers within the same local subnet.
At line:1 char:1
Test-WSMan -ComputerName w8c10
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CategoryInfo: InvalidOperation: (w8c10:String) , InvalidOperationException
FullyQualifiedErrorId: WsManError,Microsoft.WSMan.Management.TestWSManCommand
Стоит помнить о том, что включение удаленного управления командлетом Enable-PSRemoting не активирует исключение файрвола Remote Management, поэтому попытка пропинговать машину с Windows 8 успехом не увенчается.
PS C:\> ping w8c504
Pinging w8c504.iammred.net with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.0.56:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss).
В случае же с Windows Server 2012 все работает.
PS C:\> ping w8s504
Pinging w8s504.iammred.net with 32 bytes of data:
<1ms TTL=128
Reply from 192.168.0.57: bytes=32 time<1ms TTL=128
Reply from 192.168.0.57: bytes=32 time<1ms TTL=128
Reply from 192.168.0.57: bytes=32 time<1ms TTL=128
Ping statistics for 192.168.0.57:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
Это все, что касается включения WinRM.
Ed Wilson, Microsoft Scripting Guy
Оригинал: