В этой статье я расскажу как использовать двойной перекрывающий SSH-туннель поверх OpenVPN для доступа ко взломанному удаленному серверу (дедику). Предположим, что дедик у нас уже есть, и нам нужно организовать до него подключение таким образом, чтобы один SSH-туннель перекрывал другой и давал, соответственно, другой IP-адрес. Для примера, возьмем стандартную конструкцию OpenVPN + SSH. Здесь все довольно просто - сначала устанавливается OpenVPN-соединение, затем подключение к удаленному SSH-серверу через plink.exe, где в строке конфигурации прописаны параметры доступа и порт перенаправления. В данной конструкции уязвимым местом является ваш OpenVPN-сервер, который в случае работы правоохранительных органов будет легко обнаружен методом запроса в датацентр, где находился на тот момент SSH-сервер. Одним из возможных решений является использование двойного перекрывающего SSH, когда при запросе на входящий узел, с которого осуществлялась кибератака, правоохранительные органы уткнутся в другой SSH-сервер на другом конце Земли, что позволит выиграть время и, в большинстве случаев, избавиться от возможных проблем, особенно если промежуточный SSH-сервер находится на островах (таких, например, как остров Диего Гарсия). Не буду вдаваться в теоретические подробности того, каким образом вы будете покупать первичное звено доступа - OpenVPN-сервер, поскольку на Античате я неоднократно говорил о том, что наилучшим OpenVPN-аккаунтом является доступ, купленный у зарубежного продавца с использованием платежной системы LibertyReserve. Далее, вам необходимо иметь 2 доступа на SSH-серверы. Их можно сбрутить, получить бесплатно на некоторых порталах Интернета или купить за небольшую сумму (около 4 USD за один туннель). Для меня предпочтительным является первый вариант, т.к. он дает наибольший простор для выбора различных стран, в том числе экзотических. Купить SSH-туннель можно в этой теме или у меня. Не обращайте внимания на дизайн, сайт создавался с дизайном в стиле начала 90-х годов не для того, чтобы быть полноценным Интернет-проектом, а как информационное объявление, тем более домену нашлось применение. Далее, имея в наличии 2 доступа к SSH-серверам, мы можем организовать двойное перекрывающее подключение. Делается это следующим образом. Сначала устанавливается программа SocksCAP, позволяющая соксифицировать приложения на компьютере для работы через SOCKS5. Главный интерфейс программы предельно прост и выглядит следующим образом: Новая программа добавляется нажатием кнопки "New...", далее появляется следующее окно: Здесь, кнопкой "Browse..." выбирается приложение для соксификации. После выбора приложения оно будет работать в соответствии с главным настройками программы. В нашем случае, поскольку при подключении к SSH-серверу создается сервис SOCKS5 с использованием зашифрованного канала, в настройках SocksCAP должен быть прописан адрес SOCKS5 - 127.0.0.1, т.к. на этот локальный адрес осуществляется перенаправления траффика. Далее, в зависимости от выбранного порта форвардинга, мы соответствующим образом настраиваем SocksCAP. Например, мы подключились к SSH-серверу в Кении и сделали перенаправляющий порт траффика 8010, следовательно в SocksCAP нужно указать адрес подключения 127.0.0.1 и порт 8010. Выглядит это следующим образом: После этого в список можно добавлять приложения, работать они будут по зашифрованному каналу только когда SSH-туннель подключен. Учитывая то, что SocksCAP может соксифицировать любое приложение, следовательно, есть возможность соксифицировать и саму программу, управляющую созданием туннелей, т.е. сам plink.exe. Для этого необходимо добавить сам plink.exe в список соксифицированных программ. Выглядит это следующим образом: Поскольку SOcksCAP воспринимает не только само приложение, но и возможные дополнительные аттрибуты командной строки для него, значит мы можем прописать в строку соксифицированного plink.exe параметры доступа к другому SSH-серверу. Предположим, у нас есть 2 настроенных на доступ к SSH-серверам в Кении и Мозамбике BAT-файла, где прописаны команды доступа. В зависимости от того, какой туннель мы хотим сделать перекрывающим, мы должны прописать параметры его доступа в текстовое поле командной строки в соксифицированной версии plink.exe. Предположим, у нас есть SSH-сервер в Мозамбике, который мы хотим сделать перекрывающим относительно Кении, параметры доступа к серверу следующие: plink.exe -ssh 196.46.11.140 -C -N -l root -pw admin -D 8089 -v Теперь мы должны прописать эти параметры в текстовое поле соксифицированной версии plink.exe в SocksCAP. Выглядит это следующим образом: Перенаправляющие порты должны различаться и должны быть не заняты каким-либо системным приложением, т.е. если в первом случае перенаправляющим портом был 8010, то вторым перенаправляющим портом перекрывающего туннеля должны быть любой, отличный от предыдущего, и вместе с тем свободный для системы. В данном случае был выбран порт 8089. Затем, установив параметры командной строки в соксифицированной версии plink.exe, мы запускаем туннель до Кении. После успешной установки туннеля до Кении активируем соксифицированную версию plink.exe, в результате чего мы получаем следующее: Насколько видно из приведенного рисунка, сначала был установлено соединение по SSH-туннелю до Кении, после чего была подключена соксифицированная версия plink.exe с указанными параметрами командной строки, настроенная на доступ ко второму SSH-серверу в Мозамбике. На это указывает в том числе строка Opening forwarded connection to 196.46.11.140, порт 22. Адрес 196.46.11.140 является действующим адресом SSH-сервера, расположенного на территории Мозамбика. Тепем мы можем использовать адрес 127.0.0.1 с адресом 8089 в любом приложении, в котором есть поддержка использования SOCKS5-сервера. Для примера, организую подключение до whoer.net в браузере FireFox. Результат: Проверить прямую зависимость работы перекрывающего туннеля от вышестоящего можно, например, полностью разорвав соединение нижестоящего туннеля, в данном случае SSH-туннеля до Кении. Визуально результат работы перекрывающего туннеля на Мозамбик выглядит следующим образом: Насколько видно из вышеприведенного рисунка, туннель на Кению "молчит" с запущенным портом на Мозамбик, через мозамбикский туннель активно идет траффик. Соответственно, при закрытии окна консоли активированного нижестоящего доступа до Кении автоматически закроется окно вышестоящего перекрывающего туннеля до Мозамбика и траффик всех приложений, соксифицированных на Мозамбик, остановится. Вкратце скажу, что по личным впечатлениям от использования двойного перекрывающего SSH-туннеля вы потеряете в скорости, но повысите анонимность. В дальнейшем в этой теме я опишу как можно использовать двойной перекрывающий SSH-туннель для доступа ко взломанным выделенным серверам (дедикам).
Подключение к RDP с использованием двойного перекрывающего SSH-туннеля Как было ранее обещано, публикую схему подключения к удаленному выделенному серверу с использованием двойного перекрывающего SSH-туннеля. Основную концепцию, я думаю, вы уже поняли, поэтому представленная далее схема не будет представлять трудности в понимании и реализации. Подключение к RDP с использованием перекрывающих туннелей реализуется на уровне параметров командной строки соксифицированного на нижестоящий туннель приложения plink.exe. Данные параметры командной строки нужно указать там же, где были указаны параметры подключения ранее: Только теперь мы увеличиваем длину параметров командной строки, добавляя в нее адрес подключения удаленного RDP-сервера и его порт. Также необходимо добавить порт, на который будет осуществляться локальный форвардинг с SSH-туннеля. Общий синтаксис выглядит следующим образом: plink.exe -ssh -l <логин> -pw <пароль> -L <форвардинг-порт для RDP>:<адрес RDP-сервера>:<удаленый порт RDP> -P 22 -2 -C -N <адрес ssh-сервера> Разберем все параметры по порядку: 1. <логин> - логин доступа к удаленному SSH-серверу, во взломанных вариантах обычно "root", "admin" 2. <пароль> - пароль доступа к удаленному SSH-серверу, во взломанных вариантах значения как правило эквиваленты логинам или меняются местами 3. <форвардинг порт для RDP> - локальный порт, на который будет идти зашифрованный траффик с RDP-соединения 4. <адрес RDP-сервера> - IP-адрес дедика 5. <удаленный порт RDP> - порт дедика, как правило 3389 6. <адрес ssh-сервера> - адрес SSH-сервера, через который будет идти траффик Пример: plink.exe -ssh -l root -pw admin -L 7071:102.34.121.134:3389 -P 22 -2 -C -N 88.12.4.231 Данные параметры командной строки означают, что будет происходить подключение к SSH-серверу по адресу 88.12.4.231 с логином root, паролем admin. В дальнейшем, данный SSH-сервер будет подключен к удаленному RDP-серверу с IP-адресом 102.34.121.134, портом 3389. 7071 - порт, который должен быть указан в параметрах подключения в программе Remote Desktop Connection. Скриншот далее: Таким образом, задействовав первичный нижестоящий туннель и соксифицировав соответствующим образом plink.exe, указав там нужные параметры командной строки, можно осуществлять доступ к дедику используя двойное перекрывающее туннелирование.
При использовании vpn+2ssh по схеме, со включеным network.proxy.socks_remote_dns, firefox отказывается посылать запросы. При смене socks_remote_dns на false все работает, но палятся днс vpn. как решить проблему?
Единственное решение, которое можно предложить- это проставить днс гугла или любые другие днс. Вообще, многие переоценивают факт палева днс. Технически довольно сложно их спалить, к тому же, если отключить в фф яву и флеш или что-то там, через что он палит (уже не помню), DNS перестанут палиться.
Ну это не из мира фантистики уже, гугл уже вычисляет пользователей даже через систему ТОР с помощью не хитрых математических формул. (По поводу DNS) Идеальный вариант иметь свой локальный DNS сервер. P.S. Это я к тому , что не рекомендую использовать 8.8.8.8 и 8.8.4.4 для соблюдения анонимности.
Какой версией FireFox'а пользуетесь? Рекомендую FireFox 3.6.xx, у меня проблем с ним никогда не возникало. Что показывает окно консоли plink.exe вышестоящего туннеля, когда вы включаете network.proxy.socks_remote_dns и посылаете запрос? Скрины можете приложить? Для справки: в очень редких случаях при работе по маленьким странам бывает, что отображаются DNS'ы другой страны. Пример: снят туннель из Грузии, DNS'ы - Китай.
Далее будет описан способ соксификации на двойной перекрывающий туннель любых приложений, а не только программы Remote Desktop Connection. Как вы уже поняли, основной идеей является создание одного туннеля в другом с помощью соксификации самой программы для создания туннелей plink.exe. Как это делать вы можете прочитать выше, там же можно найти пример работы с выделенным сервером. Однако, каждый раз создавать подобную длинную строку доступа требует много времени и внимания, поэтому я решил рассказать об еще одном способе соксификации. На этот раз соксифицировать на двойной перекрывающий туннель можно будет любое приложение. Это достигается довольно просто - использованием второго портативного соксификатора, такого, например, как FreeCap. Описание этой программы и ссылку на скачку можно найти на этом сайте. Основные отличия FreeCap от SocksCap является измененный интерфейс и возможность создания цепочек прокси. Интерфейс программы максимально приближен к SocksCap и не должен доставить вам существенных проблем при освоении. В примере использовалась программа FreeCap версии 3.11. Далее приведен внешний вид главного окна с соксифицированной программой Remote Desktop Connection. Далее предполагается, что вы уже установили двойной перекрывающий туннель с выходом вышестоящего туннеля на порт 8086. В настройках FreeCap указываем тип проски SOCKS5, прописываем настройки локального адреса и порта вышестоящего туннеля. Теперь двойным щелчком запускаем RDC и указываем адрес подключаемого удаленного сервера. В примере использовалась портативная версия Remote Desktop Connection из китайской сборки Windows. Аналогичным образом можно соксифицировать на двойное туннелирование любое приложение, в настройках которого не предусмотрена работа через SOCKS5.
Должно быть примерно так: Проверьте, у вас первый и второй туннель висят на разных портах или одинаковых? Подробнее по разным ошибкам SSH-туннелей можно почитать тут - http://wiki.metawerx.net/wiki/SSHTunnelTroubleshooting
)) А если прописать в ProxyCap как Сокс5, будет работать? Если да, то отпадает гиммор с ручным вбиванием сокса в конфиги программ.
К сожалению, данная версия браузера безнадежно утарела. Сайты в ней работают криво, а иногда и свовсем не работают.
Оригинально и изобретательно. Респектую. Проворачивал нечто подобное с портативными proxifier, проксифицируя один из них. Почему бы вместо предпоследнего в цепочке ssh-тунеля не использовать тор-соединение, в конце тунелируя его, защитив от перехвата трафик?
Всем привет! Все хорошо если "первичное звено" открываешь с чужого IP. Доступ к "телу" ВПН сервера (подключение, получение ключей, оплата, отправка заказа на выбранный тариф) как гуру оставляют без следов?
