Туннелирование в SSH

Тема в разделе "АНОНИМНОСТЬ В ИНТЕРНЕТЕ", создана пользователем illusion, 22 авг 2011.

  1. illusion

    illusion Member

    Сообщения:
    306
    Симпатии:
    0
    Статьи по SSH

    №1. Туннелирование в SSH

    Не секрет, что на сегодняшний день большая часть сервисов не шифруют свои сетевые взаимодействия, в том числе и процесс авторизации. Это значит, что использование этих сервисов не удовлетворяет требованиям конфиденциальности. Многие люди считают, что им нет необходимости защищать свою информацию. Но так кажется только на первый взгляд. К примеру, нарушение тайны личной переписки не редко может принести негативные последствия для собеседников. Если же нарушение конфиденциальности межличностной (или деловой) переписки не пугает, то следует еще учитывать тот факт, что ваша учетная запись открытым текстом передаётся по каналу связи. То есть злоумышленнику будет доступна вся информация, необходимая ему для того, чтобы представиться системе под вашим именем, что может быть очень опасно для вас. Кроме доступа к хранимой на сервисе личной информации злоумышленник сможет действовать от вашего имени. Довольно критическая ситуация, если речь идет о переписке, денежных операциях или администрировании.

    Данная статья не сможет полностью исключить описанную проблему, но поможет установить безопасный канал связи через потенциально ненадёжную сеть. То есть, когда вы выходите в Интернет через чужую инфраструктуру где потенциально могут быть установлены специальные перехватчики пакетов (sniffer), например у знакомых в гостях, ВУЗе, Интернет-клубе, при использовании не защищенных беспроводных сетей и так далее. Для реализации нам понадобится на нашей доверенной машине openssh-server (sshd). Благо по умолчанию он установлен в большинстве дистрибутивов операционных систем семейства UNIX. Со своей стороны вы можете работать как с Windows, так и с UNIX. Оба случая будут рассмотрены ниже.

    Проброс удаленного порта на локальную машину в UNIX

    Рассмотрим проброс удаленного порта на локальную машину в UNIX. Как видно из названия, нам понадобится машина с UNIX с нашей учетной записью и установленным клиентом openssh-client. Рассмотрим ситуацию, где нам надо по безопасному каналу соединится с web-сервером на доверенной машине. Мы можем это сделать, открыв ssh-сессию специальным образом:

    Код:
    ssh -L 3333:127.0.0.1:80 x.x.x.x -N
    Разберем подробно. Ключ -L указывает клиенту ssh что бы он прослушивал указаный далее порт (3333 в примере). Далее через двоеточие IP адрес, с которым мы хотим соединится (адрес сервиса 127.0.0.1 в нашем примере, то есть localhost, то есть он и есть) и через двоеточие порт сервиса (80 в примере). Далее IP адрес нашей доверенной машины (x.x.x.x замените на реальный адрес) и ключ -N, говорящий о том, что вход в систему совершать не надо. Выполнив эту команду, мы создадим туннель через криптостойкое соединение ssh. Теперь, чтобы войти через созданный туннель на целевой сервис нам достаточно обратиться к своему отрытому порту 3333. Помните, что только root может открывать порты ниже 1024. Таким образом, вписав в браузер адрес localhost:3333 , мы попадем на целевой сайт.

    SOSKS в Windows через sshd

    Аналогичный фокус можно проделывать и из операционной системы Windows, используя специальные ssh клиенты. Наиболее популярные из них VanDyke Entunnel и Putty. Но рассмотрим более интересную возможность, а именно проброс не одного порта, а использование удаленного sshd в виде SOCKS сервера. В UNIX клиентах openssh-client для этого нужно заменить ключ -L на ключ -D . Поддерживается 4 и 5я версии протокола SOCKS. Как мы это сделаем:
    1. Запустим Putty, укажем host name и порт при необходимости.
    2. Перейдем на вкладку Connection SSH Tunnels
    3. Укажем в source port любой свободный порт (например 3334).
    4. В Destination укажем lacalhost:3334
    5. Переставим переключатель с Local на Dynamic (динамическое определение целевого хоста).
    6. Нажмём кнопку Add для фиксации изменений настроек туннелирования.
    7. Нажмём Open для соединения и авторизируемся в системе.

    [​IMG]

    До тех пор, пока открыто соединение в Putty с сервером, у нас будет на порту 3334 шифрованный SOCKS туннель до нашего сервера. Рассмотрим как пустить Mozilla Firefox (далее FF) через этот SOCKS:
    1. Запускаем FF
    2. Жмём Инструменты / Настройки... / Дополнительно / Сеть / Настроить
    3. Выбираем Ручная настройка сервиса прокси
    5. Узел SOCKS 127.0.0.1 и порт указанный вами ранее (3334 в примере)

    [​IMG]

    Теперь можно не боятся перехвата cookies или кражи вашей учетной записи на web ресурсы. Аналогичным образом настраивают все приложения, поддерживающие SOCKS. Если приложение не поддерживает его, то его можно пустить через туннель грубой силой при помощи таких программ как freecap, что описывалось в предыдущих статьях.

    Используя описанные выше методы, вы можете не опасаясь перехвата конфиденциальной информации через канал связи использовать свои ресурсы в чужой инфраструктуре.

    авторство: Security Team FOS Black Hat

    №2. Настройка PuTTY: делаем Windows полезным

    В данной статье будет описано как строить SSH-туннели с помощью PuTTY.

    1. Локальный проброс порта

    Рассмотрим следующую ситуацию. Мы находимся внутри корпоративной сети, у нашего компьютера адрес 192.168.0.2, доступ во внешний мир полностью закрыт (то есть никакого NAT-а, proxy и т.п.). Влиять на политику ограничения доступа у нас возможности нет, но зато есть SSH-доступ на один из серверов с маршрутизируемым IP-адресом, который доступен из Интернет. Внутренний адрес этого сервера, пусть будет для примера 192.168.0.3. Структура сети изображена на рисунке:

    [​IMG]

    Предположим, что нам очень нужно подключиться, к примеру, по SSH на некоторый удалённый сервер с IP-адресом 212.212.212.212 где-то далеко в Интернет. Для этого запускаем PuTTY, создаём SSH-подключение к серверу 192.168.0.3 (далее по тексту SSH-сессия 1), идем в пункт Tunnels:

    [​IMG]

    и указываем, что локальный порт 2222 нашего компьютера должен быть поставлен в соответствие порту 22 на сервере с IP-адресом 212.212.212.212. Далее жмем кнопку «Open», авторизуемся на сервере 192.168.0.3. Затем создаём ещё одно подключение (далее по тексту SSH-сессия 2), но уже на localhost, порт 2222 и жмём кнопку «Open»:

    [​IMG]

    В результате SSH-сессия 2 будет туннелироваться (т.е. будет установлена внутри ранее установленной SSH-сессии 1). Для удалённого сервера 212.212.212.212 всё будет выглядеть так, как будто к нему подключается 111.111.111.111:

    [​IMG]

    2. Удалённый проброс порта

    В этом случае подключение внутри SSH-туннеля устанавливается в другую сторону – от удаленного сервера на наш локальный компьютер. Может быть полезно, если требуется открыть доступ к локальным сервисам нашего компьютера. Рассмотрим ту же сеть, что и в пункте 1, но для простоты предположим, что теперь у нас есть NAT:

    [​IMG]

    Здесь уже у нас есть возможность подключаться через SSH напрямую к 212.212.212.212 благодаря наличию NAT-а. А вот 212.212.212.212 подключиться на 192.168.0.2 без специальных ухищрений, понятное дело, не сможет, т.к. 192.168.0.2 не подключен к Интернет непосредственно. Предположим, что пользователю, сидящему под X-ами на 212.212.212.212 нужно через remote desktop попасть на наш компьютер 192.168.0.2. Для этого в SSH-сеансе подключения с 192.168.0.2 на 212.212.212.212 нужно изменить настройки в разделе Tunnels следующим образом:

    [​IMG]

    В результате после успешной авторизации на 212.212.212.212 можно увидеть следующее:

    То есть sshd ожидает подключений на TCP-порт 3333, которые затем по SSH-туннелю будут перенаправлены на 192.168.0.2 порт 3389. И юзер сидящий за 212.212.212.212 сможет с помощью rdesktop увидеть наш рабочий стол:

    [​IMG]

    3. Socks-proxy

    В этом случае мы можем использовать сервер с SSH-демоном как промежуточный (proxy). Схема сети как в случае #1 (без NAT и штатных прокси):

    [​IMG]

    Чтобы заставить PuTTY испольнять роль socks-прокси, нужно параметры SSH-сессии с 192.168.0.2 на 192.168.0.3 изменить следующим образом:

    [​IMG]

    В результате после успешной авторизации со стороны клиента можно будет наблюдать следующее:p>
  2. Esfandiari

    Esfandiari New Member

    Сообщения:
    26
    Симпатии:
    0
    Спасибо за статью
  3. petdronn

    petdronn New Member

    Сообщения:
    23
    Симпатии:
    0
    еще бы мануальчик ssh+socks

Поделиться этой страницей