Сбор журналов — это процесс сбора данных журналов из различных источников устройств в сети организации и их агрегирования в центральном расположении для лучшего анализа. Собирая сообщения из различных источников журналов, мы можем анализировать все события, происходящие в организации, и создавать долгосрочную базу данных событий. Эти сообщения содержат важную информацию об определенных ошибках, которые могут возникнуть в нашей системе. Существует два наиболее распространенных механизма сбора данных журналов — сбор журналов путем установки агентов и сбор журналов напрямую без агентов. Другие распространенные методы сбора журналов включают сбор журналов на основе API, сбор журналов на основе WMI и SNMP. Сбор журналов на основе агента. Этот механизм сбора журналов использует агент, установленный на устройстве (источники журналов). Агент собирает данные журнала и безопасно отправляет их на центральный сервер. В нашем случае в качестве центрального сервера используется SIEM-система Graylog. Преимуществом использования агентного сбора логов является автоматизация процесса: агенты позволяют автоматизировать сбор и анализ логов, что значительно упрощает процесс и снижает вероятность возникновения ошибок. Еще одним преимуществом является то, что в агентах могут создаваться определенные нужды и требования с центрального сервера, что избавляет от необходимости каждый раз обращаться к источникам журналов и значительно упрощает работу. Мы используем Graylog Sidecar для управления конфигурацией и плагин Filebeat, который собирает события и отправляет их на сервер Graylog. В качестве источника журнала используется сервер Ubuntu 20.04.
В Linux есть два типа механизмов ведения журнала: — журналирование ядра: связано с информационными записями, которые ядро может записывать: ошибки, предупреждения, системные записи; — ведение журнала пользователей: эти записи журнала, связанные с пользовательским пространством, связаны с процессами или службами, которые могут выполняться на хост-компьютере. Мы используем журналы аудита для отслеживания активности пользователей. Система аудита Linux помогает нам вести журнал для каждого действия на сервере. Благодаря этому мы можем отслеживать события, связанные с безопасностью, записывать события в файл журнала и обнаруживать инциденты или несанкционированные действия, изучая файлы журналов аудита. То есть мы можем выбирать, какие действия на сервере и в какой степени мы хотим их отслеживать. Аудит не обеспечивает дополнительной безопасности нашей системы, он помогает отслеживать нарушения системной политики и позволяет нам принимать дополнительные меры безопасности для их предотвращения.
Для начала давайте установим пакеты auditd в Linux: В пакет аудита входит несколько инструментов с разным функционалом. К ним относятся: Auditd — это компонент пользовательского пространства, отвечающий за запись записей аудита на диск. Ausearch — это специальный компонент для запроса журналов демона аудита. Aureport — это настраиваемый компонент, который создает сводные отчеты по журналам аудита. Auditctl — это программа, используемая для настройки параметров ядра, связанных с аудитом, просмотра состояния конфигурации и загрузки пользовательских правил аудита. При загрузке системы auditctl считывает правила из файла /etc/audit/audit.rules и загружает их в ядро. Как узнать, кто редактировал файлы в Linux с помощью auditd: для начала нужно определить, какие файлы на сервере нужно мониторить.
При загрузке системы auditctl считывает правила из файла /etc/audit/audit.rules и загружает их в ядро. Правила можно зарегистрировать в etc/audit/rules.d/audit.rules, а также с помощью командной строки. В качестве примера рассмотрим файл /etc/hosts. В записи команды используются следующие параметры: -w Задает путь к отслеживаемому объекту файловой системы. -p Указывает тип разрешений для включения мониторинга файловой системы. r=чтение, w=запись, x=выполнение, a=изменение атрибутов. -k указывает свободную строку текста длиной до 31 байта. Он может четко определить аудиторские записи, сделанные в Регламенте. Мы отправляем сгенерированные журналы в систему Graylog для дальнейшего анализа и хранения. Graylog — это инструмент для сбора и управления журналами. Он используется для сбора, анализа, визуализации журналов и отправки предупреждений. Сервер Graylog состоит из 4 компонентов, а именно: Graylog Server — это сервер, который отправляет логи для отображения в веб-интерфейсе. MongoDB — это сервер базы данных, используемый для хранения данных и конфигураций. ElasticSearch — инструмент анализа журнала для Graylog Server. Предоставляет рабочую среду для Java-Elasticsearch. Все эти инструменты работают вместе для достижения основной цели консолидации журналов и управления ими. Далее необходимо установить на хост менеджер конфигурации (graylog-sidecar) и сборщик (filebeat), с которых будут собираться логи:
В этот момент выставляем правила Firewall, открываем нужные порты:
# firewall-cmd --zone=itsoft --add-ports=5044/udp
# firewall-cmd --runtime-to-permanent
Далее Sidecar должен появиться в System → Sidecars → Overview:
Здесь вам нужно нажать кнопку «Конфигурация», чтобы настроить агент, и написать, какие файлы журнала будут отправляться в систему SIEM. Следующий случай показывает, что он получает сообщения журнала из файлов /var/log/audit/audit.log и /var/log/cmdline. В файл cmdline записываются сообщения истории действий bash. Подробнее об этом будет рассказано в конце статьи.
Перейдите в System → Inputs , нажмите кнопку « show received messages » на входе Graylog-Sidecar и отслеживайте входящие журналы:
Из приведенного выше сообщения журнала вы можете увидеть, какое имя хоста регистрируется, время и само сообщение. В сообщении видно, что пользователь с uid=0 имеет доступ к файлу /etc/hosts. Далее настроим оповещения. Alerts → Alerts & Events → Get Started!
Давайте начнем создавать оповещение с помощью:
Title: FILE_ACCESS_!!! — название оповещения.
Description (Optional): — описание предупреждения.
Priority: — приоритет.
Шаг 2 Настройки выполняются следующим образом:
Condition Type: Filter & Aggregation
Search Query: «file_permission» (перед добавлением журналов аудита на сервер мы записали значение ключа как file_permission. Мы используем это значение в качестве фильтра для определения журнала)
Streams (Optional): All messages (мы применяем фильтр ко всем журналам)
Search within the last: 1 minutes (Искать за последние: 1 минут)
Execute search every: 30 seconds
Добавьте кнопку Включить в поле для флажка. Мы устанавливаем Создать события для определения, если фильтр имеет результаты. Вот краткое изложение того, что мы сделали: Мы добавляем поток, чтобы уменьшить количество сообщений, которые нужно фильтровать. Мы ввели запрос для фильтрации журналов перед неудачными входами в систему. Мы сгруппировали наши журналы, чтобы агрегирование применялось только к каждому пользователю.
Если вы обратите внимание на правый столбец, вы увидите отфильтрованные сообщения журнала среди последних полученных журналов. Это помогает убедиться, что значение, которое вы вводите в фильтре, является правильным. На скриншоте ниже мы видим, что нужное нам сообщение было отфильтровано.
Следующий шаг — поля. Этот столбец позволяет событию заполнять данные из исходного журнала в индексе событий Graylog. Это позволяет вам добавлять дополнительную информацию к следующим оповещениям для сбора важной информации. Это уведомление также можно использовать для ограничения объема отправляемых данных. Событие записывается в поток «Все события» и содержит настраиваемое поле, а также результат слияния, создавшего событие. На скриншоте мы видим, что настроено добавление логов к тревожным сообщениям.
Следующий шаг — кнопка «Notifications». После определения событий, необходимых для запуска предупреждения, вы можете зарегистрировать уведомление. Добавляя уведомление к событию или группе событий, мы можем определить, как и когда информация поступает из Graylog. На экране выбираем заранее подготовленное сообщение graylog_alerts, информация о котором будет показана далее ниже. В столбце «Настройки уведомлений» установите число 10 для значения невыполненных сообщений. Это количество сообщений, включенных в оповещение.
Теперь пришло время создать сообщение. Нажмите кнопку Создать уведомление. Заполните следующие поля во всплывающем меню: Заголовок: Мы устанавливаем уникальный заголовок для уведомления (graylog_alerts). Описание (необязательно): При желании вы можете добавить дополнительные сведения об уведомлении в это поле. Тип уведомления: выберите тип уведомления из выпадающего меню. В нашем случае мы отправляем все сообщения в мессенджер Telegram. После выбора типа уведомления будут отображаться дополнительные поля в зависимости от выбранного типа. Эти поля создаются для каждого конкретного типа уведомления. Подробнее об этом ниже. Вы также можете протестировать уведомление, выбрав опцию «Запустить тестовое уведомление». Завершаем настройку уведомления нажатием кнопки Создать уведомление.
Далее разберем шаги по отправке сообщения в мессенджер Telegram. Telegram — популярное приложение для обмена сообщениями, которое вы можете использовать для отправки предупреждений из Graylog. Давайте создадим бота Telegram для настройки оповещений Telegram в Graylog: Откройте Telegram и создайте бота, используя «BotFather». Мы отправляем сообщение «/newbot» в BotFather и следуем инструкциям по созданию нового бота. Мы скопируем значение API для нового бота.
Мы указываем шаблон сообщения, используя следующий шаблон.
Устанавливаем плагин Telegram на сервер Graylog: заходим на сервер Graylog с root-правами. Пишем плагин с платформы Github. Прежде чем писать, обратите внимание на версию Graylog, которую вы используете.
После выполнения этих действий мы перезагрузим сервер. Теперь мы можем получать уведомления Graylog в нашем приложении Telegram. Обратите внимание, что для получения оповещений нам необходимо установить приложение Telegram и войти в систему. Graylog рекомендует хранить ваш токен API и идентификаторы чата в тайне, чтобы предотвратить несанкционированный доступ к ботам и сообщениям. Мы можем имитировать оповещение, войдя в клиент Graylog и внеся изменения в файл /etc/hosts. Вы можете отслеживать приход следующих сообщений в созданную телеграм-группу.
Вы можете убедиться, что полученное сообщение соответствует заданному ранее шаблону.
В заключение можно сказать, что Graylog — это мощный и гибкий инструмент для сбора, анализа и визуализации лог-файлов и других данных в режиме реального времени. Его можно использовать для мониторинга систем и приложений, а также для выявления системных проблем и аномалий. Благодаря открытому и гибкому API Graylog можно интегрировать с другими инструментами и сервисами, такими как Slack, PagerDuty и Telegram, для быстрого и эффективного реагирования на проблемы. Graylog также имеет отличную документацию и поддержку сообщества, что делает его доступным и простым в использовании как для начинающих, так и для опытных пользователей. В целом, Graylog — это мощный и полезный инструмент для управления файлами журналов и их анализа, который может значительно улучшить работу нашей системы и приложений.
Литература:
- David R. Miller, Shon Harris, Alan Harper, Stephen Van Dyke, Chris Blask Security Information and Event Management (SIEM) — New-York: McGraw–Hill 2014, 50–250 p.
- Котенко И. В., Федорченко А. В., Саенко И. Б., Кушнеревич А. Г. Технологии больших данных для корреляции событий безопасности на основе учета типов связей // — Москва: изд. Кибер, 2017. — № 5 (24). — C 2–16.
- Новикова У. С., Котенко И. В. Механизмы визуализации в SIEM–системах. Системы Высокой Доступности // — Москва: изд. Кибер, 2012. — 91–99 с.
- Карасёв С. В., Рыболовлев Д. А. Применение методов выявления зависимостей между событиями при построении систем управления инцидентами безопасности // — Воронеж: изд. Свет, 2016. № 3. — 140–156 c.
- Новикова У. С., Котенко И. В. Механизмы визуализации в SIEM–системах. Системы Высокой Доступности // — Москва: изд. Кибер 2012. — 91–99 с.
- Марков А. С., Цирлов В. Л. Структурное содержание требований информационной безопасности // Мониторинг правоприменения. Ташкент: изд. Ташкент, 2017. — № 1 (22) — 53–61 с.
- D. R. Miller, S. Harris, A. A. Harper, S. VanDyke, C. Blask. Security Information and Event Management (SIEM) Implementation. New-York: McGraw–Hill 2016. 400–430 p.
- Олифер Виктор, Олифер Наталья Компьютерные сети. Принципы, технологий, протоеолы: Юбтлейное издание — Санкт-Петербург: изд. Питер, 2021. — № 1008 (Серия «Учебник для вузов») — 70–75 с.
- Ершов А. Л., Карасёв С. В., Поляков С. А., Рыболовлев Д. А. Подход к формированию модели данных события информационной безопасности // Информационные системы и технологии. — Воронеж: изд. Сара, 2017. — № 6 (104). — C. 124–129.
- Шабуров, А. С. Моделирование оценки угроз безопасности информационных систем персональных данных / — Вестник ПНИПУ. 2018. –№ 7 — C. 149–159.
