[gelöst] podman: published ports nicht im LAN erreichbar

[TRex]

Hi,

ich hab gestern meine docker-Container auf podman migriert, und scheinbar hab ich da ein Problem... die container-Ports sind aus dem LAN nicht erreichbar. Von localhost (auch über die LAN-IP) ists kein Problem.

Gestartet hab ich den Beispielcontainer als root mit:

Code: Alles auswählen

# podman run --rm --publish 192.168.10.100:8080:80 --name webserver quay.io/libpod/banner

curl vom LAN in tcpdump:

Code: Alles auswählen

12:56:16.309903 IP (tos 0x0, ttl 64, id 65446, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.10.23.58116 > 192.168.10.100.8080: Flags [S], cksum 0x6f09 (correct), seq 3755833564, win 32120, options [mss 1460,sackOK,TS val 2821702195 ecr 0,nop,wscale 7], length 0
12:56:17.322901 IP (tos 0x0, ttl 64, id 65447, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.10.23.58116 > 192.168.10.100.8080: Flags [S], cksum 0x6b14 (correct), seq 3755833564, win 32120, options [mss 1460,sackOK,TS val 2821703208 ecr 0,nop,wscale 7], length 0
12:56:18.336179 IP (tos 0x0, ttl 64, id 65448, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.10.23.58116 > 192.168.10.100.8080: Flags [S], cksum 0x671f (correct), seq 3755833564, win 32120, options [mss 1460,sackOK,TS val 2821704221 ecr 0,nop,wscale 7], length 0

iptables (nat und filter) hab ich geflusht und mit podman network reload -a neu anlegen lassen.

OS ist debian stable.

[heisenberg]

Was sagt denn das podman pendant von "docker ps"?
Was sagt denn ein netstat -nltp bzw. ss -tulpen innerhalb des containers (nachdem die entsprechenden Programme im container installiert sind)?

Nachtrag:

Bei mir (Bookworm/Stable) ist die Ausgabe (wget vom gleichen Rechner) ...

Code: Alles auswählen

# podman run --rm --publish 192.168.8.123:8080:80 --name webserver quay.io/libpod/banner &
...
# wget -O-   http://192.168.8.123:8080
--2023-12-14 14:26:35--  http://192.168.8.123:8080/
Verbindungsaufbau zu 192.168.8.123:8080 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 133 [text/plain]
Wird in »STDOUT« gespeichert.

-                                                  0%[                                                                                                           ]       0  --.-KB/s                  ___          __              
  / _ \___  ___/ /_ _  ___ ____ 
 / ___/ _ \/ _  /  ' \/ _ `/ _ \
/_/   \___/\_,_/_/_/_/\_,_/_//_/

-                                                100%[==========================================================================================================>]     133  --.-KB/s    in 0s      

2023-12-14 14:26:35 (14,9 MB/s) - auf die Standardausgabe geschrieben [133/133]

Via Firewallregel doch noch gesperrt?

[TRex]

Was sagt denn ein netstat -nltp bzw. ss -tulpen innerhalb des containers (nachdem die entsprechenden Programme im container installiert sind)?

Wieso innerhalb vom Container? Vom Host aus gehts ja, die Programme lauschen (das libpod/banner image hab ich jetzt auch nur verwendet, um was bekannteres/einfaches zum Zeigen zu haben).

Vom Host aus:

Code: Alles auswählen

# netstat -nltp | grep 8080
tcp        0      0 192.168.10.100:8080     0.0.0.0:*               LISTEN      2298463/conmon
# ss -tulpen | grep 8080
tcp   LISTEN 0      4096                          192.168.10.100:8080       0.0.0.0:*    users:(("conmon",pid=2298463,fd=5)) ino:4426559 sk:3a cgroup:/user.slice/user-0.slice/session-534.scope <->

wget/curl vom gleichen Rechner geht bei mir ja auch.

[heisenberg]

Von einem anderen Rechner funktioniert das bei mir genauso. Ich tippe immer noch auf Firewallregeln.

Code: Alles auswählen

root@GL-SF1200:~# nmap -p8080 192.168.8.123
Starting Nmap 7.70 ( https://nmap.org ) at 2023-12-14 21:48 CST
Unable to find nmap-services!  Resorting to /etc/services
Nmap scan report for tuwork.lan (192.168.8.123)
Host is up (0.12s latency).

PORT     STATE SERVICE
8080/tcp open  unknown
MAC Address: D0:AB:D5:88:FE:23 (Unknown)

root@GL-SF1200:~# wget -O- http://192.168.8.123:8080
Downloading 'http://192.168.8.123:8080'
Connecting to 192.168.8.123:8080
Writing to stdout
   ___          __              
  / _ \___  ___/ /_ _  ___ ____ 
 / ___/ _ \/ _  /  ' \/ _ `/ _ \
/_/   \___/\_,_/_/_/_/\_,_/_//_/

-                    100% |*******************************|   133   0:00:00 ETA
Download completed (133 bytes)

[heisenberg]

Was sagt denn ein netstat -nltp bzw. ss -tulpen innerhalb des containers (nachdem die entsprechenden Programme im container installiert sind)?

Wieso innerhalb vom Container? Vom Host aus gehts ja, die Programme lauschen (das libpod/banner image hab ich jetzt auch nur verwendet, um was bekannteres/einfaches zum Zeigen zu haben).

Ich hatte kürzlich einen Fall, wo jemand seinen Service innerhalb des Containers an 127.0.0.1 gebunden hatte. Da funktioniert die Portfreigabe nicht. Die muss dort an 0.0.0.0 gebunden werden. Aber da das ein offizielles Image von Red Hat ist - wie ich jetzt sehe - tritt so ein Anfängerfehler hier eher nicht auf.

[TRex]

Ich würde ja auch auf Firewall-Regeln tippen, aber die hab ich wie angegeben komplett gelöscht und neu durch podman anlegen lassen... hier der dump:

Code: Alles auswählen

# Generated by iptables-save v1.8.9 (nf_tables) on Thu Dec 14 14:53:51 2023
*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [243:14580]
:OUTPUT ACCEPT [0:0]
:DOCKER - [0:0]
:DOCKER-ISOLATION-STAGE-1 - [0:0]
:DOCKER-ISOLATION-STAGE-2 - [0:0]
:DOCKER-USER - [0:0]
:NETAVARK_FORWARD - [0:0]
-A FORWARD -m comment --comment "netavark firewall plugin rules" -j NETAVARK_FORWARD
-A NETAVARK_FORWARD -d 10.88.0.0/16 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A NETAVARK_FORWARD -s 10.88.0.0/16 -j ACCEPT
COMMIT
# Completed on Thu Dec 14 14:53:51 2023
# Generated by iptables-save v1.8.9 (nf_tables) on Thu Dec 14 14:53:51 2023
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:DOCKER - [0:0]
:NETAVARK-1D8721804F16F - [0:0]
:NETAVARK-DN-1D8721804F16F - [0:0]
:NETAVARK-HOSTPORT-DNAT - [0:0]
:NETAVARK-HOSTPORT-MASQ - [0:0]
:NETAVARK-HOSTPORT-SETMARK - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j NETAVARK-HOSTPORT-DNAT
-A OUTPUT -m addrtype --dst-type LOCAL -j NETAVARK-HOSTPORT-DNAT
-A POSTROUTING -j NETAVARK-HOSTPORT-MASQ
-A POSTROUTING -s 10.88.0.0/16 -j NETAVARK-1D8721804F16F
-A NETAVARK-1D8721804F16F -d 10.88.0.0/16 -j ACCEPT
-A NETAVARK-1D8721804F16F ! -d 224.0.0.0/4 -j MASQUERADE
-A NETAVARK-DN-1D8721804F16F -s 10.88.0.0/16 -p tcp -m tcp --dport 4000 -j NETAVARK-HOSTPORT-SETMARK
-A NETAVARK-DN-1D8721804F16F -s 127.0.0.1/32 -p tcp -m tcp --dport 4000 -j NETAVARK-HOSTPORT-SETMARK
-A NETAVARK-DN-1D8721804F16F -p tcp -m tcp --dport 4000 -j DNAT --to-destination 10.88.0.11:3000
-A NETAVARK-DN-1D8721804F16F -s 10.88.0.0/16 -d 192.168.10.100/32 -p tcp -m tcp --dport 8080 -j NETAVARK-HOSTPORT-SETMARK
-A NETAVARK-DN-1D8721804F16F -s 127.0.0.1/32 -d 192.168.10.100/32 -p tcp -m tcp --dport 8080 -j NETAVARK-HOSTPORT-SETMARK
-A NETAVARK-DN-1D8721804F16F -d 192.168.10.100/32 -p tcp -m tcp --dport 8080 -j DNAT --to-destination 10.88.0.21:80
-A NETAVARK-HOSTPORT-DNAT -p tcp -m tcp --dport 4000 -m comment --comment "dnat name: podman id: 292921d71e2f4140aadb0a429c9080be8caca8812f48aa10ab671f9fd4e6aee8" -j NETAVARK-DN-1D8721804F16F
-A NETAVARK-HOSTPORT-DNAT -p tcp -m tcp --dport 8080 -m comment --comment "dnat name: podman id: 12e6564c491a867dd0f78ecc2dbddac176d672896d70daa0d31746494181aff1" -j NETAVARK-DN-1D8721804F16F
-A NETAVARK-HOSTPORT-MASQ -m comment --comment "netavark portfw masq mark" -m mark --mark 0x2000/0x2000 -j MASQUERADE
-A NETAVARK-HOSTPORT-SETMARK -j MARK --set-xmark 0x2000/0x2000
COMMIT
# Completed on Thu Dec 14 14:53:51 2023

Auf client-Seite ist nichts (>1 client, btw).

[heisenberg]

Ja. DNAT-Regel ist da. Aber eine Zugriffsregel fehlt, da FORWARD-Policy auf DROP ist.

Code: Alles auswählen

iptables -A NETAVARK_FORWARD -p tcp -d 10.88.0.0/16 --dport 80 -j ACCEPT

10.88.0.0/16 ist anscheinend der PODMAN-Container Netzwerkspace.

Das ist das Paket, das bei mir geblockt wird (LOG-Rule am Anfang von NETAVARK_FORWARD):

Code: Alles auswählen

2023-12-14T15:16:33.545004+01:00 tuwork kernel: [15270.533398] IN=wlp3s0 \
    OUT=podman0 MAC=d0:ab:d5:88:fe:23:94:83:c4:31:da:ff:08:00 SRC=192.168.8.1 DST=10.88.0.3 \
    LEN=40 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=34608 DPT=80 WINDOW=0 \
    RES=0x00 RST URGP=0

[TRex]

zweiter Rechner (debian testing), exakt das gleiche Bild...
dritter Rechner (arch), exakt das gleiche Bild...

Also wenns am fehlenden forward hängt, wäre upstream was falsch (ich mach nix anderes als das, was in der Doku steht, und meine iptables, egal was da vorher war, sind aufgeräumt und durch podman erzeugt). Das kann ich mir unmöglich vorstellen. Außerdem interpretiere ich das so, dass erstmal alles an NETAVARK_FORWARD durchgereicht wird, aber um sicher zu sein, fehlt mir da die Übung mit iptables.

Edit: die neue Regel hats aber doch gefixt... verdammt

[heisenberg]

(Ich habe im vorigen Beitrag noch etwas nachgetragen!)

Damit geht es bei mir:

Code: Alles auswählen

# iptables -L -v -n
Chain INPUT (policy ACCEPT 1364 packets, 951K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     6    --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:8080

Chain FORWARD (policy DROP 20 packets, 880 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   29  1264 NETAVARK_FORWARD  0    --  *      *       0.0.0.0/0            0.0.0.0/0            /* netavark firewall plugin rules */

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain NETAVARK_FORWARD (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   19   824 LOG        0    --  *      *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 4
    3   120 ACCEPT     0    --  *      *       0.0.0.0/0            10.88.0.0/16         ctstate RELATED,ESTABLISHED
    3   132 ACCEPT     0    --  *      *       10.88.0.0/16         0.0.0.0/0           
    2    88 ACCEPT     6    --  *      *       0.0.0.0/0            10.88.0.0/16         tcp dpt:80

[TRex]

Ja, was ich aber absolut nicht verstehe: wieso muss ich hier eingreifen? Fehlt da irgendwas?

[TRex]

Habs, es sind Reste von docker.

https://github.com/containers/netavark/ ... 1793456981

Die sind auf all meinen Systemen vorhanden... mal gucken, was ich da noch purgen muss. iptables -F setzt die policy vermutlich auch nicht zurück.

[heisenberg]

The issue seems to be caused by the firewall configuration applied by Docker.
Specifically Docker changes the policy of the FORWARD chain to DROP.

But sadly netavark relies on the policy to be ACCEPT, since it does not add any specific rule, which allows DNATed packets to be actually FORWARDed.

Das finde ich aber sehr seltsam. Dass eine Policy auf DROP ist kann ja durchaus eine gewünschte Sicherheitsentscheidung sein.

Normalerweise würde ich dann auf der Hostebene ansetzen und für den freigegebenen Host-Port 8080 entsprechende Zugriffsregeln für den erlaubten Zugriff setzen. Da die Container-IP-Adresse (10.88.0.3 bei mir) dynamisch ist, kann ich die ja gar nicht wissen und muss deswegen mehr aufreissen als notwendig ist. (z. B. Port 80 für alle Podmancontainer wie in obiger Regel). Oder ich muss mir ein wildes Script basteln, dass die Podman-Container-IP (bei jedem Start jedes Containers) herausfindet und demzufolge die iptables-Regel setzen.

[TRex]

Dass eine Policy auf DROP ist kann ja durchaus eine gewünschte Sicherheitsentscheidung sein.

Wohl wahr, aber wenn ich das entschieden hab, kann ich auch damit leben, die Konsequenzen dafür tragen zu müssen. Genauso, wie wenn ich jedes Verzeichnis in / in nem separaten Volume/Partition hab (hatte Saxman mal so aus seinem System beschrieben). Hier war es mir eben nicht bewusst. Ich hatte auch vorher schon darüber nachgedacht, alles über den eh schon vorhandenen nginx zu leiten, mich dann aber wegen Timeout- und ähnlicher Konfigurationen erstmal dagegen entschieden, dann hätte ich das gar nicht erst bemerkt.

[heisenberg]

Für den vorliegenden Fall ist das geschenkt. Du hast das für Dich entschieden - Thema erledigt!

Aber mir geht es um das Grundsätzliche, dass man keinen einfachen Weg - den ich kenne - bei Podman hat, um mit Firewallregeln den Zugriff zu steuern.

Angenommen ich habe einen Container mit sehr sensiblen Daten, der nur von einigen wenigen IPs zugreifbar sein soll und einen Anderen, der absolut unkritisch ist und komplett offen sein darf. Beide haben einen Port 80 geöffnet, auf unterschiedlichen Host-Ports. Da kann ich dann nicht mehr auf der Ebene von 10.88.0.0/16 Regeln vergeben, sondern dann ist das leider kompliziert.

[TRex]

Ja, und ich weiß auch nicht, wie es mit userspace-Containern läuft - da ist was anderes als netavark am Start. Ist seitens redhat auf jeden Fall so gewollt, ohne Angabe, wie man das genau umsetzen soll [1].

Ich hab mich eigentlich nur aus zwei, drei Gründen für podman entschieden:

1. nach einer Recherche, wie ich docker-container als systemd-Unit hochziehen kann, ergab sich das Bild, dass das mit podman deutlich stressfreier/fehlerfreier ist
2. docker stresst schon ne ganze Weile mit seinem Streben nach Gewinn [2][3][4]
3. podman scheint die beste Alternative mit den meisten Vorteilen zu sein.

Und da meine Systeme zuhause nicht kriegsentscheidend und sowieso isoliert sind...

[1] https://access.redhat.com/solutions/5885821
[2] https://www.golem.de/news/container-reg ... 72678.html
[3] https://news.ycombinator.com/item?id=33258598
[4] https://www.infoworld.com/article/36303 ... users.html

[heisenberg]

Ich habe mal geschaut, was man da tun kann, bzgl. Firewall-Regeln. Grundsätzlich gibt es so etwas wie hook-scripts([1]). Bei docker hat man solches verweigert, weil Änderungen an der Umgebung die Portabiltität brechen. Da haben sie ja auch nicht so Unrecht. Wie auch immer: Mit podman geht das.

Wenn ich da also ein Hook-Verzeichnis setze, in /usr/share/containers/containers.conf:

Code: Alles auswählen

...
 hooks_dir = [
  "/etc/containers/oci/hooks.d",
]

... und einen Hook konfiguriere (/etc/containers/oci/hooks.d/debug-hook.json):

Code: Alles auswählen

{
  "version": "1.0.0",
  "hook": {
    "path": "/usr/local/bin/example-hook-script"
  },
  "when": {
    "always": true,
  },
  "stages": ["prestart","poststart","poststop"]
}

... und dann noch ein hook Script schreibe (/usr/local/bin/example-hook-script):

Code: Alles auswählen

#!/bin/bash

SELF="$(basename $0)"

{
echo "$(date) : PWD: $PWD"

# container id is contained within current path ($PWD)
# PWD: /var/lib/containers/storage/overlay-containers/365211279ff50f06516d2212a1ae14482893afc05a409febca09a96e24cb4507/userdata
CONTAINER_ID=${PWD%/userdata}
CONTAINER_ID=${CONTAINER_ID##*/}
echo "CONTAINER_ID: $CONTAINER_ID"

#echo "IP ADDRESS: $(podman inspect $CONTAINER_ID)" | jq -r ' .[] | .NetworkSettings.IPAddress '
}>>/tmp/$SELF.log 2>&1

Damit bekomme ich zumindest schon mal die Container ID heraus. Mit der obigen podman inspect Zeile würde ich auch noch die IP-Adresse des Containers bekommen. Aber leider hängt sich dann podman insgesamt auf, wenn das ausgeführt wird. Außerhalb des Hook-Scriptes kann ich das auführen. Also geht's an der Stelle so nicht weiter.

[1] https://man.archlinux.org/man/oci-hooks.5.en