Cбор данных системами обнаружения атак

Виктор Сердюк,
ведущий специалист департамента «Технологии развития информационной безопасности»
ЗАО РНТ
vas@rnt.ru

В последние годы число информационных атак, зафиксированных в информационно-коммуникационных
системах (ИС), неуклонно увеличивается. Причин этого явления несколько. Прежде
всего возросло количество уязвимостей, ежедневно обнаруживаемых в программно-аппаратном
обеспечении ИС. Увеличилось и количество возможных объектов атаки: так, если
совсем недавно в качестве основных объектов несанкционированного воздействия
рассматривались исключительно серверы стандартных Web-служб (HTTP, SMTP и FTP),
то теперь появились средства для атак на маршрутизаторы, коммутаторы, межсетевые
экраны и другие компоненты ИС. Статистику по этим вопросам можно найти на сайте
CERT (http://www.cert.org/stats/cert_stats.html).

Следует отметить также, что программные средства для совершения атак сегодня стали весьма простыми, и обращение с ними не требует специальных знаний. В Интернете можно без труда найти немало программ, при помощи которых любой пользователь Сети сумеет организовать какую-либо «интересную» для него атаку, направленную на активизацию известных уязвимостей. Как правило, для применения этих средств исполнителю достаточно ввести IP-адрес объекта атаки и нажать соответствующую управляющую кнопку.

Кроме того, количество пользователей общедоступных сетей связи, в частности, Интернета, возрастает с каждым днем, причем доступ к глобальным сетям получают как отдельные клиентские рабочие станции, так и целые корпоративные сети. А с ростом числа пользователей увеличивается и количество потенциальных источников и объектов атаки.

Сложившаяся ситуация инициировала создание ряда организаций, специализирующихся
на сборе и систематизации сведений об имеющихся уязвимостях ИС, — это, например,
CERT (http://www.cert.org), Bugtraq (http://www.bugtraq.org)
и т. д. Интенсифицировалась разработка более эффективных инструментов противодействия
информационным атакам. К числу таких средств относятся системы обнаружения атак
(СОА) — специализированные программно-аппаратные комплексы, предназначенные
для выявления несанкционированных действий нарушителя в ИС.

Типовая архитектура СОА включает в себя как минимум пять групп функциональных
компонентов, которые могут быть территориально и функционально распределены
в ИС (рис. 1). К ним относятся:

• датчики (или сенсоры) для сбора необходимой информации о функционировании
  ИС;
• модули выявления атак, которые обрабатывают данные, собранные датчиками;
• модули реагирования на выявленные атаки;
• база данных, в которой хранится вся информация, собранная датчиками системы,
  а также информация о работе СОА;
• модули, выполняющие функции управления компонентами СОА.

Рис. 1. Обобщенная архитектура системы обнаружения атак.

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

Сетевые датчики

В системах обнаружения атак возможны два вида модулей датчиков — сетевые (network-based) и хостовые (host-based).

Сетевой датчик (СД) предназначен для сбора информации обо всех пакетах данных, передаваемых в рамках того сетевого сегмента, где он установлен. Как правило, это делается при помощи сетевого адаптера, у которого нет IP-адреса и который функционирует в так называемом смешанном режиме (promiscuous mode). Управление же датчиком организуется через выделенный сетевой интерфейс с заданным IP-адресом. Такой метод установки датчика делает его «невидимым» для возможных нарушителей, что практически исключает успешную сетевую атаку на оснащенный датчиком компьютер. Очевидно, что для эффективной работы СД необходимо, чтобы через него проходил весь трафик сегмента. Существует три базовых способа подключения СД к каналу связи: к одному из портов концентратора сетевого сегмента, к SPAN-порту коммутатора или установка непосредственно в канале связи.

В сетевой среде с некоммутируемыми каналами СД обычно подключают к одному из портов концентратора (рис. 2), а весь поступающий в него трафик автоматически транслируется на порт подключения.

Рис. 2. Схема подключения сетевого датчика к порту концентратора.

При наличии в сети коммутатора датчик можно подключать к SPAN-порту (Switched
Port Analyzer) этого коммутатора, причем на данный порт при помощи специальных
настроек можно транслировать сетевой трафик с других портов. В программных продуктах
Snort (http://www.snort.org) и NetProwler
(http://www.symantec.com) применяются
именно такие датчики, подключенные через концентратор или SPAN-порт коммутатора.
Если нельзя подключить СД к SPAN-порту, между коммутатором и датчиком устанавливается
дополнительный концентратор, который отвечает за дублирование трафика и направление
его на датчик.

Третий способ подключения — установка СД непосредственно в канал связи (рис.
3). Следует заметить, что в этом случае вычислительная нагрузка на датчик значительно
возрастает, поэтому для повышения эффективности его работы используется специализированное
аппаратное обеспечение. Такое решение реализовано в системе IntruShield (http://www.intruvert.com).

Рис. 3. Схема установки сетевого датчика в канал связи.

Хостовые датчики

Хостовые датчики (ХД) устанавливаются на узловые хост-компьютеры ИС и предназначаются
для сбора информации о происходящих на этих хостах событиях. В частности, они
получают сведения о сетевом трафике, поступающем на хост, и о системных событиях,
регистрируемых в журналах аудита операционной системы хоста. На одном узле можно
устанавливать сразу несколько ХД, которые будут собирать информацию из различных
источников. Системы обнаружения атак IntruderAlert (http://www.symantec.com)
и NFR HID (http://www.nfr.com) базируются именно
на хостовых датчиках.

Хостовые датчики, в свою очередь, можно разделить на два типа — интегрированные и внешние. Интегрированные ХД встраиваются в ОС или приложения, работающие на хосте, в то время как внешние датчики представляют собой отдельные автономные приложения.

К преимуществам интегрированных ХД по сравнению с внешними можно отнести меньший размер исполняемого кода (за счет того, что датчики этого типа интегрируются в уже существующие приложения и не содержат избыточной информации) и меньший объем оперативной памяти хоста, используемый датчиком, — к объему оперативной памяти, занимаемому приложением, добавляется лишь несколько дополнительных байтов. Кроме того, интегрированные ХД имеют доступ к большему объему данных. Функционируя в рамках приложения, интегрированный датчик имеет доступ к той же информации, что и само приложение, и это позволяет ему оперировать с любыми данными, необходимыми СОА для обнаружения атаки. Например, исходный код простейшего интегрированного датчика (см. врезку с листингом), позволяет обнаружить информационную атаку Land, которая сводится к посылке объекту нападения сформированного специальным образом TCP-сегмента с совпадающими IP-адресами получателя и отправителя, а также номерами портов отправителя и адресата сегмента.

case TCPS_LISTEN:
{
   ...
   if (ti->ti_dst.s_addr == ti->ti_src.s_addr)
   {
      printf("Зафиксирована информационная атака LAND");
      goto drop;
   }
   ...
}

Однако, поскольку применение интегрированных датчиков требует фактической модификации исходных кодов ОС и приложений, они могут использоваться только в UNIX-системах с открытыми кодами. Кроме того, очевидный недостаток таких датчиков — высокая сложность их практической реализации. А ведь даже случайная ошибка в исходном коде такого датчика может привести к нарушению работоспособности всего приложения, в которое встраивают датчик. Примером продукта, основанного на интегрированных датчиках, служит система обнаружения атак AAFID (http://cerias.purdue.edu).

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

Плюсы и минусы

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

Сравнительный анализ характеристик сетевых и хостовых датчиков

С учетом того, что и СД, и ХД имеют свои плюсы и минусы, на практике, как правило,
используются оба типа датчиков. Примером может служить система RealSecure (http://www.iss.net).

Типовая схема размещения датчиков в ИС (рис. 4) предполагает, что СД устанавливают как до, так и после межсетевого экрана, что позволяет обеспечить как защиту последнего, так и контроль его функционирования. Сетевые датчики следует также располагать в сегментах с большим количеством узлов, где применение хостовых датчиков нецелесообразно. Хостовые же датчики устанавливают на критических серверах ИС, которые должны быть защищены от информационных атак.

Рис. 4. Типовая схема размещения датчиков в ИС.

Методы сбора информации

Сетевые датчики обеспечивают сбор информации о передаваемых пакетах данных путем их перехвата только на канальном уровне модели ВОС. Метод реализации самого датчика в большинстве своем зависит от типа конкретной ОС. Так, датчик для UNIX-систем может быть реализован при помощи штатных библиотек этой ОС, позволяющих получить доступ к низкоуровневым функциям установленных в системе сетевых адаптеров. Поскольку в ОС Microsoft Windows такого рода библиотеки отсутствуют, СД для них, как правило, реализуются при помощи пакетных драйверов канального уровня. Пример такого драйвера — WinPCap (http://netgroup-serv.polito.it/winpcap), на основе которого, в частности, функционирует СОА Snort.

Хостовые датчики собирают информацию о событиях, происходящих на том узле, где они установлены. Источниками информации могут быть работающие приложения, системные сервисы ОС, аппаратные ресурсы хоста и т. д. Хостовый датчик может собирать исходную информацию двумя способами: опосредованно, через промежуточные программные компоненты, или напрямую — от источника.

При опосредованном сборе информации датчик использует вспомогательные информационные ресурсы хоста — как правило, журналы аудита ОС. Так, в ОС UNIX это журнал SYSLOG, а в Windows NT/2000 — системные журналы (System Log), журналы приложений (Application Log) и безопасности (Security Log). Основной недостаток такого метода сбора информации — невозможность фиксировать события в реальном масштабе времени, поскольку информация о событии записывается в журнал лишь спустя некоторое время, иногда вполне достаточное для успешного завершения атаки. Кроме того, при опосредованном методе повышается вероятность того, что нарушитель исказит содержимое журналов аудита и датчик не сможет собрать информацию, необходимую для обнаружения атаки. Тем не менее необходимо отметить, что в большинстве существующих СОА реализован именно опосредованный метод сбора исходной информации хостовыми датчиками.

Прямой сбор данных от заданного источника позволяет в реальном времени получить доступ непосредственно к той информации, которая требуется СОА. Однако для реализации этого метода необходимо расширить функциональные возможности датчика; как следствие, растет его потребность в программно-аппаратных ресурсах (которые датчику предоставляет «его» хост). Тем не менее очевидно, что ХД, реализующие прямой метод доступа к информации, более эффективны для сбора данных, а значит, позволяют своевременно выявить атаку.

На практике реализовать прямой сбор информации от источника гораздо сложнее,
чем использовать опосредованные методы. Поэтому часто выбирают компромиссное
решение — одновременное применение обоих способов получения данных. В частности,
в системе Entercept (http://www.entercept.co.uk)
реализован именно такой подход. В этой системе ХД располагаются на системном
уровне ОС и получают информацию о всех системных вызовах функций на контролируемом
хосте.

Подведем итог

Анализ существующих методов функционирования модулей различных датчиков и примеры эксплуатации коммерческих и академических СОА показывают, что наибольшим потенциалом обладают те системы обнаружения атак, которые одновременно используют как хостовые, так и сетевые датчики. Комбинированное применение средств сбора информации позволяет получать оптимальный объем данных, достаточный для выявления широкого спектра информационных атак. В этой связи необходимо подчеркнуть, что для достижения большего эффекта хостовые датчики СОА должны быть реализованы в виде внешних компонентов системы и использовать прямой метод доступа к информации.

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