Сетевая защита с помощью сценариев (часть 3) — передовые методы
Введение
Беспроводные сети представляют множество проблем безопасности. Рассмотрим пару сценариев. В одном вам нужно принять меры, если пользователь подключается к определенной сети Wi-Fi, если точка доступа не защищена должным образом. В другом случае ваша организация обеспокоена футуристическим WiFi-червем, который может проникнуть в беспроводные сети Windows 7. Давайте подробнее рассмотрим, как можно решить эти проблемы.
Расширенная фильтрация событий WiFi
В предыдущей статье этой серии («Защита сети по сценарию — часть вторая: производительность, события и триггеры задач») мы рассмотрели, как прикрепить задачу к событию Windows. Для многих целей этот метод полностью подходит, но если вам нужно реагировать на более детализированный набор условий, вам нужно использовать более продвинутые методы. В этой статье мы рассмотрим использование запросов XPath, чтобы решить, следует ли выполнять задачу при возникновении определенного события Windows. В этом случае мы сосредоточимся на событии с идентификатором 8001, под которым Windows регистрируется:
Просмотр событий > Журналы приложений и служб > Microsoft > Windows > WLAN-AutoConfig
В нашем сценарии, вдохновленном обсуждением на форумах Superuser, нас особенно интересует гипотетическая сеть Wi-Fi «linksys» в конкретном случае, когда кто-то непреднамеренно подключается к ней без шифрования. В тот момент, когда такое событие происходит, мы хотим предпринять какие-то действия. (Запретить пользователям подключаться к незащищенным беспроводным сетям также можно настроить с помощью групповой политики — цель здесь состоит в том, чтобы осветить метод, который можно адаптировать для ваших собственных целей). Конкретные элементы, которые мы будем использовать в качестве триггера, выделены в примере события ниже:
Рисунок 1. Это событие было зарегистрировано при подключении к незащищенной сети Wi-Fi с именем Linksys.
Сначала мы прикрепим задачу к этому событию (см. нижнюю правую панель выше), как в части 2 этой серии:
- На экране «Создать базовую задачу» примите имя по умолчанию и нажмите «Далее».
- Нажмите «Далее» на экране «Когда событие зарегистрировано».
- На экране «Действие» вы можете выбрать все, что захотите. Для наших текущих целей это не важно, но, например, вы можете захотеть применить определенный набор правил брандмауэра через скрипт, принудительно использовать HTTPS и т. д. Нажмите «Далее».
- Если вы решили запустить программу, выберите ее сейчас и нажмите «Далее».
- Во второй части мы просто нажали «Готово», но на этот раз установили флажок «Свойства»:
Рисунок 2: Изменение свойств базовой задачи
Как только вы окажетесь в диалоговом окне «Свойства»:
- Перейдите на вкладку «Триггеры» и нажмите «Изменить».
- Выберите пользовательскую задачу
- Переключитесь на XML-запрос (это обеспечивает мощность и гибкость, которые нам понадобятся)
- Выберите «Редактировать запрос вручную» (нажмите «Да», если появится предупреждение об изменении вручную)
Вот как это выглядит на экране:
Рисунок 3. Редактирование запроса XPath вручную
На этом этапе мы вставим некоторый код XPath (задокументированный здесь) для фильтрации только тех событий, которые нам нужны. Если вы никогда не использовали XPath, это просто язык, который описывает, как перемещаться по узлам XML-документа (формат, в котором Windows хранит записи журнала событий). Чтобы выяснить, какой код нам нужен, мы просмотрим существующее событие нужного типа (см. левую часть рис. 3) и выберем фрагменты, которые нам нужны для нашего фильтра.
XPath кажется кратким и загадочным в первый раз, когда вы его видите. Например, код XPath, который мы будем использовать здесь:
<СписокЗапросов>
<Query Id = "0" Path = "Microsoft-Windows-WLAN-AutoConfig/Operational">
<Выберите путь = «Microsoft-Windows-WLAN-AutoConfig/Operational»>
*[Система[Поставщик[@Name='Microsoft-Windows-WLAN-AutoConfig'] и EventID=8001]]
и (*[EventData[Данные[@Name='SSID'] и (Данные='linksys')]])
и (*[EventData[Data[@Name='AuthenticationAlgorithm'] и (Data='None')]]
)
</Выбрать>
</запрос>
</СписокЗапросов>
Но, как показано на снимке экрана ниже, существует довольно прямая связь между событием и разработанным нами фильтром XPath:
Рис. 4. XML- запись события и код XPath для выбора для него
Нажмите OK до конца, чтобы сохранить запрос, и все готово. Чтобы проверить нашу работу, мы попытаемся инициировать интересующее нас событие, например, подключиться к точке доступа «Linksys», которая не использует никакого шифрования, и убедиться, что программа, которую мы настроили на экране «Действие», действительно работает.
Если что-то не работает или если вы хотите отредактировать XPath позже, вы можете перейти в Планировщик заданий Windows > Задачи просмотра событий и щелкнуть правой кнопкой мыши > Свойства нужной задачи:
Рисунок 5: Изменение задачи просмотра событий
WMI джиу-джитсу
Чем более взаимосвязанными становятся системы, тем более новыми возникают возникающие риски. Так обстоит дело с технологией Wireless Hosted Networking, также известной как Virtual WiFi, представленной в Windows 7. Хотя эта новая возможность WLAN пока не получила широкого распространения, она виртуализирует сетевую карту хоста и позволяет ПК стать программной точкой доступа. Существуют допустимые варианты использования виртуального WiFi, но также существуют риски как для ПК, так и для любых подключенных к нему устройств WLAN. В то время как Microsoft приложила немало усилий, чтобы обезопасить эту технологию, в статье 2011 года белого хакера «Корпоративные Wi-Fi-черви, бэкдоры и ботнеты для развлечения и прибыли» обсуждается потенциальная футуристическая угроза, которая требует внимания. Каждый раз, когда появляется новая крутая технология, вы можете быть уверены, что плохие парни ищут способ ее использовать.
Хотя мы не будем здесь глубоко вдаваться в особенности виртуального WiFi, достаточно сказать, что включить его можно так же просто, как выполнить две команды:
netsh wlan установить режим hostednetwork = разрешить
netsh wlan запустить размещенную сеть
В качестве последней задачи в нашей серии статей о защите сети с помощью сценариев давайте рассмотрим, как обнаружить и устранить гипотетический риск, скажем, эксплойта нулевого дня, который пытается тайно создать бэкдор-сеть WiFi на основе виртуального WiFi. Один из вариантов — просто использовать групповую политику, чтобы отключить эту функцию:
Рисунок 6: Групповая политика для управления виртуальным WiFi
Но нет никакой гарантии, что вредоносное ПО, работающее в контексте локальной системы через уязвимость нулевого дня в Windows, не сможет преодолеть это. Вместо этого мы хотим разработать форму глубокоэшелонированной защиты на основе хоста, которая автоматически определяет, когда виртуальный Wi-Fi включен, и предпринимает соответствующие действия.
Чтобы осуществить это сетевое джиу-джитсу с атакой и парированием, мы будем использовать инструментарий управления Windows (WMI). WMI — это внутренняя база данных Windows, что-то вроде помеси реестра и SNMP, и она предлагает некоторые из самых низкоуровневых функций управления системой на «голом железе», доступных на платформе Windows. Он почти полностью доступен с помощью технологии сценариев — нет необходимости в C# или скомпилированном коде. Автор WindowsNetworking.com Митч Таллок (Mitch Tulloch) написал отличную серию статей о WMI еще в 2007 году. Эта статья перенесет нас в 2012 год, к последним технологиям PowerShell и полностью отработанному современному примеру.
Вот наш план игры: как и в примере с журналом событий ранее, мы будем отслеживать условие и запускать действие. Однако вместо отслеживания записей журнала событий мы будем искать изменения непосредственно в базовом репозитории WMI. Точно так же, как журнал событий фактически «подписывается» на события, происходящие в мире WMI, мы можем нацеливаться на них непосредственно через код. На практике это менее необходимо, чем раньше, потому что интеграция Tasks, Events и Performance Monitor намного богаче, чем когда-то, но вы не можете превзойти WMI, когда вам действительно нужно приступить к делу.
Во-первых, давайте просто разберемся и посмотрим, что на самом деле может нам показать WMI. Доступно несколько хороших инструментов с графическим интерфейсом. Чаще всего я использовал встроенную в Windows утилиту WbemTest.exe и WMIExplorer, очень хороший бесплатный инструмент на основе PowerShell. Запустите его из командной строки через powershell.exe./WMIexplorer.ps1 (вы можете сделать это из командной строки с повышенными привилегиями, чтобы избежать потенциальных проблем с разрешениями). Нажмите «Подключиться», чтобы привязаться к репозиторию WMI (по умолчанию тот, который находится на вашем локальном ПК). Большинство представляющих интерес классов WMI хранятся в пространстве имен ROOTCIMv2 (аббревиатура от «Common Information Management v2»):
Рисунок 7: Основной вид после запуска WMIexplorer
В этом примере я прокрутил вниз до Win32_PerfFormattedData_Tcpip_TCPv4, нажал Get Instances и просматриваю свойство ConnectionsEstablished. Если вы когда-нибудь задавались вопросом, откуда Perfmon берет базовые данные, большая их часть находится в этой области репозитория WMI. Я выбрал этот пример просто потому, что мы невольно использовали его во второй статье этой серии.
Теперь перейдем к тому, как просмотреть эти данные через PowerShell. Здесь (строки завернуты для удобочитаемости) несколько эквивалентных способов получения той же информации, которую мы получили ранее из графического интерфейса Perfmon. Какой метод вы выберете, зависит от поставленной задачи.
PS C:> Get-WMIObject -Namespace ROOTCIMv2 -Class Win32_PerfFormattedData_Tcpip_TCPv4 |
Список форматов - свойство ConnectionsActive
ConnectionsActive: 2547
PS C:> $tcpObj = Get-WMIObject -Namespace ROOTCIMv2 -Class Win32_PerfFormattedData_Tcpip_TCPv4
PS C:> $tcpObj | Список форматов - свойство ConnectionsActive
ConnectionsActive: 2547
PS C:> $tcpObj = Get-WMIObject -Namespace ROOTCIMv2
-Запрос «ВЫБЕРИТЕ ConnectionsActive FROM Win32_PerfFormattedData_Tcpip_TCPv4»
PS C:> $tcpObj | Список форматов - свойство ConnectionsActive
ConnectionsActive: 2547
Теперь, когда мы понимаем основы использования PowerShell для взаимодействия с WMI, давайте перейдем к нашему сценарию WiFi.
Виртуальный Wi-Fi
Предполагая, что карта WiFi присутствует в вашей системе Windows 7 или более поздней версии, вы можете включить функцию виртуального WiFi через командную строку. Вот как все выглядит на типичном ПК до включения виртуального Wi-Fi: просто обычное соединение WiFi:
Рисунок 8: Одиночное WiFi-соединение
Используя командную строку с повышенными привилегиями, запустите:
netsh wlan установить режим hostednetwork = разрешить
Рисунок 9: Появление виртуального адаптера Wi-Fi
Обратите внимание на новый «Адаптер минипорта Microsoft Virtual WiFi». Теперь, когда он включен, подключите его через:
netsh wlan запустить размещенную сеть
Рис. 10. Виртуальный WiFi-адаптер в состоянии подключения
Запрос события WMI
Наша цель — определить, когда один из этих виртуальных адаптеров Wi-Fi переходит в состояние подключения. Для этого нам нужно найти событие WMI, которое срабатывает, когда это происходит. В данном случае мы будем отслеживать активацию класса событий WMI MsNDIS_StatusMediaConnect (который, в отличие от данных, которые мы рассматривали ранее, которые находились в пространстве имен ROOTcimv2, находится в пространстве имен ROOTWMI).
Одна из сложностей при работе с WMI — просто найти место хранения данных о событиях. Документация помогает, но иногда простой просмотр (и сопутствующая ему интуиция) через WMIexplorer является самым простым подходом. В этом случае различные классы событий NDIS (Спецификация интерфейса сетевого драйвера) казались многообещающими, и в итоге я выбрал тот, который, согласно этой статье MSDN, срабатывает, «когда сетевая карта устанавливает соединение на канальном уровне и когда сетевой кабель подключен или сетевая карта WLAN входит в зону действия».
Несмотря на то, что мониторинг событий WMI чрезвычайно гибок, он требует определенного обучения. Одно существенное различие между временными и постоянными подписками на события. Вообще говоря, программы, которые работают непрерывно (например, службы Windows), обычно регистрируются для получения событий WMI на временной основе, то есть только во время их фактического выполнения. Если программа не запущена и происходит интересное событие, никто не будет слушать. Примером может служить программа базы данных, которая отслеживает использование диска с помощью WMI — если служба базы данных не запущена, никто не получает уведомления о заполнении диска.
Альтернативой являются постоянные подписки на события WMI. Когда служба Windows WMIprvSE.exe (поставщик WMI) обнаруживает событие, для которого существует подписка, она автоматически запускает программу, выразившую интерес к этому событию. На языке WMI говорится, что существует привязка между запросом события и потребителем события.
Традиционное системное администрирование довольно процедурно — запустите сценарий, он сделает свою работу, а затем завершит работу. Для мониторинга в течение длительного периода времени вам нужно либо повторно запускать сценарий через запланированную задачу, либо заблокировать его в постоянном цикле и выполнять повторный опрос режима сна/пробуждения. Напротив, администрирование систем, управляемых событиями, на основе WMI — чрезвычайно мощный современный подход, который позволяет системам осуществлять глубокий самоконтроль и самовосстановление.
Сначала мы кратко рассмотрим, как работают временные подписки на динамические события.
- Запустите wbemtest.exe от имени администратора и подключитесь к пространству имен ROOTwmi:
Рисунок 11: Запуск WbemTest и подключение к пространству имен
- Переключиться на асинхронный вызов:
Рисунок 12. Асинхронный режим ускоряет обновление графического интерфейса Wbemtest.
- Нажмите «Запрос уведомлений» и введите «SELECT * FROM NSNdis_StatusMediaConnect» (не волнуйтесь, регистр не учитывается), затем нажмите «Применить»:
Рис. 13. Мониторинг соединений NIC в реальном времени
- Предполагая, что вы ранее создали виртуальный WiFi-адаптер через netsh wlan, установите hostednetwork mode=allow, в командной строке с повышенными привилегиями введите:
netsh wlan остановить размещенную сеть
netsh wlan запустить размещенную сеть - Должно появиться событие:
Рис. 14. Произошло событие
Мы вернемся к этому событию через минуту. Но сначала давайте перейдем к PowerShell и постоянным подпискам на события.
Как упоминалось ранее, постоянное потребление событий WMI состоит из создания фильтров, потребителей и привязок. Фильтр состоит из WQL-запроса, потребитель — это то, что вызывается (например, запуск сценария, отправка электронной почты, ведение журнала), а привязка соединяет одно с другим. Что делает этот процесс «постоянным», так это то, что эти фильтры и т. д. записываются в репозиторий WMI в пространстве имен ROOTsubscription, где они сохраняются между перезагрузками. Несколько отличных недавних руководств см. в разделе PowerEvents для Windows PowerShell и язык запросов WMI через PowerShell.
Вот код PowerShell, который мы будем использовать, чтобы добиться цели. Части, которые вам нужно изменить, выделены жирным шрифтом:
#
# Создать фильтр событий WMI
#
$iFilter = ([WMICLASS]”\. ootsubscription:__EventFilter”).CreateInstance()
$iFilter.QueryLanguage = «WQL»
$iFilter.EventNamespace = " ROOTwmi "
$iFilter.Query = « ВЫБРАТЬ * ИЗ MsNDIS_StatusMediaConnect »
$iFilter.Name = « Виртуальный наблюдатель WiFi »
$Результат = $iFilter.Put()
$Filter = $Result.Path # Для использования в привязке
#
# Создание потребителя событий WMI
#
$iConsumer = ([wmiclass]”\. ootsubscription: CommandLineEventConsumer “).CreateInstance()
$iConsumer.Name = « Потребитель виртуального наблюдения за WiFi »
$iConsumer.CommandLineTemplate = « powershell.exe -command C:adminscriptswifiwatch.ps1 %InstanceName% »
$Результат = $iConsumer.Put()
$Consumer = $Result.Path # Для использования в привязке
#
# Установить привязку между фильтром событий WMI и потребителем
#
$iBinding = ([wmiclass]”\. ootsubscription:__FilterToConsumerBinding”).CreateInstance()
$iBinding.Filter = $Фильтр
$iBinding.Consumer = $Потребитель
$iBinding.Put()
Фильтр событий прост: мы ищем любое событие класса MsNDIS_StatusMediaConnect, которое срабатывает в пространстве имен ROOTwmi. Потребитель немного хитрее. Во-первых, существует несколько видов потребителей событий. Помимо CommandLineEventConsumer, который позволяет запускать сценарий по вашему выбору, Microsoft предлагает несколько других так называемых стандартных потребителей. Во-вторых, давайте посмотрим на скрипт c:adminscriptswifiwatch.ps1:
$BannedAdapterType = «Адаптер минипорта виртуального Wi-Fi Microsoft»
если ("$args" -eq "$BannedAdapterType") {
(Get-WmiObject -Class Win32_NetworkAdapter -Namespace rootCIMV2 `
-Фильтр «Имя = '$ BannedAdapterType'»). Отключить ()
}
Весь смысл упражнения раскрывается: если строка, переданная в этот внешний скрипт, совпадает со стереотипным именем виртуального WiFi-адаптера, отключите адаптер:
Рис. 15. Виртуальный WiFi-адаптер отключается, как только WMI обнаруживает, что он находится в подключенном состоянии.
В течение секунды или двух после подключения (netsh wlan start hostednetwork) виртуальный WiFi-адаптер автоматически отключается. Эшелонированная защита: даже если вредоносное ПО попытается обойти системные политики, оно врежется в эту кирпичную стену, запускаемую событием WMI.
Хотя этот запрос также можно было бы выполнить полностью в операторе WQL:
SELECT * FROM MsNDIS_StatusMediaConnect, где InstanceName = «Microsoft Virtual WiFi Miniport Adapter»
Я предпочитаю помещать такую логику тестирования в скрипт, который легче модифицировать и поддерживать, а запрос WQL должен быть как можно более общим.
Последняя сложная часть — это переменная окружения: %InstanceName%. Цель состоит в том, чтобы предоставить потребительскому сценарию имя адаптера WLAN, вызвавшего событие. Для этого используется встроенный в WMI механизм, называемый стандартными строковыми шаблонами, который позволяет ссылаться на параметры объекта.
Вернитесь к предыдущему результату запроса Wbemtest и дважды щелкните экземпляр на панели результатов. Желаемое свойство в этом случае, которое содержало имя, требуемое логикой нашего скрипта, называется InstanceName:
Рисунок 16: Поиск имени свойства объекта WMI для использования в стандартных шаблонах строк
Поначалу WMI может быть сложным, но когда вы освоите его, вы обнаружите, что он обеспечивает глубокую, богатую экосистему для мониторинга и защиты ПК с Windows. Есть много других возможностей для изучения, и я надеюсь, что вы дадите волю своему творчеству.