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

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

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

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

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

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

Приоткрывая завесу

Квитирование установления связи: всего лишь брокер подключения

Рикошет всего соединения может стать причиной превращения отражателя подключений в опасное узкое место, потому что в любом направлении он должен видеть весь трафик дважды: один раз – при получении пакетов и еще один раз – при отсылке их обратно. По этой причине интерес к отражателю подключений отсутствует даже со стороны наиболее амбициозных проектов соединения равноправных узлов хостов P2P (peer-to-peer – соединение равноправных хостов (узлов)). Существуют сугубо экспериментальные системы, которые позволяют находящимся посередине соединения хостам запросто становиться брокером подключения (broker the connection). Брокеры подключения предоставляют двум хостам, запрашивающим выходящие линии связи, средства склеивания друг с другом. Подобные методы описаны в конце главы 12 и их полная работоспособность везде и всегда не гарантируется (авторы разработали их только во время написания книги). Напротив, приведенные ниже методы более работоспособны и надежны.

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

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

# Server: Export link to a mutually accessible “floating

# bastion server”

[[email protected] effugas]$ ssh -R20022:127.0.0.1:22

[email protected]

[email protected]’s password:

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

13:44:59 GMT 2001

$

# Client: Import link from the mutually accessible

# “floating bastion server” (not using netcat,

# because we’re assuming zero software installation

# for this host)

[email protected] ~

$ ssh -L30022:127.0.0.1:20022 [email protected]

[email protected]’s password:

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

13:44:59 GMT 2001

$

# Client: Initiate a connection over the imported/

# exported link, verifying the endpoint goes where we

# think it does.

[email protected] ~

$ ssh -o HostKeyAlias=10.0.1.10 -p 30022 [email protected]

Enter passphrase for key “/home/effugas/.ssh/id_dsa”:

Last login: Mon Jan 14 12:00:19 2002 from 10.0.1.56

На полпути: что теперь?

После блуждания в поисках достижения поставленной цели читатель наконец обнаружит себя в конечной точке, к которой он все это время предпринимал попытки проложить туннель. И что, считать теперь спорный вопрос решенным? Другими словами, уместно спросить: «Что теперь?» Конечно, читатель может администрировать все, что ему нужно, пользуясь удаленной командной оболочкой. Он может подключиться к различным хостам, которые могут предоставить читателю точки сетевого доступа к необходимым ему ресурсам. Но протокол SSH предлагает нечто большее, особенно когда используется переадресация команд. Наиболее важный вывод этой главы состоит в том, что все рассмотренные в ней методы могут быть успешно сведены в единую цепочку. Ниже приведены примеры, которые показывают, каким образом ранее описанные способы могут быть соединены вместе точно так же, как и строительные кубики в конструкторе LEGO, способствуя появлению новых и интересных способов.

Стандартная передача файла при помощи протокола SSH

Стандартным инструментальным средством копирования файлов внутри SSH-туннеля является программа Secure Copy (scp). Ее общепринятый базовый синтаксис весьма близок к синтаксису команды cp. Путь на удаленную машину определяется обычным образом: [email protected]:/path. Ниже приведен пример копирования локального файла dhcp.figure.pdf в директорию /tmp, расположенную на удаленном хосте 10.0.1.11:

[email protected] ~

$ scp dhcp.figure.pdf [email protected]:/tmp

[email protected]”s password:

При копировании директории следует задать флажок -r, что очень похоже на формат команды cp. При копировании опция -r указывает на необходимость рекурсивного просмотра всего дерева директории сверху вниз. Программа scp сделана по образцу команды rcp и выполняет все, что необходимо, но если честно, то не очень хорошо. Ошибочная настройка путей часто является причиной аварийного завершения серверной части программы scp, а специфицировать опции командной строки ssh нереально. Сказанное не означает невозможности воспользоваться некоторыми наиболее интересными системами туннелирования. Программа scp предоставляет возможность повторной настройки ssh посредством более многословного интерфейса файла конфигурации. Читатель, введя man ssh, может найти полный список настраиваемых опций. Ниже показан пример спецификации опции HostKeyAlias, позволяющей проверить адресата локального переадресованного порта SSH: