IP-фрагментация как способ проникновения через Firewall

Как известно из описания протокола IP (RFC 791),максимальный размер IP-пакета может достигать 216-1 байт. Однако размер пакета (дейтаграм-мы), передаваемого непосредственно по каналу передачи, зависит от типа среды передачи. Например, в среде Ethernet максимальный размер дейтаграммы 1500 байт, в среде ATM - 56 байт. Поэтому для того, чтобы IP-пакеты могли передаваться по сетям любых типов, в протоколе IP предусмотрена фрагментация пакетов. То есть для передачи одного большого пакета он разбивается на соответствующее количество пакетов меньших размеров (их размер обуславливается максимальным размером пакета в соответствующей среде передачи). Этот процесс разбиения IP-пакета на части называется IP-фрагментацией. Применение в сети Internet фрагментации пакетов делает ее более гибкой и инвариантной по отношению к разнообразным физическим средам передачи. На рисунке 4.12 приведен формат IP-пакета версии IPv4.

Не будем вдаваться в подробности, что означает каждое поле в IP-заголовке (RFC 791), так как в данном случае нас будут интересовать только поля Fragment Offset и Flags. В поле Fragment Offset содержится значение, измеряемое восьмерками байт, обозначающее смещение фрагмента относительно начала дейтаграммы (именно на то, что оно измеряется в восьмерках байт, и не обратил внимание д-р F. B. Cohen в его статье "Packet Fragmentation Attacks" [28]). Таким образом, единица в этом поле означает смещение на 8 байт от начала дейтаграммы. Поле Flags показывает фрагментирован ли пакет или нет.

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

Рис. 4.12. Формат IP-пакета версии IPv4.

4-bit Version	4-bit Header Length	8-bit Type of Service	16-bit Total Length
16-bit Identification	3-bit Flags	13-bit Fragment Offset
8-bit Time to Live	8-bit Protocol	16-bit Header Checksum
32-bit Source Address
32-bit Destination Address
Options & Padding
Data

Рис. 4.13. Формат TCP-пакета.

16-bit Source Port Number	16-bit Destination Port Number
32-bit Sequence Number
32-bit Acknowledgement Number
4-bit Header Length	6-bit Reserved	6-bit Flags	16-bit Window Size
16-bit TCP Checksum	16-bit Urgent Pointer
Options & Padding
Data

Рис. 4.14. Формат UDP-пакета.

16-bit Source Port Number	16-bit Destination Port Number
16-bit Length	16-bit Checksum
Data

В своей статье "Packet Fragmentation Attacks" (опубликована в All.net) доктор F. B. Cohen предложил следующий сценарий предполагаемой атаки, заключающейся в прохождении фрагментированного пакета через файрвол, минуя правила фильтрации. Атакующий разбивает пакет на два фрагмента, первый из которых содержит фиктивный TCP- или UDP-заголовок с номером порта назначения, который не фильтруется правилами на файрволе (например, 25 порт - почтовый SMTP-сервер), а второй имеет такое смещение (равное 1) в поле Fragment Offset, что перекрывает первый пакет и записывает в поле "порт назначения" истинное значение порта той службы, к которой доступ через файрвол запрещен. В этом случае правила фильтрации на файрволе пропустят этот IP-пакет, так файрвол не занимается сборкой фрагментированных IP-пакетов.

С этой статьей д-р Cohen'a [28] происходили с течением времени довольно любопытные изменения. В статье, которую авторы нашли на WWW-сервере all.net в мае 1996 года, для осуществления атаки предлагалось занести в поле Fragment Offset значение, равное 1 (далее будет показано, что в этом случае подобная атака в принципе невозможна). Однако, после посещения одного из серверов уже в мае 1997 года авторы с удивлением обнаружили ту же статью, но с одним "небольшим" исправлением: предлагалось заносить в это поле уже не 1, а 0! Во всем остальном статья осталась неизменной.

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

Через некоторое время после опубликования статьи д-р Cohen, видимо, обнаружил описанную выше ошибку и внес в сценарий атаки одно изменение: единица в поле Fragment Offset теперь была им заменена на 0! Проанализируем, насколько это изменение сделает возможным осуществление данной атаки.

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

Об этом поле в сценарии атаки др. Cohen'a даже не упоминается!

Однако, анализ исходных текстов ядра операционных систем Linux и FreeBSD показал, что IP-пакет будет воспринят этими ОС как фрагмент только в том случае, если значение в поле Fragment Offset не равно 0! Тем не менее, так как в алгоритме сборки фрагментов, описанном в RFC 791, не требуется обязательная проверка значения этого поля, то возможно, что некоторые сетевые ОС ее не производят (что маловероятно!) и, следовательно, атака может иметь успех.

Как нам кажется, сама идея наложения фрагментов является достаточно любопытна. Другое дело, что применение ее для проникновения пакетов атакующего через Firewall в существующем стандарте IPv4 представляется маловероятным.

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