Nginx Reverse Proxy: Sicherheit

Avenger84

Lt. Commander
Registriert
Feb. 2008
Beiträge
1.493
Hallo,
ich habe auf meinem Unraid den Nginx Reverse Proxy als Docker installiert (jc21/nginx-proxy-manager Docker)
Der Zugriff auf Dienste wie Node-Red und Grafana funktioniert gut.
Danach habe ich mir noch eine Domain gekauft, diese ist gerade mal 2 Tage alt.
Im Cloudflare Dashboard sehe ich jetzt schon zig Angriffe aus USA, Russland, Kanada, Frankreich:
1704351757303.png


Daher die Frage: wie sicher ist der Nginx Proxy?

ich habe ihn mit "Nutzername" Passwort: abcdefg12 abgesichert (Muster).

Können die o.g. Bots hier per Brute Force unendlich probieren bis sie es geknackt haben oder gibt es im Nginx eine maximale Abfrage?

Im WebUI sehe ich dazu leider gar nichts, also keine erfolglosen oder erfolgreichen Versuche.
Man kann nur sehen dass ich einen Proxy erstellt habe und ein Zertifikat, sonst nix.
 
Das Ding ist an sich schon sehr sicher, aber ich würde einfach die Firewall nutzen und Zugriffe z.B. nur aus Deutschland erlauben oder etwas wie fail2ban nutzen um den Dienst abzusichern.
 
  • Gefällt mir
Reaktionen: h00bi
Ohne die Konfiguration deines nginx zu kennen ist das schwer zu sagen, im allgemeinen ist nginx keine Identitätsmanagement Plattform, damit wird da wahrscheinlich nix dergleichen dahinter sein.

Aber wenn du eh schon cloudflare hast, wieso ein eigener nginx und nicht deren Security Plattform, also deren Zero Trust Platform oder zumindest via worker oder so.

Deine Frage, nicht böse gemeint, deutet darauf hin, dass du dich mit den notwendigen Konzepten nicht hinreichend auseinander gesetzt hast. Du kannst halt ziemlich schnell das Zeug falsch konfigurieren, so dass es mehr Schein als Sein ist.
 
Avenger84 schrieb:
ich habe ihn mit "Nutzername" Passwort: abcdefg12 abgesichert (Muster).
Was genau soll das bedeuten? Dass dein Passwort extrem simpel ist? Oer einfach nur, dass du überhaupt eins hast? Setz ein gutes Passwort mit entsprechender Länge und Komplexität für alle vom Web erreichbaren Dienste und gut ist. Das bruteforced dir dann keiner weg. Eingebaute Accounts dabei natürlich nicht vergessen.

Zu deinen "Angriffen": jeder Webserver der Welt wird zu jeder Zeit von haufenweise Bots abgegrast. Mehr ist in deinem Screenshot auch gar nicht zu sehen. Dann wirst du auch teilweise Bots sehen, die nach bestimmten Unterordnern oder "login.php" Unterseiten suchen und so verwundbare Server mit alter Software aufspüren wollen. Das kannst du kaum verhindern und kann dir auch erstmal egal sein.
 
Da der NGINX nur über den Port 81 "intern" zu erreichen ist, sollte auch niemand von außerhalb darauf zugreifen können. Die Ports 80 und 443 müssen nur nach außen freigegeben werden, damit der NGINX korrekt arbeiten kann. Ich nutze den gleichen Docker Container seit gut 6 Monaten ohne Probleme.

Mir persönlich fehlen jedoch Features, wie beispielsweise das "automatische Prüfen" der aktuellen öffentlichen IP-Adresse. Da ich 98% aller meiner "Domain-Einträge" nur intern erreichbar gemacht habe, nervt das durchaus, wennn mein ISP mir eine neue IP Adresse zuteilt.

Aktuell verwende ich als DynDNS Service DuckDNS. Ich werde aber auf absehbarer Zeit eine alternative suchen müssen, da DuckDNS seit Monaten jeden einzelnen Tag Zusammenbrüche hat und somit "Störungen" bei mir verursacht.
 
Ich würde mir weniger Sorgen um den Nginx machen als um die Dienste dahinter.

Warum stehen diese direkt im Netz? Sicherheitstechnisch sinnvoll wär edas ganze hinter einen ordentlichen VPN zu setzten.
 
  • Gefällt mir
Reaktionen: kieleich
Tornhoof schrieb:
Deine Frage, nicht böse gemeint, deutet darauf hin, dass du dich mit den notwendigen Konzepten nicht hinreichend auseinander gesetzt hast.
Deine Antwort deutet darauf hin, dass du die Frage nicht gelesen hast. Der NPM ist ein „fertiges“ Produkt, da wird der Nginx nicht extra konfiguriert.

@Avenger84
Wie der Vorredner schon gesagt hat, Port 81 nur intern freigeben, die Login Seite ist von außen dann nicht erreichbar. Zusätzlich Dienste per Firewall und / oder fail2ban absichern.
 
Donnidonis schrieb:
Deine Antwort deutet darauf hin, dass du die Frage nicht gelesen hast.
Doch schon gelesen, aber nicht den Namen des docker Images betrachtet. Ist die einzige Stelle wo npm im 1. Post erwähnt wird
 
Schon mal Cloudflare Tunnels verwendet?

Ich möchte nur selten von unterwegs auf meinen Server zugreifen und habe Cloudflare Tunnel so konfiguriert, dass überhaupt nur spezifische email-Adressen durchgelassen werden (mit Code Versendung an diese email)
 
1704377408188.png

8888 ist auf 80 von außen erreichbar
8889 ist auf 443 von außen erreichbar
kokiman schrieb:
Die NPM Images haben leider irgendwie alle kein Fail2Ban integriert, was Bruteforce komplett unterbinden würde und die Sicherheit immens steigern würde.
ok danke, dann weiß ich Bescheid

Mojo1987 schrieb:
Warum stehen diese direkt im Netz? Sicherheitstechnisch sinnvoll wär edas ganze hinter einen ordentlichen VPN zu setzten.
damit ich im Auto auf dem großen Bildschirm arbeiten kann, mein Auto kann kein VPN 🙃
auch sonst ist es sehr praktisch wenn man gerade den WG Tunnel nicht aktivieren kann.
Sonst verwende ich das nur per VPN.

Mein Passwort ist in der Länge: abcedef12 - reicht das für Bots oder muss es sowas sein, was man sich nicht merken kann, so wie in dem Stil: uXv9?#2RtVy+0a ? Wenn Brute Force möglich ist - wer weiß.

Node Red und Grafana sind zwar an sich auch noch mal per Passwort gesichert und nur die Dashboards sichtbar, trotzdem möchte ich auf gar keinen Fall dass irgendein chinesischer, amerikanischer, canadischer oder französicher Hacker/Bot bei mir einloggt ;-)
Ergänzung ()

Dig.Minimalist schrieb:
Ich möchte nur selten von unterwegs auf meinen Server zugreifen und habe Cloudflare Tunnel so konfiguriert, dass überhaupt nur spezifische email-Adressen durchgelassen werden (mit Code Versendung an diese email)
ich möchte permanent im Auto darauf zugreißen und zwar auf 4 Instanzen.
 
Das Problem ist weniger die Passwortlänge, wenngleich 8 Zeichen nichts sind vorallem ohne Bruteforce Protection, sondern viel mehr Sicherheitslücken, wissentlich oder unwissentlich in jeder Software enthalten.
 
  • Gefällt mir
Reaktionen: WeisheitsTroll
mit fail2ban kann man übrigens den gesamten Docker Host einschließlich der Container absichern.
Ist etwas komplizierter, aber sehr zu empfehlen.
Gibt auch etliche Tutorials dafür.

der NPM macht ja fast nichts, daher gibts auch nicht viel Potential für Sicherheitslücken.
Zudem sind sowohl der NPM selbst als auch der jc21 AMD64 Container sehr gut maintained.
Der armv7 Container war eine Weile ein sorgenkind, aber soll mittlerweile auch wieder mehr Liebe erfahren.
 
h00bi schrieb:
mit fail2ban kann man übrigens den gesamten Docker Host einschließlich der Container absichern.
Ist etwas komplizierter, aber sehr zu empfehlen.
Gibt auch etliche Tutorials dafür.
mir würde es schon reichen, wenn es eine Log Datei gibt, wo ich sehe wer(IP) wann auf welche Domain zugegriffen hat !?
 
Dante2000 schrieb:
Aktuell verwende ich als DynDNS Service DuckDNS.
Interessant, nutze ich auch in Zusammenhang mit Traefik(v2), funktioniert hier eigentlich klaglos.

Gibt einen Container für DuckDNS-IP-Updates, nutze ich als Teil meines Stacks seit Beginn.

Code:
#----------------------------------------------------------------------------------------------------------------------------------------------------------
## DuckDNS Host IP Update Container
  duckdns:
    image: lscr.io/linuxserver/duckdns:latest
    container_name: duckdns
    environment:
      - PUID=$PUID
      - PGID=$PGID
      - TZ=$TZ
      - SUBDOMAINS=mydomain #nur die Domain ohne .duckdns.org
      - TOKEN=$DUCKDNS_TOKEN
      - LOG_FILE=true #optional
    volumes:
      - ./appdata/config:/config #optional
    restart: unless-stopped
 
Zurück
Oben