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

Сказанное – это прежде всего ответ на постоянный поток запросов, который автор чаще всего наблюдал. (Однако отнеситесь к этому скептически: кто-то попытается свести счеты с половиной способов, изложенных в этой главе, если не во всей книге.)

Эхо на чуждом языке: перекрестное соединение взаимно защищенных межсетевыми экранами хостов

Типовое использование протокола передачи файлов FTP для управления защищенными межсетевыми экранами сетями предусматривает наличие хостов, которые не могут получить соединение и всегда генерируют поток выходящих данных к хосту, который может их получить. (Характеризуя протокол FTP, можно сказать, что, по крайней мере, это несколько странный протокол. Для сохранности своих соединений, упорядоченных в том же самом направлении, необходимо перевести протокол в так называемый пассивный режим (Passive Mode). Пассивный режим протокола FTP предусматривает, что сервер сообщает клиенту номер порта, по которому в случае установления соединения клиент передаст содержимое файла. Напротив, работа в активном режиме (Active Mode) ориентирована на клиента, который ранее инициировал выходящее соединение к серверу и сейчас посылает запрос к серверу для установки сервером выходящего соединения обратно к клиенту по некоторому случайному порту, для того чтобы разместить переданный сервером файл. Межсетевым экранам было сложно работать с одним из грандов старых протоколов Интернета из-за того, что приходилось выполнять сложную подстройку протокола FTP в результате непредсказуемых изменений направлений соединений и номеров портов.) В инструментариях Napster и Gnutella реализованы системы, которые автоматически выясняют, какая из сторон транзакции не может получать запросы на соединение. После чего транзакция создает TCP-соединение, а дальше файл либо проталкивается в канал связи (командой PUT), либо выталкивается из него (командой GET) на хост, который выдал запрос на пересылку файла.

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

Иногда возможно более изящное решение. Основная идея универсального решения, которое может быть использовано в случае отсутствия непосредственного сетевого соединения, заключается в использовании третьего хоста, так называемого отражателя подключения (connection bouncer). Отражатель подключения получает исходящие от обоих хостов соединения и затем рикошетом отправляет трафик с первого хоста на второй и наоборот.

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

К счастью, в данном случае нет необходимости ни в том, ни в другом. Если читатель вспомнит, то сначала была описана система с клиентом, который не мог непосредственно инициировать соединение с сервером. Вместо этого для создания сквозной безопасной линии связи по протоколу SSH клиент подтверждал свою подлинность хосту-бастиону и использовал сетевой путь, доступный ему благодаря бастиону. Затем была описана система, в которой для подключения клиента хост-бастион уже не предусматривался. Сервер самостоятельно инициировал свое собственное соединение с внешним миром, экспортируя при помощи переадресации удаленного порта путь клиенту для того, чтобы он проложил к нему обратный туннель. Так получилось, что этот путь был экспортирован непосредственно клиенту, хотя в этом не было необходимости. На самом деле сервер мог бы использовать переадресацию удаленного порта своему собственному SSH-демону на любом хосте, который был бы доступен как серверу, так и клиенту. После этого клиенту было бы достаточно просто обратиться к этому доступному как со стороны сервера, так и со стороны клиента хосту, который внезапно стал хостом-бастионом. Ниже рассмотрено объединение двух названных методов в один:

# Server: Export link to a mutually accessible “floating

# bastion server”

[effugas@localhost effugas]$ ssh -R20022:127.0.0.1:22

effugas@10.0.1.11

effugas@10.0.1.11’s password:

FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3

13:44:59 GMT 2001

$