Читаем без скачивания Защита от хакеров корпоративных сетей - Коллектив авторов

Программа WinVNC является одним из наиболее полезных сервисов переадресации, особенно на платформе Windows (позднее будут обсуждены вопросы переадресации на платформе UNIX). Она доступна по адресу www.tightvnc.com. Программа предоставляет простой для удаленной настройки интерфейс управления. Другими словами, с ее помощью можно увидеть работающий удаленный компьютер и исправить на нем ошибки. Переадресация удаленного порта позволяет экспортировать адресату интерфейс компьютера за пределы защищаемой межсетевым экраном зоны.

Есть ли у читателя запущенный сервер виртуальной сетевой обработки данных VNC? Да, есть:

[email protected] ~

$ telnet 127.0.0.1 5900

Trying 127.0.0.1...

Connected to 127.0.0.1.

Escape character is “^]”.

RFB 003.003

telnet> quit

Connection closed.

Соединитесь с другой машиной, переадресуя ее порт 5900 к собственному порту 5900.

[email protected] ~

$ ssh -R5900:127.0.0.1:5900 [email protected]

[email protected]’s password:

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

13:44:59 GMT 2001

Проверьте, будет ли удаленный компьютер видеть свой порт 5900. Проверку выполните точно так же, как и в случае тестирования собственного порта 5900 на локальном компьютере:

$ telnet 127.0.0.1 5900

Trying 127.0.0.1...

Connected to localhost.

Escape character is “^]”.

RFB 003.003

Обратите внимание на то, что удаленная переадресация порта не очень-то доступна. Другие машины с сетевым адресом 10.0.1.11 могут не увидеть порт 5900. Опция GatewayPorts программы SSHD позволяет решить это. Но как будет показано дальше, подобные установки необязательны.

Когда-то в Риме: пересекая непокорную сеть

Допустим, что есть сервер с запущенной на нем программой sshd и клиент с программой ssh. Сервер и клиент хотят установить связь, но сеть не настолько хороша и покорна, чтобы позволить им сделать это. При попытке установить соединение пакеты теряются, связь не устанавливается. Что делать? В рассматриваемом случае возможность прохождения пакетов обычно определяется тем, кто посылает и что посылает. Повышение проходимости пакетов через сеть будет означать изменение маршрута трафика SSH или маршрута непосредственной пересылки данных через сеть.

Прохождение моста: доступ к модулям доступа прокси с помощью опции ProxyCommand

В действительности довольно редко можно встретить сеть, которая непосредственно запрещает выходящие соединения по протоколу SSH. Когда такое случается, то это означает запрет в сети всех выходящих соединений. Обойти этот запрет можно при помощи маршрутизации выходящих соединений через прикладной уровень модулей доступа прокси. Не являясь средством полной дезинформации, модули доступа прокси предоставляют гораздо более простой метод скрытного доступа, чем современные решения трансляции сетевых адресов NAT. По сравнению со многими протоколами модули доступа прокси обладают дополнительными преимуществами, которые позволяют им лучше осуществлять кэширование. Поэтому прокси небесполезны. Существует много различных подходов построения и использования модулей доступа прокси, но поскольку обычно они почти ничего не добавляют к обеспечению безопасности выходящих соединений, то у разработчиков пакета OpenSSH не было желания реализовать их непосредственно внутри клиента. Реализация каждого из этих подходов непосредственно в модуле доступа прокси может превратиться в один из подвигов Геракла.

Поэтому вместо непосредственной интеграции в пакет OpenSSH была добавлена опция общего назначения ProxyCommand. Как правило, используя некоторый порт, протокол SSH непосредственно устанавливает TCP-соединение c заданным хостом и обменивается данными с каким-нибудь найденным там демоном, который может работать по протоколу SSH. Кроме того, опция ProxyCommand отключает это TCP-соединение, маршрутизируя все данные соединения через стандартный поток ввода-вывода I/O, который передается произвольному приложению и принимается от него. Это приложение может выполнять какие-то преобразования, которые потребуются при получении данных от модуля доступа прокси. Задача приложения будет полностью выполнена, если будет установлена полностью работоспособная связь с демоном протокола SSH. Разработчики добавили минимально возможное количество переменных, завершающихся спецификациями преобразования %h и %p, которые соответствуют адресу хоста и номеру его порта. Если клиент SSH инициализировал TCP-соединение, то он ждет эти данные. (Вне всякого сомнения, аутентификация хоста соответствует этим ожиданиям.)

Быстрая демонстрационная версия работы опции ProxyCommand выглядит следующим образом:

# Negotiate an SSH connection with whatever we find by

directly

# establishing a TCP link with 10.0.1.11:22

bash-2.05a$ ssh [email protected]

[email protected]”s password:

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

13:44:59 GMT 2001

$

# Establish a TCP connection to 10.0.1.11:22

$ nc 127.0.0.1 22

SSH-1.99-OpenSSH_3.0.1p1

# Negotiate an SSH connection with whatever we find by using

netcat to

# indirectly establish a TCP link with 10.0.1.11:22

bash-2.05a$ ssh -o ProxyCommand=“nc 10.0.1.11 22”

[email protected]

[email protected]’s password:

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

13:44:59 GMT 2001

$

# Add basic variable substitutions to above command

bash-2.05a$ ssh -o ProxyCommand=“nc %h %p” [email protected]

[email protected]’s password:

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

13:44:59 GMT 2001

$

Программа connect.c отличается наибольшей гибкостью реализации возможностей опции ProxyCommand. Ее разработчик Shun-Ichi Goto. Это изящное небольшое приложение можно найти по адресам www.imasy.or.jp/~gotoh/connect.c или www.doxpara.com/tradecraft/connect.c. Оно поддерживает протоколы SOCKS4 и SOCKS5 с аутентификацией, но без протокола HTTP: • SSH с использованием протокола SOCKS4;

[email protected] ~

$ ssh -o ProxyCommand=“connect.exe -4 -S [email protected]:20080

%h %p”

[email protected]

[email protected]’s password:

Last login: Mon Jan 14 03:24:06 2002 from 10.0.1.11

[[email protected] effugas]$

• SSH с использованием протокола SOCKS5;

[email protected] ~

$ ssh -o ProxyCommand=“connect.exe -5 -S [email protected]:20080

%h %p”

[email protected]

[email protected]’s password:

Last login: Mon Jan 14 03:24:06 2002 from 10.0.1.11

[[email protected] effugas]$

• SSH с использованием протокола HTTP (запрос HTTP CONNECT выдается программой connect.c).

[email protected] ~

$ ssh -o ProxyCommand=“connect.exe -H 10.0.1.11:20080 %h %p”

[email protected]

[email protected]’s password:

Last login: Mon Jan 14 03:24:06 2002 from 10.0.1.11

[[email protected] effugas]$...

Инструментарий и ловушки

Откуда уши растут: использование портов других сервисов

Предположим, что читатель работает в сети, которая не позволяет ему установить непосредственное SSH-соединение к выбранному им серверу. Кроме того, нет ни одного модуля доступа прокси, который очевидным образом позволил бы это сделать. Но при всем при этом передача данных по протоколам HTTP и HTTPS работает вполне успешно. Описанная ситуация может соответствовать случаю блокировки работы по протоколу SSH только из-за того, что данные передаются по портам, которые отличаются от портов 80/tcp (при работе по протоколу HTTP) или 443/tcp (при работе по протоколу HTTP поверх SSL). В этих условиях так и просится запустить демон SSH для работы с этими портами. Это действительно очевидное решение. Известна пара примеров, которые его реализуют:

• реконфигурация SSHD. В конфигурацию sshd добавляется дополнительный порт. Требуется выяснить, какая из настроек sshd_config действительно представляет интерес. Часто на выбранной машине может быть несколько отличающихся друг от друга конфигураций sshd, из которых только одна может быть загружена. Это происходит из-за использования различных ухищрений при работе с ними. Как правило, подключившись суперпользователем и введя ps – xf | grep sshd, можно обнаружить полный путь к запускаемому демону SSH. После выполнения /path/sbin/sshd – h станет ясно, какой из файлов sshd_config был локализован по умолчанию. Другими словами, будет получено что-то вроде приведенного ниже:

-f file Configuration file (default /usr/local/etc/sshd_config)

Будет достаточно просто добавить строки Port80 или Port443 ниже строчки Port 22, которая по умолчанию задает двадцать второй порт; • реконфигурация inetd. В большинстве UNIX-систем используется демон inetd, который является демоном сетевых сервисов общего назначения. Его конфигурационным файлом является файл / etc/inetd.conf. Демон inetd прослушивает TCP-порт, имя которого указано в файле /etc/services, и запускает заданное приложение после установки соединения через обслуживаемый им порт. Для переадресации порта команда netcat (nc) может быть успешно соединена по каналу с демоном inetd. В качестве примера создания переадресации порта ниже приводится модификация файла /etc/inetd.conf:

https stream tcp nowait nobody /usr/local/bin/nc nc 127.0.0.1 22

Важно отметить, что ничто не вынуждает netcat указывать на локальный хост localhost. Точно так же можно указать на любой другой выполняющийся в фоновом режиме демон SSH, определяя следующие строки:

https stream tcp nowait nobody /usr/local/bin/nc nc 10.0.1.11 22;

• создание шлюза на локальном хосте localhost для переадресации порта. Это просто, но в то же время эффективно для временного использования. Выполните ssh [email protected] – g – L443:127.0.0.1:22 – L80:127.0.0.1:22. Опция – g, означающая шлюз (по первой букве английского слова Gateway), позволяет нелокальным хостам подключаться к переадресованному порту локального хоста. Выполненное подключение под именем суперпользователя означает, что можно было создать специальный процесс – слушатель трафика, который контролирует (прослушивает) трафик, проходящий через порт, номер которого меньше величины 1024. Таким образом, без необходимости инсталляции какого-либо кода или модификации какой-либо конфигурации появляется возможность порождения дополнительных портов, которые демон SSH может прослушать через порты 80 или 43. Но надо помнить, что переадресация порта сохраняется только на время работы клиента SSH. После выполнения рекомендованных действий проверьте работоспособность TCP-соединения, установленного демоном SSH от клиента к серверу. Для проверки достаточно ввести команды telnet host 80 или telnet host 443. В случае успешной проверки простое выполнение ssh [email protected] -p 80 или ssh [email protected] -p 443 окажется существенно проще использования какой-либо разновидности модуля доступа прокси.