Коллектив авторов - Защита от хакеров корпоративных сетей
bash-2.05a$ tail -n1 /etc/hosts 10.0.1.44 alephdox
Вместо непосредственной посылки IRC по адресу 127.0.0.1 следует модифицировать файл таким образом, чтобы он содержал следующую строчку:
[email protected] /cygdrive/c/windows/system32/drivers/etc
$ tail -n1 hosts
127.0.0.1 newyork.ny.us.undernet.orgТеперь при запуске системы IRC можно подключиться к хосту, используя оригинальное имя. При этом, используя переадресацию порта, маршрутизация будет выполнена без ошибок!
[email protected] /cygdrive/c/windows/system32/drivers/etc
$ irc Timmy newyork.ny.us.undernet.org
*** Connecting to port 6667 of server
newyork.ny.us.undernet.org
*** Looking up your hostname
*** Found your hostname, cached
*** Checking Ident
*** No ident response
*** Welcome to the Internet Relay Network TimmyОбратите внимание, что расположение hosts-файла изменяется в зависимости от используемой платформы. Почти все UNIX-системы используют директорию /etc/hosts, Win9x – WINDOWSHOSTS, WinNT – WINNT SYSTEM32DRIVERSETCHOSTS, а WinXP – WINDOWSSYSTEM32 DRIVERSETCHOSTS. Полагая, что Cygwin поддерживает Symlinks (по крайней мере, версию, способную правильно работать с файлами ярлыков Windows (Windows Shortcut files)), в соответствии со здравым смыслом было бы неплохо выполнить что-то похожее на ln – s HOSTSPATHHOSTS /etc/hosts.
Обратите внимание на то, что на самом деле переадресация порта с помощью протокола SSH не удовлетворяет требованию гибкости. Переадресация порта требует предварительного объявления адресатов, значительных административных издержек, и ей присущи все виды ограничений. Помимо всего прочего, несмотря на возможность указания при переадресации различных портов для получателя и отправителя (например, 16667:irc.slashnet. org:6667), никто не сможет обратиться к переадресованным портам по имени, поскольку обратно они разрешаются к одному и тому же IP-адресу 127.0.0.1. Также необходимо точно знать, каким хостам обязательно следует предпринять попытку переадресации портов, например для просмотра Web-сети, а это очень рискованное предположение. Помимо того что невозможно организовать полноценную обработку страниц, обслуживающих многочисленные адреса (каждая из них может быть послана одному и тому же серверу по порту 80 соединения по протоколу HTTP), любые сервера, сведения о которых не включены в hosts-файлы, будут «просачиваться» во внешнюю сеть.
Примите во внимание, что у протокола SSL точно такие же недостатки обработки сетевого Web-трафика, поскольку он не предусматривает передачу через сервер страниц по протоколу HTTPS. Напомним, что протокол HTTPS – это тот же протокол HTTP, но с дополнительным использованием протокола SSL. (Действительно, это является нарушением спецификации, потому что в данном случае блокировки и адреса будут ссылаться на многие хосты.)
Однако локальная переадресация портов – совсем не бесполезная игрушка. Локальная переадресация портов полезна для переадресации всех однопортовых, однохостовых сервисов. Сам по себе протокол SSH является однопортовым, однохостовым сервисом. И как будет показано чуть позже, в этом кроются все различия.Переадресация динамического порта
То, что переадресация локального порта в какой-то степени неуправляема, еще не означает, что протокол 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 [email protected] Например,
[email protected] ~/.ssh
$ ssh [email protected] -D1080
Enter passphrase for key “/home/effugas/.ssh/id_dsa”:
Last login: Mon Jan 14 12:08:15 2002 from
localhost.localdomain
[[email protected] effugas]$В результате все подключения к адресу 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.
Рис. 13.2. Доступ к сайту FARK через протокол SSHДля проверки функционирования связи через 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
Address: 216.7.64.9...Инструментарий и ловушки
Ограничения, накладываемые на динамическую переадресацию и протокол SOCKS4
На сервер с уже работающим демоном SSH не требуется устанавливать специальное программное обеспечение для его использования в качестве «виртуальной частной сети VPN для бедных», но новейшие версии SSHD обеспечивают более стабильную работу линии с переадресованным портом. Демоны старших версий могут временно блокировать соединение при попытке установить соединение с несуществующим или недостижимым хостом. Можно наткнуться на ошибки в том случае, когда в результате статической переадресации локального порта устанавливается указатель на взломанный хост. Они вызваны тем, что статическая переадресация обычно указывает лишь на устойчиво работающие хосты. Разрешить эту проблему можно путем инсталляции на удаленную машину усовершенствованной версии OpenSSH. (Для более подробных сведений пусть читатель ознакомится со специальным разделом, в котором описано, как это сделать. Заметим, что для инсталляции OpenSSH совcем необязательно обладать правами суперпользователя.)
