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 |
| 16-bit Source Port Number | 16-bit Destination Port Number |
| 16-bit Length | 16-bit Checksum |
| Data |
С этой статьей д-р 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 представляется маловероятным.
