Результаты

Действительно существуют различия в реализации стеков протоколов целевых систем и IDS. Эти различия, прежде всего, основаны на неполном описании межсетевого взаимодействия и ошибках проектирования. Большинство таких различий основывается на разном порядке обработки фрагментированного трафика. Также встречались явные недоработки в IDS, например, IDS Snort и Dragon принимают IP-пакеты с неправильной контрольной суммой, а IDS RealSecure 6.0 и eTrust 1.0 — с неправильной версией протокола IP.

Очень много различий основано на некорректной реализации стеков. Это приводит к тому, что одни и те же ситуации обрабатываются по-разному различными системами. В качестве примера можно привести недостатки в работе IDS Dragon при анализе трафика, направленного ОС Linux RedHat.

Прием пакетов, направленных на неправильный Ethernet-адрес.

Прием пакетов с неправильной контрольной суммой IP.

Прием TCP-сегментов со смещением данных меньше 20 октетов или равным 0.

Отсутствие обработки данных, если они пришли в TCP-сегменте, с установленным флагом FIN.

Прием данных полностью, если они пришли в пакете с неправильным номером очереди. (Согласно спецификации протокола TCP, место полезной информации, передаваемой конкретным TCP-сегментом, строго определяется его номером очереди; в случае неправильного номера, целевая система "отрезала" лишние данные.)

Прием IP-фрагментов, направленных на неверный Ethernet-адрес.

Прием IP-фрагментов с неправильной контрольной суммой IP.

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

IDS не обрабатывает поток TCP-фрагментов, пришедших в обратном порядке.

IDS оставляет новые данные при посылке частично перекрывающихся TCP-фрагментов, тогда как операционная система оставляет старые.

Также интересны результаты работы IDS RealSecure 6.0, анализирующей трафик для Windows 2000.

RealSecure 6.0 принимает пакеты, направленные на неправильный Ethernet-адрес.

IDS принимает пакеты с неправильной версией IP-протокола.

IDS принимает данные полностью в случае посылки их в TCP-сегменте с неправильным номером очереди, тогда как операционная система "отрезает" лишние данные.

IDS принимает IP-фрагменты, направленные на неправильный Ethernet-адрес.

IDS принимает IP-фрагменты с неправильной версией IP-протокола.

IDS принимает TCP-фрагменты, направленные на неверный Ethernet-адрес.

IDS принимает TCP-фрагменты с неправильной версией IP-протокола.

IDS не в состоянии обработать поток TCP-фрагментов в случае посылки их в произвольном порядке.

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

Это же относится и к обработке потока TCP-фрагментов, например Dragon 5.0 и RealSecure 6.0 были не в состоянии обработать некоторые случаи: Dragon 5.0 просто выходил из строя после получения повторяющихся TCP-фрагментов и не обрабатывал поток TCP-фрагментов, пришедших в обратном порядке; RealSecure 6.0 не смог обработать TCP-фрагменты, пришедшие в произвольном порядке. Получается, что для нарушения работы IDS можно просто послать сигнатуру атаки в различной последовательности TCP-фрагментов. Dragon 5.0 не рассматривал TCP-сегменты с установленным флагом FIN, даже если они несли полезную информацию.

Особо следует отметить тот факт, что IDS Snort (как для Win32, так и для Linux), не смогла обработать HTTP-запрос, начинающийся с двух символов возврата строки. Целевая система смогла это сделать после правильного подбора номеров очереди (она просто «отрезала» эти символы в начале запроса), что делает Snort также уязвимым к проведению сокрытой атаки методом уклонения. Помимо этого, Snort еще имел восемь несоответствий при работе с Linux и Windows 2000, три из которых связаны с обработкой некорректных заголовков и пять — с различными комбинациями IP- и TCP-фрагментов.

Итак, тестирование выявило следующее количество различий в работе стеков.

Snort 1.8.4 for Linux с RedHat Linux 7.2 - 10 различий: 4 основаны на разной обработке некорректных заголовков, 1 - на обработке неправильного HTTP-запроса и 5 - на обработке фрагментированного трафика.

Snort 1.8 for Win32 с Windows 2000: те же различия плюс еще одно при обработке фрагментированного трафика.

Dragon 5.0 с Linux Red Hat 7.2 - 10 различий: 5 связаны с фрагментами, 1 - с установленным флагом FIN и 4 - с обработкой некорректных заголовков.

eTrust ID 1.0 с Windows 2000 - 8 различий: 5 - фрагментированный трафик, 3 - некорректные заголовки.

Real Secure 6.0 с Windows 2000 - 8 различий: 5 - фрагментированный трафик, 3 - некорректные заголовки пакетов.

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

Содержание раздела