Deutsch
Francais
Nederlands
Svenska
Norsk
Dansk
Suomi
Espanol
Italiano
Portugues
Magyar
Polski
Cestina
Русский
Das Elastic Agent-Paket umfasst die gesamte Beats-Software, darunter Filebeat und Packetbeat, und nutzt diese durch eine Vielzahl von Integrationen oder Datensammlungsrichtlinien. Die Architektur des Elastic Agent besteht aus mehreren Komponenten, die in einem Zusammenspiel Daten erfassen und übertragen. Im Zentrum steht Elasticsearch, eine Datenbank, die Konfigurationsinformationen sowie Ereignisse speichert. Kibana dient als benutzerfreundliche, browserbasierte Oberfläche zur Administration von Elasticsearch, zur Datenanalyse und zur Verwaltung der Agents.
Die Agents kommunizieren mit dem sogenannten Fleet-Server, einer speziellen Rolle innerhalb eines Elastic Agents, die die Verwaltung der Flotte übernimmt. Der Fleet-Server koordiniert Richtlinien, das Ein- und Ausbuchen von Agents sowie die Datensammlung. Agents fordern ihre aktuellen Richtlinien beim Fleet-Server an, der sie wiederum von Elasticsearch abruft und an alle Mitglieder der Flotte verteilt. Die Konfiguration der Richtlinien erfolgt über die grafische Benutzeroberfläche von Kibana oder via API.
Neben der Flottenverwaltung existieren Stand-alone Agents, die nicht mit dem Fleet-Server kommunizieren, sondern mit vordefinierten Konfigurationen direkt während der Installation betrieben werden. Solche Agents eignen sich besonders für isolierte oder streng kontrollierte Umgebungen. Trotz der Tatsache, dass Elastic Agent die Beats-Technologie integriert, bietet er erweiterte Funktionalitäten, wie etwa die Überwachung von AWS-Cloud-Diensten über APIs, Performance-Daten von Apache Airflow sowie Endpoint Detection and Response (EDR) Funktionen, die durch die Übernahme von Endgame von Elastic implementiert wurden. Dadurch ermöglicht ein einzelner Agent die Erfassung von Betriebssystem- und Anwendungslogs, Leistungskennzahlen und Netzwerkverkehr auf Hostebene.
Für die sichere Kommunikation zwischen Elasticsearch, Kibana und den Agents ist die Verwendung von TLS-Zertifikaten unerlässlich. In der Praxis empfiehlt sich der Einsatz von Wildcard-Zertifikaten, die durch einen Stern (*) Platzhalter für verschiedene Subdomains erlauben. Dies erleichtert die Verwaltung, da ein einzelnes Zertifikat für mehrere Dienste innerhalb einer Domäne genutzt werden kann. Allerdings ist hierbei die erhöhte Sicherheitsanfälligkeit zu berücksichtigen, da ein kompromittierter Schlüssel Angreifern die Möglichkeit gibt, vertrauenswürdige Dienste im Netzwerk zu imitieren. Ein Ausgleich dieser Risiken kann durch getrennte Zertifikate mit ausschließlich Client- oder Server-Authentifizierungszwecken erreicht werden. Alternativ bieten Zertifikate mit expliziten Subject Alternative Names (SAN) eine präzisere Einschränkung auf festgelegte Hostnamen.
Die OpenSSL-Konfiguration für ein Wildcard-Zertifikat umfasst neben dem Common Name eine umfangreiche Liste alternativer DNS-Namen, die alle relevanten Server und Dienste innerhalb der Domäne abdecken. Dadurch wird sichergestellt, dass die verschiedenen Tools, von Elasticsearch über Kibana bis hin zu Logstash und Fleet, ein und dasselbe Zertifikat nutzen können. Zudem empfiehlt es sich, zukünftige oder erweiterte Dienste frühzeitig in die SAN-Liste aufzunehmen, um späteren Konfigurationsaufwand zu minimieren und die Kompatibilität sicherzustellen.
Ein zentraler Schritt ist das Erzeugen der Zertifikatsignierungsanfrage (CSR) mit einer konfigurierten OpenSSL-Datei, die alle notwendigen Parameter für die Erstellung des Zertifikats beinhaltet. Die sorgfältige Verwaltung der TLS-Zertifikate und Schlüssel ist essenziell, um die Vertraulichkeit und Integrität der Datenübertragung zu gewährleisten und Angriffe auf die Kommunikation zwischen den Komponenten zu verhindern.
Zusätzlich zur technischen Umsetzung ist es wichtig, die organisatorischen Rahmenbedingungen zu beachten. Die Entscheidung für Wildcard- oder spezifische Zertifikate sollte im Einklang mit den jeweiligen Sicherheitsrichtlinien und dem Risikomanagement der Organisation stehen. In produktiven Umgebungen empfiehlt sich eine strikte Trennung von Zugriffsrechten und eine regelmäßige Überprüfung der eingesetzten Zertifikate, um potenzielle Schwachstellen frühzeitig zu erkennen und zu beheben. Außerdem sollte das Zusammenspiel zwischen Fleet-Server, Agents und Elasticsearch/Kibana kontinuierlich überwacht werden, um die Konsistenz der Konfigurationen und die Zuverlässigkeit der Datenübertragung sicherzustellen.
Wie man mit OpenSSL und Elasticsearch sicher arbeitet: Zertifikate und Firewall-Konfigurationen
In einer sicheren Infrastruktur sind Zertifikate eine der wesentlichen Komponenten, um sicherzustellen, dass Daten verschlüsselt und authentifiziert übertragen werden. Wenn Sie Elasticsearch in einer Umgebung mit mehreren Servern und Datenquellen betreiben, ist es notwendig, ein sicheres Setup zu schaffen, das sowohl die Kommunikation zwischen den Servern als auch den Schutz von sensiblen Informationen gewährleistet. Die Verwendung von OpenSSL zur Erstellung von Zertifikaten und die Konfiguration einer sicheren Umgebung sind dabei grundlegende Schritte.
Zu Beginn müssen Sie eine Zertifikatsanforderung signieren. Dies erfolgt mit OpenSSL, indem Sie eine Intermediate CA verwenden. Die genaue Ausführung eines solchen Befehls könnte wie folgt aussehen:
Wichtig dabei ist, dass die Zertifikatanforderungen korrekt signiert und die erforderlichen Erweiterungen aus der CSR (Certificate Signing Request) in das endgültige Zertifikat übernommen werden. Überprüfen Sie anschließend, ob das Zertifikat die richtigen Extended Key Usages und Subject Alternative Names (SAN) enthält, etwa für Wildcard-Domains oder interne Services wie elasticsearch.local und kibana.local:
Dies stellt sicher, dass das Zertifikat korrekt validiert wurde. Danach sollten Sie das Zertifikat gegen die Zertifikatskette (CA-Chain) prüfen:
Das Ergebnis sollte OK lauten, was bestätigt, dass das Zertifikat erfolgreich gegen die CA-Kette verifiziert wurde.
Nun ist es an der Zeit, den privaten Schlüssel unverschlüsselt zu speichern, um etwaige Kompatibilitätsprobleme mit Tools zu vermeiden, die verschlüsselte Schlüssel nicht unterstützen:
Für Elasticsearch können Sie alle erforderlichen Schlüssel und Zertifikate in einem PKCS#12-Container zusammenfassen. Dieser Container ermöglicht es, sowohl das Zertifikat als auch den privaten Schlüssel in einer einzigen Datei zu speichern, die von Elasticsearch genutzt werden kann:
Der so erzeugte PKCS#12-Container kann nun in Elasticsearch eingebunden werden, um eine gesicherte TLS-Verbindung zu ermöglichen.
Neben der Erstellung und Verifikation der Zertifikate ist es notwendig, sicherzustellen, dass die richtigen Firewall-Regeln gesetzt sind, damit die einzelnen Dienste wie Elasticsearch, Kibana und Logstash miteinander kommunizieren können. Beispielsweise könnte für eine Umgebung mit Uncomplicated Firewall (UFW) folgende Regel gesetzt werden:
Diese Regel öffnet die relevanten Ports für SSH, Elasticsearch, Logstash und Kibana. Für Systeme, die Firewalld verwenden, wird ein ähnlicher Befehl verwendet:
Wichtig ist, dass Sie darauf achten, dass diese Ports für die Kommunikation zwischen den einzelnen Komponenten geöffnet sind, und dass DNS-Konfigurationen korrekt eingerichtet sind, damit die verschiedenen Services unter den richtigen Hostnamen erreichbar sind. Auf Linux- und Windows-Systemen wird dies durch Bearbeitung der Hosts-Dateien erreicht:
Nachdem die Firewall- und DNS-Konfigurationen vorgenommen wurden, kann die Installation der benötigten Tools fortgesetzt werden. Für den Einsatz von Elasticsearch und Kibana auf mehreren virtuellen Maschinen wird empfohlen, mindestens zwei virtuelle Maschinen zu verwenden. Eine VM wird für Elasticsearch, Kibana und den Elastic Agent verwendet, während die zweite VM als Fleet-Server und Logstash-Instanz fungiert. Diese Konfiguration bietet einen realistischen Einblick in den Betrieb einer Produktionsumgebung, in der verschiedene Tools auf mehreren Maschinen verteilt sind.
Um Elasticsearch mit einem TLS-zertifizierten Setup zu betreiben, müssen Sie den GPG-Schlüssel von Elastic importieren und das offizielle Elastic-Repository konfigurieren. Anschließend erfolgt die Installation von Elasticsearch und Kibana:
Die TLS-Zertifikate müssen dann auf den Elasticsearch-Host heruntergeladen und korrekt konfiguriert werden. Der TLS-Container wird durch den folgenden Befehl heruntergeladen und in das Verzeichnis /etc/elasticsearch/certs abgelegt:
Schließlich muss die Konfigurationsdatei elasticsearch.yml angepasst werden, um die entsprechenden TLS-Zertifikate zu referenzieren und die grundlegenden Einstellungen wie den Cluster-Namen und die Rollen des Knotens festzulegen.
Es ist zu beachten, dass, während Elasticsearch in vielen Tutorials mit einem selbstsignierten Zertifikat eingerichtet wird, für eine Produktionsumgebung immer benutzerdefinierte Zertifikate und eine ordnungsgemäße TLS-Konfiguration erforderlich sind. Dies stellt sicher, dass die Kommunikation zwischen den verschiedenen Komponenten verschlüsselt und gesichert ist.
Wie werden Redis-Datenbanken für Bedrohungsinformationen gefüllt und repliziert?
Die effiziente Nutzung von Redis als schnelles, schlankes Key-Value-Store-System spielt eine zentrale Rolle bei der Verwaltung und Analyse von Bedrohungsinformationen in modernen Cybersecurity-Architekturen. Die Aufgabe besteht darin, Daten aus vielfältigen Quellen zu sammeln, sie zu standardisieren, aufzubereiten und schließlich in Redis abzulegen, um schnelle Lookups und Analysen zu ermöglichen. Dabei ist es essenziell, eine robuste Infrastruktur zu schaffen, die nicht nur den initialen Datenimport bewältigt, sondern auch die fortlaufende Replikation und Synchronisation von Daten über verschiedene Redis-Instanzen sicherstellt.
Der Aufbau eines sogenannten „Leader Cache“ bildet dabei oft die Basis. Diese Instanz fungiert als zentraler Knotenpunkt, in dem die wichtigsten Bedrohungsindikatoren (Threat Indicators) zunächst konsolidiert und verarbeitet werden. Die Einspeisung der Indikatoren erfolgt häufig über Tools wie Logstash, das als Bindeglied zwischen den Datenquellen und der Redis-Datenbank dient. Hierbei werden eingehende Logs und Indikatoren aufgenommen, durch definierte Input-Plugins verarbeitet, gegebenenfalls bereinigt und in das einheitliche Format überführt.
Für das Befüllen von Redis mit den eigentlichen Key-Value-Paaren sind verschiedene Mechanismen möglich. Neben der manuellen Pflege oder dem automatisierten Upload von individuellen Datensätzen ist insbesondere die Nutzung von APIs bedeutsam. Durch individuell konfigurierte API-Keys kann der Zugriff kontrolliert und flexibel gestaltet werden. Zudem ist die Ausgabe der verarbeiteten Daten in andere Systeme wie Elasticsearch ein wichtiger Schritt, um umfassende Such- und Analysefunktionen zu ermöglichen.
Um die Verfügbarkeit und Skalierbarkeit zu erhöhen, werden Redis-Follower-Instanzen eingerichtet, die den Leader Cache spiegeln. Diese Replikation minimiert Ausfallzeiten und stellt sicher, dass die Daten auch bei hoher Last oder Ausfall einzelner Knoten konsistent und aktuell bleiben. Die Konfiguration von sogenannten Logstash Gettern ermöglicht eine effiziente Datenerfassung aus verschiedenen Quellen, wobei die Deduplication und Anreicherung der Daten eine bedeutende Rolle spielen, um Redundanzen zu vermeiden und Kontext zu erweitern.
Ein weiteres Element in der Verteilung der Threat Intelligence ist der Einsatz von Caching-Systemen wie Memcached, welche die schnelle Verfügbarkeit häufig genutzter Daten gewährleisten und dadurch die Performance des gesamten Systems steigern. Die richtige Konfiguration sowohl des Cyber Threat Intelligence Nodes als auch der Data Nodes ist entscheidend, um Drift zu verhindern – also die allmähliche Auseinanderentwicklung von Datenständen zwischen verschiedenen Instanzen. Regelmäßige Synchronisation und Monitoring der Datenintegrität sind hier essenziell.
Die Verarbeitung von von Analysten eingereichten Indikatoren erfordert besondere Sorgfalt. Diese Daten müssen validiert, aufbereitet und in das bestehende System integriert werden, ohne die Konsistenz der Datenbasis zu gefährden. Dies verlangt abgestimmte Prozesse zur Qualitätssicherung und zur Vermeidung von Inkonsistenzen.
Zusätzlich zum hier beschriebenen technischen Setup sollte verstanden werden, dass der Wert einer solchen Infrastruktur nicht nur in der reinen Speicherung von Daten liegt, sondern vor allem in der Geschwindigkeit und Genauigkeit, mit der relevante Bedrohungsinformationen abgerufen und analysiert werden können. Nur wenn die Daten konsistent, aktuell und reichhaltig angereichert sind, können Security-Analysten effektive Entscheidungen treffen und automatisierte Abwehrmaßnahmen einleiten. Die Komplexität der Datenströme und die Vielfalt der Quellen erfordern deshalb eine konsequente Standardisierung und Automatisierung der Datenverarbeitungspipelines.
Darüber hinaus ist die Sicherheit der gesamten Datenpipeline ein kritischer Aspekt. Die Verschlüsselung der Netzwerkverbindungen, Authentifizierung der Zugriffe und strikte Zugriffssteuerungen verhindern, dass sensible Bedrohungsdaten kompromittiert oder manipuliert werden. Ohne ein solides Sicherheitsfundament verlieren selbst technisch ausgefeilte Systeme ihre Wirksamkeit.
In der Praxis ist es außerdem wichtig, die Architektur so zu gestalten, dass sie flexibel auf sich ändernde Anforderungen reagiert. Die Bedrohungslage wandelt sich ständig, und neue Quellen oder Indikator-Typen müssen zeitnah eingebunden werden können. Skalierbarkeit, Modularität und Monitoring sind Schlüsselkomponenten, um eine nachhaltige und widerstandsfähige Bedrohungsdateninfrastruktur zu schaffen.
Wie man den Redis Leader-Follower-Ansatz zur Analyse von Bedrohungsindikatoren nutzt
Der Einsatz des Redis Leader-Follower-Modells zur Überprüfung von Daten auf Bedrohungsindikatoren hat sich als äußerst effektiv erwiesen, besonders in der Verarbeitung großer Mengen von Datenströmen, die kontinuierlich auf Bedrohungen hin überprüft werden müssen. Allerdings gibt es auch einige Nachteile. Ein wesentlicher Nachteil des Leader-Follower-Ansatzes ist, dass bei einem Verlust der Leader-Datenbank, etwa durch eine versehentliche Löschung, alle Follower ihre Schlüssel ebenfalls verlieren. Es ist jedoch zu beachten, dass solche Situationen in der Regel durch Administratoraktionen verursacht werden und die Logstash-Instanz, die die Schlüssel in Redis speichert, auch dafür verantwortlich ist, diese Daten an Elasticsearch oder eine andere Datenbank zu übertragen. Das bedeutet, dass diese Daten gesichert werden sollten. Obwohl Logstash keinen eingebauten Filter für Redis bietet, ermöglicht der Ruby-Filter in Logstash die Erstellung eines eigenen Filters, mit dem Sie Schlüssel-Wert-Paare in Redis schreiben und Streaming-Daten gegen den Cache prüfen können.
Die Erstellung des Leader-Caches beginnt mit der Einrichtung des Cyber-Threat-Intelligence-Knotens. Dieser Knoten nutzt Filebeat, um regelmäßig Bedrohungsindikatoren aus einer Liste zu ziehen, die Sie konfigurieren. Filebeat sendet diese Indikatoren an einen Logstash-Host, der auf demselben Server läuft. Die Logstash-Instanz wird die Indikatoren analysieren, um Schlüssel-Wert-Paare zu erstellen, diese im Redis Leader zu speichern und die Indikatoren zur sicheren Aufbewahrung an Elasticsearch zu senden. Die Konfiguration von Redis als Leader erfolgt in der Datei /etc/redis/redis.conf. Hier geben Sie an, dass Redis auf allen Schnittstellen (0.0.0.0) lauschen soll, und aktivieren TLS-Verschlüsselung für den Datentransfer. Die Konfiguration des TLS-Zertifikats und der entsprechenden Schlüssel sorgt dafür, dass die Kommunikation zwischen dem Leader und den Followern verschlüsselt erfolgt.
Die Konfiguration von Redis sollte mit Bedacht erfolgen, insbesondere im Hinblick auf Sicherheit. In einer Produktionsumgebung sollten sowohl der Cyber-Threat-Intelligence-Knoten als auch die Datenknoten nicht vom offenen Internet aus zugänglich sein. Auch wenn Redis auf allen Schnittstellen lauscht, sollte der Zugriff auf den Redis-Server auf Hosts innerhalb desselben Netzwerks beschränkt bleiben. Um den Redis-Server zu starten, müssen Sie sicherstellen, dass die Firewall den entsprechenden Port (6379) zulässt und der Redis-Server automatisch beim Hochfahren des Systems startet.
Nachdem Redis als Leader eingerichtet wurde, muss Logstash konfiguriert werden, um Bedrohungsindikatoren zu empfangen. Logstash fungiert in diesem Fall als "Setter", der die Schlüssel-Wert-Paare in den Redis Leader-Cache hinzufügt. Der Logstash-Input wird so konfiguriert, dass er Indikatoren entweder von Filebeat oder von benutzerdefinierten CSV-Dateien entgegennimmt, die von Cybersicherheitsanalysten hochgeladen werden. Diese Konfiguration ermöglicht es, die Indikatoren zu verarbeiten, in den Redis Leader-Cache zu speichern und bei Bedarf auch in Elasticsearch zu sichern.
Für die Verarbeitung von CSV-Dateien, die von Analysten hochgeladen werden, müssen die entsprechenden Eingaben in Logstash so konfiguriert werden, dass sie diese Daten im richtigen Format akzeptieren. Dies kann durch die Verwendung von benutzerdefinierten Eingabekonfigurationen erfolgen, die sowohl SSL-verschlüsselte Verbindungen als auch die Validierung der hochgeladenen Daten sicherstellen. In der Logstash-Konfiguration wird definiert, welche Ports für die Kommunikation verwendet werden, und die Indikatoren werden in einem JSON-Format verarbeitet. Wenn die Daten von Filebeat kommen, wird ein Filter hinzugefügt, der sicherstellt, dass die Bedrohungsindikatoren korrekt extrahiert und für die spätere Verarbeitung in den Redis Leader-Cache gespeichert werden.
Ein weiterer wichtiger Punkt bei der Verarbeitung von Indikatoren ist die Verwendung von Mutate- und JSON-Filtern in Logstash. Dies ermöglicht es, Datenfelder zu ergänzen oder zu ändern, bevor sie in Redis gespeichert werden. Zum Beispiel kann das Dataset-Feld aus der Event-Nachricht extrahiert und in einem neuen Feld hinzugefügt werden. Die Indikatoren werden so angereichert, dass sie besser für die Analyse und den Abgleich mit anderen Daten geeignet sind.
Neben der Konfiguration von Redis und Logstash ist es auch von Bedeutung, dass die Integrität der übertragenen Daten regelmäßig überprüft wird. Durch den Einsatz von Verschlüsselung und Authentifizierung, sowohl bei der Kommunikation zwischen Redis und seinen Followern als auch beim Datentransfer zu Elasticsearch, wird sichergestellt, dass die Bedrohungsindikatoren nicht manipuliert werden können.
Es ist von entscheidender Bedeutung, dass in einem solchen System nicht nur die Konfiguration der Software, sondern auch die strategische Platzierung der Server und die Netzwerksicherheit berücksichtigt werden. Die Server, die als Redis Leader und Follower fungieren, müssen sich innerhalb eines sicheren, gut überwachten Netzwerks befinden. Nur so kann gewährleistet werden, dass die gesammelten Bedrohungsindikatoren zuverlässig und in Echtzeit verarbeitet werden, ohne dass externe Bedrohungen die Integrität der Daten gefährden.