Seite wählen

NETWAYS Blog

OSMC 2023 | Experiments with OpenSearch and AI

Last year’s Open Source Monitoring Conference (OSMC) was a great experience. It was a pleasure to meet attendees from around the world and participate in interesting talks about the current and future state of the monitoring field.

Personally, this was my first time attending OSMC, and I was impressed by the organization, the diverse range of talks covering various aspects of monitoring, and the number of attendees that made this year’s event so special.

If you were unable to attend the congress, we are being covering some of the talks presented by the numerous specialists.
This blog post is dedicated to this year’s Gold Sponsor Eliatra and their wonderful speakers Leanne Lacey-Byrne and Jochen Kressin.

Could we enhance accessibility to technology by utilising large language models?

This question may arise when considering the implementation of artificial intelligence in a search engine such as OpenSearch, which handles large data structures and a complex operational middleware.

This idea can also be seen as the starting point for Eliatra’s experiments and their findings, which is the focus of this talk.

 

Working with OpenSearch Queries

OpenSearch deals with large amounts of data, so it is important to retrieve data efficiently and reproducibly.
To meet this need, OpenSearch provides a DSL which enables users to create advanced filters to define how data is retrieved.

In the global scheme of things, such queries can become very long and therefore increase the complexity of working with them.

What if there would be a way of generating such queries by just providing the data scheme to a LLM (large language model) and populate it with a precise description of what data to query? This would greatly reduce the amount of human workload and would definitely be less time-consuming.

 

Can ChatGPT be the Solution?

As a proof-of-concept, Leanne decided to test ChatGPT’s effectiveness in real-world scenarios, using ChatGPT’s LLM and Elasticsearch instead of OpenSearch because more information was available on the former during ChatGPT’s training.

The data used for the tests were the Kibana sample data sets.

Leanne’s approach was to give the LLM a general data mapping, similar to the one returned by the API provided by Elasticsearch, and then ask it a humanised question about which data it should return. Keeping that in mind, this proof of concept will be considered a success if the answers returned consist of valid search queries with a low failure rate.

 

Performance Analysis

Elasticsearch Queries generated by ChatGPT (Result Overview)

Source: slideshare.net (slide 14)

As we can see, the generated queries achieved only 33% overall correctness. And this level was only possible by feeding the LLM with a number of sample mappings and the queries that were manually generated for them.

Now, this accuracy could be further improved by providing more information about the mapping structures, and by submitting a large number of sample mappings and queries to the ChatGPT instance.
This would however result in much more effort in terms of compiling and providing the sample datasets, and would still have a high chance of failure for any submitted prompts that deviate from the trained sample data.

 

Vector Search: An Abstract Approach

Is there a better solution to this problem? Jochen presents another approach that falls under the category of semantic search.
Large language models can handle various inputs, and the type of input used can significantly impact the results produced by such a model.
With this in mind, we can transform our input information into vectors using transformers.
The transformers are trained LLM models that process specific types of input, for example video, audio, text, and so on.
They generate n-dimensional vectors that can be stored in a vector database.
Illustration about the usage of vector transformers

Source: slideshare.net (slide 20)

When searching a vector-based database, one frequently used algorithm for generating result sets is the ‚K-NN index‘
(k-nearest-neighbour index). This algorithm compares stored vectors for similarity and provides an approximation of their relevance to other vectors.
For instance, pictures of cats can be transformed into a vector database. The transformer translates the input into a numeric, vectorized format.
The vector database compares the transformed input to the stored vectors using the K-NN algorithm and returns the most fitting vectors for the input.

 

Are Vectors the Jack of all Trades?

There are some drawbacks to the aforementioned approach. Firstly, the quality of the output heavily depends on the suitability between the transformer and the inputs provided.
Additionally, this method requires significantly more processing power to perform these tasks, which in a dense and highly populated environment could be the bottleneck of such an approach.
It is also difficult to optimize and refine existing models when they only output abstract vectors and are represented as black boxes.
What if we could combine the benefits of both approaches, using lexical and vectorized search?

 

Retrieval Augmented Generation (RAG)

Retrieval Augmented Generation (RAG) was first mentioned in a 2020 paper by Meta. The paper explains how LLMs can be combined with external data sources to improve search results.
This overcomes the problem of stagnating/freezing models, in contrast to normal LLM approaches. Typically, models get pre-trained with a specific set of data.
However, the information provided by this training data can quickly become obsolete and there may be a need to use a model that also incorporates current developments, the latest technology and currently available information.
Augmented generation involves executing a prompt against an information database, which can be of any type (such as the vector database used in the examples above).
The result set is combined with contextual information, for example the latest data available on the Internet or some other external source, like a flight plan database.
This combined set could then be used as a prompt for another large language model, which would produce the final result against the initial prompt.
In conclusion, multiple LLMs could be joined together while using their own strengths and giving them access to current data sources and that could in turn generate more accurate and up to date answers for user prompts.
Overview of the RAG (Retrieval Augmented Generation)

Source: slideshare.net (slide 36)

Noé Costa
Noé Costa
Developer

Noé ist als Schweizer nach Deutschland ausgewandert und unterstützt das Icinga Team seit Oktober 2023 als Developer im Bereich der Webentwicklung. Er wirkt an der Weiterentwicklung der Webmodule von Icinga mit und ist sehr interessiert am Bereich des Monitorings und dessen Zukunft. Neben der Arbeit kocht er gerne, verbringt Zeit mit seiner Partnerin, erweitert sein Wissen in diversen Gebieten und spielt ab und an auch Computerspiele mit Bekanntschaften aus aller Welt.

Kritisch: Fehler in Elasticsearch mit JDK22 kann einen sofortigen Stop des Dienstes bewirken

Update

Seit gestern Abend steht das Release 8.13.2 mit dem BugFix zur Verfügung.

Kritischer Fehler

Der Elasticsearch Dienst kann ohne Vorankündigung stoppen. Diese liegt an einem Fehler mit JDK 22. In der Regel setzt man Elasticsearch mit der „Bundled“ Version ein. Diese ist JDK 22 in den aktuellen Versionen. Dies geht aus einem Mailing des Elasticsearch Support-Teams hervor. Das Team entschuldigt sich für den Fehler und es wird mit hochdruck an einem Fix gearbeitet. Auch wird beschrieben, dass es nur sporadisch Auftritt und nicht in der Masse.

Betroffene Versionen:

  • Elasticsearch version 7.17.19 , versions 8.13.0/8.13.1 – with JDK 22

Empfehlung:

Da hier ein Datenverlust entstehen kann, sollte gehandelt werden. Wenn es das Einsatzszenario zulässt.

Workaround:

  • Self-Managed on Premise:
    • Installiert einfach ein JDK Bundle in der Version 21.0.2 und Elasticsearch. Beispiel:
      • $ apt install openjdk-21-jdk-headless
      • Dann müsst ihr nach der Installation auf jeden Knoten einen Neustart des Dienstes durchführen. Denk dabei daran es als „Rolling Restart“ durchzuführen.
  • Für die ES Cloud gibt es keinen Workaround. Hier gibt es Updates zum Services Status: Elasticsearch Instance Disruption on Elasticsearch 8.13
  • Für ECE/ECK (Elastic Clound on Premise / Elastic Cloud Kubernetes): gibt es keinen Workaround

 

Allgemeine Lösung

Das Team von Elastic arbeitet auf hochtouren an einem Fix für das Thema.

Die aktuellen Stände hierzu könnt ihr hier verfolgen:

Lösung

Natürlich ist es immer noch valide ein Donwgrade durch den Einsatz von OpenJDK durchzuführen wie im „Workaround“ beschrieben. Empfehlenswerter ist es aber alle Elasticsearch-Nodes auf 8.13.2 zu aktualisieren. Da hier wie immer ein Neustart des Dienstes notwendig ist, vergesst nicht nach dem Schema des „Rolling Restart“ zu handeln.

Anmerkung der Redaktion

Hier ist ein handeln Empfohlen. Der Hersteller hat die Schwachstelle erkannt und öffentlich bekannt gegeben, begleitet von Handlungsempfehlungen zur Behebung. Wir haben dies festgestellt und möchten euch mit diesem Beitrag bei der Erkennung und der damit verbundenen Möglichkeit zum Handeln unterstützen. Wenn Ihr unsicher seit, wie ihr reagieren sollt und Unterstützung benötigt, wendet euch einfach an unser Sales-Team. Das Team von Professional Services unterstützt euch gerne.

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

Kibana Sicherheits-Updates: CVSS:Critical

Und täglich grüßt das Murmeltier. Nein nicht ganz. Heute ist es  aus der Elastic Stack Werkzeugkiste Kibana, für das es ein wichtiges Sicherheits-Update gibt. Es besteht auf jeden Fall Handlungsbedarf! IMHO auch wenn ihr die „Reporting“ Funktion deaktiviert habt.

Der Link zur Veröffentlichung: Kibana 8.12.1, 7.17.18 Security Update (ESA-2024-04)

Schweregrad: Severity: CVSSv3: 9.9(Critical)

Beschreibung

Die Verwundbarkeit ist ist auf eine Schwachstelle von Google Chrome aus Dezember 2023 zurückzuführen. Da Kibana für die Reporting Funktion eine eingebettete „Chromium headless Verison“ mit sich bringt, ist Kibana von dieser „Heap buffer overflow in WebRTC“ ebenfalls betroffen. Diese Schwachstelle ermöglicht es einem entfernten Angreifer, über eine manipulierte HTML-Seite einen „Heap-Velrust“ auszunutzen.

Dieser Effekt betrifft „on-premises“ Kibana installation auf Betriebsystemen die „Chromium Sandbox“ abgeschaltet haben. Diese sind CentOS, Debian, RHEL.

Es betrifft auch Instanzen welche mit dem Kibana Docker betrieben werden, wenn „Chromium Sandbox“ wie explizit empfohlen abgeschaltet ist. Jedoch gilt hier, dass eine „Container Escape“ nicht möglich ist, da es durch „seccomp-bpf“ unterbunden wird. Das gilt auch für Kibana Instanzen auf „Elastic Cloud„, für „Elastic Cloud Enterprise (ECE)„, wobei hier das weitere Vordringen zusätzlich zum „seccomp-bf “ mit „AppArmor profiles“ verhindert wird.

Für Kibana Instanzen welche auf „Elastic Cloud on Kubernetes“ laufen, ist um das weitere Vordingen (Container Escape) durch „seccomp-bf“ zu verhindern, dieses entsprechend in Kubernetes zu konfigurieren (wird seit V1.19 unterstützt).

Betroffene Versionen

  • Kibana bis 7.17.17
  • Kibana bis 8.12.0

Handlungsablauf zur Abhilfe

  • Dringend Update auf Version 8.12.1 oder Version 7.17.18
    • Dabei ist aber auch an die Elasticsearch Version zu denken
  • Sollte Kein UPDATE möglich sein, dann sollte die „Reporting“ Funktion dringend abgeschalten werden
    vi /etc/kibana/kibana.yml
    ...
    xpack.reporting.enabled: false

     

Anmerkung der Redaktion

Hier ist ein handeln Empfohlen. Der Hersteller hat die Schwachstelle erkannt und öffentlich bekannt gegeben, begleitet von Handlungsempfehlungen zur Behebung. Wir haben dies festgestellt und möchten euch mit diesem Beitrag bei der Erkennung und der damit verbundenen Möglichkeit zum Handeln unterstützen. Wenn Ihr unsicher seit, wie ihr reagieren sollt und Unterstützung benötigt, wendet euch einfach an unser Sales-Team. Das Team von Professional Services unterstützt euch gerne.

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

CVSS:Medium: Elastic Sicherheits-Updates gleich für drei Produkte

Gleich drei Sicherheits-Updates für drei verschiedene Produkte wurden von Elastic veröffentlicht. Alle drei haben den Schweregrad  Medium. Jedoch ist es Ratsam die Updates durchzuführen. Folgend eine kurze Zusammenfassung je Produkt.

Link: APM Server 8.12.1 Security Update (ESA-2024-03)

Solltet Ihr in Elasticsearch aktiv das Application performance Feature nutzen und einen eigenen lokalen APM Server betreiben, dann ist ein Update ratsam. Dies Betrift nur die selbst betriebene APM binary Server Varianten nicht die Elastic APM Integration des Agent.

Beschreibung

Der APM-Server schreibt bei Fehlermeldungen welche einen Indizierungsfehler (das schreiben von Dokumenten in den Index) betreffen, Teile des dazugehörigen Dokumentes mit in die lokale Log-Datei. Dies kann dazu führen das Schützens werte Informationen (z.B Entitäten z.B von Applikations-Nutzern) lokal lesbar in der Datei geschrieben sind.

Betroffene Versionen

  • APM Server <8.12.1

Abhilfe

  • Aktualisierung des lokal betriebenen APM-Server auf Version 8.12.1
  • Aufspüren von sensiblen Informationen in den Logs:
    • Beispiel unter Linux mit Standard Log-Einstellungen:
      grep -Hrn "Preview of field's value:" /var/log/apm
    • sollte es Treffer geben ist die Log-Datei am besten zu rotieren und danach zu löschen.

Link: Kibana 8.12.1 Security Update (ESA-2024-01)

Beschreibung

Solltet hier die Detection Search Engine nutzen und verfügt über eine Subskription die es euch ermöglicht die Document-level (DLS) oder Field-Level (FLS)= basierten Berechtigungen zu nutzen, dann solltet Ihr hier handeln. Denn Benutzer welche Berechtigt sind die Indices für Alarmierungen über die Kibana-Api zu nutzen (Webfrontentd) könnten bei der Abfrage der entsprechenden Indices „.alerts-security.alerts-{space_id} mehr angezeigt bekommen als diese sehen dürften. Grund ist das die Engine diese einfach ignoriert. Bedeutet wenn ein Benutzer mit Berechtigungen auf Basis von DLS und FLS diese API abfragt, bekommt er Zugriff auf Informationen die er nicht sehen sollte.

Betroffene Versionen

  • Kibana 8.x bis zu <8.12.1

Handlungsablauf zur Abhilfe

  • Aktualisierung auf Version 8.12.1
    • Vorsicht es empfiehlt sich immer Elasticsearch und Kibana auf gleicher Version zu halten. Somit kann hier auch ein Update von Elasticsearch anstehen, was mit einem Rolling Restart verbunden ist.

Link: Elastic Network Drive Connector 8.12.1 Security Update (ESA-2024-02)

Beschreibung

Der Elastic Network Drive Connector ist ein Werkzeug welches bei Verwendung der Enterprise Search zum Einsatz kommt (Subskription Funktion). Hier kann der Benutzer auf Dokumenten Ebene trotzdem Dokumente sehen, welche Ihm explizit zum lesen und schreiben nicht zugeordnet sind. Somit kann der Benutzer Dokumente, auf die er nicht zugreifen kann und sollte, trotzdem sehen.

Betroffene Versionen

  • Elastic Network Drive Connector  <8.12.1

Handlungsablauf zur Abhilfe

  • Aktualisierung auf Version 8.12.1

Anmerkung der Redaktion

Hier ist ein handeln Empfohlen. Der Hersteller hat die Schwachstelle erkannt und öffentlich bekannt gegeben, begleitet von Handlungsempfehlungen zur Behebung. Wir haben dies festgestellt und möchten euch mit diesem Beitrag bei der Erkennung und der damit verbundenen Möglichkeit zum Handeln unterstützen. Wenn Ihr unsicher seit, wie ihr reagieren sollt und Unterstützung benötigt, wendet euch einfach an unser Sales-Team. Das Team von Professional Services unterstützt euch gerne.

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.

Achtung Handlungsbedarf: Kibana schreibt sensitive Benutzerinformationen im Log mit

Kibana Insertion of Sensitive Information into Log File (ESA-2023-25)

Und erneut wurden in den Kibana-Logs in bestimmten Fehlerfällen sensible Informationen gefunden. Wir empfehlen dringend ein Update auf Kibana 8.11.1. In diesen Fällen werden Anmeldeinformationen des Benutzers „kibana_system“, API-Schlüssel und Anmeldedaten von Kibana-Endnutzern in das Log geschrieben.

Hier der Post zum CVE ESA-2023-25

Betroffene Versionen

Kibana nach 8.0.0 und vor 8.11.1

Nicht betroffene Versionen

Kibana Versionen 7.x.x

Schweregrad : 9,0 (Critical)

Handlungsablauf

Es besteht also bereits Handlungsbedarf. Im Folgenden wird ein möglicher Handlungsablauf beschrieben:

  • Aktualisierung von Kibana auf  8.11.11
  • Identifizieren ob ihr betroffen seit. Genau beschrieben hier
    • Beispiel für eigene Elastic Stack Instanz mit Stack Monitoring:
      message: ("headers" AND "x-elastic-product-origin" AND "authorization")

      gesucht mit Verwendung des Agents in „logs-kibana.*-default“ oder bei Verwendung des Filebeats „filebeat-{version}“

  • Beheben der Schwachstelle (Remediation Actions) . Beispiel eigene Instanz:
    • Rotation des Passwords für den User „kibana_system“ mittels API oder Passwort-Reset Tool
      bin/elasticsearch-reset-password -u kibana_systems
      curl -X POST "localhost:9200/_security/user/kibana_system/_password?pretty" -H 'Content-Type: application/json' -d'
      {
        "password" : "new_password"
      }
      '
      
    • Für alle Kibana-Endanwender  welche in den Logs gefunden wurden, könnt ihr die Kibana UI oder die Change passwords API wie oben beschrieben verwenden.

Für alle weiteren Varianten wie ECE, ECK und Elastic Cloud findet ihr alles genauer beschrieben unter den Punkten Identification and Remediation of credentials in logs und Remediation Actions

Hinweis

Es gilt auch hier ist eine Aktualisierung von Elasticsearch auf die Version 8.11.1 empfohlen. Bei jeder Aktualisierung gilt wie immer Release Notes lesen und „Breaking Changes“ beachten.

Anmerkung der Redaktion

Wo gehobelt wird , da fallen auch Spähne

Deshalb ist Handeln erforderlich. Der Hersteller hat die Schwachstelle erkannt und öffentlich bekannt gegeben, begleitet von Handlungsempfehlungen zur Behebung. Wir haben dies festgestellt und möchten euch mit diesem Beitrag bei der Erkennung und der damit verbundenen Möglichkeit zum Handeln unterstützen. Wenn Ihr unsicher seit, wie ihr reagieren sollt und Unterstützung benötigt, wendet euch einfach an unser Sales-Team. Das Team von Professional Services unterstützt euch gerne.

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner Leidenschaft für die Natur beim Biken und der Imkerei nach und kassiert dabei schon mal einen Stich.