Quelltext der Seite Homeserver-Sicherheitsarchitektur

== Homeserver-Sicherheitsarchitektur: Aufbau, Funktionsweise und Diagnose ==

Einen eigenen Server an's Internet zu bekommen, ist nicht allzu schwierig. Ein Dienst, der die eigene, vom Internet-Provider zugewiesene IP-Adresse in einen festen Domain-Namen umwandelt (siehe: [https://de.wikipedia.org/wiki/Dynamisches_DNS Dynamisches DNS]), wird im privaten Bereich die Voraussetzung sein.
Es gibt hier verschiedene Anbieter, oft auch kostenlose.

'''Beispiel:''' Der eigenen, von außen sichtbaren IP 78.123.234.45 wird vom DynDDS-Dienst die Domain <myhomeserver.dyndns.de> zugewiesen.
Einmal eingerichtet, wird der eigene Rechner antworten, wenn die Domain http://myhomeserver.dyndns.de in die Browser-Adressleiste einkopiert wird. Bei mir war damals die Freude darüber groß.

=== Motivation für einen Server mit OPNsense, Managed Switch und Docker ===

Die Kehrseite: Sowie der Server über's Internet erreichbar ist, ist er angreifbar.
Das ist kein theoretisches Szenario. Meiner Erfahrung nach ist es eine Frage von Stunden, bis die ersten Bots "anklopfen", nach laufenden Diensten suchen, nach offenen Ports, nach Schwachstellen.

Kurz: Eine öffentliche Erreichbarkeit des eigenen Servers über die ungesicherte Adresse...

* http://myhomeserver.dyndns.de

...wäre hochgradig fahrlässig.

Aufgrund einer mangelhaften Konfiguration (offener Samba-Port) hatte ich die sehr reale Erfahrung einer russischen Hackerbande, die einige Hundert Textdateien mit Zahlungsaufforderungen und einen Verschlüsselungstrojaner auf meinem Rechner hinterlassen hatte. Gerettet hatten mich damals die Dateirechte von Linux. Das fehlende E(x)ecutional-Flag und die eingeschränkten Benutzerrechte hatten den Trojaner ausgebremst.

Trotzdem: Nie wieder!
Ein wenig von dem, was ich gelernt habe, gebe ich ich hier weiter.

----

== Einleitung ==

Dieser Artikel beschreibt den Aufbau einer '''sicheren''' Netzwerkarchitektur für einen Homeserver, der über das öffentliche Internet erreichbar ist. Der Beitrag richtet sich an alle, die ihre Daten selbst kontrollieren wollen — und dabei nicht unfreiwillig Teil einer globalen Angriffs-Infrastruktur werden möchten. Er will zum Verständnis beitragen, wie die einzelnen Komponenten zusammenspielen — und wie man systematisch vorgeht, wenn etwas nicht funktioniert.

Der Fokus liegt nicht auf einer spezifischen Hardware-Konfiguration, sondern auf dem allgemeinen Prinzip: Wie kommt ein Request von außen sicher zu einem Docker-Container?

----

== Annahmen / Szenario ==

Folgende Komponenten werden in diesem Artikel vorausgesetzt:

* '''Homeserver''' (Raspberry Pi, Intel NUC, oder beliebiger Linux-Server)
** Betriebssystem: Debian/Ubuntu oder vergleichbar
** Docker mit mehreren Diensten (z.B. WordPress, Nextcloud, MediaWiki)
** Caddy als Reverse Proxy (alternativ funktionieren [https://nginx.org/ nginx], [https://httpd.apache.org/ Apache], oder (ggf. kostenpflichtige) proprietäre Lösungen. Caddy allerdings hat das für mich charmante Feature, sich eigenständig um die TSL-Zertifikate und ihre Verlängerung bei LetsEncrypt zu kümmern. Wer schon einmal aufgrund "zu..." vieler unbeabsichtigter Fehlversuche während der Zertifikats-Einrichtung von LetsEncrypt auf Tage gesperrt wurde, wird mein Faible über diesen Automatismus teilen!)
** fail2ban als Brute-Force-Schutz

* '''DynDNS-Dienst''' der dem Homeserver eine feste Domain zuweist
** Beispiel: <code>myhomeserver.dyndns.de</code>

* '''Router / Heimnetz-Gateway'''
** Beispiel-IP: <code>192.168.2.1</code>
** Aufgabe: Portweiterleitung, WLAN, DynDNS-Aktualisierung
** Typisch: FritzBox, aber jeder Router mit Portweiterleitung funktioniert

* '''OPNsense Firewall''' (dedizierte Hardware-Firewall)
** WAN-Interface: <code>192.168.2.2</code> (im Router-Netz)
** LAN-Interface / Server-VLAN: <code>192.168.10.1</code>
** Aufgabe: Firewall, NAT, DHCP, IDS/IPS

* '''Managed Switch''' (optional, für VLAN-Segmentierung)
** Trennt Server-VLAN vom Rest des Netzes

* '''Homeserver-IP''': <code>192.168.10.100</code> (per DHCP-Reservation oder besser: Per statischer IP-Adresse fest)

----

== Abschnitt 1: Wie funktionieren die Weiterleitungen? Wer macht was? ==

=== Die Kette von außen nach innen ===

Ein Request von außen (z.B. Browser ruft <code>https://myhomeserver.dyndns.de</code> auf) durchläuft folgende Stationen:

<pre>
Internet
    ↓ DNS-Auflösung: dyndns.de → öffentliche IP des Heimnetzes
Router / Gateway (192.168.2.1)
    ↓ Portweiterleitung: :80 + :443 (und nur! diese!!) → 192.168.2.2
OPNsense WAN-Interface (192.168.2.2)
    ↓ Destination NAT: :80/:443 → 192.168.10.100
Homeserver eno1/eth0 (192.168.10.100)
    ↓ Docker-Port-Binding: 0.0.0.0:80 + 0.0.0.0:443
Caddy / Reverse Proxy (Docker-intern)
    ↓ Reverse Proxy anhand des Host-Headers
Ziel-Container (z.B. wordpress, nextcloud, ...)
</pre>

Damit ist der Server auf der IP-Ebene (Layer 3 des OSI-Modells) von außen hin "unsichtbar": Die Firewall (OPNsense) lebt, mit dem Gateway, im 192.168.2-er Netz. Von dort routet sie alle Anfragen über die Ports 80 und 443 an das Interface 192.168.10.100. Dahinter, also im 192.168.10-er-Subnetz, residiert der Heimserver.

Am Ende dieses Beitrages gibt es Sicherheitshinweise. Bitte dringend beachten, dass der Router ausschließlich die Ports '''80/TCP''' und '''443/TCP''' nach außen frei gibt. Der Webserver wird dabei so konfiguriert, dass HTTP-Daten über Port 80 nach HTTPS auf Port 443 umgeleitet werden.

Die Idee, ausschließlich HTTPS zuzulassen, läge nahe. Damit bräuchte sich der Webserver nicht um die Weiterleitung auf Port 443 zu befassen.
Bedauerlicherweise wird in diesem Fall der Umgang mit dem TLS-Zertifikat, das den HTTPS-Datenstrom verschlüsselt, scheitern. [https://letsencrypt.org/ LetsEncrypt] benötigt bei Einrichtung und Verlängerung seiner Zertifikate einen offenen 80-er Port.

Sollte es nötig sein, den Server von außen zu administrieren, wird man darüber nachdenken, einen VPN-Tunnel einzurichten. Sicherer jedoch - und einfacher - ist es dennoch, die Administration ausschließlich über einen zertifikats-geschützten SSH-Zugang im inneren 192.168.-er-Netz zuzulassen und, abgesehen von 80 und 443, auf jeden nach außen exponierten Port zu verzichten.

=== Wer macht was? ===

{| class="wikitable"
|-
! Komponente !! Aufgabe !! Konfigurationsort
|-
| '''Router / Gateway''' || DynDNS-Aktualisierung, erste NAT-Stufe, WLAN || Router Web-UI → Portfreigaben
|-
| '''OPNsense Firewall''' || Firewall-Regeln, zweite NAT-Stufe (Destination NAT), DHCP für Server-VLAN || OPNsense Web-UI (Standard: https://&lt;wan-ip&gt;:443 oder :8443)
|-
| '''Caddy / Reverse Proxy''' || TLS-Terminierung, Let's Encrypt, Weiterleitung an Container || Caddyfile auf dem Homeserver
|-
| '''Docker''' || Container-Isolation, internes Netz (Standard: 172.18.0.0/16) || docker-compose.yml pro Dienst
|-
| '''fail2ban''' || Brute-Force-Schutz auf Applikationsebene || Jail-Configs im fail2ban-Container
|}

=== Wichtig: OPNsense hat ZWEI Firewall-Engines ===

OPNsense 26.x hat zwei parallele Regelwerke:
* '''Rules [new]''' — neue API-basierte Engine
* '''Rules''' — alte Engine (Legacy)

Neue Regeln '''immer in beiden''' anlegen! Bei Problemen immer beide prüfen.

----

== Abschnitt 2: Wo steht was? ==

=== IP-Adressen (Beispiel-Setup) ===

{| class="wikitable"
|-
! Gerät !! Interface !! IP !! Bemerkung
|-
| Router / Gateway || — || 192.168.2.1 || Gateway, WLAN, DynDNS
|-
| OPNsense WAN || wan-interface || 192.168.2.2 || Statisch konfiguriert
|-
| OPNsense LAN / Server-VLAN || lan-interface || 192.168.10.1 || Gateway für Server-Netz
|-
| Homeserver || eno1 / eth0 || 192.168.10.100 || Fest per DHCP-Reservation (MAC-Adresse)
|-
| Client-Geräte || WLAN || 192.168.2.x || Im Router-Netz, nicht im Server-VLAN
|}

=== Homeserver: Netzwerk-Interface-Konfiguration ===

Der Homeserver bezieht seine IP per DHCP vom OPNsense-DHCP-Server. Bei Debian/Ubuntu mit systemd-networkd:

<pre>
/etc/systemd/network/10-eth0.network
</pre>

'''Korrekter Inhalt (DHCP):'''

<pre>
[Match]
Name=eno1

[Network]
DHCP=ipv4

[DHCP]
RouteMetric=100
</pre>

⚠️ '''Niemals''' eine statische IP oder einen Gateway manuell eintragen!
Der Default-Gateway kommt immer vom DHCP-Server der OPNsense-Firewall (<code>192.168.10.1</code>).

=== Kea DHCP Lease-Datei (OPNsense) ===

<pre>
/var/db/kea/kea-leases4.csv
</pre>

Hier verwaltet Kea die aktiven Leases. Bei Problemen mit doppelten IPs kann diese Datei (nach <code>configctl kea stop</code>) auf den Header reduziert werden:

<pre>
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context,pool_id
</pre>

----

== Abschnitt 3: Systematische Diagnose — Schritt für Schritt ==

=== Grundprinzip: Von außen nach innen ===

Immer von außen nach innen vorgehen — nie raten, immer messen. Jede Schicht einzeln prüfen.

==== Schritt 1: Ist OPNsense überhaupt erreichbar? ====

<pre>
# Vom Client-Rechner:
ping 192.168.2.2
</pre>

⚠️ OPNsense antwortet standardmäßig '''nicht''' auf ICMP/Ping von außen — das ist korrekt!

Stattdessen prüfen:
<pre>
# Web-UI erreichbar?
https://192.168.2.2:8443

# Router zeigt OPNsense als verbundenes Gerät?
http://192.168.2.1
</pre>

==== Schritt 2: OPNsense intern prüfen ====

Per SSH oder serieller Konsole auf OPNsense:

<pre>
# WAN-Interface OK?
ifconfig &lt;wan-interface&gt;
# Erwartete Ausgabe: inet 192.168.2.2, status: active

# LAN-Interface OK?
ifconfig &lt;lan-interface&gt;
# Erwartete Ausgabe: inet 192.168.10.1, status: active

# Router erreichbar?
ping -c 3 192.168.2.1

# Homeserver erreichbar?
ping -c 3 192.168.10.100
</pre>

==== Schritt 3: Homeserver direkt prüfen ====

<pre>
# SSH auf Homeserver:
ssh root@192.168.10.100

# Alle Container laufen?
docker ps

# Internet vom Homeserver aus erreichbar?
ping -c 3 9.9.9.9

# Routing-Tabelle korrekt?
ip route show
# Erwartete Default-Route: default via 192.168.10.1 dev eno1
# NICHT: default via 192.168.178.x — das wäre falsch!

# Welche IP hat das Interface?
ip addr show eno1
# Erwartete IP: 192.168.10.100
</pre>

==== Schritt 4: Caddy / Reverse Proxy prüfen ====

<pre>
# Läuft Caddy und antwortet er lokal?
curl -v http://localhost
# Erwartete Antwort: HTTP 308 Redirect → https://localhost/

# Caddy-Logs auf Fehler prüfen:
docker logs caddy --tail 50
</pre>

Typische Fehler in den Caddy-Logs:

{| class="wikitable"
|-
! Fehlermeldung !! Bedeutung !! Lösung
|-
| <code>dial tcp ...:443: connect: no route to host</code> || Caddy kommt nicht ins Internet (Let's Encrypt nicht erreichbar) || Routing auf Homeserver prüfen (Schritt 3)
|-
| <code>no route to host</code> bei Ping auf 9.9.9.9 || Falscher Default-Gateway || <code>ip route show</code> prüfen, falsche Route entfernen
|}

==== Schritt 5: NAT und Firewall-Regeln prüfen (OPNsense Shell) ====

<pre>
# NAT-Regeln anzeigen:
pfctl -s nat | grep &lt;PORT&gt;

# Firewall-Regeln anzeigen:
pfctl -s rules | grep &lt;PORT&gt;

# Traffic auf WAN-Interface beobachten (kommt der Request an?):
tcpdump -i &lt;wan-interface&gt; port &lt;PORT&gt;

# Traffic auf LAN-Interface beobachten (wird er weitergeleitet?):
tcpdump -i &lt;lan-interface&gt; port &lt;PORT&gt;
</pre>

'''Diagnose-Logik:'''
<pre>
tcpdump WAN sieht Traffic, LAN nicht → NAT-Regel prüfen!
tcpdump WAN sieht keinen Traffic    → Portweiterleitung im Router prüfen!
</pre>

==== Schritt 6: Bekannte Fallstricke ====

{| class="wikitable"
|-
! Problem !! Symptom !! Ursache !! Fix
|-
| Falsche statische Route || <code>ping 9.9.9.9</code> schlägt fehl || Netzwerk-Config hat statischen Gateway eingetragen || Auf DHCP umstellen, <code>systemctl restart systemd-networkd</code>
|-
| Homeserver hat falsche IP || NAT-Regeln greifen nicht || DHCP hat beim Neustart temporär andere IP vergeben || DHCP-Reservation per MAC-Adresse einrichten
|-
| DHCP-Leases durcheinander || Server taucht mit zwei IPs auf || Neustart hat neuen Lease vor Ablauf des alten erzeugt || <code>configctl kea stop</code>, Lease-CSV bereinigen, <code>configctl kea start</code>
|-
| OPNsense Firewall-Regel fehlt || Dienste von außen nicht erreichbar, intern OK || Regel nur in einer der beiden Engines angelegt || Regel in '''beiden''' Engines anlegen (Rules [new] + Rules)
|-
| NAT-Regel ohne Subnetz-Maske || Traffic kommt nicht an || <code>192.168.178.0</code> statt <code>192.168.178.0/24</code> eingetragen || Subnetz-Maske ergänzen — ohne /24 gilt nur die Netzadresse selbst!
|-
| Source/Destination Port vertauscht || Verbindungen werden blockiert || Bei Firewall-Regel Port unter "Source" statt "Destination" eingetragen || Source Port: any / Destination Port: gewünschter Port
|}

----

== Notfall-Cheatsheet ==

<pre>
# OPNsense: Firewall temporär deaktivieren (Notfall!)
pfctl -d

# OPNsense: Firewall wieder aktivieren
pfctl -e

# OPNsense: Kea DHCP stoppen/starten
configctl kea stop
configctl kea start

# Homeserver: Falsche Default-Route entfernen
ip route del default via &lt;falsche-gateway-ip&gt; dev eno1

# Homeserver: IP manuell setzen (Sofortlösung bei DHCP-Problemen)
ip addr add 192.168.10.100/24 dev eno1

# Homeserver: Netzwerk-Dienst neu starten (Verbindung kurz weg!)
systemctl restart systemd-networkd

# Homeserver: Docker-Logs prüfen
docker logs caddy --tail 50
docker ps

# OPNsense: Alias-Tabellen prüfen (Blocklisten)
pfctl -t &lt;tabellenname&gt; -T show | wc -l
pfctl -t &lt;tabellenname&gt; -T show | grep &lt;IP&gt;
</pre>

----

== Sicherheitshinweise ==

* SSH-Ports '''nicht''' über das Internet freigeben — nur intern erreichbar lassen! Sollte das keine Option sein: VPN-Tunnel!
* Portweiterleitung im Router auf das '''Minimum''' beschränken (nur die Ports 80 + 443 öffnen).
* Für interne Admin-Interfaces (OPNsense Web-UI, Monitoring) '''keine(!) externen Freigaben!'''
* DHCP-Reservations per MAC-Adresse oder statische IP-Adressen verhindern IP-Wechsel nach Neustarts.
* Bei Firewall-Regeln: Block-Regeln '''immer''' vor Pass-Regeln platzieren.

Abschließend eine absolute Regel, die immer und durch die Ewigkeiten gilt:
* Dienste, die auf einem Rechner '''NICHT''' existieren, werden niemals angegriffen! Wenig ist hier mehr!
----

''Dieser Artikel basiert auf praktischen Erfahrungen aus dem Betrieb eines selbst gehosteten Servers mit OPNsense, Cisco-Switch und Docker-Stack.''
''Erstellt: Mai 2026''