Задание правил для классических систем обнаружения атак

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

· адрес источника и получателя;

· порт источника и получателя;

· длину пакета;

· состояние соединения;

· полезную нагрузку (поле данных);

· флаги заголовка (для TCP-протокола).

Второй источник оперирует информацией, внешней по отношению к сетевым пакетам. Например, датой и временем их прохождения. Более подробно источники информации описаны в главе 4.

Существует несколько способов настройки шаблонов обнаруживаемых атак. Сделав доступными все сигнатуры (или отбросив меньшую их часть, если вы знаете, что некоторые вам не понадобятся) и наблюдая за событиями с консоли, можно определить, какие из сигнатур обнаруживаются в вашей сети, какие из этих событий являются наиболее важными, а какие нет. После того, как эти действия повторены на различных сегментах, можно создать конкретные шаблоны, предназначенные для сетевых сенсоров, устанавливаемых в различные точки вашей сети. Этот вариант достаточно прост и не требует никакой предварительной подготовки. Но здесь существует вероятность пропуска на практике тех событий, которые не зафиксированы в сети в процессе изучения сетевого трафика.

Второй способ предусматривает несколько шагов.

1. На основе карты сети составляется список протоколов, портов и адресов, доступных в защищаемом сегменте сети. Если при помощи системы обнаружения атак необходимо обезопасить сегмент, имеющий выход в сети открытого доступа (например, Internet), и сеть "огорожена" межсетевым экраном, то можно воспользоваться списком, применяемым на нем. Однако не стоит слепо доверять этому списку, — проверить его лишний раз не помешает.

2. На основе карты сети также составляется опись операционных систем и программного обеспечения, используемых в защищаемом сегменте сети. В данный список должны быть обязательно внесены все установленные обновления (Service Packs, Hotfixes и Patches). Без этого система обнаружения атак будет пытаться выискивать атаки, которые не могут принести никакого вреда подконтрольным ресурсам. Типичный пример — атака WinNuke (Windows Out of Band), которая способна повлечь нарушение функционирования узла под управлением ОС Windows NT или Windows 95. Но эта атака имеет смысл только для узлов с не установленным OOB-FIX поверх Service Pack 2 или 3. Во всех остальных случаях она абсолютно безвредна. Если же на узлах защищаемого сегмента сети установлено данное обновление, а в составленном списке об этом не сказано ни слова, то система обнаружения атак будет тратить ресурсы на поиск соответствующей ей сигнатуры в сетевом трафике. А если таких атак много, то производительность систем, их регистрирующих, может существенно упасть.

3. Вся собранная информацию помещается в таблицу, которая затем будет преобразована в правила для системы обнаружения атак.

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

5. В случае необходимости можно создать свои сигнатуры, временно отсутствующие в базе данных.

При настройке сигнатур атак желательно, чтобы они и правила, их использующие, базировались на числовом, а не на символьном представлении адреса отправителя и получателя. В противном случае, при неправильной конфигурации вашего DNS- или WINS-сервера или выведении его из строя злоумышленником система обнаружения атак будет неверно идентифицировать источник или цель атаки. И хотя само по себе числовое представлен адреса не очень удобно, оно может помочь обойти многие из потенциальных проблем. Идеальным вариантом является использование символьного представления, которое затем транслируется системой обнаружения атак числовое. Данный принцип заложен в межсетевой экран Check Point Firewall-1, который позволяет задавать так называемые сетевые объекты и присваивать им удобные и понятные символьные обозначения. Не правда ли, — имя Oracle_Finance_2Floor запоминается качественным образом легче, чем 10.12.34.56. В соответствии с тем же принципом работает и система RealSecure (рис. 10.8).

Рис. 10.8. Реализация механизма сопоставления числовых и символьных имен

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

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

Кроме того, изменить определенные встроенным сканером операционные системы уже нельзя.

Рис. 10.9. Реализация механизма предварительного сканирования

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