Diese Seite beschreibt sicherheitsrelevante Aspekte des Systems, identifiziert Risiken und definiert Maßnahmen zur Absicherung.
Ziel ist:
- Angriffsflächen verstehen
- aktuelle Schutzmechanismen kennen
- Sicherheitslücken systematisch schließen
- Zugang über Domains (z. B.
tyf.one, join.tyf.one)
- zentraler Einstieg:
proxy-npm-1 (Reverse Proxy)
- SSL:
- Let's Encrypt (automatisch)
- interne Kommunikation:
- Docker-Netzwerke (z. B.
proxy-net)
- Services:
- nicht direkt öffentlich exposed (außer definierte Ports)
- Zugriff nur über:
- gesteuert durch:
- Routing
- TLS-Termination
- Domain-Handling
- Container-Kommunikation
- nicht direkt öffentlich erreichbar
- basiert auf:
- Container-Namen
- Netzwerken
- User → HTTPS Request
- Reverse Proxy (
proxy-npm-1)
- Routing zu Zielcontainer:
chatjointyf-onboardingelement-web
- Response zurück an Client
- SSL wird am Proxy beendet
- interne Services sprechen HTTP
- Isolation erfolgt über:
- Docker-Netzwerke
- fehlende direkte Portfreigaben
- Container sind nicht direkt öffentlich erreichbar
- SSL wird automatisch verwaltet (Let's Encrypt)
- Zugriff erfolgt ausschließlich über den Proxy
- Container-Namen sind Teil der Architektur (DNS intern)
- Logs zeigen regelmäßige externe Scans (normal im Internet)
docker logs proxy-npm-1
docker logs chatjoin
ss -tulpen
docker network inspect proxy-net
-
Verhalten:
- Account konnte reaktiviert werden
- Passwort wurde überschrieben
-
Risiko:
- Account-Übernahme möglich
-
Maßnahme:
→ dokumentationswürdig, da sicherheitsrelevant
- offene Ports (
80, 443, 81)
- Admin-Oberfläche (
:81)
- API-Endpunkte (
/api)
- Auth-System (Matrix / Onboarding)
- falsch konfigurierte Proxy Hosts
- fehlende Netzwerkzuordnung
- Reverse Proxy = zentrale Sicherheitsinstanz
- Matrix = Auth-System
- Onboarding = Account-Erstellung
- alle Services hängen von korrekter Proxy-Konfiguration ab
- Netzwerkstruktur bestimmt interne Sicherheit
- Admin-Interface (
:81) öffentlich erreichbar
- keine zentrale Auth-Lösung für alle Services
- SQLite (Proxy) nicht gehärtet
- Container laufen als root (Standard)
- keine Rate-Limits oder WAF aktiv
- API-Zugriffe teilweise ungeschützt
- keine zentrale Zugriffskontrolle
- Fehler im UI können interne Infos leaken
- zentrale Auth-Lösung (SSO) prüfen
- Zugriffskontrolle verbessern (z. B. Rollen / Permissions)
- Absicherung von APIs (Auth + Rate Limit)
- Admin-Zugang absichern (Whitelist / VPN / Basic Auth)
- Logging und Monitoring erweitern
- Security-Header prüfen (CSP, HSTS etc.)
- Umgang mit Bots/Scannern definieren
- Admin-Interface (
:81) absichern
- keine unnötigen Ports offen lassen
- Proxy-Hosts sauber konfigurieren
- Logs regelmäßig prüfen
- Rate Limiting einführen
- API-Endpunkte absichern
- Security Header ergänzen
- Container-Rechte prüfen (root → non-root)
- Fail2Ban oder ähnliche Tools einsetzen
- Web Application Firewall (WAF)
- Geo-Blocking / IP-Filtering
- Monitoring + Alerting
Deine Sicherheit hängt zu großen Teilen an einem einzigen Punkt:
→ dem Reverse Proxy
Wenn dort etwas falsch konfiguriert ist:
- sind alle Services betroffen
Das System ist aktuell:
aber noch nicht:
- gehärtet
- segmentiert
- überwacht