Как удаленно обнаружить экземпляры SQL Server на машине? Часть I.

Недавно коллеги на работе, поинтересовались, существуют ли сравнительно честные способы сделать сабж в отсутствии инвентаризационного ПО типа System Center (см. SCOM, SCCM) в организации. С ходу удалось yназвать следующие три доморощенных способа отыскания SQL Server на некоторой удаленной машине (при условии, разумеется, что мы обладаем на ней соответствующими правами, машина в момент проверки доступна по сети, сервис Remote Procedure Call (RPC) на ней включен и необходимые порты не закрыты файрволами). Способ первый, тривиальный. Открываем services.msc и смотрим, что там есть из SQL Serverных сервисов. То есть примерно так:

Get-WmiObject -Class Win32_Service -ComputerName "w7x86sql08r2" -Filter "Name like 'SQL%' or Name like 'MSSQL%' or Name like 'MsDts%' or Name like 'Report%' or Name like 'MSSI%'" | select Name, StartMode, State

Скрипт 1

Натурально, получаем отлуп: The RPC server is unavailable

Рис.1

В моем случае машина w7x86sql08r2, на которой я пытаюсь обнаружить SQL Serverы, это виртуалка, а обнаружить я их собираюсь с хоста. Это никоим образом не ограничивает рассматриваемый сценарий для реальных машин в реальной сетке, просто мне будет удобней в дальнейшем называть машину, с которой будет происходить обнаружение, хостом, а машину, на которой я собираюсь что-либо обнаруживать, - виртуалкой. Виртуалка с хостом общаются промеж собой посредством сетевого соединения Hyper-V Internal Network, которому на виртуалке выставлено Location = Home Network.

Рис.2

В семерке Home и Work сети считаются за private, поэтому первое, что приходит в голову – отключить файрвол на Private-коннекциях, проверив тем самым, не закрывает ли он по умолчанию какие-либо жизненно необходимые WMI-порты. Сказано – сделано. На виртуалке (w7x86sql08r2) идем в Administrative Tools -> Windows Firewall with Advanced Security, кликаем справа на Properties и на закладке Private Profile отключаем файрвол:

Рис.3

С хоста повторяем Скрипт 1. Видим, что теперь все работает:

Рис.4

Значит, предположение было правильным, и виной были закрытые на виртуалке порты. На самом деле, можно видеть, что порт ТСР 135, необходимый для RPC и DCOM, в Windows Firewall открыт по умолчанию:

Рис.5

Значит, этого недостаточно. Осталось понять, чего ему еще не хватат до полного щастя. Включаем файрвол на виртуалке обратно и включаем на нем логгирование отвергнутых им сетевых пакетов. Логгирование теперь тоже отдельно включается/выключается для каждого сетевого профиля: private, public, domain. На Рис.3 обращаем внимание на секцию под названием Logging внизу формы и кликаем в ней кнопку Customize:

Рис.6

Выбираем по настроению путь к файлу журнала, его предельный размер, отмечаем, что в него должны писаться dropped packets  и жмем ОК. Повторяем Скрипт 1 и смотрим журнал – слева выбираем Monitoring, посредине кликаем на ссылку с именем файла журнала:

Рис.7

Рис.8

Можно видеть, что Скрипт 1 во время своего выполнения на машине 192.168.0.1(хост) долбился на машину 192.168.0.2, она же w7x86sql08r2, она же виртуалка, в UDP-порт 500 и в ТСР-порт 1027, причем в UDP-порт 500 он ломился тоже со своего UDP 500-го порта, а в ТСР-порт 1027 норовил залезть со своих ТСР-портов 55399, 56005, 56006, 56011, 56012 и др. Ну что, запустим бедолагу? Все там же, на виртуалочном файрволе, создадим новое входное правило, приоткрывающее на 192.168.0.2 ТСР-порт 1027 для входящих приватных коннекций:

Рис.9

Говорим, что это будет портовое правило:

Рис.10

Что это правило будет относиться к порту ТСР 1027 на данной машине.

Рис.11

и что его нужно разрешить:

Рис.12

В моем примере правило будет распространяться только на приватные сети:

Рис.13

и неважно, как мы его назовем:

Рис.14

Далее, при желании можно отредактировать свежесозданное правило, чтобы дополнительно его устрожить. Например, установить, что входящие коммуникации, подпадающие под это правило, возможны не абы с какой машины, а только со 192.168.0.1. Это логично – предположим, что SQL Server’ов у нас в организации навалом на разных машинах, но производить их ревизию мы будем только с какой-то одной, специально выделенной.

Рис.15

Я не задавался целью определить, с какого полного множества портов на хосте WMI долбится на порт 1027 на виртуалке. Понятно, что этот список динамический, поэтому просто наобум в качестве иллюстрации поставлю ограничением на хостовые порты диапазон 55000-57000.

Рис.16

Аналогично создаем второе правило под названием bbb для UDP-порта 500. Вот, что получилось в итоге:

Рис.17

Запускаем в который раз уже Скрипт 1 и видим, что по сравнению с Рис.4 все по-прежнему замечательно работает, хотя файрвол включен:

Рис.18

Запущенный с хоста скрипт показывает наличествующие на виртуалке сервисы, имеющие отношение к SQL Server, и мы видим, что на ней установлены два экземпляра SQL Server. Один – по умолчанию (его имя в этом разе MSSQLSERVER), и он имеет в своем составе установленные полнотекст, Analysis Services, Integration Services, Reporting Services и StreamInsight, второй экземпляр – по имени SQLEXPRESS.

Хотелось бы отметить, что манипуляции с файрволом здесь проходили на стороне виртуалки, т.е. на той машине, где искались SQL Serverы. На стороне хоста, т.е. той машины, с которой шло обнаружение, файрвол тоже был включен, но специально в нем что-то открывать по сравнению с настройками по умолчанию не понадобилось.

В этом способе получилось, в основном, упражнение на файрвол, поэтому продолжение в следующем номере.

  

Алексей Шуленин