ПРОЕКТИРОВАНИЕ КОМПОНЕНТ УПРАВЛЕНИЯ КОНФИГУРАЦИЯМИ И ОБРАБОТКИ СОБЫТИЙ СИСТЕМЫ ОБНАРУЖЕНИЯ ВТОРЖЕНИЙ OSSEC HIDS

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

Система обнаружения вторжений OSSEC HIDS используется для контроля изменений в файлах веб-сервисов, расположенных на отдельных серверах компании. Отслеживаются изменения связанные с вредоносным, предумышленным или непредумышленным воздействием.

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

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

Рисунок 1. Обобщенная системная архитектура

Для организации управления настройками посредством веб-интерфейса или внешних сервисов был выбран подход называемый «Толстый клиент + API» или «API First», который позволит решить одновременно обе эти задачи.

Толстый клиент предполагает, что часть бизнес-логики исполняется на нем. При этом для веб-приложений бизнес-логика на сервере остается, но сервер отдает только данные.

Для начала браузер обращается к веб-серверу и загружает HTML, Javascript, CSS и изображения. Клиент получает HTML шаблон, а затем данные подгружаются с помощью Javascript и отображается страница. Если некоторые части уже были отрисованы, то данные берутся из js-объекта, при этом не инициируется новое обращение к серверу.

Преимущества применения данного метода:

• Высокая скорость отклика пользователю;
• Только измененные фрагменты страницы заново подгружаются;
• Минимизация обращений к серверу;
• Доступ к данным из различных источников;
• Эффективность разработки за счет разделения зон ответственности.

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

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

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

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

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

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

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

Рассмотрены два решения для хранения указанных выше данных по событиям:

• Вектора, привязанные к событию и содержащие набор флагов для статусов, пришедших от каждого плагина.
• Хранение на основе записей в Redis.

Преимущества использования Redis в сравнении с векторами:

• Готовое решение. Данные поступают из разных источников. Не нужно самостоятельно разрабатывать решения для синхронизации и т. д.
• Масштабируемость. Использование нескольких серверов.
• Данные сохраняются после перезагрузки сервера.
• Аналогичная высокая скорость работы, так как также работает с оперативной памятью.

Redis представляет собой некое сетевое журналируемое хранилище данных «ключ — значение». Все данные Redis хранит в виде словаря. Одно из ключевых отличий Redis от других хранилищ данных заключается в том, что значения этих ключей не ограничиваются строками. Redis поддерживает различные абстрактные типы, такие как хеш-таблицы, которые могут помочь при хранении статусов связанных c одним redisID c сообщениями.

Рисунок 2. Подробная системная архитектура

Архитектурную стратегию для написания компонент можно разбить на две логические части. Во-первых, это «API First» подход для веб части. Во-вторых, это архитектура компоненты обработки «Ядро + Плагины», основанная на использовании очередей.

Список литературы:

1. Конференция РИТ 2013. Доклад «API плюс толстый клиент – новая парадигма веб-разработки?» [Открытый электронный ресурс], URL: [https://www.gramant.ru/AboutUs/Conference/RIT2013] (Дата обращения 23.02.2017)
2. Очередь сообщений (Message Queue) [Открытый электронный ресурс], URL: [https://habrahabr.ru/post/165981/] (Дата обращения 02.04.2017)
3. OSSEC Host-Based Intrusion Detection Guide [Текст] / Rory Bray, Daniel Cid, Andrew Hay – Syngress, Elsevier,  2008 г. – 416 с.
4. Redis – высокопроизводительное хранилище данных [Открытый электронный ресурс], URL: [https://habrahabr.ru/post/64917/] (Дата обращения 29.04.2017)