@Alex84 said in MultiBot-HTTP. Многопоточный Бот на запросах для сбора награды.:
Саму рентабельность забыли указать.
Сколь на Капчу ушло и тп :)
Так можно же посчитать. 1 клайм - 6 копеек. 1 капча -от 0.5 до 1 копейки.
HTTP/3 Работает :D
Moved
Other
-
@sergerdn said in HTTP/3 Работает :D:
@FastSpace said in HTTP/3 Работает :D:
ну да понимаю, продавцам тяжелее будет, нежели чем для себя поднять. Сначала надо проверить конечный ПК юзера, есть ли у него белый ip или нет. В зависимости от этого пойдут 2 ветки логики )) Потом еще гемор с подсчетом соединений )) в TCP это легко, по кол-ву соединений, а в UDP пинг нолевой всегда и соединения мгновенные, а то как ограничивать всех то )
Не будут ничего продавцы прокси ничего делать. Даже пытаться не будут, так как слишком сложно.
У поставщиков софта для DPI(Deep Packet Inspection) есть простое решение проблемы - просто блокировать этот протокол, так как у них нет решения по анализу пакетов и, когда будет, никто не говорит.Хорошая универсальная проверка для отсева ботов.
-
@FastSpace said in HTTP/3 Работает :D:
Хорошая универсальная проверка для отсева ботов.
Чушь. Я сижу за обычным роутером, обычные браузеры, почти все, две системы и мак и винда, все по http 2.0 по твоей проверке. И чё? Меня кто-то банит?
В любом деле есть избыточность рвения и достаточность. Не в обиду, но есть такая русская поговорка - заставь дурака богу молиться, он и лоб расшибет...
А ещё есть в психиатрии понятие - мания приследования 😁 ну не обижайся. Это так к слову.
-
@Bigma said in HTTP/3 Работает :D:
@FastSpace said in HTTP/3 Работает :D:
Хорошая универсальная проверка для отсева ботов.
Чушь. Я сижу за обычным роутером, обычные браузеры, почти все, две системы и мак и винда, все по http 2.0 по твоей проверке. И чё? Меня кто-то банит?
В любом деле есть избыточность рвения и достаточность. Не в обиду, но есть такая русская поговорка - заставь дурака богу молиться, он и лоб расшибет...
А ещё есть в психиатрии понятие - мания приследования 😁 ну не обижайся. Это так к слову.
Ты это образец для мерила 😁, ведь у нас в стране каждая домохозяйка кастомит роутер, а сверху систему. Да ещё скриптики сверху написывает.
Ты не забывай, что 1 проверки недостаточно, а вот двух уже да. UDP, DRM, ну и моник чекнуть наличие. Все 3 фейла, бот
-
@FastSpace а зачем тебе две если одной достаточно - она однозначна, а вторая сомнительна, и может привести к ложным срабатываниям...
-
@FastSpace said in HTTP/3 Работает :D:
Ты не забывай, что 1 проверки недостаточно, а вот двух уже да. UDP, DRM, ну и моник чекнуть наличие. Все 3 фейла, бот
Я думаю, что в реальной жизни все проще. Так как работает машинное обучение с подкреплением на стороне антифрода, а вот это решение уже может легко пометить всех пользователей без QUIC как подозрительных. Так как по другим показателям среди таких пользователей, к примеру, 70% фродеры.
Мое мнение - да, проблема есть. И, вероятно, проблема серьёзная. -
@sergerdn я зашел с мобилы с chrome браузера с мобильного интернета - на данную ссылку, и у меня выдает что нет поддержки квика, перезагрузил страницу, тоже самое - я бот ?
-
@Bigma said in HTTP/3 Работает :D:
@sergerdn я зашел с мобилы с chrome браузера с мобильного интернета - на данную ссылку, и у меня выдает что нет поддержки квика, перезагрузил страницу, тоже самое - я бот ?
Я этого не говорил. А говорил, что отсутствие поддержки QUIC может свидетельствовать о том, что ты подозрительный, а в совокупностями с другими признаками, с точки зрения машинного обучения, пометить тебя как бота.
Вроде на одном языке говорим, а такое непонимание. -
@sergerdn может лет через 10 это и можно будет использовать однозначным способом, а пока это лишь технология, которая мало ещё поддерживается. Вот как клаудфлер начнет пинать по этому признаку, вот тогда это звоночек 🧐
-
@Bigma said in HTTP/3 Работает :D:
@sergerdn может лет через 10 это и можно будет использовать однозначным способом, а пока это лишь технология, которая мало ещё поддерживается. Вот как клаудфлер начнет пинать по этому признаку, вот тогда это звоночек 🧐
Можно не гадать, сам Cloudflare дает статистику и тенденция заставляет напрягаться.
-
@Bigma said in HTTP/3 Работает :D:
@sergerdn я зашел с мобилы с chrome браузера с мобильного интернета - на данную ссылку, и у меня выдает что нет поддержки квика, перезагрузил страницу, тоже самое - я бот ?
Ссылка тестовая и нужно сначала разобратся как работает. Если начать детектить UDP это будет сделано без той ссылки.
-
@FastSpace по тенденции, которая по статистики Клауда есть ещё как минимум три года, хотя все стремительней развивается технологии... Но это не касается РФ. А свои фермы вы очевидно в РФ тюнити...
-
@FastSpace ты смотрел слив по Яше? Там очень все забавно 🧐
-
Решил не создавать новую ветку и написать сюда.
Целью данного сообщения является демонстрация способа определения поддержки протокола QUIC браузером со стороны антифрод систем очень незаметно для пользователя. Так как факт проверки не будет виден в developer tools Chrome, потому что сайт не доступен по протоколу QUIC.
Множество подробностей реализации я опускаю ради упрощения. Описываю ниже возможную(я ее протестировал) логику реализации такой проверки.
Подготовка на стороне сервера:
- Веб-сервер (в моем случае nginx, но можно использовать любой).
- Инструмент для мониторинга и захвата UDP-пакетов с признаками QUIC (в моем случае, собственное решение на базе eBPF/pcap). Альтернативы: стандартный tcpdump или Wireshark.
Основная логика:
- При первом запросе страницы отправлять специальные заголовки Alt-Svc и Critical-CH.
- В ответ на это, браузер (Chrome) попытается установить QUIC-соединение перед повторным запросом страницы. Повторный запрос страницы Chrome делает потому что получил заголовок Critical-CH.
- К моменту повторного запроса на сервере уже известно, был ли отправлен UDP-пакет с QUIC-признаками.
Последовательность работы Chrome:
- Исходный запрос страницы.
- Попытка установления QUIC-соединения.
- Повторный запрос страницы.
Теоретически, существует вероятность, что QUIC-пакет не успеет дойти до сервера до повторного запроса, но это маловероятно и решаемо.
Дополнительно для браузеров без поддержки Critical-CH или для надежности можно использовать внутренние редиректы, чтобы браузер успел отправить QUIC пакет к моменту анализа на сервере.
В качестве побочного эффекта можно также относительно незаметно получить реальный ip пользователя, если он использует прокси, не отключил QUIC, и устанавливает прокси в браузер стандартным способом. BAS этому не подвержен.
Выводы:
Всем капец 😁
P.S.
Стал собирать статистику по поддержке протокола QUIC в живой природе. Предварительные результаты не утешительные. Я давал выше ссылку на анализ Cloudflare. Cloudflare мягко говоря немного манипулирует статистикой, так как не дает данных в разрезе операционных систем и версий браузеров. Если выкинуть старые версии браузеров и операционных систем, то будет совсем другая история.P.P.S
Может быть добавлю позже статистику, что сейчас собирается на трафике у меня. -
@sergerdn Ты как обычно всё усложнил. На гитхабе питон готовый лежит на 20 строк по проверке UDP у прокси. Ищи называется udp_check.py
Там можно обратится как по IP, так и по hostname. Выяснилось что тот же говно 3proxy не умеет по домену, только в последнем мастере починили, а его скачать не смогут многие. Остальные вещи зараза вообще отказался фиксить. В топку этот 3proxy так что -
@sergerdn said in HTTP/3 Работает :D:
В качестве побочного эффекта можно также относительно незаметно получить реальный ip пользователя, если он использует прокси, не отключил QUIC, и устанавливает прокси в браузер стандартным способом. BAS этому не подвержен.
Потому что
Браузер должен уметь слать UDP вносокSocks5. Это не умеет делать Chrome, Firefox и прочие браузеры реальные. Это даже не умеют антики и конкурент на букву з. Бас тут топчик.Это не всё еще. Сервер с прокси тоже должен на своей стороне отправлять такие пакеты не мимо прокси. Горе подниматели с 3372 и тут накосячат.
-
@FastSpace said in HTTP/3 Работает :D:
@sergerdn Ты как обычно всё усложнил. На гитхабе питон готовый лежит на 20 строк по проверке UDP у прокси. Ищи называется udp_check.py
Нет у меня цели проверить работает ли прокси по UDP, а цель предупредить, что сайт может делать "скрытую" проверку браузера на наличие поддержки QUIC. В связи с твоим комментарием отредактировал свой пост, чтобы было более четко и яснее.
@FastSpace said in HTTP/3 Работает :D:
Браузер должен уметь слать UDP в носок Socks5. Это не умеет делать Chrome, Firefox и прочие браузеры реальные. Это даже не умеют антики и конкурент на букву з. Бас тут топчик.
BAS использует стороннюю библиотеку туннелирования трафика(правда очень древнюю). Каждый так может, почему не делают - вопрос другой. Вероятно, потому что не знают, что нужно.
Можно делать следующий хак, когда разработчики антиков забивают на запросы от пользователя:
- заменить исполняемый файл Chrome в антике на свой, предварительно переименовать оригинальный файл
- свой файлик при запуске парсит параметры командной строки и запускает оригинальный файл Chrome антика с какими угодно параметрами, какими угодно плюшками сбоку, включая туннелирование трафика всего процесса Chrome, установку переменных окружения, etc.
Пример, что может делать кастомный Chrome.exe, чтобы запускать оригинальный файл:
proxy_tunnel_program.exe --proxy=socks://127.0.0.1:3223 chrome_original.exe --profile-directory=Buu ....Я так делал в незапамятные времена с Multilogin. Думаю, что будет работать и сейчас.
-
@FastSpace said in HTTP/3 Работает :D:
Выяснилось что тот же говно 3proxy не умеет по домену, только в последнем мастере починили, а его скачать не смогут многие. Остальные вещи зараза вообще отказался фиксить. В топку этот 3proxy так что
Есть rfc9298, который вводит новый стандарт для проксирования QUIC трафика.
Несмотря на то, что есть готовые библиотеки для протокола(quiche) с вообщем-то довольно простым API, вероятно, ready to use решений мы увидим весьма не скоро.
Причина отсутствия готовых продуктов простая. Разработчики могут в 20 строк кода набросать SOCKS5 прокси, так как за них всю работу делает TCP, а вот в случае с QUIC(UDP) все уже сильно сложнее и строк надо 2К.
Можно немного почитать еще тут - https://blog.cloudflare.com/unlocking-quic-proxying-potential/
Наверное, на данный момент единственное решение это вставлять мобильный модем в сервер, там поднимать прокси, который не сильно разбирается что за трафик он проксирует. А связь с клиентом делать с помощью чего-то вроде Tailscale, так как он работает на уровне IP. Будет что-то вроде локальной сети, чтобы UDP трафик ходил в любые стороны между прокси и клиентом.
Я думаю, что люди так и делают. Сам лично НЕ делал. Немного раздражает, что прокси-сервисы забили один большой инструмент на пользователей. Но что делать - такова реальность.
Возможная архитектура для поставщиков прокси:
- Выходная нода(где трафик ходит в Интернет) -> IP туннель как backconnect к серверу.
- клиент прокси сервиса -> распаковка SOCKS5(проверка прав доступа, etc) -> заворачивание трафика в IP туннель до выходной ноды
-
-
@FastSpace said in HTTP/3 Работает :D:
@sergerdn Уже есть все готовое.
Где готовое есть? Для кого? Для поставщиков прокси? Они совсем разные бывают, есть и те, у кого выходные ноды и на мобилках под Андроидом, есть те, у кого и на Микротиках.
@FastSpace said in HTTP/3 Работает :D:
Кроме QUIC в UDP есть еще WEB RTC. Это тоже надо проксировать правильно
Если весь трафик завернут в тунель на уровне IP и прокси не разбирается что он проксирует, а просто меняет в пакете TCP/IP, UPD/IP адрес источника - все равно какой протокол.
Но это все теоретические. Если у тебя есть ссылки на готовые решения - я с удовольствием их почитаю, чтобы опять не изобретать свой велосипед.
-
M Moderator moved this topic from Off topic on
