Искать по:
Категория - проекты
Год
Отрасль
Страна
Город

Development and optimization of SIEM on the basis of Elastic Search

What is SIEM?

We offer development and optimization of the SIEM on the basis of the Elastic Stack.

SIEM (Security Information and Event Management) — combine two terms of scope: SIM (Security Information Management) — information security management and SEM (Security Event Management) — Management of security events.

SIEM systems are not designed and not able to prevent incidents of breach of information security.

SIEM technology provides the collection and analysis of real-time security events generated by network devices and applications, and then stored in databases, reporting, and analysis of behaviour based on previous observations. SIEM represented as software and/or hardware.

About Elastic Stack

Elastic Stack is represented by three independent Open Source products combined into one powerful solution for a wide range of applications for data storage and processing.

The complex consists of Elasticsearch, Logstash and Kibana. Logstash collects and processes data of the registered events. For data storage and retrieval meets Elasticsearch. Kibana to visualize the data, indexed by Logstash, using the web interface.

Compared with the traditional SIEM solution based on Elastic Stack, despite the need to adapt some features to the task of information security has a number of significant advantages. Consider some of them.

Centralized management of logs

Collection, aggregation and normalization of related logs from various security sources such as firewalls, DLP, IDS/IPS, anti-virus software, etc. Raising awareness events additional data such as geolocation and external threats, including the falsification of IP-addresses and domain names.

The full functionality of a traditional SIEM is often not implemented in full due to licensing restrictions on the software and/or the use of proprietary hardware. In turn, the Elastic Stack as OpenSource product similar problems (restrictions) is not experiencing and gives the user greater freedom of action.

Elastic Stack allows you to log any security-related data. This gives the opportunity to produce a more complete security analysis.

Traditional SIEM, generally use their own embedded or relational database that imposes restrictions on performance, the amount of processed data and the flexibility of their sample.

Search

Viewing previously recorded events with the aim of identifying potential threats to legal expertise and analysis of root causes of incidents held.

Thanks to the power of Elasticsearch, including full-text search solution on the basis of Elastic Stack available all data related to safety.

Flexibility and search performance of a traditional SIEM is limited by data storage technologies, purposes and logic of the developers of these products. Most of them can only index the data logs.

Basic analysis security

Detection of threats or facts of committing attacks on the basis of one or more sets of data using correlation rules In addition to finding established monitoring rules for a typical “negative” events and actions. The results are combined with advanced analysis.

Traditional SIEM often contain a large number of pre-configured “correlation rules” or “dashboards”.

Advanced security analysis

Includes detection of deviations (potential errors) by using machine learning such as:

rare events
the combination of atypical events that differ from previously registered patterns of behavior
events in which one of the components is not consistent with the other components
So as is the analysis of dependencies among the detected abnormalities, advanced analysis, and graphical representation of detected deviations, simulation of probable events.

Here, the majority of SIEM have a clear the backlog of Elastic Stack, while constantly working in this direction. Although, as the advantages typically have tools for assessing threats and risks.

Insitu’s offer

Having extensive experience in developing solutions based on Elastic Stack, and maximizing the benefits of this software product, we are ready to its base to offer You a solution as SIEM.
The modular structure of the solution gives the advantage to optimize the performance and cost of the solution. Advanced features Elastic Stack can and should be used for analysis and optimization of computing infrastructure in matters not directly related to information security.

Разработка и оптимизация систем SIEM на базе Elastic Search

Что такое система SIEM?

Мы предлагаем разработку и оптимизацию системы SIEM на базе Elastic Stack.

SIEM (Security Information and Event Management) — объединение двух терминов, обозначающих область применения ПО: SIM (Security Information Management) — управление информационной безопасностью и SEM (Security Event Management) — управление событиями безопасности.

SIEM-системы не предназначены и не способны предотвратить инциденты нарушения информационной безопасности.

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

Наиболее известны такие продукты как – Security QRadar SIEM от IBM, ArcSight от HP, NitroSecurity от McAfee.

Об Elastic Stack

Elastic Stack представлен тремя самостоятельными Open Source продуктами, объединенными в одно мощное решение для широкого спектра задач по хранению и  обработке данных.

Комплекс состоит из Elasticsearch, Logstash и Kibana. Logstash собирает и обрабатывает данные зарегистрированных событий. За хранение и поиск данных отвечает Elasticsearch. Kibana визуализирует данные, индексированные Logstash, через web-интерфейс.

По сравнению с традиционными SIEM решение на базе  Elastic Stack, несмотря на необходимость адаптации некоторого функционала к задачам ИБ,  имеет ряд существенных преимуществ. Рассмотрим некоторые из них.

Централизованное управление журналами регистрации событий

Cбор, агрегирование и нормализация связанных журналов регистрации безопасности из различных источников таких, как межсетевые экраны, DLP, IDS/IPS, антивирусное ПО и т.д. Повышение информативности событий дополнительными данными такими, как геолокация  и информация о внешних угрозах, включая фальсификацию IP-адресов и имен доменов.

Полный функционал традиционных SIEM часто не реализуется в полной мере из-за лицензионных ограничений на ПО и/или использование патентованных аппаратных средств. В свою очередь, Elastic Stack в качестве OpenSource продукта, подобных проблем (ограничений) не испытывает и дает пользователю большую свободу действий.

Elastic Stack позволяет протоколировать любые  относящиеся к безопасности данные. Это дает возможность произвести более полный анализ безопасности.

Традиционные SIEM, как правило, используют собственные встроенные или реляционные базы данных, что накладывает ограничения по производительности, объему обрабатываемых  данных и гибкости их выборки.

Поиск

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

Благодаря мощи Elasticsearch, включая полнотекстовый поиск, решению на базе Elastic Stack доступны запросы всех данных, относящихся к безопасности.

Гибкость и производительность поиска традиционных SIEM ограничены технологиями хранения данных, целями и логикой разработчиков этих продуктов. Большинство из них могут только индексировать данные журналов регистрации.

Базовый анализ безопасности

Обнаружение угроз или фактов совершения атак на основе одного или более наборов данных с использованием правил корреляции. Помимо поиска устанавливаются правила мониторинга для типичных «негативных» событий и действий. Результаты объединяются с возможностями расширенного анализа.

Традиционные SIEM часто содержат большое количество заранее  сконфигурированных «корреляционных правил» или  «информационных панелей».

В случае SIEM на базе Elastic Stack поставщик решения индивидуально конфигурирует правила и панели с учетом специфики задач и вычислительной инфраструктуры конкретного заказчика.

Расширенный анализ безопасности

Включает в себя обнаружение отклонений (потенциальных ошибок) при помощи машинного обучения таких, как:

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

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

Здесь большинство SIEM имеют явное отставание от Elastic Stack, хотя и постоянно работают в этом направлении. Хотя, в качестве преимущества, как правило, имеют инструменты оценки угроз и рисков.

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

Предложение Инситу

Имея большой опыт в разработке решений на базе Elastic Stack, и максимально используя преимущества этого программного продукта, мы готовы на его базе предложить Вам решение в качестве системы SIEM.

Модульная структура решения дает преимущества по оптимизации производительности и себестоимости решения. Дополнительно возможности Elastic Stack могут и должны использоваться для анализа и оптимизации вычислительной инфраструктуры в вопросах, не имеющих прямого отношения к информационной безопасности.

Оценка риска исчезновения биоразнообразия с помощью Elasticsearch

Награда Elastic Cause Awards

среди компаний, использующих Elastic Stack

Этот проект был включен в список на первую в этом году награду Elastic Cause Awards, которая признает организации, использующие Elastic Stack в своих професиональных целях для достижения успеха.

Национальный центр по сохранению растений (CNCFlora) является официальным подразделением Министерства окружающей среды Бразилии, которое находится в Ботаническом саду Рио-де-Жанейро. Он предназначен для реализации оценки риска бразильской флоры и координации усилий по сохранению.

О проекте

и его важности

В настоящее время Бразилия перечисляет 46 113 видов флоры, но даже с непрерывными и целенаправленными усилиями CNCFlora, начиная с 2010 года, только около 11% из них были оценены на предмет риска исчезновения.

Оценка риска исчезновения является первым шагом в сохранении вида и должна обеспечить научную и объективную оценку вероятности вымирания вида в одно время, если обстоятельства, в которых он находится, останутся.

Оценка риска исчезновения всех известных видов является глобальной проблемой, согласованной сторонами Конвенции о биологическом разнообразии (КБР) в рамках целевой задачи 2 Глобальной стратегии сохранения растений (ГССР).

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

Небольшая технологическая помощь

которые решают специалисты нашей компании

Оценка риска – методологический процесс, определенный Международным союзом охраны природы (МСОП) и принятый многими странами, такими как Бразилия. В этой методологии совокупность методов и информации о видах составления и анализа информации о возникновении потенциальных угроз для остального населения.

Часть этой методологии использует «записи о происшествиях», которые поступают главным образом из коллекций гербариев, сделанные образцами высушенных растений, установленных на листе картона, сопровождаемого ярлыком с названием вида и дополнительными данными, относящимися к этому образцу. Эти данные представляют собой наличие биологического образца во времени и пространстве, являясь основным источником данных для исследований по биоразнообразию и сохранению.

Таким образом, методология использует широту и долготу всех записей видов для расчета Области Занятости, расширения потока и субпопуляций.

Чтобы помочь процессу оценки риска исчезновения всей бразильской флоры, был разработан инструмент под названием «Экспресс-оценка рисков» – RRAPP, в котором эти пространственные и основанные на конкретных критериях исчисления, классифицируют риск исчезновения каждого вида бразильской флоры.

Индексирование с помощью Elasticsearch и Kibana

простой и эффективный инструмент

Из-за нехватки ресурсов для инфраструктуры и персонала очень важен простой и эффективный инструмент. Поэтому Elasticsearch стал лучшим выбором.

Таксономическая информация – название вида данных о происхождении пространственных данных и результатов анализа индексируемых в Elasticsearch. Сочетание запросов таксономии и различного вида вхождения генерирует данные оценки.

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

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

Общий результат анализа Кибаны во время работы

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

Другим важным моментом является то, что все это может выполняться ежедневно в ограниченной инфраструктуре: имеется единственный узел с 4 ядрами и 8 ГБ ОЗУ, в котором оба бота и Elastic stack индексируют и анализируют около 100 000 названий видов и 15 000 000 данных о событиях, предоставляя несколько агрегатов и отчетов.

Масштабирование будущего

объединение всех существующих данных

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

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

Представьте…

На минуту задумайтесь, если возможно спрогнозировать вымирание целого вида растений, получая данные из гербария, что можно сделать с реальными данными…

Можно построить модель по прогнозу потребления, продаж, количеству и качеству оплаты за услуги, планируемым объемам прибыли и многое другое. Получая подобного рода данные, принимаемые решения станут, как минимум, обоснованными точными данными.

Бесчисленное количество вариантов – нужно только понять, что все возможно.

Elasticsearch, Logstash and Kibana — a powerful solution for a wide range of tasks

Start. Proposed – ELK

powerful, flexible, fairly easy to handle tool for collecting, storing and visual data analysis

The starting point for the project was the treatment of the company address from the client, which is a major infrastructure provider. The client on the basis of the analysis of the data, representing logs, optimizes the capacity of hardware and software. Naturally I had to transfer this task to a higher level with increasing volume of information. In other words it took a powerful, flexible, fairly easy to handle tool for collecting, storing and visual data analysis. As such a tool we have developed a stack of software products under the name ELK.

ELK stands for Elasticsearch, Logstash and Kibana. It’s essentially three full-fledged independent software open source product, combined into one powerful solution for a wide range of tasks for processing data.

The objectives and performance requirements

To deploy a monitoring system for:

  1. capacity planning (finding bottlenecks hardware and software)
  2. retrospective monitoring of events from end user equipment

The system shall meet the following performance requirements:

  • Up to 1000 events/sec
  • The growth data up to 3GB/hour
  • Storage up to 90 days
  • Collecting 95% of events over a period of time up to 24 hours (displayed by default)
  • Collecting 95% of events with an interval of 5 min (display default)
  • Connection up to 10 clients HTTP
  • Fault tolerance 1 server in the cluster (replication 2)
  • On servers running ELK only (no third party apps)

Requirements for hardware and software systems:

  • 3 servers
  • OS – 7.2 CentOS / RHEL 7.2
  • 8 physical CPU cores on the server (or more according to physical cores without redistribution between the VM)
  • 48GB RAM on the server (without redistribution between RAM VM)
  • 8TB HDD to the server, providing, at least, the speed of random I / o-output 500 IOPS (70% read / 30% write)
  • At least 1Gb network connection between servers

Specification physical servers for deploying the system:

  • 2xE5-2630v4 10c (or E5-2660v4 14c for higher productivity)
  • 4x32GB RAM DDR4
  • 12G 2x300GB SAS 10K (RAID1)
  • 2xPSU

System deployment

On each server node takes place individual instances of Elasticsearch, Logstash and Kibana.

Further, the order of deployment will be considered on the same node.

All the details are applicable to other machines in the cluster.

PE

1. Stack of Elasticsearch, Logstash and Kibana (ELK) is set from one repository. Create a system description file of the repository:

2. Import Elasticsearch PGP Key:

3. Work for Elasticsearch and Logstash you need to download and install JDK 8.

Install Elasticsearch

1. Install Elasticsearch

2. Edit the Elasticsearch configuration:

In the section “Paths” define the path to the data directory and the logs to Elasticsearch:

To improve the stability of the site, excluding unloading of the JVM on a swap partition, raskomentiruyte line bootstrap.memory_lock true section of Memory.
In the section “Network” inserted row for CORS requests:

In the section “Various” optimize resource-intensive operations the following parameters (8 cores CPU):

3. Editable parameters JVM:

Set minimum and maximum JVM heap size parameters Xms and Xmx, respectively. In our case, these values are the same and equal to 32g:

To free unused memory selectable Garbage Collection. In our case we use G1GC. With this purpose in corresponding section changes:

4. Run and install the Elasticsearch startup at boot system:

5. Check the performance of Elasticsearch node using a simple request HTTP

Install Kibana

1. Install Kibana:

2. Edit the Kibana configuration:

Make possible the remote connection to the server Kibana:

URL for querying an instance of Elasticsearch:

Define file embed Kibana logs:

3. Run and install Kibana startup at boot system:

Installing Logstash

1. Install Logstash:

2. Edit configuration Logstash:

In the section “Pipeline Settings” define parameters:

based on the number of CPU cores on a node (8)

based on the number of Elasticsearch instances (3)

3. Edit configuration JVM:

Set minimum and maximum JVM heap size parameters Xms and Xmx, respectively. In our case, these values are the same and equal to 4g:

As for Elasticsearch from select G1GC Garbage Collection. With this purpose in corresponding section changes:

4. Create a config file:

In the input section, for our case, we prescribe the path to the directory containing the log files. In the output pane, specify the Elasticsearch cluster.

5. Run and install the Logstash startup at boot system:

Installed X-Pack as an extension to ELK

X-Pack is a PlugIns to Elasticsearch and Kibana. Includes modules, flexible distribution of access to resources (X-Pack Security), additional graphic information, notification, monitoring, reporting at the server level EK, gcd and indexes in Kibana. Setting up authentication as a native level and using LDAP and AD.

1. Installed X-Pack for Elasticsearch on each node:

2. To automatically generate indices of the X-Pack added the following line to elasticsearch.yml:

3. Restart Elasticsearch:

4. Install X-Pack for Kibana on each node:

5. Restart Kibana:

To disable modules, X-Pack, put the following lines in elasticsearch.yml:

in kibana.yml:

Restart Elasticsearch and Kibana.
To re-enable the commented line and restart the services.

Configure system for use in the cluster

Editable on each node of the configuration file Elasticsearch:

1. In the section “Network” uncomment the appropriate line and set the node address assigned to it in the cluster. For each node its value. For example:

2. In the section “ Cluster” raskomentiruyte the appropriate line and set the unique network name of the cluster. For example:

3. In the section “ Node” uncomment the relevant line prescribe and unique for our cluster the name node. For each node its value. For example:

4. In the section “ Discovery” raskomentiruyte the appropriate line and set ‘ the node, which should be detected in the cluster. For example:

In addition, to avoid splitting our cluster into two independent failure of the system, you must set the following parameters (in our case, 3 nodes):

5. Save changes of the configuration file. Restart Elasticsearch:

Check the cluster status:

Interacting with an Elasticsearch cluster

To interact with the Elasticsearch cluster using the app “elasticsearch-head”. In previous versions of Elasticsearch this application is installed as a plugin.
Starting with version 5.X developers recommend to use the X-Pack to replace the “es-head”. So here had to use “es-head” in the form of a separate web application.
To ensure the primitive web server written in golang.

Create a Dashboard in Kibana

Open the browser to the web interface Kibana (http://ip_addr_kibana:5601). Define the index name or pattern of names of several indexes (index-pattern*). Select the index field with the time stamp, which we will use to compare the time parameters. Clicking “Create”, add the indices. If the index is greater than one, you need to choose one by default. On the Discover page, we get interactive access to the documents of the selected indexes. If the selected index field with the time stamp, the document rendering is complemented by the histogram.
Next, create visualizations and include them in dashboards.
One index created dashboards, including 13 visualizations of various types, in accordance with the specification of the customer.
By means of the module “X-Pack Security” additionally created a role for a user with rights only for viewing (excluding viewing role and user).

In /etc/kibana/kibana.yml defined by the application running for all users after login to server Kibana, the relevant string:

kibana.defaultAppId: “dashboard/Dashboard_Name_Default”

Thank you!

Thank you for viewing this article.

If You have any questions-please email – will be happy to answer!

Elasticsearch, Logstash и Kibana – мощное решение для широкого спектра задач

Старт. Предложено ELK

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

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

ELK расшифровывается как Elasticsearch, Logstash и Kibana. Это по сути три полноценных самостоятельных программных open source продукта, объединенных в одно мощное решение для широкого спектра задач по обработке данных.

Задачи и требования по производительности

Развернуть систему мониторинга с целью:

  1. планирование мощностей (поиск узких мест аппаратного и программного обеспечения)
  2. ретроспективный мониторинг событий от конечного пользовательского оборудования

Система должна удовлетворять следующим требованиям по производительности:

  • До 1000 событий/сек
  • Прирост данных до 3GB/час
  • Хранение до 90 дней
  • Сбор 95% событий за период времени до 24 часов (отображение на экране по умолчанию)
  • Сбор 95% событий с интервалом до 5 мин (отображение на экране по умолчанию)
  • Подключение до 10 клиентов по протоколу HTTP
  • Отказоустойчивость 1 сервера в кластере (2 репликации)
  • На серверах запущены только ELK (отсутствие сторонних приложений)

Требования к аппаратному и программному обеспечению системы:

  • 3 сервера
  • ОС – CentOS 7.2 / RHEL 7.2
  • 8 физических ядер CPU на сервер, (или больше в соответствии физическим ядрам без перераспределения между VM)
  • 48GB RAM на сервер, (без перераспределения RAM между VM)
  • 8TB HDD на сервер, обеспечивающий, по крайней мере, скорость случайных операций ввода-вывода 500 IOPS (70% чтение / 30% запись)
  • Как минимум 1Gb сетевые подключения между серверами

Спецификация физических серверов для развертывания системы:

  • 2xE5-2630v4 10c (или E5-2660v4 14c для более высокой производительности)
  • 4x32GB DDR4 RAM
  • 2x300GB 12G SAS 10K (RAID1)
  • 2xPSU

Развертывание системы

На каждом серверной ноде разворачиваются отдельные экземпляры Elasticsearch, Logstash и Kibana.

Далее порядок развертывания ПО будет рассматриваться на одной ноде.

Все детали применимы к остальным машинам кластера.

Предустановки

1. Стек ПО Elasticsearch, Logstash и Kibana (ELK) устанавливается из одного репозитория. Создадим в системе файл описания репозитория:

2. Импортируем Elasticsearch PGP Key:

3. Для работы Elasticsearch и Logstash необходимо скачать и установить JDK 8.

Установка Elasticsearch

1. Устанавливаем Elasticsearch:

2. Редактируем конфигурацию Elasticsearch:

В секции “Paths” определяем пути к каталогам данных и логов для Elasticsearch:

Для повышения стабильности работы узла, исключив выгрузку JVM на swap раздел, раскоментируем строку bootstrap.memory_lock true секции Memory.
В секции “Network” добавляем строки для CORS-запросов:

В секции “Various” оптимизируем ресурсоемкие операции следующими параметрами (для 8 ядер CPU):

3. Редактируем параметры JVM:

Устанавливаем минимальное и максимальное значение JVM heap size параметрами Xms и Xmx соответственно. В нашем случае эти значения одинаковы и равны 32g:

Для освобождения неиспользуемой памяти выбираем Garbage Collection. В нашем случае используется G1GC. С этой целью в соответствующей секции сделаны изменения:

4. Запускаем и устанавливаем автозапуск Elasticsearch при загрузке системы:

5. Проверяем работоспособность ноды Elasticsearch через простой запрос по HTTP

Установка Kibana

1. Устанавливаем Kibana:

2. Редактируем конфигурацию Kibana:

Делаем возможным удаленное подключение к серверу Kibana:

URL для запросов к экземпляру Elasticsearch:

Определим файл размещения логов Kibana:

3. Запускаем и устанавливаем автозапуск Kibana при загрузке системы:

Установка Logstash

1. Устанавливаем Logstash:

2. Редактируем конфигурацию Logstash:

В секции “Pipeline Settings” определяем параметры:

исходя из количества ядер CPU на узле (8)

исходя из количества экземпляров Elasticsearch (3)

3. Редактируем параметры JVM:

Устанавливаем минимальное и максимальное значение JVM heap size параметрами Xms и Xmx соответственно. В нашем случае эти значения одинаковы и равны 4g:

Как и для Elasticsearch из Garbage Collection выбираем G1GC. С этой целью в соответствующей секции сделаны изменения:

4. Создаем конфигурационный файл:

В секции input, для нашего случая, прописываем путь к каталогу с лог-файлами. В секции output указываем кластер Elasticsearch.

5. Запускаем и устанавливаем автозапуск Logstash при загрузке системы:

Устанавливаем X-Pack в качестве расширения ELK

X-Pack представляет собой PlugIns к Elasticsearch и Kibana. Включает в себя модули гибкого разделения доступа к ресурсам (X-Pack Security), дополнительную графическую информацию уведомления, мониторинга, отчетности на уровне серверов EK, нод и индексов в Kibana. Настройка аутентификации как нативного уровня, т. и с использованием LDAP и AD.

1. Устанавливаем X-Pack для Elasticsearch на каждой ноде:

2. Для автоматического создания индексов X-Pack добавляем следующую строку в elasticsearch.yml:

3. Перезагружаем Elasticsearch:

4. Устанавливаем X-Pack для Kibana на каждой ноде:

5. Перезагружаем Kibana:

Для отключения модулей X-Pack помещаем следующие строки в elasticsearch.yml:

в kibana.yml:

Перезагружаем Elasticsearch и Kibana.
Чтобы снова включить, комментируем строки и перезагружаем сервисы.

Конфигурируем систему для работы в кластере

Редактируем на каждой ноде конфигурационный файл Elasticsearch:

1. В секции “Network” раскоментируем соответствующую строку и пропишем адрес ноды, назначенный для нее в кластере. Для каждой ноды свое значение. Например:

2. В секции “ Cluster” раскоментируем соответствующую строку и пропишем уникальное для нашей сети имя кластера. Например:

3. В секции “ Node” раскоментируем соответствующую строку и пропишем уникальное для нашего кластера имя ноды. Для каждой ноды свое значение. Например:

4. В секции “ Discovery” раскоментируем соответствующую строку и пропишем адреса нод, которые должны обнаруживаться в кластере. Например:

Кроме того, чтобы избежать разбиение нашего кластера на два независимых при сбое системы, необходимо установить следующие параметры (для нашего случая 3 ноды):

5. Сохраняем изменения конфигурационного файла. Перезагружаем Elasticsearch:

Проверяем состояние кластера:

Интерактивное взаимодействие с кластером Elasticsearch

Для интерактивного взаимодействия с кластером Elasticsearch используем приложение “elasticsearch-head”. В предыдущих версиях Elasticsearch это приложение устанавливалось как плагин.
Начиная с версии 5.X разработчики рекомендуют использовать X-Pack для замены «es-head». Поэтому здесь пришлось использовать «es-head» в виде отдельного веб-приложения.
Для обеспечения его работы используется примитивный веб-сервер, написанный на golang.

Создание Dashboard в Kibana

Открываем в браузере вэб-интерфейс Kibana (http://ip_addr_kibana:5601). Определяем имя индекса или шаблон имен нескольких индексов (index-pattern-*). Выбираем поле индекса с временной меткой, которую мы будем использовать для сравнения временных параметров. Нажав “Create”, добавляем индексы. Если индексов больше одного, необходимо один выбрать по умолчанию. На странице Discover мы получаем интерактивный доступ к документам выбранных индексов. Если выбрано поле индекса с временной меткой, визуализация документов дополняется гистограммой.
Далее создаем визуализации и включаем их в дашборд.
Для одного индекса создан дашборд, включающая в себя 13 визуализаций различного типа, в соответствии со спецификацией заказчика.
Средствами модуля “X-Pack Security” дополнительно создана роль для пользователя с правами только для просмотра (исключая просмотр ролей и пользователей).

В /etc/kibana/kibana.yml определяем приложение, запускаемое для всех пользователей после авторизации на сервере Kibana, соответствующей строкой:

Спасибо!

Благодарим за просмотр данной статьи.

Если у Вас возникли какие-либо вопросы – пишите – будем рады ответить!

Использование Logstash для создания маппинг-шаблона Elasticsearch

Вы сконфигурировали Logstash для анализа ваших данных

и отправки их в Elasticsearch

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

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

Что такое mapping?

Проще говоря, маппинг определяет, как поля интерпретируются Elasticsearch.

Elasticsearch является мощным средством, т.к. Вы можете отправлять в него данные, и он будет строить предположения относительно того, что должно отображаться в каждом поле. Мы называем это индексированием «без схемы», что является отличным вариантом, если вы только начинаете работать с Elasticsearch. Это также удобно в случаях, когда Вы постоянно отправляете новые данные, и не знаете, какие поля будут в нем.

Как упоминалось, есть большие преимущества в том, что данные собираются Elasticsearch, и «картирование»  сообщает Elasticsearch, как именно обрабатывать эти данные. Например, если Вы отправляете IP-адрес (например, 8.8.8.8, который является одним из DNS-серверов Google), он будет отображаться как поле строки в JSON, отправленном в Elasticsearch:

Несмотря на то, что IP-адрес является для нас IP-адресом, Elasticsearch будет рассматривать его как строку. Чтобы задавать больше значений, вы должны задать Elasticsearch, как относиться к величинам. Делается это с помощью функции сопоставления. Если IP-адрес отображается как тип ip в Elasticsearch, вы можете выполнить запрос и выполнить фильтрацию по диапазону IP-адресов – вы даже можете использовать нотацию CIDR – для включения только IP-адресов в пределах данной подсети.

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

ПРИМЕЧАНИЕ. Для целей этого упражнения мы будем использовать версии 5.3.0 Logstash и Elasticsearch. Если вы используете более старую версию Elasticsearch, особенно версию 2.x, ваше картирование, вероятно, будет сильно отличаться от нашего.

Получение Logstash для отправки данных образца Elasticsearch

Тут представлен  пример с данными журнала доступа Apache.

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

Самое приятное то, что мы можем сделать это на своем ноутбуке: не нужно запускать это на производственном узле или даже промежуточном – можно раскрутить локальный экземпляр Elasticsearch и Logstash и получить результаты, которые мне нужны.

Давайте отправим несколько строк:

И выход в узле Elasticsearch будет выглядеть примерно так:

Получение и редактирование результатов картирования

У нас есть индекс, давайте посмотрим, как выглядит наше картирование:

Теперь, если Вы отредактируете my_mapping.json в вашем любимом текстовом редакторе, вы увидите что-то вроде этого:

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

Конечно, my_index – это имя индекса, которое мы указали, а отображения указывает на следующие картирование для индекса. Mytype – это document_type, который мы указали в плагине вывода elasticsearch, а properties – там, где будут определены все поля.

Как Вы можете видеть, почти каждое поле имеет тип text и содержит вторичный тип подполя ключевого слова. Тип ключевого слова важен, потому что он обрабатывает все содержимое поля (вплоть до количества символов ignore_above) в качестве единого объекта. Это гарантирует, что поле пользовательского агента, содержащее имена операционной системы, такие как «Windows 10», идентифицируется Elasticsearch как «Windows 10», а не «Windows» и «10» разделены.

Как насчет некоторых других областей? Взгляните на вложенные поля в разделе geoip:

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

Внутри объекта geoip есть несколько числовых полей и поле IP:

На этом этапе я хочу сделать несколько важных замечаний о Logstash и grok, а также их отношении к картированию Elasticsearch. Независимо от того, как вы можете транслировать поле с помощью grok (поддерживающего типы int и float), Elasticsearch не будет точно знать, что вы намереваетесь, если не нанесете его точно. Logstash отобразит вашу строку журнала как JSON, содержащую все поля, которые вы сконфигурировали. Как правило, это будет содержать строки и цифры. Числа будут целыми числами (целые числа) или значениями с плавающей запятой (числа с десятичными знаками). После этого Elalesearch может интерпретировать эти типы полей либо путем их явного сопоставления, либо с помощью ранее упомянутого подхода без схемы.

Мы уже видели, насколько хорошо Elasticsearch обрабатывает строки и текстовые значения при использовании подхода без схемы. Он также лучше всего подходит к числовым значениям. Как правило, любое целое значение будет отображаться как длинное. Значения с десятичными знаками будут отображаться как число floats или double. Как уже упоминалось, вы можете сэкономить пространство памяти, а также некоторые накладные расходы для вычислений и агрегаций, если вы сопоставляете свои значения с минимально возможным примитивным значением. Это одно из основных преимуществ создания пользовательского картирования. Например, широта и долгота могут быть легко представлены half_floats, а dma_code может быть представлен как short. Каждое из этих изменений сокращает накладные расходы в Elasticsearch.

А как насчет нашего IP-адреса с самого начала?

Это поле ip идентифицируется как текст и ключевое слово, а не как IP. Чтобы сопоставить IP-поле как тип ip, замените этот целый блок следующим:

Довольно просто, правда? На этом этапе вы можете удивиться, почему я демонстрирую только отображение поля ip в объекте geoip, а не в поле clientip или в обоих. Это связано с тем, что в некоторых конфигурациях веб-сервера данные журнала, которые становятся полем клиента, могут содержать адрес IPv4, адрес IPv6 или имя узла. Если вы должны были сопоставить поле clientip как тип ip, а строка журнала с именем хоста должны были быть нажаты на Elasticsearch, это привело бы к ошибке, и этот документ бы не индексировался из-за конфликта отображения.

Поле местоположения также является специальным типом отображения. Это массив долготы и широты, обозначающий одну точку на карте. Elasticsearch хранит их как тип отображения geo_point, который позволяет пользователям выполнять географические поиски и отображать точки на картах в Кибане. Сопоставьте географическую точку следующим образом:

Со всеми этими изменениями отредактированное картирование для этого раздела должно выглядеть следующим образом:

Поле ответа, которое находится вне блока geoip, также является числом, но оно было сохранено в виде строки. Это связано с тем, что подшаблон grok, создавший это поле, не передает его как int или float. Впрочем, это неважно! Картирование могут принуждать число, хранящееся в виде строки, в числовой тип сопоставления. Поскольку коды ответа HTTP будут иметь только 3 цифры, а наименьший тип сопоставления – short, это должно выглядеть так:

Создание шаблонов

Итак, теперь у нас есть большой картированный файл с несколькими изменениями. Как изменить этот файл картирования в шаблон?

На самом деле довольно просто превратить обычное картирование в шаблон картирования! Это пример того, как может выглядеть шаблон картирования, в том числе, куда поместить отредактированный раздел свойств:

Шаблон elasticsearch в самом базовом представлении содержит шаблон индекса, который должен совпадать, идентифицироваться как шаблон картирования по умолчанию. В этом примере я включил версию, если вы хотите отслеживать изменения в шаблоне, и значение refresh_interval по умолчанию, равное 5 секундам, что помогает повысить производительность при более высоких нагрузках индексирования.

Чтобы сделать это полным шаблоном, вам необходимо заменить несколько строк из файла my_mapping.json. Скопируйте этот файл в файл my_template.json и откройте его в своем редакторе. Затем замените 4 верхние строки, которые должны выглядеть следующим образом:

С помощью этих строк:

Каждая следующая строка должна быть:

ВАЖНО: Мы удалили 4 фигурные скобки и заменили их на 3. Это означает, что у нас есть слишком много закрывающих фигурных скобок в конце нашего файла, поэтому прокрутите вниз и удалите один из них.

Вот так:

Сохранение шаблонов и их загрузка

Сохраните файл, и вы сможете его загрузить:

Если ваше картирование является точным, вы увидите:

Проверка шаблонов

Итак, теперь самое время протестировать наш шаблон. Удалите my_index из Elasticsearch, запустив первую строку в консоли Kibana:

Или эту строку в командной строке:

Повторно запустите команду образца Logstash, которую Вы запускали ранее, чтобы протестировать свой шаблон. Когда Вы проверите отображение my_index, Вы увидите все свои изменения!

Новый релиз Elastic Stack 5.3.0

Скажите “Привет!” новой версии Эластик

Новый релиз как всегда затронул практически все характеристики и весь функционал Elastic Stack. Обновленная версия уже сейчас доступна в Elastic Cloud.

Сразу о бонусе от Elastic: теперь система поддерживает шифрование при хранении с помощью dm-crypt! Ключевые факторы при выборе этого способа шифрования были: производительность, стабильность и надежность.

… теперь вернемся к обсуждению релиза 5.3.0.

Elasticsearch 5.3.0

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

– Как выполнить поиск одновременно по нескольким кластерам?

– Теперь можно использовать кросс-кластерный (перекрестный) поиск.

 

– Необходимо выполнить запрос с группировкой?

– Отлично, теперь есть функция сворачивания поля (collapsing).

 

– Было неудобно пользоваться маркерами?

– В новой версии продукта появился уникальный маркер, который может управлять группировкой других маркеров.

Kibana 5.3.0

В данном релизе Вас ждет 20 усовершенствований и 13 исправленных ошибок. Но это не самое главное – важно, что “под капотом” новая Кибана имеет неисчислимое количество улучшений!

Некоторые из улучшений:

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

– Был улучшен Timepicker – теперь навигация по отчетам стала еще удобнее!

– Добавлена полноэкранная визуализация на панель инструментов слева.

– Для повышения безопасности добавлена возможность использования SSL-сертификатов, которые защищены паролем.
– Собственные модальные подтверждения были заменены более гибкими и эстетически настраиваемыми пользовательскими модальными окнами.
– Уменьшено количество кликов, необходимых для добавления визуализации в панель инструментов.
– Повышена производительность на панели управления, уменьшилось количество HTTP-запросов и кешированы некоторые результаты.
– Доработано выделение с помощью highlight_query с включенными all_fields.
– Шаблон индекса по умолчанию теперь легко настраивается в расширенных настройках.
– Установка плагина оффлайн в Windows теперь корректно поддерживает 3 слэша.
– Щелчок по полям с периодами в данных больше не вызывает ошибку.
– Теперь неизвестные типы при импорте сохраненных объектов обрабатываются более корректно.
– Добавлен показатель “0” (ноль) для минимальной протяженности оси Y.
– и многое другое…

Logstash 5.3.0

– Добавлено несколько очень важных улучшений в функцию постоянной очереди (Persistent Queues):

– – каждая pipeline теперь имеет свою очередь;

– – добавлен автоматический процесс восстановления при запуске Logstash;

– – добавлен эксклюзивный доступ к постоянной очереди, находящейся на диске;

– – добавлена возможность безопасной перезагрузки pipeline без повреждения данных.

– X-Pack для мониторинга также радует – добавлена масса новых графиков и исправлены некоторые мелкие ошибки. Новые диаграммы и графики находятся в разделе “Дополнительно”.

– Добавлена масса новых плагинов.

Beats 5.3.0

Обновлены многие модули с целью повышения эргономичности использования продукта обычными пользователями.

ES-Hadoop 5.3.0

В новую версию была добавлена ​​поддержка Unicode для имен индексов и типов, а также поддержка пользовательского HTTP-заголовка.

2017

The conclusion of new partnership agreements with foreign companies, development companies in Russia and the former Soviet Union.

Cisco works with Insitu

VmWare