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

Карен Фредерик

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

Основы Анализа Протокола

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

Поскольку системы обнаружения вторжения, как правило, исследуют характеристики IP, TCP, UDP и ICMP пакетов, они обычно способны расшифровывать некоторые, а иногда и все заголовки. Однако, только «продвинутые» IDS системы способны выполнять подробный анализ протокола. Такие IDS датчики выполняют полную расшифровку протокола для DNS, HTTP, SMTP и других широко используемых протоколов. Как из-за сложности расшифровки каждого протокола, так и в связи с большим количеством широко используемых протоколов, такой анализ требует дополнительных методов, по сравнению с простыми сигнатурами, типа “просмотра пакета”. IDS-датчики, выполняющие просмотр пакетов, просто ищут специфическую строку или последовательность байтов внутри пакета, причем датчик не знает исследуемый протокол, поэтому он способен идентифицировать только злонамеренную деятельность, имеющую очевидную, простую сигнатуру.

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

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

Сравнение сигнатур, основанных на анализе пакетов и анализе протоколов

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

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

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

Другие части сигнатур, основанные на анализе протокола, делали бы дополнительные проверки правильности различных команд и параметров, искали бы любые другие признаки аномальной или подозрительной деятельности. Такие проверки определяют известные уязвимости и неизвестные, использующие переполнения буфера или недопустимые параметры. Конечно, мы не можем предсказать существование неизвестных уязвимостей, но мы можем ожидать их, проверяя различные поля на необычные значения. Есть две первопричины для этого:

1. Уязвимость может использовать непредвиденное значение для специфического поля. Например, самый большой допустимый параметр для команды FOO может быть 64 символа, но нападающий определяет параметр с 500 символами.
   
2. Эксплоит, реализующий уязвимость, может быть плохо написан, используя необычные значения, которые подозрительны, но не связанны с уязвимостью. Например, значение заголовка протокола, почти всегда установлено на значение 1, но эксплоит очень часто устанавливает это значение в 16.

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

Выполнение анализа протокола на FTP трафике

Когда мы выполняем сетевое обнаружение вторжения, используя анализ протокола, мы исследуем значения заголовка и/или значения полезных данных для протокола. Это может охватывать невероятный диапазон сигнатур, от поиска некоторых строк в почтовых заголовках, указывающих на переносимый электронной почтой саморазмножающийся вирус, до подозрительного URL, который может указывать на нападение на Web-сервер, или FTP-команду, параметр которой содержит shellcode. Для иллюстрации, мы рассмотрим характеристики некоторой реальной и гипотетической FTP-уязвимости, и обсудим, какие методы анализа протокола могут их идентифицировать.

Переполнение буфера в команде FTP MKD происходит при снабжении очень длинным параметром, содержащий shellcode. Типичная сигнатура анализа пакета, содержит последовательность shellcode (от 10 до 20 байтов) и должна соответствовать последовательности внутри FTP пакета. Анализ протокола позволяет нам идентифицировать параметр к команде MKD и проверять, что он не имеет чрезмерную длину, и что он не содержит двоичные данные. Оба эти условия указывают на попытку использовать переполнение буфера. Проверяя этот параметр вместо поиска специфических shellcode последовательностей, мы определим все возможные попытки эксплуатации этой уязвимости, а не только известные эксплоиты. В случае сканирования пакета, хакер или червь легко может избежать обнаружения, изменяя shellcode; но с сигнатурами анализа протокола этот номер не пройдет.

Команда FTP "SITE EXEC" может использоваться для выполнения команд на FTP сервере, и это используется во многих нападениях. "SITE" фактическим является названием FTP команды, и "EXEC" является параметром к команде "SITE". Сигнатура анализа пакета ищет "SITE EXEC" в пакете, ища не чувствительное к регистру соответствие такой строки. При анализе протокола ищется команда FTP "SITE" с параметром "EXEC". В чем же кардинальное различие? В первом случае нападающие легко могут уклониться от обнаружения IDS-датчиками, всего лишь добавив лишний промежуток между "SITE" и "EXEC", типа нескольких пробелов или табуляций. Большинство FTP серверов игнорируют дополнительные места, так что для них "SITE EXEC" и "SITE EXEC" - одна и та же команда. При анализе пакета, сигнатура, которая сравнивает строки, не может соответствовать этим двум строкам; сигнатура же анализа пакета, поймет команду "SITE EXEC" и любую ее разновидность, позволяя более аккуратно идентифицировать нападение.

Заключение

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