Краткий обзор технологии DPI — Deep Packet Inspection

Новых пользователей (это 8 человек каждую секунду), в России интернет проникает в забытые деревни, а уже к 2014 году , что 70% совершеннолетнего населения страны будет онлайн .

Такая динамика крайне положительно сказывается на общей ситуации в телекоммуникациях – появляется конкуренция, растёт качество услуг, падает цена, на рынок выкидываются всё новые и новые технологии – не успели мы даже посмотреть на 40G-интерфейсы, как уже появились 100G и успешно проходят испытания 400-гигабитных (кстати, недавно на была статья о том, что Huawei тоже представило работающее решение). Пользователь утопает в высокоскоростных сервисах: youtube, безразмерные файлохранилища, онлайн-радиостанции и телевидение, торренты и P2P сети. Всё это одновременно с разных компьютеров, X-падов и телефонов. Оптику уже подводят прям к вашему домашнему маршрутизатору.
Но, как нет худа без добра, так и добро без худа большая редкость. Вместе с радостями приходят и проблемы.
Приведу лишь небольшой список наиболее важных трудностей, с которыми приходится сталкиваться сегодня провайдерам и абонентам:

Высокая загрузка канала к пользователю. При том, что сеть провайдера в порядке и трафик пользователя укладывается в его тариф, большая часть пропускной способности канала занята, например, торрентом, отчего страдает голос, HTTP и другие данные абонента
- высокая нагрузка на каналы провайдера, когда много абонентов запускают торренты или P2P
- бОльшая часть пропускной способности занимается меньшей частью наиболее активных абонентов
- вирусы, черви и зомби (боты) в сети
- DOS-атаки на оборудование провайдера или абонентов
- сканеры портов

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

Какие у вас есть возможности исправить положение в обычной ситуации?
1) Канальный уровень: контроль на основе MAC-адресов или номера VLAN. Может быть реализован на коммутаторах и маршрутизаторах.
2) Сетевой уровень: вы можете блокировать пользователей по IP-адресам или запрещать доступ на определённые адреса/подсети во внешней сети. Реализуется на маршрутизаторах.
3) Транспортный уровень: провайдер или ИТ-служба предприятия может ограничить используемые порты. Например, запретить всё, кроме портов 25, 110 и 80 (почта и HTTP). Сделать это также можно на маршрутизаторе
4) Уровень приложений: на прокси-серверах или файрволах вы можете использовать наибольшую степень абстракции — доменные имена. Но файрволы, вообще говоря, имеют более широкие возможности, например, защита против атак, тонкие настройки политик. Они также предоставляют некий функционал глубокого анализа пакетов, но по сравнению со специализированными решениями DPI он крайне ограничен.

И даже одно из популярных сейчас решений — использование в сети QoS — не панацея.

Используя вышеуказанные возможности, невозможно мониторить и контролировать трафик многих приложений и протоколов, как то: Skype в частности и VoIP вообще, BitTorent, P2P, трафик, проходящий в туннелях (GRE, IPSec, QinQ и прочее)

От этих и многих других напастей может спасти DPI . Английское звучание Deep Packet Inspection говорит само за себя — эта технология, которая позволяет проводить глубокий анализ трафика.

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

Простой пример из жизни. Когда-то я работал в местечковом провайдере WiMAX. У нас была довольно небольшая база абонентов, но все они физики (физические лица), и выход в Интернет порядка 30 Мб/с. С физиками есть одна проблема — они любят торренты и P2P-сети. Если с последними всё относительно просто — если провайдер этого не делает, то и пользователи сами вряд ли скооперируются, то с торрентами настоящая беда. Трафик протокола BitTorrent сложно отследить стандартными средствами, тем более, что механизмы работы протокола постоянно адаптируют под меняющиеся реалии. Это стало настоящим бичом компании: в час наибольшей нагрузки сеть лежмя лежала.
ИТ-управлением компании тогда было принято тактическое решение: было куплено самое простое, достаточное по производительности, и недорогое DPI-оборудование, поставлено в разрыв и проблемы решились волшебным образом. Конечно, при этом пострадали особо активные абоненты, но в тот момент такая жертва была необходима. Далее, конечно, ситуацию меняли: ночью ограничение смягчалось, расширялся канал в интернет и т.д. Но DPI выручил и как сиюминутное решение и сейчас в этой сети активно применяется, уже после того, как покинул это место.

Анализ и контроль трафика может выполняться тремя способами:
1) На основе статических правил/политик
2) На основе сигнатур могут распознаваться приложения/протоколы/атаки/вирусная активность. Как правило базы сигнатур предоставляются вендором и обновляются автоматически с некой периодичностью.
3) Deep стоит понимать в неком философском смысле. Это не только глубокое проникновение в пакет, но и глубокий анализ. DPI-устройства могут анализировать поведение, активность хостов в сети. К примеру если с какого-то IP-адреса много попыток соединений на различные порты одного хоста, можно предположить, что это работает сканер портов, а если аналогично на различные хосты, но на один порт, то это может быть червь или вирус.
Благодаря такому поведенческому механизму DPI может распознавать новые протоколы VoIP, P2P или какие-либо другие ещё до выхода соответствующей сигнатуры.

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

Кроме того ещё одна киллер-фича такого плана железок — бескрайнее ромашковое поле для сбора статистики. Например, вы можете выбрать топ-10 посещаемых сайтов или пять пользователей, наиболее нагружающих канал или кто из пользователей ходил в запрещённые сектора интернета. Простор для вашей аналитической фантазии, в общем, бесконечный.
Кстати, DPI-оборудование может помочь вам обнаружить пользователей, замышляющих, что-то тёмное, отслеживать их активность в сети.
По сути СОРМ, который обязывают устанавливать всех операторов и есть DPI, просто управляете им не вы.

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

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

В данный момент на рынке уже немало решений от различных производителей. Занимаются этим и монстры телекома и совсем узкоспециализированные неизвестные в широких кругах компании.

В рамках недавней PHDays проходил ряд докладов связанных с анализом эффективности существующих средств защиты:

· В обход DPI, Олли-Пекка Ниеми (Opi)

· Теория лжи: обход современных WAF, Владимир Воронцов

· Десяток способов преодоления DLP-систем, Александр Кузнецов, Александр Товстолип

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

В своем докладе Олли-Пекка рассказал про пентестовую утилиту Evader , некоторые техники обхода средств защиты (evasion ). Сама утилита Evader – вещь отличная, но у доклада было несколько минусов:

· Во-первых, несоответствие содержания и названия. К DPI никакого отношения. Область действия Evader и описываемых способов обхода – в основном сигнатурные сетевые системы защиты (NGFW , IPS)

· Во-вторых, доклад не оправдывал уровень сложности – 200. Вполне хватило бы и 100. Так как это был краткий пересказ определений различных техник обхода и демонстрация интерфейса Evader

· В-третьих, старая тема. Аналогичный доклад я уже слышал в Stonesoft 2 года назад. С того времени новых слов не прибавилось

Теперь по сути вопроса: так как в докладе не прозвучало какие именно средства какими недостатками обладают, нам потребуется самостоятельно развернуть тестовый стенд Evader , о котором я уже писал ранее . Прогнать его используя mongbat со всеми возможными комбинациями обхода (evasion ), определить те, которые не обнаруживаются нашим сетевым средством защиты. Дополнительно настроить средства защиты, так чтобы обнаруживать атаки даже с техниками обхода (уверен, что в 90% случаев это можно сделать). А для оставшихся 10% необнаруживаемых атак принять решение о необходимости иных “компенсирующих” мер.

Например, если у нас web приложение, а FW и IPS не могу определить атаки, то нужен WAF . Либо, как предлагает Stonesoft , использовать временную меру Stonesoft Evasion Prevention System (EPS ), которую можно впихнуть в любую работающую инфраструктуру.

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

· Сам докладчик говорит, по ряду недостатков WAF (DoS, Protocol-Level Evasion, защищаемые Hostname, HTTP Protocol Pollution), говорит что они связаны с плохой настройкой средства защиты, потом совершает логическую ошибку и говорит что плохи сами WAF.

· Техники обхода перечислялись в режиме пересказа, без демонстраций, деталей и т.п.

· По ходу дела докладчик неоднократно говорит “в корпоративных WAF всё настолько плохо, что я не буду их рассматривать в данном разделе, рассмотрю только open source средства защиты”. Из этого я делаю вывод, что у докладчика всё настолько плохо с получением “корпоративных” WAF на тестирование и с опытом их настройки, что он не хочет трогать эту больную тему

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

· Часть уязвимостей, приведенных автором, являются уязвимостями конечных сервисов и приложений и не имеют отношения к WAF (который их отлично детектирует). Зачем автор привел их в данной теме? Наверное, решил выложить все, что он знает в безопасности web .

· В самом конце докладчик говорит, что разрабатывает собственное принципиально новое средство защиты web приложений (вот и открылись истинные причины критики WAF )

На самом деле, в WAF есть достаточно много правил нормализации и контроля протоколов, надо только их корректно настроить. Вполне возможно автор доклада не потратил достаточно времени на изучение возможных вариантов настройки “корпоративных” WAF .

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

· система полномочного разграничения доступа, в которой мы задаем явно, что можно делать пользователю в web приложении (не путать с блокированием запросов по сигнатурам атак)

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

· защита от автоматизированных атак (Automated Attack ), в рамках которой обнаруживаются внешняя инвентаризация, перебор, фазинг и т.п.

· корреляция с системами защиты БД, в рамках которого WAF получает информацию, о том какой реально запрос и ответ прошел от сервера web приложения к серверу БД

Эти механизмы не упоминались и делаю вывод, что они докладчику были неизвестны.

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

· отключение службы с правами администратора (путем переименования файла службы)

· копирование защищаемых документов в локально-подключенный криптоконнтейнер

· побитовое копирование документа в конец картинки

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

· удаление лога с событиями DLP с правами администратора

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

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

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

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

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

6.Ещё один вывод – Чтобы хакер смог понять, как обойти нашу систему защиты, ему нужно развернуть и протестировать у себя точный аналог. Если мы используем дорогое корпоративное решение, то обычному хакеру этот вариант недоступен.

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

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

iptables - t raw - I PREROUTING - p tcp -- sport 80 -- tcp - flags SYN , ACK SYN , ACK - j NFQUEUE -- queue - num 200 -- queue - bypass

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

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

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

iptables - t raw - I PREROUTING - p tcp -- sport 80 -- tcp - flags SYN , ACK SYN , ACK - m set -- match - set zapret src - j NFQUEUE -- queue - num 200 -- queue - bypass

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

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

iptables - t mangle - I POSTROUTING - p tcp -- dport 80 - m set -- match - set zapret dst - j NFQUEUE -- queue - num 200 -- queue - bypass

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

iptables - t mangle - I POSTROUTING - p tcp -- dport 80 - m set -- match - set zapret dst - m connbytes -- connbytes - dir = original -- connbytes - mode = packets -- connbytes 1 : 5 - j NFQUEUE -- queue - num 200 -- queue - bypass

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

iptables - t nat - I PREROUTING - p tcp -- dport 80 - j DNAT -- to 127.0.0.1 : 1188

iptables - t nat - I OUTPUT - p tcp -- dport 80 - m owner ! -- uid - owner tpws - j DNAT -- to 127.0.0.1 : 1188

Использование модификатора пакетов 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 не отбрасывает входящую сессию, а только всовывает свой пакет, который приходит раньше ответа от настоящего сервера, блокировки так же обходятся без применения «тяжелой артиллерии» следующим правилом:

iptables - t raw - I PREROUTING - p tcp -- sport 80 - m string -- hex - string "|0D0A|Location: http://95.167.13.50" -- algo bm - j DROP -- from 40 -- to 200

Ростелеком: см 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» , но лучше установить более свежее ядро. Оно есть в стабильном репозитории:

apt - get update

apt - get install linux - image - 3.16

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

Собрать 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 .

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

Обзор технологии и ситуации на рынке

Как свидетельствует статистика, за 5 лет в нашей стране значительно увеличилась группа пользователей, которые регулярно (как минимум один раз в течение 24 часов) подключаются к интернету. Если раньше этот показатель был на уровне 31%, сегодня он вырос до 57%. Если перевести эти данные в количество, получается около 66,5 млн человек.

С 2010 года отмечается стремительный рост мобильных пользователей. По статистике, на текущий момент больше трети всех посещений сайтов происходят со смартфонов (3/4 от общего количества) и прочих портативных устройств.

Несмотря на различные неблагоприятные факторы, эксперты прогнозируют дальнейшее увеличение мобильного трафика. Операторы вынуждены реагировать на изменения и искать дополнительные способы улучшения качества своих услуг, поэтому для них актуальной становится технология контроля сетевого трафика. Как считают эксперты, к 2020 году глобальный рынок DPI превысит 4,7 млрд долларов.

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

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

Решения по глубокому анализу трафика позволяют:

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

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

Carbon Reductor DPI X

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

Это программное решение:

автоматически не допускает трафик на ресурсы, находящиеся в списке Минюста и Роскомнадзора;
делает компанию полностью соответствующей российскому законодательству по ФЗ-436, ФЗ-398, ФЗ-187, ФЗ-149, ФЗ-139 (страхует от штрафов);
работает по схеме «зеркалирования трафика»;
использует 8 технологий фильтрации (поддерживаются: HSTS, TCP/IP, BGP/OSPF, HTTPS, DNS, HTTP);
способно проверять до 900 тысяч пакетов трафика в секунду;
имеет понятный веб-интерфейс;
использует минимум аппаратных ресурсов;
поддерживает IPv6.

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

Из чего состоит DPI?

DPI обеспечивает:

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

Системы имеют такой состав:

PCC – разделяет физический поток данных на логические сессии;
PCRF – «мозг», использующий необходимые правила (установление параметров качества обслуживания, применение дополнительных сервисов и так далее);
PCEF – применяет PCC-правила к трафику, проводит тарификацию;
OCS – контроль баланса абонента, тарификация сервисов, применение скидок, подсчет объема услуг;
Billing – сохраняет данные о балансе абонентов, предоставляет доступ к ним серверу OCS;
Access network – сеть подключения абонента к поставщику услуг, содержит в себе все клиентские устройства;
Transcoding, optimization server – кэширование данных для улучшения пропускной способности;
AAA Server – идентифицирует абонентов, ведет учет используемых ресурсов (протокол RADIUS);
BBERF – сообщает PCRF об активации сессии с отправкой идентификатора абонента и прочих показателей для точного определения QoS-правил обслуживания;
UDR – обеспечивает хранение данных пользователей.

Варианты использования DPI систем

Предусмотрено 9 возможных сценариев:

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

Необходимое оборудование для DPI систем

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

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

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

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

Головное устройство оснащено двумя контроллерами, каждый из которых имеет порты для подключения к сети и полок расширения. Используется процессор Intel® Xeon® E5-2600 V4. Для повышения отказоустойчивости применяется два блока питания.

ОС SmartOS выполняет управление дисками. За счет применения технологии RAID-Z и новой файловой системы ZFS оборудование получает массу преимуществ:

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

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

Схемы подключения DPI

Существует две основные схемы:

Активная. Установка «в разрыв». Обеспечивает реализацию полного функционала. Устройство подключается после пограничного маршрутизатора в разрыв uplink. Благодаря такой схеме через DPI проходит весь трафик. Это открывает широкие функциональные возможности для его обработки. Однако в такой схеме есть минус. Если устройство выходит из строя, нарушается связь. Для этого рекомендуется использовать либо резервную платформу, либо Bypass устройства.
Пассивная. «Зеркалирование трафика» происходит через оптические сплиттеры либо SPAN-порты. Подобная схема открывает доступ к множеству функций: предварительная фильтрация СОРМ, кэширование, переадресация запросов блокировки, онлайн-снятие click stream и так далее. Если сеть уже действует, такая схема позволяет за 1-2 дня внедрить DPI.

Заключение

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

04.10.2016 | Владимир Хазов

Сетевой трафик неоднороден, он состоит из множества приложений, протоколов и сервисов. Многие из этих приложений уникальны по требованиям к характеристикам сети, таким как скорость, задержки, джиттер. Удовлетворение этих требований – обязательное условие для того, чтобы приложение работало быстро и стабильно, а пользователи были удовлетворены качеством. Если в локальных сетях (LAN) с их высокой пропускной способностью проблем не бывает, то ограниченная ширина канала доступа в Интернет (WAN) требует тонкой настройки.

Классификация и маркировка

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

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

Основные понятия: классификация – идентификация приложений или протоколов; маркировка – процесс разметки пакетов для применения политик обслуживания на оборудовании.

Существуют два основных метода классификации трафика:

Классификация на основе блоков данных (Payload-Based Classification). Основывается на полях с блоками данных, таких как порты (Layer 4) OSI (отправитель и получатель или оба). Данный метод является наиболее распространенным, но не работает с зашифрованным и туннелированным трафиком.
Классификация на основе статистического метода. Основывается на анализе поведения трафика (время между пакетами, время сеанса и т. п.).

Универсальный подход к классификации трафика основывается на информации в заголовке IP-пакета – как правило, это IP-адрес (Layer 3), MAC-адрес (Layer 2), используемый протокол. Этот подход имеет ограниченные возможности, поскольку информация берется только из IP-заголовка, так же, как ограничены методы Layer 4 – ведь далеко не все приложения используют стандартные порты.

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

Deep Packet Inspection

Системы глубокого анализа трафика позволяют классифицировать те приложения и протоколы, которые невозможно определить на Layer 3 и Layer 4, например URL внутри пакета, содержимое сообщений мессенджеров, голосовой трафик Skype, p2p-пакеты BitTorrent.

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

Существуют несколько методов сигнатурного анализа:

Анализ образца (Pattern analysis).
Числовой анализ (Numerical analysis).
Поведенческий анализ (Behavioral analysis).
Эвристический анализ (Heuristic analysis).
Анализ протокола/состояния (Protocol/state analysis).

Анализ образца

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

Числовой анализ

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

Поведенческий и эвристический анализ

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

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

Анализ протокола/состояния

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

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

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

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