Для достижения поставленной цели необходимо разработать систему, которая по статистике установки соединений в локальной сети создает правила, с помощью которых можно выявить аномальный трафик. Нормальный трафик (который есть в статистике) должен игнорироваться. Набор таких правил и представляют собой автоматически сгенерированный анализатор трафика для данной локальной сети. В качестве основного варианта использования такого анализатора предлагается следующая схема. С помощью управляемого коммутатора настраивается зеркалирование трафика сети на определенный физический порт. К нему подключается компьютер с операционной системой Linux (возможен вариант с развертыванием ее внутри виртуальной машины). На этом компьютере устанавливаются правила, и таким образом происходит мониторинг трафика сети. Анализатор работает в автономном режиме и извещает администратора о появлении аномалий каким-либо образом (например, по электронной почте). Более подробно о вариантах использования будет рассказано в главе 10.
При наличии инструмента, позволяющего выявить аномальный для данной локальной сети трафик, можно решать широкий спектр задач по обеспечению безопасности работы в сети. Ниже приведено несколько примеров.
Таким образом, возможность выявления аномального трафика в локальной сети помогает в обнаружении проблем, связанных с вредоносным ПО, неисправностями оборудования или нелегальным использованием ресурсов. Но исследование доступных решений показало, что систем такого типа, по-видимому, не существует, либо они имеют закрытый статус и не предназначены для широкого использования. Ближайшие аналоги, которые удалось найти — это широкий спектр так называемых 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. Возможностей стандартной библиотеки С++ недостаточно, т.к. объемы данных могут быть огромны, что не позволяет хранить все в оперативной памяти. Реляционные же базы данных для наших целей избыточны и потребовали бы усложнения системы, как с точки зрения программиста, так и с точки зрения пользователя.
1. Система должна функционировать не на уровне отдельных пакетов, а на уровне соединений. Под соединением понимается поток пакетов между клиентом (инициатором соединения) и сервером. Даже для протоколов, не поддерживающих явно соединения (UDP, ICMP), необходимо выделять их логически из общего потока пакетов. Это необходимо для борьбы со случайными параметрами соединений (например, значения портов в некоторых протоколах).
2. Система должна предоставлять возможность сбора трафика, проходящего через определенный узел сети, и сохранение информации о параметрах устанавливаемых соединений и частоте их установки в базе данных. Таким способом можно собрать информацию не только о пакетах, относящихся к данному узлу, но и обо всех пакетах, появляющихся в сети. Для этого либо сам узел должен быть маршрутизатором, либо коммутатор должен быть настроен на зеркалирование пакетов на данный узел.
3. Система должна предоставлять возможность построения набора правил, описывающих собранную статистику. Скорость построения правил не является критичным параметром. Однако, в целях обеспечения применимости системы на практике, время построения набора не должно быть чрезмерно велико. Здесь трудно дать точные числовые характеристики. Но представляется разумным, если алгоритм будет работать за полиномиальное время.
4. Набор сгенерированных правил должен обладать следующим важнейшим свойством: чем чаще соединение с определенными параметрами встречается в статистике (то есть, чем чаще такое соединение появляется в сети), тем быстрее оно должно проходить через правила. Это позволяет значительно снизить нагрузку на процессор машины, на которой будут установлены правила, и обрабатывать большие объемы трафика на относительно маломощных компьютерах.
5. Количество генерируемых правил не должно расти с ростом размера статистики. При малых размерах такая зависимость допустима, однако по достижении определенного порога мощности должно происходить насыщение, т.е. прекращение роста количества правил.
6. Система должна поддерживать протоколы TCP, UDP и ICMP [10] и при построении правил использовать как минимум следующие параметры сетевых соединений: тип протокола, IP-адрес отправителя, IP-адрес получателя, порт получателя (имеет смысл для протоколов TCP и UDP. Порт отправителя обычно выбирается случайным образом и не должен учитываться).
7. Система должна предоставлять возможность перевода построенного набора правил в формат правил для iptables. Система должна генерировать файл(ы) с командами, необходимыми для того, чтобы полученные правила iptables вступили в силу. Также система должна генерировать файл(ы) с командами, позволяющими корректно удалить сгенерированные правила.