Portainer aus dem Internet abschotten

  • Hallo zusammen,

    ich versuche meine Portainer Anwendung auf dem Port 9000 vom Internet aus abzuschotten. Kann mir einer von euch sagen wie ich dies erreichen kann. Ich habe bereits das unten stehende über die ufw firewall versucht. Leider ohne Erfolg.


    Danke im Voraus und Liebe Grüße,

    Lucas



    To Action From

    -- ------ ----

    2183 ALLOW Anywhere

    51820 ALLOW Anywhere

    9000 DENY Anywhere

    80 DENY Anywhere

    2183 (v6) ALLOW Anywhere (v6)

    51820 (v6) ALLOW Anywhere (v6)

    9000 (v6) DENY Anywhere (v6)

    80 (v6) DENY Anywhere (v6)

  • 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.

    Hallo,

    und Danke dir für deine schnelle Antwort. Ich nutze einen VServer welcher folgende default policy umsetzt.


    sudo ufw default deny incoming
    sudo ufw default allow outgoing


    Weshalb ich doch denke das "9000 DENY Anywhere" den Zugriff auf den Port 9000 verbieten sollte, oder irre ich hier?


    Danke und LG

    Lucas

  • 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.

    VPS 500 G8 Plus | VPS Karneval 2020 | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

  • 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.

    RS Fast Rabbit OST21 (~RS 8000 G9) | RS Ostern L OST22 (~RS "3000" G9.5)

  • 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:

  • 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.

    Code
        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.

    RS Fast Rabbit OST21 (~RS 8000 G9) | RS Ostern L OST22 (~RS "3000" G9.5)

  • 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:) ?

  • 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

  • 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

  • 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.

    VPS 500 G8 Plus | VPS Karneval 2020 | Webhosting EiWoMiSau


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    Like 1
  • 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.:

    Code
        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. ;)

    RS Fast Rabbit OST21 (~RS 8000 G9) | RS Ostern L OST22 (~RS "3000" G9.5)