Оповещение об аномальной активности

Для автоматического разбора системного журнала и оповещения администратора о появлении аномальной активности предусмотрен специальный скрипт. Для регулярных проверок можно настроить его периодический запуск (например, с помощью crontab [7]).

Из командной строки скрипт принимает два имени файла. Первый файл содержит журнал для анализа[2] (он открывается только для чтения), во второй файл будет собираться информация об аномальных соединениях. В файле логов скрипт ищет записи с префиксом «IS:reject». Из их числа выбираются новые (те, которых еще нет во втором файле). Информация о них добавляется во второй файл и отправляется администратору по электронной почте. Есть возможность регулирования подробностей описания аномальных соединений. По умолчанию проверяются поля адресов и порта назначения.

Тестовые испытания и их результаты.

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

Основная статистика состояла из 292 тысяч уникальных соединений, собранных в результате непрерывного мониторинга локальной сети на протяжении недели. Построение дерева ЛРП заняло 46 минут и 35 секунд на компьютере, оснащенном процессором Intel Core2 Duo E4500 2.2ГГц и 1 Гб оперативной памяти. Такое время кажется нам удовлетворительным, учитывая то, что данную операцию нужно выполнить лишь единожды. Но если в дальнейшем это будет вызывать проблемы, имеется потенциал для улучшения данного параметра, так как серьезные работы по оптимизации по скорости построения дерева еще не проводились.

При поиске аномальной активности с помощью созданных правил удалось получить практические результаты, доказывающие полезность системы в реальных условиях, а именно выявить несколько фактов нецелевого использования ресурсов локальной сети (несанкционированные запуски клиентов пиринговых сетей на компьютерах лаборатории Parallels-НГУ).

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

Количество генерируемых правил.

На начальных этапах работы были опасения, что количество правил, генерируемых программой, будет расти вместе с ростом размера статистики, что сведет на нет практическую ценность проекта. Но этого не происходит. Во время тестирования путем выбора случайных соединений из основной статистики было создано несколько дочерних статистик разных мощностей, и замерено количество правил, генерируемых для них. Результаты представлены на рисунке 3. Можно видеть, что происходит насыщение, и количество правил колеблется в пределах некоторого среднего значения, почти независимо от размера выборки.

Рисунок 3. Количество правил для статистик разных мощностей.

Может показаться, что генерируется слишком много правил (1200–1500). Однако следует учитывать, что большая их часть служит для обработки очень редко встречающихся соединений и, следовательно, пренебрежимо мало влияет на скорость анализа трафика.