Защита от хакеров корпоративных сетей
Шрифт:
По адресу 10.0.1.10 запустите серверную часть программы httptunnel, которая будет прослушивать порт 10080 и пересылать все запросы httptunnel своему собственному 22 порту:
[effugas@localhost effugas]$ hts 10080 -F 127.0.0.1:22
На стороне клиента стартуйте клиентскую часть программы httptunnel, которая будет прослушивать порт 10022, перехватывая любые данные, поступающие через модуль доступа проксипротокола HTTP по адресу 10.0.1.11:8888, и отсылая их адресату, который для серверной части программы httptunnel является хостом с адресом 10.0.1.10:10080:
effugas@OTHERSHOE ~/.ssh $ htc -F 10022 -P 10.0.1.11:8888 10.0.1.10:10080
Убедившись в установке соединения по IP-адресу 10.0.1.10, подключите ssh к локальному слушателю порта 10022:
effugas@OTHERSHOE ~/.ssh
$ ssh -o HostKeyAlias=10.0.1.10 -o Port=10022
Enter passphrase for key “/home/effugas/.ssh/id_dsa”:
Last login: Mon Jan 14 08:45:40 2002 from 10.0.1.10
[effugas@localhost effugas]$При
Покажи свой значок: аутентификация стесненного бастиона
Многие сети установлены следующим образом. Один сервер общедоступен со стороны глобального Интернета. Для расположенных за ним систем он обеспечивает работу межсетевого экрана, маршрутизации и, возможно, сервисов трансляции адресов. Подобные системы известны как хосты-бастионы. Они являются интерфейсом между частными сетями и реальным внешним миром.
Как правило, может возникнуть ситуация, когда администратор захочет удаленно администрировать одну из систем, расположенных за хостом-бастионом. Обычно это делается так, как это показано в приведенном ниже примере:effugas@OTHERSHOE ~
$ ssh [email protected]
[email protected]”s password:
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3
13:44:59 GMT 2001
$ ssh [email protected]
[email protected]”s password:
Last login: Thu Jan 10 12:43:40 2002 from 10.0.1.11
[root@localhost root]#В конечном счете иногда даже приятно вместо «ssh [email protected]» ввести ssh [email protected]. Но если это допускается, то подобный метод слишком опасен. Он создает предпосылки для чрезвычайно эффективного массового проникновения к внутренним системам. Причина этого проста. Какому хосту на законных основаниях могут довериться, чтобы получить доступ к частному адресату? Первоначальному клиенту, понимая под этим и пользователя, который физически сидит перед компьютером. Какова истинная цель обращения хоста к частному адресату? В результате чей 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 [email protected]
[email protected]”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
[email protected]’s password:
Last login: Thu Jan 10 12:44:29 2002 from 10.0.1.11
[root@localhost root]#Изложенное, как и любая статическая переадресация порта, хорошо работает в случае одного или двух хостов, когда пользователь может запомнить, какие локальные порты каким удаленным адресатам соответствуют. При необходимости увеличить число направлений обмена удобство и простота использования этого подхода начинают резко сокращаться. Для устранения названного недостатка можно воспользоваться динамической переадресацией и динамическим определением туннелей при помощи пакета OpenSSH. Чтобы осуществить сказанное, нужно научиться администрировать частные хосты, расположенные за хостом-бастионом. Из-за присущих OpenSSH недостатков клиент SOCKS4 поддерживает все необходимое для осуществления собственного механизма непосредственной динамической переадресации.
effugas@OTHERSHOE ~
$ ssh -D1080 [email protected]
[email protected]’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”[email protected]’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”
[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), является разновидностью сетевого армейского швейцарского ножа и предоставляет аналогичный сервис.
effugas@OTHERSHOE ~
$ ssh -o ProxyCommand=“ssh [email protected] nc %h %p”
[email protected]’s password:
[email protected]’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 обнаружили, что для наступления катастрофического по своим последствиям отказа системы достаточно проникновения в нее единственного Троянского коня. Так происходит из-за ограничений, свойственных использованию хоста-бастиона. Как только будет предоставлен доступ к предложенному хостом-бастионом уникальному сетевому ресурсу, позволяющему взаимодействовать с хостами, которые защищены межсетевым экраном, то он тут же будет объединен с доверенными ресурсами и в дальнейшем не будет контролироваться слишком строго.