Здравствуйте, гость ( Вход | Регистрация )
Дата поста: | В теме: | За сообщение: | Спасибо сказали: | ||
---|---|---|---|---|---|
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. Клиенты поддерживающие расширение: ?? неизвестно. Назначение: организация и изменение списка альтернативных адресов в клиенте для хаба. Описание: Алгоритм основан на Данное расширение обеспечивает поддержку клиентом нескольких альтернативных адресов для хаба (могут быть как адреса этого же хаба, так и других хабов), к которым клиент будет подключаться в случаях недоступности основного адреса. В случае подключения к альтернативному адресу по причине недоступности основоного, клиент периодически проверяет доступность основного и в случае возобновления работы либо переключается обратно, либо выполняет другое действие указанное в настройках клиента. Синтаксис команды: Код $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| удаляет все альтернативные адреса (остаётся только основной прим. переводчика), клиент будет ждать когда основной адрес станет доступным. Источник: Расширение: $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 как бы и не собирается помирать Расширение: Тип взаимодействия: Клиент-Клиент Хабы поддерживающие расширение: поддержка со стороны хаба не требуется. Клиенты поддерживающие расширение: StrongDC++ 2.2 и выше, а также клиенты на нем базирующиеся. Назначение: Шифрование трафика между клиентами (защищенная передача файлов). Описание: Клиенты поддерживающие это расширение выставляют флаг 0x10 в передаваемой хабу команде $MyINFO. Клиент который хочет инициировать файлообмен и также поддерживающий это расширение отсылает команду $ConnectToMe, но добавляет в самый конец (приписывает к номеру порта) символ "S". Наличие этого символа приписанного к номеру порта говорит о том, что клиент хочет инициировать TLS-соединение и начать защищенное скачивание файла. Номер порта для TLS соединений указывается отдельно в настройках клиента. Код $ConnectToMe user1 IP:portS| Источник: Расширение: Тип взаимодействия: Клиент-Клиент Хабы поддерживающие расширение: поддержка со стороны хаба не требуется. Клиенты поддерживающие расширение: 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 и организовать "туннель". Очень красивое и оригинальное решение (прим. переводчика). Источник: Расширение: 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=формат времени Другие поля могут добавляться при необходимости. Источник: Расширение: SaltPass Тип взаимодействия: Клиент-Хаб, Хаб-Клиент Хабы поддерживающие расширение: FLEXHUB. Клиенты поддерживающие расширение: DiCe!++, ?? неизвестно. Назначение: безопасная валидация по паролю при входе на хаб. Описание: Безопасная передача запроса пароля в виде "соли" и самого пароля в виде хэша как производную от пароля и "соли". Алгоритм вычисления "соли" и хэша аналогичен протоколу ADC. Хаб передаёт "соль" клиенту с помощью команды $GetPass, клиент добавляет "соль" к паролю и вычисляет хэш, который конвертируется в base32 текстовый формат и отсылается клиентом хабу с помощью команды $MyPass. Последовательность команд: Код C: $Supports SaltPass H: $Supports SaltPass C: $ValidateNick <nick> H: $GetPass <salt> C: $MyPass <salted pass> Источник: |
mariner, PomanoB, Alexey, Saymon21, Enyby | ||
|
Сейчас: 23.11.2024, 1:17 |