reforef.ru 1
Фрагментация как инструмент атакующего


[ Хакерство в Интернете ]

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


Механизм фрагментации

Фрагментация происходит тогда, когда IP датаграмма, проходя через сегменты сети (или через сети), должна пройти через сеть, MTU (maximum transmission unit) которой меньше размера данной датаграммы. Например, для Ethernet MTU составляет 1500 байт. В том случае если размер передаваемой датаграммы больше 1500 байт и она должна пройти через Ethernet сегмент, опорный маршрутизатор, перенаправляя ее в сеть Ethernet, обязан ее разбить на несколько фрагментов, отсюда и термин фрагментация. Мы рассмотрели случай когда фрагментацию выполняет маршрутизатор, существует еще один случай фрагментирования, который заключается в том, что при попытке отсылки хостом датаграммы в сеть с MTU меньшим нежели размер отсылаемой датаграммы также происходит его фрагментация.

После получения фрагментов хостом назначения происходит их сборка. Однажды уже разбитые датаграммы (ее фрагменты при первом фрагментировании) могут быть фрагментированны еще мельче, при пересечении сети с еще меньшим MTU нежели размеры передаваемых фрагментов. Фрагментация обычно используется атакующими для того, чтобы избежать выявления потенциально опасных для удаленной системы данных маршрутизаторами или IDS (Snort, Shadow, SANTA), которые на данное время уже научились различать разного рода фрагментацию достаточно грамотно, но тем не менее это не дает сто процентной гарантии неуязвимости системы оснащенной IDS.
Фрагментация как таковая подразумевает от администраторов глубоких знаний о принципах функционирования TCP/IP, форматах сегментов, датаргамм, принципов их формирования, передачи, обработки и много другого, что усложняет задачу. Необходимо попытаться разобраться в этом механизме, так как его понимание является залогом успешного анализа трафика (отделения нормальной фрагментации от злоумышленной, которая также может применяться для успешной реализации атак типа «отказа в обслуживании», DoS) с целью выявления потенциально опасных для системы данных. (Тот кто обладает вышеупомянутыми знаниями о tcp/ip и механизме фрагментации в частности, может перейти сразу же к разделу анализа).


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

- каждый фрагмент должен быть связан с каждым другим фрагментом с помощью общего идентификационного номера, этот номер содержится в заголовке IP в поле IP identificaiton number – идентификационный номер, или по другому идентификатор фрагмента (fragment ID), данное определении этого поля встречается чаще, т. е. вводятся общие признак для всех фрагментов;

– каждый фрагмент содержит данные о своем местонахождении, о смещении в исходном нефрагментированном пакете, т. е. вводится признак расположения в исходной датаграмме;
- каждый фрагмент должен сообщать длину переносимых данных, т. е. вводится признак общей целостности;
- каждый фрагмент должен знать, следуют ли за ним другие фрагменты, т. е. вводится признак упорядоченности.
Все вышеуказанные сведения содержаться в заголовке IP, вследствие чего можно сделать вывод, что фрагменты содержат исчерпывающие информацию необходимую для воссоздания первичной нефрагментированной датаграммы.
Ниже приведена общая блок-схема нефрагментированной датаграммы:
--------------------------------- | заголовок IP | другие данные | | 20 байт | 1480 байт | --------------------------------- Ethernet (MTU = 1500)
Как уже отмечалось выше, MTU Ethernet составляет 1500 байт, каждая датаграмма должна содержать заголовок IP, размер которого обычно 20 байт, но может быть и больше, если например заголовок содержит какие-либо параметры IP.
Как известно в заголовке IP содержится такая информация, как IP-адреса узла источника и узла назначения, чему дается определение – «сетевой» компонент датаграммы, эти данные используются маршрутизаторами для направления датаграммы к узлу назначения.
Теперь рассмотрим что происходит с датаграммной в процессе ее фрагментации, на примере ICMP echo-запроса, длинной 4028 байт, который сформирован для передачи в сеть Ethernet c MTU=1500 байт. Такой echo-запрос слишком большой, я думаю, что многие согласятся, что это странно для обыкновенного трафика. Но его размер выбран для иллюстрации механизма фрагментации. Так как MTU=1500 данную датаграмму необходимо разбить на несколько фрагментов по 1500 байт или меньше. В каждом из созданных фрагментов, будет содержаться 20-байтовый IP заголовок. Для данных остается 1480 байт.

Прежде чем приступить к рассмотрению данных которые содержаться в каждом фрагменте, необходимо ввести трактовку понятия которое встречались выше (идентификационный номер фрагмента): Идентификационный номер фрагмента (fragment ID) или идентификационный номер IP (IP identificaiton number) – это 16 битовое поле, находящееся в заголовке IP каждой датаграммы. Оно однозначно идентифицирует каждую датаграмму, посылаемую хостом. Как правило это значение инкрементируется (увеличивается на 1) при посылке датаграммы хостом.

При фрагментации датаграммы все ее фрагменты содержат одинаковые идентификационные номера IP, или идентификаторы фрагментов. Ниже показаны результаты tcpdump с параметрами (-vv) (пользователи операционных систем семейства Windows, могут использовать для этого любой сниффер, поддерживающий низкоуровневое отображение перехваченных пакетов, как правило для использования таких снифферов необходимо еще скачать пакет WinCap32 для низкоуровневой работы с пакетами, (идеальным условием изучения данного материала является наличие в сети 2-ух компьютеров и выше указанное программное обеспечения, также рекомендуется установить генератор пакетов, для генерации своих пакетов, иногда они являются встроенными в сниффер, например Com View 3.x и выше, я же предпочитаю не только tcpdump, а unix в целом)) для нефрагментированной датаграммы с идентификационным номером IP (23):
host1 -> 192.168.0.2: icmp: echo request (ttl 240, id 23)
Если же датаграмма станет фрагментированной, то все создаваемые из нее фрагменты будут иметь идентификатор равный 23.
Рассмотрим начальный фрагмент цепочки. Как было уже замечено выше, исходный заголовок IP копируется так, чтобы содержать одинаковые идентификационные номера фрагментов в первом и остальных фрагментах.
Первый фрагмент – единственный, который будет содержать заголовок сообщения ICMP. Этот заголовок не повторяется в последующих связанных с данными фрагментами, на что и следует уделить внимание. Данная концепция одиночного первого фрагмента, очень важна, что стане понятно ниже. Итак, смещение первого фрагмента равно 0, длина –1480 байт: 1472 байта данных и 8 байт заголовка ICMP, поскольку за этим следуют другие фрагменты, установлен флаг MF.
Рассмотрим состав первого фрагмента цепочки. Первые 20 байт из 1500 являются IP заголовком, а следующие 8 байт – заголовком ICMP. Остальные 1472 байта отведены для данных ICMP.

Кроме обычных полей заголовка IP, таких как IP-адреса источника и назначения и протокол, здесь есть поля специфичные для фрагментации. Идентификатор 23 связывает все фрагменты цепочки (общий признак). Поле флага MF указывает на то, что за текущим следуют и другие фрагменты. В первом фрагменте этот флаг установлен в 1, что свидетельствует о наличии дополнительных фрагментов. Кроме того, должно быть записано смещение данных в этом фрагменте по отношению к данным всей датаграммы. Для первой записи смещение равно 0. Длиной фрагмента является длинна переносимых им данных. В наше случае это длинна равна 1480 байт. Это 8-байтовый заголовок ICMP, за которым следуют первые 1472 байта данных ICMP.

Приступим к рассмотрению среднего фрагмента. В этот новый заголовок IP копируется большая часть других данных (номера источника и назначения). После нового заголовка IP встраивается 1480 байт данных ICMP. Как видим, смещение второго заголовка составляет 1480 байт. Длина имеет такой же размер, поскольку за этим фрагментом следуют другие фрагменты, установлен флаг MF.
Рассмотрим IP датаграмму переносящую второй фрагмент. Как и для всех других фрагментов данной цепочки, для него необходим 20-байтовый заголовок IP. Вновь протокол здесь указывается как ICMP. Идентификационный код здесь не меняется – 23. Флаг MF включен потому, что за ним следуют другие фрагменты. Смещение составляет 1480 байт в компоненте данных исходного ICMP сообщения. Предыдущий фрагмент занял первые 1480 байт. Длина этого фрагмента также 1480 байт, а состоит он полностью из байтов данных ICMP.
Следует повториться, так как это важно, что заголовок ICMP не копируется из первого фрагмента вместе с данными ICMP. Значит, при исследовании этого фрагмента отдельно от других тип сообщения ICMP определить невозможно.
В последнем фрагменте вновь заголовок IP наследуется из исходного заголовка с его идентификационным номером фрагмента, и копируются другие поля Последние 1480 байт данных ICMP встраиваются в эту новую датаграмму IP. Как видим, смещение третьего фрагмента равно 2960, а длина 1480 байт; поскольку за этим другие фрагменты не следуют, для флага MF указано значение 0.

Описание последнего фрагмента цепочки, вновь 20 байт зарезервировано для заголовка IP. Остальные байты данных ICMP переносятся в компоненте данных этого фрагмента. Идентификатор фрагмента равен 23, а флаг MF не установлен, так как это последний фрагмент. Смещение равно 2960 (сумма двух предыдущих фрагментов). В этом фрагменте переносится только 1048 байтов данных, причем состоит он из полностью оставшихся байтов сообщения ICMP. В этом фрагменте как и во втором нет заголовка ICMP, и поэтому тип сообщения ICMP не отражен.



Анализ фрагментации с помощью tcpdump
Рассмотри выходные данные полученные с помощью tcpdump, из результатов видно, что эти три разные записи представляют три обсуждавшихся выше фрагмента. Т. е. хост на котором был запущен tcpdump, собрал ICMP echo-запрос после фрагментирования:
host1.local > host2.local: icmp: echo request (frag 23:1480@0+)
host1.local > host2.local: (frag 23:1480@1480+)
host1.local > host2.local: (frag 23:1048@2960
Рассмотрим выданные результаты. В первой строке показано, что hos1.local посылает эхо-запрос ICMP на host2.local. Tcpdump идентифицирует это как эхо-запрос, потому, что в первом фрагменте содержится ICMP заголовок. В первой строке справа описан фрагмент (frag), за которым следует идентификатор фрагмента (23), длина текущего фрагмента 1480, 0+ смещение данных, + указывает на установку флага дополнительных фрагментов, т. е. фрагменту в первой строке известны назначение информации, то, что, он первый и что за ним следуют другие фрагменты но сколько их и какие они неизвестно.
Во второй строке, которая уже отличается от первой нет слова icmp, что указывает на то, что в фрагменте нет заголовка ICMP. Здесь идентификатор фрагмента –23, длина текущих данных 1480 и смещение 1480, установлен флаг дополнительных фрагментов.
В последней строке, результаты таковы: идентификатор фрагмента –23, длина 1048, а смещение 2960, и отсутствует флаг дополнительных фрагментов (+), что говорит о том, что этот фрагмент последний.


Фрагментация и фильтрация пакетов.

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

У нас возникла ситуация, когда в сеть пропускаются пакеты, которые не отвечают критериям блокировки, так как отсутствует заголовок идентифицирующий принадлежность пакета к тому или иному виду трафика (tcp, udp, icmp).
Если датаграмма с установленным флагом пересекает сеть, где необходима фрагментация, маршрутизатор выясняет это и возвращает посылающему хосту ICMP сообщение об ошибке. Данное сообщение указывает MTU сети, требующей фрагментации (данное ошибочное сообщение может использоваться атакующим для выяснения MTU некоторого сегмента сети где находится интересующая его цель и впоследствии может применять это значение для своих целей, например, для генерирования своих пакетов с данным MTU с целью обхода брандмауэра). Некоторые хосты в зависимости от используемой на них ОС (соответствующего стэка tcp/ip), намеренно посылают в сеть начальную датаграмму с установленным флагом фрагментации, определяя MTU на пути к хосту назначения. Если сообщение об ошибке ICMP возвращается с меньшим MTU, хостом производится пакетирование датаграмм, предназначенных для хоста назначения, в группы, которые малы, чтобы избежать фрагментации. В связи с этим фрагментация снижает эффективность работы сети в целом, поскольку при потере одного фрагмента нужно посылать опять их всех (на данной особенности строятся атаки типа «затопления» фрагментированными пакетами).


Фрагменты заголовков.
В известно сканере nmap существует опция –f, которая разбивает 20 – байтовые заголовки tcp на несколько фрагментов, что скрывает обнаружение сканирования, например:
#nmap –f –sS –p 53 host1.local
в результате, происходит фрагментированое соединение SYN с 53 портом хоста host1.local. Рассмотрим результаты, которые выдает tcpdump:
truncated-tcp 14 (frag 2301:14@0+)
host2.local > host1.local (frag 2301:6@14)
truncated-tcp 14 (frag 1321:14@0+)
host2.local > host1.local (frag 1321:6@14)
truncated-tcp 14 (frag 4191:14@0+)

host2.local > host1.local (frag 4191:6@14)

проанализируем данные результаты: в первой строке фрагмент с 14 байтами усеченных данных tcp (truncated-tcp), так как минимальный размер заголовка tcp 20 байт, то размер в результате говорит о том что он неполный. В следующей строке дополнительно посылаются еще 6 байт заголовка tcp (формируя таким образом 20 байтовый заголовок tcp), большинство систем обнаружения вторжений не сумеет определить факт сканирования.

UnError