Ein containerisiertes Netzwerklabor für Cybersecurity-Studenten. Moderne Datacenter-Architektur (Spine-Leaf mit eBGP), zwei Angreifer-Clients (Kali Linux) und ein absichtlich verwundbarer Zielserver.
┌─────────────────────────┐
│ Spine Layer │
│ │
AS65001│ │AS65002 │
[spine1]─────────────[spine2] │
lo: 10.0.0.1 lo: 10.0.0.2 │
└──────────────────────────┘
/ \ / \
10.1.1/31 / \ 10.1.2/31 / 10.1.4/31
10.1.3/31 / \ / \
/ \ / \
┌─────────────────────────────────────────────────────────┐
│ Leaf Layer │
│ │
│ AS65101 AS65201 │
│ [leaf1] [leaf2] │
│ lo: 10.0.1.1 lo: 10.0.1.2 │
└─────────────────────────────────────────────────────────┘
/ \ \
10.10.10/30 10.10.20/30 10.20.10/30
/ \ \
[client1] [client2] [server]
10.10.10.2 10.10.20.2 10.20.10.2
(Kali Linux) (Kali Linux) (Ubuntu 22.04)
Attacker Attacker Target
| Gerät | ASN | Loopback | Peers |
|---|---|---|---|
| spine1 | 65001 | 10.0.0.1 | leaf1, leaf2, spine2 |
| spine2 | 65002 | 10.0.0.2 | leaf1, leaf2, spine1 |
| leaf1 | 65101 | 10.0.1.1 | spine1, spine2 |
| leaf2 | 65201 | 10.0.1.2 | spine1, spine2 |
| Link | Spine-IP | Leaf-IP |
|---|---|---|
| spine1 ↔ leaf1 | 10.1.1.0/31 | 10.1.1.1/31 |
| spine1 ↔ leaf2 | 10.1.2.0/31 | 10.1.2.1/31 |
| spine2 ↔ leaf1 | 10.1.3.0/31 | 10.1.3.1/31 |
| spine2 ↔ leaf2 | 10.1.4.0/31 | 10.1.4.1/31 |
| spine1 ↔ spine2 | 10.0.10.0/31 | 10.0.10.1/31 |
| Subnetz | Gateway | Host | Gerät |
|---|---|---|---|
| 10.10.10.0/30 | 10.10.10.1 | 10.10.10.2 | client1 |
| 10.10.20.0/30 | 10.10.20.1 | 10.10.20.2 | client2 |
| 10.20.10.0/30 | 10.20.10.1 | 10.20.10.2 | server |
| Host-Port | Container-Port | Dienst |
|---|---|---|
| 8080 | 80 | Nginx (HTTP) |
| 2222 | 22 | SSH |
# Docker
curl -fsSL https://get.docker.com | sh
# Containerlab (v0.45+)
bash -c "$(curl -sL https://get.containerlab.dev)"
# Prüfen
containerlab version
docker --versionContainerlab läuft nicht nativ auf macOS und benötigt eine Linux-VM (Docker und einige Linux-Kernel-Features wie netlink sind zwingend erforderlich). Empfohlener Weg über OrbStack:
# 1. OrbStack installieren
brew install --cask orbstack
# 2. Linux-VM erstellen (arm64 auf Apple Silicon, amd64 auf Intel)
orbctl create rocky clab-vm
# 3. In die VM einloggen
orb -m clab-vm
# 4. Docker + Containerlab in der VM installieren (Quick-Setup-Script)
curl -sL https://containerlab.dev/setup | sudo -E bash -s "all"Das Repo ist in der VM automatisch unter /mnt/mac/Users/<macos-user>/... erreichbar (OrbStack mountet den macOS-Host standardmäßig) — kein zusätzliches File-Sharing-Setup nötig.
Details und Alternativen (Devcontainer, andere Docker-Distributionen, ARM64-Image-Kompatibilität): containerlab.dev/macos
Fürs Lesen/Bearbeiten der Doku und paralleles Arbeiten auf den Clients liegt eine fertige, repo-lokale Neovim-Config bei:
./scripts/nvim-lab.shDetails und Tastenkombinationen: docs/neovim.md
cd spine-leaf-hacklab
sudo containerlab deploy -t topology.clab.ymlContainerlab zieht alle Images (Kali, Ubuntu, FRR) automatisch. Erster Start dauert je nach Internetgeschwindigkeit 2–10 Minuten.
docker exec -it clab-hacklab-server bash /server-setup.shDieser Befehl installiert SSH, Nginx, vsftpd und legt schwache Credentials an.
# Angreifer-Client 1
docker exec -it clab-hacklab-client1 bash
# Angreifer-Client 2
docker exec -it clab-hacklab-client2 bash
# Zielserver
docker exec -it clab-hacklab-server bash
# Switch-CLI (FRR vtysh)
docker exec -it clab-hacklab-leaf1 vtysh
docker exec -it clab-hacklab-spine1 vtyshDie minimalen Images haben kein iproute2 vorinstalliert. Das Init-Script (configs/clients/init.sh) installiert es automatisch beim ersten Start — dauert ~5 Sekunden. Danach läuft alles.
Falls du Netzwerkprobleme siehst, prüfe die Container-Logs:
docker logs clab-hacklab-client1sudo containerlab destroy -t topology.clab.ymlMit --cleanup werden auch die Netzwerk-Namespaces entfernt:
sudo containerlab destroy -t topology.clab.yml --cleanupdocker exec -it clab-hacklab-spine1 vtyshspine1# show bgp summary
spine1# show bgp ipv4 unicast
spine1# show ip route
spine1# show bfd peers
docker exec -it clab-hacklab-client1 bash
# Gateway erreichbar?
ping 10.10.10.1
# Server erreichbar? (cross-fabric)
ping 10.20.10.2
# Traceroute durch das Fabric
traceroute 10.20.10.2Erwartet: 10.10.10.1 (leaf1) → 10.1.x.x (spine) → 10.1.x.x (leaf2) → 10.20.10.2
Ziel: Verstehen wie man ein unbekanntes Netz kartiert.
# Von client1:
apt update && apt install -y nmap
# Host-Discovery im Server-Subnetz
nmap -sn 10.20.10.0/30
# Port-Scan auf Server
nmap -sV -p- 10.20.10.2
# OS-Detection
nmap -O 10.20.10.2
# Aggressive Scan
nmap -A 10.20.10.2Was lernt man: Unterschied zwischen Host-Discovery und Port-Scanning, was -sV (Version Detection) bedeutet.
Ziel: Verborgene Verzeichnisse und Informationen auf einem Webserver finden.
# Von client1:
apt install -y gobuster curl
# robots.txt lesen
curl http://10.20.10.2/robots.txt
# Verzeichnis-Brute-Force
gobuster dir -u http://10.20.10.2 -w /usr/share/wordlists/dirb/common.txt
# Backup-Datei lesen
curl http://10.20.10.2/backup/config.txtWas lernt man: Information Disclosure, Bedeutung von robots.txt, Directory Traversal Grundlagen.
Ziel: Schwache Passwörter mit Hydra angreifen.
# Von client1:
apt install -y hydra
# Passwort-Liste vorbereiten
echo -e "password\nalice123\ntoor\n123456\nadmin" > /tmp/pass.txt
echo -e "root\nalice\nbob\nadmin" > /tmp/users.txt
# Brute-Force
hydra -L /tmp/users.txt -P /tmp/pass.txt ssh://10.20.10.2
# Login testen
ssh alice@10.20.10.2Was lernt man: Warum starke Passwörter wichtig sind, wie Brute-Force-Angriffe funktionieren, wie man fail2ban später einsetzen würde.
Ziel: Anonymen FTP-Zugang ausnutzen und Dateien extrahieren.
# Von client1:
apt install -y ftp
# Anonymer Login
ftp 10.20.10.2
# User: anonymous, Passwort: (leer)
ftp> ls
ftp> cd pub
ftp> get notes.txt
ftp> bye
cat notes.txtWas lernt man: Risiken von Anonymous FTP, Credential-Leaks in Dateien.
Ziel: Unverschlüsselten Traffic auf einem Switch mitschneiden.
# Auf leaf1 (dem Switch):
docker exec -it clab-hacklab-leaf1 tcpdump -i eth3 -w /tmp/capture.pcap
# Gleichzeitig von client1 HTTP-Request senden:
docker exec -it clab-hacklab-client1 curl http://10.20.10.2
# Capture stoppen (Ctrl+C) und lesen:
docker exec -it clab-hacklab-leaf1 tcpdump -r /tmp/capture.pcap -AWas lernt man: Wie Switches Traffic sehen, warum HTTPS wichtig ist, Grundlagen der Paketanalyse.
Ziel: Verstehen wie Traffic durch das Spine-Leaf-Fabric fließt.
# Routing-Tabelle auf leaf1
docker exec -it clab-hacklab-leaf1 vtysh -c "show ip route"
# Welchen Weg nimmt ein Paket?
docker exec -it clab-hacklab-client1 traceroute 10.20.10.2
# BGP-Peers anzeigen
docker exec -it clab-hacklab-spine1 vtysh -c "show bgp summary"
# Was passiert wenn spine1 ausfällt?
docker stop clab-hacklab-spine1
docker exec -it clab-hacklab-client1 traceroute 10.20.10.2
docker start clab-hacklab-spine1Was lernt man: Redundanz durch mehrere Pfade, BGP-Konvergenz, ECMP.
Ziel: ARP-Poisoning im selben Subnetz simulieren.
client1 und client2 sind in verschiedenen /30-Subnetzen – für echtes ARP-Spoofing bräuchtest du sie im selben L2-Segment. Diese Übung zeigt warum Subnetz-Trennung schützt.
# Von client1: ARP-Cache ansehen
docker exec -it clab-hacklab-client1 apt install -y arpwatch net-tools
docker exec -it clab-hacklab-client1 arp -n
# Versuch ARP-Spoof gegen Gateway (leaf1)
docker exec -it clab-hacklab-client1 apt install -y dsniff
docker exec -it clab-hacklab-client1 arpspoof -i eth1 -t 10.10.10.1 10.20.10.2Was lernt man: Grenzen von ARP-Spoofing, warum /30-Subnetze schützen, DAI (Dynamic ARP Inspection).
Kali Rolling hat kein Tool vorinstalliert (minimales Image). Tools bei Bedarf installieren:
docker exec -it clab-hacklab-client1 bash
apt update
apt install -y nmap hydra gobuster sqlmap nikto netcat-openbsd tcpdump \
wireshark-common dnsutils curl wget python3 gitFür das volle Kali-Metapaket (3+ GB):
apt install -y kali-linux-defaultspine-leaf-hacklab/
├── topology.clab.yml # Containerlab Topologie
├── configs/
│ ├── frr-daemons # FRR Daemon-Konfiguration (geteilt)
│ ├── spine1/frr.conf # BGP-Konfiguration Spine1 (AS 65001)
│ ├── spine2/frr.conf # BGP-Konfiguration Spine2 (AS 65002)
│ ├── leaf1/frr.conf # BGP-Konfiguration Leaf1 (AS 65101)
│ └── leaf2/frr.conf # BGP-Konfiguration Leaf2 (AS 65201)
└── scripts/
└── server-setup.sh # Dienste auf dem Server installieren
| Aufgabe | Befehl |
|---|---|
| Lab starten | sudo containerlab deploy -t topology.clab.yml |
| Lab stoppen | sudo containerlab destroy -t topology.clab.yml --cleanup |
| Status anzeigen | sudo containerlab inspect -t topology.clab.yml |
| In Container | docker exec -it clab-hacklab-<name> bash |
| FRR CLI | docker exec -it clab-hacklab-<switch> vtysh |
| BGP-Status | vtysh -c "show bgp summary" |
| Routing-Tabelle | vtysh -c "show ip route" |
| Interfaces anzeigen | vtysh -c "show interface brief" |
| BFD-Peers | vtysh -c "show bfd peers" |
| Logs eines Containers | docker logs clab-hacklab-<name> |
| Traffic mitschneiden | docker exec clab-hacklab-leaf1 tcpdump -i eth3 |
| Server von außen (HTTP) | curl http://localhost:8080 |
| Server von außen (SSH) | ssh -p 2222 root@localhost |
- VLAN + VXLAN: Overlay-Netzwerk über das BGP-Fabric legen
- Vulnerable Container:
vulhub-Images einbinden (Log4Shell, Shellshock, …) - IDS/IPS: Snort oder Suricata auf einem dedizierten Node
- Firewall: nftables-Regeln auf den Leaf-Switches
- IPv6: Dual-Stack BGP konfigurieren
- Route Reflector: iBGP mit RR statt eBGP testen
Disclaimer: Dieses Lab ist ausschließlich für Lernzwecke in einer isolierten Umgebung gedacht. Alle schwachen Credentials und Konfigurationen sind absichtlich gesetzt. Niemals auf produktive Systeme oder fremde Netzwerke anwenden.