Seite wählen

NETWAYS Blog

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.

Graylog Release Version 5.2 ist da! HURRA!

Diese Woche wurde Graylog 5.2 veröffentlicht. Natürlich gibt es auch in diesem Release wieder Abstufungen für Open, Operations und Security.

Da wir nicht auf alles eingehen können, möchte ich hier auf die hervorzuhebenden Neuerungen und Änderungen eingehen. Ein vollständiges Changelog zum Release findet sich hier. Im Folgenden wollen wir auf zwei bemerkenswerte neue Features bzw. Änderungen im Detail eingehen.

HOT New Feature in Graylog OPEN/OPERATIONS/SECURITY: Pipeline Rule Builder UI

Der neue Pipeline Rule Builder UI ist wohl die auffälligste Neuerung und daher möchte ich darauf näher eingehen.

Das neue Pipeline Rule UI ist für all diejenigen hilfreich, die sich mit dem Schreiben von Pipeline Rule Code nicht auskennen oder sich noch nicht mit Pipeline Processing beschäftigt haben und daher Extraktoren am Input verwendet haben. Das neue UI (UserInterface) bringt hier eine ähnliche Handhabung wie bei den Extractoren. Die Extraktoren sind schon lange auf dem Weg aus dem Graylog heraus und sind und waren nie ein Weg für dynamische Verarbeitung.

Da dieses Menü bisher noch keine Erklärung gefunden hat, habe ich ein kurzes Video dazu gemacht. Vielleicht hilft das ja dem ein oder anderen von euch dies als Dokumentation zum verstehen.

Ausgangslage für das Video:

  • TCP RAW Input auf Port 5114 mit statischem Feld „demo“ und dem Wert true
  • rsyslog Daemon der im JSON Format sendet
  • Pipeline und Stream für die Daten vorkonfiguriert.

 

Breaking Change in Graylog Security: lluminate Bundle

Dies sollte beachtet werden:

Die Verarbeitung von IP-Adressen zu Geo-IP-Informationen wurde aus dem Illuminate Bundle entfernt und benötigt nun den globalen „Geoip Resolver Processor“. Daher muss dieser aktiviert werden und dem „Illuminate Processor“ folgen. Dabei braucht ihr keine Angst haben, dass jetzt mehr Ressourcen verbraucht werden. Mittlerweile kann der Processor unterscheiden zwischen reserved und public IP. Zu dem könnt ihr ein „Enforce default Graylog schema“ aktivieren, dies sorgt dafür das nur Felder aufgelöst werden welche dem GIM entsprechen. Das sind folgende Felder:

  • destination_ip
  • destination_nat_ip
  • event_observer_ip
  • host_ip
  • network_forwarded_ip
  • source_ip
  • source_nat_ip

Bedeutet aber auch das ihr diese Felder selbst auch bei anderen Applikation welche nicht im ILLUMINATE vorhanden sind entsprechend erzeugen müsst.

Wenn „Enforce default Graylog schema“ nicht aktiviert ist wird jedes Feld mit einer nicht reservierten IP-Addresse übersetzt.

Hierzu folgend die Einstellung für die Processor-Plugins welche notwendig sind:

Processor Configuration

Graylog Processor configuration order and activation

Dazu muss dann entsprechend auch der Geo-IP Processor konfiguriert sein und die entsprechenden Informationsdatenbanken zum Beispiel von Maxmind auf allen Servern abgelegt sein.

Geo-Location Processor Configuration in graylog

Alle weiteren Neuerungen und Änderungen in Graylog ILLUMINATE findet ihr hier.

 

Wir wünschen euch viel Spaß beim aktualisieren und Arbeiten mit den Neuerungen. Wenn ihr nicht weiter weißt oder Hilfe beim aktualisieren benötigt wir von NETWAYS Professional Services helfen euch gerne dabei. Meldet euch einfach bei unseren Sales TEAM!

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 Security Issue – Update für v8.10.0 erforderlich

Aktuelle Sicherheitslücke in Kibana Version 8.10.0

In der Nacht erreichte uns eine E-Mail von Elastic über eine Sicherheitslücke im Logging von Kibana (ESA-2023-17)  in Version 8.10.0. Im Log werden vertrauliche Informationen wie zum Beispiel Benutzernamen und Passwörter bei Authentifizierung sowie Cookies und Header im Klartext in die Kibana Log-Datei geschrieben. Es wurde bereits eine neue Version 8.10.1 veröffentlicht und 8.10.0 aus den Repositories gelöscht.

Aber was bedeutet das für euch?

EC (Elastic Cloud)

Elastic hat hier bereits alle Kundensysteme auf Version 8.10.1 aktualisiert. Trotzdem ist es notwendig die empfohlenen Handlungen wie in der Veröffentlichung von Elastic beschrieben durchzuführen. Ebenso wurden die Logs rotiert und gelöscht.

  • Internal Credentials rotiert und neu erstellt
  • End User Passwörter neu vergeben im Kibana

Self-Managed

Hier seid ihr gefragt. Es reicht nicht nur ein Update auf Version 8.10.1 durchzuführen, sondern es sind noch weitere Schritte erforderlich:

  • Logs kontrollieren, gegebenenfalls löschen (default: „/var/log/kibana/kibana.log„)
  • kibana_systems native user Passwort ändern (Zur Anleitung)
  • API-Tokens, sofern verwendet, aktualisieren (Zur Anleitung)
  • End User Passwörter im Kibana sowie für APIs neu vergeben

Handlungsbedarf besteht!

Wenn Ihr Kibana Version 8.10.0 verwendet, dann besteht dringender Handlungsbedarf. Wenn ihr euch nicht sicher seid wie Ihr Vorgehen sollt und Unterstützung benötigt, dann meldet euch direkt bei uns. Wir von NETWAYS helfen euch beim Update und der Analyse der bestehenden Logs.

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.

Datensicherheit mit OpenSearch Machine Learning

This entry is part 5 of 5 in the series OpenSearch Security

OpenSearch bringt von Haus aus die Möglichkeit mit, Machine Learning zu nutzen und hierfür pre-trained aber auch untrained Modelle zu nutzen. Den Status deiner Modelle kannst du bequem in OpenSearch Dashboards sehen.

Wie du OpenSearch Machine Learning zum Laufen bringst, zeige ich dir in diesem Blogbeitrag. Wie bei vielen neuen und sich schnell weiterentwickelnden Projekten kann es jedoch sein, dass bis zum Release dieses Blogposts der ganze Prozess noch einmal einfacher geworden ist.

Der Prozess, um OpenSearch für Machine Learning vorzubereiten, besteht aus diesen Bausteinen:

  • Vorbereitung
  • Upload des Modells
  • Modell-Gruppe erstellen
  • Model auf die Gruppe registrieren
  • Deployment
  • Machine Learning nutzen.

Ursprünglich bin ich dieser Anleitung gefolgt. Du arbeitest am bequemsten direkt unter den Developer Tools (Management-> Dev Tools), kannst deine Befehle aber wie immer auch einfach via curl gegen die API senden:

Vorbereitung von Open Search auf Machine Learning

Zunächst habe ich für alle in meinem Beispiel genutzten Modelle URL-Registrierung zugelassen:

PUT _cluster/settings
{
    "persistent" : {
        "plugins.ml_commons.allow_registering_model_via_url" : true
    }
}

Außerdem habe ich das Zeitintervall der Synchronisation erhöht.
Denn „ML Commons will run a regular sync up job to sync up newly loaded or unloaded models on each node“:

PUT /_cluster/settings
{
    "persistent": {
        "plugins.ml_commons.sync_up_job_interval_in_seconds": 600
    }
}

Ab hier musst du einige Python-Libraries laden. Viele Modelle basieren auf der Pytorch-Library. So auch Sentence-Transformers, welches für einige der OpenSearch Modelle benötigt wird.

pip install -U sentence-transformers

Prinzipiell werden ML-Tasks nur auf den eigens dafür zugewiesenen OpenSearch Knoten ausgeführt und hierfür habe ich in meiner opensearch.yml folgende Einträge gesetzt:

node.roles: [ data, cluster_manager,  ml ]
plugins.security.restapi.roles_enabled: ["all_access","ml", "security_rest_api_access"]

Machine Learning Modell bereitstellen

Vorab: Über Task-IDs checkt man, ob die vorherigen Schritte durchgingen und besorgt sich notwendige Informationen zum weiter zuordnen.

Um Machine Learning Modelle in OpenSearch bereitzustellen, legt man einfach eine Gruppe an. Anschließend lädt man das Modell, fügt das Modell der Gruppe hinzu, deployt es über die Modell-ID an die gewünschten Knoten und hat anschließend die Möglichkeit, Machine Learning zu nutzen. Diese einzelnen Schritte zeige ich dir jetzt aber noch einmal detailliert.

Schritt 1: Modell Gruppe hinzufügen.

Bevor Modelle einer Gruppe hinzugefügt werden können, muss eine solche Gruppe angelegt werden. In meinem Beispiel habe ich sie „my-ml-group“ genannt. Am einfachsten werden die Gruppen per API-Call hinzugefügt:

POST /_plugins/_ml/model_groups/_register
{
    "name": "my-ml-group",
    "description": "This is a public model group"
}

Es wird Success/Fail-Status sowie Gruppen-ID zurückgegeben, die benötigt wird: z.B. gprKIYoBmWoi9V5-T2Pb

Schritt 2: Das Modell wird von Huggingface geladen. (In meinem Beispiel verwende ich das Modell „all-MiniLM-L12-v2“)

POST /_plugins/_ml/models/_upload
{
  "name": "huggingface/sentence-transformers/all-MiniLM-L12-v2",
  "version": "1.0.1",
  "model_format": "TORCH_SCRIPT"
}

Schritt 3: Das all-MiniLM-L12-v2 Modell wird auf die vorherige Gruppen-ID meiner my-ml-group registriert:

POST /_plugins/_ml/models/_register
{
"name": "huggingface/sentence-transformers/all-MiniLM-L12-v2",
"version": "1.0.1",
"model_format": "TORCH_SCRIPT",
"model_group_id": "gprKIYoBmWoi9V5-T2Pb"
}

Hier bekommt man wieder den Success/Error-State, sowie eine Task ID zurück. In meinem Beispiel ist das die MprLIYoBmWoi9V5-o5Ix.

Schritt 4: Model-ID besorgen

Nutzt man die Task-ID vom registrierten Modell, sieht man Modell ID sowie Error-State:

GET /_plugins/_ml/tasks/MprLIYoBmWoi9V5-o5Ix
{
  "model_id": "RJrLIYoBmWoi9V5-o5LW",
  "task_type": "REGISTER_MODEL",
  "function_name": "TEXT_EMBEDDING",
  "state": "COMPLETED",
  "worker_node": [
    "KmfjhwWjS7eepv4PnUMKWw"
  ],
  "create_time": 1692784108336,
  "last_update_time": 1692784119285,
  "is_async": true
}

Die Modell-ID wird nun für das nachfolgende Deployment benötigt.

Schritt 5: Auf den Model-Nodes deployen

Zum eigentlichen Deployment braucht es Modell-ID und Knoten. Damit kann ich es auf all meinem Machine Learning-Knoten ausrollen:

POST /_plugins/_ml/models/RJrLIYoBmWoi9V5-o5LW/_load

Als Antwort bekommen ich den Task-Type: „Deploy„, sowie den State: „Completed

{
  "model_id": "RJrLIYoBmWoi9V5-o5LW",
  "task_type": "DEPLOY_MODEL",
  "function_name": "TEXT_EMBEDDING",
  "state": "COMPLETED",
  "worker_node": [
    "KmfjhwWjS7eepv4PnUMKWw"
  ],
  "create_time": 1692785563893,
  "last_update_time": 1692785582120,
  "is_async": true
}

Schritt 6: Prediction testen

Hierzu braucht es die Modell ID aus Schritt 5 des Deployments. Mit folgendem Call kannst du die Prediction testen:

POST /_plugins/_ml/_predict/text_embedding/RJrLIYoBmWoi9V5-o5LW
{
    "text_docs": [ "today is sunny" ],
    "return_number": true,
    "target_response": [ "sentence_embedding" ]
}

Ab hier wird es spannend, denn hat man mehrere OpenSearch Cluster läuft das Ganze direkt verteilt und auch alle Logs wie z.B. die von Icinga, Graylog uvm. sind im selben Backend. Dadurch wäre es möglich, mit allen vorhandenen Logs gleichzeitig zu trainieren!

Kannst du dir schon vorstellen, was du damit alles machen möchtest und vor allem da alles lokal bei dir stattfinden kann, was es bedeutet, dass du die volle Kontrolle über Datensicherheit hast?

OpenSearch: Dashboards Plugins einfach installieren

This entry is part 4 of 5 in the series OpenSearch Security

OpenSearch ist in seiner Vanilla Version schon sehr umfangreich. Doch erst mit den OpenSearch Plugins kannst du deine Experience personalisieren und das Maximum aus dem Elastic-Fork herausholen.
Eines vorab, bevor ich richtig ins Thema einsteige: die Geschwindigkeit, in der sich das Projekt aktuell weiterentwickelt ist extrem positiv. Deshalb kann man aktuell davon ausgehen, dass die Plugins beim Release des Blogposts noch mal besser geworden sind oder es noch mehr Regeln geben wird.

OpenSearch Plugins für Backend und Dashboards

Nun aber hinein ins Thema OpenSearch Plugins!
Hier muss direkt zwischen dem Backend „OpenSearch“ und den OpenSearch Dashboards unterschieden werden.

Das Backend kommt schon pre-Bundled mit einer Menge nützlicher Plugins. Diese vorinstallierten Plugins kannst du dir mit einem einfachen Befehl anzeigen lassen:

/usr/share/opensearch/bin/opensearch-plugin list

opensearch-alerting
opensearch-anomaly-detection
opensearch-asynchronous-search
opensearch-cross-cluster-replication
opensearch-geospatial
opensearch-index-management
opensearch-job-scheduler
opensearch-knn
opensearch-ml
opensearch-neural-search
opensearch-notifications
opensearch-notifications-core
opensearch-observability
opensearch-performance-analyzer
opensearch-reports-scheduler
opensearch-security
opensearch-security-analytics
opensearch-sql

Im Gegensatz dazu steht das Frontend OpenSearch Dashboards. Hier gibt es out-of-the-box keine Plugins und du kannst, darfst oder musst hier selbst Hand anlegen. Dadurch haben Anpassungen an deine individuellen Bedürfnisse jedoch nur die Grenze der Software.

Auch wenn du alle Plugins selbst installieren musst, ist dort so schnell viel in Bewegung gekommen, dass es leicht geworden ist, Plugins zu installieren. Und das Ganze ohne sich um Versionen / Git-Repositories kümmern zu müssen.

WICHTIGER HINWEIS: Es wird NICHT empfohlen, nachfolgende Skripte als Root auszuführen. Der Vollständigkeit halber habe ich die Flagge als Kommentar auskommentiert im Skript stehen lassen, solltest du das doch tun wollen.
Zum Installieren von Plugins habe ich mir folgendes „./deploy-plugins.sh„-Skript gebaut, das einfach mit dem Pfad der Binärdatei eine Installation über die Namen der Plugins macht:

#!/bin/bash

PLUGINS=(
alertingDashboards
anomalyDetectionDashboards
customImportMapDashboards
ganttChartDashboards
indexManagementDashboards
mlCommonsDashboards
notificationsDashboards
observabilityDashboards
queryWorkbenchDashboards
reportsDashboards
searchRelevanceDashboards
securityAnalyticsDashboards
securityDashboards
)

for PLUGIN in "${PLUGINS[@]}"
do
    /usr/share/opensearch-dashboards/bin/opensearch-dashboards-plugin install $PLUGIN # --allow-root
done

Mit diesem kleinen, von mir geschriebenen Skript ist es schnell und unkompliziert möglich, mehrere OpenSearch Dashboard Plugins gleichzeitig zu installieren.

Da man Plugins in den meisten Fällen nicht nur installieren, sondern auch einmal entfernen will, habe ich dazu ebenfalls ein kleines Skript geschrieben. Es hört auf den Namen „./remove-plugins.sh„:

#!/bin/bash

PLUGINS=(
alertingDashboards
anomalyDetectionDashboards
customImportMapDashboards
ganttChartDashboards
indexManagementDashboards
mlCommonsDashboards
notificationsDashboards
observabilityDashboards
queryWorkbenchDashboards
reportsDashboards
searchRelevanceDashboards
securityAnalyticsDashboards
securityDashboards
)

for PLUGIN in "${PLUGINS[@]}"
do
    /usr/share/opensearch-dashboards/bin/opensearch-dashboards-plugin remove $PLUGIN # --allow-root
done
systemctl restart opensearch && systemctl restart opensearch-dashboards

Mit dem letzten Befehl startest du OpenSearch und OpenSearch Dashboards neu. Nur so können wir sichergehen, dass die Installation oder Deinstallation von Plugins auch angenommen wird.

OpenSearch Dashboards: Plugin Überblick

Wenn du mein Skript verwendet hast, um Plugins für das Dashboard zu installieren, solltest du jetzt eine größere Seiten-Leiste haben als zuvor. Denn irgendwie musst du ja auch auf die Plugins zugreifen.
Damit du weißt, welche OpenSearch Plugins ich in meinem Skript verwende, folgt hier nun für jedes Plugin eine kurze Beschreibung sowie ein Screenshot, um dir die visuelle Darstellung vorzustellen.

Query Workbench:
Mit diesem Plugin kannst du in SQL und PPL Abfragen machen. Interessant finde ich vor allem die Explain-Funktion, die die Darstellung im JSON-Format zurückgibt.

Reporting:
Mit Reporting lassen sich bequem alle relevanten Daten, zum Beispiel deine individuell angelegten Dashboards, aber auch viele weitere Daten exportieren. Der Export kann natürlich auch mit Schedulern automatisiert werden.
Ich kann mir vorstellen, das exportiere Reportings in den Formaten PDF und PNG in vielen Business-Umgebungen eine sinnvolle Erweiterung darstellen.

Alerting:
Hiermit kannst du für alle Parameter, die du überwachst, etwa Anomalien in deinen Datensätzen, Schwellwerte setzen und Aktionen auslösen lassen. Stark sind hier die vielen Möglichkeiten, die geboten werden. Du kannst dich zum Beispiel benachrichtigen lassen, wenn ein „whoami“ eingegeben wird oder ein Icinga2Host ausfällt! Die Grenzen sind sehr weit gefasst, dass sicher auch für deinen Use Case das passende Alerting einstellbar ist.

Stark sind vor allem mitgelieferten Notification Channels und das freundliche UI!

Anomaly Detection:
Hier wird der Nutzer mit mehr Neugier, Statistikwissen und tieferer Kenntnis seiner Daten (sowie, deren Felder) besseren Nutzen rausholen können.
In meinem Screenshot siehst du ein kleines Beispiel der Anomalien der Event Codes eines Active Directories der letzten 30 Tage. Solche Möglichkeiten sind natürlich genial für alle Admins, Data Scientists oder Analysten die projizieren und erkennen wollen:

Maps:
Richtig spannend wird es, wenn dir Geodaten zur Verfügung stehen. Im OpenSearch Dashboards Plugin Maps kannst du dann aus mehreren visuellen Layern auswählen. Damit kann man schnell beeindrucken und mit den unterschiedlichen Layern sogar seine präferierte Ansicht wählen.

Security Analytics:
Vielleicht hast du mittlerweile auch ähnliche Gedankengänge wie ich zum Zeitpunkt, als ich OpenSearch getestet habe. Einer der prominentesten Gedanken bei mir war „Okay cool. Und das ist wirklich alles umsonst?“. Die einfache Antwort: Yes!

Aber als ich dann bei Security Analytics mit einem Klick einen Detector anlegen wollte, war ich dann einfach nur (positiv) schockiert. Hier sind massig Sigma Regeln eingebunden und das komplett umsonst!
Allein die Auswahl an Providern ist der Wahnsinn.

Fast 1600 Sigma-Regeln für Windows?! Wow!

Die Auswahl an Linux-Regeln ist auch stark und auch wenn es nicht viele sind, scheint man sich mit der Auswahl sehr viel Gedanken gemacht zu haben, um eine breite Trickkiste abzufangen:

Also ist hier alles perfekt? Sehr gut, ja, aber nicht perfekt. Denn ein kleiner Haken im Vergleich zu Graylog und Elastic, die fertig eingerichtet kommen, ist, dass du die Detector-Regeln erst mal an die Felder der Indices anpassen musst. Dafür benötigst du schon einiges an Wissen und Zeit. Das heißt aber nicht, dass das so bleiben muss / wird!

Kaum am Laufen und minimale Anpassungen später hatte ich direkt einen simulierten Treffer in einem Honeypot-AD von mir:

Index Management & Snapshot Management:
Snapshots sind für viele Admins und Entwickler wichtig. Ebenso wichtig sind Rollups mit denen man abbilden kann, wie lange die Daten der einzelnen Indizes verwahrt werden sollen.
In meinem Anwendungsbeispiel lege ich mir einfach einen neuen Index an und schiebe den alten dort hinein. Das Feld ist zusätzlich noch zeitgesteuert, womit man sehr viel Customization erhält:

Search Relevance:
Mit diesem Plugins sich verschiedene Suchen vergleichen. Ziemlich hilfreich, um schnell Daten, etwas Felder aus verschiedenen Indizes miteinander zu vergleichen. Das setzt natürlich voraus, sich einmal mit der OpenSearch Query DSL auseinanderzusetzen.

Maschine Learning:
Um dieses Plugin einzusetzen, willst du genug Cluster haben, mit genug CPU & GPU Power. Dabei ist auch die Frage, wo du die Arbeit verrichten lassen willst, denn Logging braucht so schon genug Leistung und du brauchst auch extra Libraries.
Den Einsatz dieses OpenSearch Dashboard Plugins solltest du also etwas genauer planen. Auch Maschine Learning Modell-Deployments habe ich im Rahmen meiner OpenSearch Analyse genauer unter die Lupe genommen. Dieser Abschnitt würde jedoch den Rahmen dieses Blogbeitrags sprengen. Deshalb werde ich zum Thema OpenSearch Machine Learnung einen gesonderten Blogpost schreiben.

Ich hoffe, ich konnte dir mit diesem Blogpost ein paar Beispiele für die vielfältigen Plugins in OpenSearch zeigen und freue mich auf dein Feedback!