bitwarten (Docker) über (Sub-) Domain zugreifbar machen

[LORDNIKON1]

Hi Leute,

ich bastle mal wieder. Habe mich nach eingehender Lektüre dazu entschlossen bitwarden zu nutzen. Das sieht alles wirklich gut aus und bringt mich meinem Ziel näher, komplett unabhängig zu sein von Anbietern, insbesondere mit einem so heiklen Thema.

bitwarden läuft soweit, kann intern darauf zugreifen.

Nun geht es um den Zugriff von außen - denn ich möchte auch mit Clients auf den Server zugreifen.

Habe eine Subdomain dafür eingerichtet, dafür mit CNAME auf DDNS verwiesen (löppt auch soweit, sagt NS-LU). Auf der DS Reverse Proxy eingerichtet. Komme von extern an bei 5152 (Port ist weitergeleitet in Router), intern dann Localhost an 5151.




Ergebnis: 404 (ergänzt dann bei der Domain hinten /defaultsite) , bzw. wenn ich xxx.tld.de:5152 eingebe, dann kommt die Synology Seite "Die Seite konnte leider nicht gefunden werden".

Wie gesagt, intern geht das; also interne IP:5151 führt zur bw-Startseite.

Was übersehe ich?


Gruß
LN1


Edit: Nach Neustart der DS insgesamt (hilft ja immer wieder mal), nun die "Weltkugel" also die Webstation Seite (ohne Eingabe des Ports, mit Eingabe bleibt es bei der Synology Fehlerseite, s.o.)

 

[blurrrr]

Wenn die Webstation angezeigt wird, bist Du wohl irgendwo falsch abgebogen, denn vom RP sollte es zum Docker-Container gehen und nicht zur Webstation.

EDIT: Hab den Klassiker ganz vergessen: Warum nicht einfach via VPN? ??

 

[LORDNIKON1]

Das dachte ich mir. Muss ja dann aber auf der DS sein, nicht "vorher" oder?
Ja, mit VPN geht das natürlich. Aber das schränkt die Nutzbarkeit für die Clients so ein. Muss dann ja jedes Mal wenn ich drauf zugreifen möchte eine VPN Verbindung aufbauen. Ich entnehme dem, dass Du das empfehlen würdest oder?

... 2 FaktorAuth wird unterstützt. Das sollte doch ausreichen dann, oder?

EDIT: Gleiches Setup nutze ich auch für meine PLEX Installation, dort läuft das einwandfrei so!

 

[blurrrr]

Auf der DS falsch abgebogen, genau Das mit dem VPN, tut mir leid, aber... ja, vorher immer einwählen. Allerdings kann man sowas auch automatisieren (nennt sich dann VPN-on-demand, auf iOS recht leicht umzusetzen, Android braucht da wieder extra Würstchen. Kannst mal hier schauen: https://www.loxwiki.eu/display/LOX/VPN+on-demand. Im Grunde genommen geht es bei der ganzen Klamotte sowieso nur darum, dass eine bestimmte Domain/ein bestimmtes Netz angesprochen wird - darauf reagiert das Ding dann und schaltet vorher das VPN ein. Sprichst Du dann z.B. "lordnikon.local" wird das VPN entsprechend automatisch aktiviert und damit der Zugriff auf das Remotenetz ermöglicht. So musst Du da nicht ständisch "händisch" rumfummeln. Auf der anderen Seite - sind wir mal ehrlich - wie OFT brauchst Du den Bitwarden-Zugang schon, wenn Du unterwegs bist? Ich habe nichtmals einen VPN-Zugang nach Hause ?

Aber VPN hin und VPN her - alles schön und gut, Dein momentanes Problem solltest Du sowieso gelöst bekommen (ganz egal, was Du später machst).

Warum eigentlich überhaupt die extra Ports, wenn Du dafür sowieso eine eigene Subdomain laufen hast? Das hört sich ein bisschen nach "Hose voll" an (?), weswegen ich das sowieso nur über VPN machen würde, aber jedem das seine.

Aber... teste doch erstmal ohne den RP dazwischen... "hübsch" machen kann man später immer noch.

 

[LORDNIKON1]

Wieso meinst extra Ports? Meinst Du den "extra" 5152 von außen?

Und wie meinst Du "ohne den RP" dazwischen? Über die Domain der DS ergänzt um den internen Port?

 

[blurrrr]

Wenn "interne-IP : Port" funktioniert, sollte ebenso "externe-IP : Port" funktionieren (mit entsprechender Portweiterleitung. Das würde ich zunächst einmal testen. Halt ohne den RP dazwischen (womit das DNS-Thema quasi noch "on top" kommt).

 

[LORDNIKON1]

Check ich nicht. Ich greife ja auf die DS per eigener Subdomain und DDNS zu. Wenn Du meinst Zugriff versuchen über DS Subdomain:5151 - dann klappt das jedenfalls nicht.

 

[blurrrr]

Äh... hä? Ich check's grade auch nicht... 5151 ist ja nach "aussen" auch garnicht freigegeben? ?

Also....

sub.domain.tld sub.domain.tld
| |
DynDNS:5152 -> externe IP -> Router ----Portweiterleitung----> NAS:5152 --> RP --> Container(localhost:5151)

Du hast da "oben" zum einen das, was "angefragt" wird (sub.domain.tld), das spielt aber nur an 2-3 Ecken eine Rolle (initialer Aufruf, RP und ggf. im Container). Alles "darunter" ist rein IP-basiert:

Musst auch Dein bisheriges Konstrukt nicht auseinanderpflücken, mach einfach mal eine neue Portweiterleitung am Router:

5555 auf Syno-IP:5151 (also direkt den Container-Port)

und dann guckste einfach mal ob "externe-IP:5555" funktioniert.

 

[LORDNIKON1]

Au man, ich lerne es noch. Das klappt natürlich. Hatte einen (Anfänger-) Fehler in der Portweiterleitung.

Was ich nur nicht check ist, warum die Seite als "unsicher" bezeichnet wird. Liegt das daran, dass die bitwarden Subdomain nicht im ursprünglichen LE Zertifikat enthalten ist? Nachträglich einfügen kann ich sie ja nicht mehr, oder? Bin nur irritiert, weil sie beim LE Zertifikat mit angezeigt wird (mit der Ergänzung :5152)

EDIT: Ah, sehe gerade - da steht "Zertifikat" und unten "für" - dort ist es gelistet.

 

[LORDNIKON1]

Mh, da habe ich mich wohl zu früh gefreut: Kommando zurück. Also wie von Dir beschrieben über 5555 (mit Domain von der DS) funktioniert.
Wenn ich es dann wieder über 5152 und Domain von der bitwarden Installation versuche - nada.

Interessanterweise Verbindung "unsicher" auch hier, obwohl ich ja über die DS Domain unterwegs bin.

 

[blurrrr]

Wenn die angesproche Subdomain nicht im Zertifikat enthalten ist, ist es normal, dass diese Meldung kommt. Hast Du "im" Container denn noch ein eigenes Zertifikat? Wird ja nach intern nach "https" weitergeleitet.

 

[LORDNIKON1]

Die ist ja jetzt enthalten. Nein, im Container kein eigenes Zertifikat. Wusste gar nicht, dass das geht.

Hast Du denn eine Idee warum das so herum geht aber mit dem RP hakelt?

 

[blurrrr]

Dann guck doch mal in das Zertifikat was da kommt, für welche Domains ist das denn? Daran müsstest Du ja auch ausmachen können, wo Du dann entsprechend gelandet bist

 

[LORDNIKON1]

Also ich komme nicht weiter.
Habe nochmal nachgesehen wie die Konfiguration bei der Subdomain ist, die auf Plex zeigt und das 1:1 mal so versucht. Es klappt nicht. Dort kommt die Verbindung über den HTTPS Port 443 rein und wird intern an den Port 32400 weitergegeben. Das klappt einwandfrei.
Auch wenn ich das testweise lösche und anstatt dessen die Subdomain für bitwarden auf den Container zeigen lasse (also 1:1 so wie bei Plex: rein über HTTPS Port 443, weitergegeben intern an 5151), passiert gar nichts.
In der FB habe ich für die Plex keine gesonderte Freigabe, dort komme ich ja für Plex über 443 rein, müsste dann bei bitwarden ja eigentlich genauso funktionieren - tut es aber nicht.

 

[Fusion]

Wenn du kein Problem hast auf der Konsole zu arbeiten kann ich dir später die proxy config (ohne GUI Eintrag) und das docker-compose file geben welches ich benutzt habe.
Das Problem war, dass für volle Funktionalität die Einstellungen in der Gui und bei benutzerdefinierten Header nicht ausgereicht haben.

Nichts desto trotz muss es eigentlich funktionieren den reinen Web Zugriff auf den Bitwarden Tresor auch per GUI Reverse Proxy zu realisieren.
sub.example.com auf 443 mit exakt passendem LE Zertifikat und Web socket Headern (connection upgrade).
Um das dann zu beurteilen bräuchte man die Infos aus den ersten zwei Tabs des Reverse Proxy und die des Docker Containers.

Bloß weil A funktioniert, muss B nicht funktionieren.
Plex hat ganz andere Anforderungen an die benutzerdefinierten Header des Proxy als Bitwarden z.b.

 

[MichaDebuss]

Hi Leute,

ich bastle mal wieder. Habe mich nach eingehender Lektüre dazu entschlossen bitwarden zu nutzen. Das sieht alles wirklich gut aus und bringt mich meinem Ziel näher, komplett unabhängig zu sein von Anbietern, insbesondere mit einem so heiklen Thema.

bitwarden läuft soweit, kann intern darauf zugreifen.

Nun geht es um den Zugriff von außen - denn ich möchte auch mit Clients auf den Server zugreifen.

Habe eine Subdomain dafür eingerichtet, dafür mit CNAME auf DDNS verwiesen (löppt auch soweit, sagt NS-LU). Auf der DS Reverse Proxy eingerichtet. Komme von extern an bei 5152 (Port ist weitergeleitet in Router), intern dann Localhost an 5151.


Anhang anzeigen 61021

Ergebnis: 404 (ergänzt dann bei der Domain hinten /defaultsite) , bzw. wenn ich xxx.tld.de:5152 eingebe, dann kommt die Synology Seite "Die Seite konnte leider nicht gefunden werden".

Wie gesagt, intern geht das; also interne IP:5151 führt zur bw-Startseite.

Was übersehe ich?


Gruß
LN1


Edit: Nach Neustart der DS insgesamt (hilft ja immer wieder mal), nun die "Weltkugel" also die Webstation Seite (ohne Eingabe des Ports, mit Eingabe bleibt es bei der Synology Fehlerseite, s.o.)

Hi,

da du intern auf den localhost gehst, sollte nicht HTTPS, sondern nur HTTP ausgewählt sein.
Des weiteren sollte HSTS noch aktiviert sein.
Versuche das mal...

Gruß

Micha

 

[LORDNIKON1]

Wenn du kein Problem hast auf der Konsole zu arbeiten kann ich dir später die proxy config (ohne GUI Eintrag) und das docker-compose file geben welches ich benutzt habe.

Super gern. Denke mit ein bisschen Geduld und Spucke bekomme ich das hin.
Im Moment habe ich keinen benutzerdefinierten Header eingegeben (siehe nachstehend)

 

[LORDNIKON1]

... habe das Thema gelöst.

Es hakte an den Einstellungen beim Docker Container. Dort unter Allgemeine Einstellungen, Verknüpfung auf Desktop erstellen, war noch die falsche Domain eingegeben. Jetzt funzt es.

Tausend Dank für Euer Mitdenken!

 

[LORDNIKON1]

Darf ich trotzdem nochmal in die Runde fragen: Ich verstehe die Anmerkungen von blurrr gut (zum Thema VPN).

Betreibt das jemand von Euch so oder begnügt Ihr Euch mit "nur HTTPS"?

Die Lösung über "VPN on demand" hört sich natürlich schon charmant an. Weiß nur nicht, ob das am Ende des Tages nicht mit Kanonen auf Spatzen geschossen ist. Am Ende des Tages sind die kritischen PW ohnehin welche, hinter denen 2 Faktor steht. Und wenn ich den zweiten nicht habe/bestätige, komme ich nicht weiter. Oder ist das zu kurz gedacht?

 

[Fusion]

Sehr schön. Siehste mal. So Sachen wie Desktop Verknüpfung für Docker Container und Kram nutze ich überhaupt nicht, weil das zu syno-spezifisch ist (falls man es mal auf einem anderen Docker Host laufen lassen will, oder sich einfach nur eingeschränkt fühlt, oder ...ich kann mir das schon irgendwie rationalisieren. Hehe). Zudem bin ich fast NIE auf dem DSM Desktop unterwegs beim normalen arbeiten, da würde mir die Verknüpfung eh nichts bringen.

tl;dr
Alles was man mit für sich vertretbarem Aufwand an Sicherheit gewinnen kann sollte man angehen.

Bezüglich der Frage des Zugriffs, mehr Sicherheit ist (meistens) besser...
Aber es ist am Ende ein persönlicher Kompromiss. Wenn ich darüber nachgedacht immer noch gut schlafen kann ist es ok. Der Rest ist Verdrängung. Also sicher im Schnitt weniger sicher als es sein sollte, in Gänze vermutlich immer noch besser als bei 90% der Leute da draußen.

Das Konstrukt mit Reverse Proxy ist prinzipiell gut, weil sich z.B. mehrere Dienste hinter einer IP und Port verbergen (unterschieden durch die Hostnamen / SNI). Ändert natürlich nichts daran, dass der Webserver wo das Ganze Geraffel drauf läuft erreichbar ist.
Besser wäre den Reverse Proxy auf einer anderen Maschine laufen zu lassen, die selbst auch wieder isoliert ist und nur Verkehr von/Zu den Proxies schicken darf.

Noch besser, wie angesprochen, wenn es gar nicht von außen erreichbar wäre bzw. indirekt per VPN. Eben auch, weil es sozusagen ein Generalschlag ist womit alle anderen Maßnahmen, die man sich zur Steigerung der Sicherheit im eigenen Netz überlegen kann, erst mal in die zweite Reihe zurück treten.

Hab zwar schon Wireguard (separates Device) und openVPN auf die Syno zur Not. Ist auch on-demand, aber nicht automatisiert.
Werde ich mir aber auch nochmal ansehen, wenn ich mal wieder Zeit über hab. Danke für die Erinnerung @blurrrr (die Baustellen gehen einfach nicht aus...), hast sicher auch einen 12 Seiten Roman zu dem Thema parat? Hihi.

Problem in dem Bereich, wenn man Dienste nicht nur im eigenen Haushalt nutzen will, sondern im erweiterten Familienkreis, steigt der Support Aufwand zumindest vom Zeitbedarf sehr schnell steil an. Ist immer wieder faszinierend wie schnell man als "unbedarfter" (je nach Bereich im Leben kann ich mich da auch ohne Probleme dazu zählen) Benutzer was "kaputt" bekommt, oder einfach Software und OS updates und anderer Kram reinpfuschen. Da habe ich dank Google, Apple und Microsoft sicher schon Tage, Wochen und Monate vernichtet um Dinge wieder gerade zu ziehen (die auch nicht in Changelogs oder sonst wo dokumentiert vorher bekannt wären).

Gerade bei Passwort Managern kann man sich es allerdings mehrfach überlegen, abhängig vom Benutzerkreis.
Wenn der Server bsp. nur lokal LAN/WLAN erreichbar ist (ich hab auch lokal DNS und Zertifikate), und mit den Daten der Sync angelegt ist, funzt das wunderbar. Wenn du unterwegs bist ist der Tresor in letztem Stand auch auf dem Mobile dabei. Änderungen werden halt erst wieder zum Server und auf andere Geräte synchronisiert, wenn der wieder erreichbar ist. Habe das allerdings noch nicht auf die Spitze getrieben und Konflikte produziert in dem ich auf mehreren "offline" Geräten gleichzeitig identische Einträge bearbeitet habe und dann zu sehen was das Ergebnis ist.
Da ist auch die Abwägung, ob man den Aufwand mit Bitwarden treibt (Domain, Zertifikate, ...) oder andere Lösungen heranzieht (bsp. keepass) und den Tresor einfach per Drive, webDAV, SMB/CIFS oder ähnlichem zwischen den Geräten synced auf denen man es benötigt.