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

# Give ourselves local access to an SSH daemon visible only

# to the bastion host on 10.0.1.11.

effugas@OTHERSHOE ~

$ ssh -L2022:10.0.1.10: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

$

# Connect through to that local port forward, but make sure

# we actually end up at 10.0.1.10. As long as we’re setting

# up a link, lets give ourselves localhost access on port

# 10080 to the web server on 10.0.1.10.

effugas@OTHERSHOE ~

$ ssh –p 2022 -o HostKeyAlias=10.0.1.10 –L10080:127.0.0.1:80

root@127.0.0.1

root@127.0.0.1’s password:

Last login: Thu Jan 10 12:44:29 2002 from 10.0.1.11

Изложенное, как и любая статическая переадресация порта, хорошо работает в случае одного или двух хостов, когда пользователь может запомнить, какие локальные порты каким удаленным адресатам соответствуют. При необходимости увеличить число направлений обмена удобство и простота использования этого подхода начинают резко сокращаться. Для устранения названного недостатка можно воспользоваться динамической переадресацией и динамическим определением туннелей при помощи пакета OpenSSH. Чтобы осуществить сказанное, нужно научиться администрировать частные хосты, расположенные за хостом-бастионом. Из-за присущих OpenSSH недостатков клиент SOCKS4 поддерживает все необходимое для осуществления собственного механизма непосредственной динамической переадресации. Еще раз воспользуемся программой connect разработчика Goto как опцией ProxyCommand. Только в этом случае трафик отскочит рикошетом от собственного клиента SSH, а не от какого-то открытого модуля доступа прокси в сети.

effugas@OTHERSHOE ~

$ ssh -D1080 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

$

effugas@OTHERSHOE ~

root@10.0.1.10

root@10.0.1.10’s password:

Last login: Thu Jan 10 13:12:28 2002 from 10.0.1.11

[root@localhost root]# ^D

Connection to 10.0.1.10 closed.

Обратитесь к другому хосту без повторной перенастройки ссылки на хост-бастион. Отметим, что в этом случае не требуется вносить каких-либо изменений, кроме изменений у конечного адресата:

$ ssh -o ProxyCommand=“connect -4 -S 127.0.0.1:1080 %h %p”

pix@10.0.1.254

pix@10.0.1.254’s password:

Type help or “?” for a list of available commands.

pix>

Но если откровенно, то необходимость предварительной переадресации соединения неудобна. Решение может быть найдено при помощи одного из способов, согласно которым SSH демон бастиона передает читателю прямую ссылку на SSH-порт хоста-адресата. Она передается через стандартный ввод-вывод. При помощи такого способа протокол SSH может работать так, как будто в нем реализована собственная опция ProxyCommand. Попытка подключения к конечному адресату может подтолкнуть модуль доступа прокси предпринять собственную попытку подключения к промежуточному хосту-бастиону. Пусть несколько грубовато, но в действительности на практике это может быть реализовано. Все же протокол SSH не обладает способностью к преобразованию одного типа инкапсуляции в другой. При переадресации порта нельзя указать на выполняемую команду. Выполняемые команды не могут быть непосредственно переданы TCP-портам. Подобные функциональные возможности были бы полезны, но этого нельзя добиться без инсталляции на сервере транслятора, преобразующего стандартный ввод-вывод I/O в формат протокола TCP. Программа netcat, написанная Хоббитом (Hobbit), является разновидностью сетевого армейского швейцарского ножа и предоставляет аналогичный сервис.

effugas@OTHERSHOE ~

$ ssh -o ProxyCommand=“ssh effugas@10.0.1.11 nc %h %p”

root@10.0.1.10

effugas@10.0.1.11’s password:

root@10.0.1.10’s password:

Last login: Thu Jan 10 15:10:41 2002 from 10.0.1.11

Приведенное решение грешит умеренным отсутствием изящности. Фактически клиент должен быть внутренне готов выполнить описанное преобразование. Вполне вероятно ожидать в ближайшем будущем патча к ssh, предоставляющего реализацию опции – W host: port. При помощи новой опции преобразование стандартного ввода-вывода в формат протокола TCP выполнялось бы на стороне клиента, а не на стороне сервера. Но, по крайней мере, при использовании программы netcat все работает, не так ли?

Есть проблема. Иногда при удаленном выполнении находятся команды, которые по непонятным пока причинам в конце своей работы не закрывают дескриптор файла. Дескриптор файла остается в открытом состоянии даже после аварийного завершения соединения SSH. Демоны, желающие обслужить этот дескриптор, отказываются завершать либо самих себя, либо эти приложения. В итоге появляются процессы-зомби. К сожалению, программа nc может привести к появлению описываемой проблемы. Ныне, как и в начале 2002 года, эта проблема указывает на серьезные разногласия среди разработчиков пакета OpenSSH. С помощью одного и того же кода, одержимо пытающегося предотвратить потерю данных при выполнении переадресованных команд, можно, слегка их поправив, мгновенно получить процесс-зомби. Хакер предупреждает!