Порт 5985 для чего
Перейти к содержимому

Порт 5985 для чего

  • автор:

Удаленное управление PowerShell Remoting через WinRM HTTPS

date09.08.2021
useritpro
directoryPowerShell, Windows 10, Windows Server 2019
commentsкомментария 3

По умолчанию трафик в сессии PowerShell Remoting шифруется независимо от того, используется ли для передачи протокол HTTP (порт TCP/5985) или HTTPS (порт TCP/5986). Весть трафик в любом случае шифруется с помощью ключа AES-256. Однако, если вы подключаетесь к удаленному компьютеру не вашем лесу AD, или в рабочей группе, с которой Kerberos не может обеспечить доверительные отношения, вы рискуете стать жертвой man-in-the middle атак. Microsoft рекомендует всегда исопльзовать HTTPS транспорт для PowerShell Remoting, когда вы подключаетесь к сторонним компьютерам.

В этой статье мы рассмотрим, как настроить PowerShell Remoting через HTTPS с помощью SSL сертификата, который обеспечивает более высокий уровень защиты ваших сессий к компьютерам не в домене Active Directory.

Следующие шаги описывают настройку удаленного Windows устройства, к которому вы хотите подключаться через PowerShell Remoting по HTTPS.

Убедитесь, что тип вашей сети (сетевого подключения) определяется как Private или Domain:

Включите WinRM и PSRemoting с помощью команды:

Чтобы настроить HTTPS для WinRM, сначала вам нужно создать SSL сертификат на компьютере, к которому вы хотите подключиться. Этот сертификат будет использоваться для шифрования WinRM трафика. Проще всего создать самоподписанный сертификат с помощью PowerShell (в доменной среде вы можете автоматизировать выпуск сертификатов для WinRM через Auto Enrollment).

В качестве DNS имени сертификата будет указаны имя компьютера и его IP адрес (удобно, если вашей сети не DNS сервера). Оба значения для Subject Alternative Name сертфиката можно получить через PowerShell:

$hostName = $env:COMPUTERNAME
$hostIP=(Get-NetAdapter| Get-NetIPAddress).IPv4Address|Out-String
$srvCert = New-SelfSignedCertificate -DnsName $hostName,$hostIP -CertStoreLocation Cert:\LocalMachine\My
$srvCert

Новый SSL сертификат появится в персональном хранилище сертификатов компьютера.

создать самоподписанный SSL сертификат для шифрования winrm трафика

По умолчанию для Powershell Remoting в Windows созданы два листенера на разных портах: HTTP на порту 5985 и HTTPS на 5986. Список активных листенеров можно получить так:

Удалите стандартные HTTP и HTTPS листенеры:

Get-ChildItem wsman:\localhost\Listener\ | Where-Object -Property Keys -like ‘Transport=HTTP*’ | Remove-Item -Recurse

Создайте новый HTTPS листенер и привяжите к нему ваш сертификат:

New-Item -Path WSMan:\localhost\Listener\ -Transport HTTPS -Address * -CertificateThumbPrint $srvCert.Thumbprint -Force

привязать SSL сертификат к HTTPS listener winrm

Создайте правило для Windows Firewall, которое разрешает WinRM HTTPS трафик, или проверьте что она активно:

New-NetFirewallRule -Displayname ‘WinRM — Powershell remoting HTTPS-In’ -Name ‘WinRM — Powershell remoting HTTPS-In’ -Profile Any -LocalPort 5986 -Protocol TCP

Вы можете проверить к какому отпечатку сертификата привязан HTTPS листенер WinRM с помощью команды:

WinRM e winrm/config/listener

Удаленный хост настроен. Теперь вам нужно экспортировать SSL сертификат в cer файл:

Export-Certificate -Cert $srvCert -FilePath c:\PS\PsRemoting-Cert.cer

dir WSMan:\localhost\Service | ? Name -eq AllowUnencrypted
dir WSMan:\localhost\Client | ? Name -eq AllowUnencrypted

AllowUnencrypted

Если нужно, запретите использовать нешифрованные подключения:

Скопируйте cer файл на ваш компьютер и импортируйте его командой (или распространите сертфикат на компьтеры через GPO):

Import-Certificate -FilePath c:\PS\PsRemoting-Cert.cer -CertStoreLocation Cert:\LocalMachine\root\

Теперь для подключения к удаленному серверу через WinRM HTTPS нужно использовать аргумент -UseSSL в командах Enter-PSSession и Invoke-Command. В следующем примере мы подключимся к удаленному хосту из консоли PowerShell по IP адресу (обратите внимание, что мы не добавляли этот IP адрес в TrustedHosts):

$SessionOption = New-PSSessionOption -SkipCNCheck
Enter-PSSession -Computername 192.168.13.4 -UseSSL -Credential kbuldogov -SessionOption $SessionOption

Настройка удаленного взаимодействия в PowerShell (часть 1)

Чтобы обеспечить возможность удаленного взаимодействия с помощью PowerShell, необходимо произвести некоторые настройки. Количество этих настроек зависит от операционной системы, сетевого окружения, требований к безопасности (и еще бог знает чего). Поскольку настроек довольно много, я попробую рассказать о наиболее важных из них. Ну, поехали…

Включение удаленного управления

Для того, чтобы управлять удаленным компьютером, необходимо на этом компьютере удаленное взаимодействие разрешить. Исключение составляет Windows Server 2012, где все возможности удаленного управления включены по умолчанию. Для всех остальных операционных систем надо:

1. Стартовать службу WinRM и поставить ее на автозапуск;
2. Создать прослушиватель (listener), который будет слушать запросы на управление;
3. Включить на файерволе правило, разрешающее трафик WS-Management.

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

запуск Enable-PSRemoting на локальном компьютере

В доменной среде для настройки PS Remoting можно воспользоваться групповыми политиками.

В разделе Computer Configuration\Policies\Windows Settings\System Services включим политику «Windows Remote Management (WS-Management)». Она задает режим запуска для службы WinRM.

настройка автозапуска для службы WinRM

В разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service включаем политику «Allow automatic configuration of listeners», которая создает прослушиватель на порту 5985 (порт для HTTP по умолчанию). Дополнительно можно указать, с каких IP можно принимать подключения. Если в фильтрации по IP нет необходимости, просто ставим знак *, что означает принимать подключения с любого адреса.

настройка прослушивателей для HTTP

Затем идем в раздел Computer Configuration\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Inbound Rules и создаем новое правило. Выбираем пункт Predefined (Предопределенные правила) и в списке выбираем Windows Remote Management.

настройка исключений файервола для HTTP

Обратите внимание, что можно выбрать два режима работы — стандатный и совместимый. В первом случае будет открыт порт 5985, использующийся WinRM по умолчанию, во втором — порт 80 (для совместимости со старыми версиями WinRM). По умолчанию выбраны оба.

выбор портов для HTTP

Настройка доверия между компьютерами

При удаленном подключении в 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 воспользуемся командой:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value SRV1.contoso.com

При добавлении нескольких компьютеров их имена можно перечислить через запятую. Допускается указывать не только имя, но IP-адрес компьютера. Также поддерживаются символы подстановки. Например, можно добавить в доверенные хосты все компьютеры из домена contoso.com, указав значение *.contoso.com, или вообще всех без исключения:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value *

Чтобы добавить имя компьютера в уже имеющийся список доверенных узлов, необходимо сначала сохранить текущее значение в переменной, а затем присвоить значение разделенному запятыми списку, который включает текущее и новое значения. Например, чтобы добавить компьютер SRV2 в имеющийся список доверенных узлов, воспользуйтесь следующей командой:

$curr = (Get-Item WSMan:\localhost\Client\TrustedHosts).value
Set-Item WSMan:\localhost\Client\TrustedHosts -Value ″$curr,SRV2.contoso.com″

Ну и посмотреть список доверенных узлов можно командой:

добавление компьютеров в TrustedHosts с помощью powerShell

Также для добавления в TrustedHosts можно воспользоваться групповой политикой. В разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Client включаем политику «Trusted Hosts» и добавляем имена или IP-адреса компов через запятую. Поддерживаются подстановочные символы.

добавление компьютеров в TrustedHosts с помощью групповых политик

Примечание: если TrustedHosts сконфигурированы через GPO, то из PS изменить их не удастся. То же касается и всех остальных настроек PS Remoting.

SSL

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

Во первых, для использования этого метода, нам нужен цифровой сертификат SSL для машины, к которой мы собираемся подключаться. Получение сертификата — отдельная тема, не будем на ней останавливаться. В тестовой среде я воспользуюсь утилитой Makecert, входяшей в состав Windows SDK, и создам самоподписанный сертификат:

makecert -a sha1 -r -pe -n ″CN=wks8″ -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localmachine -sky exchange -sp ″Microsoft RSA SChannel Cryptographic Provider″ -sy 12 -m 12 ″C:\myssl.cer″

Эта команда создаст SSL-сертификат сроком на год и поместит его в хранилище сертификатов локального компьютера. Обратите внимание, что сертификат должен быть выдан на то же имя, которое вы будете указывать в команде подключения.

создание самоподписанного сертификата

После получения сертификат должен быть добавлен в Trusted Root Authority (доверенные корневые центры сертификации). Для этого открываем сертификат и жмем на кнопку «Установить сертификат».

сведения о сертификате

Запускается мастер импорта сертификатов. Указываем расположение хранилища «Локальный компьютер».

выбор хранилища для сертификата

В качестве хранилища выбираем «Доверенные корневые центры сертификации».

помещение сертификата в доверенные корневые центры сертификации

Теперь наш сертификат является доверенным. Еще раз открываем его, и на вкладке «Состав» находим отпечаток сертификата (CertificateThumbprint). Копируем его в буфер обмена.

отпечаток сертификата

Теперь можно создавать прослушиватель для HTTPS. Открываем консоль PowerShell и вводим команду:

New-WSManInstance winrm/config/listener -SelectorSet @ < Address=′*′; Transport=′HTTPS′ >-ValueSet @

В поле CertificateThumbrint вставляем отпечаток сертификата, скопированный в предыдущем пункте.

создание прослушивателя для HTTPS

Исключения файерволла Windows (если он включен) для нового прослушивателя необходимо настраивать вручную, автоматически они не создадутся. Поэтому создадим новое правило для входящего трафика по портам TCP 5986 и 443:

New-NetFirewallRule -DisplayName ″Windows Remote Management (HTTPS)″ -Direct Inbound -Protocol TCP -LocalPort 5986,443 -Action Allow -Enabled True

Также для создания правила можно воспользоваться графической оснасткой или утилитой командной строки netsh, кому что больше нравится.

создание правила на файерволе для HTTPS

Далее идем на компьютер SRV1, с которого будем подключаться. Поскольку я использую самоподписанный сертификат, то его придется добавить к доверенным корневым сертификатам и на клиенте. Копируем файл сертификата myssl.cer на SRV1 и устанавливаем командой:

certutil -addstore root C:\myssl.cer

Вот и все, настройка закончена. Теперь можно подключаться. Откроем интерактивную сессию на wks8 командой:

Enter-PSSession -ComputerName wks8 -Credential wks8\kirill -UseSSL

Обратите внимание, что при подключении по SSL необходимо вводить учетные данные, а также указывать тип подключения. Дальше все как обычно.

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

Отключение проверки

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

В принципе это правильно, но при необходимости проверки можно отменить. Для этого в свойствах сессии есть два параметра:

-SkipCACheck — отменяет проверку издателя сертификата;
-SkipCNCheck — отменяет проверку соответствия имени компьютера.

Создать новую сессию с использованием этих параметров можно например вот так:

$ option = New-PSSessionOption -SkipCACheck -SkipCNCheck
Enter-PSSession -ComputerName wks8 -SessionOption $option -Credential wks8\kirill -UseSSL

Правда в этом случае теряется смысл SSL-сертификатов, и тогда уж проще пользоваться Thrusted Hosts. Но возможность такая есть, и знать о ней надо.

Дополнительные настройки

Начиная со второй версии, WinRM по умолчанию слушает порт 5985 для HTTP и 5986 для HTTPS. Для совместимости со старыми версиями (или чтобы не открывать дополнительные порты на брандмауэре) можно дополнительно включить прослушиватели на традиционных портах 80 и 443. Для HTTP:

Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpListener $true

Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpsListener $true

создание прослушивателей на портах 80 и 443

То же самое можно сделать с помощью групповых политик. Для этого надо в разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service включить политики «Turn On Compatibility HTTP Listener» и «Turn On Compatibility HTTPS Listener».

создание прослушивателей на портах 80 и 443 с помощью GPO

Порты по умолчанию можно изменить и указать слушать любой нестандартный порт, например порт 8080:

Set-Item WSMan:\localhost\listener\listener*\port -Value 8080

изменение дефолтного порта

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

На этом все. Во второй части статьи рассмотрим конфигурации удаленных сессий, создание конечных точек (endpoint), ну и что нибудь еще по мелочи ��

Практика ИБ. Централизованный сбор логов с Windows-устройств

Практика ИБ. Централизованный сбор логов с Windows-устройств

Коллеги, в предыдущей статье мы обсудили инвентаризацию ИТ-активов и кратко рассмотрели простейшие способы сбора технической информации с устройств. Разумеется, кроме сведений о самих активах, в целях решения задач информационной безопасности следует собирать и журналы аудита с контролируемых устройств. В данной статье мы рассмотрим централизованный сбор логов с Windows-устройств посредством использования штатного функционала Windows Event Forwarding и пересылку собранных событий в SIEM-систему (на примере IBM QRadar). Приступим!

Для начала следует напомнить читателям о том, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Microsoft предлагает использовать также бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Можно также пользоваться и веб-версией рекомендаций по настройке аудита.

Разумеется, рекомендуемые в «лучших практиках» настройки аудита следует привести в соответствие конкретной инфраструктуре: например, будет нецелесообразно включать аудит платформы фильтрации (т.е. встроенного брандмауэра Windows) в случае, если в компании применяется другое наложенное хостовое СЗИ с функционалом межсетевого экранирования. Не стоит забывать и о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые «классические» политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии))» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).

Итак, настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и централизованного их хранения и анализа. Штатный механизм Windows Event Forwarding, который работает из коробки с Microsoft Windows Server 2008 / Vista и старше, позволяет осуществлять централизованный сбор журналов аудита на устройстве-коллекторе (не ниже Windows Server 2008 и Vista, но все же рекомендуется использовать выделенный Windows Server 2012R2 и старше) с устройств-источников с применением функционала WinRM (Windows Remote Management, использует протокол WS-Management) и использованием т.н. «подписок» на определенные события (набор XPath-выражений для выбора интересующих журналов и событий на источнике). События с удаленных устройств могут быть как запрошены коллектором (режим Pull / Collector initiated), так и отправлены самим источником (режим Push / Source computer initiated). Мы рекомендуем использовать последний режим, поскольку в режиме Push на коллекторе служба WinRM слушает входящие соединения, а на клиентах-источниках WinRM не находится в режиме прослушивания и только периодически обращается к коллектору за инструкциями, что уменьшает поверхность потенциальных атак на конечные устройства. По умолчанию для шифрования трафика от источников к коллектору, принадлежащих одному Windows-домену, используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на приемнике и источнике, при этом они могут не принадлежать одному домену. При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.

Рассмотрев концепцию пересылки логов с Windows-устройств, перейдем непосредственно к настройке нашей связки: источник событий -> сервер-коллектор -> утилита IBM WinCollect -> SIEM-система IBM QRadar.

Для включения сервиса сбора логов следует выполнить нижеописанные шаги:

1. На сервере-коллекторе выполнить команду winrm qc, ответить согласием на оба последующих вопроса (включение службы WinRM и прослушивание порта TCP:5985 для входящих соединений от источников). Следует учесть, что выполнение команды winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно либо через политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленная оболочка Windows / Разрешить доступ к удаленной оболочке -> Запретить» («Computer Configuration / Administrative Templates / Windows Components / Windows Remote Shell / Allow Remote Shell Access -> Disabled»), либо командой winrm set winrm/config/winrs @

2. На сервере-коллекторе выполнить команду wecutil qc, согласиться на включение службы сборщика событий Windows. При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.

3. На источниках событий следует включить службу WinRM: установить «Тип запуска» в значение «Автостарт» и запустить «Службу удаленного управления Windows» («Windows Remote Management (WS-Management)»), при этом TCP:5985 не начинает слушаться.

4. Проверить состояние службы WinRM можно командой winrm enumerate winrm/config/listener, в результате выполнения которой отобразятся настройки порта и список локальных IP-адресов, на которых прослушиваются соединения по TCP:5985. Команда winrm get winrm/config покажет подробные настройки службы WinRM. Переконфигурировать настройки можно либо непосредственно через утилиту winrm, либо через групповые политики по пути «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленное управление Windows» («Computer Configuration / Administrative Templates / Windows Components / Windows Remote Management»).

5. На источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITY \ NETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTIN \ Event Log Readers ( «Читатели журнала событий»). После этого необходимо перезапустить «Службу удаленного управления Windows» (WinRM) и службу «Журнал событий Windows» (EventLog).

6. Затем следует создать и применить конфигурацию групповой политики для источников, в которой будет указана конфигурация и адрес сервера-коллектора. Требуется включить политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Пересылка событий / Настроить адрес сервера. » («Computer Configuration / Administrative Templates / Windows Components / Event Forwarding / Configure the server address. «) и указать адрес сервера-коллектора в следующем формате:

где 60 – частота обращения (в секундах) клиентов к серверу за новыми инструкциями по пересылке журналов. После применения данной настройки на устройствах-источниках следует сделать перезапуск службы WinRM.

7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита (eventvwr.msc) и находим внизу раздел «Подписки» («Subscriptions»). Нажимаем правой кнопкой мыши и выбираем «Создать подписку», задаем имя подписки. Далее выбираем опцию «Source Computer Initiated» (это означает предпочтительный режим Push). Нажимаем на кнопку «Select Computer Groups», выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем «Select Events» и вводим XPath-запрос (пример для сбора журналов Security):

<Query Path=»Security»>

8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На коллекторе в eventvwr.msc в разделе «Подписки» можно будет увидеть приходящие события с источников и список самих источников.

9. Далее, решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему (возьмем для примера SIEM security систему IBM QRadar (Курадар)). Для этого нам потребуется установить на сервере-коллекторе утилиту IBM WinCollect.

Рекомендуем использовать управляемый («Managed») режим работы WinCollect для упрощения его администрирования. Для того, чтобы отправляемые через WinCollect агрегированные события корректно обрабатывались в IBM QRadar, нам следует воспользоваться рекомендациями IBM и на сервере-коллекторе с установленной утилитой WinCollect перевести формат пересылаемых событий в RenderedText, а также сменить их локаль на EN-US командой wecutil ss SubscriptionName /cf:RenderedText /l:enUS (где SubscriptionName — имя подписки, заданное в п.7 выше). Кроме того, необходимо обеспечить сетевую доступность между сервером-коллектором с установленным WinCollect и нодами IBM Q Radar по TCP:8413 и TCP/UDP:514.

10. После установки утилиты WinCollect на сервер-коллектор, в самой SIEM-системе IBM QRadar нужно будет добавить этот сервер в список источников (тип источника «Microsoft Security Event Log», в поле «Target Destination» в выпадающем списке лучше выбрать вариант с TCP-syslog-подключением, отметить check-box «Forwarded Events»).

После применения указанных настроек новые события и устройства-источники, пересылающие Windows-логи на сервер-коллектор, появятся в консоли IBM QRadar автоматически. В итоге, после внедрения SIEM системы данные в ней и регистрацию событий информационной безопасности можно будет легко обогатить журналами аудита Windows, собранными описанным способом с различных устройств в инфраструктуре компании.

Default WinRm Ports and How to Change Them

Download a free trial of Veeam Backup for Microsoft 365 and eliminate the risk of losing access and control over your data!

Table of Contents

WinRM and PowerShell Remoting is a crucial feature to have when managing remote Windows computers. Just like other services, WinRM listens on specific ports under specific circumstances. In this tutorial, learn those WinRM ports and even how to change them, if needed.

The WinRM Listener

One of the most important parts of WInRM (and the ports it runs on) is the WinRM listener.

The WinRM listener is a web server at its core. It communicates with HTTP and HTTPS and back in the pre-Windows 7 days it even used to default to the same port 80 and port 443 that most web servers use.

The listener runs as a service on your computer that is waiting for connections to attempt to be established, just like a normal web server.

A WinRm listener can listen two different ways; HTTP or HTTPS. The WinRM port for HTTP is 5985 while the WinRm port for HTTPS is 5986, by default.

  • HTTP – Port 5985
  • HTTPS – Port 5986

Errors Connecting to Wrong Ports

And if you do not add the firewall rule when you change the port you will get the same message even when providing the port like this.

Changing WinRM Ports

While Microsoft recommends staying with the default listening ports for compatibility and ease of use, you can change them. This can be helpful in cases when this is a conflict with the default ports or a firewall restriction blocking the use of those ports.

Maybe you have a system set up that’s configured to connect to WinRM over custom ports. When you try to connect like normal, you receive the following error message:

Failed WinRM connection due to wrong port

Failed WinRM connection due to wrong port

If so, it’s time to change the WinRM port on the server side!

To change the WinRm ports, you’ll first need to figure out if you already have a service listening on those ports.

Tracking Down Existing Connections

The easiest way to discover what ports are in use on a Windows machine is to use the netstat tool. Netstat checks for all active ports on your system and, if active, returns the source and destination IP and port used.

To track down listening ports prior to changing WinRm posts, run netstat -aon . The -aon switches:

  • show all active connections ( a )
  • show the process ID for the process that opened the connection ( o )
  • do no attempt to resolve any DNS names of destination IPs ( n )

Running netstat to find listening connections

Running netstat to find listening connections

If a web server is listening on port 80, for example, you’ll see a line where the local address ended in :80 under the Local Address column. This row is where you’ll see the PID or process ID the connection is using.

Once you know the PID, you can then reference the PID to find the process name using something like the Get-Process PowerShell cmdlet.

Running Get-Process to find process name

Running Get-Process to find process name

Although in this case, you can see above that the process name is just System. This means that the process is highly integrated within the OS and is probably built into Windows.

Setting WinRM Compatibility Ports

WinRM has a feature called compatibility ports. Compatibility ports exist to be backward-compatible with some legacy systems that only work on ports 80 for HTTP and 443 for HTTPS. If you need to change WinRm to listen on these ports, enable the compatibility listeners.

Once you know that you do not have anything else running on ports 80 and 443 set the WSMan listeners to use the compatibility ports (80 for HTTP and 443 for HTTPS).

Setting WinRM to Listen on Any Port

If, for some reason, you need to configure WinRM to listen on a non-standard port, you can do that too. To do so:

  1. Find the listener name. You can do this by enumerating all of the WinRM listeners with the Get-Item cmdlet. The command below is listing all ( * ) of the listeners currently installed.

Getting all existing WinRm listeners

Getting all existing WinRm listeners

2. Next, using the listener name shown above, configure each listener using Set-Item providing the path of the listener and the port number to change it to.

3. At this point, the WinRM listeners are listening on the correct ports, the Windows Firewall is probably rejecting any remote connections to those ports. You need to open those ports. To do so, run the following command. The New-NetFirewallRule below is creating a Windows Firewall rule to allow all inbound TCP connections to a custom port.

If you would have not opened the appropriate Windows Firewall port, you would get a message like this when trying to connect:

Failed WinRM connection due to Windows firewall

Failed WinRM connection due to Windows firewall

Connecting to a Custom Port with PSRemoting

Now that you’ve set up and configured WinRM successfully on the WinRM server, you need to test connecting with the WinRM client. To do that requires just one additional parameter; Port .

Using any of the PSRemoting commands like Invoke-Command or Enter-PSSession , specify the Port parameter and the port set up to successfully make a connection.

Successful WinRm connection

Hate ads? Want to support the writer? Get many of our tutorials packaged as an ATA Guidebook.

More from ATA Learning & Partners

Recommended Resources!

Recommended Resources for Training, Information Security, Automation, and more!

Get Paid to Write!

ATA Learning is always seeking instructors of all experience levels. Regardless if you’re a junior admin or system architect, you have something to share. Why not write on a platform with an existing audience and share your knowledge with the world?

ATA Learning Guidebooks

ATA Learning is known for its high-quality written tutorials in the form of blog posts. Support ATA Learning with ATA Guidebook PDF eBooks available offline and with no ads!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *