[ОТВЕТИТЬ]
13.10.2015 14:37
aldemko
 
Всем привет
столкнулся с интересным случаем RDP толи обманки толи защиты.
и так в кратце.
есть сервер есть клиент - я к ним не имею никакого отношения я пк3.
сервер находится в городе А
клиент находится в городе Б
я нахожусь в городе В.
И так предположительно Сервер находится
Скрытый текст (вы должны войти под своим логином или зарегистрироваться и иметь 21 сообщение(ий)):
У вас нет прав чтобы видеть скрытый текст, содержащийся здесь.
на котором включен ф.волл (скорее всего не стандартной прошивки, но не факт) стандартный порт RDP закрыт.
на Сервере Win 2008 R2 - инфа 100%
Сканер портов говорит иди в лес - мол фильтрация и ничего не скажем, но умные программы все таки указали мне порт RDP.
Клиент - находясь в городе Б спокойно подключается к Серверу А.
При моей попытке подключения к RDP - мне выдает ошибку (0x1104) - мол проблема в клиентском RDP. не вопрос, имея достаточно ресурсов, я установил абсолютно разные OS с разными RDP клиентом. в любом случае после пары попыток подобных, порт закрывался (мне пишет что сервер выключен и так далее) и автоматом менялся на другой, при этом Клиент А - в настройках ничего не изменяет и подключается как подключался (но тем не менее он уже подключается на совершенно другой порт).
Но я снова нахожу порт на котором висит RDP сервер, точнее то что прослушивается на точке входа.
Опять пара попыток, ошибка 0x1104 и смена порта
Опять смена на сервере и на клиенте.
Вопрос как подобное можно реализовать.
Прошу прощения если не ясно выразился, спрашивайте буду приводить более конкретные данные - по крайней мере те которыми обладаю
13.10.2015 15:44
OlegON
 
В винде не силен, но в RDP несколько протоколов авторизации, как внутренний RDP, так и сертификатный и с внешней авторизацией. Причем, часть клиентов, как минимум, не будет пытаться перебирать их последовательно. Ставим в первый по умолчанию разрыв с записью в журнале и анализатором журнала выполняем необходимые действия. Только вот как сменить порт без прокси я что-то не соображу...

Ты уверен, что тот, что постоянно подключается без проблем, подключается напрямую? Не в одном ли они домене?
13.10.2015 16:24
aldemko
 
Олег приветствую.
да ты прав насчет авторизации и прочего
здесь ситуация интересней - и мне хочется ее разгадать
суть примерно такова
Сервер имеет IP 1.1.1.1 порт не известен - 99.9% фильтруются, на сканирование всего диапазона уходит около 2 суток - не вариант
Клиент имеет IP 2.2.2.2 порт на снифе.
картина такова
клиент с исходящими данными к примеру 2.2.2.2:123 конектится к 1.1.1.1:321 - соединение успешно
Я , конекчусь к 1.1.1.1:321 ошибка 0x1104 - я пробую разные версии RDP - в итоге получаю сообщение что по данному адресу мол сервер или не доступен или вообще не существует
ловлю пакеты клиента, вижу картину
2.2.2.2:313 конектится к 1.1.1.1:444 - соединение успешно.
пытаюсь опять же со своего пк подключится к 1.1.1.1:444 - ошибка та же, пара попыток, и сервера не сущестует
снифер опять ловит
2.2.2.2:432 конектится к 1.1.1.1:353
и так в не понятном мне алгоритме
Информация о сервере то что там win 2008 на входе Tplink
клиент Win 7
Достоверно известно что во внутренней сети 1.1.1.1 в настройках RDP ничего не менялось
в другом городе где обитает 2.2.2.2 не известно - но известно что периодически RDP порт меняется, и порт исходящего запроса к RDP тоже, как. загадка
13.10.2015 16:32
Dim
 
надо спросить у mamont'a )
13.10.2015 16:47
OlegON
 
Во-первых, если сканишь чем-то вроде nmap, то там несколько типов сканирования, отличающихся скоростью, и весь диапазон (до 65535 чтоль?!) сканить не надо. Надо пробовать не разные версии RDP, а разную авторизацию.
Цитата:
2.2.2.2:313 конектится к 1.1.1.1:444
тут интересна только 444, т.е. порт на сервере. TPLink, я думаю, тут не при чем. Попробуй на клиенте 2222 проснифать, куда он пытается подключиться на старте и посмотри параметры его подключения. Скорее всего, речь идет о прокси, т.е. между 2222 и 1111 кто-то есть еще, кто рулит соединением. Можешь netstat -an сделать, посмотреть, куда еще соединения установлены. Как вариант - посмотри, что 2222 не лезет в консоль, а ты - в TCP-сессию.
13.10.2015 17:00
aldemko
 
по правде говоря клиента я ничем не сканирую
при помощи Linux я по адресу узнал железо и прошивку и шелл к ней, соответственно данные клиента брались тупо с активных соединений роутера D-link 815 - это клиентский роутер. там показывается исходящий канал и куда направляетя - сначала я думал что исходящий порт один и тот же, но он меняется так же как и порт назначения, причем в сплошном рандоме
13.10.2015 17:05
OlegON
 
Если честно, я думал, что 2222 - это один из твоих компов. Сниф ловится достаточно легко, если это не просмотр соединений на рутере. Смотри, можно сильно налететь и по шапке получить. Отмазываться и потом лечить, что ты только посмотреть хотел... Шелл - это уже неправомерный доступ к информации. Даже если условно дадут - это судимость, а судимость ты засветишь в очень многих анкетах, после чего тебя куда-то не пустят или не возьмут, а там еще и на рецедивиста могут стащить. Мой тебе совет - работать только с добровольно открытыми ресурсами и по письменному согласию лично знакомого тебе человека.
13.10.2015 17:17
aldemko
 
тут я с тобой согласен- мне эти данные вообще не нужны
но как они меняют данные в автомате - при этом не меняя физически адреса в RDP клиенте - вот что мне интересно
13.10.2015 17:27
OlegON
 
Фантастики не бывает, кто-то третий в цепочке сообщает параметры подключения, либо ты что-то не видишь или видишь не так.

Смысла в такой свистопляске особого не вижу, достаточно унести порт куда-то, настроить бан за попытку подключения на штатный порт, несколько других рандомно и перебор паролей.
13.10.2015 17:31
aldemko
 
Бан по IP который меняется - а здесь, более интересная схема, на перебор все портов уходит минимум 18 часов - а сменить IP 2 минуты, вот почему я так заинтересовался. Но видимо пока не будет новых данных о вероятной третьей стороне - возможно VPN тунель то тайна будет не раскрыта
Но если даже VPN тунель то если бы внутренний порт оставался прежний а внешний менялся тут пол беды, и тот и тот меняется(
13.10.2015 17:42
OlegON
 
при чем тут VPN, если ты видишь подключение напрямую на 1111?
У тебя IP не хватит, чтобы все баны собрать, а потом еще и за пароль надо будет собирать... С помощью какого-то TARGET в iptables можно сделать так, чтобы все порты выглядели открытыми или так (TARPIT), что соединение просто так не закроется, сканить забодаешься... Иными словами, много способов устроить несладкую жизнь, если сильно заморочиться.
13.10.2015 18:11
aldemko
 
я с тобой не могу спорить по поводу твоих навыков
но на входе стоит не прошитый TP-link
да и я вижу подключения на прямую - точнее почти на прямую
не пойму что заставляет клиента RDP обращаться на 111 порт на свой роутер, него уже выходит на 222
или выход 333 а на роутер уходит 444 - при этом в клиентском роутере пробросов нет - а если бы и были то не видел я Dir 815 который динамично пробрасывает порты
не могу понять кто может быть третьим - кто выдает параметры
13.10.2015 19:30
OlegON
 
вот, например... Как я уже говорил, рутеры тут не при чем, скорее всего. Но, подождем спецов по винде, я могу теперь чего-нибудь и не знать.
14.10.2015 09:36
aldemko
 
как я понял
Клиент отправляет запрос на постоянный порт сервера (к примеру :1111) - который (возможно) конкретно этому открывает порт допустим :4444.
при этом в логах я вижу, что клиент подключается по :4444 порту, а когда я пытаюсь подключиться по этому же порту - сервер видит что мне данный порт не выдавался и посылает меня - при этом закрывая данный порт.
Следовательно нужно искать не :4444 порт, а тот на который изначально отправляется запрос ?!
14.10.2015 09:52
akonev
 
Цитата:
aldemko ...Следовательно нужно искать не :4444 порт, а тот на который изначально отправляется запрос ?!
Олег тебе давно уже про это говорит
Цитата:
OlegON ... Попробуй на клиенте 2222 проснифать, куда он пытается подключиться на старте и посмотри параметры его подключения. Скорее всего, речь идет о прокси, т.е. между 2222 и 1111 кто-то есть еще, кто рулит соединением. Можешь netstat -an сделать, посмотреть, куда еще соединения установлены...
14.10.2015 09:59
aldemko
 
я пока веду статистику исходящих от клиента запросов.
дело в том что по такому сценарию, у клиента исходящий порт должен быть всегда один и тот-же , по которому от отправляет запрос, а в ответ уже получает определенный порт.
Но клиент то с порта 1111 ломится на порт 4444 то с порта 333 на 222 в общем пока закономерности не нашел, или вылавливаются не те запросы, или не в том колве.
в общем направление понял - буду ждать, записывать и вести статистику, потом попробую отобрать одинаковые порты, и отсылать авторизацию на них - возможно найдется именно тот порт
14.10.2015 10:06
OlegON
 
ты же не снифаешь, а просто смотришь установленные соединения?
14.10.2015 10:30
aldemko
 
да просто установленные соединения.
в разделе активные соединения.
исходящий IP:порт удаленный IP:порт
исходящие порты всегда разные как и удаленные для RDP
если SSL запрос идет на удаленный сервер, роутер порт покажет ? или ....
14.10.2015 10:49
OlegON
 
Если пара пакетов пролетит, ты и ухом не моргнешь... это снифферить надо.
Кроме того, там и UDP может быть.
15.10.2015 10:02
mamont
 
вопрос конечно интересный...
пока есть несколько предположений которые не могут все объяснить: роутер за которым находится сервер поддерживает UPnP и сервер может попросить открыть и пробросить тот или иной порт. Но так как порт всегда разный, то видимо есть какая то третья сторона которая позволяет договориться о том какой порт будет использоваться.(rdp web-gate ?)
вопросы:
какие еще открытые порты обнаружены на роутере за которым прячется сервер?
есть ли среди них те которые не меняются?
какие еще соединения от клиента видно в процессе подключения?
27.10.2015 06:05
aldemko
 
Пока жду, подключений новых не было, по выписываю все исходящие порты и входящие - но тишина пока что
Опции темы


Часовой пояс GMT +3, время: 22:55.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.