Interne Software ohne offene Ports: Cloudflare Tunnel und Access für den Hub der konavent ag

Lösung

Wir haben den Hub auf einen eigenen Server umgezogen und Cloudflare davorgesetzt.

Eigener, gehärteter Server. Ein Hetzner-Server wurde am 26.10.2026 neu aufgesetzt und gehärtet. Die Firewall bei Hetzner und die Firewall auf dem Server lassen keine Verbindung von aussen zu. Für die Wartung gibt es SSH nur über Tailscale, ein privates Netz mit freigegebenen Geräten. Der Hub läuft als eigener Dienst und hört nur auf 127.0.0.1, also nur auf dem Server selbst.

Cloudflare Tunnel. Auf dem Server läuft cloudflared als Dienst. Er baut die Verbindung zu Cloudflare von innen nach aussen auf. Anfragen an konavent-hub.bytebricks.ch kommen über diesen Tunnel zum Hub. Darum braucht der Server keinen offenen Port.

DNS und TLS bei Cloudflare. Die Zone bytebricks.ch liegt seit dem 27.10.2026 bei Cloudflare. Alle bestehenden Einträge haben wir vorher 1:1 übernommen und verglichen, auch E-Mail und Webseite. Das Zertifikat liegt am Rand von Cloudflare.

Cloudflare Access. Vor dem Hub steht seit dem 29.10.2026 Cloudflare Access. Wer den Hub öffnet, gibt seine E-Mail-Adresse ein und erhält einen Code. Nur Adressen von konavent.ch und von ByteBricks kommen durch. Die Anmeldung gilt 7 Tage. Der Hub prüft das Access-Token zusätzlich selbst. Ohne gültiges Token antwortet er mit 403. Das alte Hub-Passwort gibt es nicht mehr.

Überwachung. Fällt ein Ablauf aus, schickt der Hub eine E-Mail. Ein externer Herzschlag ist vorbereitet. Er wirkt, sobald er eingerichtet ist.

Ergebnis

• Die öffentliche IP des Servers beantwortet nichts. Von aussen geprüft: alle TCP-Ports zu, IPv4 und IPv6.
• Kein Passwort mehr, das man weitergeben oder erraten kann. Die Anmeldung läuft über die Firmen-Mailbox. Wer die konavent ag verlässt, verliert mit der Mailbox auch den Zugang.
• Wer Access umgehen will, scheitert am Hub selbst: Ohne gültiges Token gibt es keine Seite.
• Für das Team änderte sich wenig: Adresse öffnen, Code eingeben, arbeiten.

Wovor das schützt: Angriffe auf offene Ports, erratene oder weitergegebene Passwörter und vergessene Zugänge nach einem Austritt.

Wie wir gearbeitet haben

Der Umzug verlief in kleinen, umkehrbaren Schritten:

1. Server neu aufsetzen und härten. Danach von aussen prüfen, dass kein Port antwortet.
2. Den Hub im Standby auf dem neuen Server starten, noch ohne Daten und ohne ausgehende Verbindungen.
3. Die Zone bytebricks.ch zu Cloudflare verschieben. Erst nach dem Vergleich aller Einträge die Nameserver umstellen.
4. Den Tunnel zuerst auf einem Test-Hostnamen prüfen.
5. Im Umzugsfenster am 27.10.2026 den alten Hub stoppen, die Datenbank sichern und prüfen, auf den neuen Server kopieren und dort starten. Dann den DNS-Eintrag auf den Tunnel umstellen.

Der Hub war nur für das Kopieren der Datenbank nicht erreichbar. Wer noch die alte Adresse im Cache hatte, wurde vom alten Server an den Tunnel weitergeleitet. Der Rückweg war beschrieben: DNS zurück und den alten Hub starten. Der alte Hub blieb zwei Wochen gestoppt erhalten.

Access haben wir zuerst auf dem Test-Hostnamen eingerichtet und geprüft, dann auf dem echten Hostnamen. Erst danach fiel das Passwort weg.

Technik

• Hetzner Cloud, Ubuntu 24.04, Firewall bei Hetzner und ufw
• Tailscale für SSH, kein SSH aus dem Internet
• cloudflared als systemd-Dienst, Token-Datei nur für root lesbar
• Cloudflare DNS, Tunnel und Access (E-Mail-Code), Zero Trust Free
• Prüfung des Access-Tokens im Hub (Signatur und Zielgruppe)
• Alarm per E-Mail bei Ausfällen

Nächster Schritt

Läuft eine interne Anwendung bei Ihnen mit offenem Port und gemeinsamem Passwort? Schicken Sie uns eine kurze Beschreibung. Im Erstgespräch klären wir, ob sich der Umzug hinter Cloudflare lohnt. Danach folgt eine schriftliche Offerte mit Umfang, Festpreis und Termin.