RFC 7754 | Технические аспекты блокировки и фильтрации интернет-услуг

RFC 7754 | Технические аспекты блокировки и фильтрации интернет-услуг

Аннотация

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

Скачать оригинальный документ на английском языке RFC 7754 PDF

 

Оглавление

1. Введение
2. Примеры фильтрации
3. Характеристики систем блокировки
3.1. Партия, которая устанавливает политику блокирования
3.2. Цели блокирования
3.2.1. Черный список против модели белого списка
3.3. Предполагаемые цели блокирования
3.4. Компоненты, используемые для блокировки
4. Оценка блокирования шаблонов проектирования
4.1. Критерии оценки
4.1.1. Область применения: какой набор хостов и пользователей затронут?
4.1.2. Гранулярность: насколько специфична блокировка? Будет ли блокирование одного сервиса также блокировать другие?
4.1.3. Эффективность: Насколько легко для ресурса или службы избежать блокировки?
4.1.4. Безопасность: как блокировка влияет на существующие доверительные инфраструктуры?
4.2. Сетевая блокировка
4.2.1. Объем
4.2.2. Зернистость
4.2.3. Эффективность и безопасность
4.2.4. Резюме
4.3. Блокировка на основе рандеву
4.3.1. Объем
4.3.2. Зернистость
4.3.3. Эффективность
4.3.4. Безопасность и другие последствия
4.3.5. Примеры
4.3.6. Резюме
4.4. Блокировка на основе конечной точки
4.4.1. Объем
4.4.2. Зернистость
4.4.3. Эффективность
4.4.4. Безопасность
4.4.5. Конечные точки сервера
4.4.6. Резюме
5. Вопросы безопасности
6. Заключение
7. Информационные ссылки
Члены IAB на момент утверждения
Благодарности
Адреса авторов

 

Статус этой заметки

Этот документ не является спецификацией Internet Standards Track; опубликовано в ознакомительных целях.

Этот документ является продуктом Совета по архитектуре Интернета (IAB) и представляет информацию, которую IAB посчитал ценным для постоянной записи. Он представляет собой консенсус Совета по архитектуре Интернета (IAB). Документы, одобренные для публикации IAB, не являются кандидатами на какой-либо уровень Интернет-стандарта; см. раздел 2 RFC 5741.

Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу http://www.rfc-editor.org/info/rfc7754.

 

Уведомление об авторских правах

Copyright (c) 2016 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа.

 

1. Введение

Первоначальная цель разработки Интернета заключалась в том, чтобы обеспечить связь между хостами. Когда эта цель была достигнута, и люди начали использовать Интернет для общения, стало очевидно, что некоторые хосты участвуют в коммуникациях, которые определенные стороны считают нежелательными. Самым известным ранним примером нежелательных коммуникаций был червь Морриса [Morris], который использовал Интернет для заражения многих хостов в 1988 году. Поскольку Интернет превратился в богатую коммуникационную среду, также существуют и механизмы, ограничивающие коммуникации, которые рассматриваются как нежелательные. от политики приемлемого использования, применяемой по неофициальным каналам, до технических механизмов блокировки.

Усилия по ограничению или запрету доступа к интернет-ресурсам и услугам развивались с течением времени. Как отмечено в [RFC4084], некоторые интернет-провайдеры выполняют фильтрацию, чтобы ограничить, какие приложения могут использовать их клиенты и какой трафик они разрешают в своих сетях. Эти ограничения часто вводятся с согласия клиента, когда клиентами могут быть предприятия или частные лица. Однако правительства, поставщики услуг и предприятия все чаще пытаются заблокировать или отфильтровать доступ к определенному контенту, трафику или услугам без ведома или согласия затронутых пользователей. В тех случаях, когда эти организации сами не контролируют сети, они обычно стремятся использовать промежуточные системы для реализации блокировки или фильтрации.

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

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

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

Фильтрация может считаться законной, незаконной, этической или неэтичной в разных местах, в разное время и разными сторонами. Этот документ предназначен для тех, кто проводит фильтрацию или рассматривает возможность проведения фильтрации и хочет понять последствия своих решений в отношении архитектуры Интернета и компромиссов, которые приходят с каждым типом стратегии фильтрации. Этот документ не представляет формулы о том, как сделать эти компромиссы; вполне вероятно, что решения по фильтрации требуют знания специфических для контекста деталей. Законность определенных форм фильтрации в определенных юрисдикциях поднимает сложные юридические вопросы, которые выходят за рамки этого документа. По тем же причинам вопросы об этике отдельных форм фильтрации также выходят за рамки.

 

2. Примеры фильтрации

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

Брандмауэры (Firewalls): Брандмауэры различных типов очень часто используются во многих точках современного Интернета [RFC2979]. Они могут быть развернуты либо на конечных хостах (под управлением пользователя или администратора), либо в сети, обычно на границах сети. Хотя глоссарий Internet Security [RFC4949] содержит расширенное определение брандмауэра, неофициально большинство людей склонны считать брандмауэр просто «чем-то, что блокирует нежелательный трафик» (см. [RFC4948] для обсуждения многих типов нежелательного трафика). ). Хотя существует много видов межсетевых экранов, есть несколько конкретных типов функциональных возможностей межсетевого экрана, на которые стоит обратить внимание.

  • Фильтрация пакетов без сохранения состояния (Stateless Packet Filtering): фильтры пакетов без сохранения состояния блокируются в соответствии с правилами, не зависящими от содержимого, например, блокируя все входящие или исходящие соединения на определенных портах, протоколах или адресах сетевого уровня. Например, блокировка исходящих подключений к порту 25.
  • Фильтрация пакетов с сохранением состояния (Stateful Packet Filtering): более сложные конфигурации требуют сохранения состояния, используемого для применения политик на основе потоков, например, блокирование входящего трафика для потоков, которые не были установлены.
  • Глубокая проверка пакетов (Deep Packet Inspection): еще более сложные конфигурации выполняют глубокую проверку пакетов и фильтруют или блокируют на основе переносимого содержимого. Многие брандмауэры включают возможности веб-фильтрации (см. Ниже).

Веб-фильтрация (Web Filtering): HTTP и HTTPS являются общими целями для блокировки и фильтрации, обычно нацеленными на определенные URI. Некоторые предприятия используют блокировку HTTP, чтобы блокировать ненужные веб-сайты, а некоторые страны требуют от своих интернет-провайдеров фильтрации HTTP и HTTPS, чтобы блокировать контент, который считается незаконным. HTTPS является проблемой для этих систем, потому что URI в запросе HTTPS передается внутри зашифрованного канала. Чтобы заблокировать доступ к контенту, доступ к которому осуществляется через HTTPS, системы фильтрации, таким образом, должны либо блокировать на основе заголовков сетевого и транспортного уровня (IP-адрес и / или порт), либо получать сертификат привязки доверия, которому доверяют конечные точки (и, таким образом, действовать как человек посередине). Эти системы фильтрации часто принимают форму «порталов» или «корпоративных прокси», представляющих свои собственные динамически генерируемые сертификаты HTTPS. (См. Дальнейшее обсуждение в разделе 5.)

Спам-фильтрация (Spam Filtering). Спам-фильтрация является одной из самых старых форм фильтрации контента. Спам-фильтры оценивают сообщения на основе множества критериев и источников информации, чтобы определить, является ли данное сообщение спамом. Например, черные списки DNS используют обратный DNS, чтобы указать, является ли IP-адрес известным источником спама [RFC5782]. Спам-фильтры могут быть установлены на пользовательских устройствах (например, в почтовом клиенте), управляться почтовым доменом от имени пользователей или передаваться на внешний подряд третьей стороне, которая действует как промежуточный прокси-сервер MX.

Изъятие доменного имени (Domain Name Seizure): ряд подходов используется для блокировки или изменения разрешения доменного имени. Один из подходов заключается в использовании унифицированной политики разрешения споров (URDP) ICANN для целей мошеннического использования имени. Другие власти могут потребовать, чтобы домены были заблокированы в пределах их юрисдикции. Было проведено серьезное исследование ценности и эффективности таких изъятий [Takedown08] [BlackLists14].

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

Изъятия могут также иметь чрезмерные последствия, поскольку доступ к контенту блокируется не только в пределах юрисдикции изъятия, но и в глобальном масштабе, даже если это может быть положительно легально в другом месте [RojaDirecta]. Когда перенаправление домена осуществляется с помощью перенаправлений на промежуточных средствах разрешения, а не на авторитетных серверах, это прямо противоречит сквозным допущениям в архитектуре безопасности DNS [RFC4033], что может привести к ошибкам проверки путем проверки конечных узлов.

Безопасный просмотр (Safe Browsing): Современные веб-браузеры предоставляют некоторые меры для предотвращения доступа пользователей к вредоносным веб-сайтам. Например, перед загрузкой URI текущие версии Google Chrome и Firefox используют службу безопасного просмотра Google, чтобы определить, является ли данный URI безопасным для загрузки [SafeBrowsing]. DNS также можно использовать для хранения сторонней информации, которая помечает домены как безопасные или небезопасные [RFC5782].

Манипулирование данными о маршрутизации и адресации. Недавно правительства вмешались в управление информацией об IP-адресации и маршрутизации, чтобы сохранить контроль над определенным набором DNS-серверов. В рамках скоординированного на международном уровне ответа на вредоносное ПО DNSChanger суд Нидерландов обязал RIPE NCC заблокировать учетные записи нескольких владельцев ресурсов в качестве средства ограничения возможности владельцев ресурсов использовать определенные блоки адресов [GhostClickRIPE] (также см. Раздел 4.3. ). Эти действия вызвали опасения, что система сертификации ресурсов нумерации и связанные с ней технологии безопасной маршрутизации, разработанные рабочей группой IETF SIDR, также могут подвергаться манипуляциям со стороны правительства [RFC6480], возможно, с целью запрета целевым сетям доступа к Интернету.

Входящая фильтрация (Ingress filtering): Поставщики сетевых услуг используют входную фильтрацию [RFC2827] [RFC3704] в качестве средства предотвращения подделки адреса источника, который используется как часть других атак.

Предотвращение потери данных (Data loss preventionDLP): Предприятие и другие сети обеспокоены потенциальной утечкой конфиденциальной информации, случайной или преднамеренной. Некоторые из инструментов, используемых для этого, похожи на основную тему документа о блокировке и фильтрации. В частности, корпоративные прокси могут быть частью решения DLP.

 

3. Характеристики систем блокировки

На общем уровне системы блокировки могут характеризоваться четырьмя атрибутами: сторона, которая устанавливает политику блокировки, цель блокировки, предполагаемая цель блокировки и интернет-компонент (ы), используемые в качестве основы системы блокировки ,

3.1. Партия, которая устанавливает политику блокирования

В число сторон, устанавливающих политику блокирования, входят правительства, суды, предприятия, операторы сетей, системы отслеживания репутации, поставщики приложений и отдельные конечные пользователи. Правительство может создавать законы, основанные на культурных нормах и / или их избранном мандате. Предприятия могут использовать культурные, отраслевые или правовые нормы для руководства своей политикой.

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

В некоторых случаях сущность параметра политики совпадает с сущностью, которая применяет политику. Например, оператор сети может установить брандмауэр на собственном сетевом оборудовании или поставщик веб-приложений может заблокировать ответы между своим веб-сервером и определенными клиентами.

В других случаях сущность параметра политики отличается от сущности, которая применяет политику. Такая политика может быть навязана субъекту принуждения, например, в случае блокировки, инициированной правительствами, или субъект принуждения может явно выбрать использование политики, установленной другими, например, в случае системы репутации, используемой фильтром спама или сервис безопасного просмотра. Поскольку политику могут применять другие, лучше всего, если ее можно будет выразить в форме, не зависящей от применяемой технологии.

3.2. Цели блокирования

Существуют различные мотивы для фильтрации:

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

3.2.1. Черный список против модели белого списка

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

3.3. Предполагаемые цели блокирования

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

Как обсуждалось в Разделе 4, дизайн системы блокировки может влиять на контент, услуги или конечные точки, отличные от тех, которые являются предполагаемыми целями. Например, когда описанные выше изъятия доменных имен предназначены для адресации определенных веб-страниц, связанных с незаконной деятельностью, путем удаления доменов из использования они влияют на все службы, предоставляемые узлами, связанными с этими именами, включая почтовые службы и веб-службы, которые могут быть не связанным с незаконной деятельностью. В зависимости от того, где блок наложен в иерархии DNS, могут быть затронуты совершенно не связанные организации.

3.4. Компоненты, используемые для блокировки

Вообще говоря, процесс предоставления интернет-услуг включает в себя три различных компонента:

  1. Конечные точки. Фактическим контентом службы обычно является протокол прикладного уровня между двумя или более хостами Интернета. Во многих протоколах есть две конечные точки, клиент и сервер.
  2. Сетевые службы: конечные точки взаимодействуют посредством набора IP-сетей, которые используют протоколы маршрутизации, чтобы определить, как доставлять пакеты между конечными точками.
  3. Службы рандеву. Конечные точки служб обычно идентифицируются идентификаторами, которые более «дружественны», чем IP-адреса. Службы рандеву позволяют одной конечной точке выяснить, как связаться с другой конечной точкой на основе идентификатора. Примером службы рандеву является система доменных имен. Распределенные хеш-таблицы (DHT) также использовались в качестве служб рандеву.

Рассмотрим, например, HTTP-транзакцию, извлекающую содержимое URI <http://example.com/index.html>. Конечная точка клиента — это конечный хост с браузером. Клиент использует DNS в качестве службы рандеву, когда выполняет запрос AAAA для получения IP-адреса для имени сервера «example.com». Затем клиент устанавливает соединение с сервером и отправляет фактический HTTP-запрос. Конечная точка сервера затем отвечает на запрос HTTP.

В качестве другого примера, в протоколе SIP две конечные точки, которые обмениваются данными, являются IP-телефонами, и служба рандеву предоставляется прокси-сервером SIP прикладного уровня, а также DNS.

Блокировка доступа к интернет-контенту, услугам или конечным точкам осуществляется путем управления одним или несколькими компонентами, участвующими в предоставлении сообщений, связанных с доступом к контенту, услугам или конечным точкам. В приведенном выше примере с HTTP успешное завершение HTTP-запроса можно было предотвратить несколькими способами:

  • [Конечная точка] Запретить клиенту сделать запрос
  • [Конечная точка] Предотвращение ответа сервера на запрос
  • [Конечная точка]. Запрет на выполнение клиентом DNS-запроса, необходимого для разрешения example.com.
  • [Сеть] Предотвращение запроса от достижения сервера
  • [Сеть] Предотвращение ответа от клиента
  • [Сеть] Предотвращение доступа клиента к DNS-серверам.
  • [Сеть] Предотвращение ответов DNS от достижения клиента
  • [Рандеву] Запрет DNS-серверам предоставить клиенту правильный IP-адрес сервера.

Те, кто хочет заблокировать связь, обычно имеют доступ только к одному или двум компонентам; поэтому их выбор относительно того, как выполнить блокировку, будет ограничен. Конечные пользователи и поставщики приложений обычно могут контролировать только свое собственное программное и аппаратное обеспечение, что означает, что они ограничены фильтрацией на основе конечных точек. Некоторые сетевые операторы предлагают услуги фильтрации, которые их клиенты могут активировать индивидуально, и в этом случае конечные пользователи могут иметь в своем распоряжении сетевые системы фильтрации. Сетевые операторы могут управлять своими собственными сетями и службами рандеву, для которых они предоставляют поддержку инфраструктуры (например, преобразователи DNS) или к которым они могут иметь доступ (например, прокси-серверы SIP), но обычно не конечные точки. Предприятия обычно имеют доступ к своим сетям и конечным точкам для целей фильтрации. Правительства могут договариваться с операторами или владельцами любого из трех компонентов, которые существуют в их юрисдикциях, для выполнения фильтрации.

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

 

4. Оценка блокирования шаблонов проектирования

4.1. Критерии оценки

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

4.1.1. Область применения: какой набор хостов и пользователей затронут?

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

Системы блокирования, как правило, рассматриваются как менее нежелательные, если область их воздействия настолько узка, насколько это возможно, но при этом остается эффективной, и до тех пор, пока влияние блокировки находится в пределах административной сферы субъекта, определяющего политику. Как упоминалось ранее, корпоративные системы блокировки обычно развертываются и, как правило, оказывают влияние на корпоративных пользователей. Тем не менее, конструктивные недостатки в системах блокировки могут привести к чрезмерному эффекту блокировки. Например, по крайней мере один поставщик услуг, блокирующий контент в соответствии с правилами, в конечном итоге заблокировал контент для нисходящих поставщиков услуг, поскольку он фильтровал маршруты к конкретным системам и не распространял исходную информацию для нисходящих поставщиков услуг в других юрисдикциях [IN-OM- фильтрация]. Другие поставщики услуг случайно утекли такие маршруты черной дыры за пределами юрисдикции [NW08]. Во избежание подобных атак была предпринята значительная работа по обеспечению безопасности BGP, но развертывание таких систем запаздывает.

4.1.2. Гранулярность: насколько специфична блокировка? Будет ли блокирование одного сервиса также блокировать другие?

Интернет-приложения построены из набора слабосвязанных компонентов или «слоев». Различные уровни служат разным целям и полагаются или предлагают различные функции, такие как маршрутизация, транспорт и присвоение имен (см. [RFC1122], особенно раздел 1.1.3). Функции на этих уровнях разрабатываются автономно и почти всегда управляются разными сторонами. Например, во многих сетях физическое и канальное соединение обеспечивается «провайдером доступа», IP-маршрутизация выполняется «интернет-провайдером», а сервисы прикладного уровня предоставляются совершенно отдельными объектами (например, веб-серверами). ). Протоколы и приложения верхнего уровня для работы полагаются на комбинации функций нижнего уровня. Функциональные возможности на более высоких уровнях имеют тенденцию быть более специализированными, поэтому многие различные специализированные приложения могут использовать одни и те же общие базовые сетевые функции.

В результате этой структуры действия, выполняемые на одном уровне, могут влиять на функциональность или приложения на других уровнях. Например, манипулирование функциями маршрутизации или именования для ограничения доступа к узкому набору ресурсов через определенные приложения, вероятно, повлияет на все приложения, которые зависят от этих функций. Как и в случае с критериями охвата, блокирующие системы обычно рассматриваются как менее нежелательные, если они очень детализированы и не наносят сопутствующего ущерба контенту или услугам, не связанным с целью блокировки [RFC4924].

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

4.1.3. Эффективность: Насколько легко для ресурса или службы избежать блокировки?

Хотя блокирование ресурса или услуги может иметь некоторый непосредственный эффект, эффективность должна оцениваться с точки зрения того, легко ли ее обойти. Простое выполнение одноразовой политики часто вряд ли будет иметь длительную эффективность (например, см. [CleanFeed] и [BlackLists14]). Опыт показывает, что в общем случае для внесения в черный список требуется постоянное ведение самого черного списка, как для добавления новых записей для нежелательного трафика, так и для удаления записей при удалении контента, нарушающего авторские права. Опыт также показывает, что в зависимости от характера блока может быть трудно определить, когда разблокировать. Например, если хост заблокирован из-за того, что он был взломан и использован в качестве источника атаки, это может быть неочевидно, когда этот сайт был исправлен.

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

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

При наличии систем черного или белого списков пользователь или приложение могут попытаться обойти фильтры несколькими способами.

Пользователи могут выбрать использование различных наборов протоколов или иным образом изменить свои характеристики трафика, чтобы обойти фильтры. В некоторых случаях приложения могут переключать свой трафик на порт 80 или 443, когда другие порты заблокированы. Либо сервисы могут быть туннелированы внутри других сервисов, проксированы взаимодействующим внешним хостом (например, анонимным перенаправителем) или просто запущены через альтернативный порт (например, порт 8080 против порта 80 для HTTP). Другим средством обхода является изменение поведения службы для использования фазы согласования динамического порта, чтобы избежать использования постоянного адреса порта.

Одним из основных мотивов для утверждения, что HTTP / 2 должен быть зашифрован по умолчанию, было то, что незашифрованный трафик HTTP 1.1 иногда блокировался или неправильно обрабатывался. Пользователи или приложения, переключающие свой трафик на зашифрованный HTTP, имеют эффект обхода фильтров, которые зависят от полезной нагрузки открытого текста HTTP.

Если голосовая связь на основе протокола SIP [RFC3261] заблокирована, пользователи, скорее всего, будут использовать приложения, которые используют собственные протоколы, которые позволяют им общаться друг с другом.

Некоторые системы фильтрации способны идентифицировать только трафик IPv4, и поэтому, переключившись на IPv6, пользователи могут избежать фильтрации. Использование IPv6 с параметрами заголовка, использование нескольких уровней туннелей или использование зашифрованных туннелей также может усложнить для систем блокирования поиск транспортных портов в пакетах, что затрудняет блокировку на основе портов. Таким образом, распространение и мобильность могут препятствовать усилиям по блокированию связи различными способами.

4.1.4. Безопасность: как блокировка влияет на существующие доверительные инфраструктуры?

Современные механизмы безопасности полагаются на доверенные узлы, обменивающиеся данными по безопасному каналу без посреднических помех. Такие протоколы, как безопасность транспортного уровня (TLS) [RFC5246] и IPsec [RFC4301], предназначены для того, чтобы гарантировать, что каждая конечная точка связи знает идентификатор другой конечной точки (точек), и что только конечные точки связи могут получить доступ к защищенному содержимому. общения. Например, когда пользователь подключается к веб-сайту банка, TLS обеспечивает безопасную передачу банковской информации пользователя банку и никому другому, обеспечивая сохранение конфиденциальности данных во время их передачи.

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

Наконец, необходимо оценить, может ли механизм блокировки использоваться конечным пользователем для эффективного определения местоположения заблокированных ресурсов, к которым затем можно получить доступ через другие механизмы, обходящие механизм блокировки. Например, Клейтон [CleanFeed] показал, как конечный пользователь может обнаружить особый режим в одной системе блокировки для эффективного обнаружения незаконных веб-сайтов, что, таким образом, противоречит цели политики механизма блокировки.

4.2. Сетевая блокировка

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

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

4.2.1. Объем

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

Независимо от того, кто отвечает за политику блокировки, принудительное применение может быть выполнено с использованием фильтрации пакетов без сохранения состояния, фильтрации пакетов с сохранением состояния или глубокой проверки пакетов, как определено в разделе 2. Хотя сетевая фильтрация пакетов без сохранения состояния имеет проблемы с гранулярностью, обсуждаемые в разделе 4.2.2, Сетевые подходы Stateful Packet Filtering и Deep Packet Inspection часто сталкиваются с несколькими техническими проблемами, которые на практике ограничивают их жизнеспособность. Например, многие проблемы возникают из-за того, что посреднику необходим доступ к достаточному объему трафика для определения блокирования.

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

Эта асимметрия означает, что посредник в сети со многими выходными точками может, в зависимости от топологии и конфигурации, видеть только половину данного сообщения, что может ограничивать объем сообщений, которые он может фильтровать. Например, фильтр, направленный на запросы, предназначенные для определенных URI, не может принимать точные решения о блокировке на основе URI, если он находится только в пути данных для ответов HTTP, а не на запросы, поскольку URI не включен в ответы. Асимметрия может быть преодолимой при наличии системы фильтрации с достаточным количеством распределенных взаимосвязанных узлов фильтрации, которые могут координировать информацию о потоках, принадлежащих одной и той же связи или транзакции, но в зависимости от размера сети это может означать значительную сложность в системе фильтрации. Иногда маршрутизацию можно заставить быть симметричной в пределах данной сети, используя конфигурацию маршрутизации, механизмы NAT или механизмы уровня 2 (например, MPLS), но эти механизмы часто являются хрупкими, сложными и дорогостоящими — и иногда могут привести к снижению производительности сети относительно асимметричной маршрутизации. Корпоративные сети также могут быть менее восприимчивы к этим проблемам, если они направляют весь трафик через небольшое количество выходных точек.

4.2.2. Зернистость

Как только посредник в сети имеет доступ к трафику, он должен определить, какие пакеты должны быть отфильтрованы. Это решение обычно основывается на некоторой комбинации информации на сетевом уровне (например, IP-адреса), транспортном уровне (порты) или прикладном уровне (URI или другой контент). Блокировка типа Deep Packet Inspection, основанная на атрибутах уровня приложения, может быть потенциально более детальной и менее вероятной, чтобы вызвать сопутствующий ущерб, чем блокирование всего трафика, связанного с конкретным адресом, что может повлиять на несвязанных жителей одного и того же адреса. Однако более узко сфокусированный таргетинг может быть более сложным, менее эффективным или более легким для обхода, чем более широкая фильтрация, и те, кто стремится к блокировке, должны сбалансировать эти атрибуты друг с другом при выборе системы блокировки.

4.2.3. Эффективность и безопасность

Независимо от уровня, на котором происходит блокировка, он может быть открыт для обхода, особенно в тех случаях, когда конечные точки сети не разрешили блокировку. Связывающие конечные точки могут запретить промежуточный доступ к атрибутам на любом уровне с использованием шифрования (см. Ниже). IP-адреса должны быть видны, даже если пакеты защищены с помощью IPsec, но блокировка на основе IP-адресов может быть тривиальной для обхода. Отфильтрованный сайт может быть в состоянии быстро изменить свой IP-адрес, используя всего несколько простых шагов: изменение одной записи DNS и предоставление нового адреса на своем сервере или перемещение своих служб на новый адрес [BT-TPB].

Действительно, Poort и соавт. [Poort] обнаружил, что «любое поведенческое изменение в ответ на блокировку доступа к The Pirate Bay не оказало постоянного влияния на общее количество загрузчиков из нелегальных источников, так как новые потребители начали скачивать из нелегальных источников, и люди учатся обходить блокировку в то время как новые нелегальные источники могут быть запущены, что приведет к повторному увеличению общего доступа к файлам «, и что эти результаты» соответствуют тенденции, обнаруженной в литературе, что любые последствия судебных исков против совместного использования файлов часто исчезают по истечении обычно шести месяцев.

Если содержимое приложения зашифровано с помощью протокола безопасности, такого как IPsec или TLS, то посреднику потребуется возможность расшифровать пакеты для проверки содержимого приложения или прибегнуть к статистическим методам, чтобы угадать, что такое содержимое. Поскольку протоколы безопасности обычно предназначены для обеспечения сквозной безопасности (т. е. Для предотвращения проверки содержимого посредниками), посреднику потребуется маскироваться под одну из конечных точек, нарушая аутентификацию в протоколе безопасности, снижая безопасность затронутые пользователи и услуги и вмешивающиеся в законное частное общение. Кроме того, различные методы, использующие открытые базы данных с ключами из белого списка (например, DANE [RFC6698]), позволяют пользователям обнаруживать такого рода посредников. Эти пользователи могут действовать так, как будто служба заблокирована.

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

Однако, как недавно продемонстрировал проект Telex [Telex], если конечная точка взаимодействует с ретранслятором в сети (например, станцией Telex), она может создать туннель TLS, который неотличим от законного трафика. Например, если интернет-провайдер, используемый банковским веб-сайтом, должен был управлять станцией Telex на одном из своих маршрутизаторов, то система блокировки не сможет отличить законный зашифрованный банковский трафик от трафика, транслируемого по телексу (потенциально несущего контент, который был бы фильтруют).

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

Правительствам и операторам сетей следует, однако, позаботиться о том, чтобы не поощрять использование небезопасных коммуникаций для обозначения имен безопасности, поскольку это неизменно подвергает их пользователей различным атакам, которые были предприняты протоколами безопасности для предотвращения.

Некоторые операторы могут предполагать, что для их целей достаточно только блокирования доступа к ресурсам, доступным по незащищенным каналам, т. Е. Размер базы пользователей, которые захотят использовать безопасные туннели и / или специальное программное обеспечение для обхода блокировки, достаточно низок. сделать блокировку через посредников стоящей. Исходя из этого предположения, можно решить, что нет необходимости контролировать безопасный трафик и, таким образом, сетевая блокировка является привлекательным вариантом.

Тем не менее, чем дольше существуют такие блокирующие системы, тем выше вероятность того, что станут доступны эффективные и простые в использовании инструменты туннелирования. Например, распространение сети Tor и ее все более изощренные методы предотвращения блокировок показывают, что за этой тенденцией стоит энергия [Tor]. Таким образом, сетевая блокировка со временем становится менее эффективной.

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

Одна из причин — это огромная проблема, связанная с блокировкой сети: Интернет был разработан с той предпосылкой, что люди захотят подключиться и общаться. IP будет работать на всех, вплоть до почтовых голубей [RFC1149]. Он часто работает поверх TLS и предназначен для работы на других протоколах, которые сами работают поверх IP. Из-за этого фундаментального многоуровневого подхода почти любой авторизованный канал связи может использоваться в качестве транспорта. Эта же «проблема» позволяет коммуникациям преуспевать в самых сложных условиях.

 

4.2.4. Резюме

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

 

4.3. Блокировка на основе рандеву

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

Глобальные службы рандеву состоят из общих технических баз данных, предназначенных для записи определенных фактов о сети. Например, DNS хранит информацию о том, какие серверы предоставляют услуги для данного имени, а инфраструктура открытых ключей ресурсов (RPKI) хранит информацию о том, каким организациям были назначены IP-адреса. Чтобы предлагать специализированные интернет-сервисы и приложения, разные люди по-разному полагаются на эти общие записи. Таким образом, последствия изменений в базах данных предсказать гораздо сложнее, чем, например, эффект выключения веб-сервера (который выполняет конкретную цель обслуживания веб-контента).

Хотя службы рандеву обсуждаются как единая категория, точные характеристики и последствия блокирования каждого вида службы рандеву немного отличаются. В этом разделе приведены примеры, чтобы подчеркнуть эти различия.

4.3.1. Объем

В случае блокировки, инициированной правительством, операторам серверов, используемых для предоставления услуг рандеву, которые подпадают под действие конкретной юрисдикции, может потребоваться заблокировать или отфильтровать. Таким образом, структурирование законов может привести к блокировке путем наложения обязательств на операторов служб рандеву в пределах юрисдикции, либо путем прямых действий правительства, либо путем разрешения частным субъектам требовать блокировку (например, посредством судебных процессов).

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

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

4.3.2. Зернистость

Блокировка в глобальной службе рандеву может быть чрезмерной, если заблокированные ресурсы поддерживают несколько служб, поскольку блокирующая служба может нанести сопутствующий ущерб законному использованию других служб. Например, данный адрес или доменное имя могут содержать как законные службы, так и службы, которые некоторые захотят заблокировать.

4.3.3. Эффективность

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

Конечные точки также могут не использовать конкретную службу рандеву. Они могут переключиться на конкурента или использовать альтернативный механизм (например, литералы IP в URI для обхода фильтрации DNS).

4.3.4. Безопасность и другие последствия

Блокирование глобальных служб рандеву также имеет ряд других последствий, которые могут снизить стабильность, доступность и удобство использования глобальной сети Интернет. Блокирование на основе инфраструктуры может подорвать доверие к общему Интернету и стимулировать развитие параллельных или «подземных» инфраструктур, вызывающих, например, формы фрагментации Интернета. Этот риск может стать более острым, так как внедрение инфраструктур и механизмов безопасности, таких как DNSSEC и RPKI, «укрепляет» достоверные данные — включая заблокированные имена или маршруты — которые предоставляют существующие сервисы инфраструктуры. Те, кто пытается обойти блоки, могут использовать менее безопасные, но разблокированные параллельные сервисы. Применительно к DNS эти соображения более подробно обсуждаются в RFC 2826 [RFC2826], в консультативном документе [SAC-056] Консультативного комитета ICANN по безопасности и стабильности (SSAC) и в официальном документе Internet Society по фильтрации DNS [ISOCFiltering], но они также относятся к другим глобальным интернет-ресурсам.

4.3.5. Примеры

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

В 2008 году Pakistan Telecom попытался запретить доступ к YouTube в пределах Пакистана, объявив фиктивные маршруты для адресного пространства YouTube для сверстников в Пакистане. YouTube был временно отказан в обслуживании в глобальном масштабе из-за утечки маршрута за пределы возможностей пакистанского интернет-провайдера, но обслуживание было восстановлено примерно через два часа, поскольку сетевые операторы по всему миру перенастроили свои маршрутизаторы, чтобы игнорировать фиктивные маршруты [RenesysPK]. В контексте SIDR и безопасной маршрутизации аналогичная реконфигурация может быть теоретически выполнена, если сертификат ресурса должен быть отозван, чтобы заблокировать маршрутизацию к данной сети.

В сфере DNS одним из недавних случаев захвата доменными именами правоохранительными органами США был испанский веб-сайт RojaDirecta. Хотя некоторые из затронутых доменных имен принадлежали испанским организациям, они были заблокированы правительством США, потому что некоторые серверы работали в Соединенных Штатах.

Правительственные чиновники требовали от операторов родительских зон целевого имени (например, «com» ​​для «example.com») направлять запросы для этого имени на набор серверов имен, управляемых правительством США. Таким образом, пользователи других служб (например, электронной почты) под целевым именем не смогут найти серверы, предоставляющие службы для этого имени, и лишат их возможности доступа к этим службам.

Обходные пути, аналогичные тем, которые использовались в случае «Пакистан Телеком», также доступны в случае с DNS. Если доменное имя заблокировано изменением авторитетных записей, операторы сети могут восстановить службу, просто расширив TTL для кэшированных записей предварительной блокировки в рекурсивных распознавателях или статически настроив преобразователи так, чтобы они возвращали неблокированные результаты для затронутого имени. Однако в зависимости от наличия действительных данных подписи эти типы обходных путей не будут работать с данными, подписанными DNSSEC.

Действия властей Нидерландов против RIPE NCC, где RIPE было приказано заморозить счета владельцев интернет-ресурсов, носят аналогичный характер. Контролируя информацию WHOIS владельцев аккаунтов, этот тип действий ограничивал возможности интернет-провайдеров управлять своими интернет-ресурсами. Этот пример немного отличается от других, потому что он не сразу влияет на способность интернет-провайдеров обеспечить подключение. В то время как интернет-провайдеры используют (и доверяют) базы данных WHOIS для создания фильтров маршрутов или используют базы данных для устранения неполадок, использование баз данных WHOIS для этих целей является добровольным. Таким образом, подобный захват может не иметь непосредственного влияния на сетевое подключение, но может повлиять на общее доверие к общей инфраструктуре. Это похоже на другие примеры того, что действия в одной юрисдикции могут иметь более широкие последствия, и в том, что глобальная система может стимулировать сети к разработке собственных автономных решений.

4.3.6. Резюме

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

4.4. Блокировка на основе конечной точки

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

В настоящее время существует несколько систем, которые сообщают пользовательским системам о том, какими коммуникациями они должны заниматься. Как уже говорилось выше, несколько современных браузеров консультируются со службами «Безопасного просмотра» перед загрузкой веб-сайта, чтобы определить, может ли сайт быть потенциально опасным. Фильтрация спама — один из самых старых типов фильтрации в Интернете; современные системы фильтрации обычно используют одну или несколько баз данных «репутации» или «черного списка» для принятия решения о том, следует ли блокировать данное сообщение или отправителя. Эти системы обычно обладают тем свойством, что многие системы фильтрации (браузеры, агенты передачи почты (MTA)) совместно используют одну службу репутации. Даже отсутствие подготовленных записей PTR для IP-адреса может привести к тому, что сообщения электронной почты не будут приняты.

4.4.1. Объем

В системе блокировки на основе конечной точки действия блокировки выполняются автономно, отдельными конечными точками или их делегатами. Таким образом, эффекты блокировки обычно имеют локальный характер, сводя к минимуму влияние на других пользователей или другие законные услуги.

4.4.2. Зернистость

Блокировка на основе конечной точки позволяет избежать некоторых ограничений блокировки на основе рандеву: в то время как блокировка на основе рандеву может видеть и влиять только на имеющуюся службу рандеву (например, разрешение имен DNS), блокировка на основе конечной точки потенциально может охватить все приложение, во всех слои и транзакции. Такая видимость может предоставить системам блокировки на основе конечных точек гораздо более богатый набор информации для принятия узких решений о блокировке. Однако поддержка узкой степени детализации зависит от того, как спроектированы клиент и сервер протокола приложения. Типичное приложение межсетевого экрана на основе конечной точки может иметь меньше возможностей для принятия детальных решений, чем приложение, которое выполняет свою собственную блокировку (см. [RFC7288] для дальнейшего обсуждения).

4.4.3. Эффективность

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

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

4.4.4. Безопасность

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

 

4.4.5. Конечные точки сервера

В этом обсуждении блокировки на основе конечных точек основное внимание было уделено потребляющей стороне сквозного взаимодействия, главным образом клиентской стороне соединения типа клиент-сервер. Тем не менее, аналогичные соображения применимы к стороне производства сквозной связи, независимо от того, является ли эта конечная точка сервером в соединении клиент-сервер или равноправным узлом в одноранговом соединении.

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

Тот факт, что конечные точки по производству контента часто не берут на себя ответственность блокировать определенные формы контента в ответ на запросы правительств или других сторон, иногда может побуждать эти последние стороны к блокированию в других местах в Интернете.

Если служба должна быть заблокирована, лучший способ сделать это — отключить службу на конечной точке сервера.

4.4.6. Резюме

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

5. Вопросы безопасности

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

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

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

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

Когда блокирующие системы не могут проверять и хирургически блокировать безопасные протоколы, возникает соблазн полностью заблокировать эти протоколы. Например, система веб-блокировки, которая не может проверить HTTPS-соединения, может просто заблокировать любое предпринятое HTTPS-соединение. Тем не менее, поскольку протоколы безопасности в Интернете обычно используются для критически важных услуг, таких как онлайн-коммерция и банковское дело, блокировка этих протоколов также блокирует доступ к этим службам или, что еще хуже, заставляет их проводить через небезопасную связь.

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

6. Заключение

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

Подходы к черному списку часто представляют собой игру в кошки-мышки, где те, у кого есть контент, перемещают его, чтобы избежать блокировки. Кроме того, содержимое может даже естественным образом зеркально отображаться или кэшироваться на других законных сайтах, таких как машина архивирования Интернета [Wayback]. В то же время белые списки представляют аналогичные риски, поскольку сайты с «приемлемым» контентом могут становиться мишенями для «недопустимого контента», и аналогичным образом доступ к совершенно безобидному и, возможно, полезному или продуктивному контенту излишне блокируется.

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

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

7. Информационные ссылки

[asymmetry] John, W., Dusi, M., and K. Claffy, «Estimating routing symmetry on single links by passive flow measurements», Proceedings of the 6th International Wireless Communications and Mobile Computing Conference, IWCMC ’10, DOI 10.1145/1815396.1815506, 2010,
<http://www.caida.org/publications/papers/2010/estimating_routing_symmetry/estimating_routing_symmetry.pdf>.

[BlackLists14] Chachra, N., McCoy, D., Savage, S., and G. Voelker, «Empirically Characterizing Domain Abuse and the Revenue Impact of Blacklisting», Workshop on the Economics of
Information Security 2014,
<http://www.econinfosec.org/archive/weis2014/papers/Chachra-WEIS2014.pdf>.

[BT-TPB] Meyer, D., «BT blocks The Pirate Bay», June 2012, <http://www.zdnet.com/bt-blocks-the-pirate-bay-4010026434/>.

[CleanFeed] Clayton, R., «Failures in a Hybrid Content Blocking System», Fifth Privacy Enhancing Technologies Workshop, PET 2005, DOI 10.1007/11767831_6, 2005,
<http://www.cl.cam.ac.uk/~rnc1/cleanfeed.pdf>.

[GhostClickRIPE] RIPE NCC, «RIPE NCC Blocks Registration in RIPE Registry Following Order from Dutch Police», 2012,
<http://www.ripe.net/internet-coordination/news/about-ripe-ncc-and-ripe/ripe-ncc-blocks-registration-inripe-registry-following-order-from-dutch-police>.

[IN-OM-filtering] Citizen Lab, «Routing Gone Wild: Documenting upstream filtering in Oman via India», July 2012,
<https://citizenlab.org/2012/07/routing-gone-wild/>.

[ISOCFiltering] Internet Society, «DNS: Finding Solutions to Illegal On-line Activities», 2012,
<http://www.internetsociety.org/what-we-do/issues/dns/finding-solutions-illegal-line-activities>.

[Malicious-Resolution] Dagon, D., Provos, N., Lee, C., and W. Lee, «Corrupted DNS Resolution Paths: The Rise of a Malicious Resolution Authority», 2008,
<http://www.citi.umich.edu/u/provos/papers/ndss08_dns.pdf>.

[Morris] Kehoe, B., «The Robert Morris Internet Worm», 1992, <http://groups.csail.mit.edu/mac/classes/6.805/articles/morris-worm.html>.

[NW08] Marsan, C., «YouTube/Pakistan incident: Could something similar whack your site?», Network World, March 2008,
<http://www.networkworld.com/article/2284273/software/youtube-pakistan-incident—could-something-similar-whackyour-site-.html>.

[Poort] Poort, J., Leenheer, J., van der Ham, J., and C. Dumitru, «Baywatch: Two approaches to measure the effects of blocking access to The Pirate Bay», Telecommunications Policy 38:383-392, DOI 10.1016/j.telpol.2013.12.008, 2014, <http://staff.science.uva.nl/~vdham/research/publications/1401-Baywatch.pdf>.

[RenesysPK] Brown, M., «Pakistan hijacks YouTube», February 2008, <http://research.dyn.com/2008/02/pakistan-hijacks-youtube-1/>.

[RFC1122] Braden, R., Ed., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989,
<http://www.rfc-editor.org/info/rfc1122>.

[RFC1149] Waitzman, D., «Standard for the transmission of IP datagrams on avian carriers», RFC 1149, DOI 10.17487/RFC1149, April 1990,
<http://www.rfc-editor.org/info/rfc1149>.

[RFC2826] Internet Architecture Board, «IAB Technical Comment on the Unique DNS Root», RFC 2826, DOI 10.17487/RFC2826, May
2000, <http://www.rfc-editor.org/info/rfc2826>.

[RFC2827] Ferguson, P. and D. Senie, «Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing», BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <http://www.rfc-editor.org/info/rfc2827>.

[RFC2979] Freed, N., «Behavior of and Requirements for Internet Firewalls», RFC 2979, DOI 10.17487/RFC2979, October 2000,
<http://www.rfc-editor.org/info/rfc2979>.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, «SIP: Session Initiation Protocol», RFC 3261,
DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.

[RFC3704] Baker, F. and P. Savola, «Ingress Filtering for Multihomed Networks», BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, DOI 10.17487/RFC4033, March 2005,
<http://www.rfc-editor.org/info/rfc4033>.

[RFC4084] Klensin, J., «Terminology for Describing Internet Connectivity», BCP 104, RFC 4084, DOI 10.17487/RFC4084,
May 2005, <http://www.rfc-editor.org/info/rfc4084>.

[RFC4301] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.

[RFC4924] Aboba, B., Ed. and E. Davies, «Reflections on Internet Transparency», RFC 4924, DOI 10.17487/RFC4924, July 2007,
<http://www.rfc-editor.org/info/rfc4924>.

[RFC4948] Andersson, L., Davies, E., and L. Zhang, «Report from the IAB workshop on Unwanted Traffic March 9-10, 2006», RFC 4948, DOI 10.17487/RFC4948, August 2007,
<http://www.rfc-editor.org/info/rfc4948>.

[RFC4949] Shirey, R., «Internet Security Glossary, Version 2», FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.

[RFC5782] Levine, J., «DNS Blacklists and Whitelists», RFC 5782, DOI 10.17487/RFC5782, February 2010,
<http://www.rfc-editor.org/info/rfc5782>.

[RFC6480] Lepinski, M. and S. Kent, «An Infrastructure to Support Secure Internet Routing», RFC 6480, DOI 10.17487/RFC6480,
February 2012, <http://www.rfc-editor.org/info/rfc6480>.

[RFC6698] Hoffman, P. and J. Schlyter, «The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA», RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.

[RFC6943] Thaler, D., Ed., «Issues in Identifier Comparison for Security Purposes», RFC 6943, DOI 10.17487/RFC6943, May 2013, <http://www.rfc-editor.org/info/rfc6943>.

[RFC7288] Thaler, D., «Reflections on Host Firewalls», RFC 7288, DOI 10.17487/RFC7288, June 2014,
<http://www.rfc-editor.org/info/rfc7288>.

[RojaDirecta] Masnick, M., «Homeland Security Seizes Spanish Domain Name That Had Already Been Declared Legal», 2011,
<http://www.techdirt.com/articles/20110201/10252412910/homeland-security-seizes-spanish-domain-name-that-hadalready-been-declared-legal.shtml>.

[SAC-056] ICANN SSAC, «SSAC Advisory on Impacts of Content Blocking via the Domain Name System», October 2012,
<http://www.icann.org/en/groups/ssac/documents/sac-056-en.pdf>.

[SafeBrowsing] Google, «Safe Browsing API», 2012, <https://developers.google.com/safe-browsing/>.

[Takedown08] Moore, T. and R. Clayton, «The Impact of Incentives on Notice and Take-down«, Workshop on the Economics of Information Security 2008,
<http://www.econinfosec.org/archive/weis2008/papers/MooreImpact.pdf>.

[Telex] Wustrow, E., Wolchok, S., Goldberg, I., and J. Halderman, «Telex: Anticensorship in the Network Infrastructure», <https://telex.cc/>.

[Tor] «Tor Project: Anonymity Online», <https://www.torproject.org/>.

[Wayback] «Internet Archive: Wayback Machine», <http://archive.org/web/>.

Члены IAB на момент утверждения

Яри Аркко (Jari Arkko)
Мэри Барнс (Mary Barnes)
Марк Бланше (Marc Blanchet)
Ральф Дромс (Ralph Droms)
Тед Харди (Ted Hardie)
Джо Хильдебранд (Joe Hildebrand)
Расс Хаусли (Russ Housley)
Эрик Нордмарк (Erik Nordmark)
Роберт Спаркс (Robert Sparks)
Эндрю Салливан (Andrew Sullivan)
Дэйв Талер (Dave Thaler)
Брайан Траммелл (Brian Trammell)
Сюзанна Вульф (Suzanne Woolf)

Благодарности

Спасибо многим рецензентам, которые предоставили полезные комментарии, особенно Биллу Херрину, Элиоту Лиру, Патрику Фальтстрому, Пекке Саволе и Рассу Уайту. NLnet Labs также признается работодателем Олафа Колкмана на протяжении большей части разработки этого документа.

Адреса авторов

Richard Barnes
Mozilla
Suite 300
650 Castro Street
Mountain View, CA 94041
United States
Email: rlb@ipv.sx

Alissa Cooper
Cisco
707 Tasman Drive
Milpitas, CA 95035
United States
Email: alcoop@cisco.com

Olaf Kolkman
Internet Society
Email: kolkman@isoc.org

Dave Thaler
Microsoft
One Microsoft Way
Redmond, WA 98052
United States
Email: dthaler@microsoft.com

Erik Nordmark
Arista
Email: nordmark@arista.com