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

[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

effugas@127.0.0.1

Enter passphrase for key “/home/effugas/.ssh/id_dsa”:

Last login: Mon Jan 14 08:45:40 2002 from 10.0.1.10

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

Покажи свой значок: аутентификация стесненного бастиона

Многие сети установлены следующим образом. Один сервер общедоступен со стороны глобального Интернета. Для расположенных за ним систем он обеспечивает работу межсетевого экрана, маршрутизации и, возможно, сервисов трансляции адресов. Подобные системы известны как хосты-бастионы. Они являются интерфейсом между частными сетями и реальным внешним миром.

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

В конечном счете иногда даже приятно вместо «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

Изложенное, как и любая статическая переадресация порта, хорошо работает в случае одного или двух хостов, когда пользователь может запомнить, какие локальные порты каким удаленным адресатам соответствуют. При необходимости увеличить число направлений обмена удобство и простота использования этого подхода начинают резко сокращаться. Для устранения названного недостатка можно воспользоваться динамической переадресацией и динамическим определением туннелей при помощи пакета 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 ~

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.

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

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

Но если откровенно, то необходимость предварительной переадресации соединения неудобна. Решение может быть найдено при помощи одного из способов, согласно которым SSH демон бастиона передает читателю прямую ссылку на SSH-порт хоста-адресата. Она передается через стандартный ввод-вывод. При помощи такого способа протокол SSH может работать так, как будто в нем реализована собственная опция ProxyCommand. Попытка подключения к конечному адресату может подтолкнуть модуль доступа прокси предпринять собственную попытку подключения к промежуточному хосту-бастиону. Пусть несколько грубовато, но в действительности на практике это может быть реализовано. Все же протокол SSH не обладает способностью к преобразованию одного типа инкапсуляции в другой. При переадресации порта нельзя указать на выполняемую команду. Выполняемые команды не могут быть непосредственно переданы TCP-портам. Подобные функциональные возможности были бы полезны, но этого нельзя добиться без инсталляции на сервере транслятора, преобразующего стандартный ввод-вывод I/O в формат протокола TCP. Программа netcat, написанная Хоббитом (Hobbit), является разновидностью сетевого армейского швейцарского ножа и предоставляет аналогичный сервис.