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

Примите во внимание, что у протокола SSL точно такие же недостатки обработки сетевого Web-трафика, поскольку он не предусматривает передачу через сервер страниц по протоколу HTTPS. Напомним, что протокол HTTPS – это тот же протокол HTTP, но с дополнительным использованием протокола SSL. (Действительно, это является нарушением спецификации, потому что в данном случае блокировки и адреса будут ссылаться на многие хосты.)

Переадресация динамического порта

То, что переадресация локального порта в какой-то степени неуправляема, еще не означает, что протокол SSH не может быть использован для туннелирования различных типов трафика. Это всего лишь означает необходимость применения более элегантных решений. И действительно, одно из них было найдено. Исследования протокола SSH показали, что в начале сессии, во время перехода слушающего порта в состояние ожидания соединения, клиент не сообщает заинтересованному серверу о переадресации порта до тех пор, пока соединение не будет полностью установлено. Более того, при переназначении слушателю различных портов через туннель SSH сведения об адресате в различных TCP-соединениях могут изменяться. Для приложения существовал единственный простой способ динамического информирования протокола SSH о месте предполагаемого указания сокета. Клиент мог по требованию переадресовать порт путем использования протокола SOCKS4…

Древний протокол SOCKS4 был разработан для предоставления клиенту простейшего способа информирования о своих намерениях модуля доступа прокси (модуль доступа прокси (proxy) – механизм, посредством которого одна система представляет другую в ответ на запросы протокола) сервера, к которому клиент пытается подключиться. Модули доступа прокси являются нечто большим, чем просто серверами, обслуживающими сетевые подключения клиентов, которые желают получить доступ к сети. Клиент передает модулю доступа запрос для сервера, к которому клиент хотел бы подключиться. После этого модуль доступа прокси передает запрос по сети, а ответ на него пересылает обратно клиенту. Это именно то, что требовалось для переадресации (перенаправления) динамического порта (dynamic port forwards) протокола SSH. Можно ли в этой ситуации использовать управляющий протокол, подобный протоколу SOCKS4? Протокол SOCKS4, основанный на добавлении всего лишь нескольких бит в конец и начало TCP-сессии, характеризуется практическим отсутствием непроизводительных издержек при передаче пакета. Он уже интегрирован в большое число ранее существовавших приложений. В состав протокола включены даже хорошо продуманные упаковщики (упаковщик (wrapper) – программные средства создания системной оболочки для стандартизации внешних обращений и изменения функциональной ориентации действующей системы), которые позволяют реализовать любые приложения, а не только suid-приложения, с поддержкой сетевых возможностей и умеющих работать с модулем доступа прокси.

Найденное решение было вполне приемлемым. Приложения могли выдавать запросы, а протокол мог отвечать на них. Все необходимые для клиента вещи были для него понятны. По этой причине в пакет OpenSSH, начиная с его первой общедоступной версии 2.9.2p2, была встроена поддержка протокола SOCKS4 (для этого необходимо всего лишь обновить клиентскую часть, хотя новейшие сервера работают устойчивее, если они используются для этой цели). Неожиданно была рождена виртуальная частная сеть VPN (Virtual Private Network) для бедных. Запустить механизм переадресации динамического порта очень просто. Для этого достаточно указать порт для прослушивания: ssh – Dl istening_port user@host. Например,

effugas@OTHERSHOE ~/.ssh

$ ssh effugas@10.0.1.10 -D1080

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

Last login: Mon Jan 14 12:08:15 2002 from

localhost.localdomain

В результате все подключения к адресу 127.0.0.1:1080 будут вынуждены пересылать в зашифрованном виде свои данные через адрес 10.0.1.10 любому адресату, запрошенному приложением. Процесс получения приложений, которые могут выдать подобные запросы, несколько грубоват, но это намного проще уловок, столь необходимых для переадресации локальных портов. Теперь приведем несколько примеров настроек. Internet Explorer 6: создание безопасной работоспособной Web-сети

Хотя простые Web-страницы могут быть легко переадресованы при помощи локальной переадресации порта, сложные Web-страницы ужасно пострадают при их передаче по протоколу SSH или, по крайней мере, при его использовании. Настройка Web-браузера для использования ранее описанного динамического механизма переадресации довольно проста. Для браузера Internet Explorer она состоит из следующих шагов.

1. Выделите пункты меню Tools I Internet Options.

2. Выберите вкладку Connections.

3. Щелкните на кнопке LAN Settings.Проверьте параметры Use a Proxy Serverи щелкните на кнопке Advanced.

4. Перейдите к текстовым полям, описывающим протоколы SOCKS. Введите строку 127.0.0.1в поле адреса хоста и укажите в поле номер порта величину 1080 (или укажите другой номер порта, который был выбран для динамической переадресации).

5. Щелкнув на кнопке OK,закройте все три окна.

После этого войдите в сеть Web. Если все работает, то наиболее вероятно, что все работает через протокол SSH. Предполагая, что все работает так, как надо, можно увидеть что-то похожее на изображенное на рис. 13.2.

Для проверки функционирования связи через SSH введите символы ~#в своем окне протокола SSH. В результате будет показано текущее представление порта с активной переадресацией:

$ ~#

The following connections are open:

#1 client-session (t4 r0 i1/0 o16/0 fd 5/6)

#2 direct-tcpip: listening port 1080 for 216.7.64.9 port

80, connect

from 127.0.0.1 port 2166 (t4 r1 i1/0 o16/0 fd 8/8)

#3 direct-tcpip: listening port 1080 for 216.7.64.14 port

80, connect

from 127.0.0.1 port 2198 (t4 r2 i1/0 o16/0 fd 9/9)

#4 direct-tcpip: listening port 1080 for 216.7.64.14 port

80, connect

from 127.0.0.1 port 2209 (t4 r3 i1/0 o16/0 fd 10/10)

$ nslookup 216.7.64.9

Server: dns-sj3.cisco.com

Address: 171.68.10.70

Non-authoritative answer:

Name: www.fark.com