Кто знает причину - почему такое происходит?
клиенты имеют глюк и генерят левые запросы?
также странно что в пассивном режиме хаб их успешно рассылает
или этот запрос валидный?
Добавлено: 22 апр 2014, 18:14
HackFresse
были бы полезными куски RAW-сообщений от хаба без изменений, просто текст, пришедший из сокета, а там будет видно, нужно ли дёргать резольвер и парсить урлы какие-то
Если пользователь в пассиве, то ответ на его поиск слать больше некуда, кроме как в сокет хаба, приславшего сообщение (никаких udp-сокетов).
Моё мнение на счет резольвера (зачем его вставили) -- продолжение темы http://dchublist.ru/forum/viewtopic.php?p=22584#p22584 , т.е. вместо принятого по стандарту IP внезапно может приходить имя, а для отсылки UDP-пакета обязательно (?) нужно использовать исключительно IP (результат работы резольвера). Где-то в одном месте допустили имена вместо адресов, в другом пришлось дополнительно заниматься вынужденным преобразованием. Или просто "пускай будет лишний раз"
Добавлено: 22 апр 2014, 18:21
flylinkdc
Строка поиска имеет вот такой вид
109.165.8.156:2008 F?T?0?1?
или
Hub:GreiderwQQQee3eet F?T?0?1?
Собственно с этого и вопрос - кто генерит такие строки поиска.
раз они скипаются всеми клиентами
1) За одну секунду прилетает сразу пачка запросов с разных хабов.
2) Крайне маловероятно, чтобы это был какой-то скрипт антипорно.
Потому как:
2.1) договориться сделать что-то совместными усилиями админы не могут
2.2) найти/сделать/запустить систему, одновременно работающую на нескольких хабах, могут единицы "специалистов по дц"
2.3) смысла запускать систему антипорно на куче разношерстных хабов нету. "На всех хабах, где я могу банить, порно не пройдёт" еще можно как-то понять, но "на первых попавшихся" - маловероятно.
Наполнять какую-то базу прямыми поисковыми запросами на куче хабов -- да, реально (сам так делал), но использовать потом полученные результаты для фильтрации порнухи на каком-то своем хабе... вероятность такого использования крайне мала
3) Глядя на список хабов, замечаю, что Atlant75 из Украины, GreiderwQQQee3eet сидит на хабах Румынии и России, у 109.165.8.156 набор хабов тоже довольно уникальный.
Т.е. группировка хабов по юзерам довольно "реалистичная", разные юзеры сидят на разных хабах.
Если бы кусок лога был больше, можно было бы по IP-адресам сделать вывод, как они разбросаны по территориям и провайдерам
4) Хабы по большей части очень небольшие, а небольшие хабы редко отключают передачу тегов
А теги нужно сначала увидеть, вдруг там FlylinkDC_r369_beta82_build_2287
Добавлено: 23 апр 2014, 00:06
Kimbo
flylinkdc писал(а):т.е. он режет запрещенные названия а не сам запрос?
т.е он, скрипт на хабе, сам ищет по ТТН запрещённое и банит юзера.
Добавлено: 23 апр 2014, 00:11
Kimbo
HackFresse писал(а):2) Крайне маловероятно, чтобы это был какой-то скрипт антипорно.
за этот хаб я могу только ответить, за остальные нет.
На данном хабе стоит скрипт антипорно FileSearch_1.0j_LUA_5.11__RusHub_.lua
Кстати, большая часть хабов на верли хаб-софт стоит, а crysis.myhub.pp.ua:666 на RusHub (основанном на верли), возможно это в самом софт-хабе что-то?
Добавлено: 23 апр 2014, 00:16
flylinkdc
HackFresse писал(а):А теги нужно сначала увидеть, вдруг там FlylinkDC_r369_beta82_build_2287
уф! r369 это какой год то был ?
завтра подниму из svn - историю фиксов.
чую ты намекаешь, что я где-то в этом районе облажался и воткнул в клиент багу?
Добавлено: 23 апр 2014, 00:52
HackFresse
Я же написал "А теги нужно сначала увидеть, вдруг там" и рандомный вариант тега предложил..
Но какая разница, если там что-то специфическое (типа чьих-то ботов или скриптов), или старое (неудачная древняя версия всё равно какого клиента)?
Инвалидные запросы всё равно игнорить нужно, а если явление не носит массовый характер, то и заморачиваться особо не стоит
Добавлено: 23 апр 2014, 01:06
flylinkdc
HackFresse писал(а):Инвалидные запросы всё равно игнорить нужно, а если явление не носит массовый характер, то и заморачиваться особо не стоит
они всегда и сейчас игнорятся.
я просто решил это скидывать в лог на бетках
чтобы админам показали что с их хаба идет мусор в некоторых случаях.
Добавлено: 23 апр 2014, 13:19
HackFresse
а админы такие "ну и что мне с этим делать? пускай разработчики клиентов/хабсофта этим занимаются. а я ничего делать не умею/не знаю/не буду ".
И формат лога непонятный, чтобы какие-то выводы админы (или кого там это может заинтересовать) могли сделать
Лично мне нужно увидеть, как именно пришла подозрительная команда в общем потоке текстовых команд изначально, а не то, как она была записана после каких-то непонятных преобразований.
т.е. кусок простого текста, полученного из сокета хаба, без обработки вообще или с добавлениями дополнительных пояснений (вроде метки времени и направления передачи вместо стандартного разделителя команд)
Такой полный лог вы можете видеть в отладчике CMD
я добавив логирование случаев когда происходит ошибка именно в парсинге команды $Search
и нет никакого преобразования если откусить пояснения то сырая команда выглядит так:
Выловить в CDM-отладчике такой запрос среди других, когда с кучи хабов этих поисковых запросов больше десятка в секунду прилетает, тот еще мазохизм.. А вот после неспешного рассмотрения готовых лог-файлов можно и придумать что-то. или сказать "и так сойдёт"
На их теги посмотреть получилось, по айпи вычислить? Там же в sqlite-базу что-то активно пишется по всем юзерам, вдруг эти записи полезными окажутся?
Добавлено: 23 апр 2014, 23:09
flylinkdc
А параметр поиска разве можно переносить на другую строку после термитора'|' ?
Добавлено: 24 апр 2014, 10:26
HackFresse
ну так в том-то и весь смысл данной темы, что кто-то неправильно формирует поисковый запрос. или нет?