© Tom Wang / 123RF.com

Wer nicht fließend Ethernet spricht, ist bei der Fehlersuche im Netz auf Werkzeuge wie Iftop und Bwm angewiesen. In größeren Umgebungen hilft Skydive, die Übersicht zu behalten und komplexe Fehlerbilder aufzudecken.

Wenn Ihre IT-Landschaft wie in Abbildung 1 aussieht, brauchen Sie nicht unbedingt weiterzulesen. Fällt Ihre Infrastruktur allerdings deutlich größer aus, kann dieser Artikel dabei helfen, etwas mehr Übersicht in die Umgebung zu bringen, vor allem bei der Fehlersuche. Das Ziel ist eine grafische Darstellung der IT-Komponenten und ihres Zusammenspiels im Netzwerk. Das bezieht sich nicht auf die Verkabelung, sondern auf die Datenflüsse zwischen den Teilnehmern. Skydive speichert diese Informationen an zentraler Stelle und lässt sich per Weboberfläche, Kommandozeile und per API bedienen.

Abbildung 1: Anfangs kennt Skydive nur die Netzadapter des lokalen Systems.

Architektur

Skydive [1] besteht aus einem zentralen Analyzer und vielen Agenten. Letztere laufen auf Linux-Hosts und berichten die Netzwerkkonfiguration und Statistiken an den Analyzer (Abbildung 2). Der lauscht auf das Feedback seiner Agenten und merkt sich den Input in einer Datenbank. Nach und nach kennt der Analyzer die gesamte Topologie und die Verkehrsflüsse zwischen den Endgeräten. Der Admin erhält über die Weboberfläche des Analyzers Zugriff auf seine neue Skydive-Instanz.

Abbildung 2: Die Linux-Agenten liefern Zustände und Metriken an den Skydive-Analyzer.

Die Agenten fungieren als “dumme” Datenweiterleiter. Das Gehirn des Analyzers bildet eine NoSQL-Datenbank, wahlweise Elasticsearch oder OrientDB. Skydive skaliert horizontal: Ist ein Analyzer mit seinen Agenten ausgelastet, können weitere Analyzer einspringen und die nächsten Agenten bedienen. Die Analyzer befüllen dieselbe Datenbank mit Flow-Information und halten dabei über »etcd« ihre Konfiguration synchron.

Installation

Das Github-Repository von Skydive [2] stellt ein vorkompiliertes Binary bereit, das nach dem Download sofort einsatzbereit ist. Wer dieser Bequemlichkeit nicht traut, schnappt sich einen Build-Host mit Compiler und übersetzt den Code selbst (Listing 1).

# yum install go git make protobuf protobuf-c-compiler \
    npm patch libxml2-devel libvirt-devel libpcap-devel \
    protobuf-devel
# mkdir $HOME/go
# export GOPATH=$HOME/go
# export PATH=$GOPATH/bin:$PATH
# mkdir -p $GOPATH/src/github.com/skydive-project
# git clone https://github.com/skydive-project/skydive.git \
    $GOPATH/src/github.com/skydive-project/skydive
# cd $GOPATH/src/github.com/skydive-project/skydive
# make
# make install

Das Ergebnis ist eine ausführbare Datei, die je nach Aufruf als Analyzer oder als Agent arbeitet. Passende Service-Dateien für Systemd liegen im Verzeichnis »contrib/« des Repositorys. Die Einstellungen bezieht der Dienst aus einer Konfigurationsdatei im YAML-Format, die Linux-typisch unterhalb von »etc/« liegt.

Erste Gehversuche

Zum Kennenlernen von Skydive eignet sich das Szenario Allinone, das Agent und Analyzer auf demselben Host betreibt. Nach dem Aufruf von »skydive allinone« starten sogleich die beiden Komponenten und erkunden das Betriebssystem und die Netzadapter. Die Weboberfläche des Analyzers wartet unter http://localhost:8082 und ermöglicht ein gefahrloses Durchstöbern der neuen Umgebung – Sie kennen sie schon aus Abbildung 1.

Dieses Setup ist nichts als ein kurzer Flirt, denn nach einem Neustart der Software gehen alle Informationen und Einstellungen verloren: Der Analyzer hält diese Daten im Arbeitsspeicher und legt sie nicht persistent im Dateisystem ab.

Analyzer

Im produktiven Umfeld kann Skydive die erkundete Topologie und die Flow-Informationen in einer Elasticsearch-Datenbank einlagern. Übermäßige Anforderungen an den Datenbankserver stellt Skydive nicht. In einfachen Setups kann die Datenbank auf demselben Host laufen wie der Analyzer. In beiden Fällen muss Elasticsearch die Verbindungsversuche des Analyzers akzeptieren. Weitere Kenntnisse über Elasticsearch oder NoSQL braucht es nicht, Skydive nutzt die Datenbank eher als stummes Datensilo.

In der Beispielkonfiguration aus Listing 2 erfährt der Analyzer von seiner neuen Speichermöglichkeit in einem benachbarten Datenbanksystem. Wichtig ist zudem die Authentifizierung der Weboberfläche, da per Default der Webzugriff ohne Anmeldung gelingt. Das Beispiel nutzt die bescheidenen Möglichkeiten von Skydive und legt die Benutzerkonten in der Apache-typischen »htpasswd«-Datei ab. Für anspruchsvolle Umgebungen realisiert ein vorgeschalteter Reverse-Proxy nahezu beliebige Anmeldeszenarien.

analyzer:
  listen: 0.0.0.0:8082
  flow:
    backend: myelasticsearch
  topology:
    backend: myelasticsearch
  auth:
    api:
      backend: mybasic
storage:
  myelasticsearch:
    driver: elasticsearch
    host: 172.31.28.51:9200
    ssl_insecure: true
etcd:
  embedded: true
auth:
  mybasic:
    type: basic
    file: /etc/skydive/skydive.htpasswd

Wenn Firewalld die Netzzugriffe auf den Server kontrolliert, schaffen die Anweisungen aus Listing 3 eine Ausnahme für Skydive. Damit ist der Analyzer bereit für die Stille Post seiner Informanten und das wachsame Auge des Admins auf die Weboberfläche.

# firewall-cmd --permanent --add-port=8082/tcp
# firewall-cmd --reload

Agent

Der Skydive-Agent arbeitet als Informant, der als regulärer Linux-Dienst auf einem Server, in einer virtuellen Maschine oder in einem Container seine Ohren spitzt. Per Konfigurationsdatei erfährt der Agent, welche Protokolle und Systembereiche er überwachen soll und welcher Analyzer für ihn zuständig ist.

Für seine Entdeckungstour kann der Agent verschiedenste Topologien erkunden: Open vSwitch, Docker, OpenStack, Linux-Container, Libvirt, aber auch das klassische Nachbarschaftsprotokoll LLDP. Die Unterstützung von Libvirt öffnet die Tür für die Erkundung der großen Virtualisierungsplattformen wie KVM, Qemu, Xen und VMware ESXi. Wählen Sie aus der Liste der Topologien diejenigen aus, die Skydive erkunden soll.

Die Konfigurationsdatei im Repository enthält alle Direktiven mit Beispielen und Vorgabewerten. In der Voreinstellung nutzt der Agent nur Netlink und Netns, was die lokale Linux-Maschine im Analyzer wie in Abbildung 1 aussehen lässt. Die Konfigurationsdatei enthält nur die Angabe des Analyzers und fällt entsprechend aus:

analyzers:
  - analyzer.example.net:8082

Sobald der Agent gestartet ist, verschwindet er in den Hintergrund und kommuniziert mit seinem Analyzer. Die Beziehung besteht aus Geben und Nehmen: Der Agent erhält Arbeitsaufträge und liefert Informationen wie einen Steckbrief des Hosts, IPv4/v6-Adressen, die Auslastung der Netzadapter oder die ARP- und Routing-Tabelle.

Zugegeben: Dieselben Werte lassen sich auch mit den entsprechenden Linux-Befehlen ausfindig machen. Der Pluspunkt von Skydive liegt darin, dass die Infos aller Agenten bereitstehen, bevor die Fehlersuche losgeht. Die übermittelten Arbeitsanweisungen stammen letztendlich vom Bediener vor dem Bildschirm und lauten: Flows sammeln und Pakete einschleusen.

Flows sammeln

Bis hierhin hat Skydive noch nicht viel geleistet. Der bunte Topologiegraph bietet zwar eine schicke Übersicht der eigenen Netzwerkumgebung, hilft aber bei Problemen nicht wirklich weiter.

Kommen Verbindungen zwischen Endgeräten nicht zustande, steht das Netzwerk stets unter Generalverdacht. Die Netzwerker müssen die Blockade umgehend finden und damit das Problem lösen. Diese Herausforderung gestaltet sich noch komplexer, wenn die beteiligten Geräte zu unterschiedlichen Teams gehören. Hier kann Skydive unterstützen, auf den verdächtigen Hosts die Verkehrsflüsse aufzeichnen und sie im Analyzer auflisten. Wählen Sie dazu in der grafischen Webansicht das Icon eines betroffenen Netzadapters aus, und starten Sie im rechten Bereich die Funktion Packet Capture. Genau wie bei Wireshark und Tcpdump kann ein Capture-Filter gezielt Pakete herauspicken, die für die Ermittlung relevant sind.

Unbemerkt sammelt der Agent die Flussinformationen des gewünschten Netzadapters und sendet sie an seinen Herrn und Meister, der sie in der Elasticsearch-Datenbank parkt. Ein Blick in die Spalte Flows des Analyzers liefert die Liste aller gesichteten IP-Verbindungen (Abbildung 3). Der Datenbestand lässt sich mit dem Flow Query beliebig sortieren oder filtern. Taucht der gesuchte Flow in der Tabelle nicht auf, hat die Verbindungsanfrage diesen Host nicht erreicht, und die Fehlerursache muss näher bei der Quelle liegen.

Abbildung 3: Der Skydive-Agent meldet Verkehrsinformationen an den Analyzer.

Pakete einschleusen

Der Einblick in die Flussinformationen ist eine passive Beobachtung, die den Netzverkehr nicht verändert. Anders gestaltet sich die zweite Hauptaufgabe von Skydive, die neue Pakete formt und über einen beliebigen Agenten ins Netz injiziert. Auf diese Weise lässt sich prüfen, ob das Testpaket da ankommt, wo es ankommen soll.

Der Zusammenbau eines neuen Pakets erfolgt im Skydive-Analyzer bequem per Maus. In Abbildung 4 simuliert das generierte Paket einen Ping zwischen zwei Endgeräten. Die benötigten Quell- und Zieladressen müssen Sie dazu nicht händisch eintippen, sondern lediglich mit der Maus auf das jeweilige Netzsymbol der Topologieansicht klicken.

Abbildung 4: Skydive generiert IP-Pakete und sendet sie an gewünschter Stelle ins Netz.

Neben ICMP ermöglicht die Web-UI noch UDP- und TCP-Pakete, sowohl IPv4 als auch IPv6. Andere Kopfzeilen (etwa IPsec) oder komplexe Konstrukte bietet Skydive nicht an. Für einen Penetrationstest ist das ziemlich dürftig, aber für die Fehlersuche genügen die Möglichkeiten völlig.

Apropos Adressen: Der Skydive-Agent sendet das Paket exakt so, wie der Analyzer es ihm mitteilt. Verläuft die Kommunikation zwischen den beiden Endpunkten über ein Default-Gateway, muss die Ziel-MAC-Adresse in der Weboberfläche die des Gateways sein und nicht die des Zielsystems. Diese Eigenart stammt nicht von Skydive, sondern vom Ethernet-Protokoll.

Sobald das Paket auf seine Reise geht, lässt es sich von den passierten Switches und Routern nicht mehr von einem normalen Paket unterscheiden und trägt damit zur Fehlersuche bei.

Topologie erweitern

Freilich läuft der Skydive-Agent nicht auf jedem beliebigen Gerät im Netz. Zugangslose Switches und Windows-Server erhalten trotzdem ihren Platz in der Skydive-Oberfläche, denn die Topologie lässt sich erweitern, was die weißen Flecken entfernt.

Wenn zwischen Server A und Server B eine Verbindung besteht, die Skydive nicht erkannt hat, dann kommt der Menüpunkt Topology rules ins Spiel. Die Topologie unterscheidet zwischen Nodes und Edges. Die Begriffe stammen aus der Graphentheorie und bezeichnen die Knotenpunkte eines Graphen sowie dessen Kanten als Verbindungslinien zwischen den Knoten. Skydive verwendet den Begriff Node nicht nur für Netzteilnehmer, sondern auch für deren Komponenten. Beispielsweise hat der Knoten Server eine Kante zum Knoten »eth0«, der seinen eigenen Netzadapter bezeichnet.

Ein neuer Knoten benötigt bei Skydive einen Namen und einen Typ. Anschließend taucht in der Topologieansicht ein losgelöstes Icon auf, das den neuen Teilnehmer darstellt. Eine neue Kante benötigt die Identifier beider Knoten, die sie verbinden soll. Genau wie beim Packet Capture lassen sich die geplanten Endpunkte der Kante per Maus markieren. Zusätzlich dazu benötigt jede Kante einen frei wählbaren Typ wie beispielsweise Layer**2 für eine Ethernet-Verbindung.

Skydive setzt den Verbindungen keine Grenzen. Die Kante von »eth0« muss nicht zu einem anderen Netzadapter führen, sondern kann auch bei einem Block-Device enden. Die flexible Topologie von Skydive bietet damit eine Basis für Dokumentation und Visualisierung. Für die massenhafte Erweiterung eignet sich die Kommandozeile besser, die Thema des nächsten Abschnitts ist.

Kommandozeile

Wer bei der Fehlersuche auf Klicki-Bunti verzichten möchte, weicht auf die Kommandozeile aus. Der Skydive-Client kommuniziert mit dem Analyzer und präsentiert seine Ergebnisse im Konsolenfenster. Ein zusätzliches Programm braucht man dazu nicht, da der Client ins Skydive-Binary integriert ist. Ob der Client sich mit seinem Analyzer unterhalten kann, prüft die eine einfache Statusabfrage (Listing 4, erste Zeile).

# skydive client status
# skydive client query G
# skydive client query "G.V().Has('Name', 'sd0181')"

Laufen Client und Analyzer nicht auf demselben Server, benötigt der Client in seinem Kommandoaufruf per Option »–analyzer« die IP-Adresse oder den Host-Namen seines Gegenübers. Bei einem erfolgreichen Kontakt füllt sich die Anzeige mit Informationen zu den verbundenen Agenten, formatiert im JSON-Format.

Beim Zugriff auf den gesamten Topologiebaum (Listing 4, zweite Zeile) gibt sich Skydive nicht wortkarg und berichtet jedes Detail zu jeder Kante und zu jedem Knoten. Sinnvoller ist eine gezielte Abfrage, die nur das liefert, was man wissen möchte. Als Abfragesprache benutzt Skydive das auch in anderen Graphdatenbanken vertretene Gremlin. Ein Beispiel für die Frage nach einem bestimmten Knoten zeigt die letzte Zeile von Listing 4.

Ein bisschen Grundwissen in Gremlin ist nötig, um Verbindungslinien im Graph per Kommandozeile anzulegen. Der Unterbefehl lautet dazu nicht »query« sondern »edge-rule create«. In Listing 5 entstehen zwei Nodes sowie eine verbindende Edge zwischen ihnen.

# skydive client node-rule create --node-name="RT-1" \
  --node-type="host" --action="create"
{
  "Name": "",
  "Description": "",
  "Metadata": {
    "Name": "RT-1",
    "Type": "host"
  },
  "Action": "create",
  "Query": "",
  "UUID": "f2043100-434b-426f-7edc-0382f15d788b"
}
# skydive client node-rule create --node-name="RT-2" \
  --node-type="host" --action="create"
{
  "Name": "",
  "Description": "",
  "Metadata": {
    "Name": "RT-2",
    "Type": "host"
  },
  "Action": "create",
  "Query": "",
  "UUID": "a8b59b62-2da7-4532-4ac6-6f94fc898553"
}
# skydive client edge-rule create \
  --src="G.V().Has('Name', 'RT-1')" \
  --dst="G.V().Has('Name', 'RT-2')" \
  --relationtype="layer2" \
  --metadata="key=value"
{
  "Name": "",
  "Description": "",
  "Src": "G.V().Has('Name', 'RT-1')",
  "Dst": "G.V().Has('Name', 'RT-2')",
  "Metadata": {
    "RelationType": "layer2",
    "key": "value"
  },
  "UUID": "1a429d13-025f-405c-740a-b4bf24bb2763"
}

Unter der Haube greift der Skydive-Client auf die API des Analyzers zu. Bei der Programmierschnittstelle handelt es sich um eine reguläre, per Swagger ausführlich dokumentierte REST-API [2]. Der Zugriff beschränkt sich nicht auf den Skydive Client, sondern klappt auch mit den üblichen HTTP-Clients Curl, Wget und Httpie. Die Suche nach dem Knoten im Graphen aus dem vorherigen Absatz erledigt Httpie mit einer Gremlin-Abfrage (Listing 6).

http POST https://skydive.analyzer:8082/api/topology GremlinQuery="G.V().Has('Name', 'sd0181')"

Sicherheit

In der Voreinstellung kommuniziert Skydive unverschlüsselt. Für ein kleines Testszenario mag das genügen, doch ein seriöses Setup schreit nach Verschlüsselung. Skydive verwendet X.509-Zertifikate, um die Kommunikation zwischen Analyzer und seinen Agenten zu sichern.

Die Variante mit Pre-shared Keys bietet Skydive nicht an, es müssen also Zertifikate und eine Zertifizierungsstelle her. Der Weg vom Schlüsselpaar zum Zertifikat funktioniert genau wie bei einem Webserver oder bei OpenVPN. Der Analyzer erfährt von seinem Kryptomaterial per Konfigurationsdatei (Listing 7):

tls:
  ca_cert: /etc/ssl/certs/ca-skydive.crt
  server_cert: /etc/ssl/certs/analyzer.crt
  server_key:  /etc/ssl/certs/analyzer.key
# und beim Agenten zusätzlich:
  client_cert: /etc/ssl/certs/client1.crt
  client_key:  /etc/ssl/certs/client1.key

Der Skydive Agent erhält noch zusätzliche Zeilen, die das Client-Zertifikat benennen. Grundsätzlich benötigt jeder Agent ein eigenes Zertifikat. Allerdings mault Skydive auch nicht, wenn sich die Agenten ein Zertifikat teilen.

Die Verschlüsselung beginnt, sobald die Teilnehmer mit Zertifikaten ausgestattet sind, die Konfigurationsdatei darauf hinweist und der Dienst neu gestartet wurde. Damit wechselt auch der Webzugriff auf den Analyzer von HTTP zu HTTPS. Die Addons des nächsten Abschnitts müssen jetzt ebenfalls den Analyzer per TLS ansprechen und sollten das Server-Zertifikat prüfen.

Liegt der Datenbestand in einer externen Datenbank, dann müssen die Zugriffe auch abgesichert erfolgen. Elasticsearch hat sein eigenes »certutil«-Tool, das sich um die Schlüssel und Zertifikate kümmert. Dazu kommt noch die Authentifizierung mit Benutzername und Kennwort. Auf der Seite von Skydive erweitert sich die Konfiguration um die Anmeldeinformationen für die Datenbank (Listing 8).

storage: client_cert: /etc/ssl/certs/client1.crt
  client_key:  /etc/ssl/certs/client1.key
  myelasticsearch:
    ssl_insecure: false
    auth:
      username: skydive
      password: uMr8Fv30bX

Müssen mehrere Skydive-Analyzer ihren Datenbestand synchron halten und verwenden dazu die Key-Value-Datenbank Etcd, sollte auch hier das notwendige Maß an Sicherheit herrschen. Etcd unterstützt zwar Zertifikate und eine Benutzeranmeldung, aber Skydive nutzt lediglich die TLS-Verschlüsselung. Hier müssen andere Mechanismen die fehlende Authentifizierung ersetzen, beispielsweise Iptables-Regeln oder ein vorgeschalteter Reverse-Proxy.

Anschluss

Als offene Plattform vermag Skydive mit anderen Monitoring-Systemen zusammenzuspielen. Beispielsweise kann die Visualisierungslösung Grafana über eine zusätzliche Datenquelle die gesammelte Topologie von Skydive anzapfen und in einem Dashboard grafisch darstellen. Den Code für die Datenquelle spendiert Skydive in seinem Github-Repository [3]. Damit Grafana an die gewünschten Inhalte gelangt, muss die Abfrage in der Gremlin-Syntax erfolgen. In Abbildung 5 holt sich Grafana die Anzahl der gleichzeitigen IP-Verbindungen und stellt sie in einem Zeit-Serien-Graphen dar.

Abbildung 5: Grafana nutzt Skydive als Datenquelle und visualisiert die Topologie.

Für den Kontakt mit weiteren Monitoring-Lösungen bietet Skydive Plugins an. Die Liste fällt (noch) recht überschaubar aus, neben Grafana stehen nur Prometheus und Collectd auf dem Programm. Über den Prometheus-Connector stellt der Skydive-Analyzer Metriken zur Verfügung, die der Prometheus-Server einsammelt und weiterverarbeitet. Bei Collectd läuft es umgekehrt: Collectd liefert, der Skydive-Agent konsumiert.

Falls Skydive die von Ihnen verwendete Monitoring-Software nicht unterstützt, bleiben nur zwei Auswege: ein eigenes Plugin schreiben oder mit Curl/Wget die API anzapfen.

Ausblick

Das Besondere an Skydive sind nicht die bunten Icons der Topologieansicht, die bei jedem Klick kreisförmig über den Bildschirm ziehen. Der Datenschatz besteht aus den Verbindungsdaten, die die Agenten im Capture-Modus sammeln und an den Analyzer berichten. Diese Informationen kann Skydive aufbereiten und auswerten. Die Arbeit macht der Analyzer nicht selbst, sondern spannt dafür weitere Tools ein.

Das Addon Skydive Flow Matrix bereitet IP-Verbindungen auf, die jene Hosts erzeugen, auf denen ein Agent läuft. Die resultierende Liste enthält Protokoll, Quell- und Zieladresse, Port-Nummern und die Adresse des Servers, der die Verbindung angenommen hat. Wem die kommaseparierte Auflistung zu langweilig erscheint, der kann die Daten auch als Graphviz-Diagramm oder Circos-Ring bewundern.

Ein weiteres Addon bietet weniger Eye Candy, erweist sich dafür aber nützlich für die Sicherheit: Der Security Advisor erhält kontinuierlich Flow-Informationen vom Analyzer und untersucht, filtert, verändert und speichert die Resultate. Die Ergebnisse lassen sich beispielsweise in Amazon S3 ablegen und als Flow-Logs mit den Methoden von AWS auswerten.

Fazit

Genauso, wie ein Fallschirmspringer die schöne Landschaft unter sich bewundert, kann Skydive das Netzwerk überblicken. Die Informationen stammen von den Skydive-Agenten, die auf Linux-Servern Daten sammeln und an einen zentralen Skydive-Analyzer berichten. Dort informiert sich der Admin per Weboberfläche oder Kommandozeile über das Netzwerk, untersucht einzelne Datenströme und schleust bei Bedarf sogar selbst definierte Pakete ein. Der Mehrwert von Skydive liegt im ganzheitlichen Ansatz, der die bekannten Netzkomponenten in Form eines Graphen darstellt und Zusammenhänge visualisiert. (jcb)