Коллектив авторов - Защита от хакеров корпоративных сетей
Допустим, что нужно рассмотреть в замедленном темпе следующую ситуацию и выявить все сопутствующие ей события. Два хоста предпринимают попытки установить выходящее TCP-соединение друг с другом. Каждый из хостов находится под защитой межсетевого экрана, настроенного на пропуск только выходных данных. Рассматриваемая ситуация в первую очередь касается межсетевых экранов с возможностью трансляции сетевых адресов. Алиса при инициализации TCP-соединения начала бы с посылки пакета SYN. Отправленный Алисой пакет SYN поступает к ее межсетевому экрану, который в своей таблице состояний отмечает попытку Алисы установить соединение с Бобом. Также он запоминает, что отформатированный соответствующим образом ответ Боба должен поступить обратно Алисе. Далее пакет SYN пересылается через Интернет тому, кого Алиса увидела как Боба. Возможно, что в пакете в качестве адреса отправителя был указан адрес межсетевого экрана Алисы.
Конечно, Боб никогда не получит этот пакет, потому что на самом деле в сети в качестве Боба выступает его межсетевой экран. Межсетевой экран Боба доверяет Алисе не больше, чем ее межсетевой экран Бобу. Поэтому межсетевой экран Боба отвечает на запрос Алисы отказом в установке соединения, посылая ей пакет RSTIACK. Конечно, когда межсетевой экран Алисы получает этот пакет, он знает, что он и не собирался получать от Боба положительный ответ на запрос подключения в виде пакета SYNIACK. Поэтому он затирает входы в своей таблице состояний, огорчая тем самым Алису.
У Боба сходная проблема. Он также не может вызвать Алису. Межсетевой экран Алисы сбрасывает его запросы точно так же, как его экран сбрасывает запросы Алисы.
Если читатель задумывался о приведенном примере, то время от времени вещи выглядят не так уж плохо. Выясняется, что каждая сторона может получить у собственного межсетевого экрана достаточно прав для того, чтобы разрешить другой стороне послать пакет с кодом возврата. Проблема состоит в том, что приходящий пакет содержит отрицательный ответ. Это происходит непреднамеренно. Ни один из межсетевых экранов не захочет пропускать приходящие извне пакеты. В данном случае запрет на пропуск приходящих пакетов предотвращает внутренний мир от выведывания его тайн. Хотелось бы добиться записи служебной информации в таблицу состояний, но при этом не сбрасывать соединение. Существует ли какой-либо способ восстановления предшествующего, но не последнего состояния?
Да, существует.
«Сейчас я спою песню судьбе!» Применение пакетов с обреченным временем жизни TTL для манипуляций с таблицей локальных состояний. По существу протокол IP очень похож на протокол Lilypad, который позволяет пакетам блуждать от маршрутизатора к маршрутизатору, пока он не достигнет своего адресата. Одна очень серьезная проблема, которая может произойти при ретрансляции пакета в сети (точнее, графе сети), заключается в возникновении по различным причинам бесконечного цикла маршрутизации. Последовательность маршрутизаторов может породить круговую траекторию (цикл), которая никогда не приведет отдельно взятый пакет к адресату. Это подобно езде по кругу, когда потеряна дорога к нужному городу, а водитель находится в слишком затуманенном сознании, чтобы осознать, что он уже тридцать раз проехал мимо одного и того гипермаркета быстрого обслуживания.
В реальном мире нельзя кружить вечно. В конечном счете закончится бензин. Но у пакетов нет бензобаков. Поскольку очень важно, чтобы пакеты не передавались по внутреннему циклу, то для предотвращения этого в каждый пакет включен счетчик предписанного времени жизни пересылаемого пакета TTL. Эта величина уже обсуждалась во время построения эффективного маршрутизатора в пространстве пользователя. Клиент определяет максимальное число «прыжков», которое данный пакет может осуществить при следовании по своему маршруту до адресата (обычно эта величина равна 256). Затем каждый маршрутизатор, через который проходит пакет, уменьшает счетчик предписанного времени жизни пакета TTL на 1. Если маршрутизатор получает пакет с нулевым значением счетчика TTL, то он удаляет его из потока передачи пакетов. Возможно, что при этом по протоколу ICMP будет послано сообщение о превышении времени существования пакета. Подобные сообщения используются для трассировки маршрута. Пакету разрешается сначала осуществить один прыжок, затем другой, третий и т. д.
В сказанном скрыты очень интересные вещи. Межсетевые экраны всегда позволяют проходить через них наружу пакетам с небольшим значением счетчика предписанного времени жизни TTL. Также они пропускают назад сообщения по протоколу ICMP для их оценки клиентом. Это относится и к пакетам, которые направляются законному адресату, но из-за недостаточного значения счетчика TTL обречены на уничтожение раньше, чем достигнут его. Пакет послан с соблюдением всех правил и ограничений, но он никогда не будет получен. Это именно то, что мы ищем! Для законно посланного пакета заводится запись в таблице состояний. Но поскольку адресат этого пакета никогда не получит его, то никогда не будет получен обратный пакет с установленным признаком сброса соединения RST, который удалил бы эту запись из таблицы состояний…
По крайней мере, ни Алиса, ни Боб никогда не пришлют такой ответ.
Поборник сетевого равноправия: пакеты SYMIACK в игре. Алиса и Боб могут оба инициализировать соединение с помощью пакетов SYN. Они даже могут преобразовать предназначенный для сброса состояния пакет RST в невинное ICMP-сообщение о превышении предписанного времени жизни пакета путем посылки обреченного SYN-пакета. Но, несмотря на сказанное, в таблице состояний останется запись, ожидающая подтверждения попытки подключения. Это своего рода проблема, поскольку нет готового механизма, при помощи которого Алиса и Боб смогли бы непосредственно послать пакет SYNIACK. Подобный механизм относится к внутренним элементам принятия входящего соединения, а межсетевой экран разрешает только исходящие соединения.
В соответствии с ранее описанным алгоритмом работы возможность ответа была заблокирована.
Но только то, что Алиса не может послать пакет, еще не означает, что Боб не сможет принять его. Это лишь означает, что кто-то должен отправить пакет для Алисы. Этот кто-то, известный как брокер подключения, мог бы получить от Алисы пакет SYNIACK, который она ожидала получить от Боба, если только его межсетевой экран позволил бы ему отправить сообщение. (Подобное сообщение брокер мог бы получить от Боба, и оно содержало бы все сведения, которые он хотел бы получить от Алисы.) Посредник мог не знать о первоначальном пакете SYN, затерявшемся где-то в сети посередине между Бобом и Алисой. Но если бы оба клиента смогли предоставить достаточно информации о посланных ими пакетах SYN и сути ожидаемого от брокера ответа, то брокер соединения смог бы фальсифицировать посланные Алисе от Боба и Бобу от Алисы пакеты SYNIACK.
Автор назвал эти пакеты SYMIACK (Ack nowledgements both Sym metric and Sim ulated) ввиду того, что они являются подтверждением симметричности и имитации. Брокер имитирует передачу двух почти идентичных пакетов, но направленных в разные стороны сети. Эти специальным образом сформированные пакеты совместно используют не только одни и те же сходные структуры. Они позволяют обоим межсетевым экранам обслуживать симметричные состояния посредством цельного процесса подтверждения установления (квитирования) связи. Оба клиента посылают пакеты SYN, оба межсетевых экрана ожидают пакеты SYNIACK, оба клиента отправляют эти пакеты SYNIACK и одновременно предоставляют возможность послать пакеты-подтверждения ACK друг другу. (Конечно, поскольку ни один из межсетевых экранов не ожидает получения пакета подтверждения ACK, то есть необходимости в его уничтожении.) После того как две стороны будут удовлетворены процессом квитирования связи, будет установлена прекрасная двухсторонняя симметричная связь между двумя хостами, которые ранее не смогли переговорить друг с другом. Начиная с этого места брокеру нет необходимости что-либо делать. И действительно, как только две стороны (Алиса и Боб) обменяются несколькими первыми пакетами, брокер не сможет вторгнуться в сеанс, если даже он попробует это сделать (хотя, вероятно, он сможет послать фальсифицированное сообщение о недостижимости хоста по протоколу ICMP (ICMP Host Unreachable message) обеим сторонам, разрывая их связь).Идеальная схема? Нет. Двум хостам для установления связи и передачи данных между собой третий хост не нужен. Это чересчур плохая попытка хакинга, обусловленная несовершенством конструкции межсетевого экрана. Кроме того, известны различные проблемы, сопутствующие только что описанному способу.
Механика чисел: полуслепая (semiblind) фальсификация пакетов SYNIACK. Хотя брокер подключения действительно информирован относительно времени и главным образом места предполагаемой фальсификации, есть нетривиальные проблемы, сопутствующие кровавым деталям того, что на самом деле было отправлено. Не рассматривая синхронизацию и размещение пакета, можно сказать, что фактический пакет инициализации соединения SYN содержит два блока случайных данных, которые должны быть полностью согласованы с межсетевым экраном. Иначе нельзя будет получить ответ. К этим данным относятся номер порта отправителя и начальный порядковый номер.
