В Китае запустили первую в мире коммерческую оптоволоконную систему, которая работает сразу в трёх диапазонах длин волн: S, C и L. Обычные магистрали задействуют преимущественно C-диапазон, поэтому одновременное использование трёх окон прозрачности сразу расширяет доступную полосу.
Вторая составляющая решения это четырёхъядерное волокно. В одном физическом волокне проложены четыре световедущих ядра, и по каждому идёт свой поток данных. Пространственное разделение каналов внутри одного кабеля умножает ёмкость без прокладки дополнительных линий.
По данным разработчиков, пропускная способность одного ядра выросла почти на 50 процентов, а суммарная ёмкость системы превышает показатели обычного одномодового оптоволокна более чем в пять раз.
Ключевой момент в том, что испытания прошли не в лаборатории, а на действующей линии длиной 35 километров. Она соединила вычислительные центры в Циндао провинции Шаньдун, то есть режим эксплуатации был близок к реальной нагрузке между дата-центрами.
Для задач машинного обучения пропускная способность межсоединений имеет прямое значение. Крупные модели обучают на кластерах из тысяч ускорителей, и скорость обмена между узлами и между дата-центрами часто становится узким местом. Более широкий канал снижает простои дорогого железа.
Если технологию удастся масштабировать, операторы и облачные провайдеры смогут поднять пропускную способность на уже проложенных трассах. Это дешевле и быстрее, чем строить новые линии с нуля.
Теперь можно отслеживать стабильность работы сайтов, серверов и приложений, размещенных в нашей инфраструктуре или на сторонних платформах.
Если что-то пойдет не так, вы сразу получите уведомление на почту, в Телеграм или Макс. О восстановлении — тоже.
Что можно мониторить:
Сайты и веб-приложения. Интернет-магазин упал ночью — узнаете сразу, а не утром по потерянным заказам.
Доступность серверов. Сервер перестал отвечать на запросы — среагируете до того, как это заметят остальные.
TCP-порты сервисов — базы данных, почта, API. База перестала отвечать — увидите до того, как приложение начнет спамить юзеров ошибками.
SSL-сертификаты. Продлите сертификат заранее — пока пользователи не заметили в браузере предупреждение о небезопасном соединении.
Проверки идут из нескольких регионов — без ложных алертов из-за временных сетевых сбоев.
Бонусом: история инцидентов по каждому сервису, дашборд с аптаймом, настройка интервала и таймаута, пауза без потери настроек. Подробнее в документации →
Стоимость — 30 ₽ в месяц за сервис, списания почасовые.
Собрал клиент AmneziaVPN для Ubuntu 22 ...и сделал это через Dockerfile, который Вы можете отредактировать для любого дистрибутива
Зачем понадобилось
Свежие блокировки Роскомнадзора отрезали меня от различных VPN, которыми я периодически пользовался для доступа к зарубежным продуктам, официально в РФ не представленным. Например, к Gemini.
Моей последней надеждой стала self-hosted Амнезия. Я восстановил доступ на всех своих устройствах, кроме одного - домашнего ПК под GPU-вычисления, работающего на Ubuntu 22.04.
Последние версии клиента AmneziaVPN 22-ю убунту не поддерживают: релизы для Linux собираются на Ubuntu 24.04, поэтому есть ограничения в поддержке дистрибутивов из-за версии glibc.
Как это может помочь другим
22-я убунта - это всего лишь пример. Если Ваши вкусы специфичны, да настолько, что AmneziaVPN не работает на выбранном дистрибутиве, докерфайл с лёгкостью можно адаптировать. Единственная дистрибутиво-зависимая часть в докерфайле - вызов apt-get
Что сделано
Я подготовил докерфайл, который из чистого образа ubuntu:22.04 устанавливает Qt и все прочие зависимости, качает репозиторий клиента AmneziaVPN, собирает проект и готовит инсталлятор. Выходная сборка, for my best knowledge, аналогична релизам авторов проекта. Вот здесь PR в официальный репозиторий со всеми объяснениями.
Я писал докерфайл в личных целях, мог что-то не учесть, открыт к критике и предложениям.
Как воспользоваться
Подготовка
Докерфайл качает официальный Qt-инсталлятор (я работал по инструкции вот здесь), поэтому потребуются активный Qt-аккаунт и IP-адрес не из РФ. Qt запрещает скачивания по российским IP-адресам. Нужно либо включить VPN, либо собирать на хостинге за пределами РФ (например, Казахстан). Да, я знаю, что это недостаток - пока не придумал, что с этим делать.
По умолчанию инсталлятор Qt смотрит на учётные данные в файле $HOME/.local/share/Qt/qtaccount.ini. Этот файл прокидывается в докер, поэтому он должен быть на машине для сборки. Если этого файла нет, можно перед запуском докера скачать любой GUI/CLI установщик Qt и пройти в нём страницу логина. Если не хочется возиться с инициализацией аккаунта на машине, то я оставил лазейку по прямой передаче логопасса в докер.
Сборка
Скачать мой форк репозитория, перейти в папку с ним и запустить докер.
Голландская полиция совместно с NCSC-NL отключила прокси-ботнет из 17 миллионов устройств. Это одна из крупнейших операций по выводу из строя вредоносной инфраструктуры.
Перехват C2. Следователи получили наводку и выяснили, что более 200 управляющих серверов физически размещены у местного нидерландского хостинг-провайдера. Вместо блокировок на уровне DNS полиция просто арестовала сами серверы, физически отключив командную инфраструктуру.
Инфраструктура оказалась связана с сервисом Asocks, который продавал доступ к миллионам IP-адресов. Через зараженные устройства злоумышленники прогоняли спам, фишинг, организовывали DDoS-атаки и обходили антифрод-системы банков и маркетплейсов.
Зараженные устройства. В сеть массово угоняли роутеры, IoT-камеры, смартфоны и ПК. География огромная — затронуто 163 страны. Вредонос превращал их в резидентские прокси. Устройства работали как скрытые exit-узлы, обеспечивая преступникам анонимность в сети.
Вы попали в следующую ситуацию: граница, проверка, оператор просит разблокировать телефон. Отказаться нельзя или невыгодно. Что можно?
Стандартные ответы у мессенджеров слабые. Обычный app-lock PIN открывает то же приложение, под принуждением бесполезен. «Удалить аккаунт по PIN» лучше, но видно что что-то стёрто. Облачные TTL текущий запрос не закрывают.
В RCQ сделали по-другому. Локальная история шифруется AES-256-GCM, ключ выводится из PIN’а через PBKDF2-HMAC-SHA256 на 400к раундов с per-install salt в keychain. Разные PIN’ы открывают разные хранилища.
400к раундов это около секунды CPU на iPhone, достаточно медленно чтобы offline-bruteforce был дорогой. Но реальная защита это длина PIN’а: 4-значный перебирается за десятки минут на M-чипе, 8-значный за месяцы. Default 6-8 символов.
Четыре режима
Real PIN - открывает реальный аккаунт.
Decoy PIN - открывает отдельный аккаунт с собственным UIN и SQLite. Не пустой экран (пустой это сигнал), а правдоподобно освоенный: пара контактов, несколько сообщений.
Wipe PIN - тихо стирает оба SQLite, чистит keychain, дёргает DELETE /auth/account. Без подтверждений и прогресс-баров. Через 3 секунды приложение перезапускается как свежеустановленное.
Biometric - опциональная вторая дверь к real. Не совмещается с decoy/wipe (скорее для удобства).
Честно про границы
Защищает от: казуального осмотра, принуждённой разблокировки, ситуации «5 секунд до того как заберут».
Не защищает от: forensic-лаб с offline-bruteforce’ом короткого PIN’а, jailbroken устройства с активным debugger’ом, человека рядом который видел как вы вводите PIN (разумеется).
Threat model правильный: «есть несколько секунд до того как кто-то откроет приложение, дальше я не контролирую устройство». Для «forensic с неограниченным временем» нужны другие инструменты. Главное из них: не пользоваться телефоном для чувствительных переписок вообще.
Стек живёт в RCQ, открытая бета на iOS. Код открытый: github.com/rcq-messenger/rcq-ios. Про маскировку самого факта установки приложения будет отдельно.
YouTube начал требовать отключить средства обхода блокировок для просмотра видео. Ограничение касается каналов с жёсткими региональными правами на контент: в первую очередь спортивных — «Формула 1», некоторые футбольные лиги, отдельные музыкальные лейблы. Это каналы, где рекламодатели платят за показы в конкретных странах, а правообладатели продают лицензии по регионам. YouTube обязан контролировать, из какой страны смотрит зритель, — иначе нарушаются условия лицензий.
Для обычных видео — летсплеев, обзоров, подкастов, авторского контента — ничего не изменилось. Средства обхода блокировок работают как прежде. Явление касается единичных каналов с крупными медиапартнёрами и существует уже не первый год — просто периодически всплывает у новых пользователей и вызывает волну тревоги.
Прятать данные в TLS-трафике: как выглядит настоящий стелс
Больше 70% интернет-трафика — зашифрованный TLS. Это не баг, это фича: тонны HTTPS-соединений, WebSocket-потоков, мобильных приложений и игровых клиентов создают идеальный фон для передачи данных без привлечения внимания.
Идея простая: если нужно спрятать дерево, прячь его в лесу. В случае интернета этот лес состоит из миллионов TCP/443-соединений, которые выглядят настолько обычно, что именно это делает их интересной средой для экспериментов.
Почему TLS-трафик — удобная маскировка
TLS скрывает содержимое пакетов. DPI может видеть метаданные — размер, timing, SNI в Client Hello, но не payload. Если ваше соединение выглядит как обычный HTTPS-запрос или долгоживущий WebSocket, оно сливается с фоном.
Практическая сторона: можно передавать данные внутри легитимных TLS-сессий, используя существующие протоколы как транспорт. Это не новая идея — стеганография в сетевых протоколах обсуждается десятилетиями, но TLS даёт дополнительный слой: шифрование на уровне протокола скрывает структуру payload от внешнего наблюдателя.
Где это может быть полезно
Обход блокировок в странах с жёстким DPI — если трафик неотличим от обычного HTTPS, его сложнее фильтровать
Распределённое хранилище данных в трафике — архивные данные можно держать не на диске, а в виде пакетов, циркулирующих между нодами
Covert channels для исследований в области безопасности — тестирование систем мониторинга и обнаружения аномалий
Технические ограничения и риски
Главное ограничение — timing и packet size analysis. Если трафик выглядит нетипично по объёму или интервалам, статистические методы могут его вычислить. Traffic shaping помогает, но не решает проблему полностью.
Второе — легитимность. Если используешь чужую инфраструктуру или протоколы без согласия провайдера, это может нарушать ToS. В корпоративной среде такие эксперименты быстро привлекут внимание security-команды.
Третье — надёжность. Пакеты теряются, соединения рвутся, данные нужно восстанавливать. Без механизмов коррекции ошибок и redundancy хранилище в трафике превращается в лотерею.
В итоге: технически возможно, но требует продуманной архитектуры, понимания сетевых протоколов и готовности к тому, что решение будет хрупким. Как proof-of-concept — интересно. Как production-инструмент — сомнительно.
Передача параметров ssh с помощью суффиксов имени хоста
В случае, если доступ к определённым хостам по протоколу SSH требует запуска ssh с кучей параметров, стандартной рекомендацией является внесение всех этих параметров в отдельную секцию Host файла конфигурации ssh, пример которой приведён ниже. Данные параметры подробно описаны в ssh_config(5).
Host tproxy
Hostname srv-10-79.dmz.company.com
User srv_user
Port 36602
DynamicForward 127.10.0.79:1080
LocalForward 127.10.0.79:4445 127.0.0.1:445
LocalForward 127.10.0.79:8080 127.0.0.1:8080
У этой рекомендации есть один существенный недостаток — она не обеспечивает модульность конфигурации и вынуждает дублировать информацию. В случае, если требуется обеспечить подключение к тому же серверу из интернета через NAT или через SSH-прокси, или без SOCKS5-прокси и переадресации портов, причём во всех возможных комбинациях:
изнутри с переадресацией портов,
изнутри без переадресации портов,
снаружи с перадресацией портов,
снаружи без переадресации портов,
для данного сервера придётся добавить ещё три секции Host, часть сведений в которых будет дублироваться. Если же компания подключилась к двум провайдерам и сэкономила на маршрутизации BGP, понадобятся уже шесть частично дублирующих друг друга секций Host. Дублирования сведений, как известно, желательно избегать, и для этого следует каким-либо образом доработать исходную рекомендацию.
Сущность предлагаемой доработки
Мною были перепробованы различные варианты доработки исходной рекомендации и, в итоге, был найден достаточно простой способ, заключающийся в разбиении конфигурации на отдельные секции в зависимости от суффиксов, добавляемых к имени хоста, передаваемого в качестве параметра команде ssh. Для отделения суффиксов от имени хоста и друг от друга оптимально использовать символ-разделитель "+" (плюс). Этот символ не используется в именах DNS, а также интуитивно понятнее любых других, указывая на то, что суффикс что-то добавляет к исходной конфигурации хоста. Распознавание добавляемых суффиксов следует производить с помощью команды Match originalhost с шаблоном суффикса.
В случае, если суффикс должен добавлять параметры, специфичные для определённого хоста, например, его реальное имя DNS, или параметры переадресации портов, в которых фигурирует адрес локального сокета, индивидуальный для каждого из хостов, команда Match должна будет содержать два аргумента originalhost: один — с шаблоном имени хоста, и второй — с шаблоном суффикса. Пример:
Match originalhost "tproxy+*" originalhost "*+rtk,*+rtk+*"
# Подключение через РостелеТелеком (NAT)
Hostname srv-10-79.rtk.company.com
Match originalhost "tproxy+*" originalhost "*+yota,*+yota+*"
# Подключение через Yota
ProxyJump gate-10-1+yota
Match originalhost "tproxy+*" originalhost "*+fwd,*+fwd+*"
DynamicForward 127.10.0.79:1080
LocalForward 127.10.0.79:4445 127.0.0.1:445
LocalForward 127.10.0.79:8080 127.0.0.1:8080
За секциями, специфичными для хоста с указанием суффиксов, в обязательном порядке должна следовать секция для этого же хоста с параметрами по умолчанию. Прежде всего эта секция нужна для того, чтобы заменить переданное ssh имя хоста его именем DNS, если добавленные к имени хоста суффиксы не ссылались на секцию Match, содержащую команду Hostname. Также в этой секции следует указывать параметры ssh, одинаковые для всех возможных способов подключения, например: имя пользователя, номер порта, используемые алгоритмы шифрования, типы ключей, и так далее. Для секции Match хоста по умолчанию достаточно одного аргумента originalhost. Пример:
Match originalhost "tproxy,tproxy+*"
Hostname srv-10-79.dmz.company.com
User srv_user
Port 36602
В случае, если добавляемые суффиксом параметры не содержат специфических для хостов аргументов, в команде Match достаточно указать один аргумент originalhost с шаблоном суффикса. Такие секции следует располагать в самом конце файла настроек ssh.
Match originalhost "*+rsa,*+rsa+*"
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
Виртуальные бои с взаимной блокировкой сайтов и сервисов перешли в реальный мир. Евросоюз изучает возможность проложить оптические магистрали в Азию через Арктику. Почему не хватило текущей надёжности Интернета, который разрабатывался как сеть, способная сохранить работоспособность после ядерной войны?
Азия и Ближний восток: риски и возможности
Вместо локальной системы связи для одной страны Интернет стал глобальной сетью. При этом магистральные каналы прокладывались не равномерно, а там, где удобно. В результате оказалось, что большая часть магистральных каналов между Европейским союзом и Китаем, Индией и другими важными партнёрами из Юго-Восточной Азии проложена через Россию или Ближний Восток.
В 2024 году в Красном море Йемен повредил четыре подводных кабеля в Красном море. А уже в этом году Иран угрожал блокировать не только Ормузский пролив, но и интернет-каналы, проходящие у его берегов. Так как долговременное примирение геополитических противников никто не гарантирует, ЕС задумался над прокладкой кабелей через арктический регион.
Трафик через полюс
У Европы два варианта прокладки интернет-кабелей — через Северо-Западный проход. Аналог Северного морского пути в обход Канады и Аляски по Северному Ледовитому океану. Однако придётся решать вопросы работы в сложных ледовых условиях. Есть опыт многомесячных перерывов в ремонте интернет-магистралей, находящихся в подобных условиях. Альтернатива — не проще: проложить кабели непосредственно через Северный полюс.
Кажется, что в таких условиях получат новые возможности спутниковые сервисы связи. Однако в текущей ситуации захочет ли Европа зависеть от американских компаний? А OneWeb вряд ли потянет полноценную связь регионов. Часть коммерческой нагрузки может взять на себя сервис спутниковой связи IRIS, основное назначение которого — связь для европейских госструктур и силовиков.
В любом случае реализация обхода через Арктику намечена к 2030 году. За 5 лет может ещё всё измениться.
ИТ-компаниям приходится учитывать не только требования локальных регуляторов, но и геополитику, чтобы готовиться к сложностям с доступностью электронных компонентов и каналов связи. К сожалению, на это уходят ресурсы, и приходится прикладывать дополнительные усилия, чтобы это не сказывалось на пользователях.
Дела становятся еще детектнее, а запуск новой версии PT NAD 13.0 — еще ближе ☄️
Уже 4 июня, ровно в 14:00, команда системы поведенческого анализа сетевого трафика от Positive Technologies — PT NAD — прольет свет на каждый темный уголок вашей инфраструктуры в новом сезоне «Очень детектных дел» (отсылка не случайна).
В этот день вы сможете вместе с нами узнать, как поменяют правила игры:
автоматизированное реагирование;
облачное детектирование;
архивное хранение метаданных.
Чтобы точно все это успеть, вот чек-лист ваших действий прямо сейчас:
Опубликовали программу infra.conf'26 — большой конференции про инфраструктуру и высоконагруженные сервисы
Команда Yandex Infrastructure открыла полную программу infra.conf 2026, которая состоится 4 июня в Москве и онлайн. Фокус конференции этого года — построение и особенности эксплуатации инфраструктуры в эпоху ML.
В трёх треках программы обсудим не только ML‑инфраструктуру, но и базы данных, стораджи, инструменты разработки, observability‑решения, SRE и эксплуатацию и управление трафиком.
Среди докладов от инженеров и разработчиков Яндекса, Сбера, X5 Tech, Wildberries & Russ и других компаний нас ждут темы:
«Как появилась Алиса AI: путь одной LLM» (Аркадий Альшан, Яндекс)
«ML‑платформы для больших компаний» (Антон Алексеев, AvitoTech)
«Как мы построили два больших GPU‑кластера на Kubernetes» (Иван Юмашев, Ozon)
«Два подхода к надёжности распределённых систем» (Евгений Дюков, Yandex Cloud)
«ИИ‑агенты для MLOps‑инфраструктуры» (Марк Кузнецов, Альфа‑банк)
«Особенности observability LLM‑приложений и агентов» (Даниэль Халиулин, Yandex Infrastructure)
Также участникам будут доступны мастер‑классы и выставочная зона инженерных команд.
Infra.conf'26 пройдёт 4 июня в Москве в пространстве TAU. Для участия нужно зарегистрироваться и дождаться приглашения. Также посмотреть доклады в прямом эфире можно будет на сайте конференции.
Представлен сервис «taken.» который позволяет оценить, какую информацию о вас знают сайты в интернете. Спойлер: они знают буквально всё — от вашего местоположения до точных настроек системы, заряда батареи и даже установленных шрифтов.
dpi-checkers — open-source инструмент от hyperion-cs — показывает, каким именно методом ваш провайдер режет трафик: RST после 16-го пакета, SNI-дроп или CIDR-вайтлист. Прогнал на трёх подключениях — картина неожиданная.
Пользователи рунета давно заметили: «интернет дома» и «интернет у бабушки в области» — это два разных интернета. YouTube грузится на одном провайдере и не грузится на другом. Discord висит на мобильном, но работает на проводе того же оператора. Это не случайность и не деградация сети — за каждым таким симптомом стоит конкретный технический механизм на L4/L7.
Набор тестов dpi-checkers (часть на Go как CLI-утилита, часть в браузере на JS) позволяет идентифицировать метод фильтрации, который применяет конкретный ISP. Я прогнал проверки на трёх подключениях: домашнем у федерального провайдера, мобильном у одного из «большой четвёрки» и через знакомого в другом регионе.
Пять методов которые реально встречаются в РФ. DPI — не одна технология, а класс решений. Современный Deep Packet Inspection анализирует не только заголовки L3/L4, но и содержимое L7: по особенностям TLS handshake система определяет сервис назначения даже без знания IP и применяет политику — пропустить, сбросить, замедлить. Когда в новостях пишут «провайдер замедляет YouTube» — это упрощение. Технически применяется один из нескольких методов, и симптомы у пользователя разные в зависимости от метода.
CIDR-вайтлисты — блокировка по IP-подсетям. Трафик к адресам вне «доверенного» списка не пропускается. Жёсткий метод, чаще встречается на мобильных тарифах 4G+/5G.
TCP 16-20 (rps-разрыв) — DPI ждёт первые 16–20 пакетов TLS-сессии, детектирует SNI нежелательного хоста и отправляет RST обеим сторонам. Клиент видит «сайт упал», хотя сервер жив. Основной механизм замедления YouTube в 2024–2025.
Подмена DNS-ответов — перехват запроса на уровне провайдера, возврат заглушки или 0.0.0.0. Старый метод, обходится DoH/DoT, но используется как первая ступень.
SNI-блокировка — поле Server Name Indication в TLS handshake передаётся открытым текстом до установки шифрованного канала. DPI читает его и сбрасывает соединение по домену.
QUIC-блокировки — UDP/443 режется целиком или деградирует, чтобы клиент откатился на TCP, где уже работает SNI-фильтрация.
Что показал dpi-checkers на трёх подключениях. Домашний федеральный провайдер — TCP 16-20 в чистом виде: соединение с рядом зарубежных сервисов рвётся ровно после 16–18 пакетов в TLS-сессии, RST приходит от «провайдерского» адреса, не от сервера назначения. Мобильный оператор — комбинация SNI-дропа и QUIC-блокировки: UDP/443 не проходит вообще, TCP-соединение с теми же хостами рвётся по SNI до завершения handshake. Региональный провайдер через знакомого — DNS-подмена как первая ступень плюс CIDR-ограничения на часть подсетей Cloudflare.
Исследования Citizen Lab и проект net4people фиксируют схожие паттерны по всему рунету — методы стандартизированы, оборудование у операторов в основном одно и то же (ТСПУ от Эшелона и аналоги). Различия между провайдерами — в настройке порогов и в том, какие именно списки им спустили.
Для меня как человека, который строит корпоративные сети, это не абстрактный research. Когда у сотрудника «не работает» корпоративный сервис — первый вопрос теперь не «а VPN включён?», а «какой метод фильтрации у его провайдера?». TCP RST лечится иначе, чем DNS-подмена, и иначе, чем QUIC-блок. dpi-checkers даёт ответ за пять минут вместо часа диагностики вслепую.
Как определить свой внешний IP когда действуют белые списки Минцифры
Когда Министерство цифровой деградации России начинает ограничивать Интернет по своим белым спискам, внезапно обнаруживается, что из привычных инструментов не работает ничего. Невозможно зайти ни на один сайт: 2ip.rumyip.ruifconfig.meipify.orgwhatismyipaddress.comwww.whatismyip.comipinfo.io потому что никто из них не занесён в белые списки. Timeweb есть в белых списках, timeweb.com/check-ip страница открывается, но во время работы белых списков все поля пустые. Из поисковых серверов в этот момент доступен только Яндекс, но он тоже ничем не может помочь в данной ситуации, потому что не готов к такому, и предлагает те же самые сайты которые недоступны.
Вспоминаем жизнь до появления поисковых серверов - создаём свои коллекции нужных ссылок вручную.
В момент действия белых списков мне через моего сотового провайдера «Мегафон» (физически я нахожусь в СПб или Ленобласти) доступен очень ограниченный перечень сайтов. Возможно, что в том месте где Вы находитесь белый список будет другим. Просмотрев вручную всё что мне доступно по состоянию на 7 мая 2026 нашёл всего две ссылки которые показывают мой IP адрес: Яндекс Интернетометр yandex.ru/internet и Reg.ru reg.ru/web-tools/myip В Интернетометре Яндекса можно ещё и скорость померить. Из сервисов whois рабочий нашёл только один nic.ru/whois Разумеется, не надо заходить на эти ресурсы через свою выходную ноду VPN. Также, в момент когда действуют белые списки, возможно ещё и замедление скорости доступа даже к тому что разрешено. Привычный дизайн сайтов может быть нарушен, из-за того, что внешние ресурсы подгружаемые сайтом недоступны во время работы белых списков.
IP адрес который выдал Вашему устройству сотовый провайдер можно посмотреть на самом устройстве. На Android это вот тут: Settings / About phone / Status / IP Address
Возможны другие варианты. На BlackView BV9800: Settings / System / Advanced / About Phone / IP Address
Во время работы белых списков на смартфоне 100.82.28.67 а внешний IP на сайте Яндекс Интернетометр в это же время показывает 178.178.244.80
100.64.0.0 — 100.127.255.255 (маска подсети 255.192.0.0 или /10). Данная подсеть рекомендована согласно RFC 6598 для использования в качестве адресов для CGN (Carrier-Grade NAT); Вики
PS: Запасайте наличные рубли, во время работы белых списков либо оплата наличными, либо предоплата на сайте. Оплата банковской картой в это время не работает. Видимо эквайринг Сбербанка в белые списки не попал.
Сервис Your IP Security & Privacy Audit проверяет подключение пользователя на предмет утечек, а также на безопасность сетевого соединения. Решение просматривает: IP, утечку гео и WebRTC, DNS, чёрный список IP-адресов, цифровые отпечатки в браузере.
Если вы считаете, что вы обманули белые списки Роскомнадзора с помощью VLESS и прочих квн-чудес, то просто представьте, как всё это держится на Yandex Cloud и VK Cloud за счет того, что они арендуют сервера с диапазонами айпи в белых списках...
На днях решил посмотреть свой IP через VPN и заметил хостинг YANDEX CLOUD или VK LLC. И вот непопулярное мнение с ноткой теории заговора, но я задумался о том, почему ВК и Яндекс вообще допускают диапазоны IP своих VDS (про сервисы не говорим, так как исключения легко можно настроить) и особо не спешат блокировать свои IP, и хочу высказать догадку.
Не видел такой точки зрения, но мне кажется, что ВК и Яндексу выгодно и очень прибыльно хостить сервера, айпи которых в белом списке, так как это тот самый важный элемент для КВН, обходящих белые списки и без точки входа во внешний Интернет, оно бы не заработало.
Представлен открытый проект TapMap, который следит за всеми подключениями на интерактивной карте и показывает, к серверам в каких странах отправляет запросы ПК пользователя.
Проект сканирует приложения, сервисы, страны и порты за последние 30 дней. При этом данные никуда не улетают — всё локально на компьютере.
Представлен открытый проект FMHY Filterlist — это список вредоносных ресурсов и другого сомнительного ПО в сети, где есть фейковые сайты популярных репакеров, торрентов и софта, пиратские сайты, где хоть раз нашли вирусы, а также «серые» ресурсы, сервисы с сомнительной репутацией вроде Avast, McAfee, Tlauncher, 360 Total Security и других. Разработчики проекта постоянно обновляют список угроз. Фильтр уберёт большинство вредоносных сайтов из доступной сети и не даст пользователям перейти на них.
Бесплатный проект email-fake позволяет генерировать одноразовую электронную почту за один клик. Сервис создаёт почтовые ящики, чтобы пользователи могли зарегаться в различных сервисах и получать любые коды доступа без регистрации и получения спама на личную почту.
Разработчики из «Яндекса» спрятали пасхалку на «1984» Оруэлла в коде заглушки с запретом на VPN. Ранее приложения вроде «Яндекс Погода», «Яндекс Пэй» и «Кинопоиск» при попытке их открыть с включённым VPN начали отображать плашку, в которой утверждается, что зайти в приложение с VPN не получится.
Могу ли я, деревенский пенсионер, стать айтишником и писать про интернет на Хабр в 2026 году?
В этом посте хочу поделиться своим опытом: может ли человек без профильного образования, без работы в провинциальном «айти‑парке», да ещё и на пенсии, стать тем самым «деревенским айтишником» и писать полезные вещи на Хабр в 2026 году.
Меня зовут Алекс, я живу в Архангельской области, в обычной деревне, и последние годы занимаюсь тем, что добываю нормальный интернет — себе, соседям и всем, кто приходит с фразой: «Сделай, как у Вани, только чтобы не дорого и не падало».
По профессии я не программист и не сетевой инженер. Всю жизнь работал ближе к «земным» делам, а айти было где‑то поблизости в виде «помоги настроить, починить, провести». Но так получилось, что именно на пенсии я стал тем человеком, который:
подбирает и вешает уличные LTE‑роутеры вроде NR‑712 ;
колдует с антеннами, кабелями и спутниковыми «тазами»;
пишет истории и технические заметки про всё это — сначала «для своих», а теперь и под Хабр.
Пример того, чем я сейчас занимаюсь:
У себя в доме поднял нормальный интернет на базе уличного CPE (NR‑712) и домашнего роутера, чтобы дочка могла учиться, а я — работать с сайтами и сервисами.
Помог соседу Ване вытащить скорость из «одной палки и молитвы», прикрутив к его старой спутниковой тарелке 4G‑облучатель и нормально настроив всю связку.
Параллельно начал вести рубрику «712‑й на связи» — по сути, деревенский новостной дайджест: что происходит в мире связи, ИИ и спутникового интернета, и как это вообще касается нашей реальной жизни за городом.
За последние пару лет я успел наделать кучу ошибок:
покупал «чудо‑антенны», которые обещали 100500 dBi и, конечно, не работали;
связывался с неподходящими операторами и неделями ловил сигнал там, где его физически почти нет;
верил рекламе «поставь эту фишку — будет счастье», пока не понял, что без понимания физики и нормального монтажа никакая интернет фишка не спасёт.
Часть этих ошибок я уже обернул в рассказы и статьи — с примерами, цифрами и честным деревенским юмором. Часть ещё ждёт своего часа.
В дальнейших постах хочу:
продолжать рассказывать живые истории — как мы в деревне боремся за мегабиты, когда вокруг лес и дизель‑генератор;
делиться практикой по уличным LTE‑роутерам, антеннам и бюджетным решениям «для своих»;
иногда смотреть "наверх" — спутниковый интернет и агентный ИИ — и перевoдить всё это на язык «а нам-то, в деревне, что с этого?».
Этим постом я, по сути, знакомлюсь с аудиторией Хабра: я не «сеньор девопс из корпорации», я тот самый человек, который ставит интернет в доме, где оптика закончилась в соседнем райцентре.
Если вам близка тема связи в регионах, бюджетных сетевых решений и «человеческих» рассказов с матчастью — буду рад видеть вас в комментариях и следующих историях.
В начале марта я писал о возможных изменениях с доменами .ru/.рф/.su! Тогда многие сомневались, что это действительно введут. Теперь — уже факт.
Анонимные сайты в России уходят в прошлое. Регистрация доменов .ru/.рф/.su будет возможна только после прохождения идентификации через «Госуслуги».
Новое правило станет обязательным с 1 сентября. Информация уже обновлена на сайте реестра, а владельцам доменов начали приходить уведомления с требованием пройти подтверждение личности. В противном случае домен могут удалить.
Про анонимность, похоже, можно окончательно забыть 😒
Коротко подведу итоги последних обсуждений по вопросам уязвимости средств обхода, как я их понимаю .
Преамбула: Многие популярные средства обхода блокировок открывают порт на localhost, на котором отвечает SOCKS-прокси. Трафик, идущий через этот прокси, отправляется в туннель, который завершается на удалённом сервере, где Интернет не столь ограничен. Для удобства использования уже этот прокси заворачивается в сетевой TUN-интерфейс, что позволяет пускать через него трафик приложений, которые с прокси работать не умеют/не хотят.
Проблема: Как правило, этот SOCKS-прокси не требует авторизации. А потому любое приложение, знающее о существовании открытого порта или TUN-интерфейса, может отправить запрос через него на подконтрольный создателям приложения сервер, и тем самым выяснить, куда именно ведёт обходной туннель. При этом выяснить наличие порта можно простым перебором (localhost обычно быстр), а список сетевых интерфейсов приложение может запросить без особых прав.
Последствия: Это позволяет РКН в перспективе полностью автоматизировать поиск и блокировку индивидуальных средств обхода блокировок, при этом не обрубая зарубежный трафик полностью. С недавних пор все российские ИТ-компании обязаны этому содействовать, блокируя пользователей с обнаруженным туннелем и/или донося на этих пользователей РКН. Любое российское приложение может оказаться стукачом.
Пути решения на Android:
Раздельная маршрутизация по сетевым адресам (например, ru - напрямую, не ru - в туннель) - скорее вредна, чем полезна. Приложение может сделать два запроса к "своим" серверам, один из которых находится за рубежом, получить от них ответы с адресом отправителя, и сравнить. Адреса разные = есть туннель.
"Обычная" раздельная маршрутизация по приложениям - гарантий не даёт. Насколько я понимаю, она просто задаёт сетевой интерфейс, который приложение использует по умолчанию, но не запрещает приложению использовать другие интерфейсы. Также она не мешает сканировать порты в поисках SOCKS-прокси.
Shelter, Knox и тому подобные песочницы - не слишком помогают. Они скроют часто проверяемый флаг TRANSPORT_VPN, но не защитят от перебора портов в поисках SOCKS. Проверяется утилитами вроде RKNHardening.
Включить авторизацию на SOCKS-прокси и ограничить доступ к TUN интерфейсу - пока доступно не везде. Сейчас добавление этой фичи в приложения для обхода обсуждается. Некоторые уже поддерживают. Это не помешает злонамеренному приложению увидеть, что прокси есть - но не позволит узнать адрес сервера. Также без ограничения доступа к TUN пароль на прокси не поможет.
Раздельные IP на вход и выход - довольно хороший способ. В худшем случае в бан улетит сервер-выход, а вы продолжите подключаться на входной.
Различные устройства - неудобный и дорогой, но надёжный способ. Одно устройство только для российских приложений, без следа средств обхода, подключается в Сети только через мобильный интернет. Второе - для всего остального. Но не стоит забывать про проблемы вебсайтов (см. ниже).
Что делать с сайтами?
Потенциально на сайт может быть внедрён JS-скрипт (через трекеры или рекламные сети), который пытается провести аналогичный анализ через сопоставление двух обращений на сервера в разных сетевых локациях. При этом правила CORS, не позволяющие скриптам произвольно обращаться к другим веб-сайтам, не особенно помешают. Они не позволяют скрипту прочитать ответ, но сервера всё ещё получат запрос - а значит, могут выполнить сопоставление сами, если они подконтрольны создателю скрипта.
Поэтому разумным представляется такой вариант: два разных браузера, или два разных профиля в одном браузере. Один без прокси, под работу с доступными сайтами и один под потенциальную запрещёнку. В оба профиля ставим адблокер и жёстко режем доступ к любым рекламным сетям - не гарантия, но может помочь. Во втором профиле - никакой раздельной маршрутизации, все запросы строго через прокси. На российские и другие подозрительные ресурсы через второй профиль не ходим никогда.
Некоторые сотовые операторы (не будем показывать пальцем) не нашли ничего лучше чем заблокировать google com, а вместе с ним кучку вполне добропорядочных отечественных сервисов. Про неотечественные и не говорю.
Ну и куда податься бедному крестьянину, желающему посмотреть на "замедленном" Ютубе про выращивание рассады, и поискать в интернете чертежи теплицы, сидя на даче?
Пришлось пенсионерам приобщаться к премудростям работы сетей и к технологиям исправления поломанного. Заодно и телеграм с вотсапом заработали.
Если цель всего этого цирка - поднятие компьютерной грамотности и воспитание недоверия - работа проводится успешно.
Wireshark: установка, фильтры и разбор реальных сценариев
Сеть ведет себя странно, но непонятно где именно — знакомая ситуация? Wireshark в таких случаях помогает увидеть трафик изнутри: перехватить пакеты, отфильтровать нужное и найти проблему — будь то задержки, потери пакетов или подозрительная активность.
В блоге разобрали инструмент с нуля: установка на Windows, Linux и macOS, работа с интерфейсом, фильтры захвата и отображения, практические сценарии — от отладки медленного соединения до анализа VoIP-звонков.
ТСПУ как система: что можно утверждать, а что пока остаётся реконструкцией
Я изучал тему ТСПУ по открытым источникам и в какой‑то момент понял, что главная проблема обсуждения здесь — смешение разных уровней знания. Подтверждённые факты, правдоподобные инженерные выводы и чистые гипотезы часто складывают в одну корзину.
Чтобы не скатываться в источники «одна баба сказала» мифологию, полезно развести эти уровни отдельно.
Подтверждённый слой
На основании открытых данных можно считать достаточно подтверждённым следующее:
ТСПУ распределены по сетям операторов и управляются централизованно.
система использует комбинацию механизмов: DPI, DNS и более грубые сетевые методы.
ТСПУ хранит контекст и может реализовывать не только статические блокировки, но и временные ограничения.
в системе существует разрешительная/запретительная политика (Белые/черные списки).
ТСПУ имеет ресурсные пределы; кроме того и режим bypass (Пропускаем весь трафик).
РКН планирует существенно увеличивать мощность и бюджет этой инфраструктуры.
Вероятный слой
Следующий уровень — это уже не прямое подтверждение, а реконструкция, которая хорошо ложится на наблюдаемую логику таких систем:
скорее всего, внутри реализован многоступенчатый pipeline обработки и принятия решений;
белые списки, скорее всего, работает как fast‑path (дешевое, с точки средния ресурсов решение) для удешевления обработки части трафика;
часть решений может приниматься по совокупности признаков, а не по одному сигнатурному совпадению, возможно накопительная система, как в антифроде;
под высокой нагрузкой система, вероятно, переходит к более дешёвым сценариям анализа и воздействия;
Telegram и сопоставимый трафик можно предположительно отнести к дорогому классу нагрузки для DPI, так как. MTProxy маскируются под https и требуют более глубокого L7 анализа, тоже похоже относится и к VLESS.
Гипотетический слой
Пока нет оснований уверенно утверждать:
как именно устроен механизм применения правил;
используются ли ML/AI‑компоненты, или всё построено на правилах и эвристиках;
как именно система управляет таблицей состояний соединений — как очищает её, какие записи вытесняет при нехватке ресурсов и по каким правилам хранит информацию о текущих и недавних сетевых сессиях;
где именно находятся пороговые значения для включения bypass;
насколько отличается глубина L7-разбора между разными типами трафика.
Мой промежуточный вывод такой: ТСПУ разумно анализировать не как отдельное устройство, а как распределённую систему с централизованным управлением, ограничениями по вычислительным ресурсам и, вероятно, несколькими режимами деградации.
Если к теме будет интерес, я могу подготовить аналитическую статью: архитектура, стоимость анализа и пределы блокировок. Готов коллаборациям с другими исследователями.
Об авторе:
Я занимаюсь информационной безопасностью, основной профиль — практическое тестирование на проникновение (pentest), расследование инцидентов и анализ защищённости инфраструктур. В том числе работаю с инцидентами, связанными с хищением криптоактивов и разбором сложных кейсов, требующих технического и аналитического подхода.
Представлен онлайн-проект Project Backbone, который показывает как устроена глобальная сеть Интернет в режиме реального времени. Можно посмотреть на кабели под океанами, серверы в разных странах, оптоволокно под городами. Также через какие маршруты идут данные, как связаны регионы и насколько всё это глобально, включая спутниковые группировки.
Открытый сетевой инструмент Deep Eye может автономно искать уязвимости и проводить тесты на проникновение в исследовательских целях. Проект использует нейросети, которые коллективно ищут уязвимости на выбранном ресурсе и пытаются проводить различные тесты. Решение поддерживает 45 методов и атак. Алгоритмы системы собирают всю информацию о сайте, включая поддомены и DNS.
Проект просуществовал более восьми лет, набрал 20 тысяч звёзд на GitHub и стал стандартом для HTTP-маршрутизации в Kubernetes. Теперь поддержка и разработка полностью прекращена: новых релизов, багфиксов и патчей безопасности не будет.
Причина архива: ресурс Ingress изначально был слишком ограничен. Весь расширенный функционал реализовали через vendor-специфичные аннотации, нормального RBAC не было, протоколы: только HTTP/HTTPS. Gateway API решает все эти проблемы на уровне спецификации.
Мейнтейнеры рекомендуют переходить на реализации Gateway API:
"If you are not already using ingress-nginx, you should not be deploying it as it is not being developed. Instead you should identify a Gateway API implementation and use it."
Если это для борьбы с БПЛА, то можно же отследить странное перемещение сигнала от вражеского мобильного устройства даже без GPS данных от него, используя Location‑based services (LBS) + MLP + подключить в наше время к анализу ИИ. Сразу выборочно направлять данные о подозрительном объекте «куда следует» и блокировать. Чем больше станций — тем точнее, но почему‑ то наоборот «массово демонтируют оборудование провайдеров на опорах „Россетей“ — вредительство?»
Вот выдержка из гугла:
1. Как провайдер определяет скорость
Оператор не просто видит местоположение, он анализирует динамику изменения сетевых параметров:
Частота хендоверов (Handover Rate): Это основной показатель. Если телефон переключается между базовыми станциями (Cell ID) каждые 30–60 секунд, алгоритмы сети понимают, что объект движется по трассе или в поезде. Зная расстояние между вышками, система вычисляет среднюю скорость.
Доплеровский сдвиг (Doppler Shift): При быстром движении частота радиоволны меняется (эффект Доплера). Оборудование базовой станции измеряет это отклонение, что позволяет определить мгновенную скорость объекта относительно вышки.
Изменение Timing Advance (TA): Параметр TA определяет задержку сигнала и расстояние до вышки (шагами по ~550 метров). Если значение TA быстро уменьшается или растет, оператор видит радиальную скорость сближения или удаления.
2. Как провайдер определяет высоту (Z-координату)
Это более сложная задача, но в современных сетях (LTE/5G) она решается так:
Протокол LPP (LTE Positioning Protocol): Сеть может запросить у смартфона данные его внутренних датчиков. Если в телефоне есть барометр, он передаст данные о давлении в зашифрованном виде оператору, что даст точность высоты до 1–3 метров.
MDT (Minimization of Drive Tests): Это функция, при которой смартфоны анонимно передают отчеты о качестве покрытия, включая GPS-координаты (в том числе высоту над уровнем моря), если навигация включена.
UTDOA (Uplink Time Difference of Arrival): Несколько вышек фиксируют время прихода сигнала с точностью до наносекунд. Разница во времени позволяет построить 3D-модель и вычислить высоту (Z), даже если у телефона нет GPS или барометра. Это метод «обратной триангуляции».
Анализ диаграммы направленности: Антенны на вышках имеют определенный наклон (Tilt). Анализируя, какой сектор и под каким углом принимает сигнал, система может предположить, находится ли абонент на земле или на верхних этажах небоскреба.
3. Где эти данные обрабатываются?
В архитектуре сети за это отвечают специальные узлы:
GMLC (Gateway Mobile Location Centre): Шлюз, который собирает и выдает координаты внешним сервисам (например, экстренным службам 112).
LMF (Location Management Function): В сетях 5G этот узел отвечает за сложные вычисления 3D-позиционирования в реальном времени.
Выпустили мобильное приложение для Интернетометра от Яндекса
Команда Yandex Infrastructure разработала приложение под iOS и Android для бесплатного сервиса Интернетометр. Как и в веб‑версии сервиса в приложении можно замерять скорость скачивания, скорость загрузки и время задержки интернет‑соединения в миллисекундах.
В приложении доступны светлая и тёмная темы
Сбор информации организован с использованием сети CDN‑серверов Яндекса: для большей точности сервис опрашивает не один, а сразу несколько ближайших серверов. Ежемесячно Интернетометром пользуются 5,5 миллионов человек — в среднем они запускают 18 миллионов измерений.
Сервис предоставляет ключевую информацию о подключении: IP‑адрес, версию браузера, разрешение экрана и так далее. В будущем в приложении будет доступен расширенный режим измерений: он будет особенно полезен для технических специалистов, которые настраивают интернет‑соединение. Также у провайдеров проводной и беспроводной связи появится личный кабинет, где они смогут отслеживать замеры в зоне своего покрытия.
Telegram наносит ответный удар: мессенджер в ответ на блокировку убивает оборудование РКН дудосом.
Что происходит
В последние дни пользователи Telegram в России столкнулись с серьёзными проблемами в работе мессенджера. Ситуация развивается на фоне активных блокировок нежелательного контента самим Telegram и последующих технических проблем с инфраструктурой.
Техническая сторона проблемы
По данным DTF, прокси-серверы Telegram начали генерировать миллиарды запросов в секунду к системам ТСПУ Роскомнадзора. Это происходит в ответ на попытки блокировки: когда РКН проверяет доступность мессенджера для последующей блокировки, прокси-серверы Telegram отвечают массовыми «мусорными» запросами, перегружая оборудование ведомства.
Перегрузка инфраструктуры: оборудование интернет-провайдеров не справляется с обработкой такого объёма запросов
Каскадные сбои: в некоторых регионах наблюдаются нестабильная работа сервиса
Побочные эффекты: зафиксированы случаи, когда из-за сбоев начали работать ранее заблокированные платформы, а "белые списки" (перечни разрешённых ресурсов) перестали функционировать должным образом
Важно: данная информация исходит из неофициальных источников и требует подтверждения.
Контекст: блокировки контента
Проблемы возникли на фоне того, что сам Telegram активизировал блокировку каналов с нежелательным контентом. Это могло спровоцировать изменения в работе протоколов мессенджера и, как следствие, повлиять на характер сетевого трафика.
Реакция властей
Депутаты Госдумы обратились к Роскомнадзору с требованием объяснить причины замедления работы Telegram в России. Парламентарии выразили обеспокоенность массовыми жалобами пользователей на сбои в работе мессенджера.
Интересно, что претензии к регулятору поступают именно после того, как Telegram начал самостоятельно блокировать контент — действие, которое ранее от платформы активно требовалось.
Что это значит для пользователей
Возможны задержки в доставке сообщений
Нестабильная работа при загрузке медиафайлов
Региональные различия в качестве связи
Непредсказуемость работы сервиса в ближайшее время
Кто победит в этой битве? Я ставлю на телеграмм! Паша умный малый.
Принимаем заявки на доклады infra.conf 2026 до 1 апреля
Команда Yandex Infrastructure приглашает докладчиков на большую конференцию по инфраструктуре — infra.conf 2026. В этом году мы встретимся 4 июня уже в третий раз и обсудим ключевые темы, которые касаются обеспечения высоких нагрузок и не только:
инструменты разработки и практики управления разработкой,
базы данных и стораджи,
принципы и практики обеспечения надёжности и доступности,
управление инцидентами
и многое другое.
Отдельное внимание уделим построению и особенностям эксплуатации инфраструктуры в эпоху ML.
Приём заявок на выступление открыт до 1 апреля включительно в этой форме. Чтобы заявить свою тему на этом этапе, достаточно тезисов и общего плана. Координатор конференции и участники программного комитета свяжутся с каждым спикером для обсуждения материала, а финальное решение по докладам будет принято до 1 мая.
Как масштабировать NGFW до сотен Гбит трафика в секунду без потери сессий
Производительность современных NGFW давно перестала измеряться «гигабитами в идеальных условиях». В реальной инфраструктуре устройство одновременно выполняет SSL-инспекцию, IDS/IPS, контроль приложений, антивирусную проверку и другие функции — и всё это под высокой нагрузкой, без потери пакетов и без разрыва пользовательских сессий.
Когда речь идёт о десятках и сотнях Гбит трафика в секунду, вертикальное масштабирование упирается в архитектурные ограничения. Горизонтальный подход выглядит логичным, но на практике поднимает целый ряд инженерных вопросов:
как обеспечить симметричную обработку трафика в обоих направлениях;
как сохранить пользовательские сессии при изменении состава кластера;
как организовать контроль состояния узлов и корректную реакцию на сбои;
как избежать появления единой точки отказа;
как корректно встроить решение в существующую инфраструктуру.
5 марта в 11:00 совместно с инженерами UserGate обсудим архитектурный подход к масштабированию производительности NGFW, принципы интеграции UserGate NGFW 7 и DS Proxima, а также результаты тестирования и практический опыт внедрения.
Открытый проект Bluehood позволяет превратить гаджеты с Bluetooth в радар устройств для OSINT‑разведки, включая тепловые карты с графиком активности пользователей:
Pi.Alert - сканирует устройства, подключённые к Wi‑Fi. Находит и уведомляет о неизвестных девайсах. Предупреждает о резком отключении устройств от сети, которые всегда была подключены.
WireTapper - находит беспроводные сигналы вблизи пользователя на предмет фишинга и передачи вредоносов. Сможет найти все Wi‑Fi сети, устройства Bluetooth, даже скрытые камеры, автомобили, наушники, телевизоры и сотовые вышки.
MetaRadar - находит и в реальном времени отслеживает Bluetooth‑устройства поблизости. Сможет определить их тип, а также расстояние до них.
Представлен учебный 5-тичасовой фильм о технических средствах противодействия угрозам (ТСПУ, «чёрные ящики» от РКН, которые установлены у операторов связи, но доступа к этим устройствам сами провайдеры не имеют). С августа 2023 года все узлы связи в России у основных провайдеров оборудованы средствами противодействия угрозам на базе оборудования ТСПУ для фильтрации трафика пользователей от запрещённого контента.
Клик-ловушка: не только для пользователей, но и для анализаторов ссылок 🐭
При ручном разборе ссылок мы в PT ESC , как правило, задаем себе лишь один вопрос — «безопасна ли она?» ✔❌
Перенести подобный подход в потоковую среду для анализа нельзя: действия, инициируемые переходом по ссылке, могут привести к возникновению новых проблем. Так, приглашения из почтовых сообщений могут автоматически приниматься или отклоняться, производиться автоматическая отписка и/или подписка на корреспонденцию и так далее. В случае если подобное действие вызывает на сервисе отправку нового письма с подобными ссылками, то автоматический переход по ним вызовет непрекращающуюся «лавину» сообщений, что может привести к снижению производительности защитных решений или просто к раздражению пользователей.
🫵 Для решения этой проблемы можно предложить подход, логически схожий с процессом выбора ссылок при ручном анализе: какие-то ссылки нам кажутся крайне подозрительными или однозначно требующими дополнительного контекста для анализа, а какие-то — точно безопасными или, как в предыдущей ситуации, вызывающими определенные действия на сервисах (или вообще одноразовыми). Подход, где система определяет набор признаков «точно нужно переходить» и набор признаков «точно не нужно переходить», называется принятием решений на основе правил (rule-based decision system). Какие признаки можно предложить для реализации подобной системы?
В наборе условий, предотвращающих переход по ссылке, можно рассмотреть:
наличие паттернов в URL-пути, семантически указывающих на возможное действие при активации, например, /(un)subscribe/, /login/, /exit/, /action/, /track/ и т.д.;
наличие параметров запроса token, key, uid со значениями, по формату совпадающими с UUID или JWT;
наличие параметров запроса ts или expires, указывающих на время жизни ссылки;
если ссылка пришла из почтового сообщения, можно проверить ее наличие в отдельных заголовках подписки/отписки от корреспонденции — List-(Un)Subscribe:;
при наличии поставки потоков данных с набором «белых» доменов можно рассмотреть отключение анализа содержащих их URL-ссылок. С подобной опцией нужно быть осторожнее, поскольку даже самые популярные и известные сервисы и домены могут использоваться в сценариях с перенаправлением контента.
В наборе условий, вызывающих переход по ссылке, можно рассмотреть:
ссылки с явным указанием IP-адреса и/или нестандартного порта;
ссылки с недавно зарегистрированным доменом;
при наличии категоризатора web-ресурсов с подобной классификацией — ссылки на сервисы-shortener'ы. В случае отсутствия можно рассмотреть условие с короткой длиной URL-ссылки;
ссылки с указанием в URL-пути файлов с конкретными статическими расширениями, например, .pdf, .exe и т.д.;
ссылки на сервисы объектных хранилищ, например на S3- или IPFS-хранилища.
🧐 Что остается делать со ссылками из анализируемого объекта, которые не попали ни под один из перечней? Здесь можно опираться на реальную картину, которая получается после работы подобного алгоритма: если позволяет производительность системы или время анализа не превышает допустимый SLA на обработку объектов, можно отправлять все «серые» ссылки на получение контента. Либо же ввести ограничение на количество одновременно анализируемых ссылок у одного объекта.
Также для URL-ссылок, не прокатегоризированных системой принятия решений, можно предусмотреть «осторожный» алгоритм получения дополнительного контекста для анализа: переходить по ссылке методом HEAD без получения контента. Таким образом можно получить дополнительную информацию из HTTP-заголовков, применимую как внутри вышеописанного алгоритма, так и в целом для принятия решения о вредоносности ссылки.
