Seltsames Verhalten Docker,UFW, UFW-Docker

  • Hallo,


    ich habe Wireguard unter Docker installiert. Läuft hervorragend. Mir ist aber bei der Neuninstallation des Servers etwas Seltsames aufgefallen:

    Um die Lücken in der UFW zu schließen, die Docker aufmacht, habe ich das Tool UFW-Docker installiert. Das behebt das und funktioniert mit anderen Containern (und TCP Ports) einwandfrei.


    Der Wireguard Dockercontainer läuft auf 51820:51820, das sind ja UDP Ports. Weder in der UFW noch mit UFW-Docker habe ich den Port 51820 freigegeben und dennoch kann ich vom Smartphone, Laptop etc über Wireguard ins Internet und bekomme die IP-Adresse, die der Server mit Docker hat.


    Wie kann das denn sein?

    Hat zufällig jemand eine Idee?

  • Sobald du in Docker Compose oder ein. Port Mapping beim starten angibst, reißt dir Docker das Loch in den Host => zu erwarten


    Ich löse das ganze allerdings mit Iptables, wo ich meine restlichen Regeln auch drin verwalte.

  • Dann stelle ich mir die Frage, wie genau hast du "alles verboten"? Vielleicht ist das nicht ganz so "alles", wie du denkst.


    Wenn dem aber so ist, dann muss es ja eine Regel geben, die dem Docker-Wireguard die Kommunikation erlaubt. Die sollte doch zu finden sein, selbst bei ufw.

  • So...hier mal die Infos:

  • UNd Teil 2:


  • Da ist definitiv eine Regel drin, die den Zugriff auf das Docker Wireguard erlaubt.

    Code
    Chain DOCKER (2 references)
    target     prot opt source               destination
    ACCEPT     udp  --  anywhere             172.18.0.2           udp dpt:51820

    Das erklärt den möglichen Zugriff. Wo die herkommt: Keine Ahnung.

  • Danke fürs prüfen. Das ist eine gute Frage. Hatte fast vermutet, dass es diese Regel ist.

    Ich vermute, die hat Wireguard geschrieben, und ufw-docker macht zwar alles dicht, aber bereits bestehndes bleibt eben bestehen.

    Die mach ich mal raus bzw. installiere ich das ufw-docker Tool mal bevor ich Wireguard installiere. Mal schauen, ob sich dann was ändert.

  • Also hab die von Dir angesprochene Regel gelöscht. Dann war Ruhe.

    Erst wenn ich es mit ufw-docker freigebe funktioniert es wie es soll.


    Rein aus Interesse, da ich evtl. von UFW weg will zu iptables: Gibt es irgendwo ein Standard iptables Regelwerk, was sicher ist, welches man hernehmen kann und dann seine benötigten Regeln ergänzen kann?


    Ich hab mal im www gesucht, da gibt es zig Vorlagen, aber keine die auf Standard basiert und die man erweitern kann. Irgendwas individuelles ist da immer schon drin

  • Ich habe mir mal UFW Docker angesehen: https://github.com/chaifeng/uf…ing-ufw-and-docker-issues


    Wenn ich es richtig verstehe, aktivierst du damit UFW Docker - hier ein Auszug davon für UDP:

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


    Damit greift UDP von Port 0 bis 32.767 - dein Wiregard Port liegt bei 51.820, ist damit deutlich großer als UFW Docker greift.

    Um diese Theorie zu bestätigen kannst du Wireguard auf einen anderen Port zwischen 0 und 32.000 schalten, oder du erhöhst die Zahl in

    /etc/ufw/after.rules - wobei es sein kann, dass diese Zahl woanders noch hardgecoded ist.


    Ggf. ist hier auch ein Github Issue angebracht.

    Edit:

    Ist Absicht, siehe dazu auch die Erklärung auf Github:


    Zitat


    For UDP protocol, all accesses to ports which is less then 32767 are blocked. Why is this port? Since the UDP protocol is stateless, it is not possible to block the handshake signal that initiates the connection request as TCP does. For GNU/Linux we can find the local port range in the file /proc/sys/net/ipv4/ip_local_port_range. The default range is 32768 60999. When accessing a UDP protocol service from a running container, the local port will be randomly selected one from the port range, and the server will return the data to this random port. Therefore, we can assume that the listening port of the UDP protocol inside all containers are less then 32768. This is the reason that we don't want public networks to access the UDP ports that less then 32768.