Интересный кейс с точки зрения вектора атаки. Компрометация PAT через утечку GitHub — это не баг в коде, это провал в управлении секретами на уровне процессов. Примечательно, что атака длилась меньше полутора часов, но успела затронуть пакеты с суммарным числом загрузок в десятки миллионов.
Вопрос к автору: в audit log GitHub фигурировал только один скомпрометированный PAT, или были признаки нескольких точек входа? Судя по тому, что удаление тегов не помогало — создаётся ощущение, что у атакующего было несколько активных токенов одновременно.
Логично, если речь о статических реестрах. Но реестры обновляются с задержкой, а CDN и облачные провайдеры постоянно меняют адреса. Получается, что классификация будет давать ложные срабатывания в обе стороны — и блокировать легальный трафик, и пропускать нелегальный.
По поводу 15 ГБ лимита — интересно, как операторы собираются технически разграничивать «международный» трафик от внутреннего. Если трафик идёт через промежуточный узел внутри России, оператор видит только последний хоп. Получается, что лимит будет бить по легальным корпоративным VPN и SD-WAN решениям не меньше, чем по потребительским. Есть ли у кого-то данные, как операторы планируют это разрешать?
Именно. И это показывает, что ТСПУ работает не только на уровне блокировок — он активно вмешивается в содержимое пакетов. Модификация RTP — это уже глубокая инспекция, а не просто фильтрация по порту или IP.
Про белые списки и мобильные операторы — точное наблюдение. Добавлю: поведение сильно зависит от того, на каком уровне оператор применяет фильтрацию — на уровне BGP-анонсов или непосредственно на ТСПУ. В первом случае блокировка жёсткая и однородная, во втором — региональные расхождения именно такие, как вы описываете. Вы пробовали сравнить поведение на разных операторах в одном регионе? Это быстро показывает, где проблема на стороне ТСПУ, а где — решение конкретного оператора.
Интересный эксперимент. Вопрос по архитектуре: вы храните ключи локально на устройстве или есть какой-то обмен через сервер? Если ключи только на клиенте — что происходит при переустановке приложения или смене устройства? Без механизма резервного копирования это довольно жёсткий UX для обычного пользователя, даже если криптография корректная.
Интересный инструмент. Вопрос по QUIC/UDP: скрипт проверяет TCP-доступность и SNI-фильтрацию — но ТСПУ всё чаще режет UDP-трафик целиком, независимо от порта. Есть ли в планах добавить проверку UDP-доступности? Это было бы полезно для диагностики протоколов, работающих поверх QUIC.
Интересный кейс с точки зрения вектора атаки. Компрометация PAT через утечку GitHub — это не баг в коде, это провал в управлении секретами на уровне процессов. Примечательно, что атака длилась меньше полутора часов, но успела затронуть пакеты с суммарным числом загрузок в десятки миллионов.
Вопрос к автору: в audit log GitHub фигурировал только один скомпрометированный PAT, или были признаки нескольких точек входа? Судя по тому, что удаление тегов не помогало — создаётся ощущение, что у атакующего было несколько активных токенов одновременно.
Логично, если речь о статических реестрах. Но реестры обновляются с задержкой, а CDN и облачные провайдеры постоянно меняют адреса. Получается, что классификация будет давать ложные срабатывания в обе стороны — и блокировать легальный трафик, и пропускать нелегальный.
По поводу 15 ГБ лимита — интересно, как операторы собираются технически разграничивать «международный» трафик от внутреннего. Если трафик идёт через промежуточный узел внутри России, оператор видит только последний хоп. Получается, что лимит будет бить по легальным корпоративным VPN и SD-WAN решениям не меньше, чем по потребительским. Есть ли у кого-то данные, как операторы планируют это разрешать?
Именно. И это показывает, что ТСПУ работает не только на уровне блокировок — он активно вмешивается в содержимое пакетов. Модификация RTP — это уже глубокая инспекция, а не просто фильтрация по порту или IP.
Про белые списки и мобильные операторы — точное наблюдение. Добавлю: поведение сильно зависит от того, на каком уровне оператор применяет фильтрацию — на уровне BGP-анонсов или непосредственно на ТСПУ. В первом случае блокировка жёсткая и однородная, во втором — региональные расхождения именно такие, как вы описываете. Вы пробовали сравнить поведение на разных операторах в одном регионе? Это быстро показывает, где проблема на стороне ТСПУ, а где — решение конкретного оператора.
Интересный эксперимент. Вопрос по архитектуре: вы храните ключи локально на устройстве или есть какой-то обмен через сервер? Если ключи только на клиенте — что происходит при переустановке приложения или смене устройства? Без механизма резервного копирования это довольно жёсткий UX для обычного пользователя, даже если криптография корректная.
Интересный инструмент. Вопрос по QUIC/UDP: скрипт проверяет TCP-доступность и SNI-фильтрацию — но ТСПУ всё чаще режет UDP-трафик целиком, независимо от порта. Есть ли в планах добавить проверку UDP-доступности? Это было бы полезно для диагностики протоколов, работающих поверх QUIC.