В школах начались каникулы, количество статей и обзоров решений по обходу блокировок и эксплуатации белых списков увеличилось вдвое. А мне уже надоели обсуждения механизмов обхода блокировок и шум в чатах и группах про блокировки, баны, переборы IP, белые списки и так далее — и я решил обсудить не «как сделать чтобы», а «почему то о чем говорят не сработает».
А есть и еще один вопрос — предположим, вы администратор какого‑либо сервиса, внесенного в белые списки. Или даже специалист по ИБ. И всё бы хорошо — но среди ваших коллег много несколько странных эмоционально неустойчивых личностей без развитого чувства самосохранения и не читавших правила пользования сетевыми ресурсами компании — и вы подозреваете, что эти одаренные создания учудят чего‑нибудь, что делать не следует.
Давайте обсудим — какие механизмы обхода, когда, почему и как перестанут работать? Почему белые списки неизбежны, почему они страшнее чем их описывают, и от чего они (не)помогут? Как можно поймать замаскированный ВПН?
Спойлер: большая часть того что сейчас распространяется и обсуждается в среде киберсопротивленцев средней школы, нетехнических специалистов и далеких от темы людей — это палиативные симптоматические решения. Они отвалятся или сломаются в ближайшем будущем. Всё сильно хуже. И сильно лучше.
Статья написана без привлечения AI
Начинаем разбор
Блокировка доступа в интеренет по белым спискам? Обыкновенная административна�� и техническая задача. И процесс блокировки выглядит как работа с любой задачей - определение проблемы, разработка модели обнаружения, реализация блокировки. И, как и при решении любой задачи, есть несколько критериев оценки решения (механизма блокировки)
ресурсозатратность (насколько много дополнительных ресурсов потребует техническое решение в случае реализации)
скорость внедрения - насколько сложно включить соответствующий механизм; например, нужен ли ему какой-то набор данных которые будут использоваться и насколько сложно эти данные собрать и привести к эффективно используемому формату
количество ложноположительных и ложнноотрицательных срабатываний - несколько часто механизм ошибается
Сейчас большинство споров ведется вокруг нескольких тем
Как будут реализованы «белые списки»
Как обмануть DPI
Как получить IP из «белых списков»
И, значит, рассматриваем указанные вопросы. Вот только рассматривать их мы будем скорее как «плохие герои». И начнем со среднего вопроса.
Можно ли обмануть DPI
DPI-системы научились понимать практически все ухищрения, вводимые клиентом на сетевом уровне - фрагментации, реордеринги и прочее, и последним убежищем осталось использования мифических "неблокируемых" имен - клиент эмулирует SNI с широкоизвестным привилегированным ресурсом, надеясь что DPI его сессию не заблокирует
Эта методика имеет одно слабое место (не)соответствие доменного имени IP-адресу, и это и будет использовано в конечном итоге. DPI-системы просто будут иметь регулярно обновляющийся список "привилегированных" доменных имен и IP-адресов им сопоставленных. Будут организованы два списка
доверенные доменные имена и сопоставленные им IP (автоматически обновляемый)
доверенные сети - обновляемый по заявке от "системно-значимых компаний"
Если доменное имя и адрес попадают в первый список - разрешаем. Если адрес источника или получателя во втором списке - разрешаем. Иначе - блокируем. Просто, быстро, эффективно. Будет ли введено? Да, неизбежно. Но не сразу.
Реализация белых списков
Наиболее эффективный механизм реализации белых списков - на сетевом уровне. Да-да, та самая "блокировка по IP". И именно этот механизм и будет реализован в конечном итоге, потому что он, в полном соответствии с критериями, максимально эффективен - очень малозатратен по ресурсам, характеризуется околонулевыми ложноположительными и ложноотрицательными срабатываниями. Вопрос остается только в скорости внедрения и легкости поддержки.
Для реализации этой модели необходимо просто собрать диапазоны адресов на которые трафик будет беспрепятственно пропускаться. Лучше всего эта задача решается административно: сервисам и компаниям направляется запрос "а перечислите ваши сети и IP-адреса", после чего полученные адреса включаются в белые списки.
Все включенные в белые списки сервисы имеют российскую юрисдикцию и подчиняются российскому регулятору. Регулятор (Роскомнадзор) может спокойно запросить такую информацию в любой момент, и получить моментальный ответ
Единственный вопрос - что делать облакам, у которых динамическая выдача ресурсов и в которые могут приземляться такие "системно-важные сервисы". Ответ на этот вопрос "на поверхности": компании-провайдеры облачных услуг и хостинга просто выделят диапазоны, которые будут переданы для включения в белые списки, и зафиксируют обязательства не выдавать IP-адреса из этих привилегированных диапазонов никому кроме компаний, чьи сервисы включены в белые списки. А компании-клиенты подпишут обязательство не использовать адреса выданные им для сервисов, не включенных в системно-значимые.
И, как только (не если - а когда!) такой механизм заработает, обойти ее станет невозможно без организации альтернативных (нерегулируемых, необозреваемых, не покрытых регулятором) каналов связи.
Единственный способ обойти блокировки с использованием механизма белых списков - попасть в этот белый список.
Именно по этому сейчас наблюдается ажиотаж вокруг крупных российских облаков — пользователи надеются, что им удастся получить IP‑адрес из диапазона, внесенного в те самые белые списки. Чаты поддержки бурлят от обсуждений «как получить IP из белого списка, а если перебором, а если еще как‑то», пользователи прибегают в чаты с жалобами «я всего лишь 10 адресов попробовал перебрать и меня заблокировали» и так далее
Но вопрос не в этом, вопрос ведь в другом:
А что будет если я/мы получим IP из белых списков?
А ничего хорошего. Но ведь вы хотите задать вопрос, и вопрос этот: «А пусть сначала меня вычислят!», верно? Определят. Вычислят.
Направление имеет значение
Сервисы, они на то и сервисы, что в большинстве случаев они активно принимают входящие соединения - и намного реже устанавливают исходящие. Вывод:
Тривальный рейтлимитер на количество исходящих соединений решает задачу фильтрации развернутых прокси, поэтому прокси на белых списках умрут — равно как и все решения, у которых число входящих соединений примерно равно числу исходящих.
Всё отфильтруют статистически. Воркэраунд — мультиплексирующие механики (заворачивание множества клиентских соединений в одно долгоживущее). Примеры — SSH‑туннель, классические полноценные VPN.
Но когда вам удалось обмануть первый механизм, наступает время второго
Никто не смог обмануть математику
Итак, вы получили легендарный имбовый экип IP из белых списков и подняли на нем релей. Прокси, VPN, туннель - не имеет значения, потому что против вас начинает работать математический паттерн:
Прокси/ VPN / туннельные узлы отличает сбалансированность входящего и исходящего трафика - их объемы примерно равны
Всё, что надо сделать регулятору - для IP из "белого списка" провести соответствующий анализ и направить информацию провайдеру (можно в форме предупреждения).
Вам не поможет компрессия - основные объемы трафика (видео и аудио) уже сжаты, поэтому статистика на графиках продолжит показывать ту же картину - In и Out примерно равны. Не верите? Просто зайдите в админку хостера и посмотрите трафик по своему "тайному" ВПН - он же светится как новогодняя елка в статистике.
Способов замаскировать эту аномалию не так много, а из реальных так вообще ровно один: надо создать достаточно значимый нетранзитный поток на вашу транзитную ноду, чтобы In и Out стали существенно различны. И кстати, во избежание проблем с законом - это не должен быть какой-то шум, потому что это в общем то может быть расценено как попытка вмешаться и помешать работе средств сетевой безопасности. Это должен быть нормальный пейлоад.
А когда вы с этим справились, то... Есть и другие механизмы которые привлекут к вам внимание
Когда друг оказался вдруг
Давайте вернемся к такой «интереснейшей» теме как найденный не так давно вопрос обращения некоего мессенджера на иностранные сервисы проверки IP. Этот вроде бы не особо опасный механизм, на самом деле, позволял обнаружить факт обхода ограничений, когда трафик на зарубежные ресурсы направлялся черз VPN, а на внутрироссийские — без VPN. Отличная схема, но точка выхода VPN становилась видна владельцам мессенджера.
Строить предположения о судьбе этих данных тут я не буду, но гипотетически, если эти данные передать регулятору, то он мог бы просто заблокировать на сетевом уровне IP‑адреса засвеченные как в списке точек выхода, и часть VPN отвалилась бы — просто потому что клиенты к ним больше не смогли бы подключиться из‑за блокировки по IP (а ее нельзя обойти, мы это помним из начала статьи, верно?)
И даже если вы используете двухзвеный ВПН: когда точка входа и точка выхода разные хосты, то блокировка точки выхода по IP приведет к потере связности точек входа и выхода, и к бесполезности такого VPN. Избегнуть такого обнаружения можно только через введение трехзвенной схемы, когда точка входа и точка выхода связываются через транзитную точку.
И нет, просто «не буду ставить XXX» или «не буду YYY запускать через VPN» вам не поможет. Можно например на сайт в рекламный блок добавить обращение к какому‑нибудь https://e‑data‑commerce.com который развернут в достоверно заблокированном облаке, и если запрос успешно отработал — ура, вашу точку выхода пометили.
Защититься от этого уже достаточно сложно — если, конечно, и браузер будете без туннеля / прокси / VPN не запускать. Но такая жизнь — это не жизнь, а существование.
Всё давно началось
Но самое главное, что система обладает огромными административными ресурсами.
Регулятор может запросить от компании любую информацию — например, о назначении каждого IP из белого списка, который заявила компания. И когда в этом списке появится ваш ВПН, вопросы возникнут очень быстро.
И это уже началось. У меня нет информации о передаче информации о пользователях в Роскомнадзор — хотя это весьма вероятно, но вот закручивание гаек хостерами и провайдерами внутри РФ идет полным ходом. Провайдеры перетряхнут списки потребителей IP из внесенного в белый список диапазона и начнется сезон «зачистки». Хотя тут я немного обманул — сезон зачистки во всю идет.
Резюме
А какие выводы? Не знаю.
Гадать о причинах этих блокировок мне не интересно — но повторения событий налета на аэродромы, аэропорты, или энергообъекты, школы, больницы и общественные мероприятия в духе того, как это устроили в прошлом году спецслужбы Украины, мне бы не хотелось. Белые списки позволяют в теории от такого сценария закрыться, как минимум частично — дрон с управлением через интернет и дрон без связи с задавленой навигацией представляют СОВЕРШЕННО разный уровень угрозы.
Самое важное — не рассчитывайте на IP из белого списка. Вас туда не записано, и если даже вам повезло, то скоро вас заметят. Не эксплуатируйте их если вы туда попали случайно. И уж особенно не используйте для обхода блокировок. Это для развертывания своего сервиса! Вот если у вас есть личный сервис на зарубежном хостинге и вам нужен туда туннель — вот тогда да, еще приемлемо.
Используйте WiFi и проводное подключение к провайдеру — белые списки (официально) планируются как промежуточное решение чтобы не убить сервисы во время блокировок.Если у вас магазинчик с кассами, кофе‑забегаловка, маленький офис — провод, WiFi, никаких 4G‑модемов. Да, неудобно — зато на порядок более надежно.
И еще — впереди майские праздники. Белые списки будут активно включаться. Это будет не самая простая весна для всех, кто завязан на Интернет. По итогам ограничений на майские праздники будет сделано много выводов и многие попадут под раздачу. Проанализируйте то, о чем написано в статье, сделайте выводы, не нарушайте законодательство, не подставляйте себя и свои�� близких.
И всех с весной. Радуемся Солнцу.