Коллектив авторов - Защита от хакеров корпоративных сетей
[email protected]
[email protected]’s password:
Last login: Thu Jan 10 13:12:28 2002 from 10.0.1.11
[[email protected] root]# ^D
Connection to 10.0.1.10 closed.
[email protected] ~Обратитесь к другому хосту без повторной перенастройки ссылки на хост-бастион. Отметим, что в этом случае не требуется вносить каких-либо изменений, кроме изменений у конечного адресата:
$ ssh -o ProxyCommand=“connect -4 -S 127.0.0.1:1080 %h %p”
[email protected]
[email protected]’s password:
Type help or “?” for a list of available commands.
pix>
pix>Но если откровенно, то необходимость предварительной переадресации соединения неудобна. Решение может быть найдено при помощи одного из способов, согласно которым SSH демон бастиона передает читателю прямую ссылку на SSH-порт хоста-адресата. Она передается через стандартный ввод-вывод. При помощи такого способа протокол SSH может работать так, как будто в нем реализована собственная опция ProxyCommand. Попытка подключения к конечному адресату может подтолкнуть модуль доступа прокси предпринять собственную попытку подключения к промежуточному хосту-бастиону. Пусть несколько грубовато, но в действительности на практике это может быть реализовано. Все же протокол SSH не обладает способностью к преобразованию одного типа инкапсуляции в другой. При переадресации порта нельзя указать на выполняемую команду. Выполняемые команды не могут быть непосредственно переданы TCP-портам. Подобные функциональные возможности были бы полезны, но этого нельзя добиться без инсталляции на сервере транслятора, преобразующего стандартный ввод-вывод I/O в формат протокола TCP. Программа netcat, написанная Хоббитом (Hobbit), является разновидностью сетевого армейского швейцарского ножа и предоставляет аналогичный сервис.
[email protected] ~
$ ssh -o ProxyCommand=“ssh [email protected] nc %h %p”
[email protected]
[email protected]’s password:
[email protected]’s password:
Last login: Thu Jan 10 15:10:41 2002 from 10.0.1.11
[[email protected] 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 [email protected]
[email protected]’s password:
[[email protected] effugas]$
# 10.0.1.10 traveling back over the remote port forward.
[[email protected] effugas]$ ssh -o HostKeyAlias=10.0.1.11 -
p 2022
[email protected]
[email protected]’s password:
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3
13:44:59 GMT 2001
$Таким образом, пользователь домашнего компьютера, подключенного к сети и защищенного от внешнего мира межсетевым экраном, может установить на нем протокол SSH, который предоставит ему локальный порт, подключившись и работая через который, можно будет получить доступ к SSH-демону на машине, расположенной на работе.
...Инструментарий и ловушки
«Реверс» клиентов
Проблема доступа к клиенту, когда сервера могут инициализировать соединение с клиентом, а клиент с ними нет, обычно разрешается с помощью «реверса» клиентов, при котором клиенты ожидают появления серверов для того, чтобы установить с ними соединение и послать им данные в стиле X-Windows. И действительно, слишком часто кто-то открыто запрашивает режим клиента SSH, для того чтобы разрешить программе sshd подключиться к нему. Подобные решения, если только они с самого начала не были заложены в протокол и его реализацию, в лучшем случае дезинформируют, а в худшем – ужасно небезопасны. Применение для перенаправления SSHD переадресации удаленного порта вместо доступа к Web-сети является уникальным расширением хорошо устанавливаемых и в общем-то безопасных методологий, которые постоянно используются. Внедрение редко используемого клиента в sshd и сервера в ssh является слишком специфичным и совсем необязательным бедствием, которое только выжидает удобный момент для своего свершения.
Сказанное – это прежде всего ответ на постоянный поток запросов, который автор чаще всего наблюдал. (Однако отнеситесь к этому скептически: кто-то попытается свести счеты с половиной способов, изложенных в этой главе, если не во всей книге.)
