Системы обнаружения вторжений (Intrusion Detection System, IDS) сегодня достаточно широко распространены и часто применяются в комплексных системах безопасности корпоративных информационных систем. Более того, требования стандартов в области защиты информации подразумевают использование данных средств с целью автоматизации обнаружения и реагирования на несанкционированную деятельность внутри корпоративной сети, а также на попытки осуществления атак извне.
Системы класса IDS подразделяются на средства обнаружения атак сетевого уровня (Network IDS) и средства обнаружения атак уровня узлов сети (Host IDS). Средства обнаружения сетевых атак производят анализ сетевого трафика на предмет наличия аномалий или попыток несанкционированного использования сетевых протоколов, а также признаков известных атак (например, SQL Slammer и множества других). Данные устройства размещаются на выделенном сервере или имеют чисто аппаратное исполнение (в том числе и в виде плат расширения коммутаторов) и подключаются к активному сетевому оборудованию.
В данной статье нам хотелось бы сделать акцент на средствах обнаружения атак на конечные узлы, размещаемых непосредственно на серверах и рабочих станциях в сети. Основная их задача — обнаруживать и фиксировать атаки, направленные на конечные узлы сети.
Для обнаружения атак на сервер или рабочую станцию подобные средства используют два источника информации: журналы регистрации событий (куда входят журналы регистрации событий операционной системы, журналы баз данных, а также журналы прикладных систем и служб) и содержимое сетевого трафика, поступающего на узел.
Не все средства обнаружения атак узлового уровня обладают возможностью анализа сетевого трафика самого узла, некоторые ограничиваются только анализом журналов регистрации. Понятно, что они по функциональным возможностям проигрывают тем системам, в которых реализованы оба механизма получения данных об атаках на узел. В частности, в примере с той же атакой SQL Slammer сервер базы данных с Microsoft SQL Server, получив один-единственный неверный пакет, становился неработоспособным, так что система протоколирования событий оказывалась неработоспособной, как и сам сервер в целом. Средства, обладающие возможностью анализа сетевого трафика узла, позволяют отбрасывать подобные неверно сконструированные пакеты до того момента, как они начнут обрабатываться протоколами верхнего уровня, и, соответственно, до того, как сервер будет выведен из строя.
Однако все же один источник информации является общим для всех без исключения средств обнаружения атак уровня узла — это журналы регистрации событий. В принципе эти системы способны использовать в качестве источников информации журналы регистрации любого формата при условии, что в средстве реализованы соответствующие интерфейсы работы с ними. Например, все средства обнаружения атак уровня узла позволяют использовать в качестве источников событий журналы регистрации операционных систем, баз данных и приложений, которые оформлены в виде текстового файла с однозначной и формально описываемой структурой.
Поскольку журналы регистрации событий операционной системы узла являются наиболее ценным, а зачастую и единственным источником информации о несанкционированной деятельности пользователей на узле или о попытках атак, все системы обнаружения атак уровня узла позволяют задействовать их в качестве источника событий. Более того, изначальная настройка этих средств (настройка по умолчанию) подразумевает использование только этих журналов в качестве источника событий.
Соответственно, для корректного и эффективного функционирования средств обнаружения атак уровня узла необходимо наличие как минимум правильно настроенной подсистемы аудита операционной системы.
Однако даже корректно настроенной подсистемы аудита операционной системы и средств обнаружения вторжений может оказаться недостаточно для обеспечения должного уровня противодействия попыткам несанкционированного доступа к важным информационным ресурсам корпоративной сети.
Взгляд на аудит
Подсистема аудита операционной системы Windows (в данной статье мы рассматриваем только версии Windows 2000, XP, Server 2003) состоит из двух частей: службы регистрации событий и журналов регистрации событий. По умолчанию используется три журнала регистрации событий.
- System - журнал регистрации системных событий. В данный журнал заносятся записи обо всех событиях, связанных с функционированием операционной системы и установленных устройств (например, события, отражающие уровень загрузки операционной системы, запуск и остановку служб, сообщения об ошибках подсистемы ввода/вывода и другие подобные события);
- Application - журнал регистрации событий, связанных с работой различных приложений и прикладных служб, например баз данных;
- Security - журнал регистрации событий системы безопасности.
С точки зрения информационной безопасности и обнаружения атак на узел наибольшее значение имеет журнал безопасности. Именно поэтому, даже если журнал безопасности очищается, в нем все равно появляется запись о том, кем и когда это было сделано.
Кроме того, существует возможность расширения функциональности подсистемы аудита за счет добавления новых собственных журналов регистрации событий (однако общее число журналов не должно превышать 255), например, в том случае если сервер является контроллером домена, появляются еще три дополнительных журнала регистрации событий, связанные с функционированием службы каталога Active Directory.
Служба регистрации событий осуществляет запись событий в соответствующие журналы регистрации. В операционной системе Windows служба регистрации событий выполнена в виде службы Win32 и представляет собой DLL-модуль (eventlog.dll), загружаемый процессом services.exe.
В качестве источника событий данная служба использует следующие объекты операционной системы.
- Источники уровня ядра:
- ядро операционной системы и реализованные в нем подсистемы (подсистема ввода/вывода, управления процессами, памятью и прочие подсистемы);
- драйверы устройств, функционирующие на уровне ядра операционной системы;
- монитор информационной безопасности (Security Reference Monitor), реализованный на уровне ядра операционной системы.
- Источники уровня подсистемы Win32:
- подсистема информационной безопасности (Local Security Authority, LSA);
- службы подсистемы Win32 операционной системы (например, службы СУБД);
- приложения.
Механизмы, используемые операционной системой для передачи сообщений службе регистрации событий, для разных источников событий различны. Все источники событий уровня ядра используют один механизм для передачи событий службе регистрации, источники событий уровня подсистемы Win32 задействуют другой механизм.
Своим путем
Рассмотрим эти механизмы более подробно. Для начала отметим, что монитор информационной безопасности («нижний» уровень подсистемы информационной безопасности) не производит передачу событий непосредственно службе регистрации событий, а передает их подсистеме информационной безопасности LSA («верхнему» уровню подсистемы информационной безопасности), используя механизм локального вызова процедур (Local Procedure Call, LPC). В дальнейшем регистрацию событий от монитора безопасности производит подсистема LSA. Подобное описание механизма LPC выходит за рамки этой статьи, отметим только, что данный механизм основан на архитектуре клиент-сервер. Сервер создает объект типа «LPC-порт», имеющий имя. Клиент создает подключение к порту сервера, зная его имя. После того как подключение установлено, создаются два новых объекта типа «LPC-порт» — один для сервера, другой для клиента (client communication port и server communication port). Эти два объекта не имеют имен, а каждая взаимодействующая сторона получает описатель своего вновь созданного порта. После этого клиент начинает процесс передачи сообщений серверу, используя вновь созданные коммуникационные порты. Сервер производит обработку сообщений и, если это предусмотрено в формате сообщения, пересылает ответные сообщения клиенту (эта схема во многом подобна схеме функционирования сетевого обмена с использованием протокола TCP/IP). Когда сеанс заканчивается, клиент посылает серверу сообщение об отключении, используя именованный порт сервера. После этого безымянные коммуникационные порты клиента и сервера закрываются.
Для пересылки команд и обновления статуса монитора безопасности со стороны подсистемы LSA используется порт SeRmCommandPort. Для пересылки сообщений от монитора безопасности в подсистему LSA для дальнейшей их регистрации службой регистрации событий применяется порт SeLsaCommandPort.
Также механизм локального вызова процедур используется для регистрации событий, связанных с функционированием операционной системы, поступающих от подсистем ядра и драйверов устройств. Служба регистрации событий eventlog запускает отдельный поток (называемый MainLPCThread) для приема сообщений о необходимости записи событий от перечисленных выше источников. Для этого поток MainLPCThread открывает LPC-порт ErrorLogPort и ожидает клиентских подключений. Клиентами, подключающимися к данному порту и использующими его для пересылки сообщения, являются упомянутые выше источники режима ядра операционной системы.
Поток MainLPCThread принимает сообщения о необходимости записи событий в журнал регистрации двух типов: сообщения об ошибках ввода/вывода и сообщения об ошибках подсистемы управления сессиями (Session Management Subsystem). Соответственно, эти сообщения обрабатываются двумя различными функциями, реализованными в библиотеке eventlog.dll — ElfProcessIoLPCPacket (обработка сообщений о необходимости записи ошибок ввода/вывода) и ElfProcessSmLPCPacket (обработка сообщений о необходимости записи ошибок подсистемы управления сессиями). Эти функции осуществляют вызов процедур записи событий в журнал System. Возвращаемое ими значение поток MainLPCThread пересылает клиенту, пославшему сообщение данному потоку. Таким образом, клиент получает возможность узнать, удачно ли были записаны события в журнал регистрации.
Рассмотрим теперь механизм, который используется службами Win32 и приложениями для записи событий в журналы регистрации. Основной функцией записи событий в журнал регистрации является функция ReportEventW (ReportEventA для записи ANSI строк) библиотеки ADVAPI32.DLL. Этим программным интерфейсом пользуются все службы и приложения для записи событий в журналы регистрации, в том числе служба локальной системы безопасности (LSA). Функция ReportEventW, в свою очередь, осуществляет вызов процедуры регистрации события, используя механизм удаленного вызова процедур (RPC). Благодаря такой реализации функция ReportEventW имеет возможность регистрировать события на другом узле.
Механизм удаленного вызова процедур, как и механизм локального вызова процедур, основан на клиент-серверном взаимодействии. Процесс клиента отправляет серверу сообщение, в которое включены параметры вызываемой процедуры, и ожидает ответного сообщения с результатами ее работы. Вызываемая процедура выполняется на сервере. При получении ответа результат считывается, и процесс продолжает работу. Со стороны сервера процесс — обработчик вызовов находится в состоянии ожидания. При поступлении сообщения он считывает параметры процедуры, выполняет ее, отправляет ответ и переходит в состояние ожидания следующего вызова. В отличие от механизма LPC, в котором клиентский и серверный процессы работают на одном узле, концепция RPC подразумевает возможность распределенной работы, когда клиентский и серверный процессы запущены на различных узлах. Отметим также, что в том случае, когда клиентский и серверный процессы запущены на одном узле, для реализации механизма RPC используется механизм LPC.
Модуль службы регистрации событий eventlog.dll содержит RPC-сервер и является при взаимодействии серверным процессом. Библиотека ADVAPI32.DLL содержит клиентские вызовы процедур регистрации событий, реализованных внутри модуля eventlog. Прием запросов и последующую регистрацию событий со стороны RPC-сервера осуществляют две функции — ElfrReportEventW и ElfrReportEventA. Первая функция вызывается библиотекой ADVAPI32 для регистрации событий, содержащих строки в формате Unicode, ее аналог — ElfrReportEventA — вызывается для регистрации событий, содержащих ANSI-строки. Последняя функция выполняет подготовку данных и вызывает функцию ElfrReportEventW, которая в свою очередь вызывает процедуры работы с журналами регистрации, выполняющие запись событий в журналы и оповещение об их изменении.
Описанная выше схема работы подсистемы аудита и взаимодействия между различными ее компонентами показана на рис. 1.
Надежна ли подсистема аудита?
Как отмечалось выше, для надежного функционирования систем обнаружения вторжений уровня узла необходимо бесперебойное функционирование подсистемы аудита операционной системы. Под надежностью в данном случае следует понимать невозможность осуществления несанкционированного вмешательства в работу подсистемы. Пожалуй, самым опасным видом вмешательства является попытка перевода подсистемы аудита в такое состояние, в котором она перестает регистрировать происходящие в операционной системе события. Возникает вопрос: можно ли это сделать? Далее мы попытаемся ответить на него.
Первая и самая очевидная идея — это изменение политики аудита. Безусловно, после такого изменения события перестанут регистрироваться, но, во-первых, не все, а только события информационной безопасности, а во-вторых, и это, пожалуй, самое главное, в журнале событий безопасности (Security) появится запись об изменении политики аудита. На это событие наверняка отреагирует система обнаружения вторжений, установленная на узле, поскольку реагирование на изменение политики аудита операционной системы всегда присутствует в конфигурации по умолчанию для этих средств, и по понятным причинам данная реакция никогда не отключается.
Завершить процесс службы регистрации событий также не удастся. Дело в том, что служба регистрации событий запущена в операционной системе Windows не как отдельный процесс, а как набор потоков процесса services.exe. Процесс services.exe является критичным системным процессом, и, если его завершить (что, кстати, можно сделать, только имея привилегии отладки системы), сервер станет полностью неработоспособным и, более того, операционная система произведет автоматическую перезагрузку через одну минуту после завершения отказавшего процесса.
Далее можно попробовать приостановить службу регистрации событий eventlog. При помощи стандартного приложения панели управления Services это сделать не удастся из-за графического интерфейса. Однако невозможность остановки или приостановки данной службы кроется не в ограничениях, накладываемых графическим интерфейсом, а гораздо глубже.
Прежде чем пояснить, почему невозможна остановка службы регистрации событий, углубимся немного в архитектуру служб операционной системы Windows. Отметим только, что каждая служба представляет собой процесс, запущенный в фоновом режиме; она умеет принимать сигналы управления от диспетчера управления службами (Service Control Manager, SCM). Как правило, это сигналы на запуск, остановку, приостановку, возобновление работы после приостановки службы, а также запросы о текущем состоянии. Кроме того, операционной системой предусмотрено еще одно сигнальное сообщение, посылаемое службе в тот момент, когда система перезагружается или выключается. Соответственно, каждая служба содержит обработчик контрольных сигналов (Service Control Handler). От того, какие контрольные сигналы воспринимает этот обработчик, и будет зависеть возможность остановки или приостановки службы.
Поэтому неудачи остановки и приостановки службы регистрации событий связаны с тем, что обработчик контрольных сигналов, реализованный в службе eventlog, воспринимает только два сигнала — запрос текущего состояния и завершение работы операционной системы. Таким образом, остановить службу, осуществляющую регистрацию событий, невозможно ни с использованием графического интерфейса управления службами, ни при помощи программного интерфейса диспетчера SCM (данный программный интерфейс представлен набором функций библиотеки ADVAPI32).
Если все же попытаться послать службе eventlog сигнал о завершении работы операционной системы, в то время как узел продолжает функционировать и никакого реального завершения работы не происходит, это отрицательно скажется на работоспособности узла. Дело в том, что, как было отмечено при рассмотрении архитектуры службы регистрации событий и ее взаимодействия с источниками событий, клиентские процессы, взаимодействующие со службой регистрации событий с использованием механизмов LPC и RPC, ожидают от серверного процесса — службы регистрации событий — ответа на посланные ими запросы на регистрацию событий. Если же служба будет остановлена, клиентские процессы не дождутся ответа на свои запросы и прекратят ожидание только спустя некоторое время. Более того, каждый раз, выполняя новый запрос, они будут находиться в состоянии ожидания. Понятно, что в результате производительность сервера существенно снизится, а система обнаружения вторжений, не получив ответа на запросы к службе журнала регистрации, может вообще начать работать непредсказуемым образом.
Сделанные выше замечания наводят на мысль о высокой надежности службы регистрации событий операционной системы Windows. И действительно, нарушить его работоспособность, используя стандартные средства и программные интерфейсы, практически невозможно. Мы говорим здесь практически, поскольку существует ненулевая вероятность, что в реализации сложных интерфейсов взаимодействия службы с другими компонентами системы, а также в реализации программных интерфейсов управления службами и регистрации событий могут быть скрытые уязвимые места, используя которые можно добиться желаемого результата. Однако на данный момент таких слабых мест не выявлено, а все, что были обнаружены ранее, уже успешно устранены.
Возможная лазейка
Однако реальность оказывается не такой уж безоблачной, как хотелось бы разработчикам и пользователям операционной системы Windows. И виной тому возможность отладки процессов операционной системы, в том числе и критичных. Для того чтобы иметь возможность отладки процессов, необходимо иметь соответствующие привилегии, получить которые можно, только обладая правами локального администратора узла (либо локальной системы узла — контекст LocalSystem). Безусловно, это очень жесткое требование, однако оно выполнимо, учитывая периодически выявляемые уязвимые места Windows, позволяющие эти права получить.
Ниже будет описан механизм, позволяющий действительно приостановить работу службы регистрации событий. Для этого сделаем следующие предположения. Во-первых, допустим, что нам удалось получить права локального администратора узла. Во-вторых, будем исходить из того, что узел функционирует на платформе Intel X86 и не является узлом в кластере. Для всех рабочих станций и для большинства серверов последнее предположение является верным.
Для приостановки службы регистрации событий необходимо получить доступ к процессу services.exe с правами на чтение и запись содержимого его адресного пространства. Это можно сделать, имея привилегии отладки процессов (SeDebugPrivileges). Кстати, здесь возникает весьма резонный вопрос: почему операционная система предоставляет доступ к критичному системному процессу, тем более с правом на запись в его адресное пространство? Оставим этот вопрос на совести разработчиков операционной системы.
После того как мы получили доступ к процессу, необходимо выяснить адрес, по которому загружен модуль, реализующий службу регистрации событий, — библиотека eventlog.dll. Это можно сделать, используя стандартные процедуры Win32 API (Module32First, Module32Next).
Как было отмечено при описании архитектуры службы регистрации событий, основной процедурой, вызываемой для записи событий в журналы регистрации RPC-клиентами, является функция ElfrReportEventW. При этом важно отметить, что успешность записи события определяется клиентом только по коду возврата данной процедуры. Соответственно, если модифицировать тело процедуры таким образом, чтобы она сразу возвращала успешный статус записи события, не выполняя больше никаких действий, то RPC-клиент будет полагать, что событие действительно было записано в журнал регистрации. При этом не будет осуществляться оповещение об изменении журнала регистрации (которое настраивается при помощи вызова функции NotifyChangeEventLog, которой пользуются все системы обнаружения вторжений для выявления факта изменения журналов регистрации) и не будут увеличены внутренние счетчики событий службы регистрации. С точки зрения службы регистрации событий ситуация будет аналогична той, когда в системе не происходит никаких событий. Но это означает как раз корректную приостановку подсистемы аудита операционной системы Windows.
Только комплексно
Приведенные выше сведения позволяют прийти к заключению, что для обеспечения должного уровня информационной безопасности, и в частности для защиты информационных ресурсов от попыток несанкционированного доступа, применения средств обнаружения вторжений недостаточно. Описанные возможные способы приостановки подсистемы аудита только подтверждают необходимость использования комплексного подхода к построению надежно защищенных информационных систем.
Алексей Выдрин (vydrin@jet.msk.su) — сотрудник центра информационной безопасности отдела проектирования защищенных систем компании «Инфосистемы Джет»
Елена Булдаева (buldaeva@gubkin.ru) — ассистент кафедры «Информатика» факультета автоматики и вычислительной техники в Российском государственном университете нефти и газа им. И. М. Губкина