Komisches Verhalten Docker-Portainer-UFW-UFW Docker

    Zitat von frank_m

    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.

    So dann mal der gewünschte Input:

    Code
    iptables -t raw -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
    Code
     iptables -t security -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

    Casstg:

    You are the man!

    Seems it was excatly that issue.

    • Tried to reach a container, which subnet was not in the modified /etc/ufw/after.rules => Access possible, because of bypassing the firewall rules.
    • Added this subnet to /etc/ufw/after.rules => no access possible
    • added ufw-docker allow container port/tcp => access possible

    I will go back to my latestet snapshot, because I did a lot of testing. Then I fire up all containers again, put them to the desired Nginx Proxy Manager Network (what was my initial plan) and then I will test container by container, modifying this file.

    Again many thanks!

    Have to pick this up again. Works perfectly after modifying the networks to my needs.

    But one container, a Wireguard Server listening on the standard port 51820 is also reachable without any allowing fire rules. Has anyone a idea?

    It is reachable for me, having the correct credentials to innitiate the wireguard connection, so others should not have any access.

    But nevertheless I would be interested why...

    Without seeing your docker config for wireguard it is hard to diagnose, but i run Wireguard with wireguard UI docker in the same setup as i previously posted and i have to publish the forward ports for the UDP. However i could be wrong but reading up i would not be overly concerned as it is a UDP port and unless someone gets hold of the wireguard keys theres nothing they could do anyway as the docker wont respond unless the keys are correct and UDP doesent respond in the same way as TCP ports for probing, again could be wrong but thats what i understood when reading up many moons ago

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

    Zitat von Casstg

    Without seeing your docker config for wireguard it is hard to diagnose, but i run Wireguard with wireguard UI docker in the same setup as i previously posted and i have to publish the forward ports for the UDP. However i could be wrong but reading up i would not be overly concerned as it is a UDP port and unless someone gets hold of the wireguard keys theres nothing they could do anyway as the docker wont respond unless the keys are correct and UDP doesent respond in the same way as TCP ports for probing, again could be wrong but thats what i understood when reading up many moons ago

    Thats my config:

    In Zeile 23 sieht man den Grund für Beitrag #23. Es ist nach wie vor dein Problem, dass Docker seine eigenen Regeln an der Firewall vorbei einträgt. Das ist der Grund, warum Docker bei mir nur in einem lxd Container läuft. Man verliert die Kontrolle über seine Firewall, weil Docker zu allen möglichen und unmöglichen Gelegenheiten irgendwas einträgt.

    Die Frage war ja, warum der Container ohne Regel erreichbar ist. Und die Antwort ist Zeile 23. Du kannst die Zeile auch rausnehmen und die Portweiterleitung selber machen. Aber geh davon aus, dass jedes Update die Zeile zurückbringt und deine Firewall wieder aufreißt.

    Zitat von Interessent

    Dafür wurde aber doch ufw- docker installiert um das zu verhindern. Hat ja auf dem alter Server auch so geklappt.

    Ohne dir zu nahe treten zu wollen, aber das wage ich zu bezweifeln. Das klappt vielleicht einmal kurzfristig, aber spätestens nach dem nächsten Docker Update, vielleicht sogar schon bei jedem Restart, trägt Docker wieder in die Firewall ein, was es für richtig hält. Ich habs nicht geschafft, es davon abzuhalten, und mit Firewalls unter Linux hab ich mich viel beschäftigt.

    Wenn man wirklich sicher sein will, dass die Firewall nur das tut, was man selber will, aber nicht das, was Docker will, muss man eine Firewall Instanz vor Docker bringen. Das kann z.B. ein kleiner dedizierter Server sein, der nur Firewall und Router spielt, oder man richtet Docker in einer VM oder einem Container ein. Da kann es sich dann austoben, und in der Instanz davor stellt man alles so ein, wie man es möchte.

    Zitat von Chriz123

    mit der anpassung von Casstg läuft es jetzt mit UFW

    Schon mal als Warnung: Das kann sich jederzeit (!) ändern.

    Zitat von Chriz123

    aber Plesk verwaltet IPtables :\

    Solange du mehrere Tools hast, die in deinen Firewallregeln herumpfuschen, musst damit rechnen, dass Dinge passieren, die du nicht willst. Vor allem, da es nicht so bleibt, wenn du es einmal eingestellt hast, da jedes Update und jeder Neustart Dinge ändern kann.

    Zitat von Interessent

    Thats my config:

    Okay without seeing all of your config files can you answer the following:

    • Why are you running so many different docker networks? If its for additional isolation then so be it fair enough but you are making life a bit more difficult for yourself
    • Did you update your UFW file to add in another additional network as on the original example i gave you the following subnet was not mentioned -172.19.0.0/16.
    • If not then you need to update that file to include the additional lines to include this network as well, then you need to forward the UDP port to the docker container as per the original guide.

    I always have one bridge network all behind a proxy which is simple to manager without issue.

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

    Einmal editiert, zuletzt von Casstg (8. Dezember 2024 um 15:30)

    Zitat von Casstg

    Okay without seeing all of your config files can you answer the following:

    • Why are you running so many different docker networks? If its for additional isolation then so be it fair enough but you are making life a bit more difficult for yourself
    • Did you update your UFW file to add in another additional network as on the original example i gave you the following subnet was not mentioned -172.19.0.0/16.
    • If not then you need to update that file to include the additional lines to include this network as well, then you need to forward the UDP port to the docker container as per the original guide.

    I always have one bridge network all behind a proxy which is simple to manager without issue.

    This is my config, changed it as recommended:

    Hope that helps

    Okay, so your config looks OKISH except possibly one thing. Now im no UFW expert at all but the only thing that stands out is the following:

    Zitat


    -A DOCKER-USER -j ufw-docker-logging-deny -p udp -m udp --dport 0:32767 -d 172.19.0.0/12

    Now i could be wrong, but if i am right the answer is staring us in the face. Again im not an expert on UFW so others feel free to call me an idiot but if im understanding that line correctly it is applying to anything going to the docker network 172.19.0.0/12. However if i am reading it right it is only applying that rule to:

    Code
    --dport 0:32767

    However Wireguard runs on:

    Code
        ports:
      - 51820:51820/udp

    Therefore if my assumption is correct that UDP port is not blocked by that rule

    I would have a backup and do a test to see if that is an issue by changing 32767 to 51821

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

    2 Mal editiert, zuletzt von Casstg (9. Dezember 2024 um 21:11)