infrastructure

Lab-Rückblick: weniger blinde Flecken, bessere Rückwege

Was das Lab seit dem Sommer im Alltag belastbarer macht: vollständigere Logs, Langzeitmetriken, überprüfbare Verfügbarkeitsziele und verschlüsselte Off-site-Backups bei Cloudflare R2. Ein Rückblick auf Betrieb, Updates und Wiederherstellung.

Seit dem letzten größeren Lab-Rückblick hat sich vor allem der Betrieb weiterentwickelt. Damals waren bessere Beobachtbarkeit, mehrschichtige Backups und weniger Handarbeit an den Übergängen zwischen Systemen noch offene Aufgaben. Inzwischen erfasst die Logsammlung auch die Control Plane, Backups verlassen die Ausfalldomäne des Clusters, und externe Checks überwachen das Monitoring selbst.

Daneben kamen neue Dienste hinzu. In diesem Rückblick geht es aber vor allem um die Änderungen, die das Lab im Alltag belastbarer machen. Grundlage ist die öffentliche Lab-Konfiguration Anfang Oktober 2026.

fabric: Eine Machbarkeitsstudie für ein selbstheilendes P2P-Mesh

Wie finden sich Knoten, wenn Adressen wechseln, Verbindungen abbrechen und kein zentraler Dienst die Topologie kennt? fabric ist meine Forschungsplattform für Peer-Discovery, Route-Healing, mehrstufige Transportwege und klar begrenztes Vertrauen. Dieser Beitrag beschreibt, was bereits funktioniert, wo die Selbstheilung heute endet und warum gerade diese Grenze interessant ist.

Ein Mesh ist auf dem Whiteboard immer gesund. Ein paar Kreise, einige Linien dazwischen, vielleicht noch eine Wolke für „das Internet“ — fertig ist das dezentrale Netz. Interessant wird es, wenn die ersten Linien verschwinden: Ein Knoten zieht um, eine Adresse ist nur aus einem privaten Netz erreichbar oder UDP fällt plötzlich aus. Dann muss sich zeigen, ob die Teilnehmer noch einen Weg zum Ziel finden.

Genau dort beginnt fabric. Das Projekt untersucht, ob wenige, bewusst begrenzte Bausteine für ein Peer-to-Peer-Netz genügen, das neue Teilnehmer sicher aufnimmt und seine Nachbarn selbst entdeckt. Es soll indirekte Wege lernen und veraltete Routen wieder überprüfen. Dabei geht es nicht um ein fertiges Produkt, das jedes kaputte Netz repariert, sondern um eine Machbarkeitsstudie für Discovery und Auto-Healing. Sie ist ausführbar und testbar und gibt auch dort Einblick, wo die Mechanismen noch nicht ausreichen.

wisp: eine Reverse-Shell über DNS — und warum das Protokoll immer noch ein Sicherheitsproblem ist

DNS als C2-Kanal ist kein Relikt: dnscat2 stammt aus den 2010ern, aber das Grundproblem — fast jedes Netz lässt DNS raus — ist ungelöst. wisp ist eine Machbarkeitsstudie in Rust, die das Konzept auf modernen Stand bringt: E2E-verschlüsselte Reverse-Shell über DNS, X25519/Ed25519/ChaCha20-Poly1305, Forward Secrecy, Wordlist-Encoding statt Base32, DoH-CDN-Egress — und ein Bootstrap-Modell ohne jemals geliefertes PSK: jedes gestempelte Binary trägt sein eigenes Token, das beim ersten Frame verbraucht wird. Dazu `!get`-Exfiltration über denselben Tunnel, ein IRC-Betreiberkanal über Tor, daemonisierte Linux-Clients (fork+setsid, Self-Delete), Dead-Drop-Schlafmodus mit `!sleep`/`!wake`, A-Record-Transport zur S3-Mimikry, System-Introspektion (!top, !ps, !netstat) und Session-Management mit !alias, !note, !attach und !wipe. Ein Vergleich mit dnscat2 — und konkrete SNORT-Regeln, mit denen ein SOC genau solche Tunnel aufspürt.

DNS ist das Protokoll, das jeder Firewall durchlässt. Nicht aus Konfigurationsfehler, sondern aus Notwendigkeit: Ohne Namensauflösung funktioniert in einem modernen Netz schlicht nichts — also bleibt Port 53/udp offen, fast immer sowohl Richtung des rekursiven Resolvers des Hauses als auch, häufig genug, Richtung beliebiger öffentlicher Resolver im Internet. Genau das ist der Spalt, durch den sich Exfiltration und Command-and-Control seit drei Jahrzehnten quetschen. dnscat2 hat das 2014 vorgemacht; das Tool ist in die Jahre gekommen, das Prinzip nicht.

Dieser Beitrag stellt wisp (ursprünglich dc - für dnscat) vor — ein Projekt, das ich als Machbarkeitsstudie gebaut habe, um zwei Dinge zu zeigen: erstens, dass ein modernes, kryptografisch hartes DNS-Tunnel-Tool heute ohne viel Aufwand möglich ist, und zweitens — und das ist mir mindestens genauso wichtig —, dass die Verteidigungsseite das nur erkennt, wenn sie es aktiv sucht. wisp ist zugleich Angriffs-POC und Argument für DNS-Firewalling, Response-Rate-Limiting, Egress-Filtering freier Resolver und DoH-Blocking. Wer nur eines davon macht, verliert schon. Zur Reverse-Shell kommt eine !get-Exfiltration über denselben E2E-Kanal — und ein Bootstrap-Modell, das kein PSK jemals ausliefert: jedes gestempelte Binary trägt sein eigenes Token, das beim ersten Frame verbraucht wird.

POC — nur für autorisierte Systeme. wisp ist eine Machbarkeitsstudie für Security-Research und autorisierte Red-Team-Demonstrationen. Es darf ausschließlich in Netzen und an Systemen betrieben werden, die man selbst besitzt oder für die man ausdrücklich autorisiert ist. Unerlaubter Einsatz ist illegal. E2E verschlüsselt den Inhalt des Tunnels, nicht seine Existenz — wer einen solchen Kanal aufbaut, erzeugt messbaren DNS-Verkehr, und genau dieser Verkehr ist, wie der zweite Teil des Beitrags zeigt, erkennbar.

Tor als CRD: ein eigener Operator statt Sidecar-Bastelei

Warum ich den inoffiziellen tor-controller durch einen eigenen, in Rust geschriebenen Operator ersetzt habe — ein gemeinsamer Tor-Daemon pro Namespace, Onion-Services und Onion-Proxies dynamisch über den Control-Port, plus kuratierte obfs4-Bridges

Tor-Konnektivität im Cluster hatte ich bisher zusammengesteckt: pro Pod ein client-only tor plus ein oder zwei socat-Sidecars, die lokale TCP-Ports in Onion-Services übersetzten — genau das Setup, das ich im IRC-Bouncer-Beitrag beschrieben habe. Das funktioniert, skaliert aber nicht als Muster: Jeder Workload, der eine .onion erreichen oder selbst eine anbieten wollte, brachte seinen eigenen Tor-Prozess und seine eigene Klebeschicht mit. Also habe ich das Ganze zu dem gemacht, was es im Lab sein sollte: einer Custom Resource. tor-operator ist ein eigener, in Rust geschriebener Kubernetes-Operator, der Tor-Konnektivität in beide Richtungen als CRD anbietet.

Schluss mit geratenen Resource-Requests — VPA und Goldilocks im Recommend-Only-Modus

Auf vier ARM-Boards ist jedes Mebibyte gezählt — trotzdem habe ich CPU- und Memory-Requests jahrelang aus dem Bauch gesetzt. Der Vertical Pod Autoscaler beobachtet jetzt den echten Verbrauch und schreibt Empfehlungen, Goldilocks macht sie als Dashboard lesbar. Bewusst nur als Ratgeber: VPA fasst keinen einzigen Pod von selbst an.

Resource-Requests und -Limits habe ich in meinem Lab lange so gesetzt, wie man es eben macht: ein paar Werte aus dem Bauch, 100m/128Mi als Reflex, und dann nie wieder angefasst. Auf einer dicken Cloud ist das egal. Auf vier RK1-Boards mit endlichem ARM-Speicher ist es das nicht: Setze ich zu hoch, verschenke ich Kapazität, die kein anderer Pod mehr bekommt, weil der Scheduler den Request reserviert, nicht den Verbrauch. Setze ich zu niedrig, holt mir der OOM-Killer nachts einen Pod ab oder die CPU wird in den Boden gethrottlet. Beides hatte ich. Was mir fehlte, war kein Gefühl, sondern eine Zahl.