Не прошло и месяца после начала ввода ограничений на трафик YouTube в России, как в Сети уже широко распространились «советы бывалых» по обходу введённых ограничений. Нет ли в этом опасности для ИБ?
- Введение
- Доставка контента YouTube
- «Умный в гору не пойдёт…»
- YouTube «летает» при QUIC — какая ещё безопасность?
- Новые риски после перехода на QUIC
- ИБ-службы видят или не видят?
- Могут ли новые отечественные файрволы противостоять рискам перехода на QUIC?
- Выводы
Введение
25 июля 2024 года глава комитета Госдумы по информационной политике Александр Хинштейн заявил, что «до конца текущей недели скорость загрузки YouTube на стационарных компьютерах может снизиться до 40 %, а к концу следующей — до 70 %». Он также заявил, что ограничения коснутся только десктопных версий, а производительность доставки видеоконтента на мобильные устройства останется прежней.
Сам депутат ещё в 2023 году предупреждал, что «сначала надо решить вопрос адекватной замены, иначе заложниками станут пользователи». Речь шла о необходимости наращивания популярности отечественных вариантов видеохостинга для замены YouTube и достижения ими адекватной производительности. Но пока эти усилия, похоже, не достигли нужного результата.
Поэтому многие российские пользователи почувствовали себя «пострадавшими» после замедления YouTube, поскольку используют его не только для просмотра нежелательного контента, а часто для реализации своих творческих и бизнес-интересов, получения новостного и развлекательного контента, в том числе с государственных каналов.
В настоящее время конфликт носит трудноразрешимый характер. С одной стороны YouTube является участником Реестра Роскомнадзора разрешённых социальных сетей в России с подтверждённым статусом добросовестного исполнителя всех его требований. С другой стороны, российские власти упрекают YouTube в блокировке ряда отечественных каналов, относящихся к политическим институтам и отдельным лицам.
Со своей стороны YouTube ссылается на нарушение установленных для этой социальной сети этических правил, за что они подвергают ограничениям нарушителей, не оценивая их с точки зрения их политического веса. Неразрешимость конфликта состоит в том, что правила задает Google, поэтому их трактовка всегда будет отражать собственное мнение владельца Youtube.
Рисунок 1. YouTube является участником Реестра РКН разрешённых социальных сетей в России
Доставка контента YouTube
«Замедление» на техническом языке означает воздействие на канал доставки контента YouTube. И здесь оказывается не все так гладко, как может показаться.
Любой разработчик скажет, что даже для самой простой задачи всегда можно предложить несколько решений. Это же касается и блокировки YouTube. Доставка контента YouTube может осуществляться разными путями даже по заранее определённым каналам. Если блокировку рассматривать в простейшей форме как наложение ограничений на скорость трафика, то даже в этом случае существуют альтернативные варианты.
Например, способы потоковой передачи видео YouTube сильно зависят от конкретной настройки. Чтобы лучше понять, как системные требования повлияют на это, достаточно оценить, как может работать YouTube.
YouTube работает через видеоплеер стандарта HTML5. Это значит, что протоколом по умолчанию для доставки контента служит HLS (HTTP Live Streaming). Его поддерживают большинство медиаплееров, веб-браузеров, мобильных устройств и медиа-серверов. Этот видеопротокол был разработан компанией Apple и запущен в тираж в 2009 году. Это было сделано, чтобы отказаться от использования Adobe Flash на смартфонах iPhone (за который полагалось платить роялти).
С тех пор HLS стал широко используемым протоколом потоковой передачи. Его поддерживают браузеры настольных компьютеров, смарт-телевизоры, мобильные устройства Android и iOS. То же относится и к видеоплеерам HTML5, которые также используют протокол HLS по умолчанию.
Не будем упрощать ситуацию. За поддержкой HLS лежат и другие связи. Стандарт HLS поддерживает потоковую передачу с адаптивным битрейтом, что позволяет динамически доставлять наилучшее возможное качество видео для каждого отдельно взятого зрителя. Через него обеспечена поддержка кодека H.265, который обеспечивает вдвое лучшее качество видео при тех же размерах передаваемого видеофайла, чем более ранний кодек H.264. HLS также поддерживает различные аудиокодеки, включая Advanced Audio Coding (AAC), Windows Media Audio (WMA) и бесплатные аудиокодеки без потерь, такие как FLAC для аудиофайлов.
Рисунок 2. Схема доставки трафика YouTube (Источник: Edgenext)
Думаю, в рамках темы данной статьи решение очевидно: для замедления трафика YouTube надо выделить в общем потоке его трафик по используемому протоколу и установить подходящую задержку. Чтобы соблюсти условие «только для настольных», можно отфильтровать трафик только для настольных браузеров тем или иным способом.
Согласно подсчетам, ежедневная аудитория пользователей YouTube в России оценивается в 96 млн человек. Поэтому сделать это незаметно будет сложно. Но почему-то ухудшения заметили не только «пользователи настольных систем», но и мобильные пользователи.
Что-то пошло не так…
«Умный в гору не пойдёт…»
Очевидно, в возникшей ситуации возникли группы «заинтересованных граждан», которые стали искать выход «в рамках существующих ограничений». Очевидное направление поиска — попробовать перейти на другие протоколы, которые допускает YouTube для доставки контента. К их числу относятся: HLS, RTMP, RTMPS, HLS и DASH.
Но всё оказалось гораздо проще. Легко был найден более простой способ: переход на протокол QUIC.
QUIC — это экспериментальный интернет-протокол, который был разработан Google ещё в 2012 году с целью сделать доставку контента интернета более быстрой и эффективной. QUIC позволяет мультиплексировать (объединять вместе) несколько потоков данных, работая поверх протокола UDP. UDP при этом остаётся транспортом для потоковой передачи данных YouTube.
Решение обхода блокировок YouTube настолько простое, что воспользоваться им, как оказалось, способны даже те, кто вообще не знает, как слово «протокол» относится к Youtube. Ведь достаточно просто переключить тумблер и включить (сделать Enable) протокол QUIC.
Для этого достаточно ввести в адресной строке браузера соответствующую команду и включить поддержку QUIC взамен той, которая «принята по умолчанию».
- Chrome: chrome://flags/#enable-quic.
- Firefox: сначала — about:config; затем — network.http.http3.enabled.
- Edge: edge://flags/#enable-quic.
- Opera: opera://flags/#enable-quic.
- Яндекс Браузер: browser://flags/#enable-quic.
YouTube «летает» при QUIC — какая ещё безопасность?
На первый взгляд, каких-либо новых рисков с переходом на QUIC не должно возникнуть. QUIC работает поверх протокола UDP, поддерживает все возможности шифрования TLS и SSL. Его главное достоинство — более низкая задержка при соединении и передаче трафика, чем при TCP.
Какое-то время назад ещё можно было сказать, что протокол QUIC разрабатывался Google с учётом поддержки браузером Google Chrome. Но сейчас его поддержку предоставляют все основные браузеры.
Риски пришли со стороны экспериментальности протокола и следовательно неопределённости из-за отсутствия у него стандартизации. Если в настоящее время его поддерживают браузеры и серверы, то это не означает, что файрволы тоже обязаны распознавать трафик QUIC. В результате многие из них (если не все) не проверяют трафик QUIC, не регистрируют его появление в подконтрольной сети, не отслеживают его применение в журналах. Если это происходит в корпоративной инфраструктуре, то возникает «дыра» в системе безопасности сети.
Отметим также, что большинство файрволов используют обширный набор функций для работы с трафиком HTTP и HTTPS. При его обнаружении сведения передаются в модуль веб-защиты. Там происходит фильтрация трафика, глубокая проверка пакетов и т.д.
Особые возможности проверки HTTP-трафика возникают, если файрвол поддерживает интерпретацию принадлежности трафика к соответствующим сетевым уровням (от LVL 4 до LVL 7). За счёт этого появляется возможность для проведения специальной обработки. Например, сканирование на наличие вредоносного ПО, получение расширенной отчётности и т.д.
Вернемся к QUIC. Его трафик работает через традиционные HTTP-порты 80 и 443. Но на этом его сходство заканчивается. Хотя его умеют понимать браузеры и серверы с соответствующими средствами поддержки, обычные сетевые устройства, через которые этот трафик также проходит, не умеют выделять прикладной протокол и переключаться на соответствующую обработку как для любого другого UDP-трафика LVL 4.
В результате трафик QUIC выпадает из списка проверки. И теперь через него могут приходить угрозы, которые при обычном трафике были бы отсеяны файрволом по умолчанию.
Для иллюстрации сравним, как видит трафик программа-анализатор Wireshark в случае использования QUIC (слева) и традиционного HTTPS TLS (справа).
Рисунок 3. Логи Wireshark при использовании QUIC (слева) и традиционного HTTPS TLS
Новые риски после перехода на QUIC
Почему Александр Хинштейн так упорно настаивал, что ограничения на YouTube не коснутся мобильных пользователей. Поскольку он не дал никаких разъяснений на этот счёт, их придется искать самим. Одна из версий: YouTube может использоваться для бизнеса. Этим утверждением депутат ГосДумы мог подчеркнуть, что принятое решение не будет мешать российскому бизнесу развиваться.
А если что-то пойдёт не так? Ведь замедление YouTube может спровоцировать корпоративных пользователей, столкнувшихся с неприемлемым для них замедлением, включить поддержку QUIC. Это, конечно, увидит системный администратор и служба безопасности компании, если такие существуют и будут готовы обратить внимание. Но им потребуется понять риски самим. Никаких специальных предупреждений о снижении безопасности в сети они не получат.
Реальные последствия появления трафика QUIC в корпоративной сети могут оказаться значительно более масштабными, чем кажется на первый взгляд. Дело в том, что после замены протокола пользователи смогут смотреть видеоматериалы YouTube без задержек, но сисадмины не смогут этому помешать, даже если смогут вычислить по названию протокола и хосту, кто именно пользуется этим. Они будут вынуждены смириться, потому что пользователи выполняют свои бизнес-задачи, а ИБ должны помогать, а не мешать им. Пусть занимаются безопасностью, а не «придумают риски», скажут они.
Корпоративные пользователи теперь также смогут использовать средства защищённого (безопасного) поиска Google Safe Search. Его особенность — это анонимизация поисковых запросов. Другими словами, если раньше служба ИБ могла разбирать трафик и выявлять инсайдеров, то теперь весь трафик, который они генерируют, окажется вне контроля. Риски инсайдерской деятельности внутри компаний повышаются.
Но самое опасное — это риски взаимодействия с веб-серверами и веб-сайтами, имеющими поддержку QUIC. Этот трафик также выпадет из проверки файрволов. Теперь по нему можно попробовать загружать вредоносные программы и программы-вымогатели за периметр компании, потому что этот трафик не будет попадать на сетевой антивирус, установленный на файрволе. Все ли побегут теперь устанавливать антивирусы на каждый пользовательский ПК?
То же самое касается и почтовых серверов с поддержкой QUIC, например, Gmail. Их корреспонденция окажется теперь также вне контроля службы ИБ компании. Самое неприятное ещё и то, что из-под контроля выйдет не только трафик обмена сообщениями, но и работа механизмов регистрации и отчётности файрволов. Служба ИБ теперь не сможет выявить даже попытки инициализации новых взаимодействий с веб-сайтами с поддержкой QUIC, чтобы проводить проверку вручную.
ИБ-службы видят или не видят?
В чём же главная проблема для безопасности при переходе на QUIC?
Для принятия любого решения системе защиты сначала требуется понять, с чем она имеет дело. Первым возникает вопрос, как выявлять пакеты QUIC в трафике и получать по ним полные URL-адреса источника и адресата. Эти сведения недоступны из метаданных, по которым часто строят на практике первую полосу обороны. В отношении трафика QUIC это не работает. Трафик, создаваемый при работе Google Search или YouTube с включенным QUIC, становится «слепым» для систем контроля.
Многие файрволы не распознают трафик QUIC как отдельный вид веб-трафика. Они обычно заносят его в лог как обычный трафик UDP. В результате, маркерная информация, которую дает HTTP-трафик, оказывается урезанной. Эти данные не генерируются, не регистрируются и не отражаются в syslog.
В качестве примера мы нашли в сети скриншот лога, созданного файрволом Sophos XG после передачи данных в модуль веб-защиты. Видно, насколько мало информации попадает в журнал Webfilter при использовании QUIC, тогда как для TCP там отражаются разнообразные данные (URL, категория сайта и т. д.). При регистрации трафика UDP с того же веб-сайта при использовании QUIC, лог для него отсутствует вообще. Вся обширная информация, которая ранее использовалась для принятия решения системой безопасности о пропуске трафика, теперь пропала.
Рисунок 4. Сравнение логов для одного сайта при TCP (сверху) и UDP с использованием QUIC
Могут ли новые отечественные файрволы противостоять рискам перехода на QUIC?
Широкому использованию QUIC долго мешало то, что подключение этого экспериментального протокола было отключено у большинства пользователей. Опция по умолчанию обеспечивала подключение стандартного протокола, а ссылка на экспериментальный характер QUIC «пугала» подавляющее большинство пользователей от «проверки». Обычный пользователь сразу принимал решение, что ему нет никакого дела до «экспериментов вендора». Этот психологический трюк работал на 100 %.
Решение Роскомнадзора ввести замедление на трафик YouTube могут теперь сломать этот «защитный барьер» со стороны пользователей. В Роскомнадзоре, похоже, не подумали о таком продолжении. Ведь «спасение утопающих» (в смысле службы ИБ) – это, как известно, «дело рук самих утопающих».
В своей технической документации вендоры файрволов часто советовали блокировать QUIC до сих пор и следовать этому, пока не появится официальная поддержка. Если поддержку QUIC между клиентом и сервером ещё можно отключить на стороне клиента, и трафик вернется к традиционному HTTP/HTTPS через TCP, который можно проверять, контролировать, регистрировать и собирать логии. То как быть на стороне сервера, если пользователь требует включить QUIC «для работы»?
Конечно, многое зависит от файрвола. Сейчас в России идёт интенсивная разработка инструментов этого типа. Умеют ли они противостоять угрозе потери log-данных при переходе на QUIC? Интересно услышать мнение отечественных разработчиков.
Хотя, с другой стороны, решение РКН и ответная реакция рынка на переход на QUIC будет способствовать росту его популярности. Это заставит вендоров подключать поддержку на стороне серверов и исследовать, как можно обеспечить безопасность в этом случае. Это – стимул для развития исследований в этом направлении и появления новых инструментов.
Выводы
Цель данной публикации не в том, чтобы оспорить принимаемые Роскомнадзором меры для решения конфликта с компанией Google. Конечно, Роскомнадзор оценивал заранее реакцию рынка и принимал взвешенное решение. Но рынок обычно реагирует хаотично на любые нововведения и делает это часто с явным пренебрежением к вопросам безопасности. Если вдруг проявляются артефакты, то они бывают особенно неприятными. После этого рынок бросается в противоположную крайность. Будем следить за развитием событий.
