myDC.ru

Здравствуйте, гость ( Вход | Регистрация )

 
История благодарностей участнику Meloun. Спасибо сказали: 12
Дата поста: В теме: За сообщение: Спасибо сказали:
29.12.2012, 0:56 Вроде всё настроил, а ничего не качает.
Интересные наблюдения.
Приветствую Друзья.

Решил я тут исследовать трафик NMDC на предмет корректности команд от клиентов, подправил код парсера, включил логгирование команд отличающихся от "ГОСТов" и умилению моему не было предела когда через несколько дней логи были конкретно забиты гумном.

И так, встречайте лидера корявости - команда запроса подключения $ConnectToMe. Как только её не сношали.
Самые популярные корявости:

1. Пустое значение или пробел вместо номера порта
$ConnectToMe [bot]ШтирлиЦ 128.72.xx.xxx: |
И куда изволите подключаться?? Ментально иллементально?)) Странно что клиент вообще такое не проверяет при вводе настроек.

2. Пробел или несколько пробелов после IP адреса или перед(после) номером порта
$ConnectToMe [bot]ШтирлиЦ 176.15.xx.xxx :333|
$ConnectToMe [bot]ШтирлиЦ 2.156.xxx.xxx: 43020|
Тут в общем всё не так плачевно, но зависит от парсера клиента которому отправляют команду. Намекаю на то, что так лучше не делать.

3. Стабильно встречающийся верх тупости, вместо IP-адреса клиента URL-адрес хаба))
$ConnectToMe [bot]ШтирлиЦ dchub://dc.sungate.su:411|
Я могу понять если вместо IP попробовать впихнуть доменное имя, авось удаленный клиент делает ДНС преобразование адреса. Могу понять кулхацкеров которым хотца проверить хаб на уязвимости. Но блин, нахрена в поле куда заносится IP-адрес ВАШЕГО клиента вписывать адрес хаба, да ещё в URL формате????

Резюмируя вышенаписанное.

1. Всегда указывайте IP и номера портов UDP и TCP если настраиваете клиента для работы через роутер или брандмауэр, либо включайте UPnP дабы умная техника сама всё настроила.

2. Проверяйте чтобы до и после вводимых адресов и номеров портов не было пробелов, иначе придётся потом долго голову ломать отчего не работает активный режим, чего_я_делаю_не_так.

3. AAGGGRRRHHHH!!!!!!!! Ну вы поняли...


Как-то так.
Delia
11.1.2012, 21:07 Поддержка NAT Traversal хабом
Организация файлообмена между пассив. пользователями средствами хаба
Кодом поделиться несмогу т.к. этот функционал вшит в хаб, а хаб самописный. Опишу вербальный алгоритм.

Клиент подключается к хабу.

Если в тэге клиента стоит флаг активного режима, то от имени бота хаба (бот должен быть виден всем пользователям, т.е. хаб должен рассылать всем клиентам MyINFO с именем бота как если бы это был обычный пользователь) отсылается команда $ RevConnectToMe ИмяБота ИмяПользователя|

Если от клиента приходит $ConnectToMe ИмяБота IP:port| то сканируем на предмет открытия порта у клиента. Если открыт - активный режим настроен верно, если нет, то сообщаем клиенту что актив настроен не верно.


Я вообще сделал так , что если хаб определяет что у клиента неверно настроен активный режим, то средствами хаба меняются команды присылаемые клиентом пользователя. Поисковые запросы преобразуются в пассивные, $ConnectToMe превращается в $RevConnectToMe.

Грабли на которые можно наступить и которые следует предусмотреть:
-хаб должен игнорировать команды $ConnectToMe если оба клиента в пассивном режиме (в т.ч. и те пользователи у которых хаб определил неверно настроеный активный режим), иначе будет зацикливание (будут пинаться друг-другу запросы на подключения до бесконечности)
-всегда пропускать команду $ConnectToMe без изменений даже если она идет от пассива к пассиву, если она иммет формат NAT-Traversal (флаги N или R в номере порта) дабы дать возможность двум пассивам попробовать соединиться (см. расширение NAT-Traversal).
-хаб должен игнорировать команду $RevConnectToMe, если она от активного пользователя (в этом случае активными считаются и те у которых хаб определил что актив настроен неверно) и адресована пассивному (включая активных у кого хаб определил неверно настроенный актив), дабы также исключить возможность зацикливания.
- всегда пропускать команду $RevConnectToMe если она от пассивного клиента и адресована пассивному (в данном случае пассивными не будут считаться те, у кого хаб определил неверно настроеный активный режим) дабы дать возможность двум пассивам попробовать соединиться (см. NAT-Traversal)


Надеюсь более-менее понятно расписал.

Для наглядности, так сказать чтобы пощупать руками, включайте фаервол, указывайте в клиенте актив, открывайте окно CDM-отладчика в клиенте и коннектесь по адресу dc.sungate.su Лучше один раз увидеть...
Enyby
5.1.2012, 6:59 NMDC Extensions
Расширения и новые команды NMDC протокола
Расширение: FailOver

Тип взаимодействия: Хаб-Клиент
Хабы поддерживающие расширение: FLEXHUB.
Клиенты поддерживающие расширение: ?? неизвестно.

Назначение: организация и изменение списка альтернативных адресов в клиенте для хаба.

Описание:
Алгоритм основан на FO extension из ADC протокола, и является реализацией для NMDC.

Данное расширение обеспечивает поддержку клиентом нескольких альтернативных адресов для хаба (могут быть как адреса этого же хаба, так и других хабов), к которым клиент будет подключаться в случаях недоступности основного адреса.
В случае подключения к альтернативному адресу по причине недоступности основоного, клиент периодически проверяет доступность основного и в случае возобновления работы либо переключается обратно, либо выполняет другое действие указанное в настройках клиента.

Синтаксис команды:

Код
$FailOver <address1[:port]>,<address2[:port]>|


Последовательность команд:
Код
Client:        $Supports ... FailOver|
Hub:    $Supports ... FailOver|
Hub:    $FailOver someaddress.no-ip.org,adc://someotheraddress.com:5432|


Команда $FailOver может отправляться клиентам в любое время, но только после отсылки хабом команды характеристик $Supports и только тем клиентам которые поддерживают это расширение. Повторная отправка команды $FailOver перезаписывает (а не добавляет к уже существующим прим. переводчика) альтернативные адреса хаба в клиенте. Оправка пустой команды $FailOver| удаляет все альтернативные адреса (остаётся только основной прим. переводчика), клиент будет ждать когда основной адрес станет доступным.

Источник: http://www.flexhub.org/forum/index.php?topic=184.0




Расширение: $Lock

Тип взаимодействия: Клиент-Клиент
Хабы поддерживающие расширение: поддержка со стороны хаба не требуется.
Клиенты поддерживающие расширение: StrongDC 2.4 и выше, а также клиенты на нем базирующиеся..

Назначение: расширение команды $Lock отсылаемой клиенту.

Описание:
данное расширение команды $Lock используется при инициалиации соединения между клиентами, т.е. после отправки через хаб команды $ConnectToMe. Команда имеет вид:

Код
$Lock EXTENDEDPROTOCOLABCABCABCABCABCABC Pk=DCPLUSPLUS0.785Ref=dc.example.com:port


как видно синтаксис идентичен старой версии команды, но в самом конце добавилась строка Ref=dc.domain.com:port причём без разделительного пробела, для совместимости сос тарыми клиентами. Данный параметр показывает на то с какого хаба клиентом была получена команда $ConnectToMe для инициализации соединения.

Для чего эту фичу добавили в стронг неизвестно, в вопросах файлообмена она абсолютно не нужна, но вот для владельцев хабов да и не только может быть очень полезной. В случае DDoS атаки CTM вам на блюдечке с каёмочкой клиенты будут слать адрес хаба с которого этот ддос устроили ;)


PomanoB, Alexey, Saymon21, Enyby
4.1.2012, 19:46 NMDC Extensions
Расширения и новые команды NMDC протокола
Доброго времени суток друзья. Предлагаю вашему вниманию информацию по новым расширениям и дополнительным командам Neo Modus Direct Connect протокола, которые нарыл в интернетах. NMDC как бы и не собирается помирать big_smile.gif



Расширение: TLS Шифрование

Тип взаимодействия: Клиент-Клиент
Хабы поддерживающие расширение: поддержка со стороны хаба не требуется.
Клиенты поддерживающие расширение: StrongDC++ 2.2 и выше, а также клиенты на нем базирующиеся.

Назначение: Шифрование трафика между клиентами (защищенная передача файлов).

Описание: Клиенты поддерживающие это расширение выставляют флаг 0x10 в передаваемой хабу команде $MyINFO. Клиент который хочет инициировать файлообмен и также поддерживающий это расширение отсылает команду $ConnectToMe, но добавляет в самый конец (приписывает к номеру порта) символ "S". Наличие этого символа приписанного к номеру порта говорит о том, что клиент хочет инициировать TLS-соединение и начать защищенное скачивание файла. Номер порта для TLS соединений указывается отдельно в настройках клиента.

Код
$ConnectToMe user1 IP:portS|


Источник: http://strongdc.sourceforge.net/forum/view...f=11&t=5528



Расширение: NAT Traversal

Тип взаимодействия: Клиент-Клиент
Хабы поддерживающие расширение: поддержка со стороны хаба не требуется.
Клиенты поддерживающие расширение: StrongDC++ 2.40 и выше, а также клиенты на нем базирующиеся.

Назначение: Возможность передавать файлы между двумя пассивными клиентами за NAT.

Описание:
Клиенты поддерживающие это расширение выставляют флаг 0x20 в передаваемой хабу команде $MyINFO. Пассивный клиент "A" который хочет инициировать файлообмен с удаленным клиентом "B" отсылает стандартную команду $RevConnectToMe. Если удаленный клиент "B" также в пассивном режиме и поддерживает это расширение, то в ответ передает коменду $ConnectToMe вида:

Код
$ConnectToMe <A's nick> <B's IP>:<port>N <B's nick>|


где <port> это номер локального порта с которого клиент "B" подключен к хабу (outbond port, см. спецификацию сокетов). Как видно к номеру порта добавляется символ "N" ("NS" в случае TLS соединения). Когда клиент "A" получает эту команду, то пытается подключиться к указанному IP:port и одновременно отсылает обратно команду:

Код
$ConnectToMe <B's nick> <A's IP>:<port>R|


где <port> это также номер локального порта с которого уже клиент "A" подключен к хабу. Теперь к номеру порта добавляется символ "R" ("RS" в случае TLS соединения). Когда клиент "B" получает эту команду, то сразу пытается подключиться к указанному IP:port.

Данные манипуляции позволяют обойти ограничения NAT и организовать "туннель". Очень красивое и оригинальное решение (прим. переводчика).

Источник: http://strongdc.sourceforge.net/forum/view...f=11&t=6001




Расширение: Locale

Тип взаимодействия: Клиент-Хаб, Хаб-Клиент
Хабы поддерживающие расширение: FLEXHUB.
Клиенты поддерживающие расширение: ?? неизвестно.

Назначение: Согласование кодировки и других региональных настроек между клиентом и хабом.

Описание:

последовательность команд (C-клиент, H-хаб):

Код
C: $Supports Locale|
H: $Supports Locale|
H: $Locale CSwindows-1251 DILR DA"<string>" TI"<string>"|


Следующие поля могут быть использованы, но могут и не указываться (автор придерживается стиля команд ADC протокола):

CS = кодировка
DI = направление написания текста, LR = слева-на-право, RL = справа-на-лево
DA=формат даты
TI=формат времени

Другие поля могут добавляться при необходимости.

Источник: http://www.flexhub.org/forum/index.php?topic=312.0





Расширение: SaltPass

Тип взаимодействия: Клиент-Хаб, Хаб-Клиент
Хабы поддерживающие расширение: FLEXHUB.
Клиенты поддерживающие расширение: DiCe!++, ?? неизвестно.

Назначение: безопасная валидация по паролю при входе на хаб.

Описание:

Безопасная передача запроса пароля в виде "соли" и самого пароля в виде хэша как производную от пароля и "соли".
Алгоритм вычисления "соли" и хэша аналогичен протоколу ADC. Хаб передаёт "соль" клиенту с помощью команды $GetPass, клиент добавляет "соль" к паролю и вычисляет хэш, который конвертируется в base32 текстовый формат и отсылается клиентом хабу с помощью команды $MyPass.

Последовательность команд:
Код
C: $Supports SaltPass
H: $Supports SaltPass
C: $ValidateNick <nick>
H: $GetPass <salt>
C: $MyPass <salted pass>


Источник: http://www.flexhub.org/forum/index.php?topic=311.0
mariner, PomanoB, Alexey, Saymon21, Enyby

RSS Сейчас: 26.4.2024, 8:55