Как удаленно обнаружить экземпляры 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ы. На стороне хоста, т.е. той машины, с которой шло обнаружение, файрвол тоже был включен, но специально в нем что-то открывать по сравнению с настройками по умолчанию не понадобилось.
В этом способе получилось, в основном, упражнение на файрвол, поэтому продолжение в следующем номере.
Алексей Шуленин
Comments
Anonymous
January 01, 2003
Спасибо, tasklist /svc действительно короче, чем Скрипт 1. Хотя с добавлением форматирования и фильтров разница стремительно сокращается: tasklist /fo list /fi "ImageName eq sql*" и т.д. :) Сразу вопрос.Если, к примеру, net stop MSSQL$SQLEXPRESS, то как?Anonymous
January 01, 2003
А смысл?Anonymous
January 01, 2003
Не торопите события. Здесь же написано - часть I.Anonymous
August 12, 2010
А вот это не годится? msdn.microsoft.com/.../a6t1z9x2.aspxAnonymous
August 13, 2010
Если речь идет только о сабже (обнаружить), то достаточно простой способ: подключиться по winrs (powershell) к хосту и выполить команду: tasklist /svcAnonymous
August 13, 2010
никак :)