Angriffe auf Umgebungen sind in der IT heute so alltäglich wie der Betrieb der IT-Infrastruktur selbst. Die Spanne der Angriffsarten ist dabei groß und hängt vom Ziel ab, das Ganoven erreichen wollen. Geht es um klassische Denial-of-Service-Attacken, ist der Angriff eher banal und ad hoc gut zu erkennen. Steht das Ausspähen von Daten im Vordergrund, sind die Methoden bereits deutlich subtiler. Hochkomplexe IT-Angriffe auf verschiedenen Ebenen zur selben Zeit sind längst keine große Herausforderung mehr für Straftäter.

So komplex die Angriffsszenarien auch sind – ein Faktor bleibt gleich: Der Administrator möchte so früh wie möglich merken, dass sich in seinem Setup sinistre Vorgänge abspielen, um zeitnah zu reagieren. Denn je früher ein Angriff auffällt, desto eher lässt sich aus Admin-Sicht gegensteuern und desto geringer bleibt der verursachte Schaden. Aber welche Mittel und Wege hat der Administrator, Angriffe frühzeitig zu erkennen?

Eine generelle Antwort auf diese Frage gibt es leider nicht. Tatsächlich hängt die Möglichkeit, einen Angriff früh zu erkennen, von den vorhandenen Werkzeugen und der Art und Weise ab, wie der Admin sie einsetzt. Früher verließen sich die meisten Admins auf banales Event-Monitoring mit Grenzwerten: Übersteigt die eingehende Datenmenge ein bestimmtes Limit, schlägt das Monitoring Alarm. Tauchen in den Authentifizierungs-Logdateien von Servern zu viele ungültige Login-Versuche auf, erhält der Admin hierüber ebenfalls eine Nachricht. Im Vordergrund steht dabei, den Verantwortlichen im konkreten Fall möglichst schnell handlungsfähig zu machen – ihm also zu vermitteln, wie die Lage aktuell aussieht.

Sonderlich up to date oder klug ist diese Vorgehensweise allerdings nicht. Moderne Monitoringsysteme wie Prometheus sammeln so viele Metrikdaten, dass sich aus ihnen Trends und Anomalien ablesen lassen, die auf bereits laufende Angriffe hindeuten können. Das gilt auch für die bereits beschriebenen DDoS-Angriffe: Sie funktionieren längst nicht mehr nach dem immer selben Prinzip, einen Server mit möglichst viel Traffic in möglichst kurzer Zeit offline zu nehmen. Regelmäßig stellt sich bei der Post-Mortem-Analyse von Angriffen stattdessen heraus, dass Angreifer in den Wochen vor einem Angriff den Traffic sukzessive erhöht haben, und zwar so, dass sie stets unter dem Radar der Grenzwerte im Monitoring flogen. Im entscheidenden Moment reicht dann ein relativ kleiner Peak beim Angriff, damit den Servern das sprichwörtliche Blech wegfliegt und sie kollabieren. Mit einer besseren Analyse des Trendings – etwa mithilfe von Prometheus – sind solche Attacken durchaus vorhersehbar.

Eine wichtige Rolle bei der Erkennung von Anomalien spielt der sogenannte Z-Score, ein Begriff aus der Statistik. Er erlaubt dem Admin eine Antwort auf die Frage, was im Kontext der jeweiligen Umgebung eine Anomalie ist. Große Infrastrukturen werden etwa bei einem DDoS deutlich höhere Schwellenwerte anlegen als Websites mit wenigen Zugriffen pro Tag. Aus Sicht des Admins besteht die Kunst bei der Erkennung von Anomalien nun also darin, einen zuverlässigen Mittelwert für einzelne Datenpunkte zu finden, um danach Grenzwerte zu definieren, innerhalb derer die aktuellen Messwerte von den Mittelwerten abweichen dürfen. Die lähmende Wirkung ständiger False Positives ist dabei nicht zu unterschätzen: Ein Monitoringsystem, das ständig grundlos alarmiert, nimmt früher oder später keiner mehr ernst. Statt der groben Keule kommt bei der Erkennung von Anomalien in Metrikdaten also das feine Sezierwerkzeug zum Einsatz. Und der Z-Score ist ein Musterbeispiel für ein besonders scharfes Skalpell.

Um zu verstehen, was er aussagt, ist ein kleiner Ausflug in die Mathematik von Carl Friedrich von Gauß unvermeidlich. Von der Gaußschen Normalverteilung haben wohl die meisten schon einmal gehört. Wer bereits ein paar Lenze auf dem Buckel hat, erinnert sich womöglich noch an die Zehn-D-Mark-Note, auf der Gauß samt seiner Theorie bildlich verewigt waren. Sehr vereinfacht formuliert besagt die Gaußsche Theorie, dass in einer beliebigen Anzahl von Messwerten die Extrema sehr selten vorkommen und der Median – also das 50. Perzentil – besonders häufig. Auf beiden Seiten der X-Achse nimmt die Anzahl der Treffer pro Wert bei Annäherung an den Median zu. Bei 100 Servern dürfte sich der Stromverbrauch der meisten Geräte rund um den Median bewegen, während es einzelne Maschinen gibt, die besonders viel oder besonders wenig Strom benötigen. Diese bilden die äußeren Extreme einer gedachten Zeichnung mit allen gemessenen Datenpunkten.

Bei der Errechnung des Z-Scores spielen Perzentile grundsätzlich eine wichtige Rolle. Existieren auf einer fiktiven Skala 0 bis 100 Messpunkte, geht es zunächst darum, den Median zu errechnen. Der Median ist das 50. Perzentil (50 Prozent aller Messwerte entsprechen diesem Wert). Um herauszufinden, wie weit ein einzelner Datenpunkt von eben diesem Median abweicht, kommt nun der Z-Score zum Einsatz: Er errechnet sich nach der Formel "Z-Score = (Wert - Median) / Standardabweichung". Letztere lässt sich wahlweise anhand generischer Werte festlegen oder einzeln bestimmen. Gängige Werte sind das 68. Perzentil für eine Abweichung von +/- 1 (68 von 100 Werten weichen um nicht weniger als 1 vom Median ab), das 95. Perzentil für eine Abweichung von +/- 2 sowie das 99,7 Perzentil für eine Abweichung von +/- 3.

Liegen 15 Messwerte bei einem Median on 2,6 zwischen 1 und 3, hätte der Datenpunkt "15" in diesem Beispiel eine Abweichung vom 99,97 Perzentil von 4,3 – der Z-Score entspricht eben dieser Zahl. Und genau darum geht es bei der automatischen Erkennung von Anomalien in der IT: Ausreißer bei den Metrikdaten zu erkennen und danach richtig zu interpretieren.

Nun stellt sich die Frage, wie der Admin vorgehen soll, um aus seinen Metrikdaten passende Warnungen zu generieren. Effektiv möglich ist das nur mit Zeitreihendatenbanken, wie etwa Prometheus eine ist. Prometheus sammelt die Metrikwerte von sogenannten "Exportern" auf den Zielsystemen und legt sie zentral ab. Mittels einer eigenen Query-Sprache lassen sich diese Daten auswerten. Grafana kann damit Prometheus-Daten zudem grafisch darstellen. Mithilfe seiner Alertmanager-Komponente generiert Prometheus Alarme, falls einzelne Metriken bestimmte Werte annehmen oder sich außerhalb definierter Grenzen befinden.

Die Antwort auf die Frage, wie Admins eine bestehende Prometheus-Installation für effektive Anomalienerkennung verwenden können, liefert Red Hat. Und der Anbieter wäre nicht Marktführer im Linux-Segment, würde er nicht gleich noch ein paar Buzzwords einbauen, etwa das der künstlichen Intelligenz. Unter dem Label "Prometheus Anomaly Detector", kurz PAD, arbeiten rote Hüte seit mehreren Jahren an einer Kombination verschiedener Softwarekomponenten, die Anomalien einerseits anhand von Bestandsdaten und andererseits anhand von maschinellem Lernen und Projektion erkennen sollen. Hierzu besteht PAD aus mehreren Komponenten.

Ein Blick unter die Haube zeigt, aus welchem Holz die Software geschnitzt ist. Zunächst: Red Hat geht grundsätzlich davon aus, dass Admins PAD als Komponente in OpenShift ausrollen werden – der Hersteller erzwingt solch ein Szenario aktuell aber nicht. Wer PAD einsetzen möchte, sollte aber jedenfalls eine bestehende Umgebung aus Prometheus, Alertmanager sowie Thanos – dazu gleich mehr – drumherum vorweisen können, denn dieses liefern die PAD-Entwickler aus verständlichen Gründen nicht mit. PAD will schließlich selbst kein Monitoringtool sein, sondern an bestehende Set-ups andocken. Im Kern ist PAD eine Python-Applikation, die zwei weitere Python-Bibliotheken einblendet, und zwar solche für KI und maschinelles Lernen: Fourier und Prophet.

Metrikdaten liegen in Prometheus als Zahlen vor – für die genaue Analyse aktueller Daten sowie der künftigen Entwicklung von Werten im Rahmen des maschinellen Lernens eignen sich sinoidale Kurven jedoch deutlich besser. Jeder Wert wird dabei in Form einer Frequenz dargestellt. Der Fourier-Algorithmus zeichnet für die Transformation zwischen den Welten verantwortlich: Er wandelt die Zahlen mittels Sinus und Cosinus in Frequenzsignale um, sodass hinterher für die Vorhersage brauchbare Basisdaten vorliegen. Dieser Vorgang heißt "Fast Fourier Transformation" und geht auf die Mathematiker JW Cooley und John Tukey zurück. Ganz neu ist das nicht: Die Idee zur Umwandlung in sinoidale Kurven kam den beiden Mathematikern bereits 1965. Das Verfahren gilt heute als Standardalgorithmus der modernen IT. Das Fourier-Modul in Python besitzt ein per AI trainierbares Modell, um die weitere Entwicklung eines bestehenden Graphen anhand historischer Werte zu prognostizieren.

Der andere Algorithmus, den PAD zur Erkennung von Anomalien einsetzt, stammt direkt aus der Feder des sozialen Netzwerks Facebook: Prophet (Bild 1) ist im direkten Vergleich mit Fourier deutlich komplexer, erlaubt im Gegenzug aber auch das Einpreisen von Faktoren wie etwa einer möglichen Saisonalität von Daten. Obendrein bezieht Prophet in seine Vorhersagen die Faktoren Jahr, Woche sowie Tag mit ein. In Summe ist die Datenlage, anhand derer Prophet laufende Datenströme analysiert, ihre Fortsetzung vorhersagt und gegebenenfalls Alarm schlägt, also viel größer.

Der aufmerksamen Leserschaft wird an dieser Stelle aufgefallen sein, dass PAD mit seinen beiden Implementierungen der Anomalienerkennung sogar deutlich weiter geht, als die eingangs beschriebene Analyse auf Basis tatsächlich gesammelter Metrikdaten. "Nicht früh, sondern früher merken, dass etwas nicht stimmt" ist die Devise: Sowohl Fourier als auch Prophet sind trainierbare KI-Modelle in PAD, die anhand bestehender Metrikdaten die Entwicklung der jeweiligen Metriken vorhersagen – und so bereits beim kleinsten Anzeichen von Anomalien eine Reaktion erlauben. Dem Admin fällt dabei die Aufgabe zu, die von Prophet oder Fourier errechneten Entwicklungen eines Metrikwerts mit dem Ist-Zustand zu vergleichen. Im Idealfall merkt der Admin also dank der trainierten Modelle im PAD sehr schnell, dass etwas Verdächtiges vor sich geht (Bild 2).

Die Prometheus-Entwickler haben ihr Werk von Anfang an so konzipiert, dass Hochverfügbarkeit im klassischen Sinne keine Rolle spielt. Stattdessen sollen Admins mehrere Instanzen von Prometheus gleichzeitig betreiben – weil das Abfragen von Metrikdaten von den Zielsystemen kaum Ressourcen bindet, führt das nicht zu höherer Last auf den überwachten Systemen. Fällt eine der laufenden Instanzen aus, hat der Admin, so die Idee, noch genug andere Instanzen, die er abfragen kann. Das ist auch der Grund, warum auf der Ebene des Alertmanagers eine umfassende Deduplizierung implementiert ist: Wenn 20 Instanzen einen Alarm ob des selben Metrikwerts in den Alertmanager speisen, versendet dieser trotzdem nur eine Nachricht an die Alarmierungsziele.

Dieser Anwendungsfall hat allerdings ein hässliches Loch beim Skalieren in die Breite. Gerade massiv skalierbare Umgebungen mit hunderten oder tausenden Hosts sorgen dafür, dass einzelne Prometheus-Instanzen mit der Zeit zum Nadelöhr werden. Nimmt der Admin ein manuelles Sharding vor, verliert er allerdings den zentralen Vorteil des "Single Point of Administration". Denn dann fragen einzelne Prometheus-Instanzen eine lokale Liste von Zielen ab, und der Admin muss sich mit der passenden Prometheus-Instanz verbinden, um die Metriken für einen bestimmten Host zu sehen. Mehr noch: Auch Grafana muss dann so konfiguriert sein und unterschiedliche Queries müssen die unterschiedlichen Datenquellen in Grafana nutzen.

Fast noch schlimmer allerdings: Prometheus gibt sich umso träger und langsamer, je mehr Daten in ihm lagern. Admins haben aber durchaus ein berechtigtes Interesse daran, historische Daten aufzubewahren. Denn die erlauben eine bessere Planung der Skalierbarkeit und ermöglichen es, Trends besser zu erkennen. Wenn in Prometheus allerdings zu viele alte Informationen liegen, dauern die Aufrufe einzelner Grafana-Dashboards bald mehrere Sekunden. Es fehlt also ein intelligentes Downsampling von Daten ebenso wie ein performanter Speicher für Archivdaten außerhalb von Prometheus selbst.

Thanos ist nun ein von Prometheus unabhängiges Projekt, das sich wie eine Art Klammer um mehrere autarke Prometheus-Instanzen legt. Zunächst bietet Thanos eine "Unified Query View": Ganz gleich also, welche der mit Thanos verbundenen Prometheus-Instanzen Metrikdaten für einen bestimmten Host enthält – der Admin redet immer mit Thanos, das sich im Hintergrund die Daten passend zusammensucht. Dasselbe gilt natürlich auch für Grafana-Instanzen.

Eine zweite Thanos-Komponente ist dafür zuständig, historische Daten mit Sinn und Verstand zu speichern. Hierfür bietet Thanos eine Schnittstelle hin zu einer eigenen Storage-Implementierung namens Store­API ebenso wie Schnittstellen zu anderen Datenbanken. Thanos stellt Prometheus dabei die Komponente Sidecar zur Verfügung, die Schreibvorgänge dynamisch nicht auf dem lokalen Prometheus-Speicher abwickelt, sondern im Netz verteilt. Das langfristige Speichern historischer Daten gelingt so viel besser, als käme Prometheus selbst dafür zum Einsatz.

Kurzum: Thanos ist eine ausgesprochen praktische Erweiterung zum reinen Prometheus, die in vielen Installationen weltweit Einzug gehalten hat. Dass die Prometheus Anomaly Detection sich Thanos zunutze macht, verwundert dabei kaum: Insbesondere das Speichern historischer Daten ist bei der Erkennung von Anomalien nämlich ausgesprochen hilfreich.

Red Hat macht es Systemverwaltern im Alltag recht leicht. Wie bereits erwähnt, ist PAD für den Einsatz in OpenShift konzipiert, der verfügbare Container läuft aber auch ohne Red Hats Orchestrierer ganz gut. Das folgende Beispiel geht davon aus, dass Admins "podman" für die Verwaltung ihrer Container verwenden. Zunächst beschafft der Admin sich also den fertigen PAD-Container, dessen Quellen darüber hinaus auf GitHub zur Verfügung stehen [1]. Das geht mit podman pull quay.io/aicoe/prometheus-anomaly-detector:latest". Danach steht der Bau der Kommandozeile auf dem Programm, die den Container passend startet. PAD bekommt die Metriken, für die es per Fourier und Prophet Anomalien erkennen soll, über Umgebungsvariablen. Und die wiederum lassen sich dem Container leicht mit auf den Weg geben. Das Kommando

startet den Container und legt als Metrik per "FLT_METRICS_LIST" "up" fest, also die Frage, ob Systeme verfügbar sind oder nicht. Hier setzt der Admin stattdessen die Namen der Metriken ein, für die er Anomalien erkennen möchte. Wer hier etwa die Metrik "node_filesystem_avail_bytes" des Prometheus Node Exporters einträgt, bringt PAD dazu, Veränderungen bei der Belegung von Speicherlaufwerken einzelner Geräte zu überwachen. Denn plötzlich ansteigender Platzbedarf (also sinkender freier Speicherplatz) kann bereits ein Indikator für sinistre Vorgänge sein, die einen genaueren Blick rechtfertigen.

PAD alleine hilft dem Administrator in der Regel nicht weiter, weil Prometheus die Daten grafisch nicht aufbereitet. Frei nach dem Motto "Schuster, bleib bei deinen Leisten!" sollte hierfür unbedingt Grafana zum Einsatz kommen – und die PAD-Entwickler machen ihren Admins genau das ganz leicht. Denn PAD exportiert die kalkulierten Metrikdaten selbst wieder im Prometheus-Format. Eine bestehende Prometheus-Instanz kann sie also aus PAD ablesen wie von jedem anderen Exporter auch. Hierfür setzen die Entwickler auf Flask.

Der Rest ist Schema F: Wenn die Metrikdaten mit ihren Vorhersagen erstmal in Prometheus vorhanden sind, lassen sich wie gewohnt Dashboards in Grafana dafür anlegen. Mehr noch: Die Vorhersagen von Fourier und Prophet lassen sich dann sogar in dieselben Dashboards integrieren und übereinanderlegen – bei Bedarf zusammen mit den aktuell tatsächlich gemessenen Werten (Bild 3). Und wer sogar Alarme auf Basis der Vorhersagen einrichten möchte, hat dazu im Alertmanager ganz normal die Möglichkeit. Ein als PDF erhältlicher Red-Hat-Vortrag aus dem Jahr 2019 [2] gibt Aufschluss über die Details der Konfiguration.

Administratoren belächeln Hersteller nicht selten, wenn diese vollmundig ihre KI- und AI-Lösungen zur Angriffserkennung präsentieren; nicht selten ist von Hokus Pokus die Rede. Red Hat stellt in Form von PAD einen ganz konkreten und sofort nutzbaren Ansatz vor, anhand von KI konkreten Mehrwert im Alltag zu schaffen. Je mehr Metrikdaten Fourier und Prophet zur Verfügung stehen, desto besser können diese ihr Modell trainieren und desto zuverlässiger werden die Vorhersagen. Etwas "Anlaufzeit" mit False Positives muss der Admin eingangs also einkalkulieren. Die Mühe macht sich aber spätestens bezahlt, wenn er mit dem Angreifer auf Augenhöhe ist, weil der Systemverwalter frühzeitig gemerkt hat, dass etwas nicht stimmt.