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

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

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

Система 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.

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

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

Трудности с обнаружением приложений связаны, в первую очередь, с эволюцией самих приложений и сетевых протоколов которые они используют. Всё больше приложений используют динамически назначаемые порты, и поэтому традиционных методов квалификации сетевых соединений по статическим портам TCP/UDP уже недостаточно. Приложения становятся более закрытыми и непрозрачными, зачастую используются различные механизмы шифрования и туннелирования. Многие приложения в рамках сессий предполагают как передачу данных, так и одновременную передачу голосовых и видео потоков. Для доступа к приложениям удобно использовать Web-интерфейс, так как при этом не требуется инсталляции дополнительного клиентского программного обеспечения – пользователю достаточно иметь только Web-браузер. Использование Web-браузера удобно, доступно, и позволяет использовать любое устройство (персональный компьютер, мобильный телефон, планшет и т.д.) для доступа к приложению. Таким образом, многие приложения становятся “скрытыми” за протоколами шифрования HTTP/HTTPS, которые обеспечивают их передачу, и по сути становятся новыми транспортными протоколами.

Многие традиционные средства классификации сетевого трафика (например, NBAR) неспособны обнаруживать приложения которые используют протокол IPv6 в своем трафике.

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

Для таких целей и используется технология DPI — deep packet inspection, устройство или программный комплекс предназначенные для «глубокого»(вплоть до 7 уровня модели OSI) анализа и классификации проходящих через него пакетов. Помимо изучения пакетов по неким стандартным правилам, по которым можно однозначно определить принадлежность пакета к определённому приложению, скажем, по формату заголовков, номерам портов и т.п., система DPI осуществляет и так называемый поведенческий анализ трафика, который позволяет распознать приложения, не использующие для обмена данными заранее известные заголовки и структуры данных. Яркий пример тому – Bittorrent. На основе анализа протоколов, портов, сигнатур и т.д., DPI определяет к какому типу трафика принадлежит данный пакет и в зависимости от заданных правил может произвести какие либо действия над трафиком.

Стоит отметить, что наиболее крупными игроками и их продуктами на рынке standalone DPI являются Allot Communications , Procera Networks , Cisco , Sandvine . Всё более и более популярными становятся интегрированные в маршрутизаторы решения DPI. Так поступают многие - Cisco, Juniper, Ericsson и т.д. по списку. Такие решения, как правило, достаточно компромиссные, и не могут предоставить весь спектр сервисов, доступных standalone решениям. Важной отличительной особенностью настоящего DPI является возможность аналитики трафика за счёт сбора различного рода статистики с разбивкой по приложениям, по тарифным планам, по регионам, по типам абонентских устройств и т.д. По этой причине замечательный NBAR имени Cisco хоть и позволяет детектировать и осуществлять контроль трафика по приложениям, полноценным решением DPI не является, т.к. в нём отсутствует ряд важных компонентов. Система DPI, как правило, устанавливается на границе сети оператора в разрыв существующих аплинков, уходящих от пограничных маршрутизаторов. Тем самым, весь трафик, который покидает или входит в сеть оператора, проходит через DPI, что даёт возможность его мониторинга и контроля. Для решения специфических задач можно устанавливать эту систему не на границе сети, а спускать её ниже, ближе к конечным пользователям, на уровень BRAS/CMTS/GGSN/… Это может быть полезно тем операторам, которые по ряду причин помимо утилизации внешних каналов также хотят решать задачу контроля внутренних. Естественно, здесь речь идёт о достаточно крупных сервис-провайдерах с большой распределённой сетью масштабов страны и с достаточно дорогими канальными ёмкостями.

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

Что дальше?

Реализация 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 позволяет контролировать загрузку каждой базовой станции в отдельности, справедливо распределяя ресурсы БС таким образом, чтобы все пользователи остались довольны качеством сервиса. Разумеется, данную задачу можно решать силами мобильного ядра, но это не всегда бюджетно.

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

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

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

Мы плавно перешли к задаче развития сети и её услуг. Глядя на то, как подписчики пользуются купленной ими полосой, какие приложения используют, оператор может изучать потребности каждой категории подписчиков и предлагать им более гибкие и совершенные тарифные планы. К примеру, основываясь на том, что подписчики тарифа Silver активно пользуются услугами сторонней SIP-телефонии, можно предложить им дополнительный пакет, позволяющий использовать аналогичный сервис, предоставляемый оператором, но со скидкой. Остальные подписчики при желании воспользоваться более дешёвой телефонией будут мотивированы переходить на более дорогой тариф, приобретая дополнительные бонусы в виде повышения скорости. Можно придумать много кейсов, это лишь один из них. Подход очень интересный, и выгодный как для пользователя, так и для оператора. Тенденции развития телекоммуникационного рынка таковы, что для операторов продавать трубу, как они делают сейчас, скоро будет просто невыгодно, есть масса исследований, подтверждающих это. ARPU не увеличивается, конкуренция высока, оборудование необходимо апгрейдить всё чаще и чаще, расходы операторов растут, а желание получать прибыль никуда не девается. Задача DPI в данном разрезе - реализовать новые модели предоставления услуг конечному пользователю. Некоторые мировые операторы маленькими шагами уже двигаются к данной идее. В России, очевидно, процесс этот будет долгим и мучительным, т.к. для достижения задачи необходимо перестраивать мозги абонентов на другую частоту, что очень непросто, т.к. отучить человека не качать торренты, а покупать легальный контент - непросто.

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

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

Спецслужбы

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

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

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

Начнем с определений.

BRAS – маршрутизатор в сетях широкополосного доступа (Broadband Remote Access Server). По сути, это конечное оборудование на стороне провайдера, предназначенное для непосредственного доступа пользователей к сети Интернет.

DPI (Deep Packet Inspection) – технология накопления статистических данных, проверки и фильтрации сетевых пакетов по их содержимому. Именно по содержимому, а не по заголовку пакета, хотя последнее также возможно.

Каким образом BRAS и DPI помогают сохранить количество абонентов?

Чтобы ответить на этот вопрос, нужно понять, почему клиенты уходят. Ни для кого не секрет, что клиенты приходят за низкой ценой, а уходят из-за плохого качества услуг. Обычно это связано с потерей пакетов или с их задержкой на уровне BRAS. Причин может быть много, но самые распространенные – недостаточная производительность аппаратного обеспечения (нагрузка на процессор, проблемы сетевого адаптера), проблемы программного характера (неоптимизированная ОС, неправильно выбранное ПО).

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

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

• использование несертифицированного оборудования;
• нарушение требований СОРМ-3;
• предоставление доступа к запрещенным ресурсам (ФЗ-139, ФЗ-187, ФЗ-398, ФЗ-114).

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

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

Какие бывают BRAS и сколько это стоит для оператора связи?

Обычно в роли BRAS выступает одна единица оборудования, в роли DPI – другая.

BRAS можно разделить на группы по исполнению и стоимости. В свою очередь, исполнение бывает программным и аппаратным, по стоимости – платное и бесплатное.

Достаточно распространенными программными Open Source (бесплатным) решениями являются:

• Accel-ppp (существует для большинства версий Linux);
• mpd5 – доступен в исходниках для ОС FreeBSD.

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

Коммерческие решения могут быть как программными, так и аппаратными.

Многочисленные аппаратные решения предлагают Cisco в серии 6XXX и 7XXX и Juniper Networks – серия MX. Также набирает популярность продукция компании Huawei ME60.

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

Кроме маршрутизатора потребуется приобрести DPI. Стоимость DPI от Cisco на вторичном рынке, в частности Cisco SCE8000-2X10G-E, приблизительно равна 2,5 млн рублей.

Общая стоимость подобных систем не ограничена. Потребляемая мощность аппаратного DPI порядка 1000–1600 Ватт, монтируемый размер в стойку – 5U. Минимальная потребляемая мощность BRAS – от 500 Вт, монтируемый размер в стойку – 3U. В конечном счете мы получаем монстра минимальным размером в 8U и потребляющим в лучшем случае 1,5 кВт энергии.

А можно ли объединить BRAS и DPI в одно оборудование?

Да, такие решения есть. Но на российском рынке представлено не так много производителей подобных решений. Большинство из них не утруждаются собственной разработкой, а покупают лицензионный зарубежный движок – со всеми «дырами» для иностранных спецслужб. Единственные, кто создал систему с нуля, это компания VAS Experts с их многофункциональным СКАТ DPI . Решение настолько популярно, что установлено уже более чем у 600 провайдеров – вы читаете эти строки, а страница прошла через СКАТ DPI.

Преимущества СКАТ DPI

• В отличие от аппаратных BRAS со своей специализированной прошивкой, это универсальное решение. Программная часть СКАТ DPI может быть установлена на любом сервере архитектуры x86-64, в том числе на уже имеющемся в организации.
• Собственный RADIUS-сервер, но можно использовать сторонние.
• Автоматическая обработка списка запрещенных сайтов Роскомнадзора и Минюста (ФЗ-139, ФЗ-187, ФЗ-398, ФЗ-114), в том числе и поддержка белого списка.
• Сертифицирован ССС – № ОС-3-СПД-1538.
• Протестирован Роскомнадзором (документ) в плане фильтрации интернет-трафика для операторов связи с целью ограничения доступа к запрещенным ресурсам и соблюдения российского законодательства.
• Поддержка ИС СОРМ-3 (соответствие требованиям Постановления Правительства РФ от 27 августа 2005 г. № 538).
• Предварительный фильтр для СОРМ, съёмник для СОРМ-2 и СОРМ-3.
• Полная поддержка IPv6, включая натирование.
• Занимаемое место в стойке – от 1U, минимальное энергопотребление – от 300 Вт.
• Перед покупкой его можно протестировать в собственной сети, чтобы убедиться в качестве работы.
• При желании можно интегрировать в сеть провайдера исключительно как DPI.
• Стоимость не зависит от курса валюты.
• Русскоязычная техническая поддержка.

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

Программно-аппаратный комплекс СКАТ-DPI доступен в трех вариантах комплектации:

• Entry – только фильтрация трафика в соответствии с требованиями федерального законодательства.
• Base – возможности Entry + дополнительные опции: предфильтр СОРМ, управление полосой пропускания и приоритизация трафика, отправка уведомлений абонентам.
• Complete – возможности Base + гибкое управление абонентами, поддержка белых списков, CG-NAT и защита от DDoS.

Выводы?

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

Мы прекрассно знаем что цензура это плохо. Но не смотря на старания властей усилить свое влияние в сети, они все также слабы и часто глупы. Мы уже рассказывали как . Сегодня мы познакомим вас с еще одним способом обхода блокировки сайта при помощи технологии обхода DPI(deep packet inspection)

У провайдеров в DPI бывают бреши. Они случаются от того, что правила DPI пишут дляобычных пользовательских программ, опуская все возможные случаи, допустимые по стандартам.
Это делается для простоты и скорости. Нет смысла ловить хакеров, которых 0.01%, ведь все равно эти блокировки обходятся довольно просто даже обычными пользователями.

Некоторые DPI не могут распознать http запрос, если он разделен на TCP сегменты.
Например, запрос вида «GET / HTTP/1.1rnHost: kinozal.tv……»
мы посылаем 2 частями: сначала идет «GET « , затем «/ HTTP/1.1rnHost: kinozal.tv…..» .
Другие DPI спотыкаются, когда заголовок «Host:» пишется в другом регистре: например, «host:».
Кое-где работает добавление дополнительного пробела после метода: «GET /» => «GET /» или добавление точки в конце имени хоста: «Host: kinozal.tv.»

Как реализовать обход б на практике в системе linux

Как заставить систему разбивать запрос на части? Можно прогнать всю TCP сессию
через transparent proxy, а можно подменить поле tcp window size на первом входящем TCP пакете с SYN,ACK.
Тогда клиент подумает, что сервер установил для него маленький window size и первый сегмент с данными отошлет не более указанной длины. В последующих пакетах мы не будем менять ничего.

Дальнейшее поведение системы по выбору размера отсылаемых пакетов зависит от реализованногов ней алгоритма. Опыт показывает, что linux первый пакет всегда отсылает не более указанной в window size длины, остальные пакеты до некоторых пор шлет не более max(36,указанный_размер).

После некоторого количества пакетов срабатывает механизм window scaling и начинает учитываться фактор скалинга, размер пакетов становится не более max(36,указанный_рамер << scale_factor).

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

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

Перехватить пакет с SYN,ACK не представляет никакой сложности средствами iptables. Однако, возможности редактирования пакетов в iptables сильно ограничены. Просто так поменять window size стандартными модулями нельзя.
Для этого мы воспользуемся средством NFQUEUE. Это средство позволяет
передавать пакеты на обработку процессам, работающим в user mode.
Процесс, приняв пакет, может его изменить, что нам и нужно.

Будет отдавать нужные нам пакеты процессу, слушающему на очереди с номером 200. Он подменит window size. PREROUTING поймает как пакеты, адресованные самому хосту, так и маршрутизируемые пакеты. То есть решение одинаково работает как на клиенте, так и на роутере. На роутере на базе PC или на базе .
В принципе этого достаточно.

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

Создать список заблоченых доменов или скачать его с rublacklist.
Заресолвить все домены в ipv4 адреса. Загнать их в ipset с именем «zapret».
Добавить в правило:

Такии образом воздействие будет производиться только на ip адреса, относящиеся к заблокированным сайтам. Список можно обновлять через cron раз в несколько дней.
Если обновлять через rublacklist, то это займет довольно долго. Более часа. Но ресурсов этот процесс не отнимает, так что никаких проблем это не вызовет, особенно, если система работает постоянно.

Если DPI не обходится через разделение запроса на сегменты, то иногда срабатывает изменение «Host:» на «host:» . В этом случае нам может не понадобится замена window size , поэтому цепочка PREROUTING нам не нужна. Вместо нее вешаемся на исходящие пакеты в цепочке POSTROUTING :

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

Случается так, что провайдер мониторит всю HTTP сессию с keep-alive запросами. В этом случае недостаточно ограничивать TCP window при установлении соединения. Необходимо посылать отдельными TCP сегментами каждый новый запрос. Эта задача решается через полное проксирование трафика через transparent proxy (TPROXY или DNAT) . TPROXY не работает с соединениями, исходящими с локальной системы, так что это решение применимо только на роутере. DNAT работает и с локальными соединениеми, но имеется опасность входа в бесконечную рекурсию, поэтому демон запускается под отдельным пользователем, и для этого пользователя отключается DNAT через «-m owner». Полное проксирование требует больше ресурсов процессора, чем манипуляция с исходящими пакетами без реконструкции TCP соединения.

Использование модификатора пакетов NFQWS

Эта программа — модификатор пакетов и обработчик очереди NFQUEUE.
Она берет следующие параметры:
—daemon ; демонизировать прогу
—qnum=200 ; номер очереди
—wsize=4 ; менять tcp window size на указанный размер
—hostcase ; менять регистр заголовка «Host:»

Использование transparent proxy TPWS

tpws — это transparent proxy.
—bind-addr ; на каком адресе слушать. может быть ipv4 или ipv6 адрес. если не указано, то слушает на всех адресах ipv4 и ipv6
—port= ; на каком порту слушать
—daemon ; демонизировать прогу
—user= ; менять uid процесса
—split-http-req=method|host ; способ разделения http запросов на сегменты: около метода (GET,POST) или около заголовка Host
—split-pos= ; делить все посылы на сегменты в указанной позиции. Если отсыл длинее 8Kb (размер буфера приема), то будет разделен каждый блок по 8Kb.
—hostcase ; замена «Host:» => «host:»
—hostdot ; добавление точки после имени хоста: «Host: kinozal.tv.»
—methodspace ; добавить пробел после метода: «GET /» => «GET /»
Параметры манипуляции могут сочетаться в любых комбинациях.
Есть исключение: split-pos заменяет split-http-req.

Обход блокировки сайтов у конкретных провайдеров.

mns.ru : нужна замена window size на 4
beeline (corbina) : нужна замена регистра «Host:» на протяжении всей http сессии.
dom.ru: нужно проксирование HTTP сессий через tpws с заменой регистра «Host:» и разделение TCP сегментов на хедере «Host:».
Ахтунг! Домру блокирует все поддомены заблоченого домена. IP адреса всевозможных поддоменов узнать невозможно из реестра
блокировок, поэтому если вдруг на каком-то сайте вылезает блокировочный баннер, то идите в консоль firefox, вкладка network.

Загружайте сайт и смотрите куда идет редирект. Потом вносите домен в zapret-hosts-user.txt. Например, на kinozal.tv имеются 2 запрашиваемых поддомена: s.kinozal.tv и st.kinozal.tv с разными IP адресами.
sknt.ru: проверена работа с tpws с параметром «—split-http-req=method». возможно, будет работать nfqueue, пока возможности проверить нет.

tkt: помогает разделение http запроса на сегменты, настройки mns.ru подходят
ТКТ был куплен ростелекомом, используется фильтрация ростелекома.
Поскольку DPI не отбрасывает входящую сессию, а только всовывает свой пакет, который приходит раньше ответа от настоящего сервера, блокировки так же обходятся без применения «тяжелой артиллерии» следующим правилом:

Ростелеком: см tkt

tiera: сама тиера до последнего ничего не банила. Похоже, что банит вышестоящий оператор, возможно telia. Требуется сплит http запросов в течение всей сессии.

Способы получения списка заблокированных IP

1) Внесите заблокирванные домены в ipset/zapret-hosts-user.txt и запустите ipset/get_user.sh
На выходе получите ipset/zapret-ip-user.txt с IP адресами.

2) ipset/get_reestr.sh получает список доменов от rublacklist и дальше их ресолвит в ip адреса в файл ipset/zapret-ip.txt . В этом списке есть готовые IP адреса, но судя во всему они там в точности в том виде, что вносит в реестр РосКомПозор. Адреса могут меняться, позор не успевает их обновлять, а провайдеры редко банят по IP: вместо этого они банят http запросы с «нехорошим» заголовком «Host:» вне зависимости от IP адреса. Поэтому скрипт ресолвит все сам, хотя это и занимает много времени.

Дополнительное требование — объем памяти в /tmp для сохранения туда скачанного файла, размер которого несколько Мб и продолжает расти. На роутерах openwrt /tmp представляет собой tmpfs , то есть ramdisk.
В случае роутера с 32 мб памяти ее может не хватить, и будут проблемы. В этом случае используйте следующий скрипт.

3) ipset/get_anizapret.sh. быстро и без нагрузки на роутер получает лист с https://github.com/zapret-info .

Все варианты рассмотренных скриптов автоматически создают и заполняют ipset.

Варианты 2 и 3 дополнительно вызывают вариант 1.

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

Принудительное обновление ipset выполняет скрипт ipset/create_ipset.sh

Можно внести список доменов в ipset/zapret-hosts-user-ipban.txt. Их ip адреса будут помещены в отдельный ipset «ipban». Он может использоваться для принудительного завертывания всех соединений на прозрачный proxy «redsocks».

Пример обхода блокировки сайта на debian 7

Debian 7 изначально содержит ядро 3.2. Оно не умеет делать DNAT на localhost.
Конечно, можно не привязывать tpws к 127.0.0.1 и заменить в правилах iptables «DNAT 127.0.0.1» на «REDIRECT» , но лучше установить более свежее ядро. Оно есть в стабильном репозитории:

Установить пакеты:

Собрать tpws:

Создать строчку «0 12 * * */2 /opt/zapret/ipset/get_antizapret.sh» . Это значит в 12:00 каждые 2 дня обновлять список.

Запустить службу: service zapret start
Попробовать зайти куда-нибудь: http://ej.ru, http://kinozal.tv, http://grani.ru.
Если не работает, то остановить службу zapret, добавить правило в iptables вручную,
запустить nfqws в терминале под рутом с нужными параметрами.
Пытаться подключаться к заблоченым сайтам, смотреть вывод программы.
Если нет никакой реакции, значит скорее всего указан неверный номер очереди или ip назначения нет в ipset.

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

Никто и не говорил, что это будет работать везде.
Попробуйте снять дамп в wireshark или «tcpdump -vvv -X host » , посмотрите действительно ли первый сегмент TCP уходит коротким и меняется ли регистр «Host:».

Пример обхода блокировки сайта на ubuntu 12,14

Имеется готовый конфиг для upstart: zapret.conf. Его нужно скопировать в /etc/init и настроить по аналогии с debian.
Запуск службы: «start zapret»
Останов службы: «stop zapret»
Ubuntu 12 так же, как и debian 7, оснащено ядром 3.2. См замечание в разделе «debian 7″.

Пример обхода блокировки сайта на ubuntu 16,debian 8

Процесс аналогичен debian 7, однако требуется зарегистрировать init скрипты в systemd после их копирования в /etc/init.d.
install: /usr/lib/lsb/install_initd zapret
remove: /usr/lib/lsb/remove_initd zapret

Пример обхода блокировки сайта на других linux системах.

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

Настройка файрвола для обхода блокировок сайтов.

Если вы используете какую-то систему управления фаерволом, то она может вступать в конфликт с имеющимся скриптом запуска. В этом случае правила для iptables должны быть прикручены к вашему фаерволу отдельно от скрипта запуска tpws или nfqws.
Именно так решается вопрос в случае с openwrt, поскольку там своя система управления фаерволом.- nfqueue iptables - mod - filter iptables - mod - ipopt ipset curl bind - tools

Самая главная трудность — скомпилировать программы на C.
Это можно сделать средствами кросс-компиляции на любой традиционной linux системе.
Читайте compile/build_howto_openwrt.txt.
Ваша задача — получить ipk файлы для tpws и nfqws.
Скопировать директорию «zapret» в /opt на роутер.
Установить ipk. Для этого сначала копируем на роутер ipk в /tmp, потом

Это значит в 12:00 каждые 2 дня обновлять список.

Если у вас linux x64, то вместо компиляции toolchain можно использовать пре-компилированный SDK от разработчиков openwrt.
https://downloads.openwrt.org/
Найдите вашу версию openwrt, найдите вашу архитектуру, скачайте файл «OpenWrt-SDK-*».
Фактически это тот же buildroot, только в нем уже подготовлен toolchain для нужной версии openwrt, нужной target архитектуры и хост-системы linux x64.

Прекомпилированые бинарики

Компилировать для роутеров может быть непростой задачей, требующей изучения вопроса и гугления «глюков из коробки» в openwrt SDK.
Нет кое-каких бинариков, нет кое-каких линков, в результате из коробки SDK может выдавать ошибки. Для самых распространенных архитектур собраны статические бинарики. См binaries.

Статическая сборка означает, что бинарик не зависит от типа libc (uclibc или musl) и наличия установленных so — его можно использовать сразу.
Лишь бы подходил тип CPU. У ARM и MIPS есть несколько версий. Если на вашей версии выдаются ошибки при запуске — придется собирать самостоятельно под вашу систему.

Обход блокировки https

Как правило трюки с DPI не помогают для обхода блокировки https.
Приходится перенаправлять трафик через сторонний хост. Предлагается использовать прозрачный редирект через socks5 посредством iptables+redsocks, либо iptables+iproute+openvpn. Настройка варианта с redsocks на openwrt описана в https.txt.

Все исходники данного способа можно найти тут — https://github.com/bol-van/zapret

Last updated by at Ноябрь 18, 2016 .