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

Предоставление горы возможностей: экспортирование 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-демону на машине, расположенной на работе.