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

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

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

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

* Каждый фрагмент должен сохранять информацию о своем месте, т.е. о смещении относительно исходного (нефрагментированного) пакета.

■ В каждом фрагменте должен быть указан размер передаваемых в нем данных.

■ Каждый фрагмент должен уведомлять о наличии следующих за ним фрагментов. Для этой цели служит флаг MF (More Fragments - следующий фрагмент).

Идентификационный номер IP (идентификатор фрагмента)

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

При фрагментации дейтаграммы все созданные фрагменты получают тот же идентификационный номер (идентификатор фрагмента). В следующей строке отчета TCPdump указан идентификатор нефрагментированного пакета, который имеет значение 202. ping.com > 192.168.244.2: icmp: echo request (ttl 240, id 202)

Если эта дейтаграмма на пути следования к адресату подвергнется фрагментации, то идентификатор всех фрагментов будет иметь значение 202. Данная строка отчета TCPdump получена с помощью указания в командной строке параметра -w. Этот параметр используется для получения расширенного отчета, в котором дополнительно показываются значения полей идентификатора и TTL (время жизни).

Все эти сведения содержатся в заголовке IP-дейтаграммы. После заголовка следует инкапсулированный фрагмент. Как уже указывалось, весь ТСР/1Р-трафик должен быть упакован в IP-дейтаграммы, так как именно протокол IP отвечает за доставку пакетов.

Фрагментация наглядно

При наглядной демонстрации процесса фрагментации (как говориться, “лучше один раз увидеть...”) мы будем считать, что .в качестве физической среды передачи данных используется сеть Ethernet. Рассмотрим сначала нефрагментированную дей таграмму (рис. 3.1). Как мы уже упоминали, максимальная единица передачи данных (MTU) в сети Ethernet равна 1500 байт. Каждая дейтаграмма должна иметь заголовок, стандартный размер которого составляет 20 байт, но может быть и больше при наличии параметров IP, например, маршрутизации от источника.

Рис. 3.1. Дейтаграмма для сети Ethernet

Напомним, что заголовок IP-дейтаграммы содержит сведения об ІР-адресах отправителя и получателя. Такая информация считается “сетевой” составляющей дейтаграммы, так как маршрутизаторы используют эти сведения для передачи дейтаграммы по адресу назначения. Инкапсулированные данные сохраняются после ІР-заголовка. Для их формирования могут использоваться различные протоколы транспортного уровня, такие как TCP, UDP или ICMP. Если, например, был использован протокол TCP, в 1480 байт данных содержится TCP-заголовок и ТСР-данные.

На рис. 3.2 представлена схема дейтаграммы, размер которой составляет 4028 байт. Это эхо-запрос ICMP, который должен быть передан в сеть Ethernet (MTU равно 1500 байт). Данный эхо-запрос слишком велик и не характерен для нормального трафика. Здесь он используется только для иллюстрации фрагментации. Итак, дейтаграмму размером в 4028 байт необходимо разделить на несколько фрагментированных пакетов длиной до 1500 байт. При этом в каждом пакете нужно по 20 байт для ІР-заголовка, поэтому для данных в каждом пакете остается по 1480 байт. На рис. 3.3 показана та же исходная дейтаграмма, но уже с указанием количества байтов, выделенных для каждого пакета при ее фрагментации. В следующих разделах подробно рассматривается каждый из трех созданных фрагментов.

Рис. 3.2. Фрагментация исходной 4028-байтовой дейтаграммы

Рис. 3.3. Распределение байтов данных по фрагментам

Последовательность фрагментов

Рассмотрим первый фрагмент созданной последовательности (рис. 3.4). В качестве идентификатора и первого, и всех остальных фрагментов копируется “исходный” идентификатор 1Р-дейтаграммы.

Только в первом фрагменте будет содержаться заголовок ICMP-пакета. Этот заголовок не копируется во все следующие фрагменты, что очень важно. Смещение первого фрагмента равно 0, его длина - 1480 байт, он имеет 1472 байт данных и 8 байт заголовка ICMP-пакета. Установленный флаг MF (More Fragments) означает, что этот фрагмент не является конечным в последовательности фрагментов.

Рис. 3.4. Начальный фрагмент

На рис. 3.5 представлена структура начального фрагмента. Его первые 20 байт из общих 1500 байт являются ІР-заголовком. Следующие 8 байт - заголовок ІСМР-пакета. Не забывайте, что это эхо-запрос, и что в исходном пакете присутствовали 8 байт ІСМР-заголовка. Оставшиеся 1472 байт начального фрагмента отведены для ICMP-данных.

Во всех фрагментах, кроме таких обычных полей заголовка IP-дейтаграммы, как IP-адреса отправителя и получателя, а также поля “Протокол” (в данном случае его значение определяет использование ІСМР), имеются специальные поля, используемые при фрагментации. Идентификатор фрагмента (в данном случае 21223) свя зывает все фрагменты в единую последовательность. Поле More Fragments (MF) указывает на наличие или отсутствие следующих фрагментов. В начальном фраг-менте этот флаг имеет значение 1. Кроме того, должно быть сохранено значение смещения данных этого фрагмента по отношению к расположению в исходной, нефрагментированной, дейтаграмме (для начального пакета это значение равно 0). И, наконец, длиной фрагмента считается длина передающихся в нем данных. В данном случае длина фрагмента составляет 1480 байт: 8-байтовый ICMP-заголовок плюс 1472 байт ICMP-данных.

Рис. 3.5. Содержимое начального пакета

Средний фрагмент

Рассмотрим следующий фрагмент нашей последовательности (рис. 3.6). Его 1Р-заголовок скопирован из заголовка “исходной” дейтаграммы. В этот новый 1Р-заголовок также копируется большая часть других исходных данных (например, 1Р-адреса отправителя и получателя). После заголовка размещаются 1480 байт ІСМР-данных. Смещение второго фрагмента равно 1480 байт, а его длина имеет такой же размер. Поскольку этот фрагмент не является последним, установлен флаг МР.

Рис. 3.6. Средний фрагмент

Продолжим изучение фрагментации и рассмотрим IP-дейтаграмму, использующуюся для передачи второго фрагмента (рис. 3.7). Как и для всех фрагментов единой последовательности в этой дейтаграмме используется 20-байтовый заголовок. В заголовке указано использование протокола ICMP, идентификатор фрагмента по-прежнему равен 21223, а установленный флаг МР указывает на наличие следующего пакета. Смещение равно 1480 байт по отношению к первому байту данных в нефрагментированной дейтаграмме (первые 1480 байт данных были отправлены в начальном фрагменте). Длина фрагмента также составляет 1480 байт, которые целиком являются 1СМР-данными.

Рис. 3.7. Содержимое среднего фрагмента

Стоит повторить, что ІСМР-заголовок из первого фрагмента не копируется во все остальные фрагменты с 1СМР-данными. Следовательно, по этому одному отдельному фрагменту нельзя сделать вывод о типе ІСМР-сообщения (в данном случае это эхо-запрос). Данный аспект имеет особое значение для работы фильтров пакетов.

Последний фрагмент

На рис. 3.8 изображен последний фрагмент нашей последовательности. Как и в других фрагментах, в заголовок его 1Р-дейтаграммы копируются значения полей исходной, нефрагментированной, дейтаграммы, например идентификатор фрагмента. После заголовка добавляются последние 1048 байт 1СМР-данных. В третьем фрагменте смещение имеет значение 2960 байт, а длина фрагмента равна 1048 байт. Так как этот фрагмент является последним, то для флага МР установлено значение 0.

Рис. 3.8. Последний фрагмент

Рассмотрим 1Р-дейтаграмму последнего фрагмента (рис. 3.9). Для 1Р-заголовка снова зарезервировано 20 байт. В оставшейся части фрагмента содержится последняя часть 1СМР-данных. Идентификатор фрагмента имеет значение 21223, а флаг МР не установлен, так как этот фрагмент - последний. Смещение составляет 2960 байт (сумма длин двух предыдущих 1480-байтовых фрагментов). В этом фрагменте передается только 1048 байт данных, причем все эти данные - остаток данных 1СМР-сообщения. В последнем фрагменте, как и во втором, не содержится 1СМР-заголовок.

Рис. 3.9. Содержимое последнего фрагмента

Фрагментация в отчетах TCPdump

Посмотрим на следующий отчет TCPdump. Три сохраненные записи соответствуют передаче по сети трех фрагментов, рассмотренных выше. Это означает, что на хосте, на котором запущен TCPdump, проведена сборка фрагментированного эхо-запроса.

ping.com > myhost.com: icmp: echo request (frag 21223:1480@0+)

ping.com > myhost.com: icmp: (frag 21223:148001480+)

ping.com > myhost.com: icmp: (frag 21223:148002960)

Первая строка содержит запись об отправке хостом ping.com эхо-запроса хосту myhost. com. Анализатор TCPdump смог распознать в этом фрагменте эхо-запрос, так как тот содержал 8-байтовый ICMP-заголовок. Теперь обратимся к обозначению фрагментации, содержащемуся в правой части строки. В TCPdump для указания фрагментированного трафика используется слово frag, после которого установлены идентификатор фрагмента (в данном случае 2122 3) и двоеточие. Далее указана длина данного фрагмента (14 8 0), символ @ и значение смещения данных (для первого пакета равно 0). Знак плюс (+) означает, что установлен флаг MF. Таким образом, по этому фрагменту можно определить предназначение “исходной” дейтаграммы, а также, что существуют следующие фрагменты, но не известно их количество и содержимое.

Вторая запись незначительно отличается от первой. Обратите внимание на то, что в ней отсутствует указание на эхо-запрос. Это объясняется тем, что в данном фрагменте нет ICMP-заголовка, и анализатор пакетов не в состоянии определить тип ICMP-трафика. В поле “Протокол” заголовка IP-дейтаграммы по-прежнему содержится значение, указывающее на протокол ICMP, но это вся информация, предоставляемая данным фрагментом. Во второй строке отчета TCPdump также указан идентификатор фрагмента (21223), длина его данных (1480) и смещение (1480). Знак плюс указывает на установку во фрагменте флага MF. Этот фрагмент участвует в общем процессе передачи данных, но сам ничего не знает о предназначении этих данных (чем-то напоминает первокурсника, правда?).

Последняя строка практически не отличается от второй записи. Тот же идентификатор фрагмента (21223), затем длина фрагмента (1048) и смещение (2 960). Единственным отличием является отсутствие установленного флага MF, но это вполне ожидаемо для последнего фрагмента. Этот фрагмент также не предоставляет никаких сведений о предназначении его данных.

Как хранится значение смещения данных

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

Значение смещения данных фрагмента занимает часть шестого байта и весь седьмой байт заголовка IP-дейтаграммы. Для его хранения используется 13-битовое поле, максимальное значение которого составляет 8191 (213-1). Теоретически, хотя и в исключительно редких случаях нормальной фрагментации пакетов, это значение может превышать число 8191, так как максимальный размер дейтаграммы составляет 65535 (216-1) байт. Для получения десятичного значения смещения данных в байтах хранящееся в этом поле число следует умножить на 8. Математическое толкование данного действия (тем, кому это интересно) выглядит следующим образом: 65536 (216) разделить на 8192 (2’3) равняется 8.

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

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

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

Если конкретный пакет не удовлетворяет условиям блокирования, например, из-за отсутствия заголовка вложенного протокола, то он пропускается фильтром пакетов. Фрагментированные TCP- и UDP-пакеты содержат заголовки только в первом фрагменте созданной последовательности. Часто решение о блокировании пакета принимается только на основании информации заголовка о порте получателя. Это означает, что фрагментированные TCP- и UDP-пакеты могут использоваться для обмана несовершенных устройств фильтрации пакетов.

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

Флаг DF

В некоторых строках отчетов TCPdump можно увидеть буквы DF, заключенные в круглые скобки. Это означает, что для данного пакета установлен флаг DF (Don’t Fragment - “Без фрагментации”), запрещающий его фрагментацию. Если дейтаграмма, для которой установлен флаг DF, должна пройти по сети, требующей фрагментации, то маршрутизатор отбрасывает эту дейтаграмму и возвращает отправителю ICMP-сообщение об ошибке.

В ICMP-сообщении об ошибке указывается значение MTU сети, в которой требуется фрагментация дейтаграммы. Некоторые хосты намеренно отправляют пробную дейтаграмму с установленным флагом DF, чтобы узнать минимальный MTU на пути к получателю. Если будет получено сообщение об ошибке с указанием MTU, то хост-отправитель уменьшит размер отправляемых пакетов до значения, которое позволит избежать фрагментации. Этот метод часто используется для TCP-трафика, так как применение протокола TCP требует значительной траты ресурсов. Одной из причин, по которым применение фрагментации нежелательно, является возможное снижение эффективности передачи данных - при потере одного фрагмента повторно должна быть отправлена вся последовательность. Можно догадаться, что злоумышленник тоже может применить данный метод для определения MTU сегмента сети. Это поможет ему впоследствии провести атаку с использованием фрагментированных пакетов. Нарушитель может создавать пакеты разной длины с установленным флагом DF и смотреть, когда появляется ICMP-сообщение об ошибке. Здесь предполагается, что атакуемая сеть не блокирует возвращение ICMP-сообщений об ошибках. В следующей строке отчета TCPdump содержится ICMP-сообщение о необходимости фрагментации пакета, для которого установлен флаг DF.

router.ru > mail.mysite.com: -icmp: Host.ru unreachable - need to frag (mtu 308) (DF)

Причиной появления этого сообщения явилась попытка отправки хостом mail.mysite.com хосту host.ru дейтаграммы с установленным флагом DF, размер которой превышает 308 байт. При прохождении этой дейтаграммы по сети к получателю хост router. ru обнаружил, что для следующего сегмента сети значение MTU составляет 308 байт, и без фрагментации дальнейшая передача дейтаграммы невозможна. Хост router.ru, определив, что для дейтаграммы установлен флаг DF, возвращает отправителю ICMP-сообщение, уведомляющее о проблеме. Таким образом, хост mail.mysite.com должен или создать дейтаграммы с размером меньше 308 байт (и фрагментация не потребуется) или сбросить флаг DF (и тогда будет проведена фрагментация на пути следования), а затем повторно отправить свою дейтаграмму.

Вредоносная фрагментация

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

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

В приложении Б, “Отказ в обслуживании”, описана одна из наиболее1 опасных атак отказа в обслуживании, при которых используется фрагментация, - атака Ping of Death. В следующий разделах рассмотрены несколько других атак с применением фрагментации.

Фрагментация заголовков ТСР-пакетов

Программа nmap является прекрасным средством сканирования. Она работает на многих платформах UNIX и доступна для загрузки по адресу www. insecure Гогд/nmap. Программа nmap осуществляет сканирование портов интересующего компьютера с целью выявления открытых портов, а также позволяет осуществлять скрытое (stealth) сканирование, усложняющее задачу выявления сканирования системами обнаружения вторжений. С помощью специального параметра командной строки (-f) nmap разбивает 20-байтовые заголовки ТСР-пакетов на несколько фрагментов с целью избежать их обнаружения. Например, пусть будет выполнена следующая команда, nmap -f -sS -р 53 target.com

Эта команда приведет к фрагментации SYN-пакета, служащего для установки соединения с портом 53 хоста target.com. Рассмотрим отчет TCPdump о результатах сканирования с помощью фрагментации ТСР-заголовка.

truncated-tcp 16 (frag 25096:16@0+) fragger.org > target.com: (frag 25096:4@16)

truncated-tcp 16 (frag 4265:16@0+) fragger.org > target.com: (frag 4265:4@16)

truncated-tcp 16 (frag 34927:16@0+) fragger.org > target.com: (frag 34927:4@16)

В данном случае хостом f ragger. org с помощью стандартного SYN-запроса выполнялось сканирование порта 53 хоста target. com. Но выявить сканирование не очень просто из-за того, что передаются небольшие фрагменты SYN-пакета.

В первой строке отчета содержится сообщение о получении 16 байт усеченного (truncated) ТСР-пакета. Минимальный заголовок ТСР-пакета равен 20 байт, поэтому TCPdump сообщает о получении 16-байтового пакета с помощью выражения truncated-tcp. В следующем фрагменте содержатся оставшиеся 4 байт ТСР-заголовка. Вполне вероятно, что система обнаружения вторжений ничего не выявит и не сообщит о подобном скрытом сканировании.

Teardrop

Ознакомившись с теоретическими основами процесса фрагментации, рассмотрим следующий отчет TCPdump. Можете ли вы самостоятельно обнаружить опасность фрагментации, связанную с использованием атакующей программы Teardrop?

evilfrag.com.139 > target.net.139: udp 28 (frag 242:36©0+) evilfrag.com > target.net: (frag 242:4@24)

Первым полученным фрагментом является UDP-пакет, идентификатор которого 242, длина - 36 байт и смещение - 0 байт. На рис. 3.10 этот фрагмент представлен в виде заштрихованного прямоугольника. Первый фрагмент начинается с байта 0 и заканчивается 35-м байтом включительно.

Теперь обратимся ко второму фрагменту. Он связан с первым, так как его идентификатор тоже имеет значение 242. Длина второго фрагмента - 4 байт, а смещение составляет 24 байт. Второй фрагмент выделен на рис. 3.10 сплошной заливкой. Таким образом, происходит замещение 4 байт (с 24 по 27 включительно) первого фрагмента.

Атака Teardrop использует слабое место процесса сборки фрагментов на хосте-получателе. Эта программа создает фрагменты, в которых указанное во фрагментах смещение приводит к затиранию доставленных ранее данных. При сборке таких фрагментов на хосте-получателе некоторые системы могут выйти из строя, зависнуть или начать перезагрузку. Эта атака была впервые применена в 1997 году и ярко продемонстрировала, какой ущерб могут наносить специально подготовленные фрагменты.

Некорректная или неполная последовательность фрагментов по-прежнему опасна для некоторых хостов. Совсем недавно появилась программа Jolt2 (более подробно она рассматривается в главе 5, “Воздействия и реакции”), которая с помощью отправки фрагментов с ненулевым смещением на хосты под управлением Windows (вплоть до Windows 2000) может вызывать отказ в обслуживании из-за возникшей нехватки ресурсов.

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

Рис. 3.10. Вредоносные фрагменты Teardrop

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

Анализ фрагментированного трафика

Хотите верьте, хотите - нет, но процесс фрагментации не такой уж сложный, если знать его теоретические основы и разбираться в обозначениях, используемых при его регистрации. Работая специалистом по вопросам безопасности и анализируя отчеты TCPdump, я много раз в уме решал задачу “что же не так с этим фрагментированным трафиком?". Здесь требуется нечто большее, чем обычные академические знания; теоретическая база для анализа трафика, проходящего по конкретной сети, должна обязательно сочетаться с мерами предосторожности против возможных атак, в которых используется фрагментация.

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

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

Резюме

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

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

Фрагментация пакетов | Обнаружение нарушений безопасности в сетях | Протокол icmp


Обнаружение нарушений безопасности в сетях



Новости за месяц

  • Июнь
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс