Сигнатуры систем обнаружения вторжения, часть вторая

Karen Kent Frederick , перевод securitylab

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

Оценка эффективности сигнатуры

В предыдущей статье мы рассмотрели характеристики пакетов, посланных инструментом synscan (как это осуществлено в черве Ramen) и идентифицировали черты, которые были необычны или подозрительны, или нарушают существующие стандарты. Тогда же мы попробовали определить, какие из этих характеристик годятся для создания хорошей сигнатуры. Теперь, основываясь на этих характеристиках, давайте создадим сигнатуру, которая будет искать все три следующие признака в каждом TCP пакете:

• Только набор SYN и FIN флагов
• IP identification number 39426
• TCP window size 1028

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

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

Теперь перед нами стоит гораздо более интересная задача – как развить сигнатуру для обнаружения всех вариантов инструмента synscan, то есть для блокирования не только конкретной версии червя Ramen, но и всех его модификаций и аналогов. Требуется создать набор сигнатур, который мог бы обнаруживать не только известные типы атак, но также и будущие и неизвестные варианты такой атаки. Исследуем эту концепцию более подробно.

Добавление данных к сигнатуре

За неделю активной деятельности червя Ramen/synscan, кроме тех пакетов, на основании которых мы создавали сигнатуру, приходили и другие схожие, но с некоторыми важными различиями:

• Вместо флагов SYN и FIN, был установлен только флаг SYN. Это - нормальная характеристика TCP пакета
• TCP window size был всегда 40, а не 1028. 40 - необычно маленький размер окна для начального SYN пакета и, конечно, гораздо менее вероятен в нормальном пакете, чем 1028.
• Reflexive port number был 53, а не 21. Старые версии BIND, действительно, использовали рефлексивные порты для некоторых операций, но более новые версии BIND этого не делают, так что вряд ли можно сейчас часто встретить рефлексивный порт TCP, да еще и именно 53.

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

Общие характеристики, которые могли бы быть полезны для этого:

• TCP пакеты с ненулевым acknowledgement number, но флаг подтверждения не установлен.
• TCP пакеты только с SYN и FIN флагами 
• TCP пакеты с изначально установленным TCP window size ниже, некоторого определенного значения (которое включило бы и 40)

Две из этих трех общих сигнатур соответствовали бы обоим типам пакетов, которые мы рассмотрели.

Идентификация аналогичного трафика

Через несколько недель после появления второй версии червя, использовавшего другой вариант synscan, стали появляться пакеты с практически теми же самыми характеристиками. Фактически, единственным, но зато крайне важным отличием было то, что IP identification number больше не был статическим. Самое вероятное объяснение этого - эта третья группа пакетов была создана новым вариантом synscan. Похоже, кто-то взял часть программного кода synscan и создал на основе него новый инструмент, в котором больше не будет статичного IP identification number. Это маскирует деятельность synscan под обычный трафик, делая ее более тайной с точки зрения систем обнаружения вторжения, так как устраняется одна из основных характеристик, по которой защитные системы IDS определяли  вторжение.

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

Если мы все еще хотим, то можем создать и определенную детальную сигнатуру для нового варианта. Здесь все зависит от цели, которую мы перед собой ставим. Большинству людей практически безразлично, каким инструментом их пытаются атаковать – главное знать, что вы сможете отбиться от нападения, и ничего плохого не случится. Но в ряде случаев существует  сильная потребность выяснить методы и намерения атакующего. Если вы просто приводите в готовность ваши защитные системы на вообще весь аномальной трафик, то вы сможете отбиться, но не сможете определить направленность действий хакера. Базируя же сигнатуры на глубоком исследовании потенциальных нападений и уязвимостей, развитии наборов подписей, объединении общих и специфических подписей, мы сможем идентифицировать вероятный источник угрозы, механизм действий хакера и его цели.

Примечания относительно значений заголовков

В примерах мы видели, как значения заголовков могут использоваться для создания  сигнатур для IDS. Вообще, наиболее часто используемые элементы сигнатуры это:

• IP-адреса (particularly reserved, non-routable, broadcast addresses)
• Port numbers, которые не должны быть использованы (особенно всем хорошо известные порты для специфических протоколов и троянов)
• Необычная фрагментация пакетов
• Специфические комбинации TCP флагов
• Типы/коды ICMP, которые обычно не наблюдаются

Конечно, любые значения заголовков могут использоваться в сигнатурах, приведенные выше параметры всего лишь наиболее часто используемые из многих других.

Есть еще одна проблема, которую мы не рассмотрели – какие пакеты стоит проверять. Если мы используем сигнатуру, основанную на значениях заголовков, то мы должны определить, какие пакеты стоит проверять - все или только некоторые? От этого много зависит. Пакеты ICMP и UDP – пакеты без установления соединения, имеет смысл проверять все из них. А TCP пакеты – пакеты на основе соединения, иногда  достаточно проверять только первый пакет. Например, некоторые характеристики типа адресов и портов останутся постоянными во всех пакетах, так нет смысла проверять их несколько раз. Другие характеристики - типа TCP флагов, необходимо проверять в каждом пакете сессии, если мы ищем специфические комбинации флагов. Очевидно, чем большее количество пакетов мы проверяем, тем большее количество времени и ресурсов будет на это затрачено.

Можно задаваться вопросом - почему мы сосредоточились на значениях IP, TCP, UDP и  ICMP заголовков, и не упомянули другие, типа DNS. Причина имеет отношение к методу структурирования пакетов. Помните, что TCP, UDP и ICMP - все это IP протоколы, так что их заголовки и содержимое расположены внутри IP-пакетов. Чтобы получать данные TCP заголовка, например, мы сначала нуждаемся в разборе IP заголовка, так что мы можем определить его содержимое. Другие протоколы, такие как DNS, содержатся внутри UDP и TCP содержимого пакетов, так что нам требуется пройти два уровня разбора (IP и UDP или TCP) чтобы добраться до них. Требуется гораздо больший объем программной работы, чтобы декодировать многие из этих протоколов, по сравнению с относительно простой структурой заголовков TCP, UDP и ICMP. Мы рассмотрим это более подробно в следующих статьях  по данной теме.

Заключение

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

В следующей же статье мы рассмотрим более изощренные и интересные сигнатуры, основанные на использовании содержимого TCP, UDP и ICMP - протоколов типа DNS, FTP, HTTP и SMTP.