Die Datenschutz-Grundverordnung nähert sich mit großen Schritten. Und auch in Sachen Hackerangriffen dürfen sich Unternehmen 2018 wieder auf einiges gefasst ... (mehr)

Logs einsammeln

Hat der Admin auf seinen Zielsystemen Osquery eingerichtet, stellt sich noch die Frage, wie er die dort gesammelten Monitoring-Daten zentral verfügbar macht. Osquery greift dem Admin hier durchaus unter die Arme: Die Ergebnisse der Checks, die es auf den Systemen ausführt, legt es in einer Logdatei ab. Ab Werk ist das auf Linux etwa "/var/log/osquery/osqueryd.results.log". Um das automatische Verarbeiten zu erleichtern, kommt die Datei sinnvollerweise in JSON daher. Obendrein pflegt Osquery die Datei inkrementell: Nur nach dem ersten Programmstart gibt es für sämtliche Queries die gesamte Ausgabe einmal in jene Datei aus; ruft Osqueryd die Checks später erneut auf, vermerkt er in "osqueryd.results.log" nur noch Änderungen der Ausgabe, falls es welche gibt (Bild 4).

Dem geneigten Admin legen die Osqueryd-Entwickler an dieser Stelle trotzdem ein ordentliches Ei – denn die Funktionalität, um "osqueryd"-Logs zentral zu sammeln und auszuwerten, fehlt. Die technische Umsetzung dieses Schritts überlassen die Entwickler ihren Nutzern – mit einer eher lapidaren Begründung: Sie hätten sich des Themas Log-Aggregation bewusst nicht angenommen, weil sie davon ausgingen, dass in großen Setups eine entsprechende Log-Aggregation-Lösung ohnehin bereits ausgerollt sei. Darin möge der Admin die Osquery-Logs ganz einfach mit aufnehmen.

Das hilft leider nur bedingt: Klassische Log-Einsammler sind qua Definition schließlich nicht darauf ausgelegt, Monitoring-Aufgaben zu erledigen. Osquery wäre etwa völlig nutzlos, wenn es zwar fleißig Fehler und Warnungen in seine Logdatei schreibt, diese anschließend jedoch in den Untiefen eines ELK-Stacks (ElasticSearch, Logstash, Kibana) verschwänden. Wer Osquery also wirklich sinnvoll einsetzen möchte, kombiniert es idealerweise mit externen Werkzeugen.

Anbindung an andere Systeme: Prometheus

Dass das technisch durchaus möglich ist, beweist Christoph Oelmueller mit seinem Prometheus-Exporter für Osquery. Zur Erinnerung: Prometheus ist eine Zeitreihendatenbank, die ursprünglich SoundCloud entwickelt hat und die auf große, skalierbare Umgebungen spezialisiert ist. In freier Wildbahn ist Prometheus meist im Gespann mit Grafana unterwegs, was zu einer umfassenden Lösung für Monitoring, Alerting und Trending führt. Prometheus basiert auf einem Pull-Prinzip: Auf den einzelnen Servern laufen so genannte Exporter, die Monitoring-Daten für Prometheus sammeln. Der Prometheus-Server grast seine Monitoring-Ziele regelmäßig ab, verarbeitet die dort erhaltenen Metriken und speichert sie schließlich. Mit Grafana lassen sich aus diesen Daten sinnvolle Trending-Diagramme zeichnen. Obendrein hat Prometheus einen Alert-Manager: Verlassen die Werte für Parameter eines Tests die festgelegten Grenzen, produziert Prometheus selbst einen Alarm und leitet diesen an den hauseigenen Alert-Manager weiter. Der setzt die Eskalation in Gang.

Oelmueller hat in Form des Osquery-Exporters für Prometheus das Bindeglied zwischen Osquery und Prometheus geschaffen: Der Exporter nutzt auf den einzelnen Hosts "osqueryi" und führt Abfragen durch, die der Admin in der Konfiguration des Prometheus-Exporters definiert. Die erhaltenen Werte stellt der Exporter Prometheus in Form aufbereiteter Metriken zur Verfügung, sodass sie unmittelbar ins Monitoring wandern. Sie lassen sich sowohl für Trending-Kalkulationen als auch als Grundlage für in Prometheus ausgelöste Alarme nutzen.

Freilich hat dieser Ansatz auch Nachteile: Weil "osqueryi" sich die Daten aus "osqueryd" nicht zunutze macht, kann es einige Funktionen nicht nutzen. Hier bleibt abzuwarten, ob sich künftig noch ein Freiwilliger findet, um für die Logdateien von "osqueryd" ebenfalls einen Prometheus-Exporter zu bauen. Als Alternative dazu kommt möglicherweise der JSON-Exporter in Frage, den Yuto Kawamura veröffentlicht hat [5]. Er akzeptiert JSON-Eingaben auf der einen Seite und leitet sie auf der anderen Seite an Prometheus weiter. Eben weil die Logdatei von Osquery im JSON-Format vorliegt, sollte sich hier eine Verbindung herstellen lassen. Die Gelegenheit, das zu testen, hatte die IT-Administrator-Redaktion allerdings nicht.

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Loadtests ohne Server

Für Loadtests der eigenen Server bietet sich die Cloud an, denn kurz getaktet lassen sich dort viele Rechnerinstanzen starten, die das eigene Budget nur wenig belasten. Noch flexibler, günstiger und besser skalierbar sind Tests mit einer Serverless-Infrastruktur wie AWS Lambda. Wir führen vor, wie Sie dort mit Serverless Artillery eigene Loadtests starten. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018