Ну если нет желания или возможности возиться с кодом и публиковать его (что было бы замечательно, как по мне), то можно сделать пустой репозиторий, закинуть туда лицензию, ридми со ссылкой на сайт, а в релизы просто публиковать готовые бинарники.
Предлагаю публиковать релизы на гитхабе. Его, может быть, тоже заблокируют когда-то, но урон от этого будет столь значителен, что недоступностью свежего билда wiresock можно будет пренебречь.
В том, что клиенты буквально приходят к ним за этим. Чтобы cloudflare расшифровал их трафик и закешировал его. Или что-бы какой-нибудь js challenge ботам встроил. Без терминации TLS это попросту невозможно.
Большинство еще и добровольно платит за это, представляете?
Если вам не нужно кеширование/js challenge/waf, а готовы ограничиться только L3/L4 ddos защитой, то вы можете воспользоваться Cloudflare Spectrum. Тогда ничего терминироваться не будет.
То есть они не прячут это где-то в соглашении, они явно и открыто продают именно такую услугу (и весьма успешно, надо сказать)
С одной стороны да, к их функциональности прямо это не относится. С другой - они массово распространены и это их сфера интересов.
В конце концов это и реклама бесплатная (если ханипот что-то обнаружит) и снижение вероятности, что их вообще будут сканировать (что бы не нарваться на этот самый ханипот)
Да я обязательно написал бы, если бы такие были бы…
Я упоминал клиенты на базе sing-box, которые безопасны если не указать mixed inbound. Но потом пришел @ValdikSS и упомянул про прямое обращение к интерфейсу. Следовательно и sing-box стал уязвим.
С точки зрения практического примера вспоминаем операцию “Телеграм 2018” когда бан был именно по пулам IP инфраструктурных гигантов, тогда РКН неожиданно для себя уяснил неприемлимый размер сопуствующего вреда при такой стратегии.
Прямо сейчас, в текущую минуту мы имеем заблокированными гораздо больший объем ресурсов и адресов на постоянку, чем то, что было заблокировано случайно тогда. Подумайте об этом, когда рассуждаете о приемлемом размере сопутствующего вреда.
Потому что этой уязвимости подвержены все vless клиенты, но Happ сделал отдельную огроменную дыру. Причем последствия от ее эксплуатации значительно превосходят основную, которая описывается в статье.
Причем тут VpnService? Xray (по крайней мере раньше) не умел принимать трафик на TUN интерфейс. Единственным способом зароутить туда трафик был tun2socks.
Это справедливо и для Andoroid и для iOS (и даже для Windows)
Можно
Для тех кто использует маршрутизацию на основе баз maxmind - IP адреса озона бьются там как ЮАР.
Ну если нет желания или возможности возиться с кодом и публиковать его (что было бы замечательно, как по мне), то можно сделать пустой репозиторий, закинуть туда лицензию, ридми со ссылкой на сайт, а в релизы просто публиковать готовые бинарники.
Вы же можете к релизу приаттачить что угодно.
Предлагаю публиковать релизы на гитхабе. Его, может быть, тоже заблокируют когда-то, но урон от этого будет столь значителен, что недоступностью свежего билда wiresock можно будет пренебречь.
(мечтательно) А вот если бы хотя бы с кодом UI…
https://github.com/2dust/v2rayNG/issues/5457
В том, что клиенты буквально приходят к ним за этим. Чтобы cloudflare расшифровал их трафик и закешировал его. Или что-бы какой-нибудь js challenge ботам встроил. Без терминации TLS это попросту невозможно.
Большинство еще и добровольно платит за это, представляете?
Если вам не нужно кеширование/js challenge/waf, а готовы ограничиться только L3/L4 ddos защитой, то вы можете воспользоваться Cloudflare Spectrum. Тогда ничего терминироваться не будет.
То есть они не прячут это где-то в соглашении, они явно и открыто продают именно такую услугу (и весьма успешно, надо сказать)
С одной стороны да, к их функциональности прямо это не относится. С другой - они массово распространены и это их сфера интересов.
В конце концов это и реклама бесплатная (если ханипот что-то обнаружит) и снижение вероятности, что их вообще будут сканировать (что бы не нарваться на этот самый ханипот)
Идея не плохая, но ханипоты в идеале должны реализовывать разработчики клиентов.
Да я обязательно написал бы, если бы такие были бы…
Я упоминал клиенты на базе sing-box, которые безопасны если не указать mixed inbound. Но потом пришел @ValdikSS и упомянул про прямое обращение к интерфейсу. Следовательно и sing-box стал уязвим.
Прямо сейчас, в текущую минуту мы имеем заблокированными гораздо больший объем ресурсов и адресов на постоянку, чем то, что было заблокировано случайно тогда. Подумайте об этом, когда рассуждаете о приемлемом размере сопутствующего вреда.
Наверное он просто не хочет делать клон xray.
Потому что этой уязвимости подвержены все vless клиенты, но Happ сделал отдельную огроменную дыру. Причем последствия от ее эксплуатации значительно превосходят основную, которая описывается в статье.
Причем тут VpnService? Xray (по крайней мере раньше) не умел принимать трафик на TUN интерфейс. Единственным способом зароутить туда трафик был tun2socks.
Это справедливо и для Andoroid и для iOS (и даже для Windows)
Если у вас настроен per-app split tunneling или ру приложения в knox, то они не будут маршрутизироваться в прокси вообще.
Слепая вера в какие-то волшебные sandbox’ы эппла ни к чему хорошему не приведет.
Apple точно так же уязвим, в том числе к атаке на Happ.
Поставьте, к примеру, libterm и попробуйте
Вообще вокруг iOS очень много сказок.
Что вы ждете от бота с нейрослопным комментарием? Он не читал даже, просто скопировал вывод клода как есть.
Ну виден им факт и что это дает? Заблокировать они его все равно не смогут.
Я не заметил часть про пароль. Да, с паролем не найдет, конечно.
Который совершенно бессилен перед простой блокировкой ip адресов.
Это недоработка POC (он не всегда находит порт), а не защита.