То, что переадресация локального порта в какой-то степени неуправляема, еще не означает, что протокол SSH не может быть использован для туннелирования различных типов трафика. Это всего лишь означает необходимость применения более элегантных решений. И действительно, одно из них было найдено. Исследования протокола SSH показали, что в начале сессии, во время перехода слушающего порта в состояние ожидания соединения, клиент не сообщает заинтересованному серверу о переадресации порта до тех пор, пока соединение не будет полностью установлено. Более того, при переназначении слушателю различных портов через туннель SSH сведения об адресате в различных TCP-соединениях могут изменяться. Для приложения существовал единственный простой способ динамического информирования протокола SSH о месте предполагаемого указания сокета. Клиент мог по требованию переадресовать порт путем использования протокола SOCKS4...

Древний протокол SOCKS4 был разработан для предоставления клиенту простейшего способа информирования о своих намерениях модуля доступа прокси (модуль доступа прокси (proxy) - механизм, посредством которого одна система представляет другую в ответ на запросы протокола) сервера, к которому клиент пытается подключиться. Модули доступа прокси являются нечто большим, чем просто серверами, обслуживающими сетевые подключения клиентов, которые желают получить доступ к сети. Клиент передает модулю доступа запрос для сервера, к которому клиент хотел бы подключиться. После этого модуль доступа прокси передает запрос по сети, а ответ на него пересылает обратно клиенту. Это именно то, что требовалось для переадресации (перенаправления) динамического порта (dynamic port forwards) протокола SSH. Можно ли в этой ситуации использовать управляющий протокол, подобный протоколу SOCKS4? Протокол SOCKS4, основанный на добавлении всего лишь нескольких бит в конец и начало TCP-сессии, характеризуется практическим отсутствием непроизводительных издержек при передаче пакета. Он уже интегрирован в большое число ранее существовавших приложений. В состав протокола включены даже хорошо продуманные упаковщики (упаковщик (wrapper) - программные средства создания системной оболочки для стандартизации внешних обращений и изменения функциональной ориентации действующей системы), которые позволяют реализовать любые приложения, а не только suid-приложения, с поддержкой сетевых возможностей и умеющих работать с модулем доступа прокси.

Найденное решение было вполне приемлемым. Приложения могли выдавать запросы, а протокол мог отвечать на них. Все необходимые для клиента вещи были для него понятны. По этой причине в пакет OpenSSH, начиная с его первой общедоступной версии 2.9.2р2, была встроена поддержка протокола SOCKS4 (для этого необходимо всего лишь обновить клиентскую часть, хотя новейшие сервера работают устойчивее, если они используются для этой цели). Неожиданно была рождена виртуальная частная сеть VPN (Virtual Private Network) для бедных. Запустить механизм переадресации динамического порта очень просто. Для этого достаточно указать порт для прослушивания: ssh - Dl istening_port user@host. Например,

effugas@OTHERSHOE ~/.ssh $ ssh effugas@10.0.1.10 -D1080 Enter passphrase for key “/home/effugas/.ssh/id_dsa”:

Last login: Mon Jan 14 12:08:15 2002 from localhost.localdomain [effugas@localhost effugas]$

В результате все подключения к адресу 127.0.0.1:1080 будут вынуждены пересылать в зашифрованном виде свои данные через адрес 10.0.1.10 любому адресату, запрошенному приложением. Процесс получения приложений, которые могут выдать подобные запросы, несколько грубоват, но это намного проще уловок, столь необходимых для переадресации локальных портов. Теперь приведем несколько примеров настроек. Internet Explorer 6: создание безопасной работоспособной Web-сети Хотя простые Web-страницы могут быть легко переадресованы при помощи локальной переадресации порта, сложные Web-страницы ужасно пострадают при их передаче по протоколу SSH или, по крайней мере, при его использовании. Настройка Web-браузера для использования ранее описанного динамического механизма переадресации довольно проста. Для браузера Internet Explorer она состоит из следующих шагов.

1. Выделите пункты меню Tools I Internet Options.

2. Выберите вкладку Connections.

3. Щелкните на кнопке LAN Settings. Проверьте параметры Use a Proxy Server и щелкните на кнопке Advanced.

4. Перейдите к текстовым полям, описывающим протоколы SOCKS. Введите строку 127.0.0.1 в поле адреса хоста и укажите в поле номер порта величину 1080 (или укажите другой номер порта, который был выбран для динамической переадресации).

5. Щелкнув на кнопке OK, закройте все три окна.

После этого войдите в сеть Web. Если все работает, то наиболее вероятно, что все работает через протокол SSH. Предполагая, что все работает так, как надо, можно увидеть что-то похожее на изображенное на рис. 13.2.

Доступ к сайту FARK через протокол SSH Для проверки функционирования связи через SSH введите символы -# в своем окне протокола SSH

Рис. 13.2. Доступ к сайту FARK через протокол SSH Для проверки функционирования связи через SSH введите символы -# в своем окне протокола SSH. В результате будет показано текущее представление порта с активной переадресацией:

$ The following connections are open:
#1 client-session (t4 rO i 1/0 0I6/O fd 5/6)
#2 direct-tcpip: listening port 1080 for 216.7.64.9 port 80, connect
from 127.0.0.1 port 2166 (t4 rl il/0 0I6/O fd 8/8)
#3 direct-tcpip: listening port 1080 for 216.7.64.14 port 80, connect
from 127.0.0.1 port 2198 (t4 r2 il/0 0I6/O fd 9/9)
#4 direct-tcpip: listening port 1080 for 216.7.64.14 port 80, connect
from 127.0.0.1 port 2209 (t4 r3 il/0 0I6/O fd 10/10)
$ nslookup 216.7.64.9
Server: dns-sj3.cisco.com Address: 171.68.10.70 Non-authoritative answer:

Name: www.fark.com Address: 216.7.64.9

Инструментарий и ловушки

Ограничения, накладываемые на динамическую переадресацию и протокол

SOCKS4

На сервер с уже работающим демоном SSH не требуется устанавливать специальное программное обеспечение для его использования в качестве «виртуальной частной сети VPN для бедных», но новейшие версии SSHD обеспечивают более стабильную работу линии с переадресованным портом. Демоны старших версий могут временно блокировать соединение при попытке установить соединение с несуществующим или недостижимым хостом. Можно наткнуться на ошибки в том случае, когда в результате статической переадресации локального порта устанавливается указатель на взломанный хост. Они вызваны тем, что статическая переадресация обычно указывает лишь на устойчиво работающие хосты. Разрешить эту проблему можно путем инсталляции на удаленную машину усовершенствованной версии OpenSSH. (Для более подробных сведений пусть читатель ознакомится со специальным разделом, в котором описано, как это сделать. Заметим, что для инсталляции OpenS SH совсем необязательно обладать правами суперпользователя.)

Большую обеспокоенность вызывает тот факт, что переадресация по протоколу SOCKS4 оказывает воздействие только на сам трафик. Она не переадресовывает запросы DNS, которые используются для управления трафиком. Поэтому администратор на локальной линии может контролировать подключение к ней и даже изменять адресата, хотя соединение читателя само по себе может быть безопасным. Это может создавать серьезный риск безопасности. Есть надежда, что в ближайшем будущем названная проблема будет благополучно решена при помощи реализации в семействе клиентов OpenSSH возможности динамической переадресации по протоколу SOCKS5.

Тем временем обе проблемы древних серверов и протоколов могут быть частично разрешены путем инсталляции на сервере небольшой порции программного кода, позволяющего работать по протоколу SOCKS4/5. Автор отдает предпочтение программе usocksd, доступной по адресу http://sites.inkade/sites/bigred/sw/usocksd-0.9.3.tar.gz. Хотя программа usocksd поддерживает только протокол SOCKS5, она удаленно разрешает имена и остается стабильной при неблагоприятных для нее сетевых условиях. Запуск ее не слишком сложен:

Dan@EFFUGAS ~ $ ssh -L2080:127.0.0.1:2080 effugas@ 10.0.1.11 “./usocksd -р 2080”

effugas@ 10.0.1.11 ’s password:

usocksd version 0.9.3 (с) Olaf Titz 1997-1999

Accepting connnections from (anywhere) ident (anyone)
Relaying UDP from (anywhere)
Listening on port 2080.

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

Говорите свободно: мгновенная передача сообщений по SSH Вероятно, осталось всего лишь несколько хакеров старой закалки, кто, возможно, скорбит об этом. Мгновенный обмен сообщениями является одной из революционных новинок для сети. Существуют две главные причины, по которым приблизительно в начале 2002 года мгновенная передача сообщений на общедоступном уровне сильно всех раздражала (в противоположность корпоративному / внутреннему уровню). Во-первых, будучи грубоватой, она не могла обеспечить достаточной безопасности. Обычно сообщения посылаются от компьютера к центральному серверу и обратно в открытом виде, поэтому любой, находясь в школе или на работе, может перехватить их во время передачи.

Другой причиной, вызывающей раздражение, является отсутствие приличных стандартов мгновенной передачи сообщений. Хотя IETF (Internet Engineering Task Force -

проблемная группа проектирования Интернет, отвечающая за решение инженерных задач Интернет. Она выпускает большинство RFC, используемых производителями для внедрения стандартов в архитектуру TCP/IP) работает на чем-то, что известно как SIMPLE (расширение сокращения SIP), но у каждого производителя свой протокол, по которому никто другой не может взаимодействовать. Для установки голосовой связи с любой точкой мира нет необходимости использовать набор из четырех телефонов, но до сих пор сохраняется необходимость в четырех клиентах для словесного обмена через Интернет.

Однако такова плата за централизацию мгновенной передачи сообщений, которая по сравнению с одноранговой сетью (соединение равноправных узлов сети, отличающееся отсутствием выделенного файл-сервера), как, например, ICQ (произносится как «I seek you»

- система интерактивного общения в Интернете. Позволяет находить в сети партнеров по интересам и обмениваться с ними сообщениями в реальном масштабе времени. Продукт компании Mirabilis, в настоящее время принадлежащей корпорации America Online; которая в конечном итоге частично использует идею централизации), значительно надежнее и лучше защищена межсетевым экраном. Все было бы еще ничего, если существовал бы какой-нибудь способ смягчить последствия темных сторон чата (обмена текстовыми сообщениями между абонентами сети Интернет в реальном масштабе времени).

Связь всех сообщений в один узелок: работа программы Trillian по протоколу SSH. ПрограммаТпШап является свободно распространяемым и, безусловно, блестящим программным кодом для платформы Win32. Она является необыкновенно элегантным и функционально полным клиентом чата. Программа Trillian в рекламе не нуждается. Программа Trillian поддерживает Yahoo, MSN, ICQ, AOL и даже IRC. Она предоставляет унифицированный интерфейс ко всем пяти сервисам точно так же, как и многопользовательские профайлы операционных систем.

Программа непосредственно поддерживает модули доступа проксипротокола SOCKS4. Это означает, что нет легкого способа избежать поступления на сервер необработанных данных незашифрованного текста. (Хотя в программе предусмотрен режим SecurelM, позволяющий двум пользователям программы Trillian установить соединение более безопасным способом.) Но, по крайней мере, с помощью программы можно экспортировать незашифрованный текст за пределы своей локальной сети, где уйма любопытных глаз следит за проходящим трафиком, если он может там пройти. Установка поддержки протокола SOCKS4 в программе Trillian очень проста.

1. Щелкните на большом изображении земного шара в нижнем левом углу и выберите пункт меню Preferences.

2. Выберите пункт меню Proxy из списка выражений с левой стороны. Приблизительно это девятый пункт меню при просмотре списка сверху вниз.

3. Отключите опции Use Proxy и SOCKS4.

4. Введите в поле, описывающее адрес хоста, значение 127.0.0.1 и укажите в поле, задающем номер порта, величину 1080 (или любой другой используемый пользователем номер порта).

5. Щелкните на кнопке OK и начните регистрацию внутри своего сервиса. Теперь вся работа будет осуществляться через протокол SSH.

Вы кто? Yahoo IM 5.0 по протоколу SSH. При настройке браузера Internet Explorer для работы по протоколу SOCKS с модулем доступа проксилокального хоста Yahoo заработает автоматически, но при этом он попытается использовать пятую версию протокола SOCKS вместо четвертой, которую браузер пока еще не поддерживает. Но в любом случае установка Yahoo для работы с SOCKS4/SSH довольна проста:

1. Перед подключением выберите пункты меню Login I Preferences.

2. Выберите вкладку Use Proxy.

3. Включите опцию Enable SOCKS Proxy.

4. Используйте в поле Server Name значение 127.0.0.1 и в поле Port величину 1080 (или другие значения по усмотрению читателя).

5. Выберите Ver 4.

6. Щелкните на кнопке ОК.

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

Криптография в коротких штанишках: работа AOL Instant Messenger 5.0 по протоколу SSH. Установка этой программы также очевидна. Помните, что если динамическая переадресация не отскакивает рикошетом куда-либо, будь то школьный или домашний сервер читателя, то ничего передать не получится.

1. Выберите пункты меню My ATM I Edit Options I Edit Preferences.

2. Щелкните на Sign On/Off в домашней строке состояний слева.

3. Щелкните на вкладке Connection для настройки AIM (AOL Instant Messenger 5.0) для своего проксисервера.

4. Проверьте поле Connect Using Proxy и выберите своим протоколом SOCKS4.

5. Используйте значение 127.0.0.1 в качестве IP-адреса своего хоста и величину 1080 в качестве значения номера порта (или другие значения, которые использует читатель).

6. На обоих раскрытых окнах щелкните на кнопке ОК. После перечисленных действий у читателя появится возможность подключиться. Только пусть читатель помнит о необходимости блокировки конфигурации модуля доступа прокси, если он еще раз захочет напрямую подключиться через Интернет.

BorgChat: Microsoft Windows Messenger по протоколу SSH. Требуется выполнить чуть больше тех же самых действий.

1. Выберите пункты меню Tools I Options.

2. Щелкните по вкладке Connections.

3. Включите опцию поля I Use A Proxy Server и убедитесь, что выбрано значение SOCKS4.

4. Введите в поле Server Name значение 127.0.0.1 и задайте номер порта величиной 1080 (или как-то иначе).

5. Щелкните на кнопке ОК.

Оболочка: инкапсуляция произвольных приложений Win32 внутри механизма динамического продвижения данных

Как правило, любое приложение, которое обрабатывает выходящие ТСР-соединения, может быть достаточно легко выполнено при помощи динамической переадресации. Стандартным инструментальным средством для инкапсуляции протокола SOCKS на платформе Win32 (также немного обсудим и UNIX) является инструментарий SocksCap компании NEC. Это неудивительно, потому что именно она изобрела протокол SOCKS. Кроме того, NEC известна тем, что подарила миру TurboGrafx-16. Инструментарий SocksCap можно найти по адресу www.socks.nec.com/reference/sockscap.html. SocksCap предоставляет дополнительный модуль запуска для приложений, у которых иногда возникает необходимость пройти модуль доступа проксипротокола SOCKS без обязательного написания 10 строчек программного кода, обязательного для поддержки работы протокола SOCKS4 (вздох).

Использовать SocksCap тривиально. Первое, что следует сделать после его запуска, -это перейти в меню, выбрав пункты File I Settings, ввести в поле Server его 1Р-адрес 127.0.0.1 и указать значение 1080 для номера порта. После щелчка на кнопке ОК останется просто перетащить в окно SocksCap ярлык приложения, которое было только что запущено для передачи или приема данных через туннель, созданный при помощи протокола SSH. На самом деле читатель может просто перетащить из меню Start нужные пункты в окно Control инструментария SocksCap (см. рис. 13.3). Приложения, на которые указывают выбранные пользователем пункты меню, могут быть выполнены непосредственно или добавлены в «профайл» для выполнения их позднее.

Настройки протокола SOCKS в Windows с помощью инструментария

Рис. 13.3. Настройки протокола SOCKS в Windows с помощью инструментария

SocksCap

Большинство вещей «просто работают». Но одно из них - FTP - работает особенно хорошо, быстро передавая данные при помощи протокола SSH. Запомните: FTP поверх SSH при помощи LeechFTP. Долгое время слабым местом протокола FTP была неудовлетворительная поддержка передачи файлов по протоколу SSH. Потребность в передаче данными по протоколу FTP поверх SSH очень велика. Мысль об исправлении этого недостатка долгое время не давала покоя разработчикам, но для этого основательно топорному протоколу был необходим специальный пакет. Отражая указанные потребности, SSH.com и MindTerm в своих более поздних версиях программного обеспечения реализовали специальный уровень FTP трансляции. С другой стороны, OpenSSH обрабатывает протокол FTP точно так же, как и любой другой нетривиальный протокол, причем делает это достаточно хорошо.

Нет никаких сомнений в том, что программа LeechFTP является выдающимся клиентом FTP для Windows. Написанная Яном Дебисом (Jan Debis) программа LeechFTP доступна по адресу http://stud.fh-heilbronn.de/~jdebis/leechftp/files/lftpl3.zip. Она относится к классу свободно распространяемых, многопоточных и простых в использовании программ. Кроме того, LeechFTP прекрасно инкапсулируется в SocksCap и OpenSSH. Одним из наиболее важных режимов настройки работы протокола FTP является переключение с активного режима работы (Active FTP) к пассивному (Passive FTP). В активном режиме сервер инициализирует дополнительные TCP-соединения к клиенту, внутри которых будут переданы отдельные файлы, а в пассивном - сервер именует TCP-порты таким образом, чтобы клиент подключался к ним и переданное по ним содержимое было отдельным файлом.

Переключение режимов осуществляется следующим образом.

1. Выберите пункты меню File I Options.

2. Щелкните на вкладке Firewall.

3. Включите опцию PASV Mode.

4. Щелкните на кнопке OK и подключитесь к какому-либо серверу. Сверкающая стрелка в левом верхнем углу (см. рис. 13.4) является признаком успешного начала работы.

Рис. 13.4. Обработка данных программой LeechFTP Насколько хорошо это работает? Посмотрите на рис. 13.4. Семь потоков с высокой скоростью обрабатывают данные, используя динамически определяемые порты. Они делают это специально для автора. На суд к Виргилию: команда socksify клиента Dante для инкапсуляции приложений UNIX Для передачи данных через межсетевые экраны в некоторые инструментальные средства UNIX встроена поддержка протокола SOCKS, но таких средств немного. Большинство инструментальных средств в этом направлении вообще ничего не делает. К счастью, с помощью клиента Dante можно добавить поддержку протокола SOCKS во все динамически подключенные приложения. Разработанная компанией Inferno Nettverks программа Dante является промышленной улучшенной реализацией протоколов SOCKS4/SOCKS5. Хотя и с трудом, но ее можно откомпилировать на большинстве платформ. Программа Dante находится по адресу ftp://ftp.inet.no/pub/socks/dante-l. 1.11 .tar.gz.

Первое, что нужно сделать после ее инсталляции, - это на системном уровне настроить протокол SOCKS. Конечно, это сильно раздражает, но выбора нет (по крайней мере, сейчас). Для настройки протокола создайте файл под именем /etc/socks.conf и запишите в него следующее:

route { from: 0.0.0.0/0 to: 0.0.0.0/0 via: 127.0.0.1 port = 1080 proxyprotocol: socks_v4 }

После этого нужно адаптировать приложения для работы с протоколом SOCKS, выполнив перед их запуском команду socksify. Это заставит приложения устанавливать соединения при помощи механизма динамического продвижения данных, который установлен таким образом, что к нему можно обратиться через порт 1080. Из-за централизованного размещения настроек протокола SOCKS необходимо одновременное выполнение двух условий. Во-первых, к системе, на которой работает пользователь, нужен доступ суперпользователя. И во-вторых, следует ограничиться одновременной работой только с одним динамическим механизмом продвижения данных. Для ознакомления с последними сведениями об этих раздражающих ограничениях зайдите на сайт www.doxpara.com/tradecraft или Web-сайт книги www.syngress.com/solutions. В некоторых приложениях, прежде всего это относится к таким известным программам, как Mozilla и Netscape, очень удачно реализована поддержка протокола SOCKS. В большинстве случаев подобные приложения могут быть настроены точно так же, как и браузер Internet Explorer. К сожалению, приложения класса setuid в общем случае не могут воспользоваться таким способом переадресации. К ним часто относят ssh, хотя для него устанавливать идентификатор пользователя setuid уже не требуется. Если говорить в целом, то большинство вещей, реализованных на основе сказанного, работают вполне успешно. Ниже показан работающий пример работы одной из таких реализаций, основанный на запуске SSH с опцией D1080:

bash-2.05а$ socksify ncftp NcFTP 1.9.5 (October 29, 1995) by Mike Gleason, NCEMRSoft. ncftp>set passive ncftp>open mirrors.rcn.net

ProFTPD 1.2.0 Server (RCN Mirrors) [mirrors.rcn.net]
Anonymous login ok, send your complete e-mail address as password.
Anonymous access granted, restrictions apply.
Logged into mirrors.rcn.net.
mirrors.rcn.net:/
ncftp>ls
debian@ mirrors/ pub/
mirrors.rcn.net:/
ncftp>

Конечно, подключение проверяется на прохождение через механизм переадресации SSH пользователя так, как это показано ниже:

libertiee:~> ~# The following connections are open:
#2 client-session (t4 rO il/0 0I6/O fd 6/7)

#3 direct-tcpip: listening port 1080 for 207.172.2.141 port 21, connect from 127.0.0.1 port 1666 (t4 rl il/0 о 16/0 fd 9/9)

Переадресация удаленного порта

Последний предусмотренный в протоколе SSH тип переадресации порта известен как переадресация (перенаправление) удаленного порта (remote port forward). Переадресация удаленного порта, так же как и переадресация динамического порта, позволяет эффективно импортировать сетевые ресурсы. Тем не менее внешний сервер системы групповых дискуссий в Интернете IRC (Internet Relay Chat - Интернетовские посиделки. Глобальная система, посредством которой пользователи могут общаться друг с другом в реальном масштабе времени) ставится в соответствие локальному хосту, а каждое приложение, обеспечивающее проведение переговоров, запускается по 1Р-адресу 127.0.0.1:1080. Фактически переадресация удаленного порта экспортирует клиентам доступную им возможность сетевого взаимодействия. Экспорт осуществляет через сервер, к которому этот клиент подключен. Сказанное поясняет приведенный ниже пример:

ssh -R listening_port:destination_host:destination_port user@forwarding_host

Все точно так же, как и в случае переадресации локального порта, но теперь слушающим порт находится на удаленной машине, а порты назначения являются портами, которые обычно видны клиенту. Программа WinVNC является одним из наиболее полезных сервисов переадресации, особенно на платформе Windows (позднее будут обсуждены вопросы переадресации на платформе UNIX). Она доступна по адресу www.tightvnc.com. Программа предоставляет простой для удаленной настройки интерфейс управления. Другими словами, с ее помощью можно увидеть работающий удаленный компьютер и исправить на нем ошибки. Переадресация удаленного порта позволяет экспортировать адресату интерфейс компьютера за пределы защищаемой межсетевым экраном зоны.

Есть ли у читателя запущенный сервер виртуальной сетевой обработки данных VNC? Да, есть:

Dan@EFFUGAS ~ $ telnet 127.0.0.1 5900 Trying 127.0.0.1...
Connected to 127.0.0.1.

Escape character is “A]”.

RFB 003.003 telnet> quit Connection closed.

Соединитесь с другой машиной, переадресуя ее порт 5900 к собственному порту 5900. Dan@EFFUGAS ~ $ ssh -R5900:127.0.0.1:5900 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

Проверьте, будет ли удаленный компьютер видеть свой порт 5900. Проверку выполните точно так же, как и в случае тестирования собственного порта 5900 на локальном компьютере:

$ telnet 127.0.0.1 5900 Trying 127.0.0.1...
Connected to localhost.

Escape character is “A]”.

RFB 003.003

Обратите внимание на то, что удаленная переадресация порта не очень-то доступна. Другие машины с сетевым адресом 10.0.1.11 могут не увидеть порт 5900. Опция GatewayPorts программы SSHD позволяет решить это. Но как будет показано дальше, подобные установки необязательны.

Когда-то в Риме: пересекая непокорную сеть

Допустим, что есть сервер с запущенной на нем программой sshd и клиент с программой ssh. Сервер и клиент хотят установить связь, но сеть не настолько хороша и покорна, чтобы позволить им сделать это. При попытке установить соединение пакеты теряются, связь не устанавливается. Что делать? В рассматриваемом случае возможность прохождения пакетов обычно определяется тем, кто посылает и что посылает. Повышение проходимости пакетов через сеть будет означать изменение маршрута трафика SSH или маршрута непосредственной пересылки данных через сеть.

Прохождение моста: доступ к модулям доступа прокси с помощью опции

ProxyCommand

В действительности довольно редко можно встретить сеть, которая непосредственно запрещает выходящие соединения по протоколу SSH. Когда такое случается, то это означает запрет в сети всех выходящих соединений. Обойти этот запрет можно при помощи маршрутизации выходящих соединений через прикладной уровень модулей доступа прокси. Не являясь средством полной дезинформации, модули доступа прокси предоставляют гораздо более простой метод скрытного доступа, чем современные решения трансляции сетевых адресов NAT. По сравнению со многими протоколами модули доступа прокси обладают дополнительными преимуществами, которые позволяют им лучше осуществлять кэширование. Поэтому прокси небесполезны. Существует много различных подходов построения и использования модулей доступа прокси, но поскольку обычно они почти ничего не добавляют к обеспечению безопасности выходящих соединений, то у разработчиков пакета OpenSSH не было желания реализовать их непосредственно внутри клиента. Реализация каждого из этих подходов непосредственно в модуле доступа прокси может превратиться в один из подвигов Геракла.

Поэтому вместо непосредственной интеграции в пакет OpenSSH была добавлена опция общего назначения ProxyCommand. Как правило, используя некоторый порт, протокол SSH непосредственно устанавливает TCP-соединение с заданным хостом и обменивается данными с каким-нибудь найденным там демоном, который может работать по протоколу SSH. Кроме того, опция ProxyCommand отключает это TCP-соединение, маршрутизируя все данные соединения через стандартный поток ввода-вывода I/O, который передается произвольному приложению и принимается от него. Это приложение может выполнять какие-то преобразования, которые потребуются при получении данных от модуля доступа прокси. Задача приложения будет полностью выполнена, если будет установлена полностью работоспособная связь с демоном протокола SSH. Разработчики добавили минимально возможное количество переменных, завершающихся спецификациями преобразования %h и %р, которые соответствуют адресу хоста и номеру его порта. Если клиент SSH инициализировал TCP-соединение, то он ждет эти данные. (Вне всякого сомнения, аутентификация хоста соответствует этим ожиданиям.)

Быстрая демонстрационная версия работы опции ProxyCommand выглядит следующим образом:

# Negotiate an SSH connection with whatever we find by directly

# establishing a TCP link with 10.0.1.11:22 bash-2.05a$ 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 $
# Establish a TCP connection to 10.0.1.11:22 $ nc 127.0.0.1 22 SSH-1.99-OpenSSH_3.0.1pl
# Negotiate an SSH connection with whatever we find by using netcat to

# indirectly establish a TCP link with 10.0.1.11:22 bash-2.05a$ ssh -o ProxyCommand=“nc 10.0.1.11 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 $
# Add basic variable substitutions to above command

bash-2.05a$ ssh -o ProxyCommand=“nc %h %p” 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, с отличается наибольшей гибкостью реализации возможностей опции ProxyCommand. Ее разработчик Shun-Ichi Goto. Это изящное небольшое приложение можно найти по адресам www.imasy.or.jp/~gotoh/connect.c или

www.doxpara.com/tradecraft/connect.c. Оно поддерживает протоколы SOCKS4 и SOCKS5 с аутентификацией, но без протокола HTTP: • SSH с использованием протокола SOCKS4;

effugas@OTHERSHOE ~ $ ssh -о ProxyCommand=“connect.exe -4 -S

foo@10.0.1.11:20080 %h %р”

effugas@10.0.1.10

effugas@ 10.0.1.10 ’ s password:
Last login: Mon Jan 14 03:24:06 2002 from 10.0.1.11 [effugas@localhost effugas]$

• SSH с использованием протокола SOCKS5;

effugas@OTHERSHOE ~ $ ssh -o ProxyCommand=“connect.exe -5 -S
foo@10.0.1.11:20080
%h %p”

effugas@10.0.1.10

effugas@ 10.0.1.10 ’ s password:
Last login: Mon Jan 14 03:24:06 2002 from 10.0.1.11 [effugas@localhost effugas]$

• SSH с использованием протокола HTTP (запрос HTTP CONNECT выдается программой connect.с).

effugas@OTHERSHOE ~ $ ssh -o ProxyCommand=“connect.exe -H 10.0.1.11:20080 %h
%p”

effugas@10.0.1.10

effugas@ 10.0.1.10 ’ s password:
Last login: Mon Jan 14 03:24:06 2002 from 10.0.1.11 [effugas@localhost effugas]$

Инструментарий и ловушки

Откуда уши растут: использование портов других сервисов

Предположим, что читатель работает в сети, которая не позволяет ему установить непосредственное SSH-соединение к выбранному им серверу. Кроме того, нет ни одного модуля доступа прокси, который очевидным образом позволил бы это сделать. Но при всем при этом передача данных по протоколам HTTP и HTTPS работает вполне успешно. Описанная ситуация может соответствовать случаю блокировки работы по протоколу SSH только из-за того, что данные передаются по портам, которые отличаются от портов 80/tcp (при работе по протоколу HTTP) или 443/tcp (при работе по протоколу HTTP поверх SSL). В этих условиях так и просится запустить демон SSH для работы с этими портами. Это действительно очевидное решение. Известна пара примеров, которые его реализуют:

• реконфигурация SSHD. В конфигурацию sshd добавляется дополнительный порт. Требуется выяснить, какая из настроек sshd config действительно представляет интерес. Часто на выбранной машине может быть несколько отличающихся друг от друга конфигураций sshd, из которых только одна может быть загружена. Это происходит из-за использования различных ухищрений при работе с ними. Как правило, подключившись суперпользователем и введя ps - xf grep sshd, можно обнаружить полный путь к запускаемому демону SSH. После выполнения /path/sbin/sshd - h станет ясно, какой из файлов sshd_config был локализован по умолчанию. Другими словами, будет получено что-то вроде приведенного ниже:

-f file Configuration file (default /usr/local/etc/sshd_config)

Будет достаточно просто добавить строки Port80 или Port443 ниже строчки Port 22, которая по умолчанию задает двадцать второй порт; • реконфигурация inetd. В большинстве UNIX-систем используется демон inetd, который является демоном сетевых сервисов общего назначения. Его конфигурационным файлом является файл / etc/inetd.conf.

Демон inetd прослушивает TCP-порт, имя которого указано в файле /etc/services, и запускает заданное приложение после установки соединения через обслуживаемый им порт. Для переадресации порта команда netcat (пс) может быть успешно соединена по каналу с демоном inetd. В качестве примера создания переадресации порта ниже приводится модификация файла /etc/inetd.conf:

https stream tcp nowait nobody /usr/local/bin/nc nc 127.0.0.1 22

Важно отметить, что ничто не вынуждает netcat указывать на локальный хост localhost. Точно так же можно указать на любой другой выполняющийся в фоновом режиме демон SSH, определяя следующие строки:

https stream tcp nowait nobody /usr/local/bin/nc nc 10.0.1.11 22;

• создание шлюза на локальном хосте localhost для переадресации порта. Это просто, но в то же время эффективно для временного использования. Выполните ssh root@l27.0.0.1 - g - L443:127.0.0.1:22 - L80:127.0.0.1:22. Опция - g, означающая шлюз (по первой букве английского слова Gateway), позволяет нелокальным хостам подключаться к переадресованному порту локального хоста. Выполненное подключение под именем суперпользователя означает, что можно было создать специальный процесс - слушатель трафика, который контролирует (прослушивает) трафик, проходящий через порт, номер которого меньше величины 1024. Таким образом, без необходимости инсталляции какого-либо кода или модификации какой-либо конфигурации появляется возможность порождения дополнительных портов, которые демон SSH может прослушать через порты 80 или 43. Но надо помнить, что переадресация порта сохраняется только на время работы клиента SSH. После выполнения рекомендованных действий проверьте работоспособность TCP-соединения, установленного демоном SSH от клиента к серверу. Для проверки достаточно ввести команды telnet host 80 или telnet host 443. В случае успешной проверки простое выполнение ssh user@host -р 80 или ssh user@host -р 443 окажется существенно проще использования какой-либо разновидности модуля доступа прокси.

Что еще сказать о 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 -о HostKeyAlias=10.0.1.10 -о 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 [effugas@localhost effugas]$

При таком способе несколько увеличивается время ожидания (из-за передачи данных стандартными методами 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 [root@localhost root]#

В конечном счете иногда даже приятно вместо «ssh root@10.0.1.10» ввести ssh effugas@10.0.1.11. Но если это допускается, то подобный метод слишком опасен. Он создает предпосылки для чрезвычайно эффективного массового проникновения к внутренним системам. Причина этого проста. Какому хосту на законных основаниях могут довериться, чтобы получить доступ к частному адресату? Первоначальному клиенту, понимая под этим и пользователя, который физически сидит перед компьютером. Какова истинная цель обращения хоста к частному адресату? В результате чей SSH-клиент обращается к конечному серверу SSH? Клиент бастиона. Хост-бастион получает и ретранслирует пароль в открытом, незашифрованном виде. Хост-бастион расшифровывает зашифрованный секретный трафик данных. Он может выбрать или не выбрать режим повторной передачи данных, не тревожа такими «мелочами» первоначального клиента. Только с помощью хоста-бастиона можно или нельзя решить вопрос о сохранении доступа с правами суперпользователя к внутренним хостам. (Даже одноразовый пароль не защитит от поврежденного сервера, который просто не сообщит о факте отсутствия регистрации нарушений в своей работе.) Перечисленные опасности - не просто теоретические размышления. В большинстве наиболее значимых случаев компрометации 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]# AD Connection to 10.0.1.10 closed. effugas@OTHERSHOE ~

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

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

FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3 13:44:59 GMT 2001 $

Таким образом, пользователь домашнего компьютера, подключенного к сети и защищенного от внешнего мира межсетевым экраном, может установить на нем протокол SSH, который предоставит ему локальный порт, подключившись и работая через который, можно будет получить доступ к SSH-демону на машине, расположенной на работе.

Инструментарий и ловушки

Переадресация локального порта | Защита от хакеров корпоративных сетей | «реверс» клиентов


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



Новости за месяц

  • Июнь
    2019
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс