Постановка задачи и новизна

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

Разработать метод контроля над трафиком локальной сети при помощи выявления аномальных для данной сети соединений. Выяснить перспективы применимости такого подхода на практике.

Для классификации объектов и выявления закономерностей используются методы интеллектуального анализа данных (ИАД). Но для выявления аномальных событий стандартные методы ИАД не приспособлены, т.к. требуют наличия в обучающей выборке как положительных, так и отрицательных примеров. Существуют разработки, призванные избавиться от этой проблемы, например, метод гибридной корреляции событий (ГКС, [1]). Основная суть ГКС состоит в том, чтобы искать аномальные события как нарушения течения нормальных событий. Использованию ГКС применительно к трафику локальной сети посвящены работы [2, 3]. В данной работе применяется метод, эксплуатирующий ту же идею, но выявляющий аномальный трафик с помощью точного описаниясобранной статистики трафика локальной сети. Такой метод нельзя назвать методом ИАД, т.к. любой трафик, отсутствующий в статистике, признается аномальным. Прогнозов по поводу нормального трафика, которого нет в статистике — не делается. Чтобы компенсировать этот недостаток, нужно учесть особенности, вносящие элемент случайности в трафик локальной сети (например, номера портов отправителя в протоколе TCP), а также работать со статистиками, собранными в течение продолжительного времени. К тому же, необходимо реализовать анализатор таким образом, чтобы он мог обрабатывать большие объемы данных в реальном времени. К «плюсам» подхода относится точность распознавания (при достаточно большой статистике, ведь трафик локальных сетей статичен и редко меняется) и низкие требования к квалификации пользователя (нет необходимости настраивать различные параметры, присущие методам ИАД).

Для достижения поставленной цели необходимо разработать систему, которая по статистике установки соединений в локальной сети создает правила, с помощью которых можно выявить аномальный трафик. Нормальный трафик (который есть в статистике) должен игнорироваться. Набор таких правил и представляют собой автоматически сгенерированный анализатор трафика для данной локальной сети. В качестве основного варианта использования такого анализатора предлагается следующая схема. С помощью управляемого коммутатора настраивается зеркалирование трафика сети на определенный физический порт. К нему подключается компьютер с операционной системой Linux (возможен вариант с развертыванием ее внутри виртуальной машины). На этом компьютере устанавливаются правила, и таким образом происходит мониторинг трафика сети. Анализатор работает в автономном режиме и извещает администратора о появлении аномалий каким-либо образом (например, по электронной почте). Более подробно о вариантах использования будет рассказано в главе 10.

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

1. Появилось новое соединение от пользователя А к пользователю Б. Это может быть следствием активности вредоносного программного обеспечения. Например, на А появился вирус, который распространился на Б. Или Б установил на А программу-троян, которая теперь пересылает ему личную информацию А. Или А проводит атаку на Б.

2. Появилось новое соединение от А к Б через узел М1. Возможно, раньше они соединялись через узел М2, но на нем появились неполадки, и им пришлось искать обходные пути.

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

Таким образом, возможность выявления аномального трафика в локальной сети помогает в обнаружении проблем, связанных с вредоносным ПО, неисправностями оборудования или нелегальным использованием ресурсов. Но исследование доступных решений показало, что систем такого типа, по-видимому, не существует, либо они имеют закрытый статус и не предназначены для широкого использования. Ближайшие аналоги, которые удалось найти — это широкий спектр так называемых NIDS/NIPS-решений (Network Intrusion Detection/Prevention Systems, сетевые системы обнаружения/предотвращения вторжений). Данные системы призваны решать задачу комплексной защиты сетей, однако они работают с позиций, сильно отличающихся от наших. Используются в основном два алгоритма анализа трафика. Первый — это сравнение битовой последовательности потока данных с эталонной сигнатурой. Второй — выявление аномальной протокольной активности (Protocol Anomaly Detection, PAD). Сигнатурный анализ позволяет установить и обезвредить уже известную угрозу, а PAD специализируется на атаках, не имеющих сигнатур. В процессе проверки средствами PAD система исследует использование сетевых протоколов на соответствие заложенным требованиям (это могут быть как общие спецификации RFC, так и специфические критерии разработчиков).

Фактически стандартом де-факто среди NIDS/NIPS благодаря своей широкой доступности стал Snort [8]. Это бесплатная система с открытым исходным кодом. Она способна выполнять регистрацию пакетов и в реальном времени осуществлять анализ трафика в IP сетях. Состоит из набора модулей для активного блокирования или пассивного обнаружения ряда известных нападений и зондирований, таких как переполнение буфера, стелс-сканирование портов, атаки на веб-приложения, попытки определения ОС. Кроме Snort существует много коммерческих программных и программно-аппаратных решений класса NIDS/NIPS (Cisco IDS/IPS, StoneGate IPS, Radware Defense Pro, Juniper Networks Tap, Intrusion SecureNet и т.д.). Они были нам недоступны для непосредственного изучения, однако из обзоров (например, [9]) следует, что базируются все эти системы также на анализе сигнатур и PAD.

Выбор платформы.

В качестве платформы для реализации была выбрана операционная система Linux. Для представления правил выделения аномального трафика решено было использовать формат правил iptables, утилиты управления межсетевым экраном netfilter, встроенным в ядро ОС. Выбор обусловлен популярностью Linux на серверах и удобством экспериментов с ОС этого семейства благодаря их открытости. Правила iptables были выбраны по нескольким причинам.

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

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

В-третьих, netfiler/iptables являются частью любой ОС семейства Linux/UNIX. Это избавляет администраторов от необходимости устанавливать и осваивать дополнительное ПО при работе с нашей системой. Результат работы программы представляет собой набор правил iptables, которые отлично знакомы любому Linux/UNIX-администратору.

С самого начала было ясно, что задача предполагает большие объемы вычислений, из-за чего необходимо минимизировать накладные расходы при работе системы. Поэтому от языков с автоматическим управлением памятью (например, Java) решено было отказаться, и в качестве языка реализации был выбран С++. Также некоторые компоненты (например, оповещение администратора о появлении аномальной активности) реализованы при помощи скриптового языка Bash.

В качестве инструмента хранения и управления статистиками была выбрана встраиваемая база данных Berkeley DB. Возможностей стандартной библиотеки С++ недостаточно, т.к. объемы данных могут быть огромны, что не позволяет хранить все в оперативной памяти. Реляционные же базы данных для наших целей избыточны и потребовали бы усложнения системы, как с точки зрения программиста, так и с точки зрения пользователя.