Seite wählen

NETWAYS Blog

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!

Maximale Datenkontrolle: OpenSearch Dashboards und Icinga Integration

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

Moderne Unternehmens-IT erfordert nicht nur eine zuverlässige Überwachung. Eine tiefgehende Analyse der Daten hilft dabei, relevante Erkenntnisse zu erhalten und damit die Leistungsfähigkeit des Systems kontinuierlich zu verbessern. Die Integration von Icinga in OpenSearch hilft dir dabei, dieses Ziel zu erreichen und dabei Leistung, Sicherheit und Analysemöglichkeiten deiner IT-Umgebung zu steigern.

Mit dem Elasticsearchwriter (als Fork von Elastic funktioniert das Tool auch in OpenSearch) kannst du OpenSearch zum Beispiel um Check Ergebnisse, Metriken und Performanz-Daten ergänzen. Icingabeat erweitert das Ganze um nahezu alle Ergebnisse deiner Checkresults, Downtimes, Notifications, Acknowledgements, um nur ein paar Parameter zu nennen. Damit bekommst du noch mehr Spielraum für Customization, Visualisierung, Data-Science Analytics und Alarmierung.
Im besten Fall ist bei dir Icinga Version 2.14 im Einsatz. Falls du Hilfe bei der Installation und Konfiguration von Icinga auf Ubuntu oder RHEL benötigst, empfehle ich dir einen Blick in unsere Guides zu werfen.

Sicherheit ist das Kernthema dieses Artikels, denn bei der Integration zweier Systeme ist es umso wichtiger, dass deine Daten auf dem Transportweg sicher verschlüsselt sind (Stichwort TLS-Verschlüsselung). Das macht vor allem bei verteilten Setups mit mehreren Netzwerken Sinn.

OpenSearch – Icinga Integration: Zertifikate vorbereiten

Um die sichere Kommunikation von OpenSearch und Icinga zu ermöglichen, müssen zunächst vertrauenswürdige Zertifikate erstellt werden, die bei der TLS-Verschlüsselung zum Einsatz kommen.
Für eine umfassende und ausführliche Erklärung zur Erstellung von Zertifikaten in OpenSearch kannst du einfach den Schritten der offiziellen Dokumentation folgen.

Um dir diese Arbeit abzunehmen und direkt eine in der Praxis von mir getestete Lösung zur Verfügung zu stellen, teile ich für dir für diese Task meine Zertifikatsgenerierung.
In diesem Beispiel heißt meine CA-Stelle graylog-root-ca und der Client Icinga2Opensearch.lan. Wenn du andere Bezeichnungen nutzt oder nutzen willst, musst du sie an den entsprechenden Stellen anpassen.

# 1. Generierung Beispiel-Ordner zum Ablegen der Zertifikate
mkdir -p /etc/ssl/certs/graylog/Icinga2OpenSearch

# 2. Generierung des Icinga2Opensearch Client-Keys
openssl genpkey -algorithm RSA -out /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch.key -pkeyopt rsa_keygen_bits:4096

# 3. Template um die Alt Names zu setzen
# 3. Start
cat << EOF > /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch_openssl.cnf
[ req ]
default_bits       = 4096
default_keyfile    = /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch.key
distinguished_name = req_distinguished_name
req_extensions     = req_ext
prompt             = no

[ req_distinguished_name ]
countryName                     = de
stateOrProvinceName             = by
localityName                    = nbg
organizationName                = nw
organizationalUnitName          = nps
commonName                      = Icinga2OpenSearch.lan

[ req_ext ]
subjectAltName = @alt_names

[alt_names]
DNS.1 = Icinga2OpenSearch.lan
IP.1 = 6.6.6.6
EOF
#3. Ende

#4. Generieren des CSRs
openssl req -new -key /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch.key -out /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch.csr -config /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch_openssl.cnf

#5. Signieren des CSRs
openssl x509 -req -days 3650 -in /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch.csr -CA /etc/graylog/server/graylog-ca-root.crt -CAkey /etc/ssl/certs/graylog/central/graylog-ca-key.pem -out /etc/ssl/certs/graylog/Icinga2OpenSearch/Icinga2OpenSearch.crt

#6. Graylog-CA mitkopieren
cp /etc/ssl/certs/graylog/central/graylog-ca-root.crt /etc/ssl/certs/graylog/Icinga2OpenSearch/


#7. In den Ordner wechseln und Packen um danach SCP zum Ziel-Icinga2-Server
cd /etc/ssl/certs/graylog/Icinga2OpenSearch && tar-czvf Icinga2OpenSearch.gz Icinga2OpenSearch.crt Icinga2OpenSearch.key graylog-ca-root.crt

#8. Nach dem SCP auf den RHEL-Icinga2-Server User & Permissions anpassen
chown -Rv icinga:icinga /etc/icinga2/Icinga2OpenSearch
chmod -Rv 750 /etc/icinga2/Icinga2OpenSearch

Mit dem ElasticsearchWriter Daten an OpenSearch schicken

Nachdem die Vorbereitungen für eine sichere Kommunikation zwischen Icinga und OpenSearch abgeschlossen sind, kann nun die eigentliche Kommunikationsschnittstelle eingerichtet werden. Damit du mit dem ElasticsearchWriter die gewünschten Daten übertragen kannst, benötigt es nur ein paar kleine Einstellungen in der elasticsearch.conf aufseiten von Icinga.

Füge Host und Port, einen Namen für deinen Index sowie deinen Service-/Benutzer-Account (wie du diesen anlegst, erkläre ich in einem anderen Blogpost) hinzu. Zudem gibst du den Pfad zu den vorher angelegten Zertifikaten an und fügst eine Aktivierungsflagge hinzu. Damit sind alle relevanten Informationen in der Konfigurationsdatei verfügbar.

Wenn du noch keine Erfahrung mit dem ElasticsearchWriter hast und mehr darüber erfahren willst, empfehle ich dir den entsprechenden Abschnitt in der offiziellen Icinga Dokumentation. Darin sind Handhabung und weitere Details gut beschrieben.

vim /etc/icinga2/features-available/elasticsearch.conf
object ElasticsearchWriter "elasticsearch" {
  
  host = "opensearch.lan"
  port = 9200
  index = "icingabeat-7.17.4"
  enable_send_perfdata = true
  flush_threshold = 1024
  flush_interval = 10s
  
  username = "Icinga2Opensearch_Service_Account"
  password = "Icinga2Opensearch_Service_Password"

  ca_path = "/etc/icinga2/Icinga2OpenSearch/graylog-ca-root.crt"
  cert_path = /"etc/icinga2/Icinga2OpenSearch/Icinga2OpenSearch.crt"
  key_path = "/etc/icinga2/Icinga2OpenSearch/Icinga2OpenSearch.key"

  # Je nachdem ob self-signed oder nicht sowie die Hostnames/IPs passen hier auf true/false
  insecure_noverify = false

  enable_tls = true
}

Nun aktivierst du das Feature mit dem Befehl icinga2 feature enable elasticsearch. Anschließend kannst du via tail -f /var/log/icinga2/icinga2.log sehen, ob alles funktioniert.
Hast du den Icingabeat Index richtig referenziert, solltest du (wie in meinem Screenshot erkennbar) im Discover die Daten fließen sehen.

OpenSearch und Icingabeat

Damit Icingabeat und OpenSearch überhaupt miteinander sprechen können, müssen die Zugriffsrechte seitens Icinga freigegeben werden. Dazu erstellst du unter /etc/icinga2/features-available/api.conf ein ApiUser Objekt mit entsprechenden Rechten, beispielsweise mit dem Namen icingabeat.

object ApiListener "api" {
  accept_config = true
  accept_commands = true
  ticket_salt = "my_salt"
}

object ApiUser "icingabeat" {
  password = "icingabeat_service_password"
  permissions = ["events/*", "status/query"]
}

Wie bei allen Beats werden Logs ausgelesen und entweder über Mittelsmänner wie Logstash weitergeleitet oder direkt an Elasticsearch gesendet.

Bei OpenSearch ist es aktuell allerdings so, dass ein „direkter“ Sendeweg nur über einen Mittelsmann wie Logstash oder Graylog geht. Von hier werden die Daten anschließend an OpenSearch weitergegeben.
Es gibt also zwei Optionen, aus denen man wählen kann. Ich zeige dir zuerst einen Graylog-Input und danach einen Logstash Input.

Icingabeat Konfiguration

Bevor ich genauer auf die beiden Möglichkeiten eingehe, zeige ich dir zunächst die Icingabeat Konfiguration. Hier arbeitest du in einem Konfigurationsfile, das an einen Beat angelehnt ist. Du kannst nach Interesse verschiedene Eventstreams auswählen, denen du wie zuvor Host-IP, Service-Passwörter für OpenSearch, Zeitintervalle und Zertifikate mitgibst.

vim /etc/icingabeat/icingabeat.yml
icingabeat:
 host: "127.0.0.1"
 user: "icingabeat_opensearch_service_account"
 password: "icingabeat_opensearch_service_password"
 ssl.verify: false 
 ssl.certificate_authorities: ["/var/lib/icinga2/ca//ca.crt"] 

 eventstream.types:
   - CheckResult 
   - StateChange 
   - Notification 
   - AcknowledgementSet 
   - AcknowledgementCleared 
   - CommentAdded 
   - CommentRemoved 
   - DowntimeAdded 
   - DowntimeRemoved 
   - DowntimeStarted 
   - DowntimeTriggered 

eventstream.filter: "" 
eventstream.retry_interval: 10s 
statuspoller.interval: 60s 

# Graylog Output Variante: 
  output.logstash: 
   hosts: ["graylog.lan"] 
   ssl.enable: true 
   ssl.verification_mode: "certificate" 

   ssl.certificate_authorities: ["/etc/icinga2/Icinga2OpenSearch/graylog-ca-root.crt"] 
   ssl.certificate: "/etc/icinga2/Icinga2OpenSearch/Icinga2OpenSearch.crt" 
   ssl.key: "/etc/icinga2/Icinga2OpenSearch/Icinga2OpenSearch.key"

Graylog Input an OpenSearch

Hier vergebe ich einen Graylog-Input Namen, eine Listener Bind-Addresse und gebe ein eigenes Graylog-CA-Server Zertifikat an. Für dieses Beispiel habe ich ein extra ein Clientzertifikat namens 5044 angelegt. In meinem Screenshot siehst du, wie das komplett ausgefüllte Eingabe-Formular aussehen sollte:

Icingabeat sendet seine Informationen an den Graylog-Input, der diesen Input verarbeitet und anschließend entsprechend der Graylog-Dokumentation, weiter an OpenSearch sendet.
Damit der zweite Schritt möglich ist, musst du in /etc/graylog/server/server.conf den Weg von Graylog zu OpenSearch angeben:

"elasticsearch_hosts = https://my_graylog_service_account:my_graylog_service_password@opensearch.lan:9200"

Icingabeat Input via Logstash-OSS

In Möglichkeit Nummer 2 benutzt du das Logstash-OSS Paket von Elasticsearch auf das Amazon referenziert, und machst dir so einen Logstash-Input, der einen Output auf OpenSearch hat:

Nachdem du das Paket geladen hast, kannst du dir die verfügbaren Plugins ansehen und sichergehen, dass die benötigten Input und Output Plugins vorhanden sind:

/usr/share/logstash/bin/logstash-plugin list --verbose
/usr/share/logstash/bin/logstash-plugin install logstash-input-beats
/usr/share/logstash/bin/logstash-plugin install logstash-output-opensearch

Bedenke, dass du aus historischen Gründen zuerst deinen Logstash-Schlüssel des Inputs in das PKCS8-Format bringen musst:

# Beispiel PKCS8-mit Passphrase
openssl pkcs8 -in logstash-oss.key -topk8 -out logstash-oss-pkcs8.key

# Beispiel PKCS8-ohne Passphrase
openssl pkcs8 -in logstash-oss.key -topk8 -nocrypt -out logstash-oss-pkcs8.key

Jetzt legst du dir eine neue Pipeline an, z.B. /etc/logstash/conf.d/icingabeat-pipeline.conf. Hier legst du Beats-Input und Opensearch-Output Einstellungen fest, die via /etc/logstash/pipelines.yml angezogen werden.

Folgende Parameter müssen angegeben werden:

Input:

  • Input Port
  • SSL-Aktivierungsflaggen
  • Privater Logstash-Schlüssel im PKCS8 Format
  • CA mitgegeben

Output:

  • das OpenSearch-Backend mit IP und Port
  • Index-Format
  • Zertifikate
  • Zugangsdaten der/des Service-Accounts
input {
  beats {
  # id => "icingabeat"
    port => "5044"
    ssl => "true"
    ssl_key => '/etc/logstash/logstash-oss-pkcs8.key'
  #  ssl_key_passphrase => 'deine_passphrase_hier_falls_vorhanden' 
    ssl_certificate => '/etc/logstash/logstash-oss.crt'
    ssl_certificate_authorities => ["/etc/logstash/graylog-ca-root.crt"]
  }
}

output {
  opensearch {
    hosts => ["https://10.3.0.171:9200"]
    index => "%{[@metadata][beat]}-%{[@metadata][version]}"
    cacert => '/etc/logstash/opensearch.crt'
    ssl => "true"
    ssl_certificate_verification => "true"
    user => "logstash_oss_service_opensearch_pass""
    password => "logstash_oss_service_opensearch_pass"
  }
}

Da du Logstash-OSS als Vermittler nutzt, muss die icingabeat.yml ebenso angepasst werden. Statt auf Graylog wird nun auf Logstash-OSS referenziert, alle anderen Einstellungen bleiben unverändert:

# Logstash OSS Output Variante

output.logstash:
  hosts: ["logstash.lan"]

  ssl.enable: true
  ssl.verification_mode: "certificate"
  ssl.certificate_authorities: ["/etc/icinga2/Icinga2OpenSearch/graylog-ca-root.crt"]
  ssl.certificate: "/etc/icinga2/Icinga2OpenSearch/Icinga2OpenSearch.crt"
  ssl.key: "/etc/icinga2/Icinga2OpenSearch/Icinga2OpenSearch.key"

Bedenke, dass deine Schlüssel und Zertifikate für Icingabeat & Logstash mit den passenden File-Berechtigungen ausgestattet sind (sie müssen lesbar sein) und deine weiteren Parameter fehlerfrei sind. Sollten dennoch Fehler auftreten oder du willst alles vor dem Einsatz überprüfen, kannst du sowohl Logstash-OSS als auch Icingabeat mit den folgenden Befehlen einfach debuggen:

tail -f /var/log/logstash/logstash-*.log
/usr/local/bin/icingabeat -c /etc/icingabeat/icingabeat.yml -e -d "*"

OpenSearch und Icinga erfolgreich verknüpft

An dieser Stelle hast du die Verknüpfung von OpenSearch und Icinga erfolgreich durchgeführt. Du kannst nun komplett frei und nach deinen Interessen und Bedürfnissen Felder für die Anzeige auswählen.
Um in den vollen Genuss von Open Source Customization zu kommen, kannst du dir Dashboards so anlegen, wie du sie brauchst. Ab diesem Punkt kannst du mit deinen Icinga-Daten mehr Data Science in OpenSearch durchführen. Mir hat es sehr viel Spaß gemacht, verschiedene Trends oder Anomalien zu erkennen und der Ursache auf den Grund zu gehen.

Falls dich mein Anwendungsbeispiel zur Verknüpfung von OpenSearch und Icinga inspiriert hat, diese Möglichkeit selbst zu testen, wünsche ich dir viel Spaß dabei! Solltest du bei deiner Konfiguration jedoch auf Probleme stoßen, freue ich mich auf eine Nachricht von dir.
Neben OpenSearch bieten meine Kolleg:innen und ich auch Consulting und Support für andere hier genannte und verwendete Tools, zum Beispiel GraylogElastic oder Icinga an.

Wir helfen dir gerne weiter!