Rip listener powershell что это
Настройка удаленного взаимодействия в PowerShell (часть 1)
Чтобы обеспечить возможность удаленного взаимодействия с помощью PowerShell, необходимо произвести некоторые настройки. Количество этих настроек зависит от операционной системы, сетевого окружения, требований к безопасности (и еще бог знает чего). Поскольку настроек довольно много, я попробую рассказать о наиболее важных из них. Ну, поехали…
Включение удаленного управления
Для того, чтобы управлять удаленным компьютером, необходимо на этом компьютере удаленное взаимодействие разрешить. Исключение составляет Windows Server 2012, где все возможности удаленного управления включены по умолчанию. Для всех остальных операционных систем надо:
1. Стартовать службу WinRM и поставить ее на автозапуск;
2. Создать прослушиватель (listener), который будет слушать запросы на управление;
3. Включить на файерволе правило, разрешающее трафик WS-Management.
В доменной среде для настройки PS Remoting можно воспользоваться групповыми политиками.
В разделе Computer Configuration\Policies\Windows Settings\System Services включим политику «Windows Remote Management (WS-Management)». Она задает режим запуска для службы WinRM.
В разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service включаем политику «Allow automatic configuration of listeners», которая создает прослушиватель на порту 5985 (порт для HTTP по умолчанию). Дополнительно можно указать, с каких IP можно принимать подключения. Если в фильтрации по IP нет необходимости, просто ставим знак *, что означает принимать подключения с любого адреса.
Затем идем в раздел Computer Configuration\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Inbound Rules и создаем новое правило. Выбираем пункт Predefined (Предопределенные правила) и в списке выбираем Windows Remote Management.
Обратите внимание, что можно выбрать два режима работы — стандатный и совместимый. В первом случае будет открыт порт 5985, использующийся WinRM по умолчанию, во втором — порт 80 (для совместимости со старыми версиями WinRM). По умолчанию выбраны оба.
Настройка доверия между компьютерами
При удаленном подключении в PowerShell используется взаимная аутентификация между компьютерами. Это означает, что перед установлением соединения удаленная машина должна подтвердить свою подлинность. Проще говоря, если вы подключаетесь к компьютеру с именем SRV1, то перед установкой соединения он (SRV1) должен вам доказать, что это действительно он, иначе подключение не будет установлено.
Если компьютеры являются членами одного домена, или находятся в разных, но доверяющих друг другу доменах, то взаимная аутентификация будет выполнена доменными службами. Главное, чтобы имя компьютера разрешалось в IP-адрес и соответствовало имени компьютера в Active Directory.
Внимание: при подключении нужно указывать действительные имена компьютеров, т.е. так как они указаны в Active Directory. Если компьютер входит в локальный домен, то можно указать просто имя компьютера, например SRV1. Для указания имени компьютера из другого домена надо указать полное доменное имя (FQDN) — SRV1.contoso.com. Если же указать IP-адрес, или некоторое другое DNS-имя (например CNAME алиас), то взаимная аутентификация не сработает.
Если же один или оба компьютера не входят в домен, то для взаимной аутентификации есть два варианта: добавить удаленную машину в список доверенных узлов (Trusted Hosts) или использовать SSL.
Trusted Hosts
Добавление компьютера в Trusted Hosts — путь простой, но менее безопасный. Для компьютеров, находящихся в Trusted Hosts взаимная аутентификация фактически отключена. Поэтому пользоваться этим способом стоит с большой осторожностью.
Добавить компьютер в доверенные узлы можно с помощью PowerShell. Так для того, чтобы создать список доверенных хостов и добавить в него компьютер SRV1 воспользуемся командой:
При добавлении нескольких компьютеров их имена можно перечислить через запятую. Допускается указывать не только имя, но IP-адрес компьютера. Также поддерживаются символы подстановки. Например, можно добавить в доверенные хосты все компьютеры из домена contoso.com, указав значение *.contoso.com, или вообще всех без исключения:
Чтобы добавить имя компьютера в уже имеющийся список доверенных узлов, необходимо сначала сохранить текущее значение в переменной, а затем присвоить значение разделенному запятыми списку, который включает текущее и новое значения. Например, чтобы добавить компьютер SRV2 в имеющийся список доверенных узлов, воспользуйтесь следующей командой:
Ну и посмотреть список доверенных узлов можно командой:
Также для добавления в TrustedHosts можно воспользоваться групповой политикой. В разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Client включаем политику «Trusted Hosts» и добавляем имена или IP-адреса компов через запятую. Поддерживаются подстановочные символы.
Примечание: если TrustedHosts сконфигурированы через GPO, то из PS изменить их не удастся. То же касается и всех остальных настроек PS Remoting.
Подключение с использованием SSL является наиболее защищенным вариантом удаленного взаимодействия. Но по сравнению с остальными способами он довольно сложен в настройке, так что придется немного повозиться.
Во первых, для использования этого метода, нам нужен цифровой сертификат SSL для машины, к которой мы собираемся подключаться. Получение сертификата — отдельная тема, не будем на ней останавливаться. В тестовой среде я воспользуюсь утилитой Makecert, входяшей в состав Windows SDK, и создам самоподписанный сертификат:
Эта команда создаст SSL-сертификат сроком на год и поместит его в хранилище сертификатов локального компьютера. Обратите внимание, что сертификат должен быть выдан на то же имя, которое вы будете указывать в команде подключения.
После получения сертификат должен быть добавлен в Trusted Root Authority (доверенные корневые центры сертификации). Для этого открываем сертификат и жмем на кнопку «Установить сертификат».
Запускается мастер импорта сертификатов. Указываем расположение хранилища «Локальный компьютер».
В качестве хранилища выбираем «Доверенные корневые центры сертификации».
Теперь наш сертификат является доверенным. Еще раз открываем его, и на вкладке «Состав» находим отпечаток сертификата (CertificateThumbprint). Копируем его в буфер обмена.
Теперь можно создавать прослушиватель для HTTPS. Открываем консоль PowerShell и вводим команду:
В поле CertificateThumbrint вставляем отпечаток сертификата, скопированный в предыдущем пункте.
Исключения файерволла Windows (если он включен) для нового прослушивателя необходимо настраивать вручную, автоматически они не создадутся. Поэтому создадим новое правило для входящего трафика по портам TCP 5986 и 443:
Также для создания правила можно воспользоваться графической оснасткой или утилитой командной строки netsh, кому что больше нравится.
Далее идем на компьютер SRV1, с которого будем подключаться. Поскольку я использую самоподписанный сертификат, то его придется добавить к доверенным корневым сертификатам и на клиенте. Копируем файл сертификата myssl.cer на SRV1 и устанавливаем командой:
Вот и все, настройка закончена. Теперь можно подключаться. Откроем интерактивную сессию на wks8 командой:
Обратите внимание, что при подключении по SSL необходимо вводить учетные данные, а также указывать тип подключения. Дальше все как обычно.
Отключение проверки
При подключении по SSL проверяется, что сертификат был выдан доверенным центром сертификации и выпущен именно для этой машины. Проще говоря, имя в сертификате должно соответствовать имени, указанному в команде подключения, а издатель сертификата должен быть в списке доверенных корневых центров сертификации. Если при проверке будет найдено несоответствие с этими условиями, то подключение не состоится.
В принципе это правильно, но при необходимости проверки можно отменить. Для этого в свойствах сессии есть два параметра:
-SkipCACheck — отменяет проверку издателя сертификата;
-SkipCNCheck — отменяет проверку соответствия имени компьютера.
Создать новую сессию с использованием этих параметров можно например вот так:
Правда в этом случае теряется смысл SSL-сертификатов, и тогда уж проще пользоваться Thrusted Hosts. Но возможность такая есть, и знать о ней надо.
Дополнительные настройки
Начиная со второй версии, WinRM по умолчанию слушает порт 5985 для HTTP и 5986 для HTTPS. Для совместимости со старыми версиями (или чтобы не открывать дополнительные порты на брандмауэре) можно дополнительно включить прослушиватели на традиционных портах 80 и 443. Для HTTP:
То же самое можно сделать с помощью групповых политик. Для этого надо в разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service включить политики «Turn On Compatibility HTTP Listener» и «Turn On Compatibility HTTPS Listener».
Порты по умолчанию можно изменить и указать слушать любой нестандартный порт, например порт 8080:
Примечание: установка прослушивателей на нестандартных портах несколько повысит безопасность. Однако имейте в виду, что изменив дефолтный порт, придется каждый раз при подключении указывать его вручную.
На этом все. Во второй части статьи рассмотрим конфигурации удаленных сессий, создание конечных точек (endpoint), ну и что нибудь еще по мелочи 🙂
Применение PowerShell для ИТ-безопасности. Часть I: отслеживание событий
Во времена, когда я писал серию статей о тестах на проникновение, чтобы помочь человечеству в борьбе с хакерами, мне попалась информация о некоторых интересных командлетах и техниках PowerShell. Я сделал выдающееся открытие: PowerShell является самостоятельным средством защиты. Похоже, самое время начать новую серию публикаций о PowerShell.
В этих публикациях мы будем придерживаться мнения, что, хотя PowerShell не заменит специальные платформы безопасности (сотрудники Varonis могут вздохнуть с облегчением), это средство поможет ИТ-специалистам отслеживать угрозы и принимать другие меры для обеспечения безопасности. Кроме того, ИТ-отдел начнет ценить чудеса специализированных платформ безопасности, таких как наше решение Metadata Framework. PowerShell может выполнять интересные задачи по обеспечению безопасности в малых масштабах, но это средство не обладает характеристиками для работы со всей инфраструктурой.
Важное событие
Для начала рассмотрим использование PowerShell в качестве инструмента мониторинга системы для отслеживания файлов, процессов и действий пользователей.
Перед тем как начать проклинать меня, позвольте сказать, что я прекрасно знаю, что любой командный язык операционной системы можно использовать для отслеживания событий на системном уровне. Любой младший системный администратор может настроить, к примеру, скрипт оболочки Linux для опроса каталога, чтобы узнать, был ли обновлен файл, или для получения списка запущенных процессов, чтобы найти среди них нестандартные.
Сейчас речь не об этом.
Вместо этого PowerShell предоставляет непосредственное событийно-управляемое отслеживание на основе доступа операционной системы к изменениям нижнего уровня. Это равнозначно получению всплывающих уведомлений о последних событиях на новостном сайте вместо необходимости обновлять страницу вручную.
При этом PowerShell не будет работать без остановки, загружая циклы процессора. Скрипт активируется, когда происходит событие (изменение файла или вход в систему нового пользователя). Такое отслеживание безопасности гораздо эффективнее опросов методом подбора.
Ниже я объясню, как это делается.
Каждый, кто, как и я, изучал операционные системы, знает, что есть граница между процессами на уровне пользователя и процессами на уровне системы.
Операционная система (неважно, Linux или Windows) обрабатывает действия устройства на нижнем уровне, от чтения диска до получения пакетов, и скрывает это от рядовых приложений, запущенных на ПК.
Таким образом, если запустить любимое приложение для обработки текстов и просмотреть первую страницу документа, вся операция будет выглядеть, как плавное и синхронное действие. Однако в действительности происходят всевозможные события (поиск на диске, чтение дисковых блоков, отправка символов на экран и т. д.), которые намеренно скрыты от нас. За это можно благодарить Билла Гейтса.
Раньше только суровые системные инженеры знали об обработке событий на нижнем уровне. Теперь программисты PowerShell могут с удовольствием поделиться этой информацией.
Инструментальный язык ОС
Рассмотрим инструментарий управления Windows (WMI), который является попыткой Microsoft обеспечить последовательный просмотр объектов операционной системы.
Служба WMI, которой всего несколько лет, является частью крупной системы управления предприятием через Интернет (WBEM), предназначенной для стандартизации сведений, полученных от маршрутизаторов, переключателей, массивов хранения данных, а также операционных систем.
Как же выглядит и работает WMI?
Тренировочная работа с WQL в WBEMTest
Фактически это программный эквивалент монитора задач Windows. Впечатляет, не так ли? Если хотите узнать больше о WQL, загрузите превосходную электронную книгу Рави Чаганти (Ravi Chaganti), посвященную этой теме.
PowerShell и командлет Register-WmiEvent
Но это еще не все. От тренировочных заданий в WBEMTest можно перейти к запросам непосредственно в PowerShell.
На изображении ниже показаны первые несколько результатов запуска select Name, ProcessId, CommandLine from Win32_Process в тестовой среде AWS.
gwmi — это Get-WmiObject в PowerShell
Результат немного ненадежен, так как есть некоторые скрытые свойства, имеющие отношение к основному классу регистрации данных. Кроме того, этот командлет выдает внушительный список в консоли.
Для улучшения работы с Win32_Process я переместил результат запроса в Out-GridView — командлет PowerShell, который форматирует данные в аккуратную таблицу на основе графического интерфейса.
Неплохо для строки кода PowerShell. Но служба WMI способна на большее, чем просто запрашивать объекты ОС.
Как я упоминал ранее, она дает доступ к соответствующим событиям этих объектов. В WMI эти события ориентировочно разделены на три типа: создание, изменение и удаление.
До выхода PowerShell 2.0 доступ к этим событиям приходилось получать запутанным способом: создавая множество различных объектов, после чего происходило синхронное зависание, так что это не была настоящая асинхронная обработка событий. Чтобы узнать подробности, прочитайте публикацию MS Technet.
Теперь командлет Register-WmiEvent в PowerShell 2.0 позволяет реагировать на события в более приемлемой манере. Иными словами, когда происходит событие, срабатывает вызов, который можно зарегистрировать.
Вернемся к моей вымышленной (и уже знаменитой) компании Acme, чья ИТ-инфраструктура работает в среде AWS.
Системный администратор (назовем его Бобом) время от времени замечает, что место на сервере Salsa заканчивается. Он подозревает, что генеральный директор Acme Тед Блоутли загружает большие файлы, такие как аудиозаписи, в один из каталогов Боба, а затем перемещает на свой сервер Taco.
Боб хочет устроить западню: необходимо, чтобы при создании большого файла в основном каталоге в его консоли появлялось уведомление.
Чтобы сделать это, ему нужно работать с классом CIM_DataFile. Вместо получения доступа к процессам, как мы делали ранее, Боб использует этот класс для соединения с метаданными основного файла.
В PowerShell можно получить непосредственный доступ к объекту CIM_DataFile
Запуск этого скрипта непосредственно в консоли Salsa активирует команду Register-WmiEvent в фоновом режиме, назначая ей номер задания. Дальнейшее взаимодействие происходит только при возникновении события.
В любом случае, играя роль Боба, я запустил скрипт из командной строки PowerShell, а затем, как и Тед из нашей истории, я скопировал большой файл MP4 в каталог Боба. Результат вы можете увидеть ниже.
Теперь мы знаем, что Тед — фанат Мелоди Гардо. Кто бы мог подумать!
В публикации были продемонстрированы некоторые удивительные возможности использования средства PowerShell в качестве инструмента для обнаружения угроз и небольшого анализа поведения.
Мы продолжим изучать эти аспекты в следующих статьях.
about_Remote_Requirements
Краткое описание
Описание требований к системе и требований к конфигурации для выполнения удаленных команд в PowerShell.
Подробное описание
В этом разделе описываются требования к системе, требования пользователей и требования к ресурсам для установки удаленных подключений и выполнения удаленных команд в PowerShell. В нем также приводятся инструкции по настройке удаленных операций.
Требования к системе
для запуска удаленных сеансов на Windows PowerShell 3,0 на локальном и удаленном компьютерах должны быть выполнены следующие действия.
для запуска удаленных сеансов на Windows PowerShell 2,0 на локальном и удаленном компьютерах должны быть выполнены следующие действия.
можно создавать удаленные сеансы между компьютерами с Windows PowerShell 2,0 и Windows PowerShell 3,0. однако функции, которые выполняются только в Windows PowerShell 3,0, например возможность отключения и повторного подключения к сеансам, доступны только в том случае, если оба компьютера работают под управлением Windows PowerShell 3,0.
Разрешения пользователя
Для создания удаленных сеансов и выполнения удаленных команд по умолчанию текущий пользователь должен быть членом группы » Администраторы » на удаленном компьютере или предоставлять учетные данные администратора. В противном случае произойдет сбой команды.
Разрешения, необходимые для создания сеансов и выполнения команд на удаленном компьютере (или в удаленном сеансе на локальном компьютере), устанавливаются конфигурацией сеанса (также называемой конечной точкой) на удаленном компьютере, к которому подключается сеанс. В частности, дескриптор безопасности в конфигурации сеанса определяет, кто имеет доступ к конфигурации сеанса и кто может использовать его для подключения.
Если у текущего пользователя нет разрешения на использование конфигурации сеанса, команда для выполнения команды (использующая временный сеанс) или создание постоянного сеанса на удаленном компьютере завершается сбоем. Пользователь может использовать параметр ConfigurationName командлетов, которые создают сеансы, чтобы выбрать другую конфигурацию сеанса, если она доступна.
Члены группы » Администраторы » на компьютере могут определить, кто имеет разрешение на удаленное подключение к компьютеру, изменив дескрипторы безопасности в конфигурациях сеансов по умолчанию и создав новые конфигурации сеанса с разными дескрипторами безопасности.
Дополнительные сведения о конфигурациях сеансов см. в разделе about_Session_Configurations.
Windows сетевые расположения
начиная с Windows PowerShell 3,0, Enable-PSRemoting командлет может включить удаленное взаимодействие на клиентских и серверных версиях Windows в частных, доменных и общедоступных сетях.
в серверных версиях Windows с частными и доменными сетями Enable-PSRemoting командлет создает правила брандмауэра, которые допускают неограниченный удаленный доступ. Он также создает правило брандмауэра для общедоступных сетей, которое разрешает удаленный доступ только с компьютеров в той же локальной подсети. это правило брандмауэра для локальной подсети включено по умолчанию на серверных версиях Windows в общедоступных сетях, но повторно Enable-PSRemoting применяет правило, если оно было изменено или удалено.
в клиентских версиях Windows с частными и доменными сетями по умолчанию Enable-PSRemoting командлет создает правила брандмауэра, разрешающие неограниченный удаленный доступ.
Имя правила брандмауэра может отличаться для разных версий Windows. Используйте Get-NetFirewallRule для просмотра списка правил. Перед включением правила брандмауэра просмотрите параметры безопасности в правиле, чтобы убедиться, что конфигурация подходит для вашей среды.
в Windows PowerShell 2,0 на серверных версиях Windows Enable-PSRemoting создает правила брандмауэра, разрешив удаленный доступ во всех сетях.
в Windows PowerShell 2,0 на клиентских версиях Windows Enable-PSRemoting создает правила брандмауэра только для частных и доменных сетей. Если сетевое расположение является общедоступным, Enable-PSRemoting происходит сбой.
Запуск от имени администратора
Для следующих операций удаленного взаимодействия требуются права администратора.
Установление удаленного подключения к локальному компьютеру. Такой сценарий обычно называется «замыканием на себя».
Управление конфигурациями сеансов на локальном компьютере.
Просмотр и изменение параметров WS-Management на локальном компьютере. Это параметры в узле LocalHost на диске WSMAN:.
Для выполнения этих задач необходимо запустить PowerShell с параметром «Запуск от имени администратора», даже если вы являетесь членом группы » Администраторы » на локальном компьютере.
в Windows 7 и Windows Server 2008 R2 для запуска PowerShell с параметром » запуск от имени администратора » выполните следующие действия.
для запуска Windows PowerShell с параметром запуск от имени администратора :
параметр запуск от имени администратора также доступен в других записях обозревателя Windows для PowerShell, включая ярлыки. Просто щелкните элемент правой кнопкой мыши и выберите команду Запуск от имени администратора.
Настройка компьютера для удаленного взаимодействия
компьютеры, на которых работают все поддерживаемые версии Windows, могут устанавливать удаленные подключения к и выполнять удаленные команды в PowerShell без какой бы то ни было конфигурации. Однако для получения подключений и разрешения пользователям создавать локальные и удаленные сеансы PowerShell («PSSession») и выполнять команды на локальном компьютере необходимо включить удаленное взаимодействие PowerShell на компьютере.
Windows Server 2012 и более новые выпуски Windows Server по умолчанию включены для удаленного взаимодействия PowerShell. Если параметры изменены, можно восстановить параметры по умолчанию, выполнив Enable-PSRemoting командлет.
во всех других поддерживаемых версиях Windows необходимо запустить Enable-PSRemoting командлет, чтобы включить удаленное взаимодействие PowerShell.
Функции удаленного взаимодействия PowerShell поддерживаются службой WinRM, которая является реализацией Майкрософт протокола веб-служб для управления (WS-Management). При включении удаленного взаимодействия PowerShell вы изменяете конфигурацию по умолчанию WS-Management и добавляете конфигурацию системы, позволяющую пользователям подключаться к WS-Management.
Чтобы настроить PowerShell для получения удаленных команд:
Чтобы убедиться, что удаленное взаимодействие настроено правильно, выполните команду теста, например следующую команду, которая создает удаленный сеанс на локальном компьютере.
Если удаленное взаимодействие настроено правильно, команда создаст сеанс на локальном компьютере и возвратит объект, представляющий сеанс. Выходные данные должны выглядеть следующим образом:
Если команда завершается ошибкой, обратитесь к разделу about_Remote_Troubleshooting.
Общие сведения о политиках
При удаленной работе вы используете два экземпляра PowerShell: один на локальном компьютере и один на удаленном компьютере. в результате работа зависит от политик Windows и политик PowerShell на локальном и удаленном компьютерах.
Как правило, перед подключением и установкой подключения действуют политики на локальном компьютере. При использовании подключения политики на удаленном компьютере вступают в действие.
Ограничения обычной проверки подлинности в Linux и macOS
при подключении из системы Linux или macOS к Windows базовая проверка подлинности по протоколу HTTP не поддерживается. Обычную проверку подлинности можно использовать по протоколу HTTPS, установив сертификат на целевом сервере. Сертификат должен иметь имя CN, соответствующее имени узла, не просрочено или отозвано. Самозаверяющий сертификат может использоваться в целях тестирования.
следующая команда, запускаемая из командной строки с повышенными привилегиями, настроит прослушиватель HTTPS на Windows с установленным сертификатом.
На стороне Linux или macOS выберите базовый для проверки подлинности и-UseSSl.
Альтернативой обычной проверке подлинности по протоколу HTTPS является Negotiate. В результате проверка подлинности NTLM между клиентом и сервером и полезными данными шифруется по протоколу HTTP.
Ниже показано использование Negotiate с New-PSSession :