Seite wählen

NETWAYS Blog

Maximale Datenkontrolle: OpenSearch Dashboards und Icinga Integration

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!

OpenSearch Dashboards: TLS, Konten & Datensicherheit

Du hast dich auch schon gefragt, wie du die einzelnen Komponenten von OpenSearch sicher verknüpfen kannst? Dann bist du auf die gleichen Probleme gestoßen wie ich. Damit du nicht auch mehrere Tage mit der Lösungsfindung verbringen musst, habe ich meine Lösungen für dich zusammengetragen.

In diesen Blogpost gehe ich auf die Lösung folgender Probleme ein:

  • OpenSearch Dashboards sicher verwenden
  • Wie deaktiviere ich Accounts, wie füge ich neue hinzu?
  • Wie kann ich mehr aus OpenSearch Dashboards herausholen und beispielweise Powershell Befehle überwachen?

OpenSearch Indexe referenzieren, Discover testen, und Dashboards verwenden

Im Vergleich zu Elasticsearch wird das Indexmanagement in OpenSearch als „Dashboard Management“. Hier muss man via „Index Patterns“ auf den gewünschten Index für die DiscoverAnzeige referenzieren, z.b. via „graylog*“

Dashboards lassen sich bequem via Visualize -> Create Visualization erstellen. Mich interessieren vor allem SSH Zugriffe und neue Nutzer Sessions.

OpenSearch Dashboards mit TLS

Im Idealfall stellst du sicher, dass die gesamte Kommunikation von OpenSearch zu den OpenSearch Dashboards über den gesamten Transportweg hinweg verschlüsselt ist. Hier werden schließlich sämtliche (auch vertrauliche) Daten ausgetauscht.
Gleichzeitig ist es wichtig, dass auch die Verbindung von deinem Browser zu den OpenSearch Dashboards verschlüsselt ist.

Um dir ein aktiv genutztes Beispiel für die Verschlüsselung zu geben, zeige ich eine von mir getestete (minimalistische) TLS-Konfiguration, die du unter „/etc/opensearch-dashboards/opensearch_dashboards.yml“ anpassen kannst.

Du siehst die Hostnamen deiner OpenSearch-Server, die genutzten Ports, Zugriffsrechte sowie die Zertifikate für den Transportweg und den Browser.
Zusätzlich benötigst du einen Zugriffsaccount. Beachte, dass teilweise standardmäßige Standardpasswörter aktiv sind. Wie du Service- und Benutzernamen änderst, erfährst du im nächsten Abschnitt.

server.name: "opensearch-dashboards"
opensearch.hosts: ["https://opensearch.lan:9200"]

opensearch.requestHeadersAllowlist: [ authorization,securitytenant ]
opensearch_security.readonly_mode.roles: [kibana_read_only]

server.ssl.enabled: true
server.ssl.certificate: /etc/opensearch-dashboards/opensearch-dashboards.crt
server.ssl.key: /etc/opensearch-dashboards/opensearch-dashboards.key

opensearch.ssl.certificate: /etc/opensearch-dashboards/opensearch-dashboards.crt
opensearch.ssl.key: /etc/opensearch-dashboards/opensearch-dashboards.key

opensearch.ssl.certificateAuthorities: [ "/etc/opensearch-dashboards/graylog-ca-root.crt" ]
opensearch.ssl.verificationMode: certificate

opensearch.username: my_dasbhboards_service_acc 
opensearch.password: my_dasbhboards_secure_pass

OpenSearch Accounts ändern via Securityadmin

Um Service-Passwörter zu verändern, musst du sie direkt auf deinem OpenSearch Server anpassen. Das geht aktuell nur über die internal_users.yml welche du unter /etc/opensearch/opensearch-security/internal_users.yml findest.
Die Passwörter sind idealerweise gehasht. OpenSearch stellt ein Tool zum Hashen von Passwörtern zur Verfügung. Das entsprechende Skript findest du hier:

/usr/share/opensearch/plugins/opensearch-security/tools/hash.sh

 

Willst du statt Passwörtern lieber Benutzer ändern, geht aktuell (soll aber deprecated werden) über das Securityadmin.sh Skript, indem du den korrekten Client-Key, das Client-Zertifikat, plus CA-Zertifikat gegen die OpenSearch-Instanz verifizierst.
Genau das tue ich, indem ich auf das Skript verweise. Dabei nutze ich das internal_users-File sowie Client-Key und Zertifikate, einschließlich der CA (Graylog-ca-Root). Zusätzlich gebe ich den FQDN meines OpenSearch an, gegen den ich das Skript ausführe.

bash /usr/share/opensearch/plugins/opensearch-security/tools/securityadmin.sh -f /etc/opensearch/opensearch-security/internal_users.yml -cert /etc/opensearch/opensearch.crt -key /etc/opensearch/opensearch.key -cacert /etc/opensearch/graylog-ca-root.crt -h opensearch.lan

Windows Command Line Logging

Ich finde, wir sind jetzt bereit, dafür weitere Felder der Indizes zu erkunden. Beispielsweise das Command-Line-Logging von Windows-Servern.

Nxlog zeigt in einem interessanten Audit, wie man unabhängig vom Active Directory schnell Command-Line Logging aktivieren kann. Ich habe das ganze ein bisschen erweitert und in ein Ansible Playbook gepackt.
Bitte beachte dabei, dass für diese Maßnahme aus datenschutzrechtlichen Gründen die Erlaubnis des betroffenen Clients erforderlich ist.

In diesem Prozess aktiviere ich die Auditpolicies für „Process Create“, „RPC Events“, „Process Terminate“ und „DPAPI“. Die Ergebnisse werden anschließend direkt im Winlogbeat erkennbar sein.

---
- hosts: windows
  tasks:
  - name: Configure Audit Policy for Process Creation
    win_shell: auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable

  - name: Configure Audit Policy for RPC Events
    win_shell: auditpol /set /subcategory:"RPC Events" /success:enable /failure:enable

  - name: Configure Audit Policy for Process Termination
    win_shell: auditpol /set /subcategory:"Process Termination" /success:enable /failure:enable

  - name: Configure Audit Policy for DPAPI Activity
    win_shell: auditpol /set /subcategory:"DPAPI Activity" /success:enable /failure:enable

  - name: Configure Audit Policy for PNP Activity
    win_shell: auditpol /set /subcategory:"Plug and Play Events" /success:enable /failure:enable

  - name: Enable Command Line in Process Creation Event
    win_shell: Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" -Name ProcessCreationIncludeCmdLine_Enabled -Value 1

  - name: Reboot the system
    win_reboot:

Opensearch Discover

Zum Abschluss werfen wir noch einmal einen Blick in OpenSearch Discover. Im Bereich „Selected Fields“ siehst du nun die von mir ausgewählten Winlogbeat-Felder sowie einige erfasste Eingaben der „Windows Command Line“. Durch einen Klick auf das Plus-Symbol neben den „Available Fields“ werden diese zu „Selected Fields“ hinzugefügt. So einfach kann die getroffene Auswahl kenntlich gemacht werden.

Bist du nun ebenfalls bereit, deine Log-Management-Strategie zu optimieren und Security mehr in den Fokus zu rücken? Falls du Hilfe bei der Implementierung von OpenSearchElastic oder Graylog benötigst, stehen dir ich und meine Kolleg:innen von NETWAYS gerne zur Seite. Mit unserer Erfahrung sorgen wir für eine für dich maßgeschneiderte Log-Management Lösung. Wir freuen uns auf deine Nachricht.

OpenSearch – TLS für den Elastic-Fork

Wir erhalten vermehrt Kundenanfragen, die sich für den Teil A 8.15 Logging der ISO 27001 interessieren und beim Logging-Teil Unterstützung möchten. Je nach Bedürfnissen & Funktionsumfang hast du die Wahl, ob du Elasticsearch oder OpenSearch als Backend möchtest.
Wir bei NETWAYS verwenden beide Projekte, denn sie bieten unterschiedliche Möglichkeiten und vor allem verschiedene Security-Ansätze. Dadurch können wir unseren Kunden immer die bestmögliche Lösung für ihre Umgebung anbieten.

Bevor wir tiefer in die die Welt der OpenSearch Security einsteigen und uns der OpenSearch TLS Verschlüsselung widmen, gibt es für alle Interessierten einen kurzen Exkurs. Denn wer steckt eigentlich hinter OpenSearch und warum ist der Elastic Fork mittlerweile so relevant.

OpenSearch ist die AWS Antwort zu Elastic

In ihrem offiziellen FAQ beschreibt sich das OpenSearch Projekt selbst als „Open Source Search and Analytics Suite„, das von AWS unterstützt wird. Wir als Anwender:innen können dementsprechend eine langfristige Maintenance erwarten. AWS ist dabei nicht das einzige namhafte IT-Unternehmen, das seine Ressourcen für die Weiterentwicklung von OpenSearch bereitstellt. Unter anderem gehören RedHat, SAP und CapitolOne zu den weiteren Unterstützern des Projekts.
Auch Graylog empfiehlt seinen Anwender:innen in der Dokumentation für neue Installationen zukünftig auf OpenSearch zu setzen.

Sind Elastic und OpenSearch also das gleiche Tool, nur mit anderem Namen? Nein, auch wenn sie auf den ersten Blick ähnliche Aufgaben erfüllen: Einsammeln, Ablegen und Durchsuchen von Datensätzen.
Die Differenzen beginnen bei allen anderen Funktionen. Seien es Features zur Authentifizierung, die Speicherung der Daten oder die besonders relevante Frage „Was bedeuten meine Daten und wie kann ich diese schützen?“.

Wenn du abseits dieser grundlegenden Informationen mehr zu den Hintergründen der Entstehung von OpenSearch erfahren willst, lege ich dir den Blogpost meines Kollegen Daniel Neuberger ans Herz. Darin hat er sich ausführlich mit den Hintergründen des Forks sowie einer Gegenüberstellung der beiden Tools beschäftigt.

OpenSearch TLS Verschlüsselung

Anstatt auf die Installation von OpenSearch einzugehen (neben der offiziellen Doku gibt es z.B. von Graylog eine Installation in zehn Zeilen Code) beschäftige ich mich mit einem anderen wichtigen Thema: Sicherheit. Genauer gesagt mit der TLS Verschlüsselung von OpenSearch.

Warum genau dieses Thema?
Weil die Sicherheit in Softwarelösungen und besonders die Verschlüsselung der Kommunikation heutzutage wichtiger ist denn je. Und OpenSearch bietet seinen Anwender:innen vielfältige Konfigurationsmöglichkeiten.
Solltest du also mehrere Server in OpenSearch eingebunden haben, die auf mehrere Netze verteilt sind, willst du auf jeden Fall TLS aktiviert haben. Zudem machst du es einem potenziellen Angreifer, wenn er es schaffen sollte, so tief in deine Infrastruktur zu gelangen (und TCPDump aktivieren will, um Credentials und Secrets abzufangen) schwer.
Das Stichwort lautet hier für Angreifer: Impose Cost.

Bevor ich dir meine Vorgehensweise zur OpenSearch TLS Verschlüsselung zeige noch ein wichtiger Hinweis:

Es ist wichtig zu beachten, dass Downgrades / Upgrades von TLS oder das Löschen von Zertifikaten potenzielle Angriffsvektoren in deiner Log-Pipeline sein können. Daher kann die Überwachung von Zertifikaten, Hosts und Fehlerprotokollen mithilfe von Monitoringsystemen, etwa Icinga signifikant dazu beitragen, die Sicherheit und Verfügbarkeit deiner Systeme zu verbessern.
Aus sicherheitstechnischer Sicht ist es zudem äußerst lobenswert, dass die offizielle Dokumentation von OpenSearch zeigt, wie man Zertifikate ausstellt und die standardmäßig verwendeten Demo Zertifikate löscht.

Für die TLS Verschlüsselung meines OpenSerch teile ich dir Dir meine /etc/opensearch/opensearch.yml , die Kernkonfigurationsdatei des OpenSearch Projektes, die alles relevante enthält. Wichtige Eckpunkte dafür sind:

  • graylog-ca-root.crt dient als CA
  • opensearch.crt wird als Clientverwendet
  • TLS wird für den Transport & HTTP-Weg benötigt
  • Self-Signed Zertifikate werden als „Demo“ geführt
  • Ich aktiviere Audittypen, Snapshots und weise Features RestApiZugriff zu.

Weitere Parameter kannst du der offiziellen Doku entnehmen. Dennoch sollte meine Konfiguration, angepasst an deine self-signed Zertifikate, problemlos direkt funktionieren und zu einer erfolgreichen TLS Verschlüsselung führen.
(Zum eindeutigen Verständnis aller Prozesse innerhalb der Konfigurationsdatei habe ich relevante Bereiche mit Kommentaren versehen.)

# WARNING: revise all the lines below before you go into production

plugins.security.ssl.transport.enabled: true
plugins.security.ssl.transport.pemcert_filepath: /etc/opensearch/opensearch.crt
plugins.security.ssl.transport.pemkey_filepath: /etc/opensearch/opensearch.key
plugins.security.ssl.transport.pemtrustedcas_filepath: /etc/opensearch/graylog-ca-root.crt

# Ist die Zertifikatskette nicht korrekt auf die subjectAltName mit FQDNs / IPs gesetzt, teste mit "false" & korrigiere danach mit true
plugins.security.ssl.transport.enforce_hostname_verification: true

plugins.security.ssl.http.enabled: true
plugins.security.ssl.http.pemcert_filepath: /etc/opensearch/opensearch.crt
plugins.security.ssl.http.pemkey_filepath: /etc/opensearch/opensearch.key
plugins.security.ssl.http.pemtrustedcas_filepath: /etc/opensearch/graylog-ca-root.crt

plugins.security.allow_default_init_securityindex: true

# Self-Signed Zertifikate werden unter "unsafe_democertificates" geführt
plugins.security.allow_unsafe_democertificates: true

plugins.security.authcz.admin_dn:
  - "CN=opensearch.lan,OU=nps,O=nw,L=nbg,ST=by,C=de"
plugins.security.nodes_dn:
  - "CN=opensearch.lan,OU=nps,O=nw,L=nbg,ST=by,C=de"

plugins.security.audit.type: internal_opensearch

plugins.security.enable_snapshot_restore_privilege: true
plugins.security.check_snapshot_restore_write_privileges: true
plugins.security.cache.ttl_minutes: 60

plugins.security.restapi.roles_enabled: ["all_access", "security_rest_api_access"]
plugins.security.system_indices.enabled: true

#opendistro_security.audit.config.disabled_rest_categories: NONE
#opendistro_security.audit.config.disabled_transport_categories: NONE

#node.max_local_storage_nodes: 3
######## End OpenSearch Security Demo Configuration ########

action.auto_create_index: true

#Wichtig: Aktivierungs-Trigger der TLS-Konfiguration:
plugins.security.disabled: false

OpenSearch und besonders die Sicherheitsaspekte der Software werden mich auch in den kommenden Wochen noch weiter beschäftigen.
Wenn du zu diesem oder anderen Themen rund um OpenSearch oder Elastic Fragen hast, stehen ich oder meine Kolleg:innen dir gerne mit unserer Expertise zur Seite. Wir helfen dir dabei, Projekte zu planen, Umgebungen zu simulieren oder Entscheidungen basierend auf deinen verfügbaren Ressourcen zu treffen.

Obwohl du bei einem Termin meist einen Consultant als Ansprechpartner:in hast, bekommst du das kollektive Wissen unserer Abteilung. Gerne helfen wir dir, TLS in Verbindung mit Graylog oder anderen Produkten über deinen kompletten Stack über alle Clients und Server auszurollen.

TLS: Eine kleine Übersicht

Der durschnittliche Internetbenutzer benutzt TLS (Transport Layer Security) mittlerweile auf fast allen größeren Websiten – ohne, dass sich dieser darüber bewusst wäre, in den allermeisten Fällen. Auch in meiner Ausbildung bei NETWAYS darf ich mich nun intensiv mit TLS beschäftigen. Doch was ist TLS? Dieser Text soll einen groben Umriss um die zugrunde liegenden Prinzipien und Techniken hinter TLS legen.

Warum brauchen wir TLS?

TLS wird benötigt, um drei Probleme zu lösen. Unsere Kommunikationen sollen verschlüsselt sein – wir wollen nicht, dass Pakete oder Informationen, die wir übertragen, abgehört werden. Außerdem wollen wir sicher gehen, dass der andere Teilnehmer dieser Kommunikation auch derjenige ist, mit dem wir diesen Austausch an Informationen vollziehen wollen. Darüber hinaus wäre es auch gut, sich darauf verlassen zu können, dass das, was von der einen Seite losgeschickt wurde, auch das ist, was der andere erhält. Um diese drei Probleme kümmert sich TLS. Doch wie macht es das?

Eine Beispielverbindung:

1. ClientHello

Ein Client verbindet sich mit einem Server und verlangt eine gesichertete Verbindung. Dazu wird die Version von TLS übertragen, und eine Chiffrensammlung, aus denen sich der Server die Verschlüsselungsmethode aussuchen kann.

2. ServerHello & Certificate & ServerKeyExchange

Der Server antwortet, welches Chiffre verwendet werden soll, und einem Zertifikat, welches den Server authentifizieren soll und einen öffentlichen Schlüssel enthält.

3. ClientKeyExchange

Dieses Zertifikat wird von dem Client verifiziert, und der öffentliche Schlüssel des Servers wird vom Client benutzt, um ein pre-master secret zu erstellen, welcher dann wieder an den Server geschickt wird.

Der Server entschlüsselt das pre-master secret, und beide Parteien nutzen es, um einen geheimen, geteilten Schlüssel zu erstellen, welcher als shared secret bezeichnet wird.

4. ChangeCipherSpec

Der Client versendet die erste, mit dem shared secret verschlüsselte Nachricht, welche der Server entschlüsseln soll, damit geprüft werden kann, ob die Verschlüsselung richtig initialisiert wurde. Wenn diese Verifizierung erfolgreich abgelaufen ist, kommunizieren dann der Client und der Server verschlüsselt untereinander. Dieser ganze Prozess wird als TLS-Handshake bezeichnet.



Geschichte: TLS wurde unter dem Vorläufernamen SSL (Secure Sockets Layer) in 1994 von Netscape für den damals sehr populären Browser Mosaic vorgestellt. Version 2.0 und 3.0 folgten jeweils ein Jahr später. 1999 wurde SSL 3.1 bei der Aufnahme als Standart von der Internet Engineering Task Force in TLS 1.0 umbenannt. 2006 folgte Version 1.1, 2008 1.2 und 2018 die heutige Version 1.3.


Asymmetrische & Symmetrische Verschlüsselung: TLS ist zunächst asymmetrisch, dann symmetrisch verschlüsselt. Was bedeutet das? Nun, hier kommen die Schlüsselpaare ins Spiel. TLS benötigt einen öffentlichen und einen privaten Schlüssel. Der öffentliche Schlüssel wird benutzt, damit der Gegenpart einen Vorschlüssel erstellen kann, welcher dann von dem privaten Schlüssel wieder decodiert wird. Das ist eine asymmetrische Verschlüsselung – welche allerdings deutlich kostenintensiver und aufwändiger ist, und sich dementsprechend nicht für die zahlreichen Anwendungsmöglichkeiten für eine TLS-Verbindung eignet. Dank‘ dem Vorschlüssel können allerdings beide Seiten des Austausches einen gemeinsamen, geheimen Schlüssel berechnen, mit Hilfe dessen die verschlüsselten Nachrichten auf jeweils beiden Seiten entschlüsselt werden können. Somit ist der Kern von TLS eine symmetrische Verschlüsselung; der Austausch der tatsächlichen Information passiert über diesen Kanal. Um aber an diesen Punkt zu kommen, sind asymmetrische Verschlüsselungsprinzipien im Einsatz.


Zertifikate: Wie in dem TLS-Handshake betrachtet, sind Zertifkate elementar zur Ausweisung und Identifikation von Server und Client – und wohl der kritischste Punkt in dem ganzen TLS-Ablauf. Damit ein Kommunikationspartner identifiziert werden kann, muss er sein Zertifikat ausweisen, welches seine Identiät beweist. Ausgestellt wird ein Zertifikat von einer certificate authority, einem vertrauenswürdigen Aussteller dieser Zertifikate, was verschiedenste Dinge bedeuten kann: Viele multinationale Konzerne stellen kommerziell Zertifikate aus, darunter fallen Firmen wie IdenTrust, Sectigo und DigiCert Group. Es existieren allerdings auch einige non-profit organisations, wie CAcert und Let’s Encrypt, die als Zertifizierungsstelle auftreten. Darüber hinaus gibt es natürlich auch jede Menge Zertifikatsaussteller innerhalb von Netzen, welche in der Hand von einem vertrauenswürdigen Admin liegen.


Chiffrensammlung: Eine Chiffrensammlung ist eine Auflistung aus den Verschlüsselungsmethoden, die bei einer TLS-Verbindung eingesetzt werden können. Beispiele dafür wären RSA, MD5, SHA. Bei einer TLC-Verbindung wird in ClientHello und ServerHello unter den beiden beteiligten Parteien kommuniziert, welche dieser Methoden zur Verfügung für den Aufbau der Verbindung stehen.


https: Doch was hat es nun mit https auf sich? Ganz einfach: https (HyperText Transfer Protocol Secure) ist eine Extension von http, bei der http über eine verschlüsselte TLS-Verbindung versendet wird, was sie im Gegensatz zu Klartext-http vor unerwünschten Abschnorchelungen und sonstigen Attacken schützt.


Verbreitung: Laut der regelmäßig auf einen neuen Stand gebrachten Auswertung von SSL Labs von rund 140.000 Webpages bieten gerade mal 67.2% eine adequate TLS-Ausstattung. Das mag im ersten Moment etwas niedrig erscheinen, man darf aber auch nicht vergessen, dass diese Lage vor nicht allzu langer Zeit noch deutlich, deutlich schlimmer war, und durch Maßnahmen wie einer automatischen Warnung von Chrome verbessert wurde. So hat sich auch laut Firefox Telemetry die Anzahl der per https aufgerufenen Websiten sich von 25% auf 75% erhöht. Ebenso bemerkenswert: Einem Jahr nach Einführung von TLS 1.3 unterstützen gerade mal 15% den aktuellen Standart, der absolut überwiegende Teil bietet noch hauptsächlich TLS 1.2 an. Man darf gespannt sein, wie lange es dauert, bis der Großteil den Wechsel vollzogen hat. Auf der anderen Seite bieten 7.5% der Webpages noch Unterstüztung für SSL 3.0 an, einem Standart, der mittlerweile fast so alt ist wie ich selbst, und als nicht sicher gilt.

 

 

 

HW Group STE2 – Hitze frühzeitig erkennen

Unser Online Store bietet nun ca. einem Jahr den inoffiziellen Nachfolger des HW group STE, das HW goup STE2 an. Dennoch wird das HW group STE weiterhin in rauen Mengen bestellt. Möglicherweise fällt Kunden, die bereits mehrere HW group STE im Einsatz haben, die Umstellung nicht leicht. Das ist schade, da es sich beim HW group STE2 bezüglich der Hard- und Software um eine komplett überarbeitete Version des HWg STE handelt. Und dabei spielt die modernere Optik nur eine Nebenrolle.
Eine schnellere Reaktionsfähigkeit und die integrierte WiFi-Funktion zeichnen das Gerät aus. Spannend: Es kann individuell entschieden werden, ob das Gerät per PoE oder Netzteil betrieben werden soll. Das HWg STE2 kann beides und das von Haus aus. Beim Vorgänger musste auf ein anderes Gerät, das HWg STE PoE zurückgegriffen werden, sollte ein Betrieb ohne Netzteil gewünscht sein.
Aber sehen Sie selbst, was das HWg STE2 zu einem Must-have der Monitoringhardware macht:

Technische Daten HWg STE HWg STE2
Anschlüsse Netzwerk Netzwerk, WiFi
Sensoren (Temperatur oder Luftfeuchte) 2x 3x
Digitale Eingänge 0 2x
HWg-Push  
SNMP    
TLS    
Stromversorgung Netzteil 5V Netzteil 5 V oder PoE
Lieferumfang HWg STE, Netztstecker/Adapter, CD, Temperatursensor HWg STE2, Netztstecker/Adapter, Temperatursensor (-10 °C bis 80 °C)

E-Mail Alarmierung – Safety first!
Ab dem STE2 wird bei der E-Mail- Alarmierung auf TLS Transportverschlüsselung gesetzt. Hier griff der Hersteller Anregungen u.a. von uns auf, da es beim Betrieb des HW group STE oftmals zu Schwierigkeiten aufgrund der fehlenden TLS gekommen war.

STE2 Lieferumfang


Auch das Thema SMS-Benachrichtigung wurde bei der Konzeption des HWg STE2 besonders berücksichtigt. Nun kann endlich auch das HWg-SMS Gateway direkt über das Netzwerk angesteuert werden. Übrigens: Dieses Gateway kann die Informationen mehrerer HWg STE2 innerhalb eines Netzwerks verarbeiten.
Selbstverständlich gibt es bei uns bis auf Weiteres beide Geräte im Angebot. Eine Abkündigung der HW group STE-Reihe ist noch längst nicht in Sicht. Trotzdem: Wir vom NETWAYS Online Store empfehlen den Umstieg auf das HW group STE2.