Работа с удаленными компьютерами с помощью NETSH

Netsh позволяет работать с удаленными компьютерами. Для операций в интерактивном режиме нужно запустить netsh с параметром -R и указать IP-адрес или доменное имя компь­ютера, к которому вы хотите подключиться, например:

netsh -г 192.168.10.15 или netsh -г comp1

Если вы работаете с удаленным компьютером, Netsh добав­ляет в приглашение командной строки IP-адрес или имя это­го компьютера:

[comp1] netsh>

Для работы в неинтерактивном режиме с удаленным ком­пьютером предназначен следующий синтаксис:

netsh -с Контекст -г Удаленный Компьютер Команда, где

• Контекст — это идентификатор нужного контекста,
• Уда­ленный Компьютер — имя или IP-адрес удаленного компью­тера,
• Команда — команда, которую нужно выполнить.

Пример команды NETSH — получение списка IP-адресов

Рас­смотрим пример: netsh -с «interface ip» -г corpsvr02 show ipaddress

В этом примере вы получаете список IP-адресов, настроен­ных на CorpSvr02, с применением контекста IP-интерфейса. Здесь контекст RPC не годится, так как он доступен только на локальном компьютере.

Netsh требует наличия в сети сконфигуриро­ванной службы маршрутизации и удаленного доступа. А точнее, вы должны настроить политику удаленного доступа Connections То Other Access Servers, чтобы предоставить разрешение на удаленный доступ. Также убедитесь, что служба удаленного доступа работает.

Работа с файлами сценариев с помощью NETSH

Как обсуждалось ранее, вы можете ввести полную последова­тельность команд Netsh в командной строке или в сценарии. Подвох в том, что вы должны знать полную командную стро­ку, которую собираетесь использовать, и не можете положиться на подсказку Netsh. Некоторые командные строки могут быть очень длинными и сложными. Например, следующие коман­ды выполняют подключение к DHCP-серверу, настраивают DHCP-область, а затем активизируют эту область:

• netsh dhcp server \\corpsvr02 add scope 192.168.1.0 255.255.255.0 MainScope PrimaryScope
• netsh dhcp server \\corpsvr02 scope 192.168.1.0 add iprange 192.168.1.1 192.168.1.254
• netsh dhcp server \\corpsvr02 scope 192.168.1.0 add excluderange 192.168.1.1 192.168.1.25
• netsh dhcp server \\corpsvr02 scope 192.168.1.0 set state 1

Если вы сохраните эти команды в сценарий, то сможете запустить его, как любой другой сценарий. Например, присво­ив сценарию имя dhcpconfig.bat, просто введите dhcpconfig для запуска этого сценария.

При работе с удаленным компьютером сценарий можно по­местить в общую сетевую папку, доступную с удаленного ком­пьютера, а затем удаленно подключиться к этому компью­теру для запуска сценария. Или скопировать сценарий не­посредственно на удаленный компьютер и, подключившись к нему, удаленно запустить сценарий. Годятся оба способа, но они требуют дополнительных усилий.

Есть более быстрый способ запустить сценарий на удаленном компьюте­ре. Для этого вы должны немного изменить сценарий и исполь­зовать синтаксис:

• netsh -с Контекст -г УдаленныйКомпыотер -f Сценарий

1000++ способ запуска команд на удаленном компьютере

В наше время даже для собак придумали удаленное управление.

Возвращаясь к циклу «Конспект Админа», мне хотелось бы рассказать о вариантах запуска исполняемых программ на удаленных компьютерах. Эта статья будет интересна тем, у кого еще нет систем централизованного управления, но уже есть понимание утомительности ручного обхода рабочих станций и серверов. Либо тем, кому решения «под ключ» не интересны ввиду неспортивности.

В качестве того, зачем нужен такой запуск программ, можно привести недавнюю истерию с Петей\Не-Петей, когда все бросились проверять\отключать SMBv1 и загружать обновления. Да и провести инвентаризацию или установить срочный патч таким методом тоже можно.

Когда-то давно я устроился работать в организацию в период эпидемии Kido\Conficker. Наиболее простым способом выяснить, все ли хорошо в ИС компании, была славная утилита от Касперского под названием Kido Killer, которая проверяла наличие вируса и устраняла его. Запускать программу на доброй сотне машин руками было невесело, поэтому пришлось знакомиться с автоматизацией.

Если в операционных системах *nix для удаленного запуска, как правило, используется SSH, то у Windows способов запуска программ и скриптов воистину как песка в пустыне. Я разберу основные варианты, как общеизвестные, так и экзотические. Таких очевидных вещей как telnet-сервер касаться не буду, тем более Microsoft уже убрала его из современных ОС.

Способы старые, временем проверенные

Psexec

Пожалуй, это первое, что приходит на ум, когда идет речь об удаленном запуске программ. Утилита от Марка Руссиновича используется еще со времен Windows NT и до сих пор применяется. Помимо основной функции, можно использовать ее и как Runas, и для запуска программ в пользовательской сессии терминального сервера. Psexec также позволяет задавать ядра процессора, на которых будет запускаться программа, и ее приоритет в системе.

В качестве примера посмотрим, установлено ли обновление, закрывающее нашумевшую уязвимость SMB на списке компьютеров:

В файле computers.txt находится список компьютеров. Для запуска по всему домену можно использовать \\*. В файле \\server\share\log.txt будут появляться имена рабочих станций или серверов без обновления. Если в домене существуют компьютеры с *nix на борту или нет доступа к административному сетевому ресурсу Admin$ ― команда на этой машине не выполнится, но обработка продолжится. Чтобы скрипт не зависал при каждой попытке подключения, можно задать тайм-аут с помощью ключа -n.

Если компьютер выключен ― мы об этом не узнаем. Поэтому лучше предварительно проверять доступность машин или собирать в файле информацию об успешном или неудачном выполнении.

К минусам Psexec можно отнести то, что она из-за своего удобства и популярности часто используется вирусописателями. Поэтому антивирусные системы могут обнаруживать утилиту как опасность вида remote admin.

По умолчанию процесс на удаленной машине выполняется от имени пользователя, запустившего Psexec. При необходимости логин и пароль можно задать явно или же использовать аккаунт SYSTEM.

Для управления системами Windows с помощью разных графических утилит часто используется WMI (Windows Management Instrumentation) ― реализация объектно-ориентированного стандарта управления WBEM. В качестве утилиты с графическим интерфейсом для работы с WMI можно использовать wbemtest.exe.

Для работы с WMI из консоли создана wmic.exe. Например, для проверки установленных обновлений вместо жутковатой конструкции из предыдущего примера можно использовать простую команду:

Использовать список компьютеров также можно командой /node:»@computers.txt».

Еще при помощи WMI можно запускать программы – синтаксис предельно прост:

К сожалению, в отличие от Psexec, получить вывод в консоли не получится ― придется выводить результаты команды в файл.

По умолчанию процесс на удаленной машине выполняется от имени пользователя, запустившего wmic. При необходимости логин и пароль можно задать явно.

Групповые политики и скрипты

Если предыдущие варианты не требовали доменной среды, то в этом случае потребуется домен. Поддерживаются скрипты при входе и выходе пользователя из системы, а также при ее включении и выключении. Поскольку каждый администратор Windows сталкивался с ними, я не буду подробно расписывать как ими пользоваться ― лишь напомню, где их искать.

Скрипты, выполняющиеся при старте и завершении системы.

Скрипты, выполняющиеся при входе и выходе пользователя из системы.

Скрипты, настраиваемые в пользовательском разделе, выполняются от имени пользователя, а в разделе компьютера ― под аккаунтом SYSTEM.

Назначенные задания

Довольно интересный способ, заслуживающий право на жизнь. Назначенные задания можно создавать из командной строки при помощи утилиты schtasks.exe, выполнять их, затем удалять. Подробнее с синтаксисом можно ознакомиться в документации, я же разберу пример использования назначенных заданий в доменной среде. Предположим, нам нужно выполнить команду как можно быстрее вне зависимости от того, выключен компьютер или нет. Для этого используются так называемые предпочтения групповых политик (Group Policy Preference).

Искать установку назначенных заданий следует в конфигурации компьютера или пользователя ― «Настройка ― Параметры панели управления ― Назначенные задания».

Создание нового назначенного задания.

Для выполнения команды или скрипта ASAP понадобится создать «Немедленную задачу (Windows 7 и выше)». Если вдруг в инфраструктуре остались машины под управлением Windows XP, то подойдет «Очередное задание (Windows XP)».

Стоит сделать несколько политик с соответствующими WMI-фильтрами или создать два разных назначенных задания в одной политике с нацеливанием ― например, при помощи того же WMI-фильтра. Это поможет избежать конфликтов в разнородной среде со старыми и новыми Windows.

Пример WMI-фильтра для применения политики только на компьютерах с Windows XP:

В остальном процедура создания назначенного задания тривиальна. Единственное, не забывайте отметить пункт «Применить один раз и не применять повторно», если задача не требует повторного запуска.

Запускаем немедленную задачу только один раз.

При использовании таких назначенных заданий программа запустится, как только компьютер получит обновление групповой политики. Это удобно: не нужно проверять доступность компьютеров в случае Psexec и wmic и заставлять пользователей перезагружать машины, как в случае скриптов групповых политик. При необходимости можно скопировать файл скрипта локально в разделе «Настройка ― Конфигурация Windows ― Файлы».

Назначенные задания позволяют явно задать имя пользователя для запуска программы, в том числе и для SYSTEM.

Через реестр

Модификация реестра на пользовательских машинах ― странный вариант, лишь на случай крайней необходимости. Можно использовать ветки Run или RunOnce. Подробнее о них ― в документации. Сама модификация реестра может проводиться через групповые политики или из командной строки ― например, такой командой:

В зависимости от ветки реестра, процесс будет выполняться или под пользователем, выполнившим вход в систему, или под аккаунтом SYSTEM.

Есть и другие способы, такие как правка ярлыков в папке «Автозагрузка» или добавление в ярлык к популярной программе && script.cmd, но эти методы уже из серии «можно, но не нужно».

Теперь перейдем к новым инструментам.

Способы новые или куда же без PowerShell

PowerShell, оправдывая свое название, может подключаться к удаленным компьютерам при помощи WMI, RPC и WS-Management (WSMan). Использование последнего метода требует предварительной настройки.

Командлеты, не требующие предварительной настройки, как правило, имеют параметр ComputerName, но не имеют параметра Session. Посмотреть список таких командлетов можно командой:

Для настройки WSMan в общем случае достаточно выполнить команду Enable-PSRemoting-Force. Она запустит службу удаленного управления WinRM и пропишет исключения в фаерволе ― в принципе, это можно сделать для всего домена при помощи групповых политик. Подробнее настройка описана в документации.

После того как все компьютеры будут готовы принимать запросы, мы сможем подключаться при помощи соответствующих командлетов PowerShell. Для проверки возможности подключения используется командлет Test-WSMan.

Проверка возможности подключения.

Для того чтобы выполнить определенную команду или скрипт, используется командлет Invoke-Command со следующим синтаксисом:

Где COMPUTER ― имя компьютера, COMMAND ―– имя команды, а USERNAME ― имя пользователя, если оно нужно.

Смотрим содержимое диска С удаленного компьютера.

Если же нам нужно получить полноценную консоль ― не автоматизации ради, а ради управления конкретным компьютером, ― то можно использовать командлет Enter-PSSession.

Работаем в консоли удаленного компьютера.

Напомню, что с помощью JEA можно ограничить доступные подобной сессии командлеты или дать доступ нужным без прав администратора.

Конечно, кроме встроенных средств и небольших утилит, существует множество программ для управления структурой. Помимо взрослых решений, для управления конфигурациями вроде Chef, Ansible и MS SCCM можно использовать и средства мониторинга вроде Zabbix, и даже консоль управления антивирусом Касперского.

В период гетерогенных структур хорошо бы иметь возможность унифицированного управления Windows и Linux. Это можно сделать и с помощью PowerShell, что само по себе достойно отдельной статьи ― стоит такую сделать или уже лишнее?

Кстати, поделитесь вашими способами скрытого и не очень запуска программ на удаленных компьютерах. Ну, за исключением эксплойтов.

Windows/Удалённое управление

Для выполнения команд на удалённом ПК можно использовать утилиту psexec из набора PsTools, который можно скачать с официального сайта Microsoft.

Содержание

Запуск командной строки на удалённом ПК

Для подключения можно использовать IP адрес или имя компьютера:

или если хотим подключиться не от имени текущего пользователя, то:

Если ПК не в домене, то вместо «Домен» указываем имя ПК.

После удачного подключения изменится заголовок окна.

Переименование удалённого ПК

Текущее имя ПК можно увидеть через запрос к значению в реестре:

Изменяем в реестре имя ПК на New-PC-Name:

reg add «HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters» /v ComputerName /t REG_SZ /d «New-PC-Name» /f

Для вступления в силу нового имени нужно перезагрузить компьютер:

Здесь мы дали пользователю 3 минуты (180 секунд) на закрытие документов, но можно этот параметр изменить в соответствии со случаем.

Отключение брандмауэра

Отключаем брандмауэр для всех профилей сети:

Включение удалённого рабочего стола

Проверить есть ли доступ к удалённому рабочему столу можно с помощью команды telnet, попробовав подключиться к соответствующему порту. Для Windows штатным является подключение по протоколу RDP на порт 3389 (хотя, конечно, и порт для RDP можно изменить и использовать другие протоколы). В случае открытого порта (подключения разрешены) мы увидим приглашение командной оболочки telnet:

Trying 192.168.2.68. Connected to 192.168.2.68. Escape character is ‘^]’.

Если же подключение запрещено, то команда зависнет на этапе «Trying 192.168.2.68. «

Даже если удалённое подключение к рабочему столу отключено его можно удалённо же и включить, а затем подключиться как обычно. Для этого внесём изменение в реестр удалённого ПК.

Если мы получили доступ к командной строке удалённого ПК (см. PsExec выше), то выполняем:

Иначе, можно подключиться к реестру через оснастку.

1) Запускаем на удалённом ПК службу «Удаленный реестр«.

• Входим в локальную оснастку «Службы»:

• Подключаемся к службам удалённого ПК: в боковом меню Службы в контекстном меню выбрать «Подключиться к другому компьютеру. «
• Находим службу «Удаленный реестр» и меняем тип запуска на «Вручную»
• Запускаем службу: кнопка «Запустить»

2) Подключаемся к реестру удалённого ПК.

• На локальном ПК запускаем редактор реестра:

• В верхнем меню выбираем: Файл — Подлкючить сетевой реестр.
• Вводим имя ПК, нажимаем «ОК» и должен появиться дополнительный куст с именем ПК и двумя ветками: HKEY_LOCAL_MACHINE и HKEY_USERS
• Спускаемся по веткам до HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
• Меняем параметр fDenyTSсonnections с 1 на 0

3) Если подлкючиться не удаётся, то нужно ещё донастроить брандмауэр на удалённом ПК

• Получаем досутп к командной строке удалённого ПК с помощью PsExec:

• Добавляем разрешающее правило в брандмауэр Windows на удалённое подключение к рабочему столу (порт 3389):

Добавление пользователя в локальную группу

1) Если у нас есть возможноть удалённого управления ПК, то проще всего запустить на локальном ПК Оснастку управелния компьютером

и подключиться к удалённому ПК:

1. Щёлкнуть правой клавишей мышы по корневому пункту бокового меню «Управление компьютером» и выбрать в контекстном меню пункт «Подключиться к другому компьютеру. «
2. Ввести имя или IP адрес ПК или нажать «Обзор. » и поискать в домене

После подключения выбрать в боковом меню: Локальные пользователи и группы — Группы

И добавить нужных пользователей в нужную группу.

2) Если возможности удалённого управления нет, то можно попробовать его получить отключив брандмауэр на удалённом ПК и включив на нём службу «Удаленный реестр» (см. выше). Или получив с помощью утилиты psExec доступ к командной строке на удалённом ПК управлять пользователями и группами через командную строку.