Docker auf RootServer

Schön dass es hier doch weitergeht!

Danke [netcup] Claudia H.

Noch ein Tip: Der Port 81 "muss" nicht im docker-compose rausgelegt werden. Mein NPM ist so konfiguriert, dass der Port nur erstmalig offen war, dann habe ich mit NPM einen Reverse Proxy für NPM selbst eingerichtet und natürlich mit SSL Zertifikat versehen (hierfür am Besten ein *.domain.tld Zertifikat via DNS Let's Encrypt Challenge holen), um dann in NPM "http" "namedesNPMcontainers" "81" zu konfigurieren und dann auf https://npmsubdomain.domain.tld zu legen. Sobald das erledigt ist, ist die NPM Oberfläche selbst geproxied und der herausgelegte HTTP Port 81 kann im docker-compose auskommentiert werden. Dann kann auch zusätzliche Sicherheit mit NPM eingebaut werden.

Ebenso muss KEIN HTTP(S) Port irgendeines Containers, der durch NPM geproxied wird, herausgelegt werden, sondern ALLE diese Ports können auskommentiert werden. Ports die nicht durch NPM geleitet werden können (z.B. FTP, SMTP(S), IMAP(S), etc.) müssen natürlich schon rausgelegt werden.

Eine einfachere Variante von Wireguard sind diverse controllerbasierten VPNs wie Tailscale (basiert auf Wireguard), Netbird, Netmaker und andere. Zerotier setzt ein OSI Layer drunter an. Du kannst auch den VPN Client direkt in einen Container integrieren (

Zitat von h725rk

Leider sehe ich aktuell keinen Mehrwertmehr dafür, da der Traffic von Docker durch die speziellen IPTables nach draußen unterbunden werden können.

Auch das kann man ja ändern.

Kein Verständnis habe ich für die Reaktion. Das ist dann wohl ein Fall von "kann die Wahrheit nicht vertragen". Aber wenn der Server dann gehackt wird und die IP auf einer Blacklist landet, leiden vor allem die anderen Netcup Kunden darunter, und das Geschrei ist groß. Das Forum ist voll davon, wir ihr alle wisst, und dann fragen sich wieder alle, warum die Leute ihre Server nicht absichern. Aber wenn dann ein konkreter Fall offenbar wird, sagt wieder niemand was. Hm.

Ich halte auch nichts davon, in Foren Schritt-für-Schritt Anleitungen zu geben. Zum einen ist der Lerneffekt gleich Null, zum anderen hilft das dann auch nur für diesen einen konkreten Fall. Ich schreibe immer, was zu tun ist, aber nicht wie. Damit hat der Fragesteller die Chance, sich die Grundlagen zu erarbeiten, und bei Anpassungen nicht wieder nachhaken zu müssen. Und andere Leser mit ähnlichen Problemen profitieren auch davon: Lesen, verstehen, adaptieren, umsetzen. Man kann es nicht oft genug wiederholen.

Man kann natürlich auch vorsichtig versuchen den Fragesteller in die richtige Richtung zu schubsen und zu mehr lernen animieren…

Es gibt so viele Foren wo es schnell toxisch wird, das netcup Forum gehört nicht dazu. Fände ich toll wenn das so bleibt.

Nichts gegen deutliche Worte, aber manchmal sollte man die ein bisschen freundlicher verpacken, denke ich.

Wir gewinnen auch nix wenn der Fragesteller angepisst ist (zugegeben, er hat jetzt sicherlich nicht die dickste Haut) und dann einfach woanders nen Spam-Server aufmacht, oder?

Zitat von frank_m

Auch das kann man ja ändern.

Kein Verständnis habe ich für die Reaktion. Das ist dann wohl ein Fall von "kann die Wahrheit nicht vertragen". Aber wenn der Server dann gehackt wird und die IP auf einer Blacklist landet, leiden vor allem die anderen Netcup Kunden darunter, und das Geschrei ist groß. Das Forum ist voll davon, wir ihr alle wisst, und dann fragen sich wieder alle, warum die Leute ihre Server nicht absichern. Aber wenn dann ein konkreter Fall offenbar wird, sagt wieder niemand was. Hm.

Ich halte auch nichts davon, in Foren Schritt-für-Schritt Anleitungen zu geben. Zum einen ist der Lerneffekt gleich Null, zum anderen hilft das dann auch nur für diesen einen konkreten Fall. Ich schreibe immer, was zu tun ist, aber nicht wie. Damit hat der Fragesteller die Chance, sich die Grundlagen zu erarbeiten, und bei Anpassungen nicht wieder nachhaken zu müssen. Und andere Leser mit ähnlichen Problemen profitieren auch davon: Lesen, verstehen, adaptieren, umsetzen. Man kann es nicht oft genug wiederholen.

Klar nur eine Schritt für Schritt Anleitung lesen und hinterher nicht wissen wie es genau funktioniert ist keine gute Idee. Es lernen aber nicht alle Menschen gleich, OP war sich der Risiken von ufw und Docker bewusst, sieht man doch schon im Post 1. Die Frage ist auch berechtigt und über ufw und andere Programme die an iptables und nftables herumfummeln sind hier schon viele andere gestolpert (bin heimlicher Leser meistens).

Und an seinem WireGuard Setup an sich sehe ich nichts gefährliches, jeglicher Traffic ohne passende Cryptokeys wird verworfen, per default.

Edit: Ich selber befolge gerne erst mal so eine Schritt für Schritt Anleitung, schaue mir die dort genannten Programme an (wg*), hab im Hintergrund später zig manpages offen, bei WireGuard auch das Konzept-PDF weil ich es faszinierend fand. Persönlich habe ich dabei keine Hilfe gebraucht, aber dumme Fragen gibt es keine.

Zitat von ThomasChr

Man kann natürlich auch vorsichtig versuchen den Fragesteller in die richtige Richtung zu schubsen und zu mehr lernen animieren…

Das hab ich ja ziemlich lange probiert am Anfang. Passiert ist wenig.

Zitat von Irrwisch

Die Frage ist auch berechtigt und über ufw und andere Programme die an iptables und nftables herumfummeln sind hier schon viele andere gestolpert (bin heimlicher Leser meistens).

Genau das ist der Punkt. Es ist für erfahrene Leute schon schwierig, einzuschätzen, was die Firewall nun durchlässt, und was nicht, wenn zahlreiche Container und Tools mit verschiedenen Frontends in den Regeln herumwühlen. Und wenn man dann nicht mal weiß, wie IP Routing funktioniert, um beurteilen zu können, wie die Pakete überhaupt durchs System fließen, dann ist es meines Erachtens unmöglich, den Server adäquat abzusichern.

Im not sure on the OP UFW setup but the first thing is do is lock down UFW so docker ports do not bypass the firwall. This is security 101 with regards to docker.

Follow this guide below and amend the lines to match your docker network IP. i.e lets say you set a custom network on 172.20.0.0/12 then ammend any lines that say 192.168.x.x with this ip instead

Lock down Docker Ports with UFW

Now rather than open port 80 443 to the whole server, further down the guide they explain how to use forward rules to the docker chain.

I Have servers with either SWAG or NPM so it works with either. so lets Say you have given a fixed docker IP of 172.20.0.100 to NPM, the forward rules would then be:

ufw route allow proto tcp from any to 172.20.0.100 port 80
ufw route allow proto tcp from any to 172.20.0.100 port 443
ufw route allow proto tcp from any to 172.20.0.100 port 81

This will now forward those ports directly to NPM and no where else on your server.

Whatever ports you publish now will only be reachable if you add a forwad rule like above otherwise they gain no access

Regarding Port 81, you only need this for initial setup, what you should do is set up a proxy host in NPM for NPM itself, add the SSL then access via the domain name. You can then remove the forward rule for 81.

With regards to Wireguard, i use a Wireguard and Wireguard-UI Stack and this works perfectly. i can give you the docker run command to see how they link, but basically the UI container actually connects to the Wireguard docker and its UI ports are published there. You then add a proxy host in NPM for the webui so its secured and add another forward rule like below

Lets say you have given the Wireguard Docker IP 172.20.0.50 and UDP port 51820, you would then publish a forward port as follows

ufw route allow proto udp from any to 172.20.0.50 port 51820

Obviously you can change"any" to a specific IP only if that suits.

If you want to add an extra layer of security then throw all your WEBUI dockers that dont need to be accessed from anyone else behind Authelia Docker 2FA. That locks it down nice and tight but is a pain to setup for the first time, and is a lot easier to setup with the SWAG proxy container than NPM