Hi Daniel,
Am 12.11.25 um 12:14 schrieb Daniel Leidert:
Hi,
irgendwie fehlt die Einstiegsmail auf der Liste..?
die hängt ja noch komplett an meiner ersten Antwort dran, falls sie bei dir abhanden gekommen ist.
Das ist mit dem All-in-one tatsächlich auch meine Erfahrung. Es gibt aber noch den
https://hub.docker.com/_/nextcloud/
Der läuft wunderbar und ist deutlich einfacher aufgebaut. Das plus Reverse Proxy läuft bei mir seit langem stabil.
Du hast Recht, das betrifft nur den AIO, die normale Version hatte ich auch eine Zeit lang im Einsatz. Allerdings waren die notwendigen Nacharbeiten mit occ nach Upgrades der Grund, das wieder in native Installationen zu migrieren. Der Container machte die Upgrades nur noch komplizierter. Ohne Container entfällt auch der zusätzliche Webserver im Container und macht das System dadurch schlanker.
Docker (der Daemon) ist eine Zumutung, vollkommem irrationales Verhalten im Netzwerkbereich und da er sich bei iptables vordrängelt, bohrt er große Löcher in die Firewall. Mit nftables kann docker nichts anfangen.
Für iptables stimme ich da nicht zu. Es gibt die DOCKER-USER Chain, um Regeln zu erstellen. Man muss es halt nur wissen und beachten. Das funktioniert mit fail2ban oder ufw sehr gut.
Ausgehend von einer funktionierenden Firewallkonfiguration, die nichts durchlässt was nicht explizit erlaubt ist, hat man nach dem Start eines Containers mit einem publishing Port diesen für die ganze Welt geöffnet, was ich nicht erwarten würde. Warum passiert das? Weil die Docker-Chains vor die vorhandenen Firewallregeln gestellt werden und diese damit umgeht. In der Docker-Chain werden dann Regeln erstellt, die eingehende Anfragen zum Container routen. Das ist ein schlechtes Standardverhalten. Ja, die User-Chain ist noch davor geschaltet und man könnte das dort auch wieder verbieten.
Die verschiedenen Docker-Netze sind besser gegeneinander abgeschirmt, als von der Außenwelt. Solange der Server im LAN steht, ist das alles nicht so dramatisch. Der Router verhindert schlimmeres. Es gibt leider auch keine Möglichkeit, die Regeln in der Docker-Config anzupassen, man kann es dort nur abschalten.
Wie sich das im Zusammenhang mit fail2ban einsortiert, kann ich nicht mehr sagen, da sich fail2ban sauber bei nftables in der inet-Chain integrieren lässt. Fail2ban löst aber auch nicht das ursprüngliche Problem, daß Ports ungefragt nach außen geöffnet werden.
Docker dagegen nutzt iptables-legacy und lässt sich damit nicht vernünftig in nftables integrieren. Ich möchte aber auf die Vorteile von nftables nicht mehr verzichten.
Zu ufw kann ich auch nichts sagen, aber Docker sagt selbst: (ufw) is a frontend that ships with Debian and Ubuntu, and it lets you manage firewall rules. Docker and ufw use firewall rules in ways that make them incompatible with each other. Quelle: https://docs.docker.com/engine/network/packet-filtering-firewalls/ Docker umgeht auch hier die eigenen Firewallregeln.
Ich konfiguriere das lieber direkt in der nftables.conf. Für iptables hab ich früher noch ferm benutzt.
Ansonsten würde ich da immer einen nginx als Proxy davor setzen, der sich um https kümmert, sonst ist der Port 443 für den einen Container verbraucht.
Oder Apache. Ansonsten ACK.
Oder irgendeinen Reverse-Proxy, je nach persönlichen Vorlieben.
GrußRico