PythonJ
Newbie | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Нужно получить доступ к MSSQL-серверу, который фильтрует входящие подключения по IP.
Никаких ограничений по пакетам или портам в сети нет, но нужно "обмануть" сам сервер.
Причем авторизация используется только NT. а домены разные, но этот момент решаем.
Условно, в локальной сети имеется 2 домена и 3 машины:
LOCAL\WORK - Win7Pro
REMOTE\MSSQL - Win2k16
REMOTE\RDP - Win2k16
LOCAL\WORK
Машина разработчика с полными административными правами.
REMOTE\RDP
Терминальный сервер. У разработчика есть учетная запись в домене REMOTE и, соответственно доступ к RDP серверу. Есть права на копирование и запуск любых программ, но нет административных прав, соответственно включить прослушивание порта не удастся.
REMOTE\MSSQL
Сервер MSSQL, открыт порт 1433, но средствами самого сервера настроена фильтрация по IP.
Подключения принимает только с терминального сервера REMOTE\RDP. Авторизация только NT, то есть по пользователю в домене REMOTE
Доступа к REMOTE\MSSQL нет никакого.
Задача - подключиться к MSSQL c компьютера разработчика.
Пинги ходят любые, никаких ограничений нет. Порт MSSQL:1433 с машины WORK виден, но подключения не принимает. Раньше, когда не было ограничения по IP, можно было запустить приложение на машине разработчика с помощью RUNAS /netonly и указанием учетной записи в домене REMOTE. Тогда приложение подключаясь к MSSQL:1433 проходило авторизацию NT по учетной записи и получало доступ к серверу. Теперь не получается.
Как пробросить порт с RDP на WORK таким образом, чтобы MSQQL считал, что подключается сервер RDP?
Пробовалось:
Поднять на WORK сервер SSH, потом запустить сеанс RDP и на RDP сервере поднять обратный SSH-туннель до WORK, то есть:
открывается порт WORK:1433, прокидывается туннелем до RDP, а там перенаправляется на MSSQL:1433.
WORK:1433 при этом действительно открывается и netcat-ом видно на нем характерный ответ MSSQL, но поведение при этом такое же, как если стукнуться сразу на MSSQL:1433, так как SSH-туннель не меняет IP и предназначен, чтобы установить соединение поверх фаерволла, а не подменять IP-адрес.
С помощью NETCAT тоже ничего не получилось сделать. Он тоже может перенаправлять поток, но никак не менять IP.
Поднять прокси на RDP-сервере невозможно, поскольку там нет административных прав и оттуда можно только подключаться к другим портам, но никак не слушать их. Запустить NAT там тоже не выйдет по этой же причине.
Чисто теоретически можно себе представить такую схему:
1. На WORK запускается который, который слушает два порта, к примеру 1433 и 1434. При соединении на обоих портах перенаправляет данные с одного на другой и обратно.
2. На RDP запускаем некое подобие прокси, который подключается к WORK:1434 и MSSQL:1433 и соответственно тоже перекидывает пакеты между ними, но уже с подменой IP.
Если второе можно себе представить, хотя я не знаю чем это можно сделать, то первое вообще непонятно как и чем реализовать.
Кто как думает, возможно ли такое в принципе и если да, то хотя бы с помощью чего. Теоретически я себе представляю, как это можно написать самому, но квалификации у меня не хватит. Предполагаю, что задача настолько специфична, что готовых инструментов действительно нет в природе.
P.S. Месье знает толк в извращениях. |
тупо алгоритм жизни.