Защита от хакеров корпоративных сетей
Шрифт:
effugas@OTHERSHOE ~
$ telnet 127.0.0.1 6667
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is “^]”.
NOTICE AUTH :*** Looking up your hostname
NOTICE AUTH :*** Found your hostname, cached
NOTICE AUTH :*** Checking Ident
NOTICE AUTH :*** No ident responseПросто установить переадресацию порта недостаточно. Следует еще так сконфигурировать свои системы, чтобы они смогли использовать созданную переадресацию. Это означает передачу данных через локальный хост вместо непосредственного подключения к конечному адресату. Первый способ заключается в простом информировании приложения о новом адресате. Это вполне осуществимо, если адресация выполняется «вживую», то есть ничто не запоминается в конфигурационных файлах:
$ irc Effugas 127.0.0.1
*** Connecting to port 6667 of server 127.0.0.1
*** Looking up your hostname
*** Found your hostname, cached
*** Checking Ident
*** No ident response
*** Welcome to the Internet Relay Network Effugas (from
newyork.ny.us.undernet.org)Случай, когда конфигурация организована в виде растущего сверху вниз большого дерева меню, намного сложнее. Работа с таким деревом раздражает, потому при желании поменять сервер необходимо
bash-2.05a$ tail -n1 /etc/hosts 10.0.1.44 alephdox
Вместо непосредственной посылки IRC по адресу 127.0.0.1 следует модифицировать файл таким образом, чтобы он содержал следующую строчку:
effugas@OTHERSHOE /cygdrive/c/windows/system32/drivers/etc
$ tail -n1 hosts
127.0.0.1 newyork.ny.us.undernet.orgТеперь при запуске системы IRC можно подключиться к хосту, используя оригинальное имя. При этом, используя переадресацию порта, маршрутизация будет выполнена без ошибок!
effugas@OTHERSHOE /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 – \WINDOWS\HOSTS, WinNT – \WINNT\ SYSTEM32\DRIVERS\ETC\HOSTS, а WinXP – \WINDOWS\SYSTEM32\ DRIVERS\ETC\HOSTS. Полагая, что Cygwin поддерживает Symlinks (по крайней мере, версию, способную правильно работать с файлами ярлыков Windows (Windows Shortcut files)), в соответствии со здравым смыслом было бы неплохо выполнить что-то похожее на ln – s \HOSTSPATH\HOSTS /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) – программные средства создания системной оболочки для стандартизации внешних обращений и изменения функциональной ориентации действующей системы),
Найденное решение было вполне приемлемым. Приложения могли выдавать запросы, а протокол мог отвечать на них. Все необходимые для клиента вещи были для него понятны. По этой причине в пакет 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
[effugas@localhost 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.
Для проверки функционирования связи через 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ем необязательно обладать правами суперпользователя.)
Большую обеспокоенность вызывает тот факт, что переадресация по протоколу SOCKS4 оказывает воздействие только на сам трафик. Она не переадресовывает запросы DNS, которые используются для управления трафиком. Поэтому администратор на локальной линии может контролировать подключение к ней и даже изменять адресата, хотя соединение читателя само по себе может быть безопасным. Это может создавать серьезный риск безопасности. Есть надежда, что в ближайшем будущем названная проблема будет благополучно решена при помощи реализации в семействе клиентов OpenSSH возможности динамической переадресации по протоколу SOCKS5.
Тем временем обе проблемы древних серверов и протоколов могут быть частично разрешены путем инсталляции на сервере небольшой порции программного кода, позволяющего работать по протоколу SOCKS4/5. Автор отдает предпочтение программе usocksd, доступной по адресуХотя программа usocksd поддерживает только протокол SOCKS5, она удаленно разрешает имена и остается стабильной при неблагоприятных для нее сетевых условиях. Запуск ее не слишком сложен:
Dan@EFFUGAS ~
$ ssh -L2080:127.0.0.1:2080 effugas@10.0.1.11 “./usocksd -p
2080”
effugas@10.0.1.11’s password:
usocksd version 0.9.3 (c) Olaf Titz 1997-1999
Accepting connnections from (anywhere) ident (anyone)
Relaying UDP from (anywhere)
Listening on port 2080.В данном случае используется как переадресация команд, так и переадресация портов. По команде демон начинает SSH-сессию и перенаправляет ее результаты обратно клиенту. После этого переадресация порта разрешает клиентам получить доступ к TCP-порту демона. Это работает, хотя и выглядит несколько неуклюже.