Всевидящее око DPI. Как работает глубокая инспекция пакетов и как от нее скрыться

Многие страны мира начали повсеместно внедрять технологии для слежки за своими гражданами и анализа их поведения. Механизмы вроде DPI ограничивают нашу свободу в Сети. Чтобы вступить в честный бой с этими механизмами, очень важно разобраться, как все устроено внутри.

Провайдеры и DPI

У провайдеров есть две проблемы:

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

И та и другая проблема решается ограничением отдельных запросов или протоколов, с чем справляется тот самый глубокий анализ пакетов — DPI.

Рядовых пользователей это лишает многих возможностей. Провайдер, например, способен заблокировать или сильно замедлить весь трафик протокола BitTorrent, так что качать торренты станет невозможно. Или, ради дополнительной выгоды, может «отключать» VoIP и Skype для всех пользователей, кроме тех, кто специально оплатил доступ.

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

Сетевая модель

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

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

  • Самый первый уровень связи основан на физических процессах. Он позволяет определять и связывать устройства, работая с аппаратными адресами: это в первую очередь ARP, L2TP и PPP.
  • Второй слой, уровень маршрутизации, затрагивает адреса IP и создает логическую связь между узлами IPv4, IPv6 и IPsec. Оба эти уровня — ключевые, они описывают основу, то, как компьютеры могут друг друга найти.
  • Третий уровень — транспортный — занимается данными: что передавать и насколько качественно это делать. TCP и UDP — два ключевых протокола, которые занимаются передачей данных на этом уровне, обеспечивают сохранность информации и ее порядок. Благодаря им все соединения строго регулируются.
  • Последний, четвертый уровень — прикладной, поэтому его описание очень широко (из-за невообразимо большого количества протоколов), а использование не обязательно, не все приложения это делают. Но если используют, то за дело берутся протоколы HTTP и WebSocket, чтобы ты мог сидеть в интернете, играть в MMORPG и чатиться. Протокол FTP используется в основном для обмена файлами, а POP и IMAP — электронной почтой.
Пример инкапсуляции данных через соединение HTTP

Оборудование DPI обычно работает с транспортным уровнем, пакетами TCP и UDP, читая не только заголовки, но и содержимое пакетов.

Анализ пакетов данных

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

HTTP

Давай разберемся, например, с HTTP — самым популярным протоколом. Отправим запрос на http://xakep.ru.

GET / HTTP/1.1
Host: xakep.ru

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.


Комментарии (8)

  • Статья очень слабая, обоснование необходимости написать ее такой в комментах и то информативней и интересней.

  • Очень поверхностная статья. О работе DPI мало что сказано.
    Касательно обходов блокировки - по тоннелям всё понятно. Это самый верный (на данный момент) способ, ибо для DPI это будет просто VPN, который пока что у нас в стране разрешён.
    По изменению регистра и изменою размера пакета - это возможно будет работать только на самых безнадёжных DPI системах. Потому что на любой нормальной сетевой софтине, что ставится в разрыве, всегда есть reassembler, а поиск в хедере по паттернам (стоит сказать что «вычленение» урла, типа запроса, версию протокола, и прочую информацию по потоку, называться metadata extraction) по всем канонам должен выполняться как case-insensitive, ибо регистр никак не влияет на обработку запроса на конечном сервере.

    Также не совсем понятно почему вы описываете что блокировка выполняется по IP и теряется доступ ко всем ресурсам на сервере. Это не так. Во-первых, любое обращение по урлу сопровождается dns запросом. (Возможно он может быть захеширован, но это другой случай). Адрес полученный для урла конкретным абонентом (DNS Answer) - сохраняется. Затем от абонента тут же улетает запрос на хендшейк (на IP полученный из DNS ответа). Затем идёт ответ от сервера, где в полях пакета можно найти домен, для которого устанавливается соединение. Тут DPI и рубит коннект отсылая RST для обоих потоков и/или перенаправляя пользователя на страницу с сообщением о блокировке ресурса.

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

    • Статья, к сожалению, не может быть настолько глубокой, насколько этого хочется, так как большинство DPI-решений (если не все) - закрытое, проприетарное ПО, и, следовательно, внутрь залезть и исследовать всё возможным не представляется.

      Изменение регистра заголовков и размера пакета все еще работает, так как "безнадёжных" систем в России полно (никто не хочет тратить лишние деньги, если и так работает).

      Reassembler, может, и работал бы хорошо, да вот незадача - у крупных провайдеров не одна и не две DPI-системы. И в таком случае трафик даже одного клиента невозможно проводить через один и тот же сервер, а значит, есть вероятность, что разные сервера увидят разные куски, и каждый из них пропустит данные. Даже внутренний обмен метаданными внутри, между серверами анализа, не помогает: слишком большой объем, необходима большая пропускная способность, есть задержка - всё это способствует успешной работе трюка с TCP Window Size.

      В случае блокировки по IP всё же блокируется как весь ресурс, так и соседние с ним (исключение составляют крупные сервисы со множеством дублирующих серверов, где блокировка одного IP не затрагивает остальные):
      Сначала производится DNS Query по URL от клиента: он получает A-записи об IP-адресах хоста (для DNS мы можем обеспечить отсутствие цензуры, равно как и шифрование DNSSEC, например, взять любой крупный, хоть 1.1.1.1 или 8.8.8.8).
      Затем происходит TCP-handshake. Уже на этом этапе провайдеры блокируют соединение, сразу после хэндшейка отправляя поддельный запрос с флагом RST. До http(s) дело даже не доходит, если блокировка идёт по IP-адресу сайта.
      Если же на одном и том же оборудовании (и, соответственно, на общем IP address) сидят несколько сайтов, например, с роутингом на nginx, когда запросы с разными директивами Host идут на разные внутренние порты, то в таком случае ранний RST не позволяет даже отправить HTTP-запрос, не говоря о каком-то роутинге и определении hostname. А значит, запрос не будет отправлен ни к блокируемому сервисы, ни к остальным.

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

    • Судя по тому как работает emmet.io через ростелеком, они просто дропают пакеты, не обременяя себя оповещением клиента о том, что соединение разорвано, не говоря уже о перенаправлении.

      • Подтверждаю. И даже не РТК... С VPN норм.

        • Тоже подтверждаю. А что с этим фреймворком не так? За что забанен?