АЛЕКСАНДР ГЕТЬМАН, ИСП РАН, thorin@ispras.ru

 ЮРИЙ МАРКИН, ИСП РАН, ustas@ispras.ru

 ДМИТРИЙ ОБЫДЕНКОВ, ИСП РАН, obydenkov@ispras.ru

 ВАРТАН ПАДАРЯН, ИСП РАН, vartan@ispras.ru

Архитектура системы
глубокого разбора сетевого трафика*

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

Введение

На практике инструменты не используются по отдельности, а объединяются в рамках комплексных решений: так, для обеспечения безопасности внутренней сети предприятия применяются межсетевые экраны, системы обнаружения и предотвращения вторжений [1], системы защиты от DDoS-атак и др.

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

На протяжении последних трех лет в ИСП РАН разрабатывается система глубокого разбора сетевых пакетов Protosphere, предусматривающая возможность получения результатов разбора сторонними инструментами и таким образом позволяющая объединить эти инструменты в рамках комплексного решения.

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

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

Модель представления разобранного сетевого трафика, описанная в работе [2], интерфейсы доступа к ее сущностям для подсистем разбора и построения, а также подсистема работы с памятью составляют ядро системы глубокого разбора (см. рис. 1).

Рисунок 1. Архитектура системы глубокого разбора

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

Главное отличие между реализацией разбора трафика в этих режимах состоит в механизме управления памятью. В online-режиме требуется своевременно освобождать память, поскольку разбирается потенциально бесконечный поток данных. Offline-режим предполагает, что памяти достаточно, поэтому освобождение памяти проводится по окончании работы системы с сетевой трассой.

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

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

Для проведения разбора в online- и offline-режимах было разработано два инструмента, причем каждый использует свой комплект модулей разбора.

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

В рамках разработанной системы модули разбора являются независимыми: при добавлении новых разборщиков не требуется вносить изменения в существующие. Такая независимость достигается благодаря механизму связывания разборщиков, основанному на применении распознавателей [2], аналогично тому, как это делается в Wireshark [3].

В зависимости от установленных параметров проводится сборка ядра, модулей разбора и модулей построения для проведения разбора либо в режиме offline либо online. Построенная по такому принципу система позволяет в полной мере использовать преимущества offline-анализа при отладке модулей разбора и дальнейшей эксплуатации этих модулей (используется тот же исходный код) при работе online.

Online-анализатор

Инструмент online-анализа (см. рис. 2) предназначен для извлечения данных из трафика в режиме реального времени: он должен работать непрерывно с производительностью, достаточной для разбора пакетов, поступающих на сетевой интерфейс.

Рисунок 2. Online-анализатор

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

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

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

Offline-анализатор

Инструмент offline-анализа (см. рис. 3) главным образом предназначен для отладки модулей разбора: с его помощью аналитик получает максимально детализированную «картину происходящего» в сохраненном трафике с указанием возникших в процессе разбора ошибок.

Рисунок 3. Offline-анализатор

Инструмент обладает графическим интерфейсом, позволяющим проследить за тем, как происходит сборка потоков высокоуровневых данных (например, файлов формата PNG или PDF) из сетевых пакетов.

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

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

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

Процесс переноса модуля разбора состоит из трех этапов:

• Трансляция исходного кода разборщика в промежуточное представление.
• Модификация промежуточного представления.
• Генерация кода на основе модифицированного промежуточного представления.

Код модулей разбора Wireshark написан на языке Си. Разработка разборщиков, используемых системой Protosphere, ведется в рамках языка Си++. В качестве промежуточного представления, используемого при портировании, было выбрано абстрактное синтаксическое дерево (АСД). АСД строится посредством инструмента Elsa, являющегося частью системы статического анализа Oink [5].

Первый этап состоит в построении АСД по исходному коду модуля разбора Wireshark. На втором этапе проводится модификация построенного АСД:

1. Замена используемых типов и имен типов, если они различны.
2. Выделение части АСД, соответствующей коду модуля (отделение части АСД, соответствующей включаемым файлам).
3. Трансляция вызовов API, т.е. замена вызовов функций одного интерфейса на вызовы функций другого интерфейса, включая преобразование переменных и параметров функций.
4. Удаление ненужных инструкций, выдача диагностики о тех фрагментах кода, которые не удалось преобразовать.

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

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

Обратная инженерия закрытого протокола ботнета rbot

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

Функционирующий ботнет, как правило, является модификацией распространяемого в сети ботнета, предоставляющего базовый функционал, который может быть расширен злоумышленником с помощью дополнительных плагинов. Таким образом, командный протокол ботнетов, принадлежащих одному семейству, может иметь общую основу и различаться в зависимости от модификаций, произведенных злоумышленником. Злоумышленники предпочитают использовать распространенные протоколы, а не разрабатывать собственные нестандартные решения, прежде всего в целях маскировки вредоносного трафика. При реализации командных протоколов нередко используются протоколы интернет-чатов, позволяющих организовать широковещательную рассылку команд вредоносным программам от оператора ботнета. По этой причине протокол IRC часто используется разработчиками ботнетов. Несмотря на то что популярность IRC-мессенджеров снизилась среди пользователей интернета, было разработано несколько семейств ботнетов, встречающихся в сети до сих пор, в частности rbot [6, 7].

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

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

Рисунок 4. Фрагмент взаимодействия ботнета и управляющего сервера

Таблица 1. Предполагаемые команды управляющего протокола ботнета

На основе данного набора возможных команд был создан прототип модуля разбора, способного в автоматическом режиме распознавать командный протокол rbot в трафике. Распознавание командного протокола было реализовано посредством регистрации распознавателя для поля <message> пакетов протокола IRC. Распознаватель проверяет текст сообщения на наличие команды из списка и в случае обнаружения выполняет проверку формата команды с помощью регулярного выражения. Чем больше команд и их форматов будет добавлено в распознаватель, тем точнее будет проводиться разбор.

Заключение

Разработанная система предлагает возможность построения комплексных решений для практических задач анализа сетевого трафика, тогда как существующие инструменты, проводящие глубокий разбор пакетов, – Wireshark, Snort [8], The Bro Network Security Monitor [9] – не предполагают подобных сценариев использования. Другая особенность разработанной системы – единый комплект исходных кодов модулей разбора пакетов протоколов для online- и offline-режимов – позволяет итеративно повышать качество проводимого разбора, а также оперативно проверять гипотезы о структуре пакетов закрытых сетевых протоколов при решении задачи обратной инженерии.

1. Hussain Ahmad Madni Uppal, Memoona Javed and M.J. Arshad. An Overview of Intrusion Detection System (IDS) along with its Commonly Used Techniques and Classifications // International Journal of Computer Science and Telecommunications, volume 5, Issue 2, 2014.
2. А.И. Гетьман, Ю.В. Маркин, В.А. Падарян, А.Ю. Тихонов. Модель представления данных при проведении глубокого анализа сетевого трафика. // Труды Института системного программирования РАН, том 27, выпуск 4, 2015, с. 5-22.
3. Wireshark – https://www.wireshark.org/ (дата обращения 20.12.2017).
4. А.И. Гетьман, Ю.В. Маркин, Д.О. Обыденков, В.А. Падарян, А.Ю. Тихонов. Подходы к представлению результатов анализа сетевого трафика. // Труды Института системного программирования РАН, том 28, выпуск 6, 2016, с. 103-110.
5. Oink: a Collaboration of C/C++ Tools for Static Analysis and Source-to-Source Transformation – http://dsw.users.sonic.net/oink/index.html (дата обращения 20.12.2017).
6. The Ruby IRC Bot – https://ruby-rbot.org/ (дата обращения 20.12.2017).
7. Index of /publicDatasets/CTU-Malware-Capture-Botnet-45 – https://mcfp.felk.cvut.cz/publicDatasets/CTU-Malware-Capture-Botnet-45/ (дата обращения 20.12.2017).
8. Snort – http://www.snort.org/ (дата обращения 20.12.2017).
9. The Bro Network Security Monitor – http://www.bro.org/ (дата обращения 20.12.2017).

Ключевые слова: углубленный разбор сетевого трафика (Deep Packet Inspection), обратная инженерия сетевых протоколов, архитектура системы разбора, построение данных в указанном формате.

* Работа поддержана грантом РФФИ 15-07-07652 А.

Комментарии могут оставлять только зарегистрированные пользователи