GearFish Team 12: Abschlussprojekt

Das Projekt

Team 12 (GearFish) hat eine eigenständige, gehärtete IT-Infrastruktur aufgebaut: von der Virtualisierung über die Firewall bis hin zu einem selbst entwickelten Messaging-Dienst.

Team

Keanu Amann und David Kleinfercher, GearFish Team 12, betreuen die gesamte Domäne t12.lan und alle ausgerollten Dienste.

Umfang

Zwei Proxmox-Knoten, eine FortiGate-Firewall mit SSL-VPN, Active Directory, Endpoint-Management, Backup, Monitoring und ein eigener E2EE-Messenger.

Eigenleistung

Neben der Integration etablierter Lösungen wurde mit Rede ein vollständiger Ende-zu-Ende-verschlüsselter Messenger samt Server, Desktop- und Terminal-Client selbst entwickelt.

Projektphasen

1

Planung

Netzwerklayout, Subnetze, Hardware-Inventur

2

Virtualisierung

Proxmox auf zwei Knoten

3

Netzwerk

FortiGate, SSL-VPN, DMZ-Trennung

4

Domäne

AD, DNS, DHCP, Group Policies

5

Dienste

Baramundi, Veeam, Naemon, Rede

6

Härtung und Doku

Backups, Monitoring, Dokumentation

Infrastruktur

Drei Netzsegmente, sechs produktive Server, eine Firewall: das Fundament, auf dem alle Dienste aufsetzen.

Netzwerk-Segmente

LAN: 192.168.1.0/24, Gateway 192.168.1.253
DMZ: 192.168.2.0/24, Gateway 192.168.2.253
VPN-Pool: 10.212.134.200 bis 210
WAN: 94.199.169.148/28
Domäne: t12.lan

Server

winsrvmgmt1 (LAN): AD, DNS, DHCP
winsrvbara1 (LAN): Baramundi Management Suite
winsrvbackup1 (LAN): Veeam Backup
ubusrvnaemon1 (LAN): Naemon Monitoring
debsrvwebCT1 (DMZ): Webserver, hostet diese Seite
debsrvrede1 (DMZ): Rede-Relay

Plattform

Zwei Proxmox-VE Knoten
FortiGate-50E, Firmware 6.2.12
SSL-VPN auf Port 8443
Hardware: zweckentfremdete Kemp-Loadbalancer-Appliances
Daraus folgt: Monitoring und Backup als Kernsäulen

Netzwerk-Architektur

Komponenten

Die sechs zentralen Bausteine des Projekts.

Active Directory

Zentrale Authentifizierung, DNS und DHCP auf winsrvmgmt1, inklusive Group Policies, OU-Struktur und PXE-Boot-Optionen für das Client-Rollout.

OU-Struktur t12 Users, Computers, Groups
GPOs: Password Policy, Remote Access, sichere Protokolle
DHCP-Scope 192.168.1.20 bis 240

FortiGate-Firewall

FortiGate-50E mit dediziertem WAN-, LAN- und DMZ-Interface, SSL-VPN, Virtual IPs für Web und Rede sowie WireGuard-Sync zu einem externen Rede-Knoten.

SSL-VPN Portal RDP-Portal, ohne Split-Tunneling
Policy-basierte Trennung LAN, DMZ, VPN, WAN
VIPs WEB_VIP_HTTP, WEB_VIP_HTTPS, VIP_rede

Endpoint-Management (Baramundi)

Baramundi Management Suite 2025 R2 auf winsrvbara1 mit SQL Server 2022 Express, dediziertem PXE-Boot über die DHCP-Optionen 66/67 und integrierten AD-Service-Konten.

Lizenz: Teststellung, gültig bis 30.06.2026
PXE: TFTP, Proxy-DHCP, DHCP-Relay
autounattend.xml für unbeaufsichtigten Client-Rollout

Backup (Veeam)

Veeam Backup und Replication auf winsrvbackup1, eigener Proxmox-Knoten zur physischen Trennung der Backups vom produktiven Cluster. 14 Tage Retention.

Gesichert: Domain Controller, Baramundi, Naemon, Rede
Voll-Backups, gestaffelt von Freitag bis Sonntag
NTLMv2 als globaler Fallback

Monitoring (Naemon)

Naemon mit Thruk-Dashboard und check_wmi_plus, agentless WMI für Windows, check_by_ssh für Linux. Triggergrund: leistungsschwache, zweckentfremdete Hardware.

WMIC-Server (aiowmi) hinter gunicorn
Per realm und sssd an t12.lan gejoint
Service-User kairos in der Queryusers-Gruppe

DMZ-Services

Diese Website (debsrvwebCT1, LXC-Container) und der Rede-Relay (debsrvrede1, vollwertige VM). Beide bewusst aus dem Internet erreichbar, deshalb vom produktiven LAN getrennt.

Webserver via VIPs auf 80/443
Rede-Relay via VIP_rede auf 9443 nach 9377
WireGuard-Sync zu externem Rede-Knoten

Rede: eigener E2EE-Messenger

Das Highlight des Projekts: ein selbst entwickelter, Ende-zu-Ende-verschlüsselter Messenger mit Server, Desktop- und Terminal-Client, voll integriert in die GearFish-Infrastruktur. Lizenz AGPL-3.0, Protokollversion 3.

Rede Desktop-Client: Direct Message mit etablierter E2EE-Session — Avalonia-Desktop-Client: 1:1-Chat mit aktiver E2EE-Session.

Server (Node.js)

Rund 6.800 Zeilen JavaScript
WebSocket-Transport, JSON-Wire-Protokoll v3
SQLite oder PostgreSQL als Datenbankschicht
Redis Pub/Sub für Cluster und Föderation
mediasoup-SFU für Gruppen-Audio
Läuft auf debsrvrede1 in der DMZ

Desktop-Client (Avalonia)

Rund 18.600 Zeilen C# auf .NET 8
Rede.Core (Business-Logik) und Rede.Desktop (UI)
libsodium für die Kryptografie
1:1, Gruppen, Places, Sprach- und Gruppenanrufe
Auto-Update mit Ed25519-signierten Releases

Terminal-Client (v1)

Rund 4.800 Zeilen JavaScript
TUI- und CLI-Modus
Vollständig protokollkompatibel zu v2
Sicherheitsfixes immer in beide Implementierungen

Architekturüberblick Client und Server: Klartext-Schicht und Krypto-Schicht liegen ausschließlich beim Client, der Server sieht nur Chiffretext — Architekturüberblick: Klartext und Schlüssel verlassen das Endgerät nicht, der Server ist ein blindes Relay.

Sicherheitsmodell

X3DH und PQXDH (Post-Quantum) für den Schlüsselaustausch
Double Ratchet für Forward Secrecy und Post-Compromise Security
Sender Keys für Gruppen, Sealed Sender für Metadaten-Sparsamkeit
Server ist ein blindes Relay: nur Chiffretext, kein Zugriff auf Klartext oder Schlüssel
SRTP für 1:1-Anrufe, SFrame für Gruppenanrufe über LiveKit
TOFU-gepinnte Ed25519-Server-Signaturen und TLS-Fingerprint-Pinning

Mehr Einblicke

Rede Login-Screen: Passphrase und Server-Auswahl, Stay signed in — Login: Passphrase entsperrt den lokalen Profiltresor, Server-Auswahl pro Identität.

Rede Places: Discord-ähnliche Server mit Kanälen wie off-topic, willkommen, chat, bugs, features — Places: Discord-ähnliche Server mit Kanalstruktur, Rollen und Berechtigungen.

Rede Terminal-Client v1 Startbildschirm: System-Init mit X3DH, Double Ratchet, XSalsa20-Poly1305, Pre-Keys, Identity-Fingerprint — Terminal-Client v1: System-Init zeigt Krypto-Stack, Pre-Keys und Identity-Fingerprint.

Rede Add-Contact-Dialog mit Security-Warnung: Server-Zertifikat geändert, möglicher MITM, Verbindung blockiert — TOFU-Pinning in Aktion: bei geändertem Server-Zertifikat wird die Verbindung blockiert.

X3DH PQXDH Handshake: Alice fetcht Pre-Key-Bundle, berechnet vier DH-Werte plus ML-KEM-768, leitet SK ab und sendet Nachricht über Server an Bob — X3DH und PQXDH-Handshake: vier klassische DHs plus ML-KEM-768 ergeben den Session-Key.

Double Ratchet KDF-Kette mit Root-KDF und Chain-KDF — Double-Ratchet-KDF-Kette: jeder msgKey wird nach Gebrauch genullt, Perfect Forward Secrecy.

Audio-Pipeline Senden und Empfangen mit SRTP-Verschlüsselung — Audio-Pipeline: SRTP verschlüsselt Senden und Empfangen, der Server sieht nur opake binäre Frames.

Lessons Learned

Was reibungslos lief, was Zeit gekostet hat und welche Schlussfolgerungen wir für die Zukunft mitnehmen.

Was gut funktioniert hat

Die selbst entwickelte Messenger-Architektur Rede ließ sich sauber in die bestehende Infrastruktur einfügen: Relay in der DMZ, Firewall-Policy, VIP und WireGuard-Sync gingen ohne Umbauten am Rest des Systems. Auch FortiGate und SSL-VPN waren schneller eingerichtet als erwartet.

Was schwierig war

Rede selbst, besonders die Sprachübertragung über verschiedene Transportwege, war das anspruchsvollste Teilstück. Den größten externen Zeitfresser bildete die Baramundi-Lizenz: trotz erfolgreicher Aktivierung blieben zentrale Module nicht freigeschaltet und die Klärung mit dem Hersteller zog sich.

Hardware-Lektion

Die Proxmox-Hosts sind zweckentfremdete Kemp-Loadbalancer-Appliances. Diese Einschränkung hat uns durchgängig zu Sorgfalt bei Monitoring und Backups gezwungen, eine gute Schule darin, Ausfallrisiken von Anfang an einzuplanen.

Konsequenz

So viel wie möglich in der eigenen Hand behalten: Open-Source-Lösungen bevorzugen, externe Abhängigkeiten begrenzen. Die Reibung entstand fast immer dort, wo wir auf Lizenzgeber oder geschenkte Hardware angewiesen waren.

Präsentation

Live-Vorschau der Abschlusspräsentation. Wird bei jeder PowerPoint-Speicherung automatisch aktualisiert.

Vollbild öffnen PDF herunterladen

Tipp: Mit ← → oder Scrollen durch die Folien navigieren

Dokumentation und Downloads

Alle Projektunterlagen als PDF.

Dokumentation Abschlussprojekt

Hauptdokument, 49 Seiten. Vollständige Beschreibung von Infrastruktur, Firewall, Active Directory, Server-Diensten, Autounattend, Baramundi-Lizenz und Lessons Learned.

PDF Download

Präsentation

Abschlusspräsentation mit allen Kernpunkten und Ergebnissen des Projekts.

PDF Download

Rede Server

Technische Dokumentation des selbst entwickelten Messenger-Servers: Wire-Protokoll, Datenbankschicht, Föderation, SFU und Sicherheitsmodell.

PDF Download

Rede Client

Technische Dokumentation des Avalonia-Desktop-Clients und des Legacy-Terminal-Clients: Kryptografie, Audio-Pipeline, Build und Auto-Update.

PDF Download

Backups mit Veeam

Backup-Konzept und Einrichtung der Veeam-Lösung, inklusive der NTLM- und Domain-Join-Stolpersteine.

PDF Download

Monitoring mit Naemon

Naemon mit Thruk-Dashboard, check_wmi_plus für Windows und check_by_ssh für Linux im GearFish-Netzwerk.

PDF Download