Сигнатуры систем обнаружения вторжения, часть первая. Библиотека I2R. Это первая часть из цикла статей, посвященных пониманию и развитию сигнатур для систем обнаружения вторжения. В этой статье мы обсудим основы IDS сигнатур и подробнее остановимся на сигнатурах, использующих значение IP, TCP, UDP и ICMP заголовков.

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

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

Основы сигнатур

Сетевая IDS сигнатура - набор данных, которые мы хотим найти в трафике. Рассмотрим некоторые примеры и методы, которые позволяют их идентифицировать:

Попытки подключения с зарезервированного IP-адреса. Могут быть легко обнаружены простой проверкой поля адреса в IP-заголовке.
Пакеты с недопустимыми комбинациями TCP-флажков. Могут быть найдены сравнением набора флажков в TCP заголовке с известными допустимыми или недопустимыми комбинациями флажков.
Электронные сообщения, содержащие определенные вирусы. IDS может сравнить имя поля объекта или вложения с известными именами, связанными с известными вирусами.
Переполнение буфера в DNS при использовании недопустимого запроса. Анализ DNS полей и проверка длины каждого из них помогает идентифицировать попытку переполнения буфера.
DoS против POP3 сервера путем вызова одной и той же команды тысячи раз. Сигнатура для этого типа нападения должна хранить информацию о том, сколько раз была вызвана команда и предупреждение, когда это число превысит некоторый порог.
Попытка запроса файла на FTP сервере без предварительной регистрации. Сигнатура должна предупреждать в случае, когда произошла попытка вызова команды без подтверждения подлинности.

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

Для чего вообще нужны сигнатуры?

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

Значения заголовков

Теперь давайте рассмотрим простую характеристику сигнатуры: значение заголовка. Некоторые значения заголовка ясно подозрительные, так что они и будут первыми кандидатами на сигнатуру. Классическим примером этого является TCP пакет с набором флажков SYN и FIN. Это - явное нарушение RFC 793 (которым определяется TCP стандарт), что и используется во многих инструментальных средствах атаки для прохождения межсетевых защит, маршрутизаторов или систем обнаружения вторжения. Многие эксплоиты включают значения заголовка, преднамеренно нарушающее правила RFC, так как многие операционные системы и прикладные программы написаны при условии, что законы RFC соблюдаются, поэтому и не исполняют надлежащей обработки ошибок трафика. Также, некоторые инструментальные средства могут содержать случайные или преднамеренные ошибки кодирования так, чтобы пакеты, произведенные ими, содержали значения заголовков, нарушающих законы RFC. И плохо написанные программы, и различные методы вторжения содержат расхождение характеристик заголовков, что может использоваться для создания сигнатуры.

Эти звучит красиво и просто, но в данном вопросе существует множество подводных камней. Так, не все операционные системы и прикладные программы твердо придерживаются правил RFC. Фактически, многие программы имеют какие-то аспекты поведения, нарушающие RFC. Также, со временем протоколы могут изменяться и получать новые возможности, ранее не включенные в RFC. И новые стандарты появляются время от времени, что также может "легализовать" действия, которые ранее были запрещены. Так RFC 3168 в разделе Explicit Congestion Notification (ECN), является хорошим примером этого. Так что сигнатура IDS, основанная на устаревших правилах RFC, может производить множество сигналов ложной тревоги. Тем не менее, RFC могут являться неплохим базисом для развития сигнатур, потому что множество злонамеренных действий явно нарушают RFC. Так как периодически правила RFC обновляются, кроме того, существует ряд других факторов, которые мы рассмотрим дальше, поэтому важно периодически пересматривать и модифицировать существующие сигнатуры.

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

Идентификация возможных компонентов сигнатуры

Лучший способ понять проблемы разработки сигнатур, основанных на значениях заголовков - рассмотреть конкретный пример. Так, synscan - инструмент, широко используемый в исследовании систем. Активность synscan в Internet в начале 2001 определялась на очень высоком уровне, потому что его код использовался для создания червя Ramen первой волны. Пакеты имели лишь несколько различающихся характеристик. Примеры из части IP и TCP заголовка, которые существовали в пакетах червя Ramen. (Обратите внимание, что блок сконфигурирован так, чтобы тихо остановить незапрашиваемый трафик, так что мы видим первый пакет каждой попытки.)

различные источники IP-адреса
TCP порт источника 21, порт адресата 21;
Тип сервиса (Type of service, ToS) 0;
IP identification number 39426;
Набор флажков SYN и FIN;
Различные наборы sequence numbers
Различные наборы acknowledgment numbers
Размер TCP window 1028

Теперь, когда мы знаем, каковы характеристики заголовков synscan пакета, мы можем рассмотреть, как должна бы выглядеть хорошая сигнатура. Следует искать значения, которые являются необычными или подозрительными - в большинстве случаев, эти характеристики соответствуют уязвимости, которую хакер пробует эксплуатировать, или определенной методике, используемой для нападения. Значения пакета, которые являются полностью нормальными, не годятся для создания хороших характеристик сигнатуры, хотя они и часто включаются, чтобы ограничить количество трафика. Например, мы можем включить нормальное значение 6 для IP протокола, чтобы проверять только TCP пакеты. Но другие характеристики, также полностью нормальные, типа type of service, равны 0, гораздо менее полезны для сигнатуры.

Некоторые характеристики synscan пакетов аномальные и могли бы использоваться в сигнатурах:

наличие только SYN и FIN флагов - известный признак злонамеренной активности.
другой признак - то, что acknowledgment number имеет самые различные значения, но флаг ACK не установлен. А ведь когда такой флаг не установлен, acknowledgment number должен быть равен 0.
еще одна подозрительная характеристика - то, что и порты источника, и адресата установлены 21, что обычно связано с FTP серверами. Когда эти порты равняются друг другу, мы говорим, что они рефлексивны. За несколькими исключениями (типа некоторых типов трафика NetBIOS), мы не должны видеть равенство этих значений. Рефлексивные порты, в принципе, не нарушают стандартов TCP, но такая ситуация выглядит крайне необычной и подозрительной. В нормальном FTP трафике стоит ожидать более высокий номер порта (более 1023) для источника, и порт 21 для адресата

Вот мы и идентифицировали три вероятных элемента сигнатуры: набор SYN и FIN флагов, ненулевой acknowledgment number без наличия ACK флажка и рефлексивные порты 21. Есть еще два элемента, на которые также стоит обратить внимание: TCP window size, всегда установленный на 1028, и IP identification number, который установлен во всех пакетах, скажем на 39426. Как правило, стоит ожидать, что TCP window size будет большим, чем 1028; хотя это значение и не является запрещенным, может, это всего лишь совпадение, но все же эту странность стоит проверить. Аналогично, IP identification number, установленный во всех пакетах на 39426. IP RFC определяет, что это значение должно изменяться в разных пакетах, так что постоянное значение очень подозрительно.

Выбор сигнатуры

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

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

Давайте предположим, что одна из целей нашей сигнатуры состоит в том, чтобы определить используемый инструмент атаки. Так, помимо определения SYN и FIN, какие параметры из отобранных нами стоит анализировать? Допустим, рефлексивные портовые числа подозрительны, но они не обеспечивают достаточно определенную сигнатуру, так как много средств атаки используют их, также как и некоторый законный трафик. Набор значения ACK без флажка ACK, бесспорно, недопустим и мог бы использоваться в сигнатуре как сам по себе, так и в комплекте с соединением SYN и FIN. window size 1028, хотя и является немного подозрительным, но может происходить естественно. Также, как и IP identification number 39426. Мы можем разработать несколько сигнатур, которые используют различные комбинации этих характеристик. В ряде случаев не бывает единого мнения, что будет лучшей сигнатурой, особенно из-за того, что оптимальная сигнатура быть разной в разных операционных средах, а также меняться со временем.

Но все эти примеры и случаи мы рассмотрим далее.

	Библиотека Интернет Индустрии I2R.ru	Малобюджетные сайты... Продвижение веб-сайта... Контент и авторское право...
Забобрить! Блог		Поиск:	Рассылки для занятых...»

Библиотека Интернет Индустрии I2R.ru

Малобюджетные сайты...

Продвижение веб-сайта...

Контент и авторское право...