Как лицензируется и чем отличаются лицензии Elastic Stack (Elasticsearch)
В этой статье расскажем как лицензируется Elastic Stack, какие бывают лицензии, что туда входит (ключевые возможности), немножечко сравним Elastic с OpenDistro от AWS и другими известными дистрибутивами.
Как видно на картинке выше, существует 5 типов, условно говоря, подписок, по которым можно пользоваться системой. Подробности по тому, что написано ниже, вы можете узнать на специальной странице Elastic. Всё написанное в этой статье применимо к Elastic Stack, размещаемому на собственной инфраструктуре (on-premise).
Open Source. Это версия Elastic Stack, которая находится в свободном доступе в репозитории Elastic на Github. В принципе, вы можете взять ее и сделать убийцу Arcsight, QRadar, Splunk и других прямых конкурентов Elastic. Платить за это ничего не нужно.
Basic. Этот тип лицензии включает в себя возможности предыдущей лицензии, но дополнен функционалом, который не имеет открытого кода, но, тем не менее, доступен на бесплатной основе. Это, например, SIEM, доступ к ролевой модели, некоторые виды визуализаций в Kibana, Index Lifecycle Management, некоторые встроенные интеграции и другие возможности.
На этом бесплатные лицензии закончились и пришло время разобраться с платными лицензиями. Elastic Stack лицензируется по количеству нод Elasticsearch. Рядом может стоять хоть миллион Kibana и Logstash (или Fluentd, если угодно), но лицензии будут считаться именно по хостам, на которых развернут Elasticsearch. В расчет лицензий также не входят ноды с ролями Ingest, Client/Coordinating. На попадающее в расчет количество нод напрямую влияет объем входящего трафика и требования к хранению данных. Напомним, что для обеспечения надежности работы кластера, в нем должно быть минимум 3 ноды. Мы проводим расчет сайзинга исходя из методики, которую описывали в одной из предыдущих статей. При покупке лицензий Elasticsearch доступен только формат подписки длительностью от 1 года с шагом в 1 год (2, 3 и так далее). Теперь вернемся к типам лицензий.
Gold. В лицензии Elasticsearch уровня Gold появляется поддержка авторизации через LDAP/AD, расширеное логирование для внутреннего аудита, расширяются возможности алертинга и техподдержка вендора в рабочие часы. Именно подписка уровня Gold очень похожа на AWS OpenDistro.
Platinum. Наиболее популярный тип подписки. кроме возможностей уровня Gold, тут появляется встроенное в Elastic машинное обучение, кросс-кластерная репликация, поддержка клиентов ODBC/JDBC, возможность гранулярного управления доступом до уровня документов, поддержка вендора 24/7/365 и некоторые другие возможности. Ещё в рамках этой подписки они могут выпускать Emergency patches.
Enterprise. Самый выскоий уровень подписки. Кроме всех возможностей уровня Platinum, сюда входят оркестратор Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, решение по безопасности для конечных устройств Endgame (со всеми его возможностями), поддержка вендором неограниченного количества проектов на базе Elastic и другие возможности. Обычно используется в крупных и очень крупных инсталляциях.
У Elastic появилось уже немало форков, самый известный из которых – OpenDistro от AWS. Его ключевым преимуществом является поддержка некоторых возможностей оригинального Elastic, доступных на платных подписках. Основные – это интеграция с LDAP/AD (а еще SAML, Kerberos и другими), встроенный алертинг (на бесплатном Elastic это реализуется через Elast Alert), логирование действий пользователей и поддержка JDBC-драйверов.
Упомянем также про HELK и Logz.io. Первый – проект на Github, который обвешивает Elasticsearch дополнительным ПО для аналитики угроз (пишут, что пока это всё находится в альфе), а второй облачный сервис, основанный на Elastic и добавляющий некоторые приятные фичи. В комментариях можно поделиться другими форками, о которых вам известно.
Для получения дополнительной информации о сайзинге Elasticsearch, лицензировании и по другим вопросам, вы можете оставить заявку в форме обратной связи на сайте или другим удобным способом.
Elastic под замком: включаем опции безопасности кластера Elasticsearch для доступа изнутри и снаружи
Elastic Stack — известный инструмент на рынке SIEM-систем (вообще-то, не только их). Может собирать в себя много разнокалиберных данных, как чувствительных, так и не очень. Не совсем правильно, если доступ к самим элементам Elastic Stack не будет защищён. По умолчанию все коробочные элементы Elastic (Elasticsearch, Logstash, Kibana и коллекторы Beats) работают по открытым протоколам. А в самой Kibana отключена аутентификация. Все эти взаимодействия можно обезопасить и в этой статье мы расскажем как это сделать. Для удобства разделили повествование на 3 смысловых блока:
Ролевая модель доступа к данным
Если установить Elasticsearch и никак его тюнить — доступ ко всем индексам будет открыт для всех желающих. Ну, или тех, кто может пользоваться curl. Чтобы этого избежать, в Elasticsearch есть ролевая модель, которая доступна начиная с подписки уровня Basic (она бесплатна). Схематически выглядит примерно так:
В Elasticsearch по умолчанию есть коробочные пользователи, к которым привязаны коробочные роли. После включения настроек безопасности их можно сразу же начинать использовать.
Чтобы активировать безопасность в настройках Elasticsearch, нужно добавить в конфигурационный файл (по умолчанию это elasticsearch/config/elasticsearch.yml) новую строку:
После изменения файла конфигурации запускаем или перезапускаем Elasticsearch, чтобы изменения вступили в силу. Следующий шаг — присвоение паролей коробочным пользователям. Сделаем это интерактивно при помощи команды ниже:
Можно хлопнуть себя по плечу — настройки на стороне Elasticsearch выполнены. Теперь пришла очередь настроить Kibana. Если запустить её сейчас, посыплются ошибки, поэтому важно создать хранилище ключей. Делается, это в две команды (пользователь kibana и пароль, введённый на шаге создания паролей в Elasticsearch):
Если всё правильно — Kibana начнёт просить логин и пароль. В подписке уровня Basic доступна ролевая модель на основе внутренних пользователей. Начиная с Gold можно подключать внешние системы аутентификации — LDAP, PKI, Active Directory и системы Single sign-on.
Права доступа к объектам внутри Elasticsearch тоже можно ограничить. Правда, чтобы то же самое сделать для документов или полей, потребуется платная подписка (эта роскошь начинается с уровня Platinum). Эти настройки доступны в интерфейсе Kibana или через Security API. Можно проверить через уже знакомое меню Dev Tools:
Безопасность данных внутри кластера Elasticsearch
Когда Elasticsearch работает в кластере (а это обычное дело), важными становятся настройки безопасности внутри кластера. Для безопасного взаимодействия между нодами, Elasticsearch использует протокол TLS. Чтобы настроить безопасное взаимодействие между ними, нужен сертификат. Генерируем сертификат и приватный ключ в PEM-формате:
После выполнения команды выше, в директории /../elasticsearch появится архив elastic-stack-ca.zip. Внутри него обнаружатся сертификат и приватный ключ с раширениями crt и key соответственно. Их желательно выложить на shared ресурс, к которому должен быть доступ со всех нод кластера.
По итогам выполнения команды получим сертификат и приватный ключ в формате PKCS#12, защищённый паролем. Осталось переместить сгенерированный файл p12 в директорию с конфигурацией:
Добавим пароль к сертификату в формате p12 в keystore и truststore на каждой ноде:
В уже известный elasticsearch.yml осталось добавить строки с данными о сертификате:
Запускаем все ноды Elasticsearch и выполняем curl. Если всё было выполнено верно, вернётся ответ с несколькими нодами:
Есть ещё одна опция по безопасности — фильтрация IP-адресов (доступна в подписках от уровня Gold). Позволяет создавать белые списки IP-адресов, с которых разрешено обращаться к нодам.
Безопасность данных вне кластера Elasticsearch
Вне кластера означает подключение внешних инструментов: Kibana, Logstash, Beats или другие внешние клиенты.
Чтобы настроить поддержку https (вместо http), добавим в elasticsearch.yml новые строки:
Т.к. сертификат защищён паролем, добавим его в keystore и truststore на каждой ноде:
После добавления ключей, ноды Elasticsearch готовы к подключению по https. Теперь их можно запустить.
Следующий шаг — создание ключа для подключение Kibana и его добавление в конфигурацию. На основе сертификата, который уже размещён в shared директории, сгенерируем сертификат в PEM-формате (PKCS#12 Kibana, Logstash и Beats пока не поддерживают):
Осталось распаковать созданные ключи в папку с конфигурацией Kibana:
Ключи есть, значит осталось изменить конфигурацию Kibana, чтобы она начала их использовать. В конфигурационном файле kibana.yml меняем http на https и добавляем строки с настройками SSL-подключения. Последние три строки настраивают безопасное взаимодействие между браузером пользователя и Kibana.
Таким образом, настройки выполнены и доступ к данным в кластере Elasticsearch зашифрован.
Если у вас есть вопросы по возможностям Elastic Stack на бесплатных или платных подписках, задачи по мониторингу или созданию SIEM-системы оставьте запрос в форме обратной связи на нашем сайте. А ещё можно подписаться на наш Фейсбук.
Ещё наши статьи об Elastic Stack на Хабре:
Мы разработали обучающий курс по основам работы с Elastic Stack, который адаптируется под конкретные потребности заказчика. Подробная программа обучения по запросу.
ELK, SIEM из OpenSource, Open Distro: Интеграция с WAZUH
Продвигаемся дальше по нашему проекту. Мы завершили часть SIEM. Пришло время перевести наш проект из простого наблюдателя в активного ответчика. Одним из важных инструментов, которые мы использовали для этого, является Wazuh. В этой статье мы надеемся просветить вас о преимуществах, предлагаемых этим инструментом. А также расскажем как его установить и использовать.
Wazuh — это механизм обнаружения, просмотра и сравнения соответствия безопасности с открытым исходным кодом.
Он был создан как форк OSSEC HIDS, позже был интегрирован с Elastic Stack и OpenSCAP, которые превратились в более комплексное решение.
Wazuh помогает вам получить более глубокую видимость безопасности в вашей инфраструктуре, отслеживая хосты на операционной системе и уровне приложений.
Оглавление всех постов.
Статья разделена на следующие разделы:
Установка приложения и интеграция с kibana
Настройка и подключение агентов
1- Установка wazuh сервера и агента
Wazuh — это бесплатный сервис для корпоративного использования для мониторинга безопасности с открытым исходным кодом, предназначенный для обнаружения угроз, мониторинга целостности, реагирования на инциденты и соблюдения нормативных требований. Вот некоторые определения, которые вам нужно знать.
Сервер Wazuh: запускает менеджер Wazuh, API и Filebeat. Он собирает и анализирует данные от развернутых агентов.
Агент Wazuh: запускается на отслеживаемом хосте, собирает системный журнал и данные конфигурации и обнаруживает вторжения и аномалии. Он общается с сервером Wazuh, на который пересылает собранные данные для дальнейшего анализа.
1.1- Введение в архитектуру сервера Wazuh:
Архитектура Wazuh основана на агентах, работающих на контролируемых хостах, которые пересылают данные журнала на центральный сервер. Кроме того, поддерживаются безагентные устройства (такие как межсетевые экраны, коммутаторы, маршрутизаторы, точки доступа и т. Д.), Которые могут активно отправлять данные журнала через системный журнал и / или периодически проверять изменения своей конфигурации для последующей пересылки данных на центральный сервер. Центральный сервер декодирует и анализирует входящую информацию и передает результаты в кластер Elasticsearch для индексации и хранения.
Мы будем использовать архитектуру с одним хостом (Single-host architecture (HIDS)), которая имеет следующие характеристики:
Подробнее о другой архитектуре. Посетите официальный сайт:
1.2- Установка Wazuh manager, API и Filebeat
Здесь мы предоставим вам официальный сайт wazuh для установки
После установки нам нужно настроить файл конфигурации filebeat: вы можете подключить filebeat к выходу elasticsearch или выходу logstash. В нашем случае мы настроим вывод elasticsearch без проверки ssl (здесь мы видим, что включен только модуль предупреждений)
Теперь настроим шаблон индекса и запустим 3 службы:
1.3- Установка wazuh-агента
Используйте эту ссылку для установки
Проверьте, правильно ли работает wazuh-agent:
1.4- Установка приложения wazuh и интеграция с Kibana:
Это приложение станет мостом между сервером Wazuh и Kibana в ELK, который мы ранее установили.
Это приложение предоставляется только в репозитории Git Hub, а не на официальном веб-сайте.
Мы будем устанавливать приложение wazuh, совместимое с ELK Stack 7.6.1. Для этого.
Рекомендуется увеличить размер Kibana, чтобы обеспечить установку плагина:
Вы можете проверить все доступные версии на этом сайте:
Теперь в вашей кибане вы должны увидеть, что символ wazuh появился на левой вкладке вашей кибаны. Нажмите на него. Откроется wazuh api. Изучите его. У вас должно получиться нечто подобное. На данный момент у вас не будет никаких агентов, связанных с ним. В следующей части мы обсудим, как подключить ваших агентов.
1–5 Подключение и настройка агентов
Есть много способов зарегистрировать агента. В этой статье мы воспользуемся ручным способом.
В интерфейсе командной строки хоста Wazuh manager мы запустим manage_agents, чтобы добавить агента. В этом примере мы собираемся добавить нового агента. Для этого типа запустите следующую команду:
Выберите агента добавления, набрав A и нажав клавишу ВВОД. Затем мы вводим имя, которое хотим дать нашей машине, в данном случае user1. Мы вводим IP-адрес конечного устройства. Обратите внимание: если у вас нет статического IP-адреса для конечного устройства, вы можете использовать ключевое слово (любой) вместо IP-адреса. После этого нажмите Enter
Теперь мы собираемся извлечь секретный ключ, который позволит нашему агенту подключиться к серверу wazuh.
Для этого на этот раз мы выберем опцию E извлекать ключ для агента. Затем мы вводим идентификатор нашего агента, и в этом случае я выбрал агента с идентификатором 001.
После того, как вы добавили агент на хост менеджера Wazuh, откройте сеанс на хосте агента Linux как пользователь root. После этого импортируем ключ и подключим агента к менеджеру.
Вы должны получить такой результат, наберите «y» и нажмите Enter.
1.6- Проверка полученных данных:
Чтобы проверить, получает ли ELK данные от сервера wazuh. Перейдите в Управление индексами. Вы должны получить что-то похожее на это (wazuh-alert и wazuh-monitoring)
Активный ответ Wazuh:
Wazuh предоставляет модуль активного ответа для обработки автоматического ответа на определенные предупреждения, которые вы настраиваете в Wazuh-manager.
Активный ответ — это сценарий, который настроен на выполнение при срабатывании определенного предупреждения, уровня предупреждения или группы правил. Активные ответы — это ответы с сохранением состояния или без состояния. Ответы с сохранением состояния настроены для отмены действия по истечении заданного периода времени, в то время как ответы без состояния настроены как одноразовые действия.
Например, если мы хотим автоматически блокировать определенные IP-адреса на основе определенных журналов, поступающих с вашего конечного устройства, показывая, что они выполняют атаку Bruteforce, независимо от того, является ли это RDP или SSH, в зависимости от ОС хоста.
Мы можем создать активный ответ, который будет блокировать IP-адрес злоумышленника, если он соответствует поведению с набором правил, хранящимся в Wazuh. Мы возьмем пример SSH-Bruteforce. Мы будем рассматривать 8 неудачных попыток входа в систему как попытку атаки. Когда это событие происходит, действует правило «5712 — SSHD брутфорс пытается получить доступ к системе». Будет запущено. Таким образом, команда блокировки IP выполняется.
Во-первых, нам нужно определить команду, которую мы будем использовать для ответа.
OSSEC поставляется с набором общих скриптов, используемых в активном ответе. Эти сценарии находятся в / var / ossec / active-response / bin / на сервере. Мы собираемся использовать сценарий firewall-drop.sh, который должен работать с распространенными операционными системами Linux / Unix и позволяет блокировать вредоносный IP-адрес с помощью локального брандмауэра.
Определите команду в ossec.conf вашего OSSEC Manager:
Мы собираемся использовать скрипт firewall-drop.sh, который должен работать с распространенными операционными системами Linux / Unix и позволяет блокировать вредоносный IP-адрес с помощью локального брандмауэра.
Затем в том же файле мы настраиваем OSSEC для запуска активного ответа. Основные поля:
—command: ранее определенная команда (firewall-drop).
—location: Где команда должна быть выполнена. Мы хотим выполнить его для агента, сообщившего о событии. Итак, мы используем local.
—rules_id: команда выполняется, если срабатывает правило 5712.
—timeout: заблокировать IP на 60 секунд на брандмауэре (iptables, ipfilter и т. д.)
Затем сохраните модификацию и закройте файл. Перезапустите wazuh-manager командой:
Теперь на ваших хостах wazuh-agent не забудьте изменить файл ossec.conf и добавить:
Теперь вы можете попытаться подобрать SSH на вашем хост-компьютере, на котором установлен агент Wazuh, и вы будете заблокированы на 60 секунд после 8 неудачных попыток входа.
Чтобы узнать больше об активном респоне Wazuh, вы можете проверить:
ELK, SIEM из OpenSource, Open Distro: Оповещения (алерты)
Здравствуйте и добро пожаловать в нашу новую статью, в которой будет рассказано об оповещениях (алертах) в нашем решении SOCaaS. Как вы все знаете, предупреждения в любом SOC играют жизненно важную роль при уведомлении группы реагирования.
Они могут прервать цепочку кибер-атак или отслеживать эту атаку, в зависимости от политики предприятия и команды. Вы, наверное, задаетесь вопросом, зачем нам нужно включать больше предупреждений. Разве модулей предупреждений Open Distro недостаточно? Это потому, что ему не хватает количества выходов и его интегрируемости с остальной частью нашего решения, например Thehive. Мы познакомим вас с другой альтернативой.
Оглавление всех постов.
Статья разделена на следующие разделы:
* Установка и настройка ElastAlert, ElastAlert-Server и Praeco
1-Установка и настройка ElastAlert, ElastAlert-Server и Praeco:
1.1 Введение:
A- Определения
— Praeco: позволяет создавать оповещения с опциями уведомлений, включая Slack, электронную почту, Telegram, Jira.
Оповещения в Praeco могут быть собраны либо путем выбора полей, о которых нужно оповещать, и соответствующих операторов с помощью конструктора запросов, либо вручную с помощью языка запросов Kibana (KQL).
— ElastAlert — это простая структура для оповещения об аномалиях, всплесках или других интересных паттернах на основе данных в Elasticsearch. Он работает путем объединения Elasticsearch с двумя типами компонентов: типами правил и предупреждениями. Elasticsearch периодически опрашивается, и данные передаются в тип правила, который определяет, когда будет найдено совпадение. Когда происходит совпадение, передается одно или несколько предупреждений, которые принимают меры в зависимости от совпадения.
Это настраивается набором правил, каждое из которых определяет запрос, тип правила и набор предупреждений.
— Правила Sigma: Sigma — это общий и открытый формат подписи, который позволяет вам прямо описывать соответствующие события журнала. Формат правила очень гибкий, его легко написать и он применим к любому типу файла журнала. Основная цель этого проекта — предоставить структурированную форму, в которой исследователи или аналитики могут описать свои однажды разработанные методы обнаружения и сделать их доступными для других.
B- Клонирование проектов:
Вы можете найти дополнительную информацию по этому URL-адресу: https://github.com/ServerCentral/praeco
1.2-Настройка Elastalert:
Настройте elastalert config.yaml с помощью:
Ваш es_host: localhost
Уникальный writeback_index: elastalert_status
Измените папку rules_folder на rules
ПРИМЕЧАНИЕ. Если вы используете python 2.7, вам необходимо изменить его на 3.6.
A- Установка python3.6 в Ubuntu:
B-Обновление конфигурации Python:
C-Изменение Python по умолчанию:
И выберите python3.6
Теперь по умолчанию у вас должен быть python3.6
D-Install pip3:
E- Вам также необходимо установить PyYAML (пример 5.1):
F- Требования к установке и elastalert
G- Создание индекса:
Мы будем использовать по умолчанию ES_username: admin и ES_password: admin.
Также оставьте ответ по умолчанию для остальных вопросов.
1.3- Настройка сервера API:
Настройте сервер API /etc/elastalert-server/config/config.json с помощью:
A- Журналы предупреждений о неисправностях ( No Data ):
Обработчик метаданных, относящийся к индексу обратной записи журнала предупреждений, ищет документы с _type elastalert. Начиная с 7.x, это не возвращает результатов, потому что все документы имеют _type _doc.
Итак, вам необходимо:
удалите строку, содержащую тип: «elastalert»,
Теперь вы сможете просматривать журналы предупреждений в интерфейсе praeco.
B-Установите Elastalert-Server:
Вы должны увидеть эту строку, если она запустилась успешно. Это просто предупреждение из-за небезопасного соединения ( SSL_verify = False ).
1.4- Настройка Praeco:
A- Изменить файлы конфигурации:
B- Установите Praeco:
C- Скопируйте BaseRule.cfg:
Перед запуском сервисов необходимо:
Этот файл содержит настройки для Slack, SMTP и Telegram.
Здесь мы добавим URL-адрес Slack Webhook, используемый в Разделе 2.
добавьте URL-адрес Webhook
D- Запустите Praeco:
Теперь вы должны увидеть, что пользовательский интерфейс работает по адресу http://yourServerIP: 8080.
Вот ваш интерфейс Praeco
2- Создание правил:
2.1.- Создание правил с помощью интерфейса Praeco и отправка их в Slack webhook:
Теперь вы можете видеть, что создание правила очень похоже на Open Distro Alerting Tool, мы отфильтруем предупреждение и укажем место назначения.
Щелкните UNFILTERED и укажите фильтр вручную или с помощью инструмента предварительной сборки.
Затем нажмите Close
Мы будем использовать уведомления Slack с тем же URL-адресом веб-перехватчика, который используется в разделе 2, и тем же каналом (#test).
Ваше оповещение включено по умолчанию
Мы можем проверить, что оповещения были успешно отправлены в Slack.
В нашем слабом канале:
2.2- Отправка предупреждений из ElastAlert в TheHive
К сожалению, Praeco не обеспечивает вывод предупреждений в TheHive, поэтому мы будем редактировать наши правила вручную и отправлять их с помощью elastalert-server.
Благодаря этому обходному пути правила будут хорошо работать в фоновом режиме благодаря Elastalert-server, они также будут присутствовать в интерфейсе Praeco, но, к сожалению, мы не сможем редактировать или настраивать их с помощью интерфейса Praeco.
A- Создание правила: «User_creation»:
Во-первых, мы создадим наше правило из интерфейса Praceo, как и раньше, мы укажем любой URL-адрес в нашем выводе HTTP, потому что мы удалим его позже.
Когда закончите, нажмите Save.
B- Уведомления о доставке в Thehive:
Добавьте настройку TheHive, сохраните и перезапустите Elastalert-Server
Перейдите в /etc/elastalert/rules
C. Проверка предупреждений в Praeco
Наше оповещение было успешно отправлено в Hive
К сожалению, как мы упоминали ранее, правило не будет редактироваться с помощью интерфейса Praeco, вам придется отредактировать его вручную в /etc/elastalert/rules :
D- Проверка предупреждений в интерфейсе TheHive:
2.3- Получите помощь с инструментом Sigma для создания правил:
Как упоминалось ранее, инструмент Sigma помог нам преобразовать правила сигмы в несколько форматов, включая Elastalert.
A- Загрузить инструмент Sigma
B- Создайте свое оповещение с помощью инструмента сигма
Выполнить (пример правила) (это одна команда):
К сожалению, это правило не может напрямую использоваться (Praeco / Elastalert-Server) из-за отсутствия нескольких полей.
Таким образом, вы можете выбрать важную информацию из этого правила (строка запроса) и создать собственное правило в интерфейсе Praeco с этой информацией.
Этот инструмент очень важен, поскольку помогает собирать информацию о многих правилах и их строках запроса.
Примечание: Иногда вам нужно проверить свои журналы (Kibana → Discover Interface) и их поля, чтобы убедиться, что поля имен в ваших журналах совпадают с полями имен в правилах сигмы. Если в ваших полях отображается желтая ошибка, перейдите к шаблону индекса, выберите соответствующий индекс и нажмите кнопку «Обновить поля».
2.4- Отправка предупреждений Wazuh в theHive:
Мы будем использовать тот же обходной путь, упомянутый ранее, для предупреждений wazuh, сначала мы создадим предупреждения wazuh с помощью интерфейса praeco, затем мы вручную отредактируем файл правил, чтобы добавить вывод Hive:
A. Создайте правило wazuh и сохраните его:
Мы использовали для фильтрации правила с помощью rule.id (вы можете выбрать любое другое поле).
Вы можете получить идентификатор правил в wazuh → Overview → Security events.
B-Отредактируйте правило и перезапустите elastalert-server:
C- Проверка оповещений:
Спасибо за уделенное время. Мы надеемся, что вам понравилась эта статья и вы лучше поняли систему оповещений, используемую в нашем проекте. Увидимся в следующей статье.
