Reverse Proxy - welcher und wie absichern?

Legolas schrieb:
Darf ich mal fragen welche Proxys Ihr so nutzt?
HAProxy als Reverse Proxy für alle Dienste die ich anbiete.

Darauf läuft für jeden Dienst ein umfangreiches Regelwerk (ACL).
 
Nginx Proxy Manager
Der npm selbst ist sicher, da muss man nichts zusätzlich absichern. Zudem ist er schlank und kompakt ohne Ballast, der Lücken enthalten könnte.
Port 81 darf natürlich nicht von extern offen sein.

Extra Absicherung nur bei Diensten, auf die nicht jeder Zugreifen soll per "Authelia" mit 2FA. Grundsätzlich wäre ein VPN bei sowas natürlich ratsamer, aber VPN ist nicht immer möglich oder praktikabel.

Aber: Grundsätzlich sollte man nur Dienste per Reverse Proxy erreichbar machen, die dafür gedacht sind. Ein Vaultwarden ist z.B. dafür gedacht öffentlich erreichbar zu sein und entsprechend abgesichert. Ein PRTG Dashboard ist das nur bedingt.
 
  • Gefällt mir
Reaktionen: Nilson
Legolas schrieb:
Sicherst Du den noch extra ab?
Mein Nginx Proxy übernimmt auch die SSL Absicherung. Alle nachgelagerten Dienste welche Zertifikate erfordern werden vom Proxy mit Zertifikaten versorgt. Ist für mich einfacher umzusetzen
 
Wenn es als VPN Ersatz dienen soll, wäre mTLS-Auth vielleicht ganz interessant.
Unterm Strich kannst du dich dann bei deinen Webseiten mit einem Zertifikat authentifizieren.
 
Ich habe mich vor ein paar Jahren für traefik entschieden aus folgenden Gründen:
 
  • Gefällt mir
Reaktionen: LieberNetterFlo
+1 für Traefik

ich hab schon

  • haproxy auf einer pfsense
  • Nginx Proxy Manager auf einem Webserver
  • Treafik auf meinem Docker Stack zu hause genutzt

Am besten automatisieren konnte ich den Traefik Stack, darum würde ich den wieder nutzen falls ich etwas brauche. Aktuell laufe ich mit Cloudflare Tunnel und umgehe somit Reverse Proxies :)
 
ich hatte erst NPM als Docker und habe jetzt sowohl meinen Webserver als auch die Reverse Proxys (verschiedene Node-Red Instanzen) über einen Nginx laufen.
Beim NPM im Unraid Docker habe ich es nicht geschafft Fail2Ban zu verknüpfen.

Jetzt läuft es auf einer Ubuntu VM inkl. Fail2Ban und Certbot mit DNS Challenge👍 - Port 80 ist zu.

Gab bislang nicht einen Versuch auf die Reverse Proxys einzudringen per Login, was mich wundert. Selber habe ich Fail2Ban natürlich getestet.

Auf dem Webserver sieht es täglich so aus:
1754378346795.png

Sind solche Angriffsversuche von Bots:
Code:
134.209.159.11 - - [05/Aug/2025:08:08:46 +0200] "GET /.env HTTP/1.1" 404 146 "-" "Mozilla/5.0; Keydrop.io/1.0(onlyscans.com/about);"
134.209.159.11 - - [05/Aug/2025:08:08:46 +0200] "GET /.env HTTP/1.1" 400 248 "-" "Mozilla/5.0; Keydrop.io/1.0(onlyscans.com/about);"
134.209.159.11 - - [05/Aug/2025:08:08:47 +0200] "GET /.git/config HTTP/1.1" 404 146 "-" "Mozilla/5.0; Keydrop.io/1.0(onlyscans.com/about);"
125.17.108.32 - - [05/Aug/2025:02:22:40 +0200] "POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1" 400 150 "-" "-"
125.17.108.32 - - [05/Aug/2025:02:22:41 +0200] "POST /cgi-bin/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/%%32%65%%32%65/bin/sh HTTP/1.1" 400 150 "-" "-"
125.17.108.32 - - [05/Aug/2025:02:22:43 +0200] "POST /hello.world?%ADd+allow_url_include%3d1+%ADd+auto_prepend_file%3dphp://input HTTP/1.1" 404 146 "-" "Custom-AsyncHttpClient"
 
Warum ich von Nginx Proxy Manager auf Caddy & NixOS gewechselt bin

Hi zusammen,

sehr spannendes Thema! Ich war früher selbst in der "Docker + NPM" oder "Traefik" Hölle gefangen. Genau wie @Avenger84 hatte ich riesige Probleme, Fail2Ban sauber mit NPM im Docker zu verknüpfen, weil entweder die Log-Pfade nicht gestimmt haben oder das Docker-Netzwerk die echten Quell-IPs verschleiert hat.

Ich habe vor einer Weile mein komplettes Heimnetzwerk auf NixOS umgebaut und setze dort auf Caddy als nativen System-Dienst (ohne Docker). Ich kann euch sagen: Das ist ein absoluter Gamechanger für die Sicherheit.

Wie ich das aktuell absichere:

  1. Kein Docker-Routing-Chaos mehr: Caddy läuft nativ. Dadurch landen alle Access-Logs perfekt formatiert direkt im journald des Systems. Fail2Ban überwacht einfach nativ das Journal. Erkennt Fail2Ban Bots, die meine Login-Seiten scannen, bannt es die echte IP sofort auf Kernel-Ebene über die Firewall (nftables). Keine Docker-Netzwerk-Brücken, die dazwischenfunken.
  2. Unix Domain Sockets (UDS) statt offener Ports: Viele meiner Backend-Dienste (z.B. Vaultwarden) lauschen gar nicht mehr auf einem TCP-Port (wie localhost:8080). Stattdessen nutzen sie Unix Sockets. Caddy leitet die Anfragen direkt über eine .sock Datei im Arbeitsspeicher an das Backend weiter. Ein Angreifer, der irgendwie ins lokale LAN kommt, kann die Backend-Dienste nicht mal "sehen" oder port-scannen.
  3. Zentrale Security-Header: Da in NixOS alles deklarativer Code ist, habe ich mir ein kleines Helper-Modul geschrieben. Ich füge bei jedem Dienst (egal ob Jellyfin, Paperless oder HomeAssistant) einfach eine Zeile wie extraConfig = caddy.proxy port; ein. Das injiziert automatisch:
  • Strikte TLS-Konfiguration
  • Strict-Transport-Security (HSTS)
  • X-Frame-Options DENY
  • X-Content-Type-Options nosniff
CrowdSec und Caddy WAF (wie vom TE erwähnt) sind coole Projekte, aber für den typischen Heimgebrauch reicht ein nativer Caddy + hartes Fail2Ban + Authelia/PocketID als SSO davor völlig aus, solange die Basis (kein Docker-IP-Leak) stimmt.

Falls jemand mal den "NixOS-Way" für Caddy ausprobieren will, kann ich gerne Snippets teilen!
 
Zurück
Oben