Geuni/ April 28, 2020/ Deutsch/ 0Kommentare

Wir haben in den vorherigen Artikeln zwei Services aufgebaut, die wir im Internet zur Verfügung stellen. Diese sollen einmal über Port 80 (HTTP) und Port 443 (HTTPS) angeboten werden. Wir bräuchten jetzt, bei der Anzahl, noch keinen ReverseProxy, aber perspektivisch wollen wir mehr Services aufbauen und da wird uns das Ding helfen! Deshalb beschäftigen wir uns mal recht früh damit, wie wir sowas aufbauen und vor allem was das ist.

1) Was ist unser Ziel?

Wir wollen alle unsere Services sicher, idealerweise auf Port 443 (nur), einheitlich und zentral gesteuert anbieten können.

2) Was haben wir für Anforderungen?

Wir wollen:

  • alle unsere Services sicher und einheitlich im Internet anbieten,
  • nur an einer Stelle unsere Zertifikate verwalten,
  • alle Services einheitlich sicher anbieten.

3) Was ist ein ReverseProxy?

Ein ReverseProxy ist ein Server oder Service der Anfragen (meist aus dem Internet) annimmt, diese dann (einfach gesagt) verarbeitet und an sein definiertes Ziel (ein Server bzw. Services) weiterreicht. Klingt erstmal einfach. Es ist praktisch ein Mittelsmann. Das Thema kann beliebig kompliziert werden, wir werden aber erstmal einen Reverseproxy dazu nutzen sog. SSl-Offloading zu machen und Services nicht direkt im Internet einzeln anzubieten, sondern immer zentralisiert über den ReverseProxy.

Mittels des ReverseProxy können wir unsere Services vor dem Internet „verstecken“. Verstecken heißt hier, das eis für alle Services einen Server geben wird der im Internet für uns auftritt und nicht beliebig viele. Das hilft uns den „Eingang“ in unser LAN zu kontrollieren. Weiterhin können wir mit einem kleinen Trick (Nutzung von DNS-SubDomains) alle Services über Port 443 mit HTTPS anbieten, egal, welchen Port der Service eigentlich im Hintergrund nutzt.

Diese „Eindämmung“ aller Ports auf 443 macht den Eingang in unser LAN so klein wie möglich. Weiterhin sind wir damit immer auf einem Standardport der von fast jedem Netzwerk aus erreichbar ist. Port 443 ist beim heutigen Standard des Internets unabdingbar und deshalb aus fast jedem Netzwerk aus erreichbar.

Letztlich haben wir dadurch noch den Vorteil, dass wir unser SSL-Parameter unabhängig und zentral vom Service steuern können (das kommt leider erst in Teil 2). Ich werde in meinem Beispiel dazu einen Apache-Docker-Container aufsetzen.

4) Warum Apache und nicht Nginx? Oder anderes?

Dieser Abschnitt ist einer der wenigen, der nicht wirklich rational sein wird, denn ich hab mich für Apache-ReverseProxy entschieden, da ich früher mal was mit Apache gemacht habe, verstand das alles aber nicht und wollte damit weiter machen. Ob das eine gute Entscheidung war, kann ich nicht sagen. Es funktioniert auf jeden Fall und das sehr gut.

Ich habe einmal, testweise, eine NGINX-Docker-Container aufgesetzt und es damit versucht. Ich habe auch erste Schritte wie mit Apache-ReverseProxy geschafft, einige Sachen gingen mit NGINX sogar scheinbar besser, aber ich habe das alles nicht genau getestet und bin dann dennoch bei Apache geblieben.

Gegen NGINX spricht aktuell in meinen Augen nur die Tatsache, das NGINX von F5 gekauft wurde. Ich vergleiche das mit dem Kauf von MySQL durch Oracle. Das ist nicht schlecht für MySQL gewesen, aber es gibt auch Gründe warum Forks dann aus MySQL entstanden sind. Ich sehe das deshalb skeptisch mit NGINX und tendiere nicht nur deshalb erstmal zu Apache. Das war aber nicht der Grund warum, ich mich für Apache entschieden habe.

Das heißt nicht, dass ich per se gegen kommerzielle Lösungen bin. Im Gegenteil, ich komme aus großen Infrastrukturumgebungen und habe so einige „Enterprise-Features“ bei manch einer Anwendung zu schätzen gelernt. Enterprise Umgebungen brauchen einfach andere Features als KMUs und hier, im Blog, arbeiten wir in sehr kleinen Umgebungen für den Heimgebrauch und brauchen deshalb bestimmt keine Enterprisefeatures.

5) Wie sieht unser Netzwerkarchitektur aus?

Da wir hier im eigenen LAN zu Hause sind, setze ich erstmal voraus, dass wir keine sog. Innentäter haben. Wir setzen auch erstmal nicht darauf, dass wir unser LAN intern absichern (mit einer DMZ bspw.). Solltet ihr sehr viele Geräte haben, bspw. eine Heimsteuerung, die über die Heizkörper hinausgeht und sowas wie eine Wasserpumpe, Klimaanlage, Heizkessel und ähnliches steuert, würde ich eine Segmentierung eures Netzwerkes schon empfehlen, denn nicht alles muss mit allen Geräten im Netzwerk kommunizieren können. Das ist aber alles wirklich vom persönlichen Anwendungsfall abhängig und kann nicht so richtig pauschal bezeichnet werden.

Weil wir aber hier in einem sehr kleinen Umfeld arbeiten, beschränken wir uns auf ein sog. Class-C Netz ( erlaubt bis zu 254 Geräte, IPs ändern sich lediglich im vierten Octet). Innerhalb dieses Netzes definieren wir für uns, dass alle IPs von 2-20 „Infrastrukturen“ sind und ab 20 ein DHCP-Rage gilt. Im DHCP-Range versuchen wir nur „Clients“ zu haben; wie ein Smart-TV, Smartphones oder Laptops. Alle Infrastrukturen bekommen immer eine feste IP (das ist wirklich zu empfehlen, bis auf einige wenige Ausnahmen).

Wenn ich etwas schreibe, dann befinden wir uns immer in meinem Netzwerk zu Hause und das hat als Router eine Fritz.Box, dort kann man den DHCP-Range an der Stelle definieren (Netzwerk -> Netzwerkeinstellungen -> IPv4-Adressen):

Fritz.Box Einstellung für die lokale IP Range und DHCP Range zur Prüfung welche IP der ReverseProxy erhalten kann.
Fritz.Box Einstellung für die lokale IP Range und DHCP Range.

Wenn ihr da hinein navigiert habt, dann solltet ihr in den folgenden Dialog kommen. Hier seht ihr jetzt einige IPs. Ich werde erstmal nicht alle erklären, denn unser Ziel ist nur zu schauen, dass bei DHCP-Server in den Zeilen „von“ und „bis“ das vierte Feld (sog. vierte Octet) von 20 bis bspw. 201 geht. Das „bis“ darf nicht größer als 254 sein.

Fritz.Box Einstellung für die lokale IP Range und DHCP Range.

Damit haben wir jetzt eine DHCP-Range (wenn wir es nicht schon hatten) für alle Clients. Alle Geräte erhalten so erstmal direkt eine IP aus diesem Bereich. Alle „Infrastrukturen“ die wir aufsetzen werden, können wir manuell auf eine IP unterhalb der DHCP-Range einstellen und sollten nie einen IP-Konflikt herbeirufen.

6) Docker oder VM?

Das ist jetzt eine evtl. philosophische Frage, oder eine Frage der vorhanden Ressourcen. In jeder größeren Umgebung würde ich immer einen eigenen Server für einen ReverseProxy empfehlen. In unserer kleinen Umgebung empfehle ich aus Ressourcengründen und aus Gründen des betrieblichen Aufwands einen Docker-Container. Vergleichen wir mal technische Zahlen der beiden Optionen in der nachfolgenden Tabelle.

EigenschaftDockerVM
RAM200 MB1 GB
HDD200 MB5 GB
Betrieb (subj. Aufw.)wenigmittel
Dokumentationgutmittel

Die CPU Belastung beider Optionen ist gleich. Deshalb ist das nicht in der Tabelle. Die RAM Belastung im Docker ist sehr gering. Da reden wir von ca. 200 MB. Ich mache das alles auf einer Qnap und die nutzt die sog. „Virtualisation Station“ für VMs und leider, das ist unabhängig von der VM, verbraucht die „Virtualisation Station“ schon min 1GB RAM, den wir hier, weil ich sonst nichts anderes in einer VM habe, hinzurechnen müssen.

Danach haben wir die Eigenschaft HDD, die als Festplattennverbrauch anzusehen ist, ein Docker-Container braucht ca. 200 MB wieder, die VM, wegen des OS, mindestens 5GB. Auf unserem NAS haben wir zwar, so gehe ich von aus, keine Probleme mit Plattenplatz, aber dennoch ist es eine Eigenschaft die im Vergleich herangezogen werden sollte, wenn es bei jemandem doch anders ist.

Die letzten zwei Eigenschaften sind eine „Experten-Einschätzung“ von mir. Mit Betrieb rede ich von der Menge an Arbeit die mich die Lösung im Alltag kostet. Stürzt diese ab? Kommen häufig Patche? Muss ich häufig was anpassen? Ich schätze den Container mit sehr wenig Aufwand ein, eine VM mit deutlich mehr, denn OS-Patches kommen fast monatlich heraus und 3rd-Party-Patche ebenfalls, die man regelmäßig installieren muss.

Dokumentation ist immer so eine Sache. Docker, wenn man sog. YML-Dateien benutzt, dann ist die Dokumentation super, denn dort steht alles was Infrastrukturell ist, beschrieben. Bei einem OS ist das leider nicht so, damit geht der Dokumentationspunkt an die Docker-Lösung. Apache müssen wir hier nicht vergleichen, denn da sind beide Lösungen identisch.

Demnach kommt für mich, für zu Hause, die Docker-Lösung in Frage.

7) Wie ist unser Namenskonzept?

Ich habe das oben schon erwähnt, wir werden mit sog. Sub-Domains arbeiten. Das können wir zum einen sehr einfach mit FreeDNS machen, denn da können wir so viele Sub-Domains einrichten wie uns passt. Weiterhin ist die Handhabung im ReverseProxy damit sehr einfach! Warum das so ist, werde ich später erklären, dass hat was mit sog. „Rewrites“ auf dem ReverseProxy zu tun. Diese sind komplizierter als die Nutzung von SubDomains.

Starten wir mit der Erklärung was eine Sub-Domain ist, woran ich diese erkenne und wie ich diese auf FreeDNS einrichte.

FreeDNS Admin-Ui zur Verwaltung der eigenen Domains

Eine Sub-Domain ist immer „prefix.domain.tld“. Ihr habt eine Domain die auf „DE“, „COM“ oder sonst was endet. Wenn ihr einen „Prefix.“ vor eure Domain schreibt, wird das eine Sub-Domain genannt und diese können wir im FreeDNS Admin-Web-Ui anlegen. Da wir bis jetzt nur 2 Services haben, unser Qnap Web-UI und unseren Card/CalDav Server, werde ich das Qnap-UI auf die „root“ der Domain legen, also auf „domain.tld“ und unseren Card/CalDav Server, weil die Software Radicale heißt, können wir bspw. die Sub-Domain „radicale.domain.tld“ nennen. Für jeden weiteren Service den wir aufbauen werden, folgen wir diesem Schema, wir legen immer eine Sub-Domain je Service an.

Subdomain Ansicht in FreeDNS Admin-UI mit hinterlegter IP oder dynamischer IP
Dialog zum Anlegen von neuen Subdomains oder sog. Records

Wenn wir jetzt FreeDNS nutzen, können wir eine Sub-Domain einfach anlegen indem wir im Navigationsmenü links auf „Subdomain“ klicken. Dort sollten wir dann eine Auflistung unserer Domains sehen und dessen Subdomains, wenn vorhanden. Mit einem Klick auf „add“ (oben rechts bei der Domain) können wir eine Subdomain anlegen. Eine SubDomain legen wir als sog. A-Record an. Im Feld „SubDomain“ kommt für unser Beispiel „radicale“ rein. Im Feld „Destination“ sollte, wenn euer Dyn-DNS korrekt eingerichtet ist schon eure IP stehen. Es kann sein, dass ihr beim DropDown „Domain“ nicht stealth (wie im Bild) auswählen könnt, das ist aber nicht schlimm. Lasst einfach den Default.

8) Wie setze ich den Container auf? – Netzwerkvoraussetzung

Wie ich oben beschrieben habe, soll der Cointainer eine eigene IP erhalten. Damit das geht, müssen wir erstmal per SSH auf dem NAS prüfen, ob unsere Container-Station überhaupt schon ein Netzwerk korrekt konfiguriert hat, sodass wir dem Container auch wirklich eine eigene IP geben können. Wie erwähnt, brauchen wir dazu SSH und das prüfen wir in der Qnap unter „Systemsteuerung -> Netzerk und Dateiservices -> Telnet/SSH“. Dort müssen wir einen Haken setzen bei „SSH-Verbindungen zulassen (…)“ und den Port dazu bestimmen. Standard ist 22, man sollte diesen aber ändern, denn wenn man jemals Port 22 im Internet freigibt, wird man schnell feststellen das ganz viele Menschen danach suchen und versuchen werden euch zu Bruteforcen (versuchen Benutzername und Passwort zu erraten um Zugang zu erlangen) oder ähnliches (wir werden hier Port 22, oder euren definierten Port, nicht im Internet freigeben!).

Qnap Systemsteuerung zur Konfiguration des SSH-Dienstes

Wenn wir das haben, sollten wir noch schauen mit welchem Benutzer wir SSH Zugriffe machen wollen. Dazu prüfen wir das unter „Zugangsrechte bearbeiten“. Dort tauchen nur die Benutzer auf, die in der Benutzergruppe „Administratoren“ sind. Wenn ein Benutzer also in dieser Gruppe ist, sollte dieser hier auch bei „Zugangsrechte bearbeiten“ auftauchen. Ich werde immer mit dem „admin“ Benutzer unter SSH arbeiten, damit ich so wenig Berechtigungen wie möglich verändern muss um das NAS soweit es geht im „Standard“ zu lassen. Das heißt, für alle die das anders machen wollen, ihr müsst selber eure Berechtigungen für einige Dateien immer wieder anpassen, sodass ihr mit den Daten arbeiten könnt, oder ihr müsst ganz häufig den „sudo“ Befehl vor einen Command setzen damit ihr diesen ausführen könnt.

Jetzt nehmen wir ein Tool wie Putty um uns per SSH auf das NAS zu verbinden (Interne IP verwenden und dann den konfigurierten Port).

Benutzername und Passwort eingeben, angemeldet.

Wir müssen jetzt schauen ob wir schon ein geeignetes Netzwerk in der Container-Station haben, welches wir für eine IP-Vergabe für einen Container benutzen können. Dazu muss man wissen, dass die Container-Station nur die QNap eigene Implementierung von Docker ist. Demnach sollte sich alles was wir hier machen, in so ziemlich jeder weiteren Dockerumgebung anwenden lassen. Wir tippen den folgenden Befehl in unsere SSH-Konsole ein und erhalten eine kleine Tabelle als Ausgabe:

docker network ls

Was heißt das jetzt? Die erste Zeile sind die Namen der Eigenschaften, die recht sprechend sind. Die „Network ID“ ist uns recht egal, die Namen sind uns wichtig, denn die werden wir später für die sog. YML-Datei brauchen. Der Driver bezeichnet „kryptisch“ die grundlegenden Konfiguration und Funktion des virtuellen Netzwerks.

Driver „bridge“ heißt, dass das NAS ein sog NAT anlegt und euren Container dahinter in einem eigenen Netzwerk versteckt. „host“ heißt, dass der Container als Teil des NAS (IP-technisch gesehen wird) und alle Ports die der Container aufmacht, direkt auf der IP des NAS aufgemacht werden (kann bei Portüberschneidungen zu Problemen führen, da ein Port nur einmal von einer Anwendung genutzt werden kann). „null“ heißt, dass es nichts macht. Das ist wie kein Netzwerk haben. „qnet“ ist das was wir brauchen, denn hier wird das sog. Spanning-Tree Protokoll angewendet und damit können wir dem Container eine eigene IP geben ohne das wir dazu mehrere Netzwerkkarten benötigen (wobei das möglich wäre mit der Qnap, natürlich abhängig vom Model). Aber genau hier, kann es sein, dass bei euch dieses Netzwerk fehlt, welches den Parameter „qnet“ hat! Damit wir jetzt das ganze so einfach wie möglich anlegen, nutzen wir einen Umweg.

Wir gehen in unser Web-UI der Qnap rein und starten die Container Station (solltet ihr natürlich zuvor installiert haben). Dort legen wir jetzt einfach einen Container an, bei mir im Beispiel nehme ich den Apache-ReverseProxy-Docker von Bitnami und klicke auf Create.

Qnap Container-Station Docker Implementierung, Anlage von neuem Container mit statischer IP

Jetzt kommt ein weiterer Dialog, der erstmal anders aussieht wie das Bild! Wir klicken aber jetzt mal auf „Advanced Settings“ und gehen links auf „Network“, dann siehts aus wie im Bild! Als „Network Mode“ wählen wir im drop down Menü „Bridge“ aus (nicht wundern, die Namen „Bridge, NAT und host“ werden zwischen dem Qnap-Web-Ui/Container Station und Docker unterschiedlich verwendet!). Dann können wir unsere Netzwerkschnittstelle wählen. Da nehmen wir den Adapter, an dem auch ein Netzwerkkabel dran ist und sagen dann „Use static IP“. Dort tragen wir nun eine lokale IP gemäß unserem mini IP-Konzept von vorher ein.

Wichtig: Wir machen das nur, damit das NAS jetzt nach euren Konfigurationen automatisch für Docker/Container Station ein Netzwerk anlegt, das wir gleich auch per SSH recht einfach ansprechen und nutzen können. Wir hätten das jetzt auch alles per SSH und Docker Befehlen machen können. Das ist etwas komplizierter und so sollte es für alle am einfachsten passen. Den Container können wir, sobald er angelegt ist, wieder löschen. Wenn wir das gemacht haben, wechseln wir wieder in die SSH-Konsole und tippen erneut den Befehl für die Docker-Netzwerke ein und sollten dann in der Tabelle einen Eintrag haben, der als „Drive“ „qnet“ hat. Wie es bei mir oben im Bild schon der Fall ist.

9) Wie setze ich den Container auf? – Dateistruktur

Leider sind wir immer noch nicht soweit, dass wir den Container in einer Form aufsetzen können, wie es unserem Anspruch gerecht wäre! Es ist aber nicht mehr viel. Wir müssen jetzt die Dateistruktur/Ordnerstruktur in der wir die persistenten Daten des Containers ablegen werden, erstellen. Das machen wir idealerweise per SMB über den Windows-File-Explorer. Da greifen wir auf unser NAS zu und sollten einen Freigabeordner mit dem Namen „Container“ sehen. Dieser wird von der Container-Station angelegt und hat sowieso schon alle Daten der Container dort standardmäßig abgelegt und da legen wir auch unsere Daten rein bzw. definieren wo wir dort unsere Daten drin haben wollen.

Solltet ihr den Ordner nicht sehen, prüft im Web-Ui des NAS unter „Systemsteuerung -> Rechte -> Freigabeordner“ ob euer Benutzer, mit dem ihr auf SMB zugreift, auch Schreibrechte auf den Freigabeordner „Container“ hat. Falls nicht, solltet ihr euch diese geben, indem ihr bei „Container“ (wie im Bild), ganz rechts auf das zweite Symbol klickt und euren Benutzer Schreibrechte auf das Verzeichnis gebt.

Qnap Web-UI Systemsteuerung zur Rechtevergabe auf Freigabeordner

Ok. In unserem Beispiel werde ich jetzt mal vorgeben wie die Ordnerstruktur sein wird. Ihr legt auf eurem NAS im Freigabeordner „Container“ einen Ordner an mit dem Namen „apache“ und einen Ordner mit dem Namen „letsencrypt“. Im Ordner „apache“ legt ihr noch einen Ordner mit dem Namen „logs“ an. Im Ordner „letsencrypt“ legt ihr noch einen Ordner mit dem Namen „data“ an. WICHTIG: Wir arbeiten hier letztlich immer auf einem Linux-OS, das heißt, Groß- und Kleinschreibung macht einen Unterschied! Demnach immer darauf achten, dass ist nämlich gern ein Fehler!

Fertig mit den Ordnern. Jetzt arbeiten wir in der SSH-Konsole weiter und verwenden mal alles was wir gerade vorbereitet haben.

10) Wie setze ich den Container auf? – Die YML-Datei für Docker-Compose

Wir haben unser Fundament fertiggestellt. Jetzt schreiben wir unsere sog. YML-Datei. YML steht für „Yet another Markup Language“ und wird innerhalb von Docker für die Beschreibung und Installation von Container genutzt. Das würde ich immer empfehlen zu benutzen, denn mit dieser Datei könnt ihr eure Container immer in jeder Dockerumgebung mit einem Befehl einfach neu aufbauen. Ebenfalls hilft uns diese Datei, wenn wir die Container updaten wollen.

Nachfolgend meine YML-Datei für den Apache-ReverseProxy! Ihr könnt diese wahrscheinlich nicht einfach so übernehmen, ihr werdet ein wenig ändern müssen damit es bei euch geht. Deshalb erkläre ich unterhalb des Codes was es alles mit den Zeilen auf sich hat.

WICHTIG: YML arbeitet mit Einrücken als Block-Kennzeichnung. Würdet ihr jetzt z.B. in der Config unten das Wort „apache:“ in Zeile 4, ganz nach links schieben, würde der Docker-Compose (das Tool das die Datei verarbeitet) einen Fehler beim verarbeiten der Datei ausspucken, denn diese Zeile definiert einen Service und gehört damit „in“ (also mindestens ein Leerzeichen weiter eingerückt) den „services:“ Block und nicht auf die gleiche Ebene! In anderen Markup- oder Programmiersprachen wird sowas meist durch Klammern ( [ , (, { ) gelöst. Vorweg noch, ich glieder meine YML-Dateien immer in Services, dann Volumes und dann Netzwerke. Ich versuche das immer deutlich durch Kommentare zu kennzeichnen. Eine YML-Datei beginnt immer mit dem „version“ Tag. Wir nutzen Version 2, auch wenn es schon Version 3 gibt.

version: '2'
# ---------------------------
# Services
# ---------------------------
services:
#apache                
    apache:
        container_name: apache
        hostname: apache
        mac_address: xx:xx:xx:xx:xx:xx
        restart: always
        image: bitnami/apache:latest
        volumes:
            - apache_data:/bitnami
            - apache_logs:/logs
            - apache_letsencrypt:/letsencrypt
        networks:
            qnet-static-bond0-ae19be:
                ipv4_address: 192.xxx.xxx.14

# ---------------------------
# Volumes
# ---------------------------
volumes:
######### APACHE
    apache_letsencrypt:
        driver_opts:
            type: none
            device: /share/Container/letsencrypt/
            o: bind
    apache_data:
        driver_opts:
            type: none
            device: /share/Container/apache/
            o: bind
    apache_logs:
        driver_opts:
            type: none
            device: /share/Container/apache/logs/
            o: bind
# ---------------------------
# Network
# ---------------------------
networks:
    qnet-static-bond0-ae19be:
        external: true

11) Wie setze ich den Container auf? – Erklärung des Services-Block

Fangen wir an mit dem Services-Block. Auf der erstem Eben wird der Name des Services eingerückt (Die Zeile „apache:“ im Beispiel oben). Ich kommentiere immer noch den Namen darüber hinzu (Kommentare beginnen mit einer Raute, #), denn nicht immer ist der Name des Containers gleich dem Service der darin laufen soll.

Danach folgt der „container_name“, sowie der „hostname“, beides Eigenschaften die den Namen des Containers definieren. Die „mac_address“ gebe ich deshalb an (fiktiver Wert, 6x Hexadezimale Werte mit einem Doppelpunkt getrennt), damit ein Router wie eine Fritz.Box nicht bei jedem Neustart eines Containers ein neues Gerät erkennt (sorgt für nicht schöne lange Listen an Unbekannten Geräten in der Fritz.Box), denn die Container erhalten sonst immer eine zufällige Mac beim start.

Der nächste Parameter „Restart“ besagt das Verhalten, wenn der Container mal abstürzen sollte oder das NAS ausgeht, in dem Fall, immer neustarten. „Image“ ist der Verweis des zu benutzenden Container-Images vom Docker-Hub. Die Namenskonvention ist „Anbieter/Anwendung:Version“. Googelt einfach mal nach irgendwas als Container, meisten findet ihr einen Link von einem Anbieter auf Docker-Hub da seht ihr dann die Notation, aber weiter in der YML.

Volumes sind letztlich Laufwerksmappings vom NAS oder dem Host auf dem Docker an sich läuft, in den Container. Die Notation in YML ist einmal möglich wie ich das mache, wo man erst einen Namen für das Volume auf dem NAS angibt und dann, nach einem Doppelpunkt den Pfad im Container angibt, welcher Ordner das sein soll. Das nutzt man dazu, um Daten persisten für einen Container vorzuhalten wie z.B. Konfigurationsdateien für den Apache-Server. Deshalb binden wir hier drei Volumes. Das erste ist der Ordner Bitnami, der ist spezifisch vom Bitnami-Image das wir verwenden und dort sind alle Configs von Apache-ReverseProxy drin. Das zweite Volume ist eines für Apache-Logs und das dritte ist schon mal ein Volume über das wir unser SSL-Zertifikat einbinden werden (wie schon erwähnt, das kommt erst in Teil 2).

Jetzt kommt der letzte Abschnitt für den Container, nämlich „networks:“. Hier definieren wir das Netzwerk des Docker-Containers sowie dessen IP. Wir wollen statische IPs verwenden und müssen deshalb hier in meiner Beispiel-YML den Namen des „qnet-…“ Netzwerks ändern! Bei euch heißt dieser anders. Wie der heißt, dazu müsst ihr hochscrollen und im Abschnitt „Wie setze ich den Container auf? – Netzwerkvoraussetzung“ nach dem Namen eures Netzwerks suchen, welches den Parameter „qnet“ hat und dieses hier eintragen. Die IP solltet ihr nach euren Wünschen anpassen.

12) Wie setze ich den Container auf? – Erklärung des Volume-Block

Jetzt kommen wir in den zweiten Block, „Volumes“. Hier definieren wir jetzt unsere zuvor als Namen angegebenen Volumes. Wir haben drei Volumes, wie schon erklärt. Wichtig hier ist erstmal für euch nur der Pfad den ihr als Absoluten Pfad auf eurem NAS angebt, wo das Volume gespeichert werden soll. Die anderen Eigenschaften sparen wir uns mal in der Erklärung. Die Struktur in der YML ist immer, Name des Volumes, Doppelpunkt, Absatz, Einrücken, Optionen, Doppelpunkt, Absatz, Einrücken, Eigenschaften (nach einem Doppelpunkt, der Wert der Eigenschaft).

13) Wie setze ich den Container auf? – Erklärung des Network-Block

Letzter Block „Network“. Hier muss wieder euer Name für das „qnet-…“ Netzwerk angegeben werden und der Parameter „external: true“, das besagt lediglich, dass es das Netzwerk schon gibt und wir demnach für den Container das bestehende Netzwerk nehmen wollen. Man könnte hier, wenn man das will, auch das Netzwerk vollständig definieren, aber das haben wir auf andere Art und Weiße zuvor schon gemacht und brauchen es deshalb für den Anwendungsfall nicht.

14) Wie setze ich den Container auf? – Docker-Compose benutzen

So, jetzt ist unsere YML fertig und kann ausgeführt werden! Wir speichern diese Datei am besten auf unseren NAS im Freigabeordner „Container“. Dort speichere ich einfach alle meine Daten die was mit meinen Containern zu tun haben und so finde ich das am einfachsten wieder. Ich nenne die Datei „apache.yml“. Jetzt loggen wir uns per SSH auf unser NAS ein, navigieren in das Share „Container“ und führen einen „docker-compose“ Befehle wie folgt aus (wir navigieren vorher in den Ordner wo unsere YML-Datei liegt):

cd /share/Container/
docker-compose -f apache.yml -p apache up

Wenn ihr das ausgeführt habt, sollte Docker auf euer NAS direkt das Bitnami-Apache-Image herunterladen und installieren. Kurze Erklärung, während euer NAS herunterlädt, was ihr da getan habt: „docker-compose“ ruft einfach die Anwendung auf, der Parameter „-f“ sagt, welches YML-File herangezogen werden soll um zu wissen, was zu tun ist. Hier geben wir nur den relativen Pfad zum YML-File an, denn wir haben zuvor in das Verzeichnis navigiert. Der Parameter „-p“ ist nur ein Name für das zu komponierende Projekt und das nennen wir einfach hier „apache“, da kann man aber alles eintragen was man will. Der letzte Parameter „up“ sagt dann, dass wir das alles aufbauen.

Nachdem das erfolgt ist, geht die Ansicht in der Shell direkt in den Container und ihr solltet alle Ausgaben die im Container passieren jetzt direkt als Lauftext in der SSH-Konsole angezeigt bekommen. Wenn ihr da nun raus wollt, ohne den Container zu beenden, drücke man Strg+Z. Wenn ihr versucht mit STRG+C herauszugehen, beendet ihr den Container, was wir erstmal nicht wollen.

Ein Test per Browser auf die interne IP des Containers sollte nun eine Website bringen mit dem Text „It Works!“.

15) Wie konfiguriere ich meinen ReverseProxy Container? – httpd.conf #1

Leider ist es mit installieren des Containers noch nicht getan. Wir müssen zum Beginn ein paar Dateien bearbeiten, die sog. httpd.conf; Das ist die grundlegende Konfiguration des Apache-Servers. Dann entfernen wir noch, ich nennen sie mal Test-Websites von Bitnami, damit wir keine unnötigen Konfigurationen haben und dann erstellen wir unsere sog. virtual Hosts, das sind die Einstellungen die dann sozusagen die Arbeit übernehmen. Wir machen das zum Beginn alles in HTTP und somit unverschlüsselt, SSL fügen wir nach dem wir es geschafft haben hinzu.

Fangen wir also mit der HTTPD.conf an. Diese finden wir, wie wir es zuvor in der YML-Datei definiert haben im Volume mit dem Namen „apache_data“ welches wir auf „/share/Container/apache/“ gelegt haben. Das sollten wir per SMB über unseren Windows-File-Explorer auf unserem NAS im Freigabeordner „Container“ öffnen können. Die Datei sollte nun im Ordner „..\Container\apache\apache\conf“ zu finden sein.

Qnap hat leider manchmal ein komisches Verhalten in meinen Augen was Berechtigungen angeht, deshalb testen wir erstmal ob wir die Datei bearbeiten können. Dazu einfach mit einem Editor/Notepad öffnen, eine kleine Änderung machen und speichern. Wenn das geht, wunderbar, wenn nicht müssen wir uns per SSH auf dem NAS anmelden und den Besitzer der Datei ändern. So müssen wir nicht die grundlegende Berechtigungsstruktur der Datei ändern und erhalten dennoch Schreibrechte. Wenn die Berechtigung kein Problem sind, dann einfach den kleinen Exkurs überspringen.

16) Exkurs: Linux-Berechtigungen verstehen, prüfen und ändern

Wenn wir eine SSH-Sitzung aufgemacht haben, gucken wir uns erstmal die Berechtigungsstruktur an, mit folgendem Befehl (der Pfad kann abweichen bei euch wenn ihr das nicht wie beschrieben aufgesetzt habt):

 ls -al /share/Container/apache/apache/conf/

Das sollte eine Ausgabe über alle Dateien und Ordner in diesem Ordner bringe und uns die Berechtigungsstruktur anzeigen, sowie den Besitzer und die Berechtigungsgruppe. Bei mir sieht das bspw. so aus:

...
-rw-rw-r-- 1 admin administrators 19147 2019-05-26 21:58 httpd.conf
...

Jetzt sollten wir erstmal verstehen wie die Zeile aufgebaut ist. Wichtig, Eigenschaften werden durch ein Leerzeichen getrennt. Demnach ist der erste „Block“ die Berechtigungsstruktur, der nachfolgende Block eine ID dann kommt der Besitzer die Berechtigungsgruppe, die Dateigröße in Bytes, das letzte Änderungsdatum und der Name.

Wichtig zu verstehen ist, was am Anfang der Zeile steht, die Berechtigungsstruktur. Das erste „-“ hier heißt, dass es eine Datei ist, denn wäre es ein Verzeichnis würde da ein „d“ stehen. Nachfolgend kommen 9 Zeichen, immer als 3er-Block zu sehen mit den Werten „r“=read, „w“=write, „x“=execute. Der erste Block sagt welche Rechte der Besitzer hat. Hier „rw“, also Schreib und Leserechte. Der zweite Block bezieht sich auf die Gruppe, hier „administrators“ auch mit „rw“. Der letzte Block bezieht sich auf alle Benutzer des Systems und diese haben hier nur Leserechte „r“. Wenn wir jetzt den Besitzer ändern wollen, auf den Benutzer mit dem wir über SMB zugreifen, tippen wir folgenden Befehl ein:

chown admin:administrators /share/Container/apache/apache/conf/httpd.conf

Die Syntax: chown -> „Change Owner“ ein Leerzeichen und dann der neue Besitzer, nach dem Doppelpunkt die Gruppe und nach einem Leerzeichen der Pfad zur Datei. Hier im Text steht als Besitzer wieder Admin drin, das ändert ihr ggf. auf euren Benutzer ab. Jetzt sollten wir die Datei im Windows-File-Explorer ändern können, wenn es zuvor nicht ging!

17) Wie konfiguriere ich meinen ReverseProxy Container? – httpd.conf #2

Wir fügen in der httpd.conf unter „ServerRoot „/opt/bitnami/apache“ diese zwei Zeilen ein:

ServerSignature Off
ServerTokens Prod

Diese zwei Zeilen härten unseren apache Server ein wenig. Die erste Zeile bewirkt dass der Server bei Fehlerseiten dem Benutzer niemals seine Versionsnummer verrät. Die zweite Zeile sorgt dafür, dass der Server sich immer nur als „Apache“ ausgibt und keine weiteren Informationen preisgibt.

Als nächstes definieren wir auf welchen Ports unser Server lauschen soll. Bitnami hat standardmäßig Port 80 definiert und 443 (das sind Standardports für HTTP und HTTPs), das ändern wir aus meinem persönlichen Interesse auf 8181 und 8443. Dazu ersetzen wir die Zeile mit „Listen 80“ durch:

Listen 8181
Listen 8443

Diese Werte kann jeder nach seinem Belieben verändern, es sollte nur später drauf geachtet werden dann die Änderung einheitlich in den sog. virtual Host Konfigurationen identisch zu halten.

Jetzt kommen wir zur Liste der Module die beim Start von Apache geladen werden sollen. Wir werden ein paar mehr benötigen, als standardmäßig im Bitnami-Container aktiviert sind. Alle nachfolgend erwähnten Module sollte bei euch mit einer # zuvor gekennzeichnet sein und sind damit nicht aktiv, wenn ihr die # vorne entfernt, werden diese Module beim Neustart des Containers geladen. Die Punkte sollen heißen, das da zwischen einige andere Module sind, genannt sind bei mir nur die, die abweichend vom Standard bei mir aktiv sind.

...
LoadModule cache_module modules/mod_cache.so
LoadModule cache_disk_module modules/mod_cache_disk.so
LoadModule cache_socache_module modules/mod_cache_socache.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
...
LoadModule deflate_module modules/mod_deflate.so
...
LoadModule logio_module modules/mod_logio.so
...
LoadModule unique_id_module modules/mod_unique_id.so
...
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_connect_module modules/mod_proxy_connect.so
...
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_fcgi_module modules/mod_proxy_fcgi.so
...
LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so
...
LoadModule slotmem_shm_module modules/mod_slotmem_shm.so
LoadModule ssl_module modules/mod_ssl.so
...
LoadModule dav_module modules/mod_dav.so
...
LoadModule dav_fs_module modules/mod_dav_fs.so
...
LoadModule negotiation_module modules/mod_negotiation.so
...
LoadModule rewrite_module modules/mod_rewrite.so
...

Ich erkläre nicht jedes einzelne Modul. Das wäre zu viel. Ich sage nur, dass wir einige dieser Module jetzt schon verwenden werden, andere erst etwas später in nachfolgenden Beiträgen. Es ist aber nicht schlimm, dass wir die Module jetzt schon laden.

Jetzt suchen wir weiter unten eine Zeile die mit „ServerAdmin“ bezeichnet ist und geben dort unsere E-Mail Adresse an. So können andere herausfinden an wen diese sich wenden sollen, wenn diese Probleme mit eurem Server feststellen.

ServerAdmin user@mail.tld

Der Servername definiert, oh Wunder, den Namen eures Servers. Hierbei solltet ihr aber darauf achten, dass damit der Name der Website auf die zugegriffen werden soll der Name ist. Also eure Domain.

ServerName domain.tld

Die letzte Änderung die wir machen ist das „ErrorLogFormat“ zu ändern. Wir werden später mal den Apache in ein Graylog loggen lassen. Dazu machen wir uns das leben jetzt schon einfach indem wir das Format der Fehler auf ein standard JSON-Format abändern. Dazu sucht ihr die Zeile die mit „ErrorLogFormat“ beginnt und ersetzt diese durch die folgende:

ErrorLogFormat "{\"Timestamp\": \"%{cu}t\",\"Modul\": \"%-m\",\"LogLevel\": \"%-l\",\"ClientIP\": \"%-a\",\"ID\": \"%-L\",\"Message\": \"%M\"}"

Jetzt müssen wir nur den Container neustarten mit:

docker restart apache

Und prüfen, wie ich finde am einfachsten, im Qnap-Web-UI ob der Container ohne Fehler startet. Wenn es Fehler gäbe, startet der Container nicht und zeigt dort, wo hier schwarze Balken in der „Console“ sind an, wo der Syntaxfehler (meist in der Konfiguration) liegt. Leider könnt ihr die Container die ihr per SSH anlegt, nicht über das UI neustarten oder anderweitig verändern. Das geht immer nur per SSH dann. Leider. Ich sagte ja, QNaps eigene Integration von Docker.

QNap Wen-Ui Ansicht der Container und dessen Consolen

18) Wie konfiguriere ich meinen ReverseProxy Container? – Ballast entfernen

Bitnami bringt zwei vHosts als Standard mit, die wir entfernen, denn wir nutzen diese nicht. Dazu entfernen wir mal die Datei „\\…\Container\apache\apache\conf\bitnami\bitnami.conf“.

Die Datei „\\…\Container\apache\apache\conf\vhosts\00_status-vhost.conf“ leeren wir vollständig, denn diese schreiben wir jetzt neu!

Wichtig zu beachten ist, dass eine Änderung an der Konfiguration erst wirksam wird, wenn ihr den Container neustartet.

19) Wie konfiguriere ich meinen ReverseProxy Container? – virtual host für das NAS #1

Ok, wir fangen hier jetzt mit einem Quickwin an. Wir bauen direkt den HTTP virtual Host für unser NAS auf. Dazu gehen wir, wie zuvor beschrieben in die 00_status-vhost.conf (ihr könntet diese auch umbenennen, alle *.conf-Dateien in dem Ordner werden geladen).

Dort fügen wir die folgenden Zeilen ein:

    <VirtualHost *:8181>
        Servername domain.tld
        ServerAlias www.domain.tld

        <Location "/">
            ProxyPass        http://xxx.xxx.xxx.xxx:8080/
            ProxyPassReverse http://xxx.xxx.xxx.xxx:8080/
        </Location>
    </VirtualHost>

Alles andere aus der Datei sollte man vorerst entfernen, vor allem wenn man nicht weiß, was die Befehle bedeuten. Dieser einzelne vHost hat jetzt nur zwei Funktionen. Die erste Funktion ist, wenn Anfragen auf Port 8181 (<VirtualHost *:8181>) kommen mit der Domain „domain.tld“ (Servername …) oder dem Alias mit dem Prefix www ankommen, sollen die Anfragen nach hinten raus (aus dem ReverseProxy) an die die Adresse „http://xxx.xxx.xxx.xxx:8080/ weitergeleitet werden (ProxyPass, ProxyPassReverse; Syntax: „Protokoll://IP:Port/“). Hier im Beispiel ist für das NAS Port 8080 angegeben, das kann für euer NAS natürlich abweichen, wenn ihr diese Einstellung geändert haben solltet. Die Antworten werden zudem von der gleiche Stelle erwartet. Der Parameter „<Location „/“>“ sagt, dass alle Anfragen für den Servername (beginnend ab der Root-URL) nach hinten weitergeleitet werden. Der Trick hierbei ist, dass der ReverseProxy für den Benuzter (bspw. Anwender der über einen Browser kommt) nicht verrät, das er die Anfragen hinten an einen anderen Server weiterleitet. Der Benutzer glaubt, er spricht einen Server wie das NAS direkt an. Genau das, ist ein Sicherheitsplus für unsere Infrastruktur.

Jetzt müssen wir testen, ob unsere Domain mit dem ReverseProxy funktioniert. Dazu erstellen wir auf unserer Fritz.Box eine Portfreigabe, nach außen hin idealerweiße auf Port 80 und nach innen (in meinem Fall) auf Port 8181 (darauf hört der ReverseProxy). Das sähe in der Fritz.Box so aus.

Port Access Translation (PAT) in der fritz.Box konfigurieren

Den Docker-Container mit dem SSH-Befehl wieder neustarten:

docker restart apache

Wenn wir jetzt, mit einem Browser auf unsere Domain gehen, sollten wir das UI des NAS vorfinden.

Sollte jetzt auf unserer Domain nicht das NAS-UI aufrufbar sein, dann prüft ihr bitte in eurem NAS unter Systemsteuerung ob ihr den Zugriff auf das NAS mit HTTP unterbunden habt! Bei QNAP-Nas kann das an zwei Stellen definiert werden (Systemsteuerung -> Allgemein; Systemsteuerung -> Anwendungen -> WebServer) und sollte an beiden Stellen ausgestellt werden, denn genau diese Sicherheitsfunktion werden wir ja nun selber am ReverseProxy übernehmen. Zudem könntet ihr den NAS-Webserver, wenn euer ReverseProxy funktioniert, ausstellen, dieser hat dann keinen Mehrwert.

20) Exkurs: Unsere neue IT-Architektur

Schematisch haben wir jetzt also folgenden Aufbau:

Schematische Darstellung der Architektur die wir mit einem ReverseProxy aufgebaut haben

Sieht etwas überdimensioniert aus auf den ersten Blick. Ist es aber gar nicht. Denn wir brauchen zukünftig, keine weiteren Änderungen an der FritBox, denn wir können am ReverseProxy alles nun auf der Basis von Subdomains abbilden unabhängig welcher Server im Hintergrund den Dienst nun tatsächlich anbietet. Ende mit dem kleinen Exkurs der IT-Architektur.

Warum nutzen wir vom ReverseProxy zum NAS keine Verschlüsselung? Das hat was mit dem Aufwand im täglichen Betrieb zu tun. Wenn man das ordentlich machen will, muss man das HTTPS-Zertifikat regelmäßig erneuern, da wir uns aber hier im internen Netzwerk befinden, können wir nicht einfach so Lets-Encrypt einsetzen mit sog. Auto-Renewals. Es ist also schlichtweg zu viel Aufwand für uns zu Hause das zu machen. Man kann das natürlich machen, im internen Netzwerk verschlüsselt kommunizieren, nur dann muss man sich im Klaren sein, was das an Aufwand bedeutet. Für mich zu Hause ist das einfach nicht sinnvoll. Hier kämen Stichworte wie eine on-premise PKI zum tragen wenn man ernsthaft über eine solche Lösung mit vollumfänglicher Verschlüsselung anstrebt.

21) Wie konfiguriere ich meinen ReverseProxy Container? – virtual host für Radicale

Jetzt kommen wir zu unseren Kontakte und Kalendern die auf Radicale basieren. Das Ziel das wir haben ist, Radicale über den ReverseProxy sicher aufrufbar zu machen. Dazu werden wir einen neuen vHost in unsere vHost Konfiguration des Apache-Containers hinzufügen (da bauen wir sog. htaccess Sicherheiten ein), Radicale leicht anpassen und feststellen, dass wir damit auch an manch einer stelle ein evtl. komisches Verhalten erhalten werden.

Wir sammeln jetzt erstmal Daten. Dazu gehen wir per LAN-IP auf unser NAS und starten von dort aus Radicale um uns mit dem zuvor schon angelegten Benutzer mal am Radicale-UI anzumelden. Jetzt sehen wir wieder ein Bild wie das nachfolgenden und dort stehen alle Informationen die für den vHost (später im Text) brauchen werden. Wir nutzen diese Informationen demnach später.

Radicale Web-Ui Ansicht wenn man in einem Account ist und die URLs der angelegten Kontakte und Kalender sehen kann

Jetzt ändern wir die Form der Authentifizierung von Radicale, sodass wir die Authentifizierung an unserem ReverseProxy vornehmen können. Das hilft uns an der Stelle, dass wir perspektivisch alles über ein zentrales Active-Directory abbilden können und ansonsten haben wir es erstmal zentral an einem Server und nicht verteil in jeder Anwendung.

Dazu suchen wir die Config-Datei von Radicale die sich im versteckten „.qpkg“-Verzeichnis auf dem NAS für üblich unter „/share/CACHEDEV1_DATA/.qpkg/Radicale/config/config“ befindet und ändern dort die unten stehenden Zeilen wie beschrieben ab.

[auth]

# Authentication method
# Value: none | htpasswd | remote_user | http_x_remote_user
type = http_x_remote_user

Jetzt starten wir Radicale neu, indem wir im NAS-UI im App-Center auf den Reiter Qnap-Club gehen, dort Radicale suchen und auf den kleinen Pfeil klicken. Ein sog. Kontextmenü sollte aufgehen in dem auswählbar ist, dass wir Radicale beenden können und dann starten wir es einfach wieder. Das kann manchmal ein wenig dauern.

Radicale über das App-Center des NAS neustarten

Jetzt brauchen wir noch den weitern vHost in der Apache-ReverseProxy-Konfiguration. Dazu öffnen wir die vHost Datei die wir zuvor genutzt haben und fügen die folgenden Zeilen unten ein.

    <VirtualHost *:8181>
        Servername radicale.domain.tld
        <Location "/">
            AuthType      Basic
            AuthName      "Radicale - Password Required"
            AuthUserFile  "/bitnami/apache/conf/vhosts/htaccess/htpasswd.txt"
            Require       valid-user

            ProxyPass        http://192.xxx.xxx.xxx:5232/ retry=0 timeout=60 Keepalive=on
            ProxyPassReverse http://192.xxx.xxx.xxx:5232/
            RequestHeader    set X-Script-Name "/"
            RequestHeader    set X-Remote-User expr=%{REMOTE_USER}
        </Location>
    </VirtualHost>

Neue Befehle hier sind:

BefehlWertBeschreibung
AuthTypeBasicDas Beschreibt, dass wir eine sog. htpasswd-Datei für die Authentifizierung nutzen werden.
AuthName„Radicale – Password Required“Das ist nur der Anzeigename des Anmeldefenster im Browsers.
AuthUserFile„/bitnami/apache/conf/vhosts/htaccess/htpasswd.txt“Der Pfad im Container, wo sich die htpasswd Datei befinden soll. Dieser Pfad weicht von dem ab, den wir über SMB dafür ansprechen werden.
Requirevalid-userBesagt, dass bei der Anmeldung ein Benutzer aus der benannten Datei sein muss mit Passwort.
RequestHeaderset X-Script-Name „/“Radicalespetzifischer Wert, der für die korrekte Ausführung von Scripten genutzt wird.
RequestHeaderset X-Remote-User expr=%{REMOTE_USER}Radicalespezifischer Parameter der mit der X-Header Config von Radicale übereinstimmt für Benutzerweitergabe

Jetzt sollten wir noch auf FreeDNS schauen ob wir schon eine passende SubDomain angelegt haben. Dazu einfach auf FreeDNS in den Menüpunkt „Subdomains“ gehen und dann wie im Bild, rechts oben auf „add“ eine neue SubDomain eintragen.

FreeDNS SubDomain Ansicht wie u.a. eine neue Subdomain hinzugefügt werden kann

Damit jetzt die Authentifizierung über den ReverseProxy mittels htaccess funktioniert, generieren wir uns mal den Verschlüsselten Inhalt auf einer Seite wie dieser. Wir erzeugen hier einfach einen Benutzernamen und ein Passwort. Die verschlüsselte Zeile kopieren wir in unser Clipboard. Jetzt legen wir per SMB im Apache-Ordner (\\ip\Container\apache\apache\conf\vhosts\htaccess) eine Datei mit dem Namen „htpasswd.txt“ (den Namen haben wir im vHost definiert, könnt ihr auch gern ändern). Das können wir alles über den Windows-File-Explorer machen. Jetzt fügen wir unser Clipboard hier ein und speichern das. Hier im Code ist jetzt der Benutzer „test“ mit dem Passwort „test“ angegeben.

test:$apr1$pIGPLD.z$aV2WuIV5jbkGWiEpSIP3e/

Wenn ihr jetzt eure Clients, wie bspw. DavDroid/Davx5 auf eure Domain umstellt, solltet ihr euch mit dem definierten Benutzer in der htaccess-Datei anmelden können.

Was jetzt ein kleiner Hinkefuß ist, ist, dass wenn man sich per Domain auf Radicale im Web-UI anmelden will, kommt erst eine Benutzername/Passwort Abfrage, dann landet ihr auf dem Web-Ui wo ihr wieder aufgefordert werdet Benutzername und Passwort einzugeben. Das bringt aber nur bedingt was, denn mit dem X-Header wird der bereits eingegeben Name an Radicale weitergegeben, also könnt ihr hier nichts oder irgendwas eingeben und landet in eurem Account. Wenn ihr jetzt aber einen gültigen anderen Benutzernamen und Passwort eingebt, landet ihr wiederum in dessen Account. Leicht skuril, stört uns aber erstmal nicht, denn alle Clients die Synchronisieren, haben damit keine Problemen und wir können dennoch nicht Cross-Benutzer auf URLs nach der Anmeldung zugreifen. Also nur komisch in der Handhabung.

22) Wie greifen meine Clients jetzt auf die Services zu? LAN vs. WAN.

Wir haben jetzt beide Wege offen für den Zugriff, den Weg aus unserem eigene LAN und den Weg über das Internet (WAN) auf Basis unserer Domain. Damit es für uns in der Handhabung am einfachsten ist, würde ich nun empfehlen, dass wir immer über die WAN-Adresse, sprich unsere Domain ansprechen. Es ist natürlich nicht immer sinnvoll über seine Domain-Adresse zu gehen. Wir haben aber einfach wenig Datenverkehr, weshalb wir schlicht den einfachsten Weg gehen können. Wenn man in größeren Umgebungen unterwegs ist, dann ist eine Unterscheidung zwischen LAN und WAN sinnvoll, denn im LAN haben wir natürlich kürzere Wege und schnellere Übertragungsraten.

23) Fazit

Wir haben trotz viel arbeit es hier noch nicht geschafft unsere Verbindung mit HTTPs abzusichern. Das liegt daran, dass es mit Containern nicht all zu einfach ist, wenn man verstehen will was da passiert und wie es zusammenspielt. Wir werden das deshalb im nachfolgenden Artikel genau erklären.

24) Ausblick

Wir bauen einen Container mit der Software Certbot und lassen diesen mit dem Apache-Container interagieren und sorgen dafür, dass wir nur noch HTTPs nutzen werden. Wir werden einige sog. SSL-Parameter einbauen die unsere Verbindung möglichst sicher und abwärtskompatibel machen (Sprichwort SSL-Ciphers). Wir werden nicht das Maximum an Sicherheit erreichen, denn wir werden erstmal kein Public-Key-Pinning machen und keine „Content Security Policy“ (CSP) und das ist der Artikel!

Share this Post

Hinterlasse einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*
*