Docker über https absichern

[r00b]

Hallo zusammen,
ich versuche gerade herauszufinden wie ich meine Docker-Container absichern kann. Ich nutze sie zwar nur im lokalen Netzwerk (oder per VPN) aber sollte sich doch mal jemand Zugang dazu verschaffen, würde ich mich wohler fühlen, wenn die Verbindungen verschlüsselt wären.

Jetzt war meine Idee die Container über https erreichbar zu machen, doch so wie ich das sehe müsste ich dazu meine Synology per DDNS erreichbar sein und ich müsste Ports freigeben. Das erscheint mir allerdings riskanter als die Wahrscheinlichkeit, dass sich tatsächlich jemand unerwünschtes in meinem Netz befindet. Gibt es alternative Möglichkeiten die Verbindung zu verschlüsseln?

Danke!

 

[EDvonSchleck]

Das machst du einfach über den Reverse Proxy. Siehe Anmeldeportal > Erweitert.

Dort gibst du den Eingang an und leitest den auf den Container weiter. Ich würde alles über den Port 443 extern laufen lassen.

 

[MattCB]

Wenn du die von den Container verwendeten Ports nicht im Router freigibst, kann auch niemand von außen drauf zugreifen. Und über welche Container reden wir? Ein Zugriff von außen macht ja nicht bei jedem Container Sinn.

Ich nutze für meinen Vaultwarden-Container den standardmäßig vorhandenen Reverse Proxy. Dort habe ich einen Eintrag angelegt (z.B. vaultwarden.meineddns.synology.me) und das ganze auf localhost und den für Vaultwarden vorgesehenen Port geleitet. Somit kann ich über eine HTTPS-Verbindung auf meinen Passwort-Manager zugreifen. Die Verbindung ist mit einem Zertifikat von Lets Encrypt abgesichert. Wenn man den Synology-eigenen DynDNS nutzt, kann man sich ein Zertifikat erstellen lassen, das für alle Subdomains gilt. Für den Reverse Proxy musst du im Router nur Port 443 auf dein NAS weiterleiten. Zum Erstellen des Zertifikats (und für das automatische Erneuern) muss aber auch Port 80 offen sein. Aber den kann man nach dem Erstellen oder Erneuern des Zertifikats wieder schließen.

Dir muss dann allerdings bewusst sein, dass dann jeder den Container ansprechen kann, der die Adresse kennt. Deshalb sind sichere Passwörter Pflicht. Die sicherste Variante ist natürlich immer noch, das ganze nur per VPN zu machen.

 

[Lambrone]

Hallo zusammen,
ich versuche gerade herauszufinden wie ich meine Docker-Container absichern kann. Ich nutze sie zwar nur im lokalen Netzwerk (oder per VPN) aber sollte sich doch mal jemand Zugang dazu verschaffen, würde ich mich wohler fühlen, wenn die Verbindungen verschlüsselt wären.

Jetzt war meine Idee die Container über https erreichbar zu machen, doch so wie ich das sehe müsste ich dazu meine Synology per DDNS erreichbar sein und ich müsste Ports freigeben. Das erscheint mir allerdings riskanter als die Wahrscheinlichkeit, dass sich tatsächlich jemand unerwünschtes in meinem Netz befindet. Gibt es alternative Möglichkeiten die Verbindung zu verschlüsseln?

Danke!

Proxyserver einrichen mit einer Subdomain. Certifikat erstellen für die Subdomain. Port anpassen x:443

 

[r00b]

Danke für eure schnellen Rückmeldungen. Eure Vorschläge funktionieren so wie ich verstehe allerdings nur über die Port-Weiterleitung (443). Da mir der Zugriff über VPN ausreicht, würde ich gerne die Port geschlossen halten. Vielleicht bin ich zu Paranoid aber mir ging es jetzt primär darum, dass ich innerhalb des lokalen Netzwerks eine verschlüsselte Verbindung habe (so wie sie auch zu DSM möglich zu sein scheint). Sollte ich bei http bleiben und jemand schafft es doch Zugriff auf mein Netz zu bekommen, könnten ja alle Nutzernamen/Passwörter im Klartext rausgelesen werden, oder täusche ich mich?

 

[EDvonSchleck]

Nein, das funktioniert auch Netzintern. Entweder über IP (manuell akzeptieren oder hinzufügen) oder über eine Domain/DysDNS.
Für eine Domain musst du aber trotzdem erst einmal ein Zertifikat erstellen. Das geht auch ohne Portöffnung mit acme.sh.
Damit diese URL im Netzwerk funktioniert, gibt es unterschiedliche Herangehensweisen.
Eine Domain oder DynDNS lässt sich auch besser für die Anwendungen zuordnen, in dem man einfach ein Subdomain nutzt.

 

[EDvonSchleck]

Zu deiner Angst eines Angreifers. Wenn eine böse Figur im Netzwerk eingedrungen ist, wird eine Schwachstelle oder Zero-Day-Exploit ausreichen, um Zugriff zu erlangen. Dazu muss man nicht unbedingt eine Verschlüsselung knacken, wenn man das umgehen kann. Auch kann unter Umständen die Tastatureingaben geloggt werden und vieles mehr. Alte oder IoT Geräte machen die Sachen auch nicht besser. Sicherheit muss man ganzheitlich denken.

 

[ottosykora]

mir ging es jetzt primär darum, dass ich innerhalb des lokalen Netzwerks eine verschlüsselte Verbindung habe (so wie sie auch zu DSM möglich zu sein scheint). Sollte ich bei http bleiben und jemand schafft es doch Zugriff auf mein Netz zu bekommen, könnten ja alle Nutzernamen/Passwörter im Klartext rausgelesen werden, oder täusche ich mich?

ich verstehe nicht warum sich Leute immer wieder die Mühe machen im lokalen Netz eine Transportverschlüsselung einzurichten. Was da extra sicher sein soll habe ich ehrlich nie verstanden

 

[synfor]

Nicht immer kommt der Angreifer direkt von draußen. Manchmal nutzt der auch schon kompromittierte Geräte innerhalb des lokalen Netzes um sich dort weiter auszubreiten. Oder der Täter kommt von vornherein von innen.

 

[r00b]

Nein, das funktioniert auch Netzintern. Entweder über IP (manuell akzeptieren oder hinzufügen) oder über eine Domain/DysDNS.
Für eine Domain musst du aber trotzdem erst einmal ein Zertifikat erstellen. Das geht auch ohne Portöffnung mit acme.sh.
Damit diese URL im Netzwerk funktioniert, gibt es unterschiedliche Herangehensweisen.
Eine Domain oder DynDNS lässt sich auch besser für die Anwendungen zuordnen, in dem man einfach ein Subdomain nutzt.

Danke, damit scheint es zu gehen. Vielleicht bin ich hier zu unwissend, aber habe ich nicht immer noch das Problem, dass auch wenn ich nun vermeintlich über https auf den Container zugreife, die Kommunikation zwischen Proxy und Container wieder über http läuft und somit „abhörbar“ wäre?

 

[ottosykora]

also wenn der Täter von innen kommt...dann braucht man auch kein SSL, der kann sich alles direkt aus den Geräten holen.
Also dieser extra Layer von Security ist für mich nur Aufwand

 

[EDvonSchleck]

@r00b
Meinst du nicht, du übertreibst es? Dann könnte auch im Container etwas stecken, was Daten abgreift!

@ottosykora, der Aufwand ist sehr überschaubar und in 5–10 Minuten eingerichtet, der Rest funktioniert automatisch und ohne Portfreigaben

 

[ottosykora]

...und in jedem anderen Gerät welches damit kommunizieren versucht

 

[r00b]

@EDvonSchleck haha, gut möglich
aber mein Gedanke war, wenn der Weg über den Reverse Proxy so aussieht
Endgerät —(https)—> Reverse Proxy —(http)—> Container,
dann wäre die Strecke zwischen Proxy und Container genauso transparent für jeden, der den Verkehr mitlogt wie wenn ich direkt den Weg
Endgerät —(http)—> Container
gehe. Wenn dem so wäre, dann könnte ich mir den Umweg über den Proxy auch sparen….

 

[EDvonSchleck]

Dazu muss der Container es beherrschen (gibt welche) und zeitlich muss die (Sub)Domain ansprechbar/definiert sein.

Der Reverse Proxy wird ja nicht nur zur Weiterleitung eingesetzt. Du kannst damit einfach ein Zertifikat auf eine Domain/Subdomain/DynDNS aktivieren. Auch lauscht der Reverse Proxy nur auf die eingegebene URL und weist die entsprechend weiter. Es ist damit möglich, viele Anwendungen nur über einen Port laufen zu lassen, mit unterschiedlichen Adressen.

Bei deiner Angst solltest du eher auf analoge Möglichkeiten zurückgreifen. Dann hast du auch kein Vertrauen zur DSM oder Synology. Der Reverse Proxy ist ja nur ein Eintrag für den Webserver und damit ein größter Bestandteil der DS.

Ich bin wirklich sehr kritisch, aber auf deinen Level bin ich (noch) nicht.

 

[r00b]

Analog muss es dann doch nicht sein, hatte nur die Hoffnung, dass man ggfs. mit wenigen einfachen Schritten die Sicherheit erhöhen kann.
Meine Sorge war im Grunde „nur“, dass ggfs. Mal ein infiziertes Gerät in meinem Netzwerk unterwegs ist und ich vermeiden wollte, dass dieses im Klartext alles mitbekommt, was in den Containern läuft.

 

[ottosykora]

ja aber was in Containern läuft zu erfahren, dafür nutzt SSL nicht viel, damit ist der Eingang zu dem Container ja nicht gesichert, nur der 'Kabel' dazwischen

Auch meinen einige Leute mit SSL wird der jeweilige Webserver irgendwie geschützt, und das ist auch nicht der Fall.

 

[ebusynsyn]

Deshalb sind sichere Passwörter Pflicht. Die sicherste Variante ist natürlich immer noch, das ganze nur per VPN zu machen.

Ich habe mein Vaultwarden ebenfalls via ReverseProxy von extern erreichbar gemacht, habe ergänzend zum komplexen, langen Passwort die 2FA-Funktion aktiviert und auch noch Fail2Ban drüber gelegt.

Eine recht gute Anleitung dazu gibt es hier: https://www.synoforum.com/resources/securing-your-vaultwarden-install.140/

Es ist aber nicht so ganz trivial. Du musst die diversen Files auf Deine Installation anpassen und etwas herumexperimentieren. Aktuell prüfe ich etwa einmal im Monat ob die es noch funktioniert.

 

[allahopp]

Zum Erstellen des Zertifikats (und für das automatische Erneuern) muss aber auch Port 80 offen sein. Aber den kann man nach dem Erstellen oder Erneuern des Zertifikats wieder schließen.

Muss ich wirklich im Router den Port 80 öffnen?

Ich habe gestern erstmalig ein Zertifikat über acme.sh erstellt ohne dass im Router ein Port offen ist.

 

[EDvonSchleck]

Wenn du ein Zertifikat über die Synology anforderst – ja,
Wenn es über acme.sh läuft, dann nicht. Das ist ja ein Vorteil von acme.sh neben der automatischen Aktualisierung.