Защита от хакеров корпоративных сетей
Шрифт:
$ 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 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
$
# 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”
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
$
# Add basic variable substitutions to above command
bash-2.05a$ ssh -o ProxyCommand=“nc %h %p” 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
$Программа connect.c отличается наибольшей гибкостью реализации возможностей опции ProxyCommand. Ее разработчик Shun-Ichi Goto. Это изящное небольшое приложение можно найти по адресам www.imasy.or.jp/~gotoh/connect.c или www.doxpara.com/tradecraft/connect.c. Оно поддерживает протоколы SOCKS4 и SOCKS5 с аутентификацией, но без протокола HTTP: • SSH с использованием протокола SOCKS4;
effugas@OTHERSHOE ~
$ ssh -o ProxyCommand=“connect.exe -4 -S foo@10.0.1.11:20080
%h %p”
effugas@10.0.1.10
effugas@10.0.1.10’s password:
Last login: Mon Jan 14 03:24:06 2002 from 10.0.1.11
[effugas@localhost effugas]$• SSH с использованием протокола SOCKS5;
effugas@OTHERSHOE ~
$ ssh -o ProxyCommand=“connect.exe -5 -S foo@10.0.1.11:20080
%h %p”
effugas@10.0.1.10
effugas@10.0.1.10’s password:
Last login: Mon Jan 14 03:24:06 2002 from 10.0.1.11
[effugas@localhost effugas]$• SSH с использованием протокола HTTP (запрос HTTP CONNECT выдается программой connect.c).
effugas@OTHERSHOE ~
$ ssh -o ProxyCommand=“connect.exe -H 10.0.1.11:20080 %h %p”
effugas@10.0.1.10
effugas@10.0.1.10’s password:
Last login: Mon Jan 14 03:24:06 2002 from 10.0.1.11
[effugas@localhost effugas]$Инструментарий и ловушки
Откуда уши растут: использование портов других сервисов
Предположим, что читатель работает в сети, которая не позволяет ему установить непосредственное 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 root@127.0.0.1 – 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 user@host -p 80 или ssh user@host -p 443 окажется существенно проще использования какой-либо разновидности модуля доступа прокси.
Что еще сказать о HTTP? Изменение последовательности передаваемых пакетов
Функциональные возможности опции ProxyCommand определяются ее способностью переназначать необходимый поток данных через стандартный ввод-вывод. Важно, чтобы набранные на клавиатуре данные в конце концов были отосланы на экран (в данном случае это абстрактное изложение самых общих принципов). Не во всех системах реализован этот уровень взаимодействия. Особенно хочется упомянуть о программе httptunnel, разработчиком которой является nocrew.org. В Интернете она доступна по адресу www.nocrew.org/software/httptunnel.html. Программа httptunnel является чрезвычайно полезным инструментальным средством. Она позволяет реализовать SSH-соединения через сеть, в которой разрешен только трафик HTTP и больше ничего другого. Любые модули доступа прокси, поддерживающие Web-трафик, будут поддерживать работу программы httptunnel, хотя, если говорить откровенно, в случае зашифрованного трафика могут возникнуть проблемы.
Во многом работа программы httptunnel похожа на переадресацию локального порта. Порт на локальной машине устанавливается так, чтобы он указывал на порт удаленной машины, который в этом случае должен быть настроен специальным образом для поддержки на стороне сервера соединения программы httptunnel. Более того, принимая во внимание, что при переадресации локального порта клиент может определить адресата, программа httptunnel настраивается во время старта сервера. Тем не менее для грамотного пользователя это не является проблемой, потому что программа httptunnel используется как метод установления связи с удаленным демоном SSH.