Skip to content

Security & Plattformbetrieb

Praxisnahe Security-Arbeit im Self-Hosted-Umfeld: private Zugriffswege, Reverse Tunneling, DNS-Filterung, reaktive Abwehr, first-party Analytics, serviceorientierte Observability und kontrollierte Exponierung von Webdiensten.

Security-Architekturueberblick

Layer-Ansicht der aktuellen Plattform: Access & Network, Filtering & Defense, Web & Analytics, Observability und Operations mit klaren Public-, Management- und Data-Plane-Grenzen.

Diagramm oeffnen
Security and Platform Operations diagram with access, defense, analytics, observability, operations, and trust boundaries

Aktuelle Security- und Operations-Bausteine

Architektur-Snapshot

  1. Public Web
  2. VPS / Ingress
  3. Tailscale Overlay
  4. Private Proxmox Runtime
  5. Docker Services
Private AccessReduced ExposureFirst-Party AnalyticsMonitoringBackup Ready

Access & Network

Private Einstiegspfade und kontrollierte Exponierung.

  • Tailscaleprivates Overlay-Netzwerk
  • UFWInterface-basierte Firewall-Regeln
  • Nginx Proxy Managerkontrollierte Reverse-Proxy-Einstiegspunkte

Filtering & Defense

DNS-Filterung und reaktive Blockierung.

  • Pi-holeDNS-Filterung
  • CrowdSecreaktive Intrusion Response

Analytics & Data

First-Party-Metriken und Speicherkomponenten.

  • Plausible AnalyticsFirst-Party Web Analytics
  • PostgreSQLrelationaler Datenspeicher
  • ClickHouseAnalytics- und Event-Speicher

Observability

Runtime-Sichtbarkeit über Hosts und Services.

  • NetdataEchtzeit-Host-Metriken
  • Uptime KumaService-Verfügbarkeitsprüfungen
  • DozzleContainer-Log-Sichtbarkeit

Operations

Container-Administration und Update-Flow.

  • PortainerContainer-Management
  • WatchtowerContainer-Update-Lifecycle

Security Stack

Netzwerk-Segmentierung

Prinzip: Angriffsflaeche minimieren. Impl: Private Overlay-Pfade, workloadnahe Trennung auf Proxmox und kontrollierte Service-Einstiegspunkte statt ungebuendelter Direkt-Exponierung.

Firewall-Strategie

Prinzip: Mehrschichtige Abwehr. Impl: Interface-basierte UFW-Regeln, Pi-hole für DNS-Filterung, CrowdSec für reaktive Blockierung und Nginx Proxy Manager für gebuendelte Service-Exponierung.

Sicherer Fernzugriff

Prinzip: Keine offenen Management-Ports. Impl: Tailscale-Overlay auf WireGuard-Basis für private Administration, konsistente SSH-Pfade und kontrollierten Remote-Zugriff auf interne Plattformen.

Observability

Prinzip: Betriebszustand sichtbar halten. Impl: Netdata für Echtzeit-Metriken, Uptime Kuma für Service-Checks, Dozzle für Live-Logs und Watchtower für den routinemaessigen Container-Update-Lifecycle.

Operative Ergebnisse

  • Die Umgebung kombiniert privaten Tailscale-Ingress, DNS-Filterung, kontrollierte Service-Exponierung und CrowdSec-basierte Reaktion statt sich auf einen einzelnen Schutzmechanismus zu verlassen.
  • Metriken, Uptime, Logs, Analytics und der Container-Update-Zyklus sind sichtbar und strukturierter betreibbar, was den Wartungsaufwand für die Self-Hosted-Plattform senkt.

Öffentliche Zusammenfassung; interne Hostnamen, Adressen, Secrets und Konfigurationsdetails werden nicht veröffentlicht.

Zur Fallstudie: Self-Hosted Infrastructure >Zur Operations-Schicht: The Vienna Fortress >

Fallstudien

Mehrschichtige DNS-Filterung & IPS

Herausforderung: Interne Dienste und Clients brauchten Basisschutz gegen unerwünschte Domains und auffällige Zugriffsmuster.

Vorgehen: Pi-hole für DNS-Filterung mit CrowdSec für verhaltensbasierte Erkennung und Gegenmaßnahmen kombiniert und Service-Zugriffe über kontrollierte Einstiegspunkte gebündelt.

Ergebnis: Unerwünschte Domains und auffälliger Traffic werden früher im Request-Pfad abgefangen und reduzieren die Exponierung der eigentlichen Services.

Privater Administrationspfad

Herausforderung: Verteilte Dienste und Dashboards mussten remote administrierbar sein, ohne Management-Flächen breit freizugeben.

Vorgehen: Tailscale-Overlay, gemeinsame SSH-Aliasse und kontrollierte Reverse-Proxy-Einstiegspunkte statt direkter öffentlicher Management-Zugänge genutzt.

Ergebnis: Administration bleibt auf privaten Pfaden, während Nutzer-Dienste strukturierter und mit geringerer Fehlkonfiguration exponiert werden.

The Vienna Fortress

Herausforderung: Ein werkzeugorientiertes privates Infrastruktur-Lab wurde mit wachsendem Stack schwerer zu überwachen, abzusichern und im Alltag wartbar zu halten.

Vorgehen: Eine Proxmox- und Docker-Plattform um Nginx Proxy Manager, Pi-hole, CrowdSec, Netdata, Uptime Kuma, Dozzle, Watchtower und Homepage aufgebaut und zusätzlich eine Proxmox-API-Integration für ein React-Dashboard stabilisiert.

Ergebnis: Eine produktionsnaehere interne Plattform mit geschichteter Sicherheit, zentraler Sichtbarkeit und geringerem Wartungsaufwand geschaffen.