Webseiten, Server und ganze Netzwerke mit der Enginsight Suite analysieren und überwachen (2018)

Über

Meinen Blog gibt es nun schon seit fast 10 Jahren, verrückte Sache. Und obwohl ich grob über 300 Tutorials und How-To’s geschrieben habe, ist es wie so oft: Der Schuster hat gerne mal die schlechtesten Leisten. Wartung und Pflege des eigenen Systems geraten bei viel Stress und wenig freier Zeit in den Hintergrund. So kommt es, dass mich die Firma Enginsight letztens kontaktiert hat. Der Inhalt war ein weniger positiv – man übergab mir einen Sicherheitsbericht meines Blogs. Dieser enthielt Bewertungen in mehreren Kategorien und leider nicht nur gute, dazu später mehr. Das war der Anlass, dass ich mich mit der Sicherheits-Suite von Enginsight und der Sicherheit meines Blogs detaillierter auseinandergesetzt habe.

Erster Eindruck

Die Suite von Enginsight möchte mit ihren Tools die Sicherheit und Verfügbarkeit von IT-Netzwerken erhöhen und den Aufwand der Wartung und Überwachung verringern. Das Netzwerk kann hier beliebig verschieden und groß sein – von 1 Webseite, einem PC oder Server bis hin zu einem aus mehreren Nodes und Netzwerkkomponenten bestehenden Netzwerk.

Dank des 14-tägigen Probeaccounts lässt sich die Suite auch direkt selbst ausprobieren. Nach dem Login lande ich auf einem sehr übersichtlichen Dashboard, in dem mir meine eingerichteten Assets (in diesem Moment natürlich noch keine) angezeigt werden. Über eine Menüleiste habe ich schnellen Zugriff auf die wichtigsten Funktionen: Umgebungen, Hosts, Endpunkte, Alarme, Einstellungen, Suche, mein Profil sowie einigen weiteren Kleinigkeiten.

webseiten-netzwerke-analysieren-kontrollieren-enginsight-suite-dashboard
Übersichtliches Enginsight Dashboard mit ersten angelegten Assets

Detaillierte Analysen

Ich habe hier direkt meinen Blog als einen Endpunkt angelegt. Endpunkte sind Webseiten oder Webapplikationen, für die verschiedene Funktionen zur Verfügung gestellt werden: Webseite (Verfügbarkeitstests aus EU/USA), SSL/TLS, Web Thread Intelligence, Portscan, HTTP-Headers und Redirects. Die Funktionen können flexibel hinzugefügt werden. Anschließend starten direkt die ausgewählten Untersuchungen auf das eingegebene Ziel und nur wenige Sekunden später erhalte ich eine ausführliche Analyse meiner Seite:

Schnell ist klar: Hier muss was gemacht werden! Ich gehe mal kurz die Features durch und was jeweils untersucht wird:

  • Webseite: Stündliche Verfügbarkeitstests von Servern aus Frankfurt (EU) oder East-Virginia (USA), Analyse der Verbindungszeiten (wieviel Millisekunden Lookup, Connect, Transfer usw.)
  • HTTP-Headers: Analyse der Antwort-Header-Eigenschaften und speziell der Security-Header. Dazu mehr im Kapitel weiter unten
  • SSL/TLS: Untersuchung des verwendeten SSL-Zertifikats, der unterstützten Protokolle und Chiffren sowie möglicher Sicherheitslücken bzgl. SSL
  • Redirects: Weiterleitungen der Domain
  • Web Threat Intelligence: Prüfung von Sicherheitslücken beim Server, benutzten Anwendungen, der Webseite, benutzter Frameworks und Errechnung eines Scores
  • Portscan: Offene Ports und deren Service, ggf. Informationen zu eingesetzter Software und Version hinter einem Port

Bei der dauerhaften Verwendung von externen Dienstleistern, vor allem wenn (personenbezogene) Daten der eigenen Plattform dort verarbeitet werden, müsst ihr darauf achten, das Verzeichnis von Verarbeitungstätigkeiten zu ergänzen. Ansonsten wäre das im worst-case ein Datenschutzverstoß.

Ein Bericht hat mir dabei besonders wenig gefallen: Die Bewertung F bei den HTTP-Header. Also habe ich hier mal einen detaillierteren Blick geworfen:

Crashkurs HTTP-Headers

HTTP-Header sind Anweisungen, die vom Server- oder Webseitenbetreiber konfiguriert werden, um die Sicherheit des Webangebots sowie der Besucher zu erhöhen
Die Anweisungen können, je nach Hosting Setup, recht einfach über die .htaccess (empfohlen beim Shared Webhosting) gesetzt werden.
Im folgenden nenne ich zwei beispielhafte Security-Header, es gibt jedoch noch mehr:

HTTP Strict Transport Security (HSTS)

HSTS gibt vor, dass und für welchen Zeitraum in der Zukunft alle Anfragen über HTTPS/SSL vom Client zum Server geschickt werden müssen. Anfragen über HTTP werden innerhalb dieses Zeitfensters dann komplett geblockt. Eine Beispielkonfiguration wäre:

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>

Anzupassen: max-age als Zeitangabe in Sekunden, wie lange der Zugriff in Zukunft für diesen gerade aufrufenden Client ausschließlich über SSL erfolgen muss. Der Wert 31536000 steht demnach für 1 Jahr. includeSubDomains erweitert dieses Verfahren auf alle Subdomains. Weitere Informationen und Details zu HSTS und die preload-Eigenschaft in meinem separaten Artikel zum Thema HSTS und XSS-Protection hier.

Content-Security-Policy (CSP)

Der Content-Security-Policy Header überprüft die Art und Herkunft von Daten und Anfragen während des Ladens und kann darauf reagieren. Damit wird verhindert, dass unerwünschte, fremde oder gefährliche Inhalte geladen und ausgeführt werden. Das ist für gewöhnlich das Ziel von XSS-Angriffen und Code-Injections, schädliche Inhalte in vertrauenswürdige Seiten einzubinden.

Die Kontrolle der Inhalte wird hierbei in unterschiedliche Kategorien (auch Direktiven genannt) aufgeteilt und jeweils können erlaubte Datenquellen definiert werden. Beispielsweise gibt die Direktive script-src an, von welchen Domains und Quellen Skripte in die geschützte Seite eingebunden werden dürfen. Ein CSP-Beispiel:

Header always set Content-Security-Policy: "default-src 'self'; img-src 'self' https://secure.gravatar.com https://wordpress.org data:; script-src 'self'; font-src 'self' fonts.gstatic.com; report-uri https://report-uri.de/report.php"

Diese CSP definiert erlaubte Datenquellen für die Direktiven default-src, img-src, script-srcfont-src und definiert einen Bericht-Endpunkt mit report-uri. Die Angabe ’self‘ erlaubt Daten von der eigenen Domain, in der die CSP benutzt wird. Zusätzlich wurden für Bilder die Domains von gravatar.com und wordpress.org sowie die Einbindung von data-uri Bildern als Ausnahmen definiert. Ebenso das Laden von Schriften vom Google Repository. Wenn ein Angreifer nun versucht, beispielsweise über einen Kommentar ein Skript von seiner Angreiferdomain einzubetten, würde die CSP dies blocken, da nur die eigene Domain Skripte einbinden darf.

Mehr zum Aufbau und Einrichtung des CSP Header in meinem Artikel zu diesem Thema hier.

Sicherheit von Hosts auch mit Künstlicher Intelligenz überwachen

Zurück zur Enginsight-Suite, denn hier gibt es noch viel mehr zu entdecken! Aus Gründen der Komplexität reiße ich die folgenden Features nur grob an.

Wie eingangs erwähnt, lassen sich auch Computer und Server in das System einfügen und durchleuchten. Dafür wird ein Client auf den Geräten eingerichtet und schon werden etliche Systemkomponenten untersucht: Auslastung von CPU, RAM, SWAP, integrierte Partitionen, Netzwerkschnittstellen, installierte Software und Updates sowie laufende Prozesse. Daran erkennt Enginsight dann mögliche Sicherheitsrisiken und gibt Handlungsempfehlungen.

Außerdem wacht eine auf Neuralen Netzwerken basierende Künstliche Intelligenz über die erfassten Daten. Auf Wunsch erkennt diese beispielsweise wenn personenbezogene Daten das Netzwerk verlassen oder bestimmte Metriken wie CPU oder RAM ihre Normalwerte verlassen. Basierend auf den gelernten Daten erkennt die KI Anomalien und alarmiert den Admin. Dieser kann den Vorfall dann einstufen und die KI lernt für zukünftig Entscheidung aus diesem Handeln. Somit wird die KI immer intelligenter und der Admin hat weniger Verwaltungsaufwand.

Im Peacemaker werden die Systemupdates aller angelegten Hosts in einer Übersicht angezeigt und können direkt verwaltet werden. So lassen sich beispielsweise unter Linux Updates direkt aus Enginsight heraus installieren.

Unter dem Menüpunkt Umgebung versteckt sich ein Visualisierungstool, mit dem die angelegten Assets miteinander in Verbindung gebracht werden können. Außerdem lassen sich hier auch Notizen oder ganze Dokumentationen für jedes Asset hinzufügen. So fehlt nie der Überblick bei komplexen Infrastrukturen.

Automatisierung über Alarme und Plugins

Zwei weitere Funktionen lassen sich gut kombinieren, um eine Automatisierung von Maßnahmen im Problemfall zu realisieren: 
Alarme können erstellt werden, um regelmäßige Überprüfungen durchzuführen und im Problemfall Maßnahmen zu ergreifen. Mögliche Überwachungen bei einem Endpunkt: Response Time, Tage bis Zertifikatsablauf, Webseite nicht erreichebar, Neue Sicherheitslücke, Datenschutzverstoß. Für Hosts gibt es noch mehr, hier nur ein paar: Temperatur, neue oder entfernte Programme, Verdächtiger Netzwerkverkehr. Natürlich lassen sich hier Benachrichtigungen einstellen, aber als besonderes Extra gibt es auch Plugins, die im Problemfall ausgeführt werden können.

Plugins sind im Skripte, die selbst geschrieben werden können. Zur Verfügung stehen die drei Sprachen: Bash, Powershell und Python. Plugins können per Cronjob regelmäßig ausgeführt oder eben von Alarmen getriggert werden. Dem Troubleshooting sind mit diesen drei Sprachen kaum Grenzen gesetzt. Beispielsweise könnten per SSH im Falle des Ausfalls bestimmter Webseiten die Netzwerksettings vom Server geändert oder repariert werden.

Fazit

Die Enginsight-Suite bietet eine große Palette an Sicherheits- und Überwachungsfeatures (nicht alle konnte ich in diesem Artikel vorstellen), mit denen sich einzelne Assets oder ganze Netzwerke analysieren und steuern lassen können. Dank KI-Metrik-Überwachung, Alarmen, Plugins und anderen kombinierbaren Lösungen ist hier eine großes Potential für Automatisierung, wenn alles richtig eingerichtet wird. Das Produkt ist immernoch stark in der Entwicklung und der Kontakt zum Enginsight-Team war äußerst angenehm – hier steckt viel Herzblut im Produkt. 

1 Kommentar

  1. Spannend, ein Scanning-Anbieter, der wenigstens mal Preise öffentlich angibt und nicht nur auf Anfrage. Schade nur, dass die Definition von „Asset“ ziemlich schwammig ist. Einen Host mit mehreren Webseiten zu scannen scheint wesentlich teurer zu sein, als einen Host mit irgendwelchen anderen Services, da der Host als 1 Asset zählt und jede einzelne Webseite dann nochmal als je 1 Asset. Andere Anbieter lösen das intelligenter, indem sie wenigstens die Assetdefinition an IP-Adressen festmachen.

    Bei dem Agent wäre ich wiederum eher vorsichtig. Es gibt auf der Webseite keine Beschreibung, wie er genau funktioniert. Sammelt er autonom „nur“ Daten und sendet sie an den Server oder kann er Befehle vom Server erhalten und diese ausführen? Man weiß es nicht.

Schreibe einen Kommentar