Worum geht’s?

Inspiriert hat mich Jan mit seinem Artikel: Er betreibt einen Snowflake-Proxy auf seiner Synology. Das wollte ich auch machen – allerdings nicht auf einem NAS, sondern als eigene VM mit Docker, mit eigener Firewall-Zone und mit Logs in meinem Grafana.

Kurz zur Einordnung: Tor ist ein Anonymisierungsnetz, das Verbindungen über mehrere Stationen leitet. In vielen Ländern sind die bekannten Tor-Server gesperrt. Hier kommt Snowflake ins Spiel: Freiwillige betreiben kleine Proxys, die zensierten Nutzern als Sprungbrett zu einer Tor-Brücke dienen. Die Verbindung läuft per WebRTC (dieselbe Technik wie bei Videocalls im Browser) und sieht damit für Zensoren ziemlich unauffällig aus. Weil die Proxys ständig kommen und gehen, lassen sie sich kaum alle sperren – daher der Name: Schneeflocken.

Wichtig, weil das oft verwechselt wird: Ein Snowflake-Proxy ist kein Exit-Knoten. Er leitet nur verschlüsselten Tor-Verkehr zwischen Nutzer und Brücke weiter. Er sieht weder, welche Seiten jemand aufruft, noch tritt meine IP-Adresse als Absender irgendwelcher Anfragen ins Internet auf. Und er braucht keine Portweiterleitung – alles läuft ausgehend.

Container auf dem Docker-Host – oder doch nicht?

Mein erster Plan war simpel: ein weiterer Container auf meinem Docker-Host. Der läuft eh, da passt noch einer drauf.

Beim zweiten Nachdenken hat mir das nicht mehr gefallen. Auf demselben Host laufen Dienste wie mein Passwort-Manager. Der Snowflake-Proxy redet den ganzen Tag mit fremden Rechnern im Internet. Selbst wenn das Risiko klein ist: Ich will nicht, dass sich so ein Dienst Kernel und Netz mit meinen sensibelsten Daten teilt. Und im Server-Netz kann ich ihm auf der Firewall keine eigenen Regeln geben.

Also habe ich mich für eine kleine eigene VM in der DMZ entschieden. Die DMZ hatte ich schon für meinen Honeypot gebaut – und nach dessen Ende wieder abgerissen. Jetzt bekommt sie ein zweites Leben, diesmal mit einem deutlich friedlicheren Bewohner.

Voraussetzungen

• Hypervisor: Proxmox VE 9
• VM: 2 vCPU, 1 GB RAM (ohne Ballooning), 16 GB Platte
• Betriebssystem: Debian 13 netinst, nur SSH-Server und Standard-Werkzeuge
• Docker: Docker Engine 29 mit Compose v5 aus dem offiziellen Docker-Repository
• Snowflake: offizielles Image thetorproject/snowflake-proxy
• Firewall: FortiGate mit FortiOS 7.6, eigenes VLAN als DMZ
• Logging: Grafana, Loki und Grafana Alloy (als Syslog-Empfänger) in einem eigenen LXC-Container

Umsetzung

Schritt 1: Die DMZ wiederbeleben

Die DMZ ist ein eigenes VLAN mit eigenem Netz. Im Beispiel nenne ich es 10.0.99.0/24, das Gateway ist die FortiGate auf .254, die VM bekommt 10.0.99.10.

Ein Detail, über das ich gestolpert bin: Beim Rückbau des Honeypots hatte ich das VLAN auch im UniFi-Controller gelöscht. Ohne das Netz dort lassen die Switches das VLAN nicht durch – die VM hätte also ins Leere gefunkt. Also zuerst das VLAN im Controller wieder anlegen (reines VLAN, ohne DHCP und ohne Gateway, das macht ja die FortiGate).

Die Regeln auf der FortiGate, sinngemäß:

Drei Details dazu:

• Die Sperrregel nach innen zielt nicht auf eine Liste von Interfaces, sondern auf alle privaten Adressbereiche (RFC 1918) über beliebige Interfaces. Lege ich später ein neues VLAN an, ist es automatisch gesperrt. Beim Honeypot musste ich die Regel noch bei jedem neuen Netz anfassen.
• Kein Application Control auf der Internet-Regel. Mein Standardprofil blockt die Kategorie „Proxy“ – und ein Snowflake-Proxy ist nun mal genau das.
• Meine Sperrliste für bekannte Bedrohungen (inklusive Tor-Knoten aus der Fortinet-Datenbank) gilt auch für die DMZ. Snowflake stört sie nicht: Der Proxy spricht mit dem Broker per HTTPS und mit den Nutzern per WebRTC, nicht mit klassischen Tor-Relays. In den Logs gab es dort nach dem Start keinen einzigen Treffer aus der DMZ.

Zum Logging auf der Internet-Regel kommt unten noch eine eigene Geschichte.

Schritt 2: Eine kleine, harte Debian-VM

Die VM ist schnell angelegt. Debian per netinst, im Installer nur „SSH-Server“ und „Standard-Systemwerkzeuge“, feste IP, öffentliche DNS-Server.

Kleine Falle: Ich hatte im Installer ein Root-Passwort gesetzt. Dann installiert Debian kein sudo. Also einmal per su - nachholen und den Root-Zugang danach sperren:

su -
apt install sudo
usermod -aG sudo <DEIN_USER>
passwd -l root

Für SSH gibt es eine eigene Datei mit den Härtungsregeln, nachdem der eigene Schlüssel per ssh-copy-id auf der VM liegt:

sudo tee /etc/ssh/sshd_config.d/00-hardening.conf >/dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowUsers <DEIN_USER>
EOF
sudo sshd -t && sudo systemctl reload ssh

Wichtig: Eine zweite SSH-Sitzung offen lassen, bis der Login mit Schlüssel in einer neuen Sitzung klappt. Sonst sperrt man sich bei einem Tippfehler selbst aus.

Dazu unattended-upgrades für Sicherheitsupdates und, bevor Docker draufkommt, ein Proxmox-Snapshot. Dann gibt es einen sauberen Rückweg.

Noch ein Klassiker: Auf meinem Laptop lag für die IP-Adresse der VM noch ein SSH-Host-Key – vom Honeypot. Genauer gesagt vom SSH-Honeypot auf Port 22. SSH hat sich zu Recht lautstark beschwert. ssh-keygen -R 10.0.99.10 entfernt den alten Eintrag; den neuen Fingerprint habe ich an der Proxmox-Konsole verglichen, bevor ich ihn akzeptiert habe.

Schritt 3: Docker – mit der Lehre vom letzten Mal

Docker kommt aus dem offiziellen Repository. Bevor der erste Container startet, bekommt Docker einen eigenen Adressbereich:

{ "default-address-pools": [ { "base": "172.16.0.0/12", "size": 24 } ] }

Das gehört nach /etc/docker/daemon.json. Beim Honeypot hatte mir Docker mit seinem Standard-Pool aus 192.168.x.0/20 ein Netz angelegt, das mein Client-Netz überdeckte – mit dem Ergebnis, dass die VM mir nicht mehr antwortete. Das passiert mir kein zweites Mal.

Schritt 4: Der Proxy selbst

Der ganze Stack ist eine einzige Compose-Datei, bei mir unter /opt/stacks/snowflake/compose.yaml:

services:
  snowflake-proxy:
    image: thetorproject/snowflake-proxy:latest
    container_name: snowflake-proxy
    network_mode: host
    restart: unless-stopped
    command: ["-capacity", "10", "-summary-interval", "1h"]
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    logging:
      driver: syslog
      options:
        syslog-address: "tcp://10.0.20.20:1514"
        syslog-format: "rfc5424"
        tag: "snowflake"
        mode: "non-blocking"

Was die Zeilen tun:

• network_mode: host empfiehlt das Tor-Projekt selbst. WebRTC braucht viele wechselnde UDP-Ports, und hinter Dockers eigenem NAT funktioniert das deutlich schlechter. Weil die VM nichts anderes macht und in einer eigenen DMZ steht, finde ich das hier unbedenklich.
• -capacity 10 begrenzt den Proxy auf zehn gleichzeitige Nutzer. Ohne die Option nimmt er so viele, wie kommen. Ich wollte erst einmal sehen, was das mit meinem Upload macht.
• -summary-interval 1h sorgt dafür, dass der Proxy einmal pro Stunde eine Zusammenfassung ins Log schreibt. Daraus baue ich später das Dashboard.
• read_only, cap_drop: ALL, no-new-privileges nehmen dem Container alles, was er nicht braucht. Er läuft damit problemlos.
• Logging per Syslog direkt an Alloy auf meinem Log-Server. non-blocking heißt: Ist der Log-Server mal weg, läuft der Proxy trotzdem weiter.

Was hier bewusst fehlt: -verbose und -unsafe-logging. Standardmäßig entfernt der Proxy IP-Adressen aus seinen Logs. Mit -unsafe-logging würde er sie mitschreiben. Genau das will ich nicht.

cd /opt/stacks/snowflake
sudo docker compose up -d
sudo docker logs -f snowflake-proxy

Nach dem Start meldet der Proxy, dass er läuft, und welchen NAT-Typ er erkannt hat. Bei mir steht da „moderate“ – ganz ohne Portfreigabe. Das reicht, damit der Broker ihm Nutzer zuteilt.

Schritt 5: Die Logging-Falle – oder: Wer loggt hier eigentlich wen?

Jetzt der Teil, der mich am meisten beschäftigt hat. Mein Ziel war von Anfang an: keine Verbindungsdaten. Ich will sehen, ob und wie viel der Proxy genutzt wird – nicht von wem.

Den Proxy selbst hatte ich dafür richtig eingestellt. Die Firewall aber nicht. Die Internet-Regel der DMZ stand anfangs, wie meine anderen Regeln auch, auf „alle Verbindungen loggen“. Als ich im Grafana nachsah, ob schon etwas passiert, sah ich: jede Menge UDP-Sitzungen von der VM zu fremden IP-Adressen. Das waren die Nutzer. Ihre IP-Adressen landeten also für 30 Tage in meinem Loki.

Für einen Dienst, der Menschen vor Überwachung schützen soll, ist das ziemlich genau das Gegenteil vom Ziel. Also habe ich die Regel umgestellt:

config firewall policy
    edit <POLICY-ID>
        set logtraffic utm
    next
end

Mit utm loggt die FortiGate nur noch Sicherheitsereignisse – also wenn Virenscanner, Web-Filter oder IPS anschlagen –, aber keine normalen Verbindungen mehr. Die Sicherheit geht dabei nicht verloren: Die Sperrregel nach innen loggt weiter jeden Versuch, und die Bedrohungs-Sperrliste ebenfalls. Was der Proxy tut, sehe ich ab jetzt nur noch aus seiner eigenen Zusammenfassung. Die Einträge der ersten Minuten laufen nach den 30 Tagen von allein aus Loki heraus.

Mein Learning daraus: Datensparsamkeit muss man an jeder Stelle der Kette prüfen, nicht nur in der Anwendung. Die Firewall ist auch ein Logger.

Schritt 6: Alloy bringt die Logs in Form

Die Logs kommen per Syslog bei Alloy an und landen in Loki mit den Labels host="snowflake" und app="snowflake". Ein Schönheitsfehler: Docker schickt alles, was der Container auf stderr schreibt, mit Schweregrad „error“. Der Snowflake-Proxy schreibt sein ganzes Log auf stderr. Im Grafana war also jede harmlose Statuszeile ein roter Fehler.

Abhilfe schafft eine zusätzliche Relabel-Regel in der Alloy-Konfiguration, hinter der Regel, die normalerweise den Schweregrad setzt:

rule {
  source_labels = ["__syslog_message_app_name"]
  regex         = "snowflake"
  target_label  = "level"
  replacement   = "info"
}

Fallstrick am Rande: Nach dem Neustart von Alloy hat der Syslog-Treiber von Docker die Verbindung nicht von selbst wieder aufgebaut. Erst ein Neustart des Containers brachte die Logs zurück. Wer Alloy neu startet, sollte also kurz prüfen, ob die Docker-Logs noch ankommen.

Schritt 7: Ein Dashboard, das zählt, ohne mitzuschreiben

Einmal pro Stunde schreibt der Proxy eine Zeile wie diese:

In the last 1h0m0s, there were 7 completed successful connections. Traffic Relayed ↓ 52310 KB (14.53 KB/s), ↑ 8124 KB (2.26 KB/s).

Die Zahlen sind ein Beispiel, das Format stimmt. Mehr braucht es nicht. Mit LogQL lassen sich die Werte aus der Zeile herausziehen und aufsummieren. Die Verbindungen im gewählten Zeitraum:

sum(
  sum_over_time(
    {app="snowflake"} |= "completed"
      | regexp `there were (?P<conns>\d+) completed( successful)? connections`
      | unwrap conns [$__range]
  )
)

Das ( successful)? ist kein Zufall: Meine erste Version des Ausdrucks suchte nach „completed connections“ – in der echten Zeile steht aber „completed successful connections“. Mit dem optionalen Teil passt beides.

Nach demselben Muster entstehen die Panels für die weitergeleiteten Daten (↓ (?P<down>\d+) KB und ↑ (?P<up>\d+) KB), ein Verlauf pro Stunde und das Datenvolumen pro Tag. Dazu kommen ein paar Panels aus den Firewall-Logs: Treffer auf der Sperrregel nach innen und auf der Bedrohungs-Sperrliste. Beide sollten im Normalbetrieb bei null stehen. Steht dort plötzlich etwas, will ich das sehen.

So sieht das Ganze nach knapp einer Woche aus:

Die Firewall-Panels darunter habe ich für den Screenshot weggelassen. Und weil man es im kleinen Bild schlecht erkennt, hier noch einmal das Datenvolumen pro Tag. Jeder Balken endet um Mitternacht, steht also für den Tag davor:

Kleine Randnotiz: Beim ersten Versuch begann die y-Achse dieses Panels nicht bei null, sondern bei gut einem Gigabyte. Dadurch sahen die Unterschiede zwischen den Tagen viel dramatischer aus, als sie waren. Wer Balkendiagramme baut: Soft min 0 setzen.

Ein kurioser Treffer auf der Sperrregel

Ganz bei null blieb die Sperrregel nach innen dann doch nicht. Am ersten Tag zeigte das Dashboard 29 Treffer. Sechs davon war ich selbst: mein Sperrtest beim Einrichten, bei dem ich aus der VM bewusst versucht habe, Dienste im Heimnetz zu erreichen. Die Regel hat gemacht, was sie soll.

Die anderen 23 waren spannender. Alle innerhalb von nicht einmal einer Sekunde, alle UDP, alle an dieselbe private Adresse aus dem Bereich 172.17.x.x – eine Adresse, die es bei mir gar nicht gibt. Vier verschiedene lokale Ports, Runde um Runde im Abstand von etwa 200 Millisekunden. Und das Interessanteste: Laut Firewall-Log wären die Pakete ohne die Sperrregel ins Internet gegangen, nicht in mein Heimnetz. Das hatte ich im ersten Moment falsch eingeschätzt.

Meine Vermutung, ausdrücklich nicht bewiesen: Das waren Verbindungstests von WebRTC. Bevor zwei Gegenstellen per WebRTC miteinander reden, tauschen sie mögliche Adressen aus (ICE-Kandidaten, ICE = Interactive Connectivity Establishment) und probieren sie der Reihe nach durch. Schickt eine Gegenseite dabei auch eine private Adresse mit – 172.17.x.x ist zum Beispiel das Standardnetz von Docker –, versucht mein Proxy eben auch die. Woher die Adresse genau kam, weiß ich nicht. Mitgeschnitten habe ich bewusst nichts: Das wären genau die Verbindungsdaten, die ich nicht haben will.

Für mich ist das trotzdem das beste Argument für die Sperrregel. Diesmal lag die fremde Adresse zufällig in einem Bereich, den ich nicht nutze. Hätte die Gegenseite eine 192.168.x.x geschickt, die zufällig in meinem Heimnetz existiert, hätte die Firewall ohne die Regel brav nach innen geroutet.

Was kommt rein, was geht raus?

Gestartet habe ich den Proxy in der Nacht zum 1. November. Die erste Zusammenfassung eine Stunde später war ernüchternd: null Verbindungen, ein paar Hundert Kilobyte Rauschen. Ich hatte schon den Verdacht, irgendwas falsch gemacht zu haben. Hatte ich nicht – nach 18 Stunden standen 84 Verbindungen und rund ein Gigabyte im Zähler.

Die erste Woche, gezählt nach deutscher Zeit und aufsummiert aus den stündlichen Zusammenfassungen:

Was mir daran auffällt:

• Die Nachfrage ist erstaunlich gleichmäßig. Meist vier bis sechs Verbindungen pro Stunde, Tag und Nacht. Nur ganz vereinzelt gab es eine Stunde ohne Verbindung, und einmal schoss es auf 41 Verbindungen in einer Stunde hoch.
• Das Volumen schwankt stärker als die Verbindungen. Am 2. November floss bei praktisch gleicher Verbindungszahl dreimal so viel wie am Tag davor. Warum, kann ich nicht sagen – und genau so soll es sein: Was die Leute über meinen Proxy machen, sehe ich nicht.
• Neun zu eins. Grob neunmal so viel geht Richtung Nutzer (↓) wie zurück. Das passt zum typischen Surfen: kleine Anfragen raus, Webseiten und Videos rein.
• Die Kapazität von zehn kann ich aus den Zusammenfassungen nicht ablesen. Sie zählen nur abgeschlossene Verbindungen pro Stunde, nicht, wie viele gleichzeitig offen waren.

Und im Alltag? Merke ich davon nichts.

Was man beim Datenvolumen wissen sollte: Alles, was der Proxy weiterleitet, läuft zweimal über meine Leitung – einmal herein und einmal hinaus. Die Summe aus ↓ und ↑ in der Zusammenfassung taucht also sowohl im Download als auch im Upload meines Anschlusses auf. Bei mir sind das gut 3 GB pro Tag in jede Richtung, im Schnitt also etwa 0,3 Mbit/s – für einen normalen Anschluss kaum der Rede wert. Die Begrenzung auf zehn gleichzeitige Nutzer hält auch die Spitzen im Rahmen.

Zum Ressourcenverbrauch: Proxmox zeigte für die VM zeitweise über 100 % RAM-Auslastung an. Das sah dramatischer aus, als es war. Ohne Ballooning zeigt Proxmox die Sicht des Hosts inklusive Cache und QEMU-Overhead. In der VM selbst waren knapp 500 MB frei, der Proxy braucht rund 140 MB, hauptsächlich für seine GeoIP-Tabellen.

Stolperfallen & Learnings

Die Firewall ist auch ein Logger. Ich hatte am Proxy alles richtig gemacht und trotzdem Nutzer-IPs gespeichert – über die Firewall. Wer bewusst keine Verbindungsdaten will, muss die ganze Kette ansehen: Anwendung, Container-Runtime, Firewall, Log-Server.

Application Control und Proxys vertragen sich nicht. Ein Profil, das die Kategorie „Proxy“ blockt, blockt auch einen Proxy, den man absichtlich betreibt. Für die DMZ-Regel gibt es deshalb ein eigenes Sicherheitsprofil ohne App Control.

Docker und Syslog: stderr ist nicht gleich Fehler. Der Syslog-Treiber stuft stderr pauschal als „error“ ein. Das lässt sich in Alloy geradeziehen, sollte man aber wissen, bevor man Alarme auf „error“ baut.

Docker-Adresspools vor dem ersten Start setzen. Das habe ich beim Honeypot schmerzhaft gelernt und diesmal gleich richtig gemacht.

Alte Host-Keys erzählen Geschichten. Die SSH-Warnung beim ersten Login war berechtigt – unter derselben IP wohnte vorher ein Honeypot. Nicht einfach wegklicken, sondern Fingerprint prüfen.

Eine Sperrregel nach innen lohnt sich auch dann, wenn man glaubt, sie nicht zu brauchen. WebRTC probiert Adressen aus, die ihm die Gegenseite schickt – auch private. Ohne Regel entscheidet allein das Routing, wo so ein Paket landet.

Geduld. Mit -summary-interval 1h kommt die erste Zusammenfassung frühestens eine Stunde nach dem Start. Und wenn man den Container zwischendurch neu startet, fängt die Stunde wieder von vorn an. Ich bin nicht gut im Warten.

Ein Wort zum Rechtlichen

Ich bin kein Anwalt, deshalb nur meine Einschätzung: Ein Snowflake-Proxy ist kein Exit-Knoten. Von meinem Anschluss gehen also keine Anfragen an fremde Webseiten aus, für die ich Ärger bekommen könnte. Mein Provider sieht lediglich, dass ich viele WebRTC-Verbindungen habe. Wer unsicher ist, wirft vorher einen Blick in die Hinweise des Tor-Projekts und in die Bedingungen des eigenen Anschlusses.

Fazit

Für eine Handvoll Zeilen Compose und eine kleine VM ist das ein ziemlich gutes Verhältnis von Aufwand und Nutzen. Mein Anschluss gibt ein bisschen Bandbreite ab, und irgendwo kommt jemand an Informationen, die ihm sonst verwehrt wären. Die DMZ hat nach dem Honeypot eine Aufgabe, die keinen Ärger macht, und ich habe nebenbei gelernt, dass Datensparsamkeit nicht in der Anwendung endet.

Was als Nächstes kommt

• Updates regeln: Das Image regelmäßig aktualisieren, ob per Hand mit docker compose pull oder automatisch nur für diesen einen Container.
• Metriken statt Logzeilen: Der Proxy kann mit -metrics auch Prometheus-Metriken liefern. Dafür bräuchte ich aber erst einmal einen Metrik-Speicher im Homelab.
• Kapazität anpassen: Wenn die Leitung es hergibt, darf der Proxy mehr als zehn Nutzer gleichzeitig bedienen.