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

effugas@OTHERSHOE ~

$ 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

$ ssh root@10.0.1.10

root@10.0.1.10”s password:

Last login: Thu Jan 10 12:43:40 2002 from 10.0.1.11[root@localhost root]#

В конечном счете иногда даже приятно вместо «ssh root@10.0.1.10» ввести ssh effugas@10.0.1.11. Но если это допускается, то подобный метод слишком опасен. Он создает предпосылки для чрезвычайно эффективного массового проникновения к внутренним системам. Причина этого проста. Какому хосту на законных основаниях могут довериться, чтобы получить доступ к частному адресату? Первоначальному клиенту, понимая под этим и пользователя, который физически сидит перед компьютером. Какова истинная цель обращения хоста к частному адресату? В результате чей SSH-клиент обращается к конечному серверу SSH? Клиент бастиона. Хост-бастион получает и ретранслирует пароль в открытом, незашифрованном виде. Хост-бастион расшифровывает зашифрованный секретный трафик данных. Он может выбрать или не выбрать режим повторной передачи данных, не тревожа такими «мелочами» первоначального клиента. Только c помощью хоста-бастиона можно или нельзя решить вопрос о сохранении доступа с правами суперпользователя к внутренним хостам. (Даже одноразовый пароль не защитит от поврежденного сервера, который просто не сообщит о факте отсутствия регистрации нарушений в своей работе.) Перечисленные опасности – не просто теоретические размышления. В большинстве наиболее значимых случаев компрометации Apache.org и Sourceforge – двух исключительно важных, критических сервисов сообщества с открытыми текстами – была выявлена зависимость между компрометацией сервисов и появлением Троянских коней у клиентов SSH известных серверов. Однако подобные угрозы могут быть почти полностью устранены. Хосты-бастионы обеспечивают доступ к хостам, которые иначе из Интернета были бы недоступны. Для получения к ним доступа люди подтверждают свою подлинность хостам-бастионам. Для аутентификации используется SSH-клиент, работающий совместно с SSH-демоном сервера. Поскольку уже имеется один SSH-клиент, которому доверяют (а ему следует доверять), то почему пользователь должен зависеть еще от кого-то? Используя переадресацию порта, можно превратить доверие, которым пользователь пользуется у хоста-бастиона, в непосредственное подключение к хосту, к которому пользователь хотел подключиться с самого начала. Можно даже из середины общедоступной сети получить сквозной безопасный доступ к доступным сетевым ресурсам частного хоста!

# 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[root@localhost root]#

Изложенное, как и любая статическая переадресация порта, хорошо работает в случае одного или двух хостов, когда пользователь может запомнить, какие локальные порты каким удаленным адресатам соответствуют. При необходимости увеличить число направлений обмена удобство и простота использования этого подхода начинают резко сокращаться. Для устранения названного недостатка можно воспользоваться динамической переадресацией и динамическим определением туннелей при помощи пакета 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 ~$ ssh -o ProxyCommand=“connect -4 -S 127.0.0.1:1080 %h %p”

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.effugas@OTHERSHOE ~

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

$ 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>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[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$