Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 104
Про статистические характеристики трафика - всё верно. Но самое главное мы упускаем. Что РКН теперь блокирует произвольные соединения, произвольные ресурсы интернета уже даже не однозначно вредные по его мнению, а просто банально подозрительные, как ему показалось. И никакого отчёта о своих действиях РКН не предоставляет. Просто что хочет, то и делает. Наводит всяческий хаос и беспорядок в интернет-коммуникациях, и всё ему сходит с рук. Сейчас уже с новыми DPI подходами и софтом - они могут поломать всё что угодно, хаотичным образом.
Вот представьте себе, что так вели себя бы власти в отношении людей? Подозрителен? Шляпу носишь не того цвета, и наперекосяк? Осанка странная? В концлагерь его, по заветам гестапо!
Власть практически так себя и вела. Или вы забыли, как людей с зелёными вещами задерживали в уентрк в марте 22го?
Снизить уровень доступности нарушающей законодательство информации при сохранении доступа к социально значимым ресурсам.
Не знаю, кому и по какой причине удаётся упустить вот эту первую цель буквально в публичной декларации целей и задач РКН на сайте этого самого РКН. А ещё там сверху написано, что РКН не хаос наводит, как Вы тут изволили выразиться, а обеспечивает стабильность в обществе.
А есть чёткое определение этих "социально значимых ресурсов"? Ато может, лично для меня, оранжевый ютуб вполне себе социально значимый.
Нет, нельзя. “Четкое определение” это свойства заранее установленный и оговоренных правил, которые не могут произвольно меняться по желанию левой пятки. То есть ровно того, чего они делать совершенно не хотят, наоборот правила должны быть максимально размыты и запутаны, чтоб каждый под Дамокловым мечом ходил
Целый список есть, и постановление Правительства РФ от 29.12.2021 №2531, определяющее правила попадания в него. Когда этот оранжевый ютуб переедет в Россию и там начнут появляться страницы местных органов самоуправления, тогда приходите.
Вот рядом комментатор говорит, мол, правила должны быть и не меняться по желанию левой пятки, и чёткие. Так вот они, и когда некоторые граждане говорят «у нас в стране всё по закону» - так и есть. Когда РКН и Минцифры говорят, что они исполняют существующие законы - так и есть. А если кто-то продолжает подменять у себя в голове законность собственными представлениями о справедливости или логичности или о чём угодно ещё - ну что ж, желаю всяческих удач.
Ну-ка расскажите мне о законности блокировок всех крупнейших постеров зарубежных и cdn??
Рассказываю! Российские законы это не закон всемирного тяготения, и поэтому между отстыковкой яблока от яблони и началом падения его на землю может быть ощутимый временной лаг. Или, например, первые 16 грамм яблока могут падать на землю, а остальное яблоко - нет.
Владелец яблони может обратиться в суд, если считает, что его права нарушены. В суде ему напомнят про закон о приземлении, приоритет местного законодательства над международным и прочие увлекательные вещи. И может быть даже починят его яблоки года через три разбирательств. Зачем владельцу яблони тратить своё время и деньги на это ради какого-то небольшого количества странно ведущих себя яблок - непонятно.
Стоящий под яблоней гражданин России, ждущий, что на него упадёт всё яблоко, а не только 16 грамм, тоже может обратиться в суд для защиты своих прав, а если его не устроит решение суда - подать апелляцию, и так пока суды не кончатся. Как сделал, например, гражданин Ларионов (иск еле нашёл, ещё бы ходатайство РКН почитать). Процесс этот тоже небыстрый, закончится наверняка торжеством правосудия, если до ВС/КС дойдут (как в деле Долиной, например). Но если в процессе заявителю активно подставляться под административную ответственность, то шансы несколько уменьшаются.
В общем, решения суда о незаконности блокировок нет, поэтому лично Вы их можете считать незаконными, но более незаконными с точки зрения закона они от этого не становятся. И не то чтобы это чисто российское развлечение - посмотрите на цитадель демократии с её центром имени Трампа и Кеннеди, и как местное население этому всему радуется. Тред начался с того, что люди не замечают поведения, буквально написанного на лице у объекта.
Владелец яблони может обратиться в суд, если считает, что его права нарушены.
А если я, как гражданин РФ, считаю, что мои права нарушены блокировкой для меня ресурсов - к кому обращаться? В суд - уже обращались, бесполезно.
Номер дела не подскажете? Если это про того же гражданина Ларионова, про которого я упомянул в следующем после цитируемого абзаце, то там всего два отказа в рассмотрении пока. Ну то есть, какие были ожидания от подачи иска, что Таганский суд скажет «а, да, точно, фигня какая-то; слышь, ты, министерство, ну-ко прекрати щасже блокировать телеграм»?
Вы идёте судиться с государством как на детский утренник, а потом удивляетесь результатам.
>В суде ему напомнят про закон о приземлении,
какое приземленеи вы о чем? бОЛьшая часть этих команий не оказывает услуги в РФ, а часть официально ушли...
Если эти компании ушли или не оказывают услуги в России, то им нет ни резона, ни средств доказывать незаконность блокировки, и написанное мной в прошлом комментарии по существу не меняется.
Для признания на территории Российской Федерации чего-то незаконным одного жжения в тканях недостаточно, нужно обязательно в суд идти и/или жалобы писать. Вы не спрашивали меня о правильности или оправданности или справедливости блокировок. Вы спросили о законности. Я вижу, что Вы недовольны, но не понимаю, почему Вы недовольны мной, как будто это я Вам что-то блокирую или в суд не пускаю или в ответ на Ваш иск пощу мемы с котятами.
А вот вопрос к эксперту по законности блокировок. У нас Хуавей под санкциями, и если нет магазина от Гугл, есть желание поставить приложение той же управляющей организации, которого нет в русторе. Есть Aurora Store, который позволяет это сделать. Его почему накрывают блокировки?
Извините на они уже всё поломали. Вы когда последний раз заходили в Интернет без прокси VPN или запрета? Я ради интереса открыл браузер на первые несколько страниц абсолютно нейтральные поиск у меня не работал 98% ресурсов. Что неудивительно при поголовном массовом замедлении всех крупных зарубежных остров иcdn . Абсолютно незаконных. Даже в рамках текущих так называемых законов.
Презумпция виновности.
Или, как вариант, бесполезности: если мне хватает цитат интернета бумажными распечатками на стол, то и другие без гитхаба обойдутся.
У меня есть вообще предложение, чтобы уйти от простых банальных TCP соединений с серверами и использовать их для обхода блокировок. Надо теперь перейти на уровень самих IP пакетов, и слать их в массовых количествах, напрямую к серверам обходов блокировок. TCP соединение можно сбросить, а что ты сделаешь с IP пакетами? Весь поток к IP адресу перекроешь?
Но вот для вспомогательных целей, подтверждения доставки и прочего действительно можно организовать TCP соединение. Однако же, отчего же надо это соединение организовывать непременно с хостом, который лежит по тому же IP адресу, что и сервер обхода блокировок? Можно организовать ещё какой-нибудь сервер в сторонке, который будет помогать, и слать часть нужной нам информации от своего имени.
Да и вообще, можно организовать параллельную работу по обходу блокировок через несколько слаженных хостов, со своими IP адресами, работающих сообща.
Весь поток к IP адресу перекроешь?
Ну, допустим, UDP успешно перекрывают, оставляя окно строго только для TCP.
Ну дык можно слать к серверу IP пакеты, выглядящие как фрагменты TCP сессии. И только посвященные будут понимать что это не просто рядовые какие-то пакеты. К ним должна быть особая интерпретация. Воспринимающая их на самом деле, как что-то вроде UDP датаграмм.
Рандомные ТСР уже выглядят странно, особенно, если там бардак с флагами, выходящий за рамки стейт-машины состояния сессии.
Я хочу сказать, что в условиях произвольных блокировок и хаоса в сетях - явное установление соединений, которые могут быть заблокированы и сброшены, это проблема. Подход, где информация передается порциями, как-то налаживается за ней контроль передачи, маршрутеризация по разнообразным маршрутам передачи, не обязательно постоянно одним и тем же - этот подход выглядит куда более живучим и надёжным. А порции информации могут быть как UDP пакеты, так и просто передача через временно устанавливаемые TCP соединения, на которых не рассчитывается что они проживут долго и могут быть разорваны в любой момент.
Если бы сеть состояла только из IP маршрутизаторов, то ваша идея вполне себе рабочая, что можно не ограничиваться только UDP или только TCP и делать хоть каждый день свой IP протокол. Однако, такое было бы возможно при наличии у каждого своего личного и уникального адреса (привет IPv6!), который может пиринговаться напрямую каждый с каждым. Но легаси IPv4 и некоторые "особенности" сетестроения в прошлом принесло нам несчётное количество NAT узлов в этой сети. И каждый из них должен уметь работать с каждым выдуманным протоколом. Об этом уже намекнули ниже.
В принципе уже есть что-то похожее на описываемое, вроде условного udp2raw. Правда не думаю, что можно далеко ускакать от TCP/UDP/ICMP. Не эксперт в теме, но по-моему иначе эта идея разобьется об провайдерский NAT, даже не дойдя до ТСПУ
Было бы проще, распространись уже IPv6. Жаль его в дикой природе домашнего интернета я пока даже ни разу не видел
С голым IP протоколом ещё все упирается в NAT, за которым так или иначе находится большинство пользователей.
Вот скажем да, сделать 3 сервера A, B, C. Через A будет идти служебный трафик, с подтверждением доставки пакетов. Через B будет идти outbound трафик, через C будет идти inbound трафик. Но можно даже не так строго, а трафик может варьироваться. То значит через B пошлют всё-таки порции inbound трафика, то через C пошлют ещё сколько-то там outbound трафика.
А между собой сервера A, B, C коммуницируют, и объединяют всю информацию, которая от них уходит или поступает.
Ещё добавлю, что если группировка сервером будет не из 3-х хостов, а большого их количества, можно будет вообще не держать постоянно открытые соединения с какими-то отдельными серверами, а время от времени их открывать, гнать трафик, закрывать. Открывать другие соединения с другими серверами. И так до бесконечности. Но виртуальное соединение между нашим компьютером и группировкой серверов будет продолжать поддерживаться.
Вы исходите из логики чёрного списка. А тут всё ближе логика списка белого. Недостаточно скрепный трафик - в /dev/nul.
ну и зачем это? тспу пофиг на количество трафика, время соединений
NaiveProxy наше всё!
Не хватает опроса:
Павел придёт и спасёт
Кончающий AI-баклажан, а не прокси
Задрали уже. Их бы энергию в мирное русло.
Хз, может до меня ещё не дошло, но личный прокси работает пока.
Дык, это же основа конспирации: пока ты используешь только сам (ну, пусть ещё твоя жена и дети) ключ на антивирус/виндовс/etc то его не блокируют. Но стоит его разместить на варезнике с хорошим охватом и вот его уже заблокировали. Это же применимо и к сетевым ресурсам: статистика использования конкретных адресов решает.
Интересно, но выглядит так, что новые блокировки (конец мая) таки все же как то детектируют особенности ClienHello (в обсуждении issue d tdlib предполагали, что по соответствию Chome определенной версии, и якобы эта версия хрома сайты тоже открывает нестабильно) - тормозит именно хендшейк, но если соединение установлено, то далее прокся работает нормально
Да, последнее время vless+reality+xhttp на своем vps работает из рук вон плохо. Пока есть резервные каналы - бесплатные прокси-расширения для браузеров, некоторые android-приложения которые сами как-то умеют обходить блокировки, но все равно тревожно.
Я не такой крутой специалист чтобы понять в чем там дело, единственное - внимательно слежу за статьями и комментариями на Хабре, вдруг кто что дельного посоветует.
-
Детектируют реальный TLS client hello от хрома, но только если устанавливается несколько сессий (что и делает телеграм и большинство vless проксей). К этому ещё есть динамический триггер блок - при запросе на популярные в проксях sni (например github.com), полностью блокируется https с fingerprint chrome к некоторым хостинг провайдерам (напр vdsina).
А ещё есть полный блок https со sni к некоторым хостингам (например justhost)
В самом начале новых блокировок я видел что у людей срабатывал блок начиная со второй TLS сессии с отпечатком chrome на любой ip (на сколько я знаю это уже откатили, но это не точно. у меня сейчас ограничение это 6 сессий хрома на определённые хостинг провайдеры типа vdsina и h2nexus)
DPI с базой JA3/JA4-отпечатков популярных браузеров может сравнивать: вот пришёл ClientHello, который заявляет себя как Chrome, но его JA3-хеш не совпадает ни с одной реальной версией Chrome.
ClientHello не может заявлять себя, как хром. Юзер-агент будет только в HTTP. На уровне TLS - только косвенные признаки, так что фраза вводит в заблуждение. LLM, как обычно, врёт в важных деталях.
Я правильно понимаю, что в статье художественный вымысел про ТСПУ (не подкреплённый никакими воспроизводимыми исследованиями) в стиле "чё там чисто в теории можно было бы сделать" смешан с реальными фактами? Автор, признавайся!
Дурной вопрос - а почему не проложат тоннель через реальный https? Условно, клиент держит у себя кастрированный electron, который обращается к прокси как к обычному сайту, а полезная нагрузка передаётся через get/post запросы, или вебсокет, или через любой другой мало-мальски адекватный механизм. Прокси, соответственно, возвращает абсолютно валидную веб-страницу с размещённым посреди ответом. И хэдеры на месте, и порядок загрузки всего добра правильный будет.
Так уже давно используют https под совершенно другие задачи, чем он предназначен изначально. Те же VPN маскируются под https соединения, и гонят в них совсем не HTTP запросы.
Да, и я об этом же. А что, если собственно и не маскировать, а именно что легитимно оборачивать? Ведь внутри зашифрованного соединения, гонящего HTML-страницы, никто не поймёт, картинка котика там пришла в числе прочего наполнения, или жирный кусок данных.
Потому что ТСОЦ увидит, что пользователь гоняет гигабайты данных до какого-то неизвестного сайта типа Wolf4D.freemyip.com, тыкнет его, увидит что на нем даже главная не отрывается (active probing) и отправит его в блок. Или даже сразу отправит его в блок
ну хз
как будто бы, в век ии, генерировать уникальные гладковыглядящие сайты можно тысячами за миску риса
Хостинги, сертификаты и доменные имена для этих тысяч обойдутся уже совсем не в миску риса
Почему же? Сертификаты бесплатны нынче. Хостить индивидуально тоже их все не надо, а проксировать все невалидные запросы на 1 сервер с тысячами (пусть, даже нестатических сайтов), на который приходит по пару открытий сайтов в минуту тоже ниочем. Остаются только домены. Но, кажется, ip v4 нынче сильно дороже 1го домена типа fun/space/xyz и так далее, если, конечно, не требуется держать его на балансе больше года (а это не нужно), и, выходит, что, если держатель прокси раздобыл ipv4 и виртуалку, способную проксировать, то все остальное уже крохи от понесенных затрат
А потом ТСОЦ вычислит что у юзера идут гигабайты с одного айпишника но разными SNI и отправит его в блок. Какой-нибудь LetsEncrypt тоже думаю не шибко рад будет если у него начать серты тысячами прям запрашивать.
А зачем плодить домены на 1 ip?
1 прокс-1 домен-1 уник сайт. То, что их таких тысячи на один ориджин смотрят при клоакинге, только админу ведомо.
Ну так CIDR то у запросов ко всем сайтам один же? Или даже без этого: отлитит в бан одна прокся по ip, отлетят все за ней, а ТСОЦ видит, что вы гигабайты льете с какого-то левого сайта постоянно.
edit: кажется понял что вы предлагаете, но это защитит только от active probing, а вот паттерны трафика вида “гоняет гигабайты на один сайт” или “частота пакетов похожа на стриминг видео” вполне может быть вычислена и прокся отлетит в бан. В принципе это от vless мало чем отличается
А может это у меня форум любителей котиков, и мы там смотрим видяшки с котиками? :) но вообще такой канал не про видяшки, а скорее про обмен единичными сообщениями. Видяшку можно и по-другому выгрузить, чтобы пакеты не гонять.
Помню, во времена местечковых провайдеров с развитыми локалками и дорогим трафиком "в мир", были люди с безлимитом, изобретали irc ботов, которым пишешь адрес веб-странички, а бот лезет в большой интернет, выкачивает её и укладывает в локальный FTP.
P.S. С современным ИИ вполне можно и "мёртвоинтернетный" форум из ботов соорудить, где будет дикая фейковая активность.
Ну вот его сначала заблокируют, а потому будете доказывать что это форум любителей котиков. Тут у половины страны вся подсеть cloudfire не работает, потому что TLS1.3 c EncryptedClientHello по умолчанию использует, а блокировка из сабжа рубит и часть легитимных соединений через Хром. Думаете ваш сайт любителей котиков кого-то остановит?
Вот эти вот рассуждения, что а может у меня что-то такое, что вполне легитимно... Оно не прокатит с нынешним РКН. Если он делает что хочет, блокирует кого хочет - никакие оправдания неуместны. РКН что-то не понравится хоть слегка, и он ваш сайт заблокирует. И даже не почешется. И даже достучаться до него не выйдет, т.к. он не ответственнен перед народом. Для РКН имеет значение только мнение начальства.
active probing
Кстати, это точно есть. У меня маскировочный nginx на vps когда упал - соединение vless моментально пропадает, хотя все работает на обоих сторонах. Режут. Сайт поднимается - коннект возникает. Содержимое сейчас не проверяют - должен быть просто ответ любым http кодом. Если не накрутили уже еще чего...
скорее потому, что у тебя упавший nginx не пересылает пакеты на интерфейс xray
Нет. Зачем вы делаете уверенные предположения без диагностики и даже без деталей настройки? :)
Там вообще, все наоборот - xray пересылает пакеты nginx. И я все проверил - пакеты на vps вообще перестают приходит, если сайт маскировки не отвечает.
Хех, но логичнее как раз было бы, чтобы был сайт про котиков и рецепты, а уже xray где-то там, среди мейнкунов и пирожков с яблоками...
Если Вы используете Reality, то это обычное поведение. При инициировании TLS-соединения Reality подключается к маскировочному сайту. Когда этот сайт не отвечает, не работает и прокси.
что на нем даже главная не отрывается
Чисто теоретически, что будет делать ТСОЦ если у нас mTLS? Пускать под нож всю идеологию ZeroTrust ну такое себе (я конечно понимаю что там всем пофигу, но тут уж проще только православные сертификаты выдавать, а остальное блочить)
Так VLESS+XRAY именно так и работают. Они "сбоку" видятся как обычный https трафик. И даже если ТСПУ сам постучится на сервер, то ему ответ придёт в виде вполне легитимной и правильной странички.
Это да, но статья о том, что ТСПУ это отслеживает по несовпадению характера трафика с загрузкой веб-страниц. А я о том, что ведь можно и пойти дальше, и пользователю также возвращать веб-страницы, только с пейлоадом. Тогда ни один детектор не отличит, где срач на форуме, а где редирект сообщений через "фейковый" форум
Это возможно, но очень недружелюбно к конечному пользователю туннеля и администратору сервера:
Нужно хостить конкретный новый сайт типа
funny-cats-not-suspicious.ru, чтобы его бэк мог после TLS-терминирования прочитать расшифрованное тело GET/POST и отправить ответ обратно. Соответственно, весь сайт можно полностью заблокировать по SNI после первого подозрения.Теоретически, можно использовать любой чужой двунаправленный разрешённый канал передачи (типа чата Avito или Яндекс.Телемост, но это другое семейство подходов).
На клиентской стороне снова придётся использовать что-то похожее на браузер, смешивающее и расщепляющее обратно настоящие смешные картинки с полезным proxy-трафиком.
Иначе, если используем настоящий браузер, фронтенд сайта должен общаться с условным
127.0.0.1:12345в LAN (или на самой машине/смартфоне), на котором слушает TUN- или проще socks-proxy, который как раз перекидывает трафикapp <-> socks <-> browser[cats.ru].
Пока писал, понял, что подход интересный, и неплохо формализуется: достаточно иметь несложную JS-либу для фронтенда/бэкенда, и клиентское/серверное приложения, с которыми общается эта либа (большую часть можно собрать из готовых кирпичей).
Минусы:
в п.1, бэк сайта должен быть полностью подконтролен администратору входной ноды;
как сказано, сайт очень просто заблокировать по SNI, если соединение без Encrypted Client Hello;
плохая защита от реверс-инжинирига: в JS на клиентской стороне даже с обфускацией можно будет явно найти попытку соединения с условным
127.0.0.1:12345— значит, сайт-то непростой, в бан его.сайт-носитель должен быть постоянно открыт (решаемо, но может быть противно, держать на том же устройстве или в LAN работающий набор вкладок).
Плюсы:
можно прятаться за CDN;
носитель соединения — настоящий браузер, отличить его от настоящих соединений при хорошем shaping нереально;
ну и собственно shaping — можно сколько угодно аккуратно троттлить и фрагментировать трафик, делая его неотличимым от обычного сёрфинга.
(Микрореклама: работаю над проектом FPS, который, теоретически, способен использовать любые TLS-носители для передачи полезного трафика.)
Наверное пора в консерватории менять что-то.
Учитывая статистический подход к анализу трафика, где кучу параметров у TLS/TCP анализируется - будто хорошей идеей становится гонять трафик на высоких UDP портах, который вообще ни на что не похож абсолютно.
Потому что одна ошибка в маскировке (неправильный SNI, fingerprint и прочее) буквально сразу триггер для DPI и после VLESS серверов с условным махом на 8443 порту начинается naive proxy и прочая дичь.
Кроме того, не забываем, что VLESS априрори для обхода блокировок используется, чего не скажешь о древних openvpn/l2tp+ipsec, которые классика для корпоративных туннелей, которые после недавно сломанного эквайринга побаиваются трогать. Wireguard с трудом сюда еще проходит. В общем я о том, что небольшое количество понятного трафика классических L2-L3 туннелей могут стерпеть, чем кривую маскировку.
Так что все эти шаблонные настройки для VLESS ток упрощают работу по тому, чтобы найти и вычислить и не можешь нормально замаскироваться - просто не будь похожим не на что, hyseria2 + salamander/awg2.0 в помощь.
Извините, не айтишник, инжинигер.
Это получается, на всех крупных сетевых узлах стоит некое (и полагаю очень большое) количество вычислительных процессоров (видимо, CPU или GPU) для онлайн-анализа гигабитных объемов трафика?
Именно, зазовутся они официально ТСПУ. стоят великие миллиарды, и еще недавно выделили дополнительно великие миллиарды чтоб нарастить их мощность вдвое к 2030му году
Господи Иисусе, тут хер пробьешь закупку лишнего вычислительного сервера, микросхемы рассчитывать, про перенос вычислений на GPU, как европейцы делают, я вообще молчу и не заикаюсь, а этим уродам вагон с баблом выделяют... Очень сильно демотивирует делать что-то новое.
Пишут, что пропускная способность одного блока ТСПУ - 100 ГБит/сек. Машинки явно крайне мощные, если способны на такой скорости исследовать трафик.
Себестоимость есть, и она конечная. Условно миллион пакетов в секунду прогнать по тысяче правил = 1 млрд проверок. Кратно количество правил увеличить нельзя, нет кратного запаса производительности. Этим принципом конечности возможностей и пробивает zapret/byedpi, главное узел не был в списке блокировок по ip или ip всей подсети. Подсети проще, правил много меньше. Но и попутный ущерб гораздо больше, можно что-то нужное грохнуть.
видимо, CPU или GPU
FPGA, там где большие объемы трафика
Там не обычные десктопные процессоры стоят, а специализированные сборки на ПЛИС. Они аппаратно заточены чисто под разбор сетевых пакетов на лету, поэтому и тянут такие объемы
А как ТСПУ анализирует поведение трафика? Ведь для этого надо неимоверные объёмы оперативки. Соединений миллионы в секунду и все их надо хранить, дополнять новыми запросами а после анализировать. Выглядит как что то нереальное
Это ведь специализированная железка, по типу как асики для майнинга, всё делается налету, зачем хранить? Хранить по закону Яровой обязали провайдеров, это другое направление. Естественно что метаданные и данные для статистического анализа пересылаются для обработки, и скорее всего уже не человеками, а нейросетью, но это тоже ответвление, сама коробка ТСПУ тупо исполняет приказы, быстро исполняет. Сетевая система у неё быстрая, если это на магистральных каналах, то боюсь представить, там же что-то порядка 400-800Gb/s должно быть, если не больше.
А никто не хочет написать про то, что текст нейронкой написан? Читать противно
чтобы не было противно читать нейротексты, заставляйти сами нейронки их читать, а вам доставлять краткое изложение прямо через речевой синтезатор.
Причём не какой-то нейронкой, а именно GPT 5.x, которая отвратительно пишет на русском языке.
Бросается в глаза по трём основным признакам:
1) Излишнее использование англицизмов. Большее, чем пишет реальный человек.
2) Постоянные "фразы в кавычках".
3) Много коротких односложных предложений, идущих подряд.
О, Спасибо! Значит, нужно писать ботов которые будут показывать активность 24/7, похожую на человеков и пропускать пользовательский трафик по своим отпечаткам при необходимости.
Помню, во времена Windows'95 пользователи грозились лично БГ на почту отправлять свап-файл. Не в курсе - сработало или нет. Но если всей страной начать гонять терабайты бесполезных данных - интересно было бы понаблюдать реакцию РКП =)
Так уже - шевеления в сторону ограничения объёма зарубежного трафика.
Реакция будет одна: 15 Гб на рыло в месяц плюс список исключений. Чего там интересного наблюдать?
Генерировать мусорный трафик дорого в первую очередь для самого пользователя и провайдера аплинка. Ты быстрее свой домашний роутер или свич в подъезде положишь, чем магистральный узел
генерировать фейковый «веб-подобный» трафик поверх реального — это огромный overhead, который убивает производительность и всё равно не идеален
Это overhead, но в этом и плюс. Особенно если до начала подключения надо "скачать" или "загрузить" десятки МБ, как на обычный файлообменник, и только потом в потоке этих псевдорандомных данных пойдут handshake и данные скрываемого приложения. Причём для того, чтобы всё это детектировать и отличить от обычной выгрузки файла - надо держать в ОЗУ все эти десятки МБ и для расшифровки нужно будет кратковременно нагрузить вычислениями процессор на 100%. Для пользователя в эпоху безлимитов такой трафик и подзависание аппарата будут некритичны, как и для инфраструктуры, уже давно гоняющей пользователям гигабайты потокового видео, но для системы фильтрации такая нагрузка будет приговором.
Забавно как попытка замаскироваться под хром выдает тебя с потрохами, потому что твой "хром" не качает баннеры и аналитику гигабайтами
Идеальный секьюрити-инцидент - юзер не смотрит рекламу, значит точно шпион
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как DPI вычисляет MTProto-прокси: технический разбор детекции протоколов по сигнатурам