Считается, что Интернет — это надежная и самоорганизующаяся Cеть, причем надежность обеспечивается именно за счет самоорганизации. Долгие годы так и было, однако в фундаменте Сети есть слабое место: изначально предполагалось, что все ее участники, управляющие промежуточными или оконечными узлами, действуют исключительно в целях повышения степени связности и сохранения возможности обмена информацией. В соответствии с этой моделью и были спроектированы фундаментальные протоколы: TCP/IP, BGP, DNS и др., — по сей день работающие в значительной мере благодаря доверию, а методы защиты от нарушителей еще только внедряются. Действительно, Сеть позволяет надежно передавать любые данные, но именно это привело к возникновению разнообразных технологий блокировки доступа, перехвата или фильтрации трафика.

Блокирование доступа к Сети1 и фильтрация трафика — давно известные задачи, в силу ряда причин получившие сегодня новое звучание. Например, ограничение потока запросов к DNS-серверу использовалось как защита от атак. Это ограничение доступа, но проводимое на стороне сервера и по результатам действий клиента. Сегодня речь идет о превентивном блокировании доступа к определенным ресурсам, размещаемым на промежуточных узлах, с целью воспрепятствовать пользователям устанавливать соединения с этими ресурсами (сайтами).

Выборочный доступ

WWW — один из сервисов, работающих на базе Интернета. Веб-ресурс в Интернете — это узел Сети, отвечающий на запросы клиентской программы (браузера) и возвращающий содержимое веб-страницы. В подавляющем большинстве случаев доступ к такому узлу осуществляется через протоколы TCP/IP (реже — UDP), а для обнаружения IP-адреса, идентифицирующего узел, применяется система доменных имен DNS. Задача блокирования доступа пользователей,  например,  к узлу с доменным именем test.ru заключается в том, чтобы, вопреки действиям администратора узла test.ru и его пользователей, закрыть доступ к ресурсу, сохранив доступ к другим узлам.

Инструмент блокирования должен находиться между пользовательской «точкой выхода» в Сеть и блокируемым узлом, причем чем ближе к пользователю такой фильтр, тем точнее он работает (см. рисунок). Когда проблема подобных блокировок замаячила на технологическом горизонте, предлагалось рассматривать только вариант добровольного блокирования на стороне пользователя, например, путем установки программ-фильтров или списков фильтрации для браузера, однако, из-за возможности простого отключения фильтра по команде пользователя, такая схема не подходит. В реальности фильтрующий узел находится в сетях провайдеров доступа и необязательно близко к пользователю, более того, обычно это не один узел.

 

За час до закрытия Интернета

Общая архитектура системы блокирования доступа

Чтобы блокировать выборочно, нужно уметь различать сеансы доступа к различным ресурсам. В случае WWW имеется несколько источников нужной для этого информации: IP-адреса, имена узлов (доменные имена) и адреса конкретных страниц (URL). В идеале фильтрующий узел точно «тегирует» сессии, адресованные к заблокированному веб-ресурсу, и прерывает их в самом начале, но в реальности все сложнее. Сеть меняется, и точное «тегирование» становится невозможным, вынуждая системы блокирования переходить к грубой работе «по площадям»: вместо выборочного блокирования отдельных сессий массово блокировать произвольно выбираемые ресурсы.

Элементарный метод блокирования может быть построен на использовании только DNS. Если DNS-сервер контролируется провайдером, то, обнаружив запрос об адресе test.ru, провайдер может принудительно вернуть заведомо недоступный IP-адрес (0.0.0.0) либо подставить IP-адрес узла-заглушки, который сообщит пользователю, что ресурс test.ru заблокирован. Схема простая и надежная — она не затрагивает сетевой транспорт, но это не значит, что она эффективна. С точки зрения DNS такая манипуляция выглядит как атака с подменой адреса в ответе (вместо верного IP-адреса, узел, находящийся между клиентом и DNS-сервером, присылает подменный). Защиты от подобной подмены классическая система доменных имен не предлагает, но есть расширение протокола — DNSSEC [1], позволяющее обнаружить подмену с помощью электронной подписи. В современной Сети простая подмена ответов на DNS-сервере провайдера довольно бессмысленна. Например, имеются внешние, относительно провайдера, сервисы DNS (резолверы), среди которых Google Public DNS (8.8.8.8 и 8.8.4.4) и Cloudflare (1.1.1.1). В простейшем случае пользователь может указать адреса этих сервисов в настройках сетевого подключения, и его ОС станет работать, минуя DNS-сервер провайдера. Впрочем, подмена все еще может быть осуществлена в не зависящем от действий пользователя режиме, но для этого придется перейти на уровень ниже — так настроить сетевое оборудование, чтобы оно перехватывало пакеты, адресованные внешним DNS-сервисам по известным IP-адресам, и отвечало вместо них. Другими словами: операционная система пользователя отправляет запрос по адресу 8.8.8.8, однако вместо настоящего узла сервиса Google будет отвечать перехватывающий узел, установленный, например, в сети провайдера доступа. Это возможно потому, что используемые сетевые протоколы не могут гарантировать подлинность оконечных узлов, для этого требуются дополнительные криптографические механизмы. Такой метод перехвата, действующий на уровне сетевых пакетов, реализовать намного сложнее, но эта схема тоже используется для блокирования доступа при помощи вмешательства в работу DNS.

Непрозрачность на всех направлениях

Вполне очевидно, что технологии, улучшающие доступность DNS, не стоят на месте. Недавно повсеместно начал внедряться защищенный доступ к DNS: DNS-over-TLS и DNS-over-HTTPS. Оба протокола базируются на TLS-технологии, обеспечивающей криптографическую защиту данных от просмотра третьей стороной и от подмены. Более того, TLS позволяет убедиться, что ответы присылает настоящий узел, а не перехватывающий, это делается при помощи аутентификации узлов. Данные методы позволяют дезавуировать блокирование DNS, но только в пассивном режиме, — криптографическая защита работает лишь в том случае, если информация все же передается, а если соединение с сервисом DNS установить не удается, то блокирование продолжает действовать и не позволяет определить адрес, соответствующий ресурсу. Однако в этом случае третья сторона уже не может просматривать DNS-трафик и принимать решения о подмене адреса — придется целиком блокировать весь сервис DNS по IP-адресу, что может негативно сказаться на работе сетевого сегмента, так как DNS используется не только для WWW.

Можно ли полностью перевести клиентский доступ к DNS на ограниченную подсистему, которая будет реализовывать блокировки? Пользователь в таком случае не сможет подключиться к внешнему DNS-серверу, а будет вынужден довольствоваться сервером провайдера. Для классического протокола DNS это возможно — на сетевом оборудовании потребуется разрешить обмен DNS-запросами только с «авторизованным» узлом DNS. Обнаружить классический DNS-трафик относительно несложно, он не маскируется, использует хорошо известные номера портов и простой, узнаваемый протокол. Конечно, такая блокировка, скорее всего, сломает другие сервисы (например, некоторые онлайн-игры), использующие протокол UDP.

Применение защищенных протоколов усложняет блокировку, а попытка ее реализации потянет за собой большой пласт новых трудных задач. Например, DNS-трафик может быть инкапсулирован («обернут») в VPN-канал, и узлы, инспектирующие трафик на пути от точки входа в VPN до точки выхода, не смогут определить, что внутри VPN работает DNS. Хотя можно прерывать всякое VPN-соединение.

Таким образом, для систем блокирования доступа важна метаинформация, позволяющая избирательно воздействовать на трафик, и DNS-запросы предоставляют лишь часть такой метаинформации.

Информация об информации

Рассмотрим теперь протокол HTTP. Здесь запросы содержат имя узла («хоста»), с которого запрашивается HTML-документ. Соответственно, это имя можно извлечь из трафика и использовать в качестве входных данных для фильтра блокировки, позволяющего закрывать доступ не только к веб-узлу целиком, но и к конкретным страницам. Такое очередное «лобовое» решение неплохо работало, пока массовым не стал протокол HTTPS, базирующийся на протоколе TLS.

В случае HTTPS, данные HTTP-запросов уже передаются в зашифрованном виде, и промежуточные узлы, если у них нет криптографических ключей, не видят адреса документов и имена узлов, которые используются на уровне HTTP. Оговорка про уровень HTTP важна: дело в том, что имя узла все же передается в открытом виде и для HTTPS. В TLS определено специальное поле данных SNI (Server Name Indication), которое содержит имя хоста (узла), требуемое, чтобы сервер мог определить, какой именно использовать TLS-сертификат, и набор ключей в случае, если на одном IP-адресе находится несколько ресурсов. Все современные браузеры передают SNI, поэтому система блокирования, просматривающая трафик, может видеть имя узла, с которым пользователь пытается установить соединение, и блокировать его, если имя находится в стоп-листе. Увидеть полный адрес документа в защищенном трафике HTTPS нельзя, так как сам HTTP-запрос зашифрован. Получается, что использование защищенного протокола снизило избирательность системы блокирования и затруднило ее работу: на основе анализа SNI можно заблокировать только весь веб-ресурс с точностью «до имени», но не отдельный документ.

Автоматическое блокирование на основе анализа поля SNI некоторое время считалось большим технологическим достижением, поскольку, несмотря на ряд ограничений, позволяло блокировать защищенный трафик в «мягком режиме» — без нарушения работы других ресурсов, как это было бы при блокировании доступа к конкретному IP-адресу. Однако реальность опять оказалась сложнее. При использовании HTTPS передаются два имени: одно в открытом виде, в составе параметров TLS, а второе — в зашифрованном, в составе HTTP-запроса. При штатной работе протокола эти имена узлов совпадают, однако можно указать различные имена, и при установке TLS-соединения система блокировок в поле SNI увидит имя узла, не связанное с реальным именем, указываемым внутри защищенной сессии, при отправке HTTP-запроса. Некоторые крупные хостинги допускают подобную схему: при установлении соединения используется имя, указанное на уровне TLS, но HTTP-запросы, адресованные другому имени, сервер перенаправлял на соответствующий узел, уже внутри сетей хостинга, и возвращал ответ тем же путем. Такая схема называется Domain Fronting и в обычных браузерах недоступна, так как подстановка имени требует специальной обработки HTTPS-соединения. Схема используется отдельными приложениями, которые таким способом маскируют запросы. Преимущество схемы состоит в том, что фильтрующие узлы должны блокировать запросы к узлу в домене, который служит в качестве прикрытия, а этот домен может соответствовать популярному сервису (например, google.com), который не все готовы блокировать.

Передача браузерами имени узла в поле SNI создает утечку информации, так как третья сторона может видеть эти имена, а значит, в случае веба может определить, какой именно сайт просматривает пользователь. Такая утечка — это плохо, поэтому при разработке новой версии TLS 1.3 рассматривались различные методы защиты поля SNI. Однако, по соображениям совместимости и оптимизации работы серверов с новой версией протокола, все эти предложения остались за рамками основной спецификации TLS. Но SNI все же зашифруют: предложен черновик RFC, использующий ключи, размещаемые в DNS. Данная технология, получившая название ESNI, уже реализована в браузере Firefox и поддерживается крупным провайдером услуг хостинга веб-ресурсов Cloudflare. Таким образом, при условии массового внедрения ESNI, для систем блокирования станет недоступен еще один из важных источников метаинформации — поле SNI в TLS.

В TLS 1.3 был скрыт и другой важный для блокирования источник метаинформации — TLS-сертификаты, содержащие имя узла, с которым устанавливается соединение. Кроме того, сам сертификат и входящие в его состав криптографические ключи могут служить точным маркером узла. До выхода TLS 1.3 сертификаты сервера передавались в открытом виде на начальном этапе установления соединения, а в новой версии практически сразу включается защищенный режим и сертификаты передаются в зашифрованном виде.

Криптография повсюду

Внедрение криптографических механизмов защиты информации идет сейчас довольно активно, и уже скоро трафик приложений в Сети может стать полностью непрозрачным, а вся метаинформация будет сводиться к IP-адресам узлов, установившим соединение. Все это затруднит анализ трафика и избирательное блокирование. Блокирование же трафика по IP-адресам несет немало побочных эффектов, что, впрочем, вряд ли способно предотвратить его использование. Предельным вариантом здесь может быть использование белых списков узлов, но тогда это будет уже не Интернет, а закрытая частная сеть.

Таким образом видно, что эффективность простого метода блокировки по IP-адресам сомнительна: в дополнение к описанным способам существуют инструменты быстрой смены IP-адресов, используемых серверами. Конечно, из-за высоких накладных расходов эти инструменты доступны далеко не везде, а только для крупных проектов. Логика процесса смены адресов по своей прямолинейности вполне соответствует прямолинейности блокирования по IP-адресу — сервис использует большой пул IP-адресов, из которых для каждого соединения случайным образом выбирается некоторое подмножество. Так как блокирующая трафик система не может заранее знать, какой адрес будет следующим, то блокирование оказывается возможным только постфактум, что не очень помогает, поскольку другие клиенты используют другие адреса. Перечень адресов может передаваться с помощью DNS либо подобной системы — устойчивый механизм доставки новых списков адресов необходим, в противном случае, если этот механизм заблокировать, через некоторое время пользователи не смогут переходить к другим адресам.

Схема «скачков по адресам» работает и для веб-ресурсов, но наиболее эффективна она для приложений, отличающихся от браузеров и не использующих, например, HTTPS. Причина все та же: для успешного блокирования требуется метаинформация о соединении. Предположим, что система, блокирующая ресурсы, просматривает весь трафик, тогда, если она может точно распознать тип трафика и выделить соединение, соответствующее конкретному приложению, это соединение может быть заблокировано еще до завершения процесса его установления. Под эти требования попадают типичные сценарии HTTPS: как уже говорилось, в HTTPS-соединении передается имя узла, поэтому системе блокировок не нужно знать IP-адрес (кстати, после того как соединение классифицировано и заблокировано, IP-адрес соответствующего сервера можно отнести к подозрительным). Если же приложение использует протокол, трафик которого специально замаскирован (например, имитирует другой протокол), то классифицировать соединение чрезвычайно трудно. Впрочем, в условиях, когда в Сети действуют только протоколы, которые система блокирования умеет классифицировать с высокой точностью, появление трафика, не укладывающегося в имеющийся список классов, само по себе является хорошим классифицирующим признаком — «зашифрованный протокол» без метаинформации может быть уверенно выявлен. Другими словами, для преодоления всеобъемлющих систем мониторинга и фильтрации трафика потребуются протоколы, использующие методы стеганографии для сокрытия самого факта установления сеанса.

Перспективы и фантастика

Любая система блокирования обязана быть активной, она не только должна подробно анализировать трафик, но и иметь инструменты имитации соединений, предназначенные для тестирования возможных подозрительных узлов (Connection probe). Это специальные программы-боты, которые имитируют обращения пользователей к скрытым сервисам и анализируют ответы для построения признаков классификации соединений, а также для добавления адресов в перечень подозрительных. Уже сейчас, несмотря на то что внедрены только простейшие системы, таким образом выявляются прокси-серверы, которые могут быть использованы для доступа к заблокированным ресурсам. С точки зрения задачи блокирования это означает, что протоколы прокси-сервисов будут изменены таким образом, что признаки наличия прокси будут видны только для подключений, использующих специальный ключ. Иначе говоря, происходит маскировка под другой тип сервиса. Например, такая маскировка уже используется некоторыми сервисами, которые полностью имитируют работу веб-сервера по HTTPS. При условии знания некоторых ключей можно внутри веб-сервера «завернуть» полезный трафик в проксирующий сегмент.

Общая эффективность системы блокирования доступа зависит от ее масштабов. Анализ трафика позволяет обнаруживать новые способы подключения к заблокированным ресурсам, и чем больше точек, из которых система анализирует трафик, тем точнее результаты. Оборотная сторона этого процесса в том, что чем больше точек, тем больше ресурсов требуется для достаточно наукоемкого анализа, однако во всем мире есть немного специалистов, способных хорошо разбирать интернет-трафик, особенно с учетом того, что существенная часть его зашифрована.

Масштабные системы блокирования узлов Интернета рано или поздно неизбежно столкнутся с противодействием распределенных систем (P2P), для которых очень сложно, а иногда и невозможно построить списки ключевых узлов.

Среди перспектив развития систем контроля трафика (именно контроля) можно отметить пропуск только авторизованного трафика. Конечно, такой вариант пока кажется фантастикой. Авторизация трафика — это развитие схемы с белыми списками. В этом случае доступ по спискам IP-адресов и имен не ограничивается, но промежуточные узлы пропускают только трафик, который содержит специальные криптографические маркеры, подтверждающие его легитимность. Коммуникация остается двусторонней, поэтому маркеры выставляются источником и получателем — приложениями, работающими на оконечных узлах, а также всеми промежуточными узлами. Для генерации валидных маркеров требуется секретный ключ, который находится внутри приложения, а для получения ключа приложение должно пройти сертификацию. Возможны варианты, когда, например, допущенный к передаче трафик несет внутри себя стеганографическое послание. О ключах, позволяющих построить стойкое к обнаружению стеганографическое соединение, стороны могут договориться даже через полностью контролируемый открытый канал, единственным строгим требованием здесь будет наличие механизма проверки подлинности каждой из сторон (аутентификации).

Однако даже в такой фантастической ситуации главной проблемой системы блокирования останется контроль пользователя над приложением: если пользователь сам разработает приложение и будет контролировать коммуникационные устройства, то обход строгой фильтрации вполне возможен.

***

Имеющиеся на сегодняшний день инфраструктура и сетевая архитектура допускают и позволяют технически реализовать массовое блокирование доступа к Интернету, в том числе полное отключение больших сегментов Сети, но точное избирательное блокирование доступа представляет собой серьезную проблему, сложность которой растет по мере появления в эволюционирующей Сети новых защищенных протоколов. Более серьезные трудности для блокирования возникают при создании наложенных пользовательских p2p-сетей, предназначенных не столько для публикации информации, сколько для быстрого обмена сообщениями. Вместе с тем глобальная сеть довольно широко задействована во многих информационных системах, поэтому в случае крупных «блэкаутов», вызванных тотальной блокировкой, возникнут нарушения в работе и других средств коммуникации.

1 Автор широко использует словосочетание «блокирование доступа к Сети» для обозначения процессов выбора IP-адресов и составления их списков, а также создания механизмов, обеспечивающих исполнение запретов, отличая его от «блокировки IP» — ситуации, когда конкретный IP-адрес включен в список адресов, по которым запрещен доступ. По сути, это виртуальный аналог механического приспособления, которое условно «присоединили» к IP-адресу, и  оно  никуда «не ходит». Отсюда такие обороты: «поставить блокировку на адрес», «снять блокировку с адреса» и т. п. — Прим. ред.

Литература

1. Александр Венедюхин. DANE — новая роль DNS в обеспечении безопасности // Открытые системы.СУБД. — 2013. — № 3. — С. 44–47. URL: www.osp.ru/os/2013/03/13035117 (дата обращения: 01.03.2019).

Александр Венедюхин (inbox@alex.vened.ru) — ведущий аналитик, «Технический центр Интернет» (Москва).