Способы удаленного управления и выполнения команд на Windows хостах
Сергей «grinder» Яремчук (grinder@synack.ru)
Инструментарий, позволяющий выполнить команду на удаленных системах, существенно упрощает работу админа. Не покидая рабочего места, можно запустить сервис, изменить настройки, диагностировать и исправить проблему. Популярность задачи обуславливает множество вариантов ее решения.
Содержание:
- Админ должен быть ленив!
- Cамый простой вариант подключения — по RDP
- Попурри из консолей и тулкитов
- Служба удаленного управления WinRM
- PowerShell Remoting
- Утилита PsExec
- Инструментарий для управления Windows
- Заключение
- Боковые выносы
Функции удаленного управления, реализованные в WinNT, были весьма ограничены и нагоняли тоску даже на прыткого админа. Большинство операций приходилось выполнять за локальной консолью, и это, кстати, во времена, когда в Unix вообще не чувствовалось разницы, с каким сервером ты сейчас работаешь — удаленным или локальным. Но с каждой новой версией и сервис-паком возможности ОС расширялись, и в настоящее время количество доступных решений возросло на порядок. Администратор может управлять системами при помощи сценариев WSH (Windows Script Host) и PowerShell, командной строки WinRS (Windows Remote Shell), консоли MMC (Microsoft Management Console), программного интерфейса WMI (Windows Management Instrumentation), групповых политик и средств удаленного доступа к рабочему столу RDP (Remote Desktop Protocol). Этот список можно дополнить инструментами и утилитами сторонних разработчиков, но сегодня хотелось бы подробно остановиться именно на штатных возможностях, поскольку заложенного функционала с головой хватает для решения большинства административных задач в малых и средних сетях, и, что немаловажно, за них не нужно отдельно платить.
Cамый простой вариант подключения — по RDP
Пользователь, подключившийся к удаленному компьютеру по протоколу RDP, получает практически те же возможности, что и при работе за локальной системой — доступ к программам, дискам, сети, печати, звуковым устройствам и т.п. В Vista, помимо улучшений в отображении шрифтов и поддержки 32 разрядной картинки, появилась очень удобная функция растягивания рабочего стола удаленного компьютера на все мониторы, подключенные к локальной системе (mstsc /span). Версия RDP 7, анонсированная в Win7/2k8R2, добавила еще ряд возможностей, например, появилась поддержка Aero, Direct2D и Direct3D в приложениях.
Клиенты для подключения по RDP имеются в большинстве популярных ОС – они встроены в Windows (в том числе Windows CE и Mobile), Linux, xBSD, Mac OS X и некоторые другие. В частности, терминальный клиент официально поддерживает все ОС вплоть до Win2k8 (с подключением к Win2k8R2 проблем также не будет). В Linux в паре с rdesktop удобнее использовать графическую оболочку Gnome-RDP или KDE Remote Desktop Client. Еще одна надстройка — — фактически позволяет «встроить» в рабочий стол Linux приложения из Windows. При его использовании вместо традиционной рамки с рабочим столом удаленной системы на десктопе появляется панель задач, а приложения открываются в отдельном окне. При желании можно сделать так, что пользователь даже не заметит «подмену» ОС.
В режиме администрирования клиентские версии ОС поддерживают работу только одного пользователя (локального или удаленного). Для его активации достаточно в «Свойства» компьютера — «Удаленные сеансы» установить флажок «Разрешить удаленный доступ к этому компьютеру» и указать учетные записи, которым разрешен доступ. При подключении к системе администратора пользователь будет отключен. То есть показать, как правильно выполнить некоторую операцию, весьма проблематично, можно лишь произвести действия по настройке, после чего отдать управление обратно пользователю. Для помощи в настройках удаленному пользователю и одновременной консультации в режиме чата или голосового общения следует использовать Remote Assistance (Удаленный помощник). Он также позволяет взять управление системой, но с разрешения пользователя.
Серверные версии поддерживают два удаленных подключения, плюс локальное. Режим работы Terminal Server mode уже требует дополнительного лицензирования и предназначен для удаленной работы с приложениями, а не администрирования систем.
В Win2k8 появились новые вкусности для обеспечения доступа к удаленной системе по RDP. К ним можно отнести службы TS RemoteApp (удаленные приложения RemoteApp служб терминалов) и Terminal Services Web Access (обеспечивает и контролирует доступ к RemoteApp программам или рабочим столам компьютеров офисной сети через браузер). Первая устанавливается как часть роли сервера терминалов Win2k8. Администратор создает и распространяет специальный RDP файл, щелчком по которому пользователь может запустить удаленное приложение (поддерживается Win2k3SP1, WinXPSP2 и выше). Это приложение будет выполняться в отдельном окне и внешне ничем не отличаться от локальной программы. Чтобы избавить удаленных пользователей от необходимости подключения к RDP через VPN, администратор может настроить Terminal Services Gateway.
Попурри из консолей и тулкитов
Во времена Win2k для удаленного администрирования по безопасному каналу Microsoft предлагала использовать службу Remote Command Service (Rcmd.exe). Серверная часть Rcmdsvc.exe устанавливалась в качестве службы и обеспечивала одновременное подключение до 10 клиентов, а управление производилось при помощи командной консоли Rcmd.exe.
Для Win2k3 стал доступен Administration Tools Pack, в состав которого вошли 3 ММС консоли, предназначенные для выполнения специфических административных задач: ADMgmt.msc (управление Active Directory), PKMgmt.msc (сертификаты и ключи), IPAddrMgmt.msc (IP-адреса, DHCP, DNS, WINS). Активация пункта Remote Administration (HTML) в настройках IIS дает возможность удаленно управлять сервером при помощи веб-браузера (порт 8098).
В Win2k8 появился новый инструмент управления сервером — Server Manager, являющийся, по сути, универсальным центром, куда добавляются все роли и функции по настройке сервера. Правда, возможность подключения к другому серверу появилась в Server Manager лишь в Win2k8R2. Оснастки MMC в Win2k8, предназначенные для удаленного управления, объединены в компонент Средства удаленного администрирования сервера (RSAT, Remote Server Administration Tools), и большая часть из них в Win2k8 по умолчанию не устанавливается. Кроме этого, свой RSAT есть и для Vista/Win7, он в свободном доступе лежит на сайте Microsoft. C его помощью можно управлять из Vista/Win7 ролями и компонентами на серверах, работающих под управлением Win2k3/2k8/2k8R2.
Напомню, что консоль MMC позволяет подключаться, управлять удаленной системой и следить за ее состоянием. Для этого необходимо лишь добавить оснастку Управление компьютером (Computer Management) и затем в новом окне выбрать управление другим компьютером (Another Computer).
Кстати, многие консольные утилиты, входящие в стандартную поставку Windows, умеют выполнять команды на удаленных системах. Например, запустим утилиту SC и получим список сервисов на компе \\synack:
> SC \\synack query type= service state= all
Планировщик заданий (Task Scheduler) также имеет параметр «/s», при помощи которого задается целевая машина, где будет выполнено задание, что делает его весьма полезным инструментом.
Рис. 1. Подключаемся в MMC консоли к удаленной системе
Служба удаленного управления WinRM
Первая версия службы удаленного управления WinRM появилась в Vista/Win2k8 и является Microsoft-вариантом реализации протокола Web Services for Management (WS-Management Protocol), позволяющего управлять локальными и удаленными системами посредством XML сообщений. Запущенная служба WinRM предоставляет доступ ко всем WMI данным (о них ниже), но в более удобной форме. Первая версия использовала стандартные порты HTTP/HTTPS, что делало ее дружелюбной для брандмауэров и позволяло подключиться к удаленной системе практически с любого компьютера, имеющего доступ к сети. В WinRM 2.0 по умолчанию для удаленного доступа используются порты с номерами 5985/5986, плюс для локального — 47001/TCP. Хотя при необходимости можно достаточно просто вернуть стандартные 80/443.
В целях безопасности весь трафик по умолчанию шифруется, поэтому команды и пароли нельзя подсмотреть, аутентификация производится с использованием Kerberos (возможно CredSSP). Причем все компьютеры должны входить в домен.
В Win2k8R2 и Win7 включен последний релиз WinRM 2.0. Для WinXPSP3/2k3SP2/VistaSP1/2k8/2k8SP2 эту версию можно установить при помощи пакета (Windows PowerShell 2.0, WinRM 2.0, BITS 4.0). Установка тривиальна и не должна вызвать трудностей.
Чтобы служба WinRM могла принимать сетевые запросы, ее нужно предварительно настроить:
> winrm quickconfig
Отвечаем на ряд вопросов, после чего сервис WinRM устанавливается в автозапуск, активируется прослушивание портов 5985/5986, а также перестраиваются правила Windows Firewall. Чтобы WinRM прослушивал порты 80/443, просто изменим его настройки:
> winrm set winrm/config/service \
@{EnableCompatibilityHttpListener="true"}
> winrm set winrm/config/service \
@{EnableCompatibilityHttpsListener="true"}
Еcли в последствии будут обнаружены проблемы с подключением, смотрим вывод команд «winrm enumerate winrm/config/listener» и «winrm get winrm/config». Кстати, веб-сервер и WinRM, прослушивающие 80 порт, не будут друг другу мешать: все дело в том, что для WinRM зарезервировано размещение "/wsman", поэтому на веб-сервере следует избегать использования такого URL.
Рис. 2. Просматриваем установки WinRM
Другим вариантом настройки является использование групповых политик. Нужные установки найдешь в «Конфигурация компьютера — Политики — Административные шаблоны — Компоненты Windows — Удаленное управление Windows» (Computer Configuration — Administrative Templates — Windows Components — Windows Remote Management). Здесь два подпункта, в которых производятся соответственно настройки клиентов WinRS и сервера WinRM. Например, в «Разрешить автоматическую настройку прослушивателей» (Allow automatic configuration of listeners) можно задать диапазон IP-адресов, с которых разрешены подключения.
В консоли такие системы добавляются в TrustedHosts:
> winrm set winrm/config/client @ {TrustedHosts="synack"}
Соответственно, чтобы просмотреть настройки, используем аргумент get:
> winrm get winrm/config/client
Клиентская часть заключена в консольной утилите WinRS. По умолчанию команды выполняются на текущем узле, но стоит добавить параметр ‘-r‘, и можно подключиться к удаленной системе:
> winrs -r:synack cmd.exe > hostname synack > ipconfig
В итоге мы получаем нечто вроде SSH сессии, отлично защищенной и позволяющей управлять удаленным компьютером. Утилита WinRS использует оболочку cmd, в чем нетрудно убедиться, просмотрев список доступных команд по «winrs help».
Конечно же, команду можно задать и сразу, не вызывая напрямую оболочку cmd:
> winrs -r:synack "dir C:"
По умолчанию используется протокол HTTP, но перейти на HTTPS очень просто:
> winrs -r:https://synack "tasklist"
Рис. 3. Настройка работы службы удаленного управления при помощи групповых политик
Одним из главных нововведений командной оболочки PowerShell версии 2.0 стало удаленное выполнение команд — Remoting. В основе этой фичи лежит WinRM 2.0, все возможности которого используются по полной программе: подключение к системам через прокси-сервера, работа по стандартным портам HTTP/HTTPS, шифрование передаваемых данных с использованием SSL и т.д. Что интересно, PowerShell Remoting позволяет не просто выполнять команды на одном или множестве удаленных хостов (параллельно или последовательно), но и отслеживать их выполнение, получать результаты их работы.
При первом запуске PowerShell скрипта, скорее всего, появится сообщение о том, что выполнение PowerShell скриптов на данной системе заблокировано, и дается рекомендация набрать «get-help about_signing». Все дело в политиках. Смотрим текущее положение дел:
PS C:\> Get-ExecutionPolicy Restricted
В таком варианте сможем запускать лишь отдельные команды, выполнение сценариев запрещено. Установим "RemoteSigned":
PS C:\> Set-ExecutionPolicy RemoteSigned
Подтверждаем запрос на изменение политики.
Подготовить систему для удаленного управления достаточно просто, вводим в консоли PowerShell:
PS C:\> Enable-PSRemoting
Будет запрошено подтверждение на выполнение ряда операций (ключ ‘-Force‘ запустит без подтверждений). После этого автоматически будет сконфигурирован сервис WinRM на автозапуск, созданы исключения в правилах WF (аналогичные «winrs quickconfig», точнее Set-WSManQuickConfig), создан прослушиватель HTTP для приема WS-Management на любом из IP-адресов компьютера.
При необходимости отключить возможность удаленного управления также просто:
PS C:\> Disable-PSRemoting
Для проверки работы удаленного управления можно использовать, например, командлет Test-WSMan:
PS C:\> Test-WSMan -ComputerName synack.ru
Теперь у нас два варианта выполнения PS командлетов на удаленной системе: интерактивный и командный. В первом случае, используя командлет Enter-PSSession, подключаемся к PowerShell сессии на удаленной системе:
PS C:\> Enter-PSSession synack.ru
Теперь можем вводить команды, получать ответ, то есть работать как за локальной консолью. Чтобы отключиться от удаленной системы, набираем exit или Exit-PSSession.
Чтобы выполнить команду на одном или нескольких удаленных компьютерах, используется командлет Invoke-Command. Список систем можно передать как непосредственно в командной строке, так и прописать их в текстовом файле (удобно в том случае, если их много). Например, получим список процессов на удаленной системе:
PS C:\> Invoke-Command -ComputerName synack.ru \
-ScriptBlock {Get-Service | Format-List}
Допускается передача любого количества команд за раз (причем для этого удобно задействовать переменную), что может быть использовано в скриптах и для автоматизации операций. Для примера откроем 445 порт в брандмауэре:
PS C:\> $portcommand = {netsh firewall set portopening tcp 445 smb enable}
PS C:\> Invoke-Command -ComputerName synack.ru -ScriptBlock $portcommand
Кстати, Netsh сам умеет управлять настройками не только локальной, но и одной или нескольких удаленных машин. Достаточно добавить команду «set machine» или ключ ‘–r‘, после чего задать WINS/UNC/DNS имя или IP-адрес:
> netsh -r synack.ru -u administrator -p password diag gui
В итоге получаем HTML-страницу с диагностической информацией (сведения о компьютере, сетевые настройки, список служб интернета), которая может помочь в определении источника проблем.
Рис. 4. Активируем удаленное управление в PowerShell
Утилита PsExec не входит в стандартную поставку ОС, но она достаточно удобна для выполнения большинства задач по администрированию удаленных систем. Найти ее можно в пакете . Чтобы было удобнее вызывать, исполняемый файл лучше скопировать в каталог, доступный через переменную %path% (например, system32). Для выполнения команд на удаленной системе автоматически запускается служба system32\psexesvc.exe, поэтому для работы с PsExec необходимы соответствующие админские права (в домене или локальной системе). После завершения работы данная служба и связанные файлы автоматически удаляются. Общий формат запуска следующий:
psexec \\computer -u user -p passwd command ключи
Если имя пользователя отсутствует, то подразумевается текущая учетная запись. Соответственно, если убрать название компьютера, то команда будет выполнена на локальной системе.
Пример использования:
> psexec \\synack cmd.exe
Все, перед нами консоль удаленной системы. Сессия никак не шифруется, и данные можно перехватить сниффером, поэтому PsExec следует использовать в защищенной среде. Проверка подлинности производится средствами Windows NTLM или Kerberos.
При необходимости можно выполнить команду одновременно на нескольких системах, имена хостов перечисляются через запятую, как вариант, их можно вписать в файл текстового формата, который и указать при запуске:
> psexec @c:\systems.txt shutdown /p /f
Утилита имеет ряд ключей. Так ключ ‘-c‘ позволит скопировать программу с локального диска на удаленную систему перед ее выполнением. Ключ ‘-i‘ запускает программу в интерактивном режиме. Чтобы PsExec «забыл» о запущенной программе сразу после ее выполнения, освободив тем самым консоль, используем ‘-d‘:
> psexec -d \\sysack chkdsk
Теперь на удаленной системе инициируется проверка дисков, а администратор сможет продолжить ввод команд.
Инструментарий для управления Windows
Как следует из названия, WMI также может использоваться для управления и доступа к данным на удаленных системах. Хотя по сравнению с другими методами, рассмотренными ранее, работа с WMI на порядок сложнее. Но сегодня в интернете можно найти большое количество готовых скриптов, позволяющих после некоторой адаптации выполнить практически любую задачу по управлению системами и сбору данных. Кроме этого, следует учитывать, что некоторые команды и параметры специфичны для разных версий ОС, поэтому скрипт, написанный для Win7, в WinXP, возможно, не будет работать должным образом. Для проверки подлинности используется NTLM или Kerberos, по умолчанию удаленное подключение не шифруется, но такая возможность предусмотрена.
Перед началом использования WMI следует запустить MMC консоль DCOMCnfg и разрешить удаленное выполнение DCOM запросов, аналогичные действия производятся и для WMI в wmimgmt.msc. Плюс создаем разрешающее правило Windows Firewall для WMI:
> netsh advfirewall firewall set rule group="windows management \ instrumentation (wmi)" new enable=yes
Возможно несколько вариантов выполнения WMI на удаленной системе. Скрипты здесь рассматривать не будем, это достаточно емкий вопрос. Самый простой способ — использование консольной утилиты Wmic с ключом "/node". Например, получим список учетных записей на удаленном компьютере:
> wmic /node:synack /USER:"username" useraccount list brief
Если нужно выполнить команду сразу на нескольких компьютерах, поступаем аналогично PsExec, то есть перечисляем их через запятую или прописываем в файл.
Просмотрим список процессов и уничтожим «ненужный»:
> wmic /node:synack process list > wmic /node:synack process where(id="679") call terminate
К слову, штатная команда tasklist поддерживает возможность выполнения на удаленной системе. Формат следующий:
tasklist /S <система> /U <домен>\<пользователь>
То есть, чтобы получить список процессов, выполняемых на удаленной машине, можно сделать так:
> tasklist /S \\synack
Рис. 5. Настройка безопасности DCOM
Любители графических морд могут выполнить любую WMI команду с помощью «Тестера инструментария управления Windows». Запускаем Wbemtest.exe, нажимаем «Подключить» (Remote), прописываем данные удаленной системы (\\synack\root\cimv2), выбираем параметры и выполняем запрос.
Рис. 6. Wbemtest - графическая утилита для взаимодействия с WMI
Конечно, это далеко не все варианты удаленного управления и выполнения команд. Не забываем о групповых политиках, которые также позволяют произвести большинство операций по администрированию систем. Многие языки программирования, включая Windows Script Host, .Net и так далее имеют возможности подключения к удаленному компьютеру для выполнения административных операций. Не говоря уже о многочисленных утилитах сторонних разработчиков. Выбирай наиболее подходящий способ и действуй.
INFO
-
О PowerShell читай в статье «Капитан PowerShell и администрирование будущего», опубликованной в сентябрьском номере журнала за 2009 год.
- PowerShell 2.0 по умолчанию входит в состав Win2k8R2 и Win7.
- Впервые поддержка протокола RDP (порт 3389) появилась в WinNT 4.0 Terminal Server.
-
Существует реализация RDP сервера и для Unix систем — . Однако проект не пользуется популярностью, что косвенно подтверждается и тем, что он уже более двух лет не обновлялся.
-
Подключение по RDP работает даже по медленным каналам (если убрать лишние украшательства), а при работе через NAT-устройства, поддерживающие технологию UPnP, сложностей не возникает.
-
При использовании протокола RDP 6 и выше можно подключаться не к виртуальной консоли, а непосредственно к консоли 0, для этого следует запустить терминальный клиент с ключом "/console".
-
Служба Terminal Services Web Access будет также полезна в том случае, если сотрудникам часто приходится подключаться к корпоративным компам и ресурсам из интернет-кафе, имея в своем распоряжении только веб-браузер.
-
WWW
-
Windows Management Framework Core (Windows PowerShell 2.0, WinRM 2.0, BITS 4.0) для WinXP/2k3/Vista/2008 —
- Утилиты Sysinternal —
- Microsoft Script Center —
Статья опубликована в мартовском номере журнала «Xakep» за 2010 год.