Файл: Обзор методов и средств анализа сетевого трафика и поиска аномалий трафика (Классификация средств мониторинга и анализа).pdf
Добавлен: 25.04.2023
Просмотров: 1916
Скачиваний: 43
СОДЕРЖАНИЕ
Глава 1. Исследование существующих систем мониторинга и анализа сетевого трафика
1.1 Классификация средств мониторинга и анализа
Глава 2. Проектирование системы
Глава 3. Разработка прототипа системы анализа сетевого трафика
3.1 Модуль преобразования дампа сетевого трафика
3.2 Обоснование выбора программных средств
3.3 Модуль хранения сетевого трафика
3.4 Обоснование выбора программных средств
3.5 Модуль анализа и отображения
3.7 Анализ частоты запросов по ip-адресам
3.8 Обоснование выбора программных средств
В первой главе обоснована актуальность проблемы анализа сетевого трафика для защиты от несанкционированного воздействия и рассмотрены существующие способы решения данной проблемы.
В последнее время в области систем управления наблюдаются две достаточно четко выраженные тенденции:
- интеграция в одном продукте функций управления сетями и системами;
- распределенность системы управления, при которой существует несколько консолей, собирающих информацию о состоянии устройств и подсистем, а затем выдающих управляющие действия.
Это связано с тем, что большинство представленных систем узкоспециализированы и направлены на хорошее выполнение своего функционала. Соответственно специалистам приходится использовать связку из нескольких продуктов, чтобы полностью покрыть все возможные уязвимости сети: системы мониторинга и учета трафика проверяют работоспособность оборудования и сети, выявляют оптимальность текущей аппаратно-программной конфигурации; системы обнаружения и предотвращения вторжений – позволяют выявить угрозу внутри и снаружи сети.
Современный подход к построению систем обнаружения сетевых вторжений и выявления признаков компьютерных атак на информационные системы полон недостатков и уязвимостей, позволяющих, к сожалению, злонамеренным воздействиям успешно преодолевать рубежи защиты информации.
На рынке представлено около десятка систем предотвращения и обнаружения вторжений [13], но все они имеют один важный недостаток: так как их работа построена на отработке правил и шаблонов, не все случаи вторжений улавливаются; кроме того они слабо справляются с
«мимикрирующим» вредоносным трафиком.
Помимо этого стоит отметить, что продуктов отечественных производителей на данном рынке представлено мало. Также, описанные ранее методики не всегда доступны, так как являются коммерческой тайной [14]. Поэтому возникает необходимость в разработке новой системы, которую можно применять в комплексе сетевых инструментов.
По итогу первой главы была выполнена первая задача работы – изучить проблемы обеспечения безопасности сети и исследовать современные методики анализа сетевого трафика.
Глава 2. Проектирование системы
2.1. Задача перехвата трафика
Система анализа должна обеспечивать захват 100% трафика и предоставлять эффективные методы анализа с навигацией по результатам.
Если говорить о комплексном решении задачи анализа сетевого трафика, то в первую очередь следует разделить ее на три в достаточной степени независимые подзадачи (рисунок 2): перехват трафика, его хранение и анализ [8].
Рисунок 2 – Подзадачи системы анализа сетевого трафика
Захват трафика осуществляется посредством снифферов. В общем случае, сниффер (англ. «sniffer» - дословно переводится как «нюхач» или «вынюхиватель») – это программа или программно-аппаратное устройство, предназначенное для перехвата трафика. В рамках конкретных продуктов могут быть реализованы дополнительные возможности, например, разбор заголовков сетевых протоколов, фильтрация по заданным критериям, восстановление сессий. Перехват сетевого трафика может осуществляться:
- с помощью «прослушивания» сетевого интерфейса;
- подключением сниффера в разрыв канала;
- ответвлением («зеркалированием») трафика и направления его копии на сниффер (пример: Network tap);
- посредством анализа побочных электромагнитных излучений;
- через атаку на канальном или сетевом уровне, приводящую к перенаправлению трафика жертвы на сниффер.
Различают два вида снифферов по их месторасположению:
-
- на маршрутизатор (шлюзе);
- на оконечном узле сети.
В первом случае будет перехватываться весь трафик, проходящий через интерфейсы устройства, во втором – либо только трафик узла сети, если сетевая карта работает в нормальном режиме, либо пакеты всех устройств этого сегмента сети (для этого у сетевой карты выставляется режим «promiscuous» - неразборчивый).
Создаются такие программы, основываясь на свободно распространяемой библиотеке Pcap (англ. «packet capture»). Она предназначена для использования совместно с языками C/C++, а для работы с библиотекой на других языках, таких как Java, .NET, используют обертки. Для Unix-подобных систем это библиотека libpcap, а для Microsoft Windows – WinPcap.
Программное обеспечение сетевого мониторинга может использовать libpcap или WinPcap, чтобы захватить пакеты в сети, для передачи пакетов в сети. Кроме того поддерживается сохранение захваченных пакетов в файл и чтение файлов, содержащих сохранённые пакеты.
Так как разрабатываемая нами система подключается к выходному маршрутизатору, связывающего сеть провайдера и сеть Интернет, соответственно, чтобы не создавать задержки в работе оборудования при таком объеме обрабатываемого трафика, разумно использовать метод «зеркалирования» трафика, то есть дублировать его на другой сетевой интерфейс (рисунок 3).
Рисунок 3 – Схема установки системы сбора информации
Что касается задачи анализа, то предпочтение тому или иному инструменту отдается исходя из специфики подзадач, которые необходимо решить [9]. Большинство существующих инструментов, как правило, проводит разбор заголовков сетевых протоколов, а также восстанавливает сессии (базовый анализ). В то же время существуют достаточно специфические задачи, для которых может не оказаться готового инструмента, например:
- анализ туннелированных протоколов произвольной глубины;
- анализ сессий на уровне приложений (выделение связей между потоками данных, передаваемых по сети);
- выполнение определенных сценариев (скриптов) в случае обнаружения в трафике предварительно заданных сигнатур.
Выделяют два режима работы анализаторов:
- в реальном времени;
- по предварительно сохраненному трафику.
Анализ в реальном времени требует поддержки работы инструмента в непрерывном режиме с производительностью, достаточной для разбора трафика, поступающего на вход. При этом должна быть обеспечена возможность обработки потенциально бесконечного входного потока данных.
В случае отложенного анализа инструмент получает входные данные из файла, что позволяет проводить более детальный анализ сетевой трассы по сравнению с анализом в режиме реального времени на аналогичном трафике.
Для примерной оценки работы и тестирования прототипа системы нам был предоставлен трафик Сибирского федерального университета (СФУ) с шириной канала по официальным данным – 1,5 Гбит/с. Если смотреть данные статистики по загруженности на 09 июня 2016 года (рисунок 4, таблица 1), то в сумме его средняя нагрузка выходит 591 Мбит/с. Соответственно такой поток трудно обрабатывать в реальном времени, эффективнее будет сохранять его дамп и работать уже с ним. Отсюда следует необходимость решения задачи хранения трафика.
Таблица 1 – Статистика трафика за сутки
Канал |
Максимальная загруженность канала (Мбит/с) |
Средняя загруженность (Мбит/с) |
Текущая загруженность (Мбит/с) |
Входящий |
810.0 |
478.7 |
526.8 |
Исходящий |
206.7 |
112.3 |
150.2 |
Рисунок 4 – Загруженность внешнего Интернет-канала СФУ
Предоставленная часть трафика СФУ занимает 110 Гб для 28,190358 секунд реального времени передачи информации; можно предположить, что для провайдера эти цифры будут увеличены в разы. Из полученных сведений следует необходимость обработки и преобразования дампа с целью уменьшения занимаемого пространства и оптимизации выборки данных. Для достижения этого хорошо подходят базы данных.
Во-первых, это дает нам возможность быстро находить среди всего дампа подходящие условиям пакеты, потому что каждый из них хранится отдельной записью в таблице. Кроме этого для ускорения выборок большого количества данных применяется индексирование.
Индекс – объект базы данных, создаваемый из значений одного или нескольких столбцов таблицы и указателей на соответствующие строки таблицы. Соответственно ускорение работы достигается в первую очередь за счёт того, что индекс имеет структуру, оптимизированную под поиск.
Существует два типа индексов: кластерные и некластерные. При наличии кластерного индекса строки таблицы упорядочиваются по значению ключа этого индекса.
Если в таблице нет кластерного индекса, таблица называется кучей, и индекс, созданный для такой таблицы, содержит только указатели на записи. Это второй тип индексов. Кластерный индекс может быть только одним для каждой таблицы, но каждая таблица может иметь несколько различных некластерных индексов, каждый из которых определяет свой собственный порядок следования записей.
Индексы могут быть реализованы различными структурами, часто применяемыми являются B*-деревья, B+-деревья, B-деревья и хеши.
Для оптимальной производительности запросов индексы обычно создаются на тех столбцах таблицы, которые больше используются в запросах. То есть для одной таблицы может быть создано несколько индексов. Однако увеличение числа индексов замедляет операции добавления, обновления, удаления строк таблицы, так как при этом приходится обновлять сами индексы. А поскольку они занимают дополнительный объем памяти, перед их созданием следует убедиться, что планируемый выигрыш в производительности запросов превысит дополнительную затрату ресурсов компьютера на сопровождение индекса.
Во-вторых, применение баз данных должно обеспечить уменьшение размера занимаемого пространства, так как в продуманной архитектуре на хранение останутся только прописанные данные.
В разработанном прототипе трафик СФУ размером 110 Гб был преобразован и записан в базу данных; размер новых данных составил 73,9 Гб, что иллюстрирует сжатие в 1,49 раз. Количество записанных пакетов – 138 миллионов.
Таким образом, перед введением системы в эксплуатацию нужно провести исследование: какие базы данных лучше всего подходят для этой цели.
Во второй главе была разработана архитектура прототипа и описаны следующие модули системы:
- модуль захвата трафика;
- модуль хранения пакетов;
- модуль анализа полученных данных.
Также были выявлены важные критерии для некоторых модулей. Например, мы установили, что при перехвате трафика нужно использовать метод «зеркалирования», преобразовывать дамп и сохранять его базе данных.
По итогу второй главы решена следующая задача работы – разработка оптимальной архитектуры системы.
Глава 3. Разработка прототипа системы анализа сетевого трафика
3.1 Модуль преобразования дампа сетевого трафика
Во второй главе работы спроектирована архитектура системы анализа, ее развернутую схему можно увидеть на рисунке 5.
Трафик с выходящего маршрутизатора дублируется в систему в виде фиксированных по объему файлов, которые затем попадают на чтение и преобразование программе-снифферу. Из пакетов мы собираем и записываем в базу данных следующую информацию:
- длину пакета;
- время получения;
- о протоколах сетевого и транспортного уровня;
- ip-адреса источники и получателя;
- флаги SYN, ACK, FIN протокола TCP;
- значения портов протокола UDP.
Получая запрос от пользователя, web-сервер загружает из базы необходимые данные, анализирует их в запрошенном виде и отображает.
Рисунок 5 – Структурная схема системы анализа сетевого трафика
Данный модуль предназначен для чтения и преобразования в другой формат сохраненных данных. Он постоянно мониторит состояние файловой системы сервера: как только появляется новый файл дампа, сразу отправляем его на обработку.