Жил да был большой провайдер, пропускал пакеты, ограничивал понемногу трафик. Всем было счастье. Или почти всем. До тех пор, пока кто-то не сказал: "Нам мало средств контроля трафика". Так в уютной обжитой сети появился DPI. Эта молодая бестия со своим уставом лезет в самую глубину пакетов, куда не добраться простым файрволам.
Системы DPI (Deep Packet Inspection) приобретают всё большую и большую популярность, несмотря на их астрономическую стоимость. Сейчас почти у каждого большого вендора есть своё решение. У Cisco это Cisco SCE , у Huawei - SIG9800 , у Juniper -VXA . Есть и менее известные компании, которые производят преимущественно оборудование DPI. Например, Allot или Inline Telecom с их Sandvine . Вроде бы, даже русские ребята засветились: Traffica .
Так чем же так занимательны эти комплексы, стоящие каких-то заоблачных денег? Ваш непокорный слуга посвятил несколько месяцев интеграции DPI и я имею, что сказать.
Какие у нас сейчас есть средства управления трафиком?
- На основе MAC-адресов или VLAN’ов. Очень грубо.
- По IP-адресам получателей или отправителей. Так сейчас зачастую и делают.
- По портам TCP и UDP. Так тоже делают.
- На прокси-серверах можно ограничить по доменному имени. Но вы представляете себе прокси-сервер для абонентов в сети провайдера?
На основе вышеуказанных параметров пакета можно строить ACL или настраивать QoS. Но, положа руку на клавиатуру, сможете вы ограничить доступ на один только блог в ЖЖ, не закрывая сам ЖЖ? А сможете вычленить трафик торрента из кучи остального?
То есть в руках у вас сейчас есть инструменты stateful файрвола, который максимум добирается до транспортного уровня (4 из 7). DPI позволяет врезаться в самую глубину пакета, анализируя данные на всех уровнях OSI с 1-го по 7-й. На то он и Deep. Даже туннели без шифрования (QinQ, GRE, MPLS и т.д.) ему по зубам.
Итак, что же он на самом деле может:
- Собирать самую разнообразную статистику. Практически любой каприз маркетологов вы теперь преподнесёте им на блюдечке.
- Фильтровать (вычленять) трафик по определённым критериям. Тут к очевидным IP-адрес+порт прибавляются доменные имена и протоколы. Например, сложновычисляемый трафик P2P или Skype определяется тут на ура.
- Применять на абонентов всевозможные политики. Они могут быть, как статическими - вы сами выбираете кому, что и когда можно, и с какими приоритетами - так и динамическими - есть где-то один централизованный сервер, который отвечает на эти вопросы. К слову, абонентами могут быть не только обычные пользователи фиксированных сетей, но, также, к примеру, и беспроводных, со всеми присущими атрибутами (могут отслеживаться APN, номера телефонов, способ доступа - GERAN, UTRAN...)
- Предотвращение атак. Речь идёт о сетевых атаках извне, таких как DoS, сканирование портов. Также детектируются некоторые атаки изнутри
- Благодаря возможности зеркалирования и перенаправления трафика возможны всякие приятные штуки, вроде проверки почты на спам или трафика с вебсайтов на вирусы.
Каким образом шайтан-машина определяет атаки и принадлежность трафика тем или иным протоколам? Для этого у неё есть три пути:
- Явно заданные правила..ru" в заголовке HTTP;
- Сигнатуры. Они подготавливаются вендором и содержат набор самых разнообразных правил, на основе которых будет фильтроваться трафик. Вполне возможно, что этот файл будет подготовлен с учётом ваших пожеланий. Файл сигнатур периодически обновляется и, в зависимости от производителя, либо автоматически скачивается оборудованием, либо нужно сделать это вручную;
- Анализ поведения. В этом пункте вся философия слова Deep в названии. Многие системы DPI позволяют на основе "странностей" в поведении трафика совершать действия - определить протокол или обнаружить и предотвратить атаку.
Самый простой пример: запустили вы сканер портов. Программа обращается к указанному адресу и перебирает все 65 535 портов протокола TCP, например. Ежу же понятно, что никакая здоровая программа не будет устанавливать такие дикие соединения - это колокольный звон для DPI, что в сети что-то неладно.
Мне довелось потрогать и даже покопаться с лихвой в командной строке SIG9810 - DPI решения Хуавэй. Поэтому про его интеграцию я и расскажу. Думаю, что принципы работы оборудования любого другого вендора отличаются незначительно.
Оборудование DPI ставится в разрыв, что весьма логично. То есть, очень грубо говоря, так:
Весь трафик, разумеется, проходит через систему, где на него и применяются политики и снимается вся статистика.
В плане железа DPI состоит из следующих компонентов:
- Bypass;
- Устройство Front-End;
- Устройство Back-End;
- PCRF-сервер (Policy and Charging Rules Function);
- Коммутаторы для обеспечения связности между компонентами.
Опционально:
6. Серверы (мониторинг состояния системы, syslog);
7. Дисковые массивы (для хранения статистики и для серверов);
8. Устройства VAS (Value Added Services - проверка на спам и вирусы, родительский контроль).
Типовая схема выгляди так:
Всё это вместе занимает 2-3 стойки.Расскажу по порядку о каждом из них.
1) Bypass
Что происходит, когда в сеть вы добавляете ещё один элемент? А тем более стойку? Верно, появляется ещё одно слабое звено. Bypass призван хоть немного исправить это положение.
В сеть оно включается первым и уже к нему подключается Front-End.
У него есть два режима работы:
1. Защитный. Трафик проходит напрямую и не заворачивается на Front-End
2. Рабочий. Трафик заворачивается на Front-End, но в случае чего переключается на прямой канал, как в первом случае.
Bypass всеми силами будет пытаться удержать связь.
Ломается Front-End (сгорела плата) - трафик переключается на защитный канал.
Рвётся линк до Front-End’a (сгорел порт, повредился кабель) - трафик переключается на защитный канал.
Выключилось электричество - трафик переключается на защитный канал.
Bypass’ы бывают электрическими и оптическими. Электрические основаны на реле и применяются с медными проводами, то есть максимальная скорость, на канал 1 Гб/с.
Оптические сильно круче. Помимо того, что скорость на канал до 10 Гб/с, существует возможность зеркалирования трафика задаром - световому лучу не убудет. То есть в то время как трафик идёт по прямому каналу, его копия направляется на Front-End. Действия над трафиком никакие ещё совершать нельзя, но статистику уже собирать вполне можно.
D
2) Front-End
Это адская молотилка. Через неё несутся гигабиты, именно в нём каждый пакет разбирается по байтикам, именно в нём трафик каждого абонента подвергается экзекуции в соответствии с политиками.
По сути это очень мощный модульный маршрутизатор.
В нём есть голова - платы управления самим устройством - их, как правило, две - мастер/слейв.
Есть линейные платы, отвечающие за приём-передачу трафика, то есть физический, канальный и немного сетевой уровни.
Есть фабрики коммутации, которые отвечают за передачу данных между платами.
И наконец, руки - процессинговые платы, которые и перелопачивают эти кучи, накладывают ограничения, собирают статистику и успевают при этом взаимодействовать с Back-End и с PCRF-сервером, запрашивая политики и передавая данные на них.
3) Back-End
Это огромный сарай, куда складируется всё подряд. Тут лежат подробности всех политик, вся собранная статистика, сигнатуры, правила зеркалирования и перенаправления, радиус-пакеты отправляются сюда и прочее-прочее. Что угодно в любой момент можно извлечь.
В плане железа у Хуавэй это блейд-сервер. Каждая плата дублируется. Некоторые из них на горячей замене, другие организуют балансировку нагрузки.
4) PCRF-сервер
Очень грубо говоря, он хранит соответствия: пользователь - номер политики. Front-End отправляет ему идентификатор абонента, тот возвращает номер политики, Front-End запрашивает подробности соответствующей политики на Back-End’e.
Как правило, PCRF-сервер один на множество сайтов.
С точки зрения сети DPI можно разделить на три части:
1) супервысокоскоростная часть;
Трафик пользователей
Исчисляется Гигабитами в секунду
2) Сеть взаимодействия компонентов (FE, BE,сервера);
Тут трафик небольшой и гагибитного (даже сотки) с лихвой. По этой сети ходит только служебная информация.
3) управление и PCRF - стык с внешней (для DPI) сетью.
Это каналы в сеть OMC (operation and maintenance center) транзит до PCRF-сервера. Также только для служебных целей - доступ на оборудование и NMS (Network Management Server).
На практике
Статистику можно собирать самую богатейшую. Приведу несколько примеров:
Общий трафик по городу с разделением по различным типам:
То же в виде пирога:
Какой хостинг видео преобладает:
Топ 10 сайтов по числу соединений:
Топ 10 сайтов по объёму трафика:
Трафик по каждому абоненту отдельно в категории WEB:
Самые активные пользователи:
А вот пример применения политик: всё делается на лету - и между командой и её эффектом проходит пара секунд.
На картинке показано действие политики, ограничивающей общий трафик до 700 кб/с, при этом приоритет на видео (зелёный), а для Р2Р (фиолетовый) гарантировано 200 кб/с.
А это пример использования просто приоритетов. Общее ограничение также на 700 кб/с, наивысший приоритет у видео (зелёный), на втором месте FTP (красный) и на последнем фиолетовый P2P
Политики тоже можно задавать очень гибко:
- ограничивать общую скорость трафика вплоть до блокировки;
- ограничивать скорость трафика по каждой категории (веб, видео, p2p, IM и так далее) отдельно вплоть до блокировки;
- выделять полосу для каждого типа трафика (например, не более мегабита/с, но 200 кб/с должно быть гарантировано);
- указывать приоритет для каждого типа.
И другие менее очевидные способы.
Я люблю всякие огромные махины, вроде КрАЗа, БелАЗа - чувствуется невообразимая мощь в урчании их двигателей и лёгкий трепет перед ними. Очень похожие ощущения от работы с DPI. Словами не передашь турбинного потока воздуха из кулеров, мигания десятков светодиодов в темноте машинного зала, тугого жгута оптических проводов, уходящих в загадочный Bypass и те, почти неограниченные, возможности, которые он предоставляет. Возможностям, которые делают вас не администратором сети, но хозяином.
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 позволяет выполнять эту задачу с максимальной эффективностью и производительностью.
В рамках недавней 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-системы дают богатый инструментарий операторским службам эксплуатации и маркетинга, уверен Александр Орлов, эксперт Центра сетевых решений компании «Инфосистемы Джет».
Российский рынок DPI-систем (deep packet inspection - накопление статистических данных, проверка и фильтрация сетевых пакетов по их содержимому) сравнительно молод. Какие драйверы и тормозящие факторы его развития можно выделить?
Первый драйвер - принятая 3GPP (3rd Generation Partnership Project) концепция развития сетей 3G и 4G, неотъемлемым элементом которой являются системы DPI. В России подъем интереса к этим системам полтора-два года назад подстегнуло законодательство, потребовавшее от операторов ограничивать доступ абонентов к противоправному контенту в интернете. DPI осуществляет глубокий анализ трафика и в соответствии с поставленными задачами обеспечивает их выполнение. Так, на одном IP-адресе может находиться 3 тыс. доменов, из которых лишь один содержит противоправный контент. Именно его и нужно заблокировать. И только DPI может его "отловить" и закрыть к нему доступ. Все законы, требующие фильтрации трафика и блокировки интернет-ресурсов, так или иначе, связаны с решениями DPI или "около-DPI". Под последними я подразумеваю решения, которые изначально не предназначались для фильтрации, но сейчас их пытаются приспособить к решению этой задачи, поскольку имеющиеся на рынке промышленные DPI-решения, как правило, не вписываются по цене в бюджеты средних и маленьких компаний.
- Чем объясняется высокая "цена вопроса"?
Коробочное аппаратно-программное решение DPI позволяет обрабатывать колоссальные объемы трафика - 100−200−300 Гбит/с. Это действительно решение операторского класса, и стоимость систем каждого из трех основных игроков российского рынка DPI (Allot Communications, Procera Networks, Sandvine) исчисляется сотнями тысяч долларов для крупных операторов. Для небольшого оператора цена составит не больше $100 тыс., но и это для него составляет уже критичную сумму. Поэтому маленькие операторы вынуждены искать альтернативные пути, использовать "наколенные" решения и проч. Так или иначе они должны что-то придумать, потому что наше законодательство довольно строго спрашивает с операторов, которые не выполняют предписания 139-ФЗ (закон о "черных списках"), 149-ФЗ (об информации, информационных технологиях и о защите информации), 187-ФЗ ("антипиратский закон").
- Такие мелкие операторы могут брать DPI как услугу у крупных?
У одного большого оператора, насколько мне известно, уже есть заказчики такого сервиса - "нижестоящие" провайдеры. Для них это возможность не тратить больших денег на покупку собственного решения, а крупный оператор может таким образом монетизировать уже внедренное решение по блокировке трафика.
- Помимо карающего меча закона, какие еще существуют движущие факторы внедрения DPI-систем?
- DPI-систему можно установить раз и навсегда и "забыть" о ней?
Это было бы идеально для всех. Но если система используется по своему прямому назначению, для распознавания и классификации трафика, а не только для исполнения буквы закона, то приходится постоянно обновлять сигнатуры. Приложения и трафик все время меняются - и вряд ли кому интересно решение, которое уже через год не сможет "видеть", какой трафик идет через сеть, какое приложение сколько места занимает в общем канале емкости и т.д.
Смогут ли операторы, построившие сети 3G и строящие теперь 4G, использовать уже внедренные DPI-системы и на новых сетях?
Для оператора теоретически ничего поменяться не должно. Возможно, решение придется умощнить, поскольку через сеть пойдет больший объем трафика, но не вижу проблем использовать ту же самую инфраструктуру, потому что точка выхода из сети будет одна и та же.
Очевидно, что применение DPI ориентировано на массовый рынок. Для корпоративного сектора эти системы неактуальны?
Корпоративными заказчиками DPI-решения пока мало востребованы. Однако сейчас появляются DPI Next Generation − обычные карточки PCI Express, которые вставляются в сервер, на который также ставится программный движок, и это все работает в комплексе. Цена вопроса значительно снижается, но и функциональность падает. Такое устройство не сможет обрабатывать 50−100 Гбит/с трафика, но для корпоративной сети с запасом хватит и 3−4 Гбит/с. Мы работаем с производителями таких решений и надеемся получить их на тестирование в ближайшее время. Думаю, они заинтересуют корпоративных заказчиков.
- Какова роль системных интеграторов на этом рынке?
Системные интеграторы выступают в роли консультантов, поставщиков, проектировщиков, а также вполне могут выполнять функции техподдержки первой линии для заказчика. Ни один из "большой тройки" DPI-вендоров не имеет в России своего физического представительства (офиса со штатом сотрудников, со службой техподдержки). При возникновении серьезной проблемы интегратор направляет запрос вендору, который его отрабатывает в своей лаборатории и передает решение партнеру-интегратору. А тот, в свою очередь, − заказчику.
- Насколько высок в сегменте DPI уровень конкуренции среди интеграторов?
Сейчас начинается активная конкуренция, и самым весомым конкурентным преимуществом является опыт реализации таких проектов, практика. На рынке пока немного специалистов имеют компетенции по DPI, умеют с ними работать и, главное, понимают, для чего они нужны. Разумеется, системному интегратору важно иметь штат специалистов, обладающих необходимой квалификацией. Специалисты нашей компании, например, прошли обучение у вендоров, у них есть необходимые знания.
Но решающим фактором считаю все же опыт. Например, мы выполнили проект по созданию платформы управления трафиком, основанный на применении технологий DPI для «ВымпелКома». В ходе которого мы устанавливали и настраивали программно-аппаратные комплексы DPI PacketLogic компании Procera Networks на 40 самых загруженных узлах магистральной сети. А по завершению монтажа − сформировали правила и политики, включили функцию сбора статистики, на основании которой правила управления трафиком корректировались для каждого конкретного города. Иначе говоря, мы обеспечили интеллектуальную часть и экспертизу, а также прорисовку перспектив развития проекта, потому что внедренное решение, по своей сути − очень мощный инструмент, позволяющий оператору проводить качественный и количественный анализ структуры трафика, эффективно управлять им, оптимизировать нагрузку на каналы магистральной сети, и, как следствие, повысить качество услуг, предоставляемых абонентам.
Кроме этого компания обладает значительным опытом реализации проектов в телекоммуникационной отрасли, выполненных для ведущих телеком-операторов Росси и стран СНГ.
К настоящему времени "большая тройка" уже внедрила DPI-системы, "Ростелеком" планирует завершить внедрение в 2014 г. Но у нас в России действующих лицензий на услуги связи больше 80 тыс. Это все потенциальные заказчики DPI?
Я бы сократил эту цифру как минимум вдвое, но в любом случае потенциальный рынок очень большой. Небольших операторов очень много, хотя бы даже только в Москве. Думаю, очень скоро поднимется новая волна спроса на DPI. Сейчас рынок находится в стадии ожидания этой волны и подготовки к ней.
Беседовала Лилия Павлова
Провайдеры Российской Федерации, в большинстве своем, применяют системы глубокого анализа трафика (DPI, Deep Packet Inspection) для блокировки сайтов, внесенных в реестр запрещенных. Не существует единого стандарта на DPI, есть большое количество реализации от разных поставщиков DPI-решений, отличающихся по типу подключения и типу работы.
Существует два распространенных типа подключения DPI: пассивный и активный.
Пассивный DPI
Пассивный DPI - DPI, подключенный в провайдерскую сеть параллельно (не в разрез) либо через пассивный оптический сплиттер, либо с использованием зеркалирования исходящего от пользователей трафика. Такое подключение не замедляет скорость работы сети провайдера в случае недостаточной производительности DPI, из-за чего применяется у крупных провайдеров. DPI с таким типом подключения технически может только выявлять попытку запроса запрещенного контента, но не пресекать ее. Чтобы обойти это ограничение и заблокировать доступ на запрещенный сайт, DPI отправляет пользователю, запрашивающему заблокированный URL, специально сформированный HTTP-пакет с перенаправлением на страницу-заглушку провайдера, словно такой ответ прислал сам запрашиваемый ресурс (подделывается IP-адрес отправителя и TCP sequence). Из-за того, что DPI физически расположен ближе к пользователю, чем запрашиваемый сайт, подделанный ответ доходит до устройства пользователя быстрее, чем настоящий ответ от сайта.Выявляем и блокируем пакеты пассивного DPI
Поддельные пакеты, формируемые DPI, легко обнаружить анализатором трафика, например, Wireshark.Пробуем зайти на заблокированный сайт:
Мы видим, что сначала приходит пакет от DPI, с HTTP-перенаправлением кодом 302, а затем настоящий ответ от сайта. Ответ от сайта расценивается как ретрансмиссия и отбрасывается операционной системой. Браузер переходит по ссылке, указанной в ответе DPI, и мы видим страницу блокировки.
Рассмотрим пакет от DPI подробнее:
HTTP/1.1 302 Found
Connection: close
Location: http://warning.rt.ru/?id=17&st=0&dt=195.82.146.214&rs=http%3A%2F%2Frutracker.org%2F
В ответе DPI не устанавливается флаг «Don"t Fragment», и в поле Identification указано 1. Серверы в интернете обычно устанавливают бит «Don"t Fragment», и пакеты без этого бита встречаются нечасто. Мы можем использовать это в качестве отличительной особенности пакетов от DPI, вместе с тем фактом, что такие пакеты всегда содержат HTTP-перенаправление кодом 302, и написать правило iptables, блокирующее их:
# iptables -A FORWARD -p tcp --sport 80 -m u32 --u32 "0x4=0x10000 && 0x60=0x7761726e && 0x64=0x696e672e && 0x68=0x72742e72" -m comment --comment "Rostelecom HTTP" -j DROP
Что это такое? Модуль u32 iptables позволяет выполнять битовые операции и операции сравнения над 4-байтовыми данными в пакете. По смещению 0x4 хранится 2-байтное поле Indentification, сразу за ним идут 1-байтные поля Flags и Fragment Offset.
Начиная со смещения 0x60 расположен домен перенаправления (HTTP-заголовок Location).
Если Identification = 1, Flags = 0, Fragment Offset = 0, 0x60 = «warn», 0x64 = «ing.», 0x68 = «rt.ru», то отбрасываем пакет, и получаем настоящий ответ от сайта.
В случае с HTTPS-сайтами, DPI присылает TCP Reset-пакет, тоже с Identification = 1 и Flags = 0.
Активный DPI
Активный DPI - DPI, подключенный в сеть провайдера привычным образом, как и любое другое сетевое устройство. Провайдер настраивает маршрутизацию так, чтобы DPI получал трафик от пользователей к заблокированным IP-адресам или доменам, а DPI уже принимает решение о пропуске или блокировке трафика. Активный DPI может проверять как исходящий, так и входящий трафик, однако, если провайдер применяет DPI только для блокирования сайтов из реестра, чаще всего его настраивают на проверку только исходящего трафика.Системы DPI разработаны таким образом, чтобы обрабатывать трафик с максимально возможной скоростью, исследуя только самые популярные и игнорируя нетипичные запросы, даже если они полностью соответствуют стандарту.
Изучаем стандарт HTTP
Типичные HTTP-запросы в упрощенном виде выглядят следующим образом:GET / HTTP/1.1 Host: habrahabr.ru User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/50.0 Accept-Encoding: gzip, deflate, br Connection: keep-alive
Запрос начинается с HTTP-метода, затем следует один пробел, после него указывается путь, затем еще один пробел, и заканчивается строка протоколом и переносом строки CRLF.
Заголовки начинаются с большой буквы, после двоеточия ставится символ пробела.
Давайте заглянем в последнюю версию стандарта HTTP/1.1 от 2014 года. Согласно RFC 7230, HTTP-заголовки не зависят от регистра символов, а после двоеточия может стоять произвольное количество пробелов (или не быть их вовсе).
Each header field consists of a case-insensitive field name followed
by a colon (":"), optional leading whitespace, the field value, and
optional trailing whitespace.
header-field = field-name ":" OWS field-value OWS
field-name = token
field-value = *(field-content / obs-fold)
field-content = field-vchar [ 1*(SP / HTAB) field-vchar ]
field-vchar = VCHAR / obs-text
obs-fold = CRLF 1*(SP / HTAB)
; obsolete line folding
OWS - опциональный один или несколько символов пробела или табуляции, SP - одинарный символ пробела, HTAB - табуляция, CRLF - перенос строки и возврат каретки (\r\n).
Это значит, что запрос ниже полностью соответствует стандарту, его должны принять многие веб-серверы, придерживающиеся стандарта:
GET / HTTP/1.1
hoSt:habrahabr.ru
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/50.0
Accept-Encoding: gzip, deflate, br
coNNecTion: keep-alive ← здесь символ табуляции между двоеточием и значением
На деле же, многие веб-серверы не любят символ табуляции в качестве разделителя, хотя подавляющее большинство серверов нормально обрабатывает и отсутствие пробелов между двоеточием в заголовках, и множество пробелов.
Старый стандарт, RFC 2616, рекомендует снисходительно парсить запросы и ответы сломанных веб-северов и клиентов, и корректно обрабатывать произвольное количество пробелов в самой первой строке HTTP-запросов и ответов в тех местах, где требуется только один:
Clients SHOULD be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they SHOULD accept any amount of SP or HT characters between fields, even though only a single SP is required.Этой рекомендации придерживаются далеко не все веб-серверы. Из-за двух пробелов между методом и путем ломаются некоторые сайты.
Спускаемся на уровень TCP
Соединение TCP начинается с SYN-запроса и SYN/ACK-ответа. В запросе клиент, среди прочей информации, указывает размер TCP-окна (TCP Window Size) - количество байт, которые он готов принимать без подтверждения передачи. Сервер тоже указывает это значение. В интернете используется значение MTU 1500, что позволяет отправить до 1460 байтов данных в одном TCP-пакете.Если сервер указывает размер TCP-окна менее 1460, клиент отправит в первом пакете данных столько, сколько указано в этом параметре.
Если сервер пришлет TCP Window Size = 2 в SYN/ACK-пакете (или мы его изменим на это значение на стороне клиента), то браузер отправит HTTP-запрос двумя пакетами:
Пакет 1:
GE
Пакет 2: T / HTTP/1.1
Host: habrahabr.ru
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/50.0
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Используем особенности HTTP и TCP для обхода активного DPI
Многие решения DPI ожидают заголовки только в стандартном виде.Для блокировки сайтов по домену или URI, они ищут строку "Host: " в теле запроса. Стоит заменить заголовок «Host» на «hoSt» или убрать пробел после двоеточия, и перед вами открывается запрошенный сайт.
Не все DPI можно обмануть таким простым трюком. DPI некоторых провайдеров корректно анализируют HTTP-заголовки в соответствии со стандартом, но не умеют собирать TCP-поток из нескольких пакетов. Для таких DPI подойдет «фрагментирование» пакета, путем искусственного уменьшения TCP Window Size.
В настоящий момент, в РФ DPI устанавливают и у конечных провайдеров, и на каналах транзитного трафика. Бывают случаи, когда одним способом можно обойти DPI вашего провайдера, но вы видите заглушку транзитного провайдера. В таких случаях нужно комбинировать все доступные способы.
Программа для обхода DPI
Я написал программу для обхода DPI под Windows: GoodbyeDPI .Она умеет блокировать пакеты с перенаправлением от пассивного DPI, заменять Host на hoSt, удалять пробел между двоеточием и значением хоста в заголовке Host, «фрагментировать» HTTP и HTTPS-пакеты (устанавливать TCP Window Size), и добавлять дополнительный пробел между HTTP-методом и путем.
Преимущество этого метода обхода в том, что он полностью автономный: нет внешних серверов, которые могут заблокировать.
По умолчанию активированы опции, нацеленные на максимальную совместимость с провайдерами, но не на скорость работы. Запустите программу следующим образом:
goodbyedpi.exe -1 -a
Если заблокированные сайты стали открываться, DPI вашего провайдера можно обойти.
Попробуйте запустить программу с параметром -2 и зайти на заблокированный HTTPS-сайт. Если все продолжает работать, попробуйте режим -3 и -4 (наиболее быстрый).
Некоторые провайдеры, например, Мегафон и Yota, не пропускают фрагментированные пакеты по HTTP, и сайты перестают открываться вообще. С такими провайдерами используйте опцию -3 -a
Эффективное проксирование для обхода блокировок по IP
В случае блокировок по IP-адресу, провайдеры фильтруют только исходящие запросы на IP-адреса из реестра, но не входящие пакеты с этих адресов.Программа работает как эффективный прокси-сервер: исходящие от клиента пакеты отправляются на сервер ReQrypt в зашифрованном виде, сервер ReQrypt пересылает их серверу назначения с подменой исходящего IP-адреса на клиентский , сервер назначения отвечает клиенту напрямую, минуя ReQrypt.
Если наш компьютер находится за NAT, мы не можем просто отправить запрос на сервер ReQrypt и ожидать ответа от сайта. Ответ не дойдет, т.к. в таблице NAT не создана запись для этого IP-адреса.
Для «пробива» NAT, ReQrypt отправляет первый пакет в TCP-соединении напрямую сайту, но с TTL = 3. Он добавляет запись в NAT-таблицу роутера, но не доходит до сайта назначения.
Долгое время разработка была заморожена из-за того, что автор не мог найти сервер с возможностью спуфинга. Спуфинг IP-адресов часто используется для амплификации атак через DNS, NNTP и другие протоколы, из-за чего он запрещен у подавляющего большинства провайдеров. Но сервер все-таки был найден, хоть и не самый удачный. Разработка продолжается. Добавить метки
