Portainer aus dem Internet abschotten

Root/VPS? Was ist denn die Default Policy?

Default Deny/Drop und dann einfach nur die Ports erlauben erlauben. Dann einen Reverseproxy davor mittels htpasswd absichern.

Also wenn inc.eh schon auf deny steht, dann sollte der Port garnicht offen sein. Einfach mal mittels telnet von außen testen.

Ggf mittels iptables -L mal schauen.

Dazu dann einen ReverseProxy mit BasicAuth. Dann ist halt Ruhe.

Ach, Deny durch Drop ersetzen. Dann werden die Pakete einfach verworfen.

Docker ordnet sich da irgendwie drüber. Bei mir greift die Firewall bei Docker dann nur bei IPv6. IPv4 ist aus einem von mir noch nicht näher untersuchten Grund höher priorisiert.

Ich löse es immer so, dass ich die Container nur auf localhost binden lasse und den Rest über nen Reverse Proxy erledige.

Pack doch schon gleich mal Portainer hinter den Nginx Proxy Manager ( https://nginxproxymanager.com/ ), dann ists schonmal nicht mehr Port 9000, sondern eine Subdomain Deiner Wahl. Ohne die Kenntnis dieser Domain kein Zugriff. Zudem kann NPM die Kommunikation per Let's Encrypt Zertifikat absichern. Ich habe alles hinter NPM, sogar den NPM selbst.

Und in der Tat, den Port 9000 gar nicht erst auf den Host legen, sondern nur im NPM drauf verweisen.

Damit das funktioniert, müssen NPM und der Container, der geproxied werden soll, im gleichen definierten Netzwerk sein.

ein paar kleine Eingriffe in ufw, und dann wird geblockt wie erwartet - siehe https://github.com/chaifeng/ufw-docker

oder in

/etc/ufw/after.rules vor dem letzten Commit:

# BEGIN UFW AND DOCKER
# *filter
:ufw-user-forward - [0:0]
:ufw-docker-logging-deny - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j ufw-user-forward
# these are your local networks / docker networks
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16

-A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN
# allow some common ports
-A DOCKER-USER -p tcp --dport 25 -j RETURN
-A DOCKER-USER -p tcp --dport 1025 -j RETURN
-A DOCKER-USER -p tcp --dport 1465 -j RETURN
-A DOCKER-USER -p tcp --dport 143 -j RETURN
-A DOCKER-USER -p tcp --dport 1143 -j RETURN
-A DOCKER-USER -p tcp --dport 1993 -j RETURN
-A DOCKER-USER -p tcp --dport 4190 -j RETURN
-A DOCKER-USER -p tcp --dport 80 -j RETURN
-A DOCKER-USER -p tcp --dport 587 -j RETURN
-A DOCKER-USER -p tcp --dport 443 -j RETURN
-A DOCKER-USER -p tcp --dport 8443 -j RETURN
-A DOCKER-USER -p tcp --dport 9980 -j RETURN
-A DOCKER-USER -p tcp --dport 993 -j RETURN
-A DOCKER-USER -p tcp --dport 8888 -j RETURN
-A DOCKER-USER -p tcp --dport 8021 -j RETURN

-A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

-A DOCKER-USER -j RETURN

-A ufw-docker-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW DOCKER BLOCK] "
-A ufw-docker-logging-deny -j DROP

COMMIT
# END UFW AND DOCKER

TBT , Virinum :

Das bedeutet Ihr macht folgendes wenn z.B. ein Container auf 8000:8000 eingerichtet werden sollte:

Statt 8000:8000 => 127.0.0.0:8000:8000

Hab ich das so richtig verstanden?

Damit die Container im gleichen Netz wie der NPM sind, kann ich doch in Portainer jedem Container das NPM Netzwerk hinzufügen.

Lasse den Container dann zusätzlich das bridge Netz oder lösch ich das?

Ich lege bei den meisten Containern gar keinen Port nach draußen, nur bei NPM. Bzw. bei der Erstkonfiguration mach ich das ggfalls mal und wenn ich sicher gehen kann, dass die Sache läuft, dann werden die exposed Ports entfernt und der Container ist nur mehr durch NPM erreichbar.

    ports:
      - "80:8080"
      - "443:4443"

Das ist mein Codeschnipsel für den NPM, nur dieser lauscht auf Port 80 und 443 des Hosts.

Beispiel Portainer: da läuft das Webinterface standardmäßig auf Port 9000. Meistens wird dieser Port dann auch nach außen exposed. Das war bei mir vielleicht für 10 Minuten so, danach war die Exposition weg und ich hab in NPM einen Proxy Host "wasauchimmer.domain.tld" -> http://portainer:9000 mit automatischem LE Zertifikat eingerichtet. Ergebnis: http://hostip:9000 ist von außen nicht mehr zugänglich, und httpS://wasauchimmer.domain.tld (ohne Port) leitet weiter zu Portainer.

Wenn ein Container intern Port 80 oder 443 verwendet, legt man diese zu einem anderen "ports" Bereich um (wie oben bei NPM, bei dem der externe Port 80 auf den containerinternen Port 8080 umgelegt wird, auf dem der Dienst eigentlich läuft.

D.h. die "ports" werden nach wie vor definiert, aber eben nicht mit "expose" nach außen gelegt.

Nebenbei: nachdem NPM einmal aufgesetzt ist, kann man das übrigens auch mit NPM selbst machen, d.h. man kann die Weboberfläche von NPM durch sich selbst durchleiten und damit die nicht-proxy Ports des NPM Containers auch hinter ein LE Zertifikat packen.

Das ist alles halbwegs komplex zu erklären, ich hoffe Du verstehst es halbwegs.

Danke für Deine ausführliche Antwort. Genau so will ich es auch machen.

Nur kurz zu meinem Verständnis:

Wenn jetzt z.B. bei Portainer standardmäßig 9000:9000 eingestellt ist, dann wäre Port 9000 exposed. Wenn ich es jetzt auf auf z.B. 9000:9005 ändere wäre und dann NPM wie von Dir beschrieben einrichte, wäre nicht mehr exposed. Hab ich das so richtig verstanden?

Kurz Externer Port "ungleich" interner Port => Gut:) ?

Quote from Interessent

Danke für Deine ausführliche Antwort. Genau so will ich es auch machen.

Nur kurz zu meinem Verständnis:

Wenn jetzt z.B. bei Portainer standardmäßig 9000:9000 eingestellt ist, dann wäre Port 9000 exposed. Wenn ich es jetzt auf auf z.B. 9000:9005 ändere wäre und dann NPM wie von Dir beschrieben einrichte, wäre nicht mehr exposed. Hab ich das so richtig verstanden?

Kurz Externer Port "ungleich" interner Port => Gut:) ?

Nein, wenn ein Port nicht exposed bzw. eigentlich published werden soll darf gar nichts definiert werden.

Nur so lauscht der Container am internen Netzwerk.

In deinem Beispiel ist 9000 der externe Port und 9005 der Container Port (bei Portainer läuft da kein Service)

https://www.baeldung.com/ops/docker/expose-vs-publish

Danke, stehe irgendwie noch auf dem Schlauch, wie es dann richtig aussehen soll

Du definierst einfach gar keine Ports. Mit -p 9005:9000 würdest du den Container Port 9000 auf den Port 9005 des Hosts durchreichen, genau das willst du ja nicht. Also einfach keine Ports angeben. Portainer ist dann nur im internen docker Netzwerk auf Port 9000 erreichbar.

NPM und Portainer müssen dafür im gleichen Netzwerk sein.

Im Optimalfall definierst du für jeden Container ein eigenes Netzwerk. Dann sind die Container auch voneinander isoliert. NPM muss dann in jedem Netzwerk sein damit er alles Container ansprechen kann

Danke.

Also wenn ich es richtig verstanden habe dann bei Container xyz in Portainer statt z.B. 8000:8000 dann - : 8000 eintragen...

Muss ich mal probieren.

Quote from Interessent

Danke.

Also wenn ich es richtig verstanden habe dann bei Container xyz in Portainer statt z.B. 8000:8000 dann - : 8000 eintragen...

Muss ich mal probieren.

Wenn kein Port published werden soll, muss eigentlich auch nichts angegeben werden.

Das exposing funktioniert trotzdem.

Sorry, aber jetzt versteht ich gar nix mehr. Ich hab doch nichts angegeben

Quote from Interessent

Sorry, aber jetzt versteht ich gar nix mehr. Ich hab doch nichts angegeben

Was meinst du dann mit dem -:8000 eintragen?

Wenn dein Befehl vorher docker run -d -p 8080:80 nextcloud war, muss er dann so aussehen docker run -d nextcloud. Also den Teil -p 8080:80 weglassen.

Quote from Virinum

Wenn dein Befehl vorher docker run -d -p 8080:80 nextcloud war, muss er dann so aussehen docker run -d nextcloud. Also den Teil -p 8080:80 weglassen.

Ok, verstanden. Da ich das ganze mit Portainer mache, kann man dort sicher bei den Ports beide Felder löschen.

Nur:

Wenn ich jetzt nach Deinem Beispiel nextcloud mit NPM unter nextcloud.domain.de erreichbar machen will, was soll ich dann als Port angeben, wenn ich vorher keine mehr angegeben habe.

Nur nochmal als Erinnerung, das ganze läuft auf einem VPS und nicht im Heimnetzwerk

Gerade bei komplexen Multicontainer Setups wie Nextcloud kann ich nur davon abraten zu versuchen, das mit "docker run" anstellen zu wollen. Statt dessen solltest Du ein docker-compose File schreiben und alle Definitionen da rein machen. Eine wichtige Sache bei NC: unbedingt die Datenbankversion per Tag festpinnen, z.B.:

    image: mariadb:10.7

denn bei ":latest" wird beim Neuspawnen / Update mit Watchtower sonst eine neue DB Version eingespielt, die leicht mal die Installation killen kann. DB Updates sollten da nur mit äußerster Sorgfalt und allen Vorkehrungen, die hierfür erforderlich sind, durchgeführt werden.

Und ja, keinen Port exposen. Virinum hat das ja schon erläutert.

Ein Anfangspunkt für ein Nextcloud docker-compose mit Proxy Server davor (und gepinnter Datenbankversion) kann https://github.com/nextcloud/docker --> "Base version - FPM" sein, aber halt ohne die "ports" Sektion.

Allerdings hat NC durchaus seine Schwierigkeiten hinter einem Proxy, da muss dieser vermutlich noch im Bereich "Advanced" des NPM zusätzlich konfiguriert werden.

Da hast Du Dir aber durchaus eine der schwierigeren Docker Übungen rausgesucht.