Коллектив авторов - Защита от хакеров корпоративных сетей

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

Хотя есть другое мнение по данному вопросу. Выберем находящиеся под защитой межсетевого экрана два хоста и, возможно, незащищенный межсетевым экраном, третий хост, который может тайно послать ограниченное число данных обоим хостам. Межсетевой экран разрешает только выходящие соединения. Можно ли в этом случае так обмануть расположенные между двумя сетями межсетевые экраны, чтобы каждый из экранов думал, что другой принимает входящие соединения?

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

Допустим, что нужно рассмотреть в замедленном темпе следующую ситуацию и выявить все сопутствующие ей события. Два хоста предпринимают попытки установить выходящее TCP-соединение друг с другом. Каждый из хостов находится под защитой межсетевого экрана, настроенного на пропуск только выходных данных. Рассматриваемая ситуация в первую очередь касается межсетевых экранов с возможностью трансляции сетевых адресов. Алиса при инициализации TCP-соединения начала бы с посылки пакета SYN. Отправленный Алисой пакет SYN поступает к ее межсетевому экрану, который в своей таблице состояний отмечает попытку Алисы установить соединение с Бобом. Также он запоминает, что отформатированный соответствующим образом ответ Боба должен поступить обратно Алисе. Далее пакет SYN пересылается через Интернет тому, кого Алиса увидела как Боба. Возможно, что в пакете в качестве адреса отправителя был указан адрес межсетевого экрана Алисы.

Конечно, Боб никогда не получит этот пакет, потому что на самом деле в сети в качестве Боба выступает его межсетевой экран. Межсетевой экран Боба доверяет Алисе не больше, чем ее межсетевой экран Бобу. Поэтому межсетевой экран Боба отвечает на запрос Алисы отказом в установке соединения, посылая ей пакет RSTIACK. Конечно, когда межсетевой экран Алисы получает этот пакет, он знает, что он и не собирался получать от Боба положительный ответ на запрос подключения в виде пакета SYNIACK. Поэтому он затирает входы в своей таблице состояний, огорчая тем самым Алису.

У Боба сходная проблема. Он также не может вызвать Алису. Межсетевой экран Алисы сбрасывает его запросы точно так же, как его экран сбрасывает запросы Алисы.

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

Да, существует.

«Сейчас я спою песню судьбе!» Применение пакетов с обреченным временем жизни TTL для манипуляций с таблицей локальных состояний.По существу протокол IP очень похож на протокол Lilypad, который позволяет пакетам блуждать от маршрутизатора к маршрутизатору, пока он не достигнет своего адресата. Одна очень серьезная проблема, которая может произойти при ретрансляции пакета в сети (точнее, графе сети), заключается в возникновении по различным причинам бесконечного цикла маршрутизации. Последовательность маршрутизаторов может породить круговую траекторию (цикл), которая никогда не приведет отдельно взятый пакет к адресату. Это подобно езде по кругу, когда потеряна дорога к нужному городу, а водитель находится в слишком затуманенном сознании, чтобы осознать, что он уже тридцать раз проехал мимо одного и того гипермаркета быстрого обслуживания.

В реальном мире нельзя кружить вечно. В конечном счете закончится бензин. Но у пакетов нет бензобаков. Поскольку очень важно, чтобы пакеты не передавались по внутреннему циклу, то для предотвращения этого в каждый пакет включен счетчик предписанного времени жизни пересылаемого пакета TTL. Эта величина уже обсуждалась во время построения эффективного маршрутизатора в пространстве пользователя. Клиент определяет максимальное число «прыжков», которое данный пакет может осуществить при следовании по своему маршруту до адресата (обычно эта величина равна 256). Затем каждый маршрутизатор, через который проходит пакет, уменьшает счетчик предписанного времени жизни пакета TTL на 1. Если маршрутизатор получает пакет с нулевым значением счетчика TTL, то он удаляет его из потока передачи пакетов. Возможно, что при этом по протоколу ICMP будет послано сообщение о превышении времени существования пакета. Подобные сообщения используются для трассировки маршрута. Пакету разрешается сначала осуществить один прыжок, затем другой, третий и т. д.

В сказанном скрыты очень интересные вещи. Межсетевые экраны всегда позволяют проходить через них наружу пакетам с небольшим значением счетчика предписанного времени жизни TTL. Также они пропускают назад сообщения по протоколу ICMP для их оценки клиентом. Это относится и к пакетам, которые направляются законному адресату, но из-за недостаточного значения счетчика TTL обречены на уничтожение раньше, чем достигнут его. Пакет послан с соблюдением всех правил и ограничений, но он никогда не будет получен. Это именно то, что мы ищем! Для законно посланного пакета заводится запись в таблице состояний. Но поскольку адресат этого пакета никогда не получит его, то никогда не будет получен обратный пакет с установленным признаком сброса соединения RST, который удалил бы эту запись из таблицы состояний…