VLAN und Isolierung von Docker Containern

[mgutt 382]

On 1/19/2021 at 10:55 PM, mgutt said:

Ich schaue mal ob ich damit Erfolg habe:

https://github.com/docker/for-mac/issues/1390#issuecomment-284467649

 

 

Schritt für Schritt was dadurch passiert.

 

Nach Ausführen von diesem Befehl:

docker network create nextcloud_internal --internal

 

Bekomme ich eine ID zurück. Außerdem werden dadurch diese zwei neuen Einträge in iptables hinzugefügt:

-A DOCKER-ISOLATION-STAGE-1 ! -s 172.18.0.0/16 -o br-28d52fb72e46 -j DROP
-A DOCKER-ISOLATION-STAGE-1 ! -d 172.18.0.0/16 -i br-28d52fb72e46 -j DROP

 

Diese neue IP-Range hat Docker selbst angelegt. Normalerweise liegen meine bridge-Container nämlich in 172.17.0.2/32.

 

Beim Erstellen des Containers sehe ich nun ein neues Custom-Netzwerk. Eine feste IP-Adresse kann man nicht vergeben (das Feld muss also leer bleiben):

 

Außerdem füge ich eine Port-Weiterleitung hinzu:

 

Nun sieht das ganze so aus:

 

Nextcloud lässt sich nicht öffnen:

 

Versuche ich innerhalb des Nextcloud-Containers auf das Internet zuzugreifen, dann ist das nicht möglich:

 

Dann habe ich den Nginx Proxy Manager ganz normal im Bridge-Modus gestartet. Dieser lauscht also auf 3 Ports:

 

Nun verbinde ich den Proxy Manager mit dem nextcloud_internal Netzwerk:

docker network connect nextcloud_internal NginxProxyManager

 

Ich öffne dessen Konsole und stelle fest, dass er nun eine IP aus dem Netz von Nextcloud hat, nämlich die 172.18.0.3:

 

Von der Konsole des Nextcloud-Containers kann ich nun den Proxy Manager erreichen:

 

Meinen Router erreiche ich allerdings nicht:

 

Der Proxy Manager erreicht dagegen meinen Router:

 

Bis hierhin sieht das schon mal gut aus. Allerdings besteht natürlich nach wie vor die Gefahr, dass der Angreifer den Nextcloud Container übernimmt und von da aus versucht den Proxy Manager zu attackieren. Ich denke damit muss man leben.

 

Was aber schon mal gut ist, dass der Nextcloud-Container keine Pakete nachladen kann (der Angreifer kann also keine weiteren Tools holen):

 

Allerdings fehlt mir jetzt noch die Möglichkeit den Proxy Manager von meinem restlichen Netz auszuschließen. Also er soll zwar mit meinem Router kommunizieren können, aber mit keiner anderen IP des Netzes. Braucht es dafür eine separate iptables Regel oder kann ich das auch über Docker umsetzen?

 

Außerdem habe ich ein Problem. Der Proxy Manager kann zwar Nextcloud mit dessen interne IP erreichen, aber nicht über dessen Host-IP:

 

Da ich ja keine feste interne IP vergeben kann, wie soll ich dann einen Proxy-Reverse konfigurieren?! Welchen Sinn hätte dann überhaupt die Port-Freigabe 8666?!

[mgutt 382]

Zu dem Problem, dass der Port nichts durchlässt:

https://github.com/moby/moby/issues/36174#issuecomment-363615950

As far as I'm aware, this is by design, and --internal networks should not be reachable, even with -p being used 

 

In dem Post ist von HaProxy als Lösung die Rede. Das muss ich mal testen.

[mgutt 382]

Also man kann eine feste IP vergeben, wenn man eine eigene IP-Range angibt. zB so:

docker network create --subnet=172.19.0.0/24 nextcloud_internal --internal

 

Danach habe ich wie schon zuvor Nextcloud darin erstellt, aber diesmal mit der festen IP 172.19.0.5 und NPM damit nachträglich verbunden. Dann in NPM die Proxy Regel erstellt und läuft. Nun noch MariaDB dem internen Netz zugewiesen um Nextcloud fertig installieren zu können und läuft ebenfalls.

 

Dann habe ich noch mal in MariaDB geschaut was ich machen kann:

 

Das eine Ergebnis kam mir komisch vor, also habe ich nachgehakt und leider kann MariaDB auf die Login-Seite von Unraid zugreifen:

 

Nextcloud auch:

 

 

Wirklich verstehen tue ich das nicht. Beide Container sind im Netz 172.19.0.0/24 und es gibt keine Port Mappings. Außerdem habe ich testweise NPM von nextcloud_internal wie folgt getrennt, was aber auch nicht geholfen hat:

docker network disconnect nextcloud_internal NginxProxyManager

 

 

Also der Container kann wirklich nichts machen außer auf die Weboberfläche von Unraid zugreifen. Das muss man doch auch irgendwie unterbinden können.

 

[ich777 773]

@mgutt Wenn du deinen Container verbieten willst das sie auf den Host zugreifen können schmeiß sie in Custom: br0 und sie haben keine Zugriff mehr auf den host (vorausgesetzt das du 'Host access to custom networks' deaktiviert hast).

[mgutt 382]

8 minutes ago, ich777 said:

schmeiß sie in Custom: br0

 

Damit hat der Container aber Zugriff auf das Internet und das gesamte lokale Netz. Also alles erlaubt außer die IP von Unraid. Selbst die Fritz!Box könnte man so angreifen:

 

Das "internal" Netz schottet dagegen alles ab. Bis auf die IP von Unraid. Also genau das Gegenteil. Mit der iptables Regel ist es dann komplett dicht.

 

 

[mgutt 382]

Also warum der Container auf Unraid zugreifen kann weiß ich wie gesagt nicht, aber man kann es mit der folgenden iptables Regel leicht lösen:

iptables -A INPUT -s 172.19.0.0/24 -d 192.168.178.0/24 -j DROP

 

Damit darf also kein Container, der eine IP aus 172.19.0.0/24 besitzt, Kontakt zu einem Teilnehmer aus dem 192.168.178.0/24 Netz aufnehmen.

 

Testergebnis an Hand des Nextcloud-Containers:

 

Was mich wundert, dass die Nextcloud-Konsole trotzdem noch funktioniert. Weil das Webterminal wird ja durch Unraid geladen, also durch eine IP aus dem 192.168.178.0/24 Netz. Oder gilt das jetzt als eingehende Verbindung und ist daher erlaubt? Naja, keine Ahnung. Schadet jedenfalls nicht, dass es geht

 

Bis hier hin läuft die Sache aber schonmal so wie ich es mir vorgestellt habe. Der Traffic aus dem Internet landet bei NPM und von da wird er intern an die anderen Container weitergeleitet. Damit ist der einzige Schwachpunkt nun NPM, wo noch folgendes zu machen wäre:

1. Internetzugang verhindern
2. Zugang zu 192.168.178.0/24 verhindern bis auf 192.168.178.1 (Router)
3. Möglichst viele "Capabilites" entfernen, was auch von RedHat empfohlen wird.

Was mir noch aufgefallen ist: Wenn man die Ports von NPM verstellt, dann muss man den folgenden Befehl noch mal ausführen:

docker network connect nextcloud_internal NginxProxyManager

 

Am besten führt man ihn also jedes mal aus, wenn man den Container startet. Geht das nicht über das Feld "Post Arguments"? Darüber könnte man dann ja auch gleich die iptables Regel raushauen 😬

[Smolo 2]

On 1/21/2021 at 8:36 AM, ich777 said:

So war es nicht gemeint...

 

Sieh dir mal das Konzept von ipFire an die haben bis zu 4 Schnittstellen Rot=WAN, Grün=LAN, Orange=DMZ, Blau=WLAN

Klick

 

Du machst alles auf einer Firewall und teilst dort auf.

 

Ja mit IPFire habe ich vor Jahren mal rumexperimentiert das UI schaut ja immer noch grusselig aus  
Hast du die Fritzen dann vor dem IPFire oder dahinter?

 

Bin ja immer noch am überlegen die Firewall über ne VM zu regeln *ja du darfst Steine schmeißen* 🤣

 

On 1/20/2021 at 8:13 PM, mgutt said:

Meine Stromrechnung, weshalb ich die Fritz!Box auch nur sehr ungern gegen Router + Modem + X ersetzen will. Und parallel weiterlaufen lassen schon gar nicht.

 

Youtube ist gar nicht unter 13 Jahren erlaubt. Oder geht es um ältere Kinder? Ab 13 werde ich denke ich kaum noch was filtern. Wenn nur wie jetzt die nächtliche Nutzung per Google Family Link bzw Microsoft Family Safety unterbinden.

D.h. du hast deinen Container jetzt direkt > Fritte > ProxyManger > Docker Container eingerichtet oder?

[ich777 773]

4 hours ago, Smolo said:

Ja mit IPFire habe ich vor Jahren mal rumexperimentiert das UI schaut ja immer noch grusselig aus  

Naja ich find das halb so wild, mir ost es lieber ich hab ne firewall die ordentlich funktioniert und da is mir die UI egal.

Ipfire ist wirklich sehr resourcenschonend, zumindest war es das früher als ich es verwendet hab.

 

4 hours ago, Smolo said:

Firewall über ne VM zu regeln

Das kann man ja machen nur gehen da die Meinungen auseinander und ich bin hald auch auf der seite das es nicht die beste lösung is.

Sobald die VM down is, hast du kein Internet mehr.

Vergiss auch nicht wenn du zB ein Plugin installiert hast das beim Start von Unraid nach updates sucht hast du dann auch pech, da du dann noch kein internet hast.

[mgutt 382]

9 hours ago, Smolo said:

D.h. du hast deinen Container jetzt direkt > Fritte > ProxyManger > Docker Container eingerichtet oder?

 

Noch nicht. Ich muss noch den NPM hätten und testen. Danach mache ich dazu ein Video.

[Smolo 2]

3 hours ago, mgutt said:

 

Noch nicht. Ich muss noch den NPM hätten und testen. Danach mache ich dazu ein Video.

Ja das wäre super ansonsten bin ich echt am überlegen temporär erstmal IPFire als VM aufzusetzen...3 virtuelle LANs dran und in die DMZ vom IPFire die Docker Container rein. Das sollte doch von der Thematik leichter zu konfigurieren und sicherer sein als in die Container Config einzugreifen die es einem bei einem Update auch zerlegen kann oder?

[mgutt 382]

36 minutes ago, Smolo said:

Das sollte doch von der Thematik leichter zu konfigurieren und sicherer sein als in die Container Config einzugreifen die es einem bei einem Update auch zerlegen kann oder?

 

Dazu kann ich dir noch keine verbindliche Antwort geben, aber ich werde versuchen das so zu konfigurieren, dass die gemachten Einstellungen direkt im Container Template hinterlegt sind. Soll heißen, wenn startet der immer mit diesen Regeln. Auch nach einem Update. Die Container hinter dem NPM können auch nach einem Update nicht auf das restliche Netzwerk zugreifen, da sie ja dem "internal" Netzwerk zugewiesen werden.

 

In einer VM hätte ich persönlich gar keinen Bock Container zu betreiben, da man dann den Overhead der VM hat. Und nicht zu knapp. Schließlich läuft dann ja alles virtuell. Also selbst der Netzwerk-Traffic läuft dann ja durch die KVM Treiber.

[Smolo 2]

5 hours ago, mgutt said:

In einer VM hätte ich persönlich gar keinen Bock Container zu betreiben, da man dann den Overhead der VM hat. Und nicht zu knapp. Schließlich läuft dann ja alles virtuell. Also selbst der Netzwerk-Traffic läuft dann ja durch die KVM Treiber.

Hm da haben wir glaube ich anhand der vorherigen Diskussion grad etwas vorbei geredet. Wenn ich jetzt nur die Container absichern möchte kann ich das natürlich wie du grad testest so machen das man dem Container selbst nichts zuweist bzw. Alles verbietet. Meiner Meinung nach könnte sich das als ziemlich Fehler anfällig erweisen weil du ja nicht in den Container drinnen steckst.

 

Die andere Idee wäre eine IPFire VM aufsetzen d.h. der externe traffic geht immer gegen die FW und ein virtuelles DMZ Netz für die Container aufspannen. Die Container selbst laufen ganz normal unter unraid aber mit dem speziellen Netz.

 

Ich habe es mir noch nicht weiter angeschaut unter Unraid aber bei den QNAPs kann man virtuelle Switch anlegen und entsprechend die Ports zuweisen.

[mgutt 382]

On 29.1.2021 at 8:40 PM, Smolo said:

Die Container selbst laufen ganz normal unter unraid aber mit dem speziellen Netz

 

Ähnliches könnte ich vermutlich jetzt schon machen, in dem ich br0.100 verwende, denn diese VLAN 100 route ich an Gast-LAN4 meiner Fritz!Box, wie hier beschrieben:

https://janscholten.de/blog/2014/09/vlans-im-heimnetz-mit-netgear-unifi-und-fritzbox/

 

Allerdings hat der Container dann Internetzugriff. Er kann also Pakete nachladen, was ich nicht möchte.

 

Stattdessen könnte ich also eine VLAN nehmen, die schlicht nicht existiert. Der getaggte Traffic findet also kein Ziel.

 

Bisher wusste ich nicht wie ich den eingehenden Traffic aus dem Internet nun dahin bekomme. Nur sollte das nicht gehen, wenn die Fritz!Box 80/443 an NPM freigibt und ich den NPM Container mit dem br.fake Netz verlinke? Muss ich mal ausprobieren.

 

Wenn das geht, könnte ich bei Bedarf kurz mit Nextcloud auf br0.100 wechseln um eine App aus dem Internet zu installieren und dann wieder zurück auf br0.fake und der Container wäre wieder offline bzw ausschließlich über NPM erreichbar.

 

Gerade wegen Plex habe ich aber denke ich noch ein Problem. Ich dachte ja einfach lokal über eine Domain auf Plex zuzugreifen. Aber dann gehen doch alle Clients hin und erzwingen Transcoding oder nicht (weil "Plex über Internet verbunden")? Kommt darauf an ob der Client mit einer lokalen IP bei Plex anklopft oder nicht. Ich befürchte fast, da NAT Loopback durch die Fritz Firewall läuft, dass ich dann von einer öffentlichen IP komme. Muss ich auch noch testen.

[Ford Prefect 86]

@mgutt: Ist ja schon ein wenig her...hast Du Erfolg gehabt?...gerade das hier gesehen:

...könnte das interessant für Deinen UseCase sein?