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

В общем случае проксисервера являются разновидностью отражателя подключения. Запрос на выходящее соединение перенаправляется по направлению отсылки ответного сигнала входящего соединения от удаленного 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

$

# Client: Import link from the mutually accessible

# “floating bastion server” (not using netcat,

# because we’re assuming zero software installation

# for this host)

effugas@OTHERSHOE ~

$ ssh -L30022:127.0.0.1:20022 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

$

# Client: Initiate a connection over the imported/

# exported link, verifying the endpoint goes where we

# think it does.

effugas@OTHERSHOE ~

$ ssh -o HostKeyAlias=10.0.1.10 -p 30022 effugas@127.0.0.1

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, способствуя появлению новых и интересных способов.