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

Что еще сказать о HTTP? Изменение последовательности передаваемых пакетов

Функциональные возможности опции ProxyCommand определяются ее способностью переназначать необходимый поток данных через стандартный ввод-вывод. Важно, чтобы набранные на клавиатуре данные в конце концов были отосланы на экран (в данном случае это абстрактное изложение самых общих принципов). Не во всех системах реализован этот уровень взаимодействия. Особенно хочется упомянуть о программе httptunnel, разработчиком которой является nocrew.org. В Интернете она доступна по адресу www.nocrew.org/software/httptunnel.html. Программа httptunnel является чрезвычайно полезным инструментальным средством. Она позволяет реализовать SSH-соединения через сеть, в которой разрешен только трафик HTTP и больше ничего другого. Любые модули доступа прокси, поддерживающие Web-трафик, будут поддерживать работу программы httptunnel, хотя, если говорить откровенно, в случае зашифрованного трафика могут возникнуть проблемы.

Во многом работа программы httptunnel похожа на переадресацию локального порта. Порт на локальной машине устанавливается так, чтобы он указывал на порт удаленной машины, который в этом случае должен быть настроен специальным образом для поддержки на стороне сервера соединения программы httptunnel. Более того, принимая во внимание, что при переадресации локального порта клиент может определить адресата, программа httptunnel настраивается во время старта сервера. Тем не менее для грамотного пользователя это не является проблемой, потому что программа httptunnel используется как метод установления связи с удаленным демоном SSH.

По адресу 10.0.1.10 запустите серверную часть программы httptunnel, которая будет прослушивать порт 10080 и пересылать все запросы httptunnel своему собственному 22 порту:

[[email protected] effugas]$ hts 10080 -F 127.0.0.1:22

На стороне клиента стартуйте клиентскую часть программы httptunnel, которая будет прослушивать порт 10022, перехватывая любые данные, поступающие через модуль доступа проксипротокола HTTP по адресу 10.0.1.11:8888, и отсылая их адресату, который для серверной части программы httptunnel является хостом с адресом 10.0.1.10:10080:

[email protected] ~/.ssh $ htc -F 10022 -P 10.0.1.11:8888 10.0.1.10:10080

Убедившись в установке соединения по IP-адресу 10.0.1.10, подключите ssh к локальному слушателю порта 10022:

[email protected] ~/.ssh

$ ssh -o HostKeyAlias=10.0.1.10 -o Port=10022

[email protected]

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

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

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

[email protected] ~

$ 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

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

[email protected] ~

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

[email protected] ~

$ ssh –p 2022 -o HostKeyAlias=10.0.1.10 –L10080:127.0.0.1:80

[email protected]

[email protected]’s password:

Last login: Thu Jan 10 12:44:29 2002 from 10.0.1.11

Изложенное, как и любая статическая переадресация порта, хорошо работает в случае одного или двух хостов, когда пользователь может запомнить, какие локальные порты каким удаленным адресатам соответствуют. При необходимости увеличить число направлений обмена удобство и простота использования этого подхода начинают резко сокращаться. Для устранения названного недостатка можно воспользоваться динамической переадресацией и динамическим определением туннелей при помощи пакета OpenSSH. Чтобы осуществить сказанное, нужно научиться администрировать частные хосты, расположенные за хостом-бастионом. Из-за присущих OpenSSH недостатков клиент SOCKS4 поддерживает все необходимое для осуществления собственного механизма непосредственной динамической переадресации. Еще раз воспользуемся программой connect разработчика Goto как опцией ProxyCommand. Только в этом случае трафик отскочит рикошетом от собственного клиента SSH, а не от какого-то открытого модуля доступа прокси в сети.

[email protected] ~

$ 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

$

[email protected] ~

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

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

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

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