Ein ganzes Netzwerk aus einer Textdatei.

Der sicherste Ort, um eine Netzwerkänderung auszuprobieren, ist nicht das Produktionsnetzwerk. Mit ContainerLab beschreiben Sie eine Topologie in einer kurzen Textdatei, fahren ein ganzes Netzwerk in Sekunden auf einem Laptop hoch, machen es kaputt, reparieren es und werfen es wieder weg. Es ist das Werkzeug, zu dem wir greifen, wann immer eine Änderung zu riskant ist, um sie in der Produktion zu testen, was in kritischen Netzwerken auf die meisten zutrifft.

Das ist eine Einführung. Am Ende wissen Sie, was ContainerLab ist, wie eine Lab-Datei aussieht, welche vier Befehle den ganzen Lebenszyklus steuern und wie wir damit einen digitalen Zwilling eines echten Netzwerks mit MikroTik- und OT-Geräten bauen. Wenn Sie lieber klicken als lesen: Unser OT-Security-Lab läuft im Browser, und Sie können mitmachen.

Was ContainerLab ist

ContainerLab ist ein Open-Source-Werkzeug, das Netzwerk-Labs auf Basis von Containern betreibt. Sie schreiben eine Topologie-Datei, es startet die Nodes, verbindet sie mit virtuellen Links und verwaltet ihren Lebenszyklus. Da die Nodes einfach Container sind, startet ein Lab in Sekunden und kostet nichts, wenn es nicht läuft.

Es unterscheidet drei Arten von Nodes. Containerisierte Netzwerk-Betriebssysteme laufen nativ. Klassische VM-basierte Systeme lassen sich über die vrnetlab-Integration containerisieren. Und jeder Linux-Container kann mitspielen, so fügen Sie Hosts, Server, Angreifer oder, in unserem Fall, simulierte PLCs hinzu.

Wie ein Lab aussieht

Ein Lab ist eine .clab.yml-Datei. Sie hat einen Namen, eine Menge von nodes und die links zwischen ihnen. Jeder Node hat einen Typ (das Feld kind), der ContainerLab sagt, wie er auszuführen ist. Hier eine gekürzte Version eines unserer eigenen Labs: eine MikroTik-Firewall und ein Switch, dazu ein simulierter PLC als Linux-Container.

Das ist die ganze Idee. Die nodes sind Ihre Geräte, die links sind die Kabel, und kind ist der einzige Kniff: Damit sitzen eine Nokia, eine Arista, eine Cisco, eine MikroTik und eine einfache Linux-Box in derselben Datei und verhalten sich wie das echte Gerät. Das Beispiel hier nutzt MikroTik, weil viel von unserer Arbeit darauf läuft, aber ContainerLab unterstützt einen langen Katalog von kinds, von Nokia, Arista, Cisco und Juniper bis zu Firewalls wie Fortinet und Palo Alto.

Vier Befehle, der ganze Lebenszyklus

Sobald die Datei existiert, müssen Sie sich kaum etwas merken. Einmal installieren, dann deployen, schauen, verbinden und zerstören.

ContainerLab trägt die Nodes in Ihre /etc/hosts ein, sodass Sie sie auch über den Namen erreichen, etwa ssh admin@clab-ot-sec-segmented-gw-firewall.

Gut zu wissen

Ein paar Dinge, die ContainerLab zum Lernen angenehm machen, jenseits der vier Befehle.

Warum wir darauf aufbauen: der digitale Zwilling

In einem kritischen Netzwerk können Sie eine Firewall-Änderung, ein Segmentierungs-Redesign oder einen Firmware-Rollout nicht testen, indem Sie es an der laufenden Anlage versuchen. Also bauen wir einen digitalen Zwilling: eine getreue Kopie des echten Netzwerks, die in ContainerLab läuft und gegen die wir planen, testen und validieren können, bevor eine einzige Änderung die Produktion berührt.

VM-basierte Geräte einbinden

Viele Netzwerk-Betriebssysteme, darunter Cisco, Juniper, Palo Alto und andere, werden als virtuelle Maschinen bereitgestellt. ContainerLab löst das über vrnetlab, das eine VM als Container verpackt, sodass sie sich wie jeder andere Node in der Topologie verhält. MikroTik ist hier unser konkretes Beispiel, weil viel von unserer Arbeit darauf läuft, und der Typ mikrotik_ros in der Datei oben ist genau das in Aktion.

Eines sollten Sie wissen: ContainerLab verwendet seinen eigenen erweiterten Fork des ursprünglichen vrnetlab (srl-labs/vrnetlab). Images, die mit dem Upstream-Projekt gebaut wurden, funktionieren nicht, bauen Sie also aus dem Fork.

Sobald die MikroTik-Nodes laufen, steuern wir ihre Konfiguration genauso wie die echten Boxen: mit Ansible. RouterOS hat keinen Python-Interpreter, also nutzen wir die community.routeros-Module über die API für strukturierte, idempotente Änderungen. Das ist die Brücke zwischen Zwilling und Produktion, und sie ist offen: Unsere ansible-mikrotik-Collection ist dieselbe, die wir auf Kundennetzwerken einsetzen.

Ein echtes Beispiel: das OT-Security-Lab

Um das konkret zu machen: Wir pflegen ein vollständiges OT-Netzwerk-Security-Lab in ContainerLab, gemeinsam mit SWITCH aufgebaut. Es ist ein realistisches Industrienetzwerk: MikroTik-Firewall und -Switches sowie simulierte PLCs von WAGO, Bosch Rexroth, Schneider und ABB mit einer Codesys-Runtime, verteilt über VLAN-Zonen für Hygiene, Prozess, Entsorgung und einen Leitstand.

Es kommt in zwei Ausprägungen aus demselben Repo. Eine flache Topologie, die unsichere Ausgangslage, in der alles mit allem reden kann, und eine segmentierte Topologie mit echten Zonen und einer Firewall dazwischen. Die eine gegen die andere zu tauschen ist eine Änderung von einem Wort auf der Kommandozeile, womit sich der Wert von Segmentierung zeigen statt beschreiben lässt.

clab deploy -t ot-sec-flat.clab.yml         # alles erreicht alles
clab deploy -t ot-sec-segmented.clab.yml    # Zonen, VLANs und eine Firewall

Auf dem Lab sitzt eine Reihe praktischer Übungen: VLAN-Discovery und Traffic-Analyse, ein ARP-Spoofing-Angriff, Spanning-Tree-Verhalten und mehr. Da das Ganze in GitHub Codespaces läuft, brauchen Teilnehmende nichts ausser einem Browser, um ein echtes Netzwerk vor sich zu haben, an dem sie wirklich experimentieren können. Dieses Lab ist das Rückgrat unserer OT-Security-Kurse.

Wie Sie heute starten

Zwei Wege, je nachdem, ob Sie etwas installieren möchten.

Häufige Fragen