Создание обратного прокси-сервера Socks5 на PowerShell: Часть 1

Создание обратного прокси-сервера Socks5 на PowerShell: Часть 1

Среди различных возможностей использования SSH, есть возможность создания локального SOCKS5 прокси-сервера, трафик которого будет туннелироваться через удаленный сервер. В нашем материале мы разберем возможности использования двух популярных SSH клиентов - стандартной утилите ssh и популярного Windows клиента PuTTy.

Использование утилиты ssh

В стандартной утилите ssh, которая является частью набора программ OpenSSH и входит в стандартный набор программ Linux и Windows, создание туннелируемого прокси сервера SOCKS5 делается с помощью указания дополнительного параметра-D.

Например, если нужно подключиться к серверу с адресом 192.168.0.1 , используя имя пользователя root , с поднятием SOCKS5 прокси на 3128 порту, то строка подключения будет иметь следующий вид:

ssh -D 0.0.0.0:3128 root@192.168.0.1

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

Использование утилиты PuTTy

1. Запускаем PuTTy, и выполняем стандартные процедуры - вписываем адрес сервера и его порт - к примеру, 192.168.0.1.
2. После этого открываем " Connection - SSH - Tunnels ".
3. Заполняем " Source port " (например, стандартными значениями 3128 или 8080). Отмечаем пункт " Dynamic ".
4. Нажимаем кнопку " Add ". В строке " Forwarded ports " появится строка D3128, или с любым другим значением, которое было установлено в качестве Source port.
5. Нажимаем кнопку " Open ".
6. Откроется окно соединения с SSH сервером, где вам нужно будет ввести свой логин и пароль. После успешной авторизации, можно начинать пользоваться SOCKS5 прокси, которое будет работать по адресу 127.0.0.1:3128 (или любой другой самостоятельно указанный порт).При закрытии окна с подключением к SSH серверу, будет так же завершена работа и прокси-сервера.

Связанные вопросы и ответы:

Что такое обратный прокси-сервер Socks5

1. В условиях реальной сети с потерями практическая скорость прокси зачастую выше, чем у VPN-решений. Это вызвано тем, что при проксировании TCP-соединений ретрансмиты на участках клиент-прокси и прокси-целевой узел происходят независимо. Прокси имеет свои TCP-буферы и кратковременные задержки ввода-вывода в обе стороны не сказываются на передаче с противоположной стороны. VPN же работает только на сетевом уровне (IP) и потерянные сегменты TCP будут пересылаться по всей длине пути от VPN-клиента до целевого сервера.
2. Гибкость. Проще настроить избирательное проксирование. Использование прокси можно ограничить конкретными приложениями, в браузере — конкретными доменами. Можно использовать несколько разных прокси для разных адресов назначения одновременно.
3. Трудно обнаружить с помощью DPI, в том числе DPI осуществляющими активные пробы. Однако, для этого необходима некоторая донастройка. В случае с прокси через TLS, такое соединение можно выдать за обычное HTTPS-соединение. В случае с VPN факт его использования виден даже пассивному DPI. Даже если это Wireguard.
4. Нет целого класса проблем с внезапно прервавшимся VPN-соединением. В худшем сценарии VPN-соединение может прерваться и пользователь не заметит, что его трафик уже не защищён и/или он уже работает со своего «домашнего» IP-адреса. В случае с прокси такие проблемы исключены.
5. Нет принципиальной возможности проводить атаки, пускающие трафик мимо VPN-туннеля. Пример такой проблемы .
6. Не нужны высокие привилегии в системе ни для клиента прокси, ни для сервера. Это может быть весьма полезно в случаях, когда у Вас нет высоких прав в системе.

Зачем нужен обратный прокси-сервер Socks5

Понятное дело, что сперва мы посмотрим в гугл и… не найдем ровным счетом ничего по этой теме (если кто-то нашел — кидайте ссылки в комменты). Есть толькоSocks5 на powershell, но это обычный «прямой» сокс, имеющий ряд своих недостатков (о них поговорим позднее). Можно, конечно, легким движением руки превратить его в обратный, но это будет только однопоточный сокс, что для нас не совсем то, что надо.Итак, мы не нашли ничего готового, поэтому нам придется все-таки изобрести свой велосипед. За основу нашего велосипеда мы возьмемобратного сокса на голанге, а клиента к нему реализуем на powershell. RSocksTun Итак, как же работает rsockstun?В основе работы RsocksTun (далее по тексту — rs) лежат два программных компонента — Yamux и Socks5 сервер. Socks5 сервер — это обычный локальный socks5, он запускается на клиенте. А мультиплексирование соединений к нему (помните про многопоточность?) обеспечивается с помощью yamux (). Такая схема позволяет запускать несколько клиентских socks5 серверов и распределять внешние подключения к ним, пробрасывая их через одно единственное TCP-соединение (почти как в meterpreter) от клиента к серверу, реализуя тем самым многопоточный режим, без которого нам просто не получится полноценно работать во внутренней сети.Суть работы yamux’а заключается в том, что он вводит дополнительный сетевой уровень стримов, реализуя его в виде 12-байтного заголовка для каждого пакета. (Здесь мы намеренно используем слово «стрим», а не поток, чтобы не путать читателя с программным потоком «thread» — это понятие мы так же будем использовать в данной статье). Внутри yamux заголовка содержатся номер стрима, флаги для установки/завершения стрима, количество передаваемых байт, размер окна передачи.Помимо установки/завершения стрима в yamux реализован механизм keepalive’ов, позволяющий отслеживать работоспособность установленного канала связи. Работа механизма keeplive-сообщений настраивается при создании Yamux-сессии. Собственно, из настроек там только — два параметра: enable/disable и периодичность отсылки пакетов в секундах. Keepalive-сообщения может отсылать yamux-сервер, так yamux-клиент. При получении keepalive-сообщения удаленная сторона обязана ответить на него посылкой точно такого же идентификатора сообщения (фактически — числа), который она приняла. В общем, keepalive — это тот же пинг, только для yamux.Подробно вся техника работы мультиплексора: типы пакетов, флаги установки и завершения соединений механизм передачи данных описана вк yamux.

Какие преимущества имеет PowerShell для создания обратного прокси-сервера Socks5

Вот так, тихо, без оваций и громких речей на Mikrotik завезли поддержку Socks5. Скромная строчка в релизе 6.47 - added support for SOCKS5 (RFC 1928) и ожидания пользователей mikrotik наконец то сбылись.

Краткая справка для тех кто не в теме:

SOCKS это разновидность прокси-сервера. Используется например для доступа к сайтам торрентов. В отличие от HTTP-прокси-серверов, SOCKS передаёт все данные от клиента, ничего не добавляя от себя, то есть с точки зрения конечного сервера, данные, полученные им от SOCKS-прокси, идентичны данным, которые клиент передал бы напрямую, без проксирования.

Отличие SOCKS 4 от SOCKS 5 состоит в том, что SOCKS 5 имеет поддержку сетевого протокола UDP, может работать в схемах со строгой аутентификацией, а также поддерживает сетевую адресацию IPv6 (которую планируют внедрить в будущем, так как современная IPv4 скоро исчерпает все свои возможности). SOCKS 5 дал возможность работы через прокси, даже тем программам, которые изначально не имели такой возможности.

Проще говоря соксы 5 продвинутей.

Настройка Socks5 сервера проста и не затейлива.

Порт я обычно меняю на не стандартный, чтобы хоть чуть-чуть снизить нагрузку от сканящих все подряд ботов. Выбираем версию протокола 5 и метод аутентификации по паролю:

Добавляем пользователя с паролем и на этом базовая настройка Socks5 сервера завершена.

Хотя я обычно добавляю еще ограничение на доступ по IP:

Остается добавить правило в файрволл:

ip firewall filter add chain=input protocol=tcp dst-port=7777 action=accept comment="SOCKS5 TCP"

add chain=input protocol=udp dst-port=7777 action=accept comment="SOCKS5 UDP"или в winbox

Для работы с проксей в хроме использую расширение Proxy Switcher, но он почему то не хочет использовать авторизацию.

Какие инструменты и технологии могут использоваться для создания обратного прокси-сервера Socks5 на PowerShell

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

Гугление в интернете (гуглим мы вроде нормально), а также поиск по гитхабу по ключевым словам «reverse socks» не дал особо много результатов. В основном, все сводится к построению ssh-туннелей с обратным пробросом портов и всего, что с этим связано. Помимо SSH-туннелей можно выделить несколько решений:

github.com/klsecservices/rpivot
Давняя реализация обратного туннеля от ребят из Лаборатории Касперского. По названию понятно, для чего предназначен этот скрипт. Реализован на Python 2.7, туннель работает в cleartext режиме (как модно сейчас говорить — привет РКН)

github.com/tonyseek/rsocks
Еще одна реализация на питоне, так же в cleartext, но возможностей больше. Написан в виде модуля и есть API для интеграции решения в свои проекты.

github.com/llkat/rsockstun
github.com/mis-team/rsockstun
Первая ссылка — изначальная версия реализации реверс сокса на голанге (не поддерживается разработчиком).
Вторая ссылка — уже наша доработка с дополнительными фишками, также на голанге. В нашей версии мы реализовали SSL, работу через прокси с NTLM-авторизацией, авторизацию на клиенте, лендинг-страницу при неверном пароле (вернее — редирект на лендинг-страницу), многопоточный режим (т.е. с туннелем могут работать несколько человек одновременно), систему пингов клиента на предмет того — живой он или нет.

github.com/jun7th/tsocks
Реализация обратного сокса от наших «китайских друзей» на питоне. Там же для ленивых и «бессмертных» лежит уже готовый бинарь (exe), собранный китайцами и готовый к использованию. Тут один только китайский бог знает, что в этом бинаре может быть еще, кроме основного функционала, так что используйте на свой страх и риск.

github.com/securesocketfunneling/ssf
Довольно-таки интересный проект на С++ для реализации обратного сокса и не только. Помимо обратного туннеля, он может делать проброс портов, создание командного шелла и т.д.

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

Все вышеописанные инструменты работают по схожей технологии: на машине внутри сети запускается заранее подготовленный исполняемый бинарный модуль, который устанавливает соединение с внешним сервером. На сервере запускается SOCKS4/5 сервер, принимающий подключения и транслирующий их на клиента.

Недостатком всех вышеперечисленных инструментов является то, что либо на клиентской машине необходим установленный Python или Golang (часто ли вы встречали установленный Python на машинах, к примеру, директора компании или офисных работников?), либо на эту машину необходимо тащить заранее собранный бинарь (фактически python и скрипт в одном флаконе) и запускать этот бинарь уже там. А загрузка exe с последующим его запуском — это еще та сигнатура для местного антивируса или HIPS.

В общем, вывод напрашивается сам собой — нам нужно решение на powershell. Сейчас в нас полетят помидоры — мол powershell — это уже все избито, он мониторится, блокируется и т.д. и т.п. На самом деле — далеко не везде. Ответственно заявляем. Кстати, существует уйма способов обойти блокировки (тут опять модная фраза про привет РКН ), начиная от тупого переименования powershell.exe -> cmdd.exe и заканчивая powerdll и т.п.

Как настроить сетевой трафик для работы с обратным прокси-сервером Socks5 на PowerShell

Прежде чем изобретать свой велосипед — необходимо сделать анализ существующих велосипедов и понять, действительно ли оно нам надо и, вероятно, не только мы задумались о необходимости такого функционального велосипеда.Гугление в интернете (гуглим мы вроде нормально), а также поиск по гитхабу по ключевым словам «reverse socks» не дал особо много результатов. В основном, все сводится к построению ssh-туннелей с обратным пробросом портов и всего, что с этим связано. Помимо SSH-туннелей можно выделить несколько решений:Давняя реализация обратного туннеля от ребят из Лаборатории Касперского. По названию понятно, для чего предназначен этот скрипт. Реализован на Python 2.7, туннель работает в cleartext режиме (как модно сейчас говорить — привет РКН)Еще одна реализация на питоне, так же в cleartext, но возможностей больше. Написан в виде модуля и есть API для интеграции решения в свои проекты.Первая ссылка — изначальная версия реализации реверс сокса на голанге (не поддерживается разработчиком).Вторая ссылка — уже наша доработка с дополнительными фишками, также на голанге. В нашей версии мы реализовали SSL, работу через прокси с NTLM-авторизацией, авторизацию на клиенте, лендинг-страницу при неверном пароле (вернее — редирект на лендинг-страницу), многопоточный режим (т.е. с туннелем могут работать несколько человек одновременно), систему пингов клиента на предмет того — живой он или нет.Реализация обратного сокса от наших «китайских друзей» на питоне. Там же для ленивых и «бессмертных» лежит уже готовый бинарь (exe), собранный китайцами и готовый к использованию. Тут один только китайский бог знает, что в этом бинаре может быть еще, кроме основного функционала, так что используйте на свой страх и риск.Довольно-таки интересный проект на С++ для реализации обратного сокса и не только. Помимо обратного туннеля, он может делать проброс портов, создание командного шелла и т.д. MSF meterpreter Тут как говорится, без комментариев. Все мало-мальски образованные хакеры прекрасно знакомы с этой штукой и понимают, насколько легко ее обнаруживают средства защиты.Все вышеописанные инструменты работают по схожей технологии: на машине внутри сети запускается заранее подготовленный исполняемый бинарный модуль, который устанавливает соединение с внешним сервером. На сервере запускается SOCKS4/5 сервер, принимающий подключения и транслирующий их на клиента.Недостатком всех вышеперечисленных инструментов является то, что либо на клиентской машине необходим установленный Python или Golang (часто ли вы встречали установленный Python на машинах, к примеру, директора компании или офисных работников?), либо на эту машину необходимо тащить заранее собранный бинарь (фактически python и скрипт в одном флаконе) и запускать этот бинарь уже там. А загрузка exe с последующим его запуском — это еще та сигнатура для местного антивируса или HIPS.В общем, вывод напрашивается сам собой — нам нужно решение на powershell. Сейчас в нас полетят помидоры — мол powershell — это уже все избито, он мониторится, блокируется и т.д. и т.п. На самом деле — далеко не везде. Ответственно заявляем. Кстати, существует уйма способов обойти блокировки (тут опять модная фраза про привет РКН :) ), начиная от тупого переименования powershell.exe -> cmdd.exe и заканчивая powerdll и т.п.