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

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

[root@localhost root]#

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

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

Сетевые администраторы, желающие обеспечить безопасность работы хоста-бастиона, могут пойти по такому спорному пути, как удалить на сервере веськлиентский код, включая Telnet, sshи даже lynx.Являясь для выполняемых программ пользователя узким местом, хост-бастион представляет из себя чрезвычайно привлекательную и уязвимую мишень, поскольку в нем сконцентрированы средства обеспечения взаимодействия в сети. Если бы даже для полного управления своей собственной безопасностью не было бы менее безопасного (или технически не осуществимого) способа довериться каждому внутреннему хосту, то и в этом случае идея хоста-бастиона опаснее, чем это следовало бы.

Предоставление горы возможностей: экспортирование SSHD-доступа

Безусловно, хост-бастион полезен. Хотя бы даже потому, что он позволяет сетевому администратору централизованно удостоверить подлинность полного доступа к внутренним хостам. При применении рассмотренных в предыдущей главе стандартов, которые не используют чрезмерно щепетильных способов аутентификации внутренних хостов сети, подавляется даже возможность попытки передать им запрос на подключение. Но у централизации есть собственные недостатки. Apache.org и Sourceforge обнаружили, что для наступления катастрофического по своим последствиям отказа системы достаточно проникновения в нее единственного Троянского коня. Так происходит из-за ограничений, свойственных использованию хоста-бастиона. Как только будет предоставлен доступ к предложенному хостом-бастионом уникальному сетевому ресурсу, позволяющему взаимодействовать с хостами, которые защищены межсетевым экраном, то он тут же будет объединен с доверенными ресурсами и в дальнейшем не будет контролироваться слишком строго.

Что в итоге? Пользователь становится незащищенным от повреждений хоста-бастиона и десятков маршрутизаторов, которые могут располагаться на пути между ним и нужным ему хостом. Это не является неожиданным из-за того, что обычно хост-бастион используется не только как маршрутизатор аутентификации, но и как еще что-то. Это очень полезно.

Однако что произойдет в случае отсутствия хоста-бастиона?

Что, если управляемая машина находится дома, она подключена к линии DSL (Digital Subscriber Line – цифровая абонентская линия), между машиной и сетью размещен один из превосходных маршрутизаторов Cable/DSL NAT Routers компании LinkSys (на момент написания книги это было единственное устройство, про которое известно, что оно позволяет надежно транслировать сетевые адреса (функция NAT) по протоколу IPSec) и отсутствует какая-либо возможность разместить демон SSH непосредственно на внешнем интерфейсе?

Что, если пользователь, исходя из самых лучших побуждений, пожелает запретить доступ из глобального Интернета ко всем своим сервисам? В старших версиях SSH и OpenSSH полностью исправлены ошибки в реализации протокола SSH1. Можно ли поэтому считать, что огромное уважение, которое питает сообщество Интернет к протоколу SSH, уравновешивает риск оказаться взломанным?

Что, если потребность в удаленном управлении настолько мала, что она не может сравниться со стоимостью аппаратных средств или стоимостью администрирования хоста-бастиона?

Нет проблем. Только не используйте длительное время один и тот же сервер. Хост-бастион – это нечто большее, чем просто система, с помощью которой клиент может успешно связаться с сервером. Хотя для управления соединениями удобно иметь постоянную инфраструктуру и установленные учетные записи пользователя, но в рассматриваемом случае в этом нет особой необходимости. Протокол SSH вполне успешно может экспортировать доступ к своим собственным демонам при помощи механизма переадресации (перенаправления) удаленного порта. Давайте предположим, что сервер может получить доступ к клиенту, а клиент к серверу – нет. Именно так обычно и бывает в мире многоуровневой защиты, где верхние уровни могут связываться с нижними:

# 10.0.1.11 at work here

bash-2.05a$ ssh -R2022:10.0.1.11:22 effugas@10.0.1.10

effugas@10.0.1.10’s password:

[effugas@localhost effugas]$

# 10.0.1.10 traveling back over the remote port forward.

[effugas@localhost effugas]$ ssh -o HostKeyAlias=10.0.1.11 -

p 2022

effugas@127.0.0.1

effugas@127.0.0.1’s password:

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

13:44:59 GMT 2001

$

Таким образом, пользователь домашнего компьютера, подключенного к сети и защищенного от внешнего мира межсетевым экраном, может установить на нем протокол SSH, который предоставит ему локальный порт, подключившись и работая через который, можно будет получить доступ к SSH-демону на машине, расположенной на работе.

Читать дальше