[ОТВЕТИТЬ]
Опции темы
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 ?)
вопросы:
какие еще открытые порты обнаружены на роутере за которым прячется сервер?
есть ли среди них те которые не меняются?
какие еще соединения от клиента видно в процессе подключения?
 
 


Опции темы



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

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