Как с помощью BRAS и DPI интернет-провайдеры удерживают абонентов. Что собой представляют DPI системы анализа и фильтрации пакетов

Deep Packet Inspection (сокр. DPI , также complete packet inspection и Information eXtraction или IX , рус. Углубленная проверка пакетов) - технология накопления статистических данных, проверки и фильтрации сетевых пакетов по их содержимому. В отличие от сетевых экранов, Deep Packet Inspection анализирует не только заголовки пакетов, но и полное содержимое трафика на всех уровнях модели OSI , начиная со второго и выше. Использование Deep Packet Inspection позволяет обнаруживать и блокировать вирусы, фильтровать информацию, не удовлетворяющую заданным критериям.

Contents

Введение / Постановка задачи защиты информации

Система DPI выполняет глубокий анализ пакетов - анализ на верхних уровнях модели OSI, а не только по стандартным номерам сетевых портов. Помимо изучения пакетов по неким стандартным шаблонам, по которым можно однозначно определить принадлежность пакета определённому приложению: по формату заголовков, номерам портов и прочему, система DPI осуществляет и так называемый поведенческий анализ трафика, который позволяет распознать приложения, не использующие для обмена данными заранее известные заголовки и структуры данных, к примеру, BitTorrent .

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

Другой проблемой, получающей всё большее распространение, является широкое применение средств шифрования сетевого трафика и использование TLS/SSL в составе протокола HTTPS , что не позволяет использовать для них классические средства глубокого анализа.

Системы DPI могут быть реализованы как программно (Tstat, OpenDPI, Hippie, L7-filter, SPID), так и аппаратно (продукты компаний Allot Communications, Procera Networks, Cisco, Sandvine). В последние годы последний вариант становится всё более популярен. Производительность данных решений может варьироваться от сотен Мбит/с до 160 Гбит/с для одного аппаратного устройства, которые также можно объединить в кластеры, увеличив производительность. Стоимость при этом может меняться от нескольких тысяч до миллионов долларов США.

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

Применение

Благодаря внедрению систем DPI, у оператора появляется мощный инструмент по решению различных задач по эксплуатации и развитию сети.

Целевая реклама

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

Реализация QoS

Система DPI может быть использована для нарушения сетевого нейтралитета - реализации QoS . Так, с помощью DPI, оператор данных может контролировать использование каналов, на которых установлены системы DPI, на 7 уровне OSI. Классическое решение задачи реализации QoS основано на построении очередей, на основании маркировки трафика служебными битами в заголовках IP, 802.1q и MPLS, с выделением приоритетного трафика (к примеру, VPN или IPTV). Данному трафику гарантируется заданная пропускная способность в любой момент времени. При этом трафик, обслуживаемый по принципу "Best Effort", к которому относится, в том числе, трафик домашних абонентов, остаётся без контроля, что даёт возможность ряду протоколов, к примеру, BitTorrent, единолично использовать всю свободную полосу.

Использование DPI предоставляет оператору возможность распределить канал между различными приложениями и вводить гибкую политику управления трафиком: к примеру, разрешить трафику BitTorrent использовать в ночное время большую часть полосы, чем днём. Другая частоиспользуемая оператором возможность: блокировка, либо существенное ограничение пропускной способности, определенного вида трафика, к примеру, VoIP-телефонии мобильными операторами, что уменьшает финансовые убытки от неиспользования пользователями услуг связи.

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

Другой стороной реализации QoS на основе DPI является возможность доступа по подписке. Правила, на основании которых выполняется блокировка, могут быть заданы посредством двух основных базисов: per-service или per-subscriber. В первом случае оговаривается, что конкретному приложению позволяется использовать определённую полосу. Во втором - привязка приложения к полосе осуществляется для каждого подписчика или группы подписчиков независимо от других, что производится через интеграцию DPI с существующими OSS/BSS системами оператора.

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

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

Использование госорганами

При помощи DPI спецслужбы могут вести наблюдение за сетевой активностью того или иного пользователя. Помимо наблюдения, можно активно влиять на данную активность, ограничивая доступ к использованию VPN, HTTPS и прочим средствам, делающим невозможным анализ сетевого контента. Кроме того, именно решения на основе DPI используются для блокировки доступа к запрещенным веб-ресурсам в США, Китае, Иране, России. Так, в Китае был разработан стандарт по DPI (Y.2770), позднее утверждённый Международным союзом электросвязи (ITU).

DPI является неотъемлемой частью систем, подобных СОРМ-2 и Эшелон.

DPI для зашифрованного трафика

HTTPS и другие протоколы шифрования получают в последние годы всё большее распространение. Шифрование защищает конфиденциальную информацию пользователей в любой точке сети, в том числе в промежуточных узлах. К сожалению, HTTPS представляет собой давнюю проблему для DPI-устройств. Поскольку полезная нагрузка пакетов зашифрована, промежуточные сетевые узлы больше не могут анализировать полезную нагрузку и выполнять свои задачи. Необходимо отметить, что применение протоколов шифрования на прикладном уровне не мешает DPI-системе анализировать трафик более низких уровней, однако существенно понижает её эффективность. Так, HTTPS не помешает DPI-системе изучить TCP-заголовок пакета, чтобы определить порт назначения и попытаться сопоставить его с определенным приложением, однако не даст проанализировать полезную нагрузку прикладного уровня: DPI-система сможет определить время, объем и назначение пакета, но не его содержимое.

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

Использование HTTPS поможет защитить данные от DPI лишь при передаче. Если DPI-система установлена на стороне сервера, с которым взаимодействует клиент, то данные будут обработаны в открытом виде. К примеру, при взаимодействиями с серверами Google, несмотря на использование ими HTTPS, DPI-системы собирают информацию для выдачи контекстной рекламы.

Чтобы решить проблему анализирования зашифрованного трафика, некоторые разрабатывающиеся сейчас DPI-системы поддерживают небезопасный механизм установки HTTPS-соединения: они, фактически, проводят MITM -атаку на протокол SSL и расшифровывают трафик на промежуточном узле. Этот подход нарушает принцип сквозного шифрования, заложенный в SSL. Кроме того, это вызывает недовольство пользователей.

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

BlindBox

Описание

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

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

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

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

Модель конфиденциальности на основе вероятной причины основывается на другой логике: промежуточный узел может расшифровать весь поток, если обнаружена подстрока трафика, совпадающая с ключевым словом известной атаки. Данная модель удобна для задач обнаружения атак, которые требуют выполнения анализа с помощью регулярных выражений или скриптов. Данная модель вдохновлена двумя причинами: первая - модель "вероятной причины" уголовного права США: поводом для нарушения конфиденциальности является только наличие причины для подозрений. Вторая - большинство правил в системе обнаружения атак Snort, использующие регулярные выражения, сперва пытаются найти ключевые слова, связанные с атакой, в пакете, а лишь затем начинают использовать поиск с использованием регулярных выражений, поскольку в противном случае обнаружение будет слишком медленным.

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

Архитектура системы

На рисунке 1 представлена архитектура системы. В ней четыре стороны - отправитель (О), получатель (П), промежуточный узел (ПУ), и генератор правил (ГП), что отражает стандартную архитектуру промежуточного узла на данный день. Генератор правил предоставляет правила атаки (также называемые сигнатурами), используемые ПУ для обнаружения атак. Каждое правило пытается описать атаку, и содержит поля: одно или несколько ключевых слов, содержащихся в трафике, информация о смещении для каждого ключевого слова, и, иногда, регулярные выражения. Роль ГП на сегодняшний день выполняют организации, такие каке Emerging Threats, McAfee, Symantec. Отправитель посылает трафик получателю через промежуточный узел, который позволяет отправителю и получателю обмениваться информацией, если он не обнаруживает сигнатур в их трафике.

Рисунок 1. Архитектура BlindBox. Закрашенные элементы обозначают алгоритмы, добавленые в BlindBox.

Рассмотрим модель применения BlindBox. Генератор правил создаёт набор правил, который содержит перечень ключевых слов, которые используются в существующих атаках или представляют интерес для изучения. ГП подписывает их с использованием своего секретного ключа, и отправляет ПУ, своему пользователю. Отправитель и получатель, доверяющие ГП, устанавливают конфигурацию HTTPS BlindBox, которая включает в себя открытый ключ ГП. После этапа инициализации, ГП больше никогда напрямую не вовлечён в протокол. Теперь речь идёт о взаимодействии между отправителем, получателем и ПУ, когда отправитель и получатель инициируют соединение в сети, контролируемой ПУ.

Установка соединения

Сперва, отправитель и получатель осуществляют обычное SSL-рукопожатие, которое позволяет им согласовать ключ . Они используют его для получения трёх ключей (к примеру, с помощью ГПСЧ):

В то же самое время, ПУ осуществляет свою собственную установку соединения для обеспечения возможности обработки трафика отправителя и получателя. В процессе обмена с отправителем и получателем, ПУ получает каждое правило от ГП детерминировано зашифрованным на ключе k - это впоследствии позволит ПУ осуществлять обнаружение. Однако, данный обмен происходит таким образом, что ПУ не узнаёт значение k, а отправитель и получатель не узнают, в чем заключаются правила. Данный обмен называется запутанным шифрованием правил, и подробно описан в статье .

В отличии от описанного выше SSL-рукопожатия, которое идентично обычному SSL-рукопожатию, запутанное шифрование правил добавляет новый процесс. Поскольку в существующих решениях, клиент обычно не связываются с DPI-узлами напрямую (в отличии от других типов промежуточных узлов, таких как явные прокси или NAT hole-punching), это лишает полной "невидимости" наличия DPI, это незначительный недостаток по сравнению с преимуществами использования BlindBox.

Отправка трафика

Чтобы отправить сообщение, отправитель должен:

(1) Зашифровать трафик с использованием классического SSL.

(2) Разбить трафик на метки (токены) путем разделения его на подстроки, взятые с различным смещением, и зашифровать результирующие метки с использованием схемы шифрования DPIEnc.

Обнаружение

Промежуточный узел получает зашифрованный SSL-трафик и зашифрованные метки. Модуль обнаружения будет выполнять поиск соответствия между зашифрованными правилами и зашифрованными метками, используя алгоритм обнаружения BlindBox. При обнаружении совпадения, выполняется предопределенное действие: отбрасывание пакета, закрытие соединения, уведомление администратора системы. После выполнения обнаружения, промежуточный узел перенаправляет SSL-трафик и зашифрованные метки получателю.

Получение трафика

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

Схема шифрования DPIEnc

Отправитель шифрует каждую метку (токен) t как:

Где “соль” (salt) - случайно выбранное число, а смысл RS (фактически, ReduceSize) поясняется далее.

Обоснуем необходимость схемы шифрования DPIEnc. Допустим, промежуточный узел передал для каждого правила r пару (r, (r)), но не ключ k. Начнем с рассмотрения простой детерминированной схемы шифрования вместо DPIEnc: шифртекст от t пусть будет равен (t). Чтобы проверить, равен ли t ключевому слову r, ПУ может проверить, выполняется ли (t) ?= (r). К сожалению, в результате стойкость будет низкой, поскольку каждое вхождение t будет иметь одинаковый шифртекст. Для решения данной проблемы, нам необходимо внести элемент случайности в шифрование. Поэтому, мы будем использовать “случайную функцию” H со случайной солью, и шифртекст будет иметь следующую структуру: salt, H(salt, (t)). Конечно же, H должна быть односторонней и псевдослучайной.

Для проверки соответствия, промежуточный узел может вычислить H(salt, (r)) основанную на (r) и соли, и затем провести проверку равенства. Типичная реализация H - SHA-1, но SHA-1 работает не так быстро, поскольку на современных процессорах AES реализовано аппаратно, и это может понизить пропускную способность. Вместо этого, в BlindBox H реализована через AES, но должна использоваться осторожно, поскольку AES имеет другие свойства безопасности. Чтобы достигнуть требуемых свойств, необходимо инициировать AES на ключе, неизвестном промежуточному узлу, пока не найдена сигнатура атаки. Именно поэтому, используется значение (t).

Теперь алгоритм целиком реализован на AES, что обеспечивает высокую скорость работы.

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

В данной реализации, RS это 2 в 40 степени, что даёт длину шифртекста в 5 байт. В результате, шифртекст более не дешифруем, что не является проблемой, поскольку BlindBox всегда дешифрует трафик из первичного SSL-потока.

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

Поскольку, очевидно, что промежуточный узел выполняет проверку для каждого правила r и метки t, итоговые временные затраты на метку находятся в линейной зависимости от числа правил, что слишком медленно.

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

Результат - значительное улучшение производительности: к примеру, для набора правил с 10 тысячами ключевых слов, логарифмический поиск на четыре порядка быстрее, чем линейный.

Протокол обнаружения

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

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

Основы

Система DPI, как видно из названия, выполняет глубокий анализ всех проходящих через неё пакетов. Термин «глубокий» подразумевает анализ пакета на верхних уровнях модели OSI, а не только по стандартным номерам портов. Помимо изучения пакетов по неким стандартным паттернам, по которым можно однозначно определить принадлежность пакета определённому приложению, скажем, по формату заголовков, номерам портов и т.п., система DPI осуществляет и так называемый поведенческий анализ трафика, который позволяет распознать приложения, не использующие для обмена данными заранее известные заголовки и структуры данных. Яркий пример тому – Bittorrent. Для их идентификации осуществляется анализ последовательности пакетов, обладающими одинаковыми признаками, таким как Source_IP:port – Destination_IP:port, размер пакета, частота открытия новых сессий в единицу времени и т.д., по поведенческим (эвристическим) моделям, соответствующим таким приложениям. Естественно, сколько производителей такого железа – столько и интерпретаций поведенческих моделей соответствующих протоколов, а значит и точность детектирования также разнится. Раз речь зашла о производителях, стоит отметить, что наиболее крупными игроками и их продуктами на рынке standalone DPI являются Allot Communications , Procera Networks , Cisco , Sandvine . Всё более и более популярными становятся интегрированные в маршрутизаторы решения DPI. Так поступают многие - Cisco, Juniper, Ericsson и т.д. по списку. Такие решения, как правило, достаточно компромиссные, и не могут предоставить весь спектр сервисов, доступных standalone решениям. Однако, для большинства задач этого вполне достаточно. Софтварные продукты, крутящиеся на серверах (такие как OpenDPI) я умышленно не указываю, их рынок весьма узок и, как правило, ограничивается корпоративными/кампусными сетями, а это немного не мой профиль. Важной отличительной особенностью настоящего DPI является возможность аналитики трафика за счёт сбора различного рода статистики с разбивкой по приложениям, по тарифным планам, по регионам, по типам абонентских устройств и т.д. По этой причине замечательный NBAR имени Cisco хоть и позволяет детектировать и осуществлять контроль трафика по приложениям, полноценным решением DPI не является, т.к. в нём отсутствует ряд важных компонентов.

Система DPI, как правило, устанавливается на границе сети оператора в разрыв существующих аплинков, уходящих от пограничных маршрутизаторов. Тем самым, весь трафик, который покидает или входит в сеть оператора, проходит через DPI, что даёт возможность его мониторинга и контроля. Для решения специфических задач можно устанавливать эту систему не на границе сети, а спускать её ниже, ближе к конечным пользователям, на уровень BRAS/CMTS/GGSN/… Это может быть полезно тем операторам, которые по ряду причин помимо утилизации внешних каналов также хотят решать задачу контроля внутренних. Естественно, здесь речь идёт о достаточно крупных сервис-провайдерах с большой распределённой сетью масштабов страны и с достаточно дорогими канальными ёмкостями.

На рынке DPI есть модели на самый разный кошелёк. Производительность представленных на рынке устройств плавает в пределах от сотен Мбит/с до 160 Гбит/с FDX в рамках одной отдельно взятой коробки, которые, как правило, можно объединять в кластеры. Соответственно, и стоимость плавает весьма серьёзно - от нескольких тысяч до миллионов долларов США. В случае с корпоративным сегментам решения предполагают низкоскоростные подключения по медным интерфейсам типов 10/100/1000. Операторские решения рассчитаны на подключение множества линков 1GE и 10GE. Что касается совсем взрослых решений, то пока что рынок 100GE интерфейсов на сетевом оборудовании достаточно скуден и дорог, но как только появится первый реальный бизнес-кейс, вендоры DPI предложат соответствующие решения, ибо у некоторых из них заготовки уже имеются.

Основная проблема всех существующих решений DPI заключается в том, что для того, чтобы однозначно определить принадлежность того или иного потока данных к одному из сетевых приложений, устройство, осуществляющее анализ трафика, должно увидеть оба направления сессии. Иными словами, входящий и исходящий трафик в пределах одного flow должны пройти через одно и то же устройство. Если оборудование понимает, что видит только одно направление в рамках сессии, оно не имеет возможности соотнести данный flow с какой-либо известной категорией трафика со всеми вытекающими последствиями. В связи с этим, когда речь заходит о контроле аплинков, встаёт очень логичный вопрос об асимметричном трафике, который для более-менее крупных операторов является не экзотикой, а обыденностью. Разные вендоры решают эту задачу по-разному:

• Cisco довольствуется половинкой сессии и пытаются определить тип сетевого приложения, используя лишь эти данные. Очевидно, что при данной методике страдает точность детектирования приложений, особенно тех, для которых требуются поведенческие модели анализа. Также в такой реализации есть ряд ограничений, накладываемых на возможности управления таким трафиком, у каждого вендора они свои.
• Sandvine для решения проблемы асимметричного трафика использует следующую идею - весь трафик, являющийся асимметричным, при помощи инкапсуляции в broadcast-фреймы пересылается на все устройства DPI, находящиеся в едином домене. В итоге данной пересылки устройства, видевшие до этого лишь одно направление в рамках сессии, увидят и второе, на основании чего можно будет осуществить полный комплекс мер по анализу и управлению трафиком. Недостаток данной схемы очевиден - при больших объёмах асимметричного трафика на сети предъявляются серьёзные требования к каналам связи, соединяющим устройства DPI на разных сайтах. В некоторых случаях, когда речь идёт об асимметрии порядков нескольких гигабит (или десятков гигабит) в секунду, данная методика неприменима в связи с высокими накладными расходами на организацию канала между сайтами.
• Умнее всех поступают Procera и Allot. Идея похожа на реализацию Sandvine с тем отличием, что между сайтами пересылается не асимметричный трафик, а метаданные, явно характеризующие его. В общем случае можно считать, что это протокольные заголовки, хотя на самом деле всё чуть сложнее. За счёт подобной оптимизации требования к межсайтовым каналам связи намного более гуманны, относительно реализации Sandvine выигрыш может быть до 95%. Предвосхищая некоторые комментарии, отвечу сразу - да, это работает, подтверждено на практике на production сетях, внедрял лично своими руками.

Ещё один важный момент, который является критичным для некоторых заказчиков - это периодичность обновления файлов сигнатур, на основании которых осуществляется анализ трафика. Некоторые вендоры делают обновление раз в квартал, некоторые - раз в неделю. В случае необходимости критическое обновление (содержащее методики обнаружения новой версии скайпа, к примеру) может выйти раньше календарного срока. Как правило, все вендоры адекватно относятся к желаниям заказчиков добавить какой-то новый протокол в список поддерживаемых и всячески помогают в этом. Не секрет, что на каждом локальном рынке существуют специфические приложения, практически отсутствующие в иных странах. В России и странах СНГ самым ярким примером является Mail.ru агент. Или, например, подобный запрос может возникнуть после выхода очередной сетевой игры, которую необходимо выделять из общего потока данных.

Что дальше?

Теперь возникает логичный вопрос – ну и что теперь со всем этим делать? У оператора появляется достаточно мощный инструмент, при умелом использовании которого можно решать различные задачи по эксплуатации сети и её развитию.

Реализация QoS

С точки зрения эксплуатации, оператор может контролировать утилизацию подключенных через DPI каналов на уровне приложений. Раньше он решать задачи реализации QoS (Quality of Service) исключительно средствами построения очередей на основании маркировки трафика служебными битами в заголовках IP, 802.1q и MPLS, выделяя наиболее приоритетный трафик (разного рода VPN’ы, IPTV, SIP и т.д.), и гарантируя ему определённую пропускную способность в любой момент времени. Трафик типа Best Effort, к которому относится весь интернет трафик домашних абонентов (HSI - High Speed Internet), оставался фактически без контроля, что давало возможность тому же Bittorrent забрать себе всю свободную полосу, что, в свою очередь, вело к деградации любых других веб-приложений. С использованием DPI у оператора появляется возможность распределить канал между различными приложениями. К примеру, в ночные часы разрешить трафику Bittorrent забирать себе больше полосы, чем днём, в часы-пик, когда в сети ходит большое количество другого веб-трафика. Другая популярная мера у многих мобильных операторов – блокировка Skype-трафика, а также любых видов SIP-телефонии. Вместо полной блокировки оператор может разрешать работу данных протоколов, но на очень низкой скорости с соответствующей деградацией качества предоставления сервиса у конкретного приложения, чтобы вынудить пользователя платить за услуги традиционной телефонии, либо за специальный пакет услуг, разрешающий доступ к VoIP-сервисам.

Subscriber Management

Важным моментом является то, что правила, на основании которых выполняется шейпинг/блокировка, могут быть заданы посредством двух основных базисов – per-service или per-subscriber. В первом случае простейшим образом оговаривается, что конкретному приложению позволяется утилизировать определённую полосу. Во втором привязка приложения к полосе осуществляется для каждого подписчика или группы подписчиков независимо от других, что производится через интеграцию DPI с существующими OSS/BSS системами оператора. Т.е. можно настроить систему таким образом, что подписчик Вася, который за неделю накачал торрентов на 100 гигабайт, до конца месяца будет ограничен по скорости скачивания этих же торрентов на уровне 70% от купленного им тарифа. А у подписчика Пети, который купил дополнительную услугу под названием «Skype без проблем», трафик приложения Skype не будет блокироваться ни при каких условиях, но любой другой – легко. Можно сделать привязку к User-Agent и разрешить браузинг только при помощи рекомендуемых браузеров, можно делать хитрые редиректы в зависимости от типа браузера или ОС. Иными словами, гибкость тарифных планов и опций ограничена лишь здравым смыслом. Если же речь идёт о трафике мобильных операторов, то DPI позволяет контролировать загрузку каждой базовой станции в отдельности, справедливо распределяя ресурсы БС таким образом, чтобы все пользователи остались довольны качеством сервиса. Разумеется, данную задачу можно решать силами мобильного ядра, но это не всегда бюджетно. Раз уж я упомянул мобильных операторов, то хотелось бы отметить, что каждый уважающий себя производитель пакетного ядра EPC (Evolved Packet Core) для LTE интегрирует в свой PDN-GW функционал DPI, заточенный под решение задач мобильных операторов.

Зачем это всё надо?

Звучит это всё, конечно, не очень оптимистично, но для многих операторов по экономическим причинам значительно дешевле поставить систему DPI для контроля утилизации каналов, чем расширять аплинки. Причём, сделать это без особых потерь абонентской базы, т.к. давно известно, что большая часть трафика генерируется примерно 5% наиболее активных абонентов. И в этом случае оператору экономически целесообразней снизить абонентскую базу, но платить меньше денег за аплинки, т.к. уйдут самые активные качальщики, из-за которых оператор вынужден каждый месяц платить немаленькую сумму за аплинки. Это ночной кошмар любого маркетолога, но в некоторых случаях потерять клиентов – выгодно. Деликатность ситуации заключается в том, что рано или поздно наступит такой момент, когда все операторы так или иначе будут что-либо шейпить при помощи DPI. Т.е. если сегодня один оператор начнёт рубить торренты, самые активные качальщики разом уйдут к другому. После этого у того сильно скакнёт загрузка его каналов и клиенты начнут жаловаться на то, что плохо работает веб-браузинг. Оператор подумает, подсчитает, и в итоге купит DPI. И так до тех пор, пока все игроки на рынке не обзаведутся подобной системой. Разумеется, установка DPI не снимает с оператора задачу по периодическому расширению аплинков и увеличению скорости доступа для подписчиков. Просто теперь эти расширения не будут бесконтрольными. Т.е. оператор всегда будет знать трафик какого типа и в каком количестве пойдёт через его каналы, это будет прогнозируемо. Разумеется, когда речь идёт о коробках стоимостью $1M, дело не только в аплинках, необходимо это понимать. Моё личное мнение в первом приближении, как пользователя услуги широкополосного доступа в интернет, заключается в том, что что-либо резать и блокировать, конечно же, плохо и совершенно неправильно. Но, глядя глазами инженера на то, какими темпами растут объёмы трафика, использование DPI становится спасением для многих операторов, т.к. торренты сегодня способны забить намертво практически любой аплинк.

Новая модель услуг

Мы плавно перешли к задаче развития сети и её услуг. Глядя на то, как подписчики пользуются купленной ими полосой, какие приложения используют, оператор может изучать потребности каждой категории подписчиков и предлагать им более гибкие и совершенные тарифные планы. К примеру, основываясь на том, что подписчики тарифа Silver активно пользуются услугами сторонней SIP-телефонии, можно предложить им дополнительный пакет, позволяющий использовать аналогичный сервис, предоставляемый оператором, но со скидкой. Остальные подписчики при желании воспользоваться более дешёвой телефонией будут мотивированы переходить на более дорогой тариф, приобретая дополнительные бонусы в виде повышения скорости. Можно придумать много кейсов, это лишь один из них. Своё видение персонализированных сервисов представила компания Allot в своей презентации, выдержки из которой упоминаются в материале, когда-то опубликованном на хабре . Подход очень интересный, и выгодный как для пользователя, так и для оператора. Тенденции развития телекоммуникационного рынка таковы, что для операторов продавать трубу, как они делают сейчас, скоро будет просто невыгодно, есть масса исследований, подтверждающих это. ARPU не увеличивается, конкуренция высока, оборудование необходимо апгрейдить всё чаще и чаще, расходы операторов растут, а желание получать прибыль никуда не девается. Задача DPI в данном разрезе - реализовать новые модели предоставления услуг конечному пользователю. Некоторые мировые операторы маленькими шагами уже двигаются к данной идее. В России, очевидно, процесс этот будет долгим и мучительным, т.к. для достижения задачи необходимо перестраивать мозги абонентов на другую частоту, что очень непросто, т.к. отучить человека не качать торренты, а покупать легальный контент - непросто. Я бы не хотел сейчас запускать дискуссию на тему «А где мне брать легальный контент?», это отдельная песня, и я очень рад, что это сдвинулось с мёртвой точки (на примере ivi, omlet, zabava и т.п. совместно с возрастающими продажами Smart TV). Надеюсь, данные проекты не заглохнут. О Netflix я пока не мечтаю, но было бы здорово.

DPI отлично умеет работать в связке с различными VAS (Value Added Services) системами, такими как антиспам, антивирус, видеооптимизаторы и т.п. Суть функционала заключается в отводе части трафика по заданным администратором критериям, на сторонние устройства, для осуществления более глубокого анализа и обработки.

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

Спецслужбы

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

Сетевой нейтралитет

И, наконец, хотелось бы сказать пару слов о многострадальном сетевом нейтралитете, который существует в некоторых странах. Если коротко, то операторам в отсутствие перегрузок на аплинках нынче запрещено блокировать трафик законных/легальных приложений. Т.е. начать выборочную блокировку любого трафика теперь разрешается только в случае возникновения перегрузки. Но, в то же время, ещё нет чётких формулировок на тему того, какие именно приложения являются законными, а какие – нет. По логике, незаконным может быть только контент, а не приложения. К примеру, детская порнография явно относится к незаконному контенту, но протоколы HTTP и Bittorrent, посредством которых можно осуществлять его передачу – вполне себе легальны. Так что тут имеется ещё достаточно большой простор для споров, а тема, на мой взгляд, весьма интересна. Пока что у нас сетевым нейтралитетом не пахнет, посему у операторов на руках - все карты для управления трафиком при помощи DPI.

Вместо заключения

Надеюсь, данная заметка помогла кому-то немного структурировать свои знания относительно DPI. Я подумаю над тем, чтобы остановиться на каких-то моментах более детально в следующих опусах, ежели на них будет спрос, тема достаточно обширна. Чтобы избежать лишней полемики - лично я, как пользователь услуг ШПД, против того, чтобы что-либо резалось и блокировалось, что ни в коем случае не мешает мне делать свою работу. С радостью отвечу на вопросы.

Провайдеры Российской Федерации, в большинстве своем, применяют системы глубокого анализа трафика (DPI, Deep Packet Inspection) для блокировки сайтов, внесенных в реестр запрещенных. Не существует единого стандарта на DPI, есть большое количество реализации от разных поставщиков DPI-решений, отличающихся по типу подключения и типу работы.

Существует два распространенных типа подключения DPI: пассивный и активный.

Пассивный DPI

Пассивный DPI - DPI, подключенный в провайдерскую сеть параллельно (не в разрез) либо через пассивный оптический сплиттер, либо с использованием зеркалирования исходящего от пользователей трафика. Такое подключение не замедляет скорость работы сети провайдера в случае недостаточной производительности DPI, из-за чего применяется у крупных провайдеров. DPI с таким типом подключения технически может только выявлять попытку запроса запрещенного контента, но не пресекать ее. Чтобы обойти это ограничение и заблокировать доступ на запрещенный сайт, DPI отправляет пользователю, запрашивающему заблокированный URL, специально сформированный HTTP-пакет с перенаправлением на страницу-заглушку провайдера, словно такой ответ прислал сам запрашиваемый ресурс (подделывается IP-адрес отправителя и TCP sequence). Из-за того, что DPI физически расположен ближе к пользователю, чем запрашиваемый сайт, подделанный ответ доходит до устройства пользователя быстрее, чем настоящий ответ от сайта.

Выявляем и блокируем пакеты пассивного DPI

Поддельные пакеты, формируемые DPI, легко обнаружить анализатором трафика, например, Wireshark.
Пробуем зайти на заблокированный сайт:

Мы видим, что сначала приходит пакет от DPI, с HTTP-перенаправлением кодом 302, а затем настоящий ответ от сайта. Ответ от сайта расценивается как ретрансмиссия и отбрасывается операционной системой. Браузер переходит по ссылке, указанной в ответе DPI, и мы видим страницу блокировки.

Рассмотрим пакет от DPI подробнее:

HTTP/1.1 302 Found Connection: close Location: http://warning.rt.ru/?id=17&st=0&dt=195.82.146.214&rs=http%3A%2F%2Frutracker.org%2F
В ответе DPI не устанавливается флаг «Don"t Fragment», и в поле Identification указано 1. Серверы в интернете обычно устанавливают бит «Don"t Fragment», и пакеты без этого бита встречаются нечасто. Мы можем использовать это в качестве отличительной особенности пакетов от DPI, вместе с тем фактом, что такие пакеты всегда содержат HTTP-перенаправление кодом 302, и написать правило iptables, блокирующее их:
# iptables -A FORWARD -p tcp --sport 80 -m u32 --u32 "0x4=0x10000 && 0x60=0x7761726e && 0x64=0x696e672e && 0x68=0x72742e72" -m comment --comment "Rostelecom HTTP" -j DROP
Что это такое? Модуль u32 iptables позволяет выполнять битовые операции и операции сравнения над 4-байтовыми данными в пакете. По смещению 0x4 хранится 2-байтное поле Indentification, сразу за ним идут 1-байтные поля Flags и Fragment Offset.
Начиная со смещения 0x60 расположен домен перенаправления (HTTP-заголовок Location).
Если Identification = 1, Flags = 0, Fragment Offset = 0, 0x60 = «warn», 0x64 = «ing.», 0x68 = «rt.ru», то отбрасываем пакет, и получаем настоящий ответ от сайта.

В случае с HTTPS-сайтами, DPI присылает TCP Reset-пакет, тоже с Identification = 1 и Flags = 0.

Активный DPI

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

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

Изучаем стандарт HTTP

Типичные HTTP-запросы в упрощенном виде выглядят следующим образом:
GET / HTTP/1.1 Host: habrahabr.ru User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/50.0 Accept-Encoding: gzip, deflate, br Connection: keep-alive
Запрос начинается с HTTP-метода, затем следует один пробел, после него указывается путь, затем еще один пробел, и заканчивается строка протоколом и переносом строки CRLF.
Заголовки начинаются с большой буквы, после двоеточия ставится символ пробела.

Давайте заглянем в последнюю версию стандарта HTTP/1.1 от 2014 года. Согласно RFC 7230, HTTP-заголовки не зависят от регистра символов, а после двоеточия может стоять произвольное количество пробелов (или не быть их вовсе).
Each header field consists of a case-insensitive field name followed by a colon (":"), optional leading whitespace, the field value, and optional trailing whitespace. header-field = field-name ":" OWS field-value OWS field-name = token field-value = *(field-content / obs-fold) field-content = field-vchar [ 1*(SP / HTAB) field-vchar ] field-vchar = VCHAR / obs-text obs-fold = CRLF 1*(SP / HTAB) ; obsolete line folding
OWS - опциональный один или несколько символов пробела или табуляции, SP - одинарный символ пробела, HTAB - табуляция, CRLF - перенос строки и возврат каретки (\r\n).

Это значит, что запрос ниже полностью соответствует стандарту, его должны принять многие веб-серверы, придерживающиеся стандарта:
GET / HTTP/1.1 hoSt:habrahabr.ru user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/50.0 Accept-Encoding: gzip, deflate, br coNNecTion: keep-alive ← здесь символ табуляции между двоеточием и значением
На деле же, многие веб-серверы не любят символ табуляции в качестве разделителя, хотя подавляющее большинство серверов нормально обрабатывает и отсутствие пробелов между двоеточием в заголовках, и множество пробелов.

Старый стандарт, RFC 2616, рекомендует снисходительно парсить запросы и ответы сломанных веб-северов и клиентов, и корректно обрабатывать произвольное количество пробелов в самой первой строке HTTP-запросов и ответов в тех местах, где требуется только один:

Clients SHOULD be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they SHOULD accept any amount of SP or HT characters between fields, even though only a single SP is required.

Этой рекомендации придерживаются далеко не все веб-серверы. Из-за двух пробелов между методом и путем ломаются некоторые сайты.

Спускаемся на уровень TCP

Соединение TCP начинается с SYN-запроса и SYN/ACK-ответа. В запросе клиент, среди прочей информации, указывает размер TCP-окна (TCP Window Size) - количество байт, которые он готов принимать без подтверждения передачи. Сервер тоже указывает это значение. В интернете используется значение MTU 1500, что позволяет отправить до 1460 байтов данных в одном TCP-пакете.
Если сервер указывает размер TCP-окна менее 1460, клиент отправит в первом пакете данных столько, сколько указано в этом параметре.

Если сервер пришлет TCP Window Size = 2 в SYN/ACK-пакете (или мы его изменим на это значение на стороне клиента), то браузер отправит HTTP-запрос двумя пакетами:

Пакет 1:
GE Пакет 2: T / HTTP/1.1 Host: habrahabr.ru User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/50.0 Accept-Encoding: gzip, deflate, br Connection: keep-alive

Используем особенности HTTP и TCP для обхода активного DPI

Многие решения DPI ожидают заголовки только в стандартном виде.
Для блокировки сайтов по домену или URI, они ищут строку "Host: " в теле запроса. Стоит заменить заголовок «Host» на «hoSt» или убрать пробел после двоеточия, и перед вами открывается запрошенный сайт.
Не все DPI можно обмануть таким простым трюком. DPI некоторых провайдеров корректно анализируют HTTP-заголовки в соответствии со стандартом, но не умеют собирать TCP-поток из нескольких пакетов. Для таких DPI подойдет «фрагментирование» пакета, путем искусственного уменьшения TCP Window Size.

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

Программа для обхода DPI

Я написал программу для обхода DPI под Windows: GoodbyeDPI .
Она умеет блокировать пакеты с перенаправлением от пассивного DPI, заменять Host на hoSt, удалять пробел между двоеточием и значением хоста в заголовке Host, «фрагментировать» HTTP и HTTPS-пакеты (устанавливать TCP Window Size), и добавлять дополнительный пробел между HTTP-методом и путем.
Преимущество этого метода обхода в том, что он полностью автономный: нет внешних серверов, которые могут заблокировать.

По умолчанию активированы опции, нацеленные на максимальную совместимость с провайдерами, но не на скорость работы. Запустите программу следующим образом:
goodbyedpi.exe -1 -a Если заблокированные сайты стали открываться, DPI вашего провайдера можно обойти.
Попробуйте запустить программу с параметром -2 и зайти на заблокированный HTTPS-сайт. Если все продолжает работать, попробуйте режим -3 и -4 (наиболее быстрый).
Некоторые провайдеры, например, Мегафон и Yota, не пропускают фрагментированные пакеты по HTTP, и сайты перестают открываться вообще. С такими провайдерами используйте опцию -3 -a

Эффективное проксирование для обхода блокировок по IP

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

Если наш компьютер находится за NAT, мы не можем просто отправить запрос на сервер ReQrypt и ожидать ответа от сайта. Ответ не дойдет, т.к. в таблице NAT не создана запись для этого IP-адреса.
Для «пробива» NAT, ReQrypt отправляет первый пакет в TCP-соединении напрямую сайту, но с TTL = 3. Он добавляет запись в NAT-таблицу роутера, но не доходит до сайта назначения.

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

Жил да был большой провайдер, пропускал пакеты, ограничивал понемногу трафик. Всем было счастье. Или почти всем. До тех пор, пока кто-то не сказал: "Нам мало средств контроля трафика". Так в уютной обжитой сети появился DPI. Эта молодая бестия со своим уставом лезет в самую глубину пакетов, куда не добраться простым файрволам.

Системы DPI (Deep Packet Inspection) приобретают всё большую и большую популярность, несмотря на их астрономическую стоимость. Сейчас почти у каждого большого вендора есть своё решение. У Cisco это Cisco SCE , у Huawei - SIG9800 , у Juniper -VXA . Есть и менее известные компании, которые производят преимущественно оборудование DPI. Например, Allot или Inline Telecom с их Sandvine . Вроде бы, даже русские ребята засветились: Traffica .

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

Какие у нас сейчас есть средства управления трафиком?

1. На основе MAC-адресов или VLAN’ов. Очень грубо.
2. По IP-адресам получателей или отправителей. Так сейчас зачастую и делают.
3. По портам TCP и UDP. Так тоже делают.
4. На прокси-серверах можно ограничить по доменному имени. Но вы представляете себе прокси-сервер для абонентов в сети провайдера?

На основе вышеуказанных параметров пакета можно строить ACL или настраивать QoS. Но, положа руку на клавиатуру, сможете вы ограничить доступ на один только блог в ЖЖ, не закрывая сам ЖЖ? А сможете вычленить трафик торрента из кучи остального?

То есть в руках у вас сейчас есть инструменты stateful файрвола, который максимум добирается до транспортного уровня (4 из 7). DPI позволяет врезаться в самую глубину пакета, анализируя данные на всех уровнях OSI с 1-го по 7-й. На то он и Deep. Даже туннели без шифрования (QinQ, GRE, MPLS и т.д.) ему по зубам.

Итак, что же он на самом деле может:

1. Собирать самую разнообразную статистику. Практически любой каприз маркетологов вы теперь преподнесёте им на блюдечке.
2. Фильтровать (вычленять) трафик по определённым критериям. Тут к очевидным IP-адрес+порт прибавляются доменные имена и протоколы. Например, сложновычисляемый трафик P2P или Skype определяется тут на ура.
3. Применять на абонентов всевозможные политики. Они могут быть, как статическими - вы сами выбираете кому, что и когда можно, и с какими приоритетами - так и динамическими - есть где-то один централизованный сервер, который отвечает на эти вопросы. К слову, абонентами могут быть не только обычные пользователи фиксированных сетей, но, также, к примеру, и беспроводных, со всеми присущими атрибутами (могут отслеживаться APN, номера телефонов, способ доступа - GERAN, UTRAN...)
4. Предотвращение атак. Речь идёт о сетевых атаках извне, таких как DoS, сканирование портов. Также детектируются некоторые атаки изнутри
5. Благодаря возможности зеркалирования и перенаправления трафика возможны всякие приятные штуки, вроде проверки почты на спам или трафика с вебсайтов на вирусы.

Каким образом шайтан-машина определяет атаки и принадлежность трафика тем или иным протоколам? Для этого у неё есть три пути:

1. Явно заданные правила..ru" в заголовке HTTP;
2. Сигнатуры. Они подготавливаются вендором и содержат набор самых разнообразных правил, на основе которых будет фильтроваться трафик. Вполне возможно, что этот файл будет подготовлен с учётом ваших пожеланий. Файл сигнатур периодически обновляется и, в зависимости от производителя, либо автоматически скачивается оборудованием, либо нужно сделать это вручную;
3. Анализ поведения. В этом пункте вся философия слова Deep в названии. Многие системы DPI позволяют на основе "странностей" в поведении трафика совершать действия - определить протокол или обнаружить и предотвратить атаку.

Самый простой пример: запустили вы сканер портов. Программа обращается к указанному адресу и перебирает все 65 535 портов протокола TCP, например. Ежу же понятно, что никакая здоровая программа не будет устанавливать такие дикие соединения - это колокольный звон для DPI, что в сети что-то неладно.

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

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

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

В плане железа DPI состоит из следующих компонентов:

1. Bypass;
2. Устройство Front-End;
3. Устройство Back-End;
4. PCRF-сервер (Policy and Charging Rules Function);
5. Коммутаторы для обеспечения связности между компонентами.

Опционально:

6. Серверы (мониторинг состояния системы, syslog);

7. Дисковые массивы (для хранения статистики и для серверов);

8. Устройства VAS (Value Added Services - проверка на спам и вирусы, родительский контроль).

Типовая схема выгляди так:

Всё это вместе занимает 2-3 стойки.Расскажу по порядку о каждом из них.

1) Bypass

Что происходит, когда в сеть вы добавляете ещё один элемент? А тем более стойку? Верно, появляется ещё одно слабое звено. Bypass призван хоть немного исправить это положение.

В сеть оно включается первым и уже к нему подключается Front-End.

У него есть два режима работы:

1. Защитный. Трафик проходит напрямую и не заворачивается на Front-End

2. Рабочий. Трафик заворачивается на Front-End, но в случае чего переключается на прямой канал, как в первом случае.

Bypass всеми силами будет пытаться удержать связь.

Ломается Front-End (сгорела плата) - трафик переключается на защитный канал.

Рвётся линк до Front-End’a (сгорел порт, повредился кабель) - трафик переключается на защитный канал.

Выключилось электричество - трафик переключается на защитный канал.

Bypass’ы бывают электрическими и оптическими. Электрические основаны на реле и применяются с медными проводами, то есть максимальная скорость, на канал 1 Гб/с.

Оптические сильно круче. Помимо того, что скорость на канал до 10 Гб/с, существует возможность зеркалирования трафика задаром - световому лучу не убудет. То есть в то время как трафик идёт по прямому каналу, его копия направляется на Front-End. Действия над трафиком никакие ещё совершать нельзя, но статистику уже собирать вполне можно.

D

2) Front-End

Это адская молотилка. Через неё несутся гигабиты, именно в нём каждый пакет разбирается по байтикам, именно в нём трафик каждого абонента подвергается экзекуции в соответствии с политиками.

По сути это очень мощный модульный маршрутизатор.

В нём есть голова - платы управления самим устройством - их, как правило, две - мастер/слейв.

Есть линейные платы, отвечающие за приём-передачу трафика, то есть физический, канальный и немного сетевой уровни.

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

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

3) Back-End

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

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

4) PCRF-сервер

Очень грубо говоря, он хранит соответствия: пользователь - номер политики. Front-End отправляет ему идентификатор абонента, тот возвращает номер политики, Front-End запрашивает подробности соответствующей политики на Back-End’e.

Как правило, PCRF-сервер один на множество сайтов.

С точки зрения сети DPI можно разделить на три части:

1) супервысокоскоростная часть;

Трафик пользователей

Исчисляется Гигабитами в секунду

2) Сеть взаимодействия компонентов (FE, BE,сервера);

Тут трафик небольшой и гагибитного (даже сотки) с лихвой. По этой сети ходит только служебная информация.

3) управление и PCRF - стык с внешней (для DPI) сетью.

Это каналы в сеть OMC (operation and maintenance center) транзит до PCRF-сервера. Также только для служебных целей - доступ на оборудование и NMS (Network Management Server).

На практике

Статистику можно собирать самую богатейшую. Приведу несколько примеров:

Общий трафик по городу с разделением по различным типам:

То же в виде пирога:

Какой хостинг видео преобладает:

Топ 10 сайтов по числу соединений:

Топ 10 сайтов по объёму трафика:

Трафик по каждому абоненту отдельно в категории WEB:

Самые активные пользователи:

А вот пример применения политик: всё делается на лету - и между командой и её эффектом проходит пара секунд.

На картинке показано действие политики, ограничивающей общий трафик до 700 кб/с, при этом приоритет на видео (зелёный), а для Р2Р (фиолетовый) гарантировано 200 кб/с.

А это пример использования просто приоритетов. Общее ограничение также на 700 кб/с, наивысший приоритет у видео (зелёный), на втором месте FTP (красный) и на последнем фиолетовый P2P

Политики тоже можно задавать очень гибко:

• ограничивать общую скорость трафика вплоть до блокировки;
• ограничивать скорость трафика по каждой категории (веб, видео, p2p, IM и так далее) отдельно вплоть до блокировки;
• выделять полосу для каждого типа трафика (например, не более мегабита/с, но 200 кб/с должно быть гарантировано);
• указывать приоритет для каждого типа.

И другие менее очевидные способы.

Я люблю всякие огромные махины, вроде КрАЗа, БелАЗа - чувствуется невообразимая мощь в урчании их двигателей и лёгкий трепет перед ними. Очень похожие ощущения от работы с DPI. Словами не передашь турбинного потока воздуха из кулеров, мигания десятков светодиодов в темноте машинного зала, тугого жгута оптических проводов, уходящих в загадочный Bypass и те, почти неограниченные, возможности, которые он предоставляет. Возможностям, которые делают вас не администратором сети, но хозяином.

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

Также DPI позволяет оптимизировать работу сети, не допуская ее перегрузок и защищая, например, от DDoS-атак. Кроме того, возможна оптимизация потока данных внутри сети за счет выделения приоритетного трафика в определенный день/время дня или для определенных категорий пользователей. Например, в ночные часы трафику с одного ресурса дозволено забирать больше полосы, чем днём. Днем же приоритет отдается другому веб-трафику.

Краткий обзор

На рынке услуг DPI представлены как иностранные, так и российские компании. Иностранные вендоры имеют большой опыт: почти все компании - Allot communications, Huawei Technologies, Procera Networks, Sandvine Incorporated - занимаются решениями DPI более 15 лет. Опыт отечественных производителей - NAPA Labs, Peter Service, VAS Experts, «Протей» - скромнее, но они привлекают клиентов за счет цены: более низкая стоимость решений в рублях - это отличное преимущество.

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

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

Представленные на рынке решения

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

Например, в линейке Procera PacketLogic представлены 6 устройств, которые отличаются по пропускной способности (от 1 Гбит/с до 600 Гбит/с), максимальному количеству подключений (от 400 тысяч до 240 миллионов), размеру аппаратной платформы (от 1U до 14U) и т. д. Младшая серия платформ PL1000 подойдет для серверов отчетности, статистики и трендов, а серия PL20000 имеет операторский класс и уже способна идентифицировать сетевой трафик при помощи DRDL в режиме реального времени, а также работать с асимметричным трафиком.

Стоит отметить решение компании Allot Communications. Устройства серии Allot NetEnforcer – это аппаратные комплексы для анализа и управления сетевым трафиком, которые оптимизируют услугу предоставления широкополосного доступа в интернет корпоративным пользователям и интернет-провайдерам. Решение также справляется с определением и разделением типа трафика (p2p, video, skype и т. п.).

Другой комплекс компании – Allot Service Gateway – создан для операторов сотовой связи. Шлюз позволяет идентифицировать трафик на скоростях до 160 Гбит/с, проводить его анализ и визуализацию для оптимизации полосы пропускания и улучшения качества сервиса.

Что касается российских производителей, то они тоже стараются не отставать. Мы в компании VAS Experts также специализируемся на создании и внедрении сервисов в области контроля и анализа трафика.

Например, в нашем портфеле есть система «СКАТ », которая имеет 6 аппаратных платформ: от «СКАТ-6» (6 Гбит/с, до 400 тысяч абонентов, 1U) до «СКАТ-160» (160 Гбит/с, до 16 миллионов абонентов, 3U). «СКАТ» различает более 6000 протоколов, может работать в 3 режимах («в разрыв», асимметрия исходящего трафика, зеркало трафика), управлять абонентами с динамическим IP и поддерживает несколько видов Netflow.

Еще одна российская компания Napa Labs выпускает программно-аппаратный комплекс DPI Equila операторского класса в двух вариантах с разной функциональностью, при этом рассчитывая на интерес интернет-провайдеров и корпоративных клиентов:

Другие вендоры нацелены лишь на отдельный сегмент рынка. Например, НТЦ «ПРОТЕЙ» поставляет программно-аппаратный комплекс «ПРОТЕЙ DPI» для операторов связи. Решения компании отличаются производительностью и решают задачи по анализу трафика и управлению им, предоставлению дополнительных услуг (VAS) и ограничению доступа к определенным ресурсам.

Компания Huawei предоставляет системы только для интернет-провайдеров. Её решение - это система для анализа трафика SIG9800-X - сервисный шлюз операторского класса, построенный на платформе маршрутизации. Она позволяет выполнять все функции DPI: анализ и управление трафиком, визуализацию отчетов по использованию полосы пропускания приложениями, QoS и защиту от сетевых атак.

Отдельные компоненты

Некоторые решения предоставляют дополнительные функции за отдельную плату. Помимо широкой линейки решений, мы в VAS Experts предлагаем на выбор 3 варианта лицензии для любой платформы «СКАТ» и дополнительный компонент – КЭШ Сервер.

Peter-Service предлагает на выбор 4 компонента своей DPI-системы TREC. Сюда относятся:

• программная библиотека TREC.SDK для анализа трафика по технологии DPI (Deep Packet Inspection)
• программные продукты TREC.Analyser и TREC.MDH для мониторинга, хранения и анализа трафика, а также управления им
• программно-аппаратные комплексы для обработки трафика с предельной пропускной способностью в 10 Гбит/с, 80 Гбит/с и 600 Гбит/с
• Professional Services - услуги по консультированию в области применения технологии DPI

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

Виртуальные платформы

Главный плюс виртуальных платформ - возможность установки на любом совместимом железе. Такая опция есть далеко не у всех вендоров, что объясняется использованием иностранными системами специального аппаратного обеспечения. Но такую возможность предоставляет Procera на PacketLogic/V Platform и Sandvine на PTS Virtual Series. Что касается отечественного рынка, то развернуть свое решение в виртуальной среде предлагает Peter-Service.

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

Заключение

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

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

Дополнительное чтение