Komisches Verhalten Docker-Portainer-UFW-UFW Docker

  • Hallo zusammen,

    ich habe gerade auf einem Webserver (Ubuntu, UFW + UFW Docker, um das Docker und UFW Problem zu lösen) einige Docker Container mit Portainer verteilt und eingerichtet.


    Bisher wurden in der Firewall mit Hilfe von UFW Docker KEINE Regeln und Freigaben für irgendwelche Container erteilt. Alles zu.


    Ein Test hat jedoch ergeben, dass alle Container und IP:externer Port erreichbar sind.

    Ich habe mal mit iptables -L nachgeschaut und in der Chain DOCKER finden sich tatsächlich zu allen Containern Einträge, die den Zugriff auf die jeweiligen Ports zulassen.


    Wie kann das denn sein? Ich nutze doch UFW Docker um gerade das zu verhindern.


    Hab den Server jetzt erstmal wieder offline genommen, bis ich eine Lösung gefunden habe.


    Kann hier jemand helfen?


    Danke & Grüße

  • Hab ich installiert, ja

    Hatte ich überlesen, sorry. War gestern doch zu spät.


    Weitere Workarounds wären noch auf localhost zu binden (ist aber auch nicht absolut sicher, finde den Post aber leider gerade nicht dazu) oder den Network-Type host zu wählen.

    Natürlich könnte man auch noch einen weiteren Server als Firewall davor setzen.


    Aber schöner wäre es natürlich, wenn man keine Workarounds nutzen müsste und es einfach funktionieren würde wie gedacht. Hab da aber leider gerade spontan keine weiteren Ideen.

    RS Brezn | VPS 500 G8 Plus | 2× VPS Karneval 2020 | VPS Pocket Admin | RS Cyber Quack | VPS 500 ARM


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

    Edited once, last by Virinum ().

  • I run docker / portainer / ufw on all my setups and do not face this issue.


    However, I use UFW on the root server and not in docker. I make the amendments listed in the github listed above (changing the IP's to match my custom docker network i.e 172.20.0.0/12 and then use forward rules to point to my proxy docker container (either Swag or NPM). However that works for my setup and not knowing how you have yours setup, wethere you have a proxy container etc it is hard to pin point the issue. As i am using a proxy i do not have to publish any ports publically for the containers so that also assists.


    My Setup

    • Debian 12 with UFW and Crowdsec installed
    • UFW ammended with the changes listed in Github Link
    • Custom Docker Network so all containers can talk to each other without issue (also assigndocker network Static IP's to each container)
    • NPM/SWAG as Proxy managing traffic to the correct containers
    • Apart from the proxy container no other containers have ports published
    • UFW Forward rules for Port 80/443 are sent to the Proxy container static ip only following the github guide

    That results in 2 forward rules for TCP traffic and then i have a SSH rule obviously as normal.


    I occasionally have published ports for portainer as i forget to remove it after initial setup however, NMAP scan only ever shows the 3 ports as being open as expected.

    One of those RS Things, A Nano One and Rocking an ARM one also which is becoming my goto!

  • So hier noch mal eine Zusammenfassung mit mehr Infos:

    - ufw läuft standallone, direkt auf dem Server, nicht in Docker

    - Der Netzwerktyp aller Container (bis auf einem Wireguard Container) ist NICHT Host

    - aktuell sind die Container noch in unterschiedlichen Netzen, die meisten davon werden dann final in einem Netz mit dem NPM sein und hinter diesem verschwinden, d.h. noch noch der NPM Container wird auf 80,443 TCP erreichbar sein.

    - Aktuell nur diese Firewall Regeln vorhanden:

    Code
         To                         Action      From
         --                         ------      ----
    [ 1] *SSHPORT*/tcp              LIMIT IN    Anywhere
    [ 2] *SSHPORT*                  LIMIT IN    Anywhere
    [ 3] 172.18.0.2 51820/udp       ALLOW FWD   Anywhere                   # allow wireguard 51820/udp wireguard-server_default
    [ 4] 172.17.0.3 9001/tcp        ALLOW FWD   Anywhere                   # allow portainer_agent 9001/tcp bridge
    [ 5] *SSHPORT*/tcp (v6)         LIMIT IN    Anywhere (v6)
    [ 6] *SSHPORT* (v6)             LIMIT IN    Anywhere (v6)

    Normalerweise gebe ich dann die Docker COntainer so in UFW frei:

    ufw-docker allow containername *PORT*/tcp


    Auf dem alten Server ging es. Evtl. hat das Update auf 22.0.4 von 20.0.4 was zerschossen? Hab UFW Docker aber bereits neu installiert. Keine Änderung.


    So schaut meine /etc/ufw/after.rules aus:

    Sollte eigentlich passen...



    So schaut die DOCKER CHAIN mit iptables -L aus (alle Regeln hatte ich gestern gelöscht, jetzt nach hochfahren des Servers, alles wieder da):


    Vll. kann ja jemand damit was anfangen.

  • Vll. hängt es auch mit der Docker Version zusammen? Damals noch unter 20.0.4, hab ich es so installiert:


    Code
    sudo apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common
    
    
    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
    
    
    sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
    
    
    sudo apt-get update && sudo apt-get install docker-ce docker-ce-cli containerd.io
  • - Der Netzwerktyp aller Container (bis auf einem Wireguard Container) ist NICHT Host

    Alle Regeln, die du ins zeigst, betreffen die INPUT Kette. Aber in dem Fall ist die FORWARD Chain entscheidend, vor allem auch die Pre-Routing und Post-Routing Regeln. Dort wird festgelegt, welche Pakete von außen auf deine Container gelassen werden. Also auch wenn du sie hier nicht freigegeben hast, können darüber Pakete an deine Container gelangen.

    Du musst schon das gesamte Regelwerk betrachten.

  • ok hier mal alle Regeln, vll. seht ihr ja einen Fehler:

  • und Teil 2:

  • Indem du mit "-t" die entsprechenden Tabellen angibst, z.B. "raw", "nat", "mangle", "security".


    Generell empfehle ich, dich intensiv mit iptables bzw. nftables zu befassen. ufw ist nur ein Frontend, die eigentliche Filterung findet woanders statt.

  • Hiya


    You appear to have copied the github contents verbatim and have not amended them, not sure if it makes a difference but i always ammend my to also include my custom docker networks


    From your quote you have:


    And especially these lines:


    Code
    -A DOCKER-USER -j RETURN -s 172.16.0.0/12
    -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

    Now i could be wrong however anything out side of those docker networks will still bypass UFW.


    Looking at your firewall rules


    Code
    [ 3] 172.18.0.2 51820/udp       ALLOW FWD   Anywhere                   # allow wireguard 51820/udp wireguard-server_default
    [ 4] 172.17.0.3 9001/tcp        ALLOW FWD   Anywhere                   # allow portainer_agent 9001/tcp bridge

    You have containers on a 172.18 and 172.17 network, these are not declared in the docker UFW rules


    I never use the default network of 172.16 however i do leave that rule in, but i change the other example 192.168 to match my docker network as thats just an example.


    Change the line


    Code
    -A DOCKER-USER -j RETURN -s 192.168.0.0/16

    to

    Code
    -A DOCKER-USER -j RETURN -s 172.18.0.0/12

    And do the same for :


    Code
    -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 udp -m udp --dport 0:32767 -d 192.168.0.0/16

    to

    Code
    -A DOCKER-USER -j ufw-docker-logging-deny -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.18.0.0/12
    -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 172.18.0.0/12

    Then duplicate each line for each network you have running on docker i.e your other 172.17.0.0/12


    And try that


    So it should look like this:


    It may not make a difference but its how i have mine setup on Debian 12 and none of my containers are visible but i also have them on one network behind a proxy

    One of those RS Things, A Nano One and Rocking an ARM one also which is becoming my goto!

    Edited 3 times, last by Casstg ().

  • Casstg


    Thanks for your input. Makes sense, try that later today.

    I maybe wrong but there was no instruction on the GitHub page to modify these entries.

    I agree it does not mention anything about modifying , but i noted his use of 192.168 being a home network default so i just amended it as that line is pointless on most cloud setups, so i always changed it to my custom docker network, may make no difference but worth a try

    One of those RS Things, A Nano One and Rocking an ARM one also which is becoming my goto!