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

Что еще сказать о 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 порту:

[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-клиент, которому доверяют (а ему следует доверять), то почему пользователь должен зависеть еще от кого-то? Используя переадресацию порта, можно превратить доверие, которым пользователь пользуется у хоста-бастиона, в непосредственное подключение к хосту, к которому пользователь хотел подключиться с самого начала. Можно даже из середины общедоступной сети получить сквозной безопасный доступ к доступным сетевым ресурсам частного хоста!