Введение
Стеганографические методы подразумевают сокрытие секретной информации в ходе передачи обычных пользовательских данных, и в идеале скрытая информация и существование скрытой связи не могут быть обнаружены третьими лицами. Ранее были предложены и проанализированы различные стеганографические методы. Их можно рассматривать как угрозу сетевой безопасности, поскольку эти методы могут быть использованы в качестве инструмента для организации, например, путей утечки конфиденциальной информации. Именно поэтому важно обозначить потенциальные возможности скрытой связи, так как знание процедуры сокрытия информации может быть использовано для разработки контрмер.
Обе версии протокола IP 4 и 6 были разработаны для использования в различных каналах передачи данных. Максимальная длина IP-пакета составляет 64 кБ, но для большинства каналов передачи данных максимальная длина пакета меньше. Данная характеристика канала передачи данных, ограничивающая размер пакета, называется MTU (англ. Maximum Transmission Unit – максимальная единица передачи). MTU зависит от типа канала передачи данных, например, для протокола Ethernet эта величина составляет 1500 байт, для беспроводного протокола IEEE 802.11-2300 и PPP (Point to Point Protocol) – 296 байт.
Существует два варианта передачи большого IP- пакета по сквозному пути, состоящему из каналов передачи с разными значениями MTU:
• С разделением большого пакета на более маленькие. Для решения этой задачи был стандартизирован механизм, называемый IP-фрагментацией.
• Без применения пакетной фрагментации с приведением максимального размера IP-пакета к так называемому PMTU (Path MTU) – минимально допустимому MTU на всём сквозном пути. Для этой цели были разработаны два метода: PMTUD (англ. Path MTU Discovery – определение MTU на пути) для IPv4 и для IPv6, а также PLPMTUD (англ. Packetization Layer Path MTU Discovery – определение MTU на пути уровня пакетизации), который представляет собой усовершенствованную версию первого метода для обеих версий IP-протокола.
Механизмы для обработки больших пакетов, такие как IP-фрагментация, PMTUD или PLPMTUD, востребованы и используются в сетевых сценариях, когда на сквозном пути промежуточные каналы имеют меньшие MTU, чем MTU конечных каналов.
Ниже перечислены стандартные сетевые сценарии, в которых требуется обработка пакетов большого размера:
• Использование различных протоколов туннелирования, таких как GRE (англ. Generic Routing Encapsulation – общая инкапсуляция маршрутов), IPSec (IP Security) и L2TP (англ. Layer Two Tunneling Protocol – протокол туннелирования второго уровня), которые добавляют заголовки и трейлеры, тем самым уменьшая эффективное MTU.
• Использование протокола PPPoE (Point to Point Protocol over Ethernet – сетевой протокол передачи через Ethernet) в совокупности с технологией ADSL (англ. Asymmetric Digital Subscriber Line – асимметричная цифровая абонентская линия). PPPoE имеет 8 байт заголовка, что уменьшает эффективное MTU для Ethernet до 1492 байт.
• Использование MPLS в сети Ethernet.
• Соединения между конечными точками в сетях Token Ring или FDDI, между которыми установлен канал Ethernet (с меньшим MTU) и другие подобные случаи.
Обзор механизмов обработки IP-пакетов большого размера
- IP-фрагментация
Чтобы учитывать разницу значений MTU в каналах сквозного пути при IP-фрагментации, промежуточным узлам разрешается фрагментировать большие пакеты. Затем принимающий узел или другой сетевой узел (например, маршрутизатор) отвечает за сборку фрагментов обратно в исходный IP-пакет. Механизм IP-фрагментации подразумевает использование следующих полей заголовка IPv4 (рисунок 1): поле «Идентификатор», «Смещение фрагмента», а также флаги MF (More Fragments – «У пакета ещё есть фрагменты») и DF (Don’t fragment – «Не фрагментировать»). Также в поля «Общая длина» и «Контрольная сумма заголовка» каждого фрагмента необходимо установить корректные значения. Вышеуказанные поля заголовка используются следующим образом:
Поле «Идентификатор» (16 бит) содержит значение, присваиваемое отправителем каждому IP-пакету для обеспечения правильной сборки фрагментов (каждый фрагмент имеет одно и то же значение идентификатора).
Рисунок 1 – Заголовок пакета протокола IPv4
Поле «Смещение фрагмента» (13 бит) указывает, какую часть исходного пакета содержит фрагмент.
Поле «Флаги» (3 бита) содержит управляющие флаги. Бит «0» зарезервирован и всегда установлен в значение 0. Бит «1» является флагом DF: если флаг установлен в 0, фрагментация разрешена; если флаг установлен в 1, фрагментация запрещена. Бит «2» является флагом MF: если этот флаг установлен в 0 и значение поля «Смещение фрагмента» отлично от нуля, это указывает на то, что данный фрагмент является последним, а если флаг MF установлен в 1, это означает, что ещё не все фрагменты пакета получены.
Рисунок 2 – Расширенный заголовок фрагментации протокола IPv6
Подобный механизм используется в шестой версии протокола IP, где для выполнения фрагментации используется Расширенный заголовок фрагментации (рисунок 2). Отличие фрагментации в IPv6 от фрагментации в IPv4 состоит в том, что её может выполнять только отправитель, а процесс сборки должен осуществляться только на стороне получателя, а не в каком-либо промежуточном узле.
Пример фрагментации IP-пакета для IPv4 представлен в таблице 1. Исходный пакет размером 5140 байт делится на четыре фрагмента максимальным размером 1500 байт.
Таблица 1 – Пример IP-фрагментации
Существует несколько проблем, которые делают IP-фрагментацию в сетях IPv4 нежелательной, поскольку она снижает эффективность и надёжность связи. Фрагментация вызывает серьёзные избыточные нагрузки на получателя, поскольку при сборке фрагментов получатель должен выделять память для поступающих фрагментов, а после получения всех фрагментов он должен снова поместить их в исходный IP-пакет. Хотя для хоста это не составляет проблем, поскольку у него есть время и ресурсы для выполнения такого рода задач, сборка может оказаться весьма неэффективной на промежуточных узлах (таких как маршрутизаторы). Маршрутизатор не может определить размер исходного IP-пакета до того, как будет получен последний фрагмент, поэтому для сборки пакета он должен выделить большой приёмный буфер.
Ещё одна проблема фрагментации связана с обработкой отброшенных фрагментов. Если один из фрагментов IP-пакета отброшен, то весь исходный IP-пакет должен быть отправлен повторно (все фрагменты).
Брандмауэры и NAT (англ. Network Address Translation – механизм преобразования сетевых адресов) могут испытывать трудности с правильной обработкой фрагментов и фактически отбрасывать их. Если IP-фрагменты расположены не по порядку, брандмауэр может блокировать неначальные фрагменты, поскольку они не несут информации, которая соответствовала бы пакетному фильтру. Это может привести к тому, что исходный пакет не сможет быть собран принимающим узлом. Аналогичная проблема может возникнуть и в NAT, поскольку у него есть проблемы с интерпретацией IP-фрагмента, если он приходит не по порядку.
- PMTUD (определение MTU на пути)
PMTUD был стандартизирован для IPv4 и опубликован в 1990 году, но не получил широкого распространения в течение следующих нескольких лет. В настоящее время PMTUD реализован в ведущих операционных системах (Windows, Unix, Linux): уже в 2002 году около 80-90% оконечных устройств в Интернете использовали его. Как упомянуто во введении, этот механизм был разработан для того, чтобы избежать фрагментации на пути между конечными точками. Как и для IPv4, механизм PMTUD был также разработан и стандартизирован для IPv6.
PMTUD используется для динамического определения наименьшего MTU на сквозном пути между отправителем и получателем пакетов. Вместо фрагментации пакета конечная точка определяет наибольший возможный размер пакета, который может быть отправлен по заданному адресу назначения. Конечная точка устанавливает правильный размер пакета для заданного пути, отправляя пакеты разных размеров. Такие пакеты, используемые PMTUD, называются зондирующими сообщениями и имеют установленный в «1» флаг DF в заголовке IP-пакета. Их размер изначально устанавливается равным MTU канала отправителя. Пока отправитель генерирует «зонды», он также отвечает на возможные сообщения об ошибках протокола ICMP (англ. Internet Control Message Protocol – протокол межсетевых управляющих сообщений), которые указывают на наличие меньшего значения MTU на пути соединения. Отправитель получает уведомление, сообщающее о том, какой размер пакета будет подходящим. Уведомления запрашиваются путём установки флага DF в исходящих пакетах. Для IPv4 уведомления приходят в виде ICMP-сообщений, известных как «Fragmentation required, and DF flag set» («Требуется фрагментация и флаг DF установлен») (ICMP тип 3, код 4), для IPv6 это сообщение – «Packet too big» («Пакет слишком большой») из протокола ICMPv6. PMTUD работает непрерывно во время соединения, поскольку путь между отправителем и получателем может измениться (например, из-за отказа канала).
Пример PMTUD показан на рисунке 3. Хост A отправляет пакет хосту B, размер которого установлен в 1500 байт (значение MTU по умолчанию для Ethernet).
Рисунок 3 – пример PMTUD
Пакет будет пересылаться с использованием туннеля IPSec, который начинается на первом маршрутизаторе. Поскольку MTU следующего канала также составляет 1500 байт, а IPSec добавляет 54 байта сверху, то общий размер пакета превысит допустимое MTU. В результате пакет отбрасывается и хосту A отправляется ICMP-сообщение с указанием значения MTU, допустимого для следующего канала. Затем хост A повторяет попытку отправки пакета, уменьшая его размер до 1442 байт, чтобы выполнить требование ограничения, и пакет успешно проходит через первый маршрутизатор. Однако MTU канала после следующего маршрутизатора составляет 1000 байт, поэтому пакет снова отбрасывается, и хосту A посылается ICMP- сообщение, но оно блокируется первым маршрутизатором. По истечении таймаута хост A повторно пересылает пакет и получает ICMP- сообщение, которое указывает на необходимость уменьшить размер пакета до 942 байт. Это последнее значение MTU затем используется для успешного обмена данными с хостом B.
Следует отметить, что существуют проблемы безопасности, связанные с использованием PMTUD. В частности, в некоторых случаях сетевые администраторы считают весь ICMP-трафик опасным и блокируют его, лишая возможности использовать механизм определения MTU.
- PLPMTUD (определение MTU на пути уровня пакетирования)
Для смягчения проблем, связанных с использованием ICMP-трафика, в было разработано и стандартизировано расширение для PMTUD под названием PLPMTUD. Отличие PLPMTUD от PMTUD заключается в том, что принимаемые зондирующие сообщения проходят валидацию на транспортном уровне. Данный механизм не зависит от ICMP или других сетевых сообщений, вместо этого он определяет правильное значение MTU, начиная с относительно маленьких пакетов и постепенно увеличивая их размер. В частности, PLPMTUD использует метод поиска для определения оптимального PMTU. Каждое зондирование сужает диапазон поиска MTU. Он может повысить нижний предел при успешном прохождении сообщения или понизить верхний предел при неудачном прохождении сообщения. Однократная потеря зондирующего сообщения рассматривается как указание для ограничения MTU, и протоколу транспортного уровня разрешается ретранслировать любые недостающие данные.
Выводы
В этой статье были представлены потенциальные стеганографические методы, которые применимы к механизмам обработки IP-пакетов большого размера, а именно: к механизмам IP-фрагментации, PMTUD и PLPMTUD.
Предлагаемые стеганографические методы характеризуются различной стеганографической пропускной способностью и возможностью обнаружения, поэтому они могут по-разному влиять на безопасность сети. Знание этих механизмов сокрытия информации теперь может быть использовано для разработки и реализации контрмер для мониторинга сетевого трафика. Это может снизить риск утечки конфиденциальной информации или других угроз, возникающих при использовании скрытой передачи данных.
Библиографический список
- Rowland, C. (1997). Covert channels in the TCP/IP protocol suite, first Monday. Peer Reviewed Journal on the Internet, July 1997.
- Zander, S., Armitage, G., & Branch, P. (2007). A survey of covert channels and countermeasures in computer network protocols. IEEE Communications Surveys & Tutorials, 9(3), 44–57.
- Petitcolas, F., Anderson, R., & Kuhn, M. (1999). Information hiding – a survey. IEEE Special Issue on Protection of Multimedia Content, July 1999.
- Murdoch, S. J., & Lewis, S. (2005). Embedding covert channels into TCP/IP. Information Hiding, 247–260.
- Postel, J. (1981). Internet protocol. IETF RFC 791, September 1981.
Количество просмотров публикации: Please wait