|
mb-ware.de
(Themenstarter)
Anmeldungsdatum:
8. September 2024
Beiträge: Zähle...
|
lubux schrieb: mb-ware.de schrieb: Hier die Ausgabe: root@v220240911850328xxxx:~# iptables -nvx -L | grep -i docker
4827500 868462454 DOCKER-USER 0 -- * * 0.0.0.0/0 0.0.0.0/0
902705 223489688 DOCKER 0 -- * br-6fe4932af9a5 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-USER (1 references)
pkts bytes target prot opt in out source destination
4832602 869346823 RETURN 0 -- * * 0.0.0.0/0 0.0.0.0/0
Versuch mal Folgendes (als root):
iptables -I DOCKER-USER 1 -i docker0 -p tcp --dport 8000 -j REJECT
iptables -I DOCKER 1 -i docker0 -p tcp --dport 8000 -j REJECT
Danach Zugriff aus dem Internet, auf den TCP-Port 8000 deines Servers.
... und die Ausgaben von:
iptables -nvx -L DOCKER-USER
iptables -nvx -L DOCKER
hier posten.
ERGÄNZUNG: Wie kann ich herausfinden, wo docker seine "iptables-rules" fest ablegt?
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14402
|
mb-ware.de schrieb: Was bedeutet "docker0" in Deinen Zeilen?
"docker0" ist das Interface.
Versuch mal ohne Interface:
iptables -I DOCKER 1 -p tcp --dport 8000 -j REJECT
iptables -I DOCKER-USER 1 -p tcp --dport 8000 -j REJECT
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14402
|
|
|
mb-ware.de
(Themenstarter)
Anmeldungsdatum:
8. September 2024
Beiträge: Zähle...
|
lubux schrieb: mb-ware.de schrieb: Was bedeutet "docker0" in Deinen Zeilen?
"docker0" ist das Interface.
Versuch mal ohne Interface:
iptables -I DOCKER 1 -p tcp --dport 8000 -j REJECT
iptables -I DOCKER-USER 1 -p tcp --dport 8000 -j REJECT
Danke für Deine Unterstützung - hat aber leider auch nichts genutzt - ich komme immer noch über 8000 auf die COOLIFY-Admin-Ebene! Hier die Ausgabe: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21 | root@v220240911850328xxxx:~# iptables -I DOCKER 1 -p tcp --dport 8000 -j REJECT
root@v220240911850328xxxx:~# iptables -I DOCKER-USER 1 -p tcp --dport 8000 -j REJECT
root@v220240911850328xxxx:~# iptables -nvx -L DOCKER-USER
Chain DOCKER-USER (1 references)
pkts bytes target prot opt in out source destination
0 0 REJECT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8000 reject-with icmp-port-unreachable
0 0 REJECT 6 -- docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8000 reject-with icmp-port-unreachable
5334692 1004643039 RETURN 0 -- * * 0.0.0.0/0 0.0.0.0/0
root@v220240911850328xxxx:~# iptables -nvx -L DOCKER
Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
0 0 REJECT 6 -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8000 reject-with icmp-port-unreachable
0 0 REJECT 6 -- docker0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8000 reject-with icmp-port-unreachable
0 0 ACCEPT 6 -- !br-6fe4932af9a5 br-6fe4932af9a5 0.0.0.0/0 172.18.0.2 tcp dpt:6432
108 4912 ACCEPT 6 -- !br-6fe4932af9a5 br-6fe4932af9a5 0.0.0.0/0 172.18.0.6 tcp dpt:8080
391 21152 ACCEPT 6 -- !br-6fe4932af9a5 br-6fe4932af9a5 0.0.0.0/0 172.18.0.6 tcp dpt:443
364 19098 ACCEPT 6 -- !br-6fe4932af9a5 br-6fe4932af9a5 0.0.0.0/0 172.18.0.6 tcp dpt:80
13 700 ACCEPT 6 -- !br-6fe4932af9a5 br-6fe4932af9a5 0.0.0.0/0 172.18.0.10 tcp dpt:8001
13 720 ACCEPT 6 -- !br-6fe4932af9a5 br-6fe4932af9a5 0.0.0.0/0 172.18.0.3 tcp dpt:6001
45 2280 ACCEPT 6 -- !br-6fe4932af9a5 br-6fe4932af9a5 0.0.0.0/0 172.18.0.8 tcp dpt:80
root@v220240911850328xxxx:~#
|
|
|
mb-ware.de
(Themenstarter)
Anmeldungsdatum:
8. September 2024
Beiträge: Zähle...
|
lubux schrieb: mb-ware.de schrieb: Wie kann ich herausfinden, wo docker seine "iptables-rules" fest ablegt?
Abwarten bis Du hier https://forums.docker.com/t/where-does-docker-save-the-iptables-rules-permanently-in-ubuntu-24-04/143731
eine Antwort bekommst.
Da tut sich nicht wirklich was - krass - dass das niemand weiß ...
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14402
|
mb-ware.de schrieb: Da tut sich nicht wirklich was - krass - dass das niemand weiß ...
BTW: Eigentlich sollte docker von sich aus, gar keine iptables-Regeln autogenerieren. systemd autogeneriert (falls erforderlich bzw. konfiguriert) nur noch nf_tables-Regeln.
Wie sind die Ausgaben von:
ls -la /etc/iptables
nft list ruleset
find / -iname '*iptables*'
?
|
|
mb-ware.de
(Themenstarter)
Anmeldungsdatum:
8. September 2024
Beiträge: 38
|
lubux schrieb: mb-ware.de schrieb: Da tut sich nicht wirklich was - krass - dass das niemand weiß ...
BTW: Eigentlich sollte docker von sich aus, gar keine iptables-Regeln autogenerieren. systemd autogeneriert (falls erforderlich bzw. konfiguriert) nur noch nf_tables-Regeln.
Wie sind die Ausgaben von:
ls -la /etc/iptables
nft list ruleset
find / -iname '*iptables*'
?
Hier die Ausgabe der 3 Befehle (verstehe das nicht wirklich - SMILE): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139 | root@v220240911850328xxxx:~# ls -la /etc/iptables
ls: cannot access '/etc/iptables': No such file or directory
root@v220240911850328xxxx:~# nft list ruleset
# Warning: table ip nat is managed by iptables-nft, do not touch!
table ip nat {
chain DOCKER {
iifname "docker0" counter packets 0 bytes 0 return
iifname "br-6fe4932af9a5" counter packets 3545 bytes 212700 return
iifname != "br-6fe4932af9a5" tcp dport 6432 counter packets 0 bytes 0 dnat to 172.18.0.2:6432
iifname != "br-6fe4932af9a5" tcp dport 8080 counter packets 112 bytes 5072 dnat to 172.18.0.6:8080
iifname != "br-6fe4932af9a5" tcp dport 443 counter packets 415 bytes 22308 dnat to 172.18.0.6:443
iifname != "br-6fe4932af9a5" tcp dport 80 counter packets 377 bytes 19678 dnat to 172.18.0.6:80
iifname != "br-6fe4932af9a5" tcp dport 8001 counter packets 13 bytes 700 dnat to 172.18.0.10:8001
iifname != "br-6fe4932af9a5" tcp dport 6001 counter packets 15 bytes 824 dnat to 172.18.0.3:6001
iifname != "br-6fe4932af9a5" tcp dport 8000 counter packets 52 bytes 2636 dnat to 172.18.0.8:80
}
chain POSTROUTING {
type nat hook postrouting priority srcnat; policy accept;
ip saddr 172.17.0.0/16 oifname != "docker0" counter packets 0 bytes 0 masquerade
ip saddr 172.18.0.0/16 oifname != "br-6fe4932af9a5" counter packets 1203 bytes 68664 masquerade
ip saddr 172.18.0.2 ip daddr 172.18.0.2 tcp dport 6432 counter packets 0 bytes 0 masquerade
ip saddr 172.18.0.6 ip daddr 172.18.0.6 tcp dport 8080 counter packets 0 bytes 0 masquerade
ip saddr 172.18.0.6 ip daddr 172.18.0.6 tcp dport 443 counter packets 0 bytes 0 masquerade
ip saddr 172.18.0.6 ip daddr 172.18.0.6 tcp dport 80 counter packets 0 bytes 0 masquerade
ip saddr 172.18.0.10 ip daddr 172.18.0.10 tcp dport 8001 counter packets 0 bytes 0 masquerade
ip saddr 172.18.0.3 ip daddr 172.18.0.3 tcp dport 6001 counter packets 0 bytes 0 masquerade
ip saddr 172.18.0.8 ip daddr 172.18.0.8 tcp dport 80 counter packets 0 bytes 0 masquerade
}
chain PREROUTING {
type nat hook prerouting priority dstnat; policy accept;
fib daddr type local counter packets 33296 bytes 1653374 jump DOCKER
}
chain OUTPUT {
type nat hook output priority dstnat; policy accept;
ip daddr != 127.0.0.0/8 fib daddr type local counter packets 0 bytes 0 jump DOCKER
}
}
# Warning: table ip filter is managed by iptables-nft, do not touch!
table ip filter {
chain DOCKER {
tcp dport 8000 counter packets 0 bytes 0 reject
iifname "docker0" tcp dport 8000 counter packets 0 bytes 0 reject
ip daddr 172.18.0.2 iifname != "br-6fe4932af9a5" oifname "br-6fe4932af9a5" tcp dport 6432 counter packets 0 bytes 0 accept
ip daddr 172.18.0.6 iifname != "br-6fe4932af9a5" oifname "br-6fe4932af9a5" tcp dport 8080 counter packets 112 bytes 5072 accept
ip daddr 172.18.0.6 iifname != "br-6fe4932af9a5" oifname "br-6fe4932af9a5" tcp dport 443 counter packets 415 bytes 22308 accept
ip daddr 172.18.0.6 iifname != "br-6fe4932af9a5" oifname "br-6fe4932af9a5" tcp dport 80 counter packets 377 bytes 19678 accept
ip daddr 172.18.0.10 iifname != "br-6fe4932af9a5" oifname "br-6fe4932af9a5" tcp dport 8001 counter packets 13 bytes 700 accept
ip daddr 172.18.0.3 iifname != "br-6fe4932af9a5" oifname "br-6fe4932af9a5" tcp dport 6001 counter packets 15 bytes 824 accept
ip daddr 172.18.0.8 iifname != "br-6fe4932af9a5" oifname "br-6fe4932af9a5" tcp dport 80 counter packets 52 bytes 2636 accept
}
chain DOCKER-ISOLATION-STAGE-1 {
iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 jump DOCKER-ISOLATION-STAGE-2
iifname "br-6fe4932af9a5" oifname != "br-6fe4932af9a5" counter packets 11019 bytes 6557391 jump DOCKER-ISOLATION-STAGE-2
counter packets 5488214 bytes 1034286173 return
}
chain DOCKER-ISOLATION-STAGE-2 {
oifname "docker0" counter packets 0 bytes 0 drop
oifname "br-6fe4932af9a5" counter packets 0 bytes 0 drop
counter packets 11019 bytes 6557391 return
}
chain FORWARD {
type filter hook forward priority filter; policy drop;
counter packets 5488214 bytes 1034286173 jump DOCKER-USER
counter packets 5488214 bytes 1034286173 jump DOCKER-ISOLATION-STAGE-1
oifname "docker0" ct state related,established counter packets 0 bytes 0 accept
oifname "docker0" counter packets 0 bytes 0 jump DOCKER
iifname "docker0" oifname != "docker0" counter packets 0 bytes 0 accept
iifname "docker0" oifname "docker0" counter packets 0 bytes 0 accept
oifname "br-6fe4932af9a5" ct state related,established counter packets 4231789 bytes 718021368 accept
oifname "br-6fe4932af9a5" counter packets 1245406 bytes 309707414 jump DOCKER
iifname "br-6fe4932af9a5" oifname != "br-6fe4932af9a5" counter packets 11019 bytes 6557391 accept
iifname "br-6fe4932af9a5" oifname "br-6fe4932af9a5" counter packets 1244403 bytes 309655164 accept
}
chain DOCKER-USER {
tcp dport 8000 counter packets 0 bytes 0 reject
iifname "docker0" tcp dport 8000 counter packets 0 bytes 0 reject
counter packets 5488214 bytes 1034286173 return
}
}
root@v220240911850328xxxx:~# find / -iname '*iptables*'
/proc/sys/net/bridge/bridge-nf-call-iptables
/usr/lib/python3/dist-packages/ufw/__pycache__/backend_iptables.cpython-312.pyc
/usr/lib/python3/dist-packages/ufw/backend_iptables.py
/usr/sbin/iptables-legacy-restore
/usr/sbin/iptables
/usr/sbin/iptables-nft-restore
/usr/sbin/iptables-legacy-save
/usr/sbin/iptables-apply
/usr/sbin/iptables-restore-translate
/usr/sbin/iptables-translate
/usr/sbin/iptables-save
/usr/sbin/iptables-legacy
/usr/sbin/iptables-nft-save
/usr/sbin/iptables-restore
/usr/sbin/iptables-nft
/usr/bin/iptables-xml
/usr/share/iptables
/usr/share/iptables/iptables.xslt
/usr/share/bash-completion/completions/iptables
/usr/share/mime/text/x-iptables.xml
/usr/share/doc/iptables
/usr/share/ufw/iptables
/usr/share/lintian/overrides/iptables
/usr/share/man/man1/iptables-xml.1.gz
/usr/share/man/man8/iptables.8.gz
/usr/share/man/man8/iptables-restore.8.gz
/usr/share/man/man8/iptables-restore-translate.8.gz
/usr/share/man/man8/iptables-save.8.gz
/usr/share/man/man8/iptables-nft-restore.8.gz
/usr/share/man/man8/iptables-nft.8.gz
/usr/share/man/man8/iptables-legacy-save.8.gz
/usr/share/man/man8/iptables-apply.8.gz
/usr/share/man/man8/iptables-nft-save.8.gz
/usr/share/man/man8/iptables-translate.8.gz
/usr/share/man/man8/iptables-legacy-restore.8.gz
/usr/share/man/man8/iptables-legacy.8.gz
/usr/share/man/man8/iptables-extensions.8.gz
/usr/src/linux-headers-6.8.0-41-generic/include/config/IP_NF_IPTABLES
/usr/src/linux-headers-6.8.0-41-generic/include/config/IP6_NF_IPTABLES
/usr/src/linux-headers-6.8.0-44-generic/include/config/IP_NF_IPTABLES
/usr/src/linux-headers-6.8.0-44-generic/include/config/IP6_NF_IPTABLES
/sys/devices/virtual/net/docker0/bridge/nf_call_iptables
/sys/devices/virtual/net/br-6fe4932af9a5/bridge/nf_call_iptables
/etc/alternatives/iptables
/etc/alternatives/iptables-save
/etc/alternatives/iptables-restore
/var/lib/dpkg/alternatives/iptables
/var/lib/dpkg/info/iptables.list
/var/lib/dpkg/info/iptables.postinst
/var/lib/dpkg/info/iptables.md5sums
/var/lib/dpkg/info/iptables.prerm
root@v220240911850328xxxx:~#
|
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14402
|
mb-ware.de schrieb: root@v220240911850328xxxx:~# nft list ruleset
# Warning: table ip nat is managed by iptables-nft, do not touch!
# Warning: table ip filter is managed by iptables-nft, do not touch!
}
Lt. "list ruleset" sind keine native nf_tables-Regeln generiert. Auch von docker wird (noch) iptables (bzw. dessen Syntax) benutzt.
|
|
mb-ware.de
(Themenstarter)
Anmeldungsdatum:
8. September 2024
Beiträge: 38
|
lubux schrieb: mb-ware.de schrieb: root@v220240911850328xxxx:~# nft list ruleset
# Warning: table ip nat is managed by iptables-nft, do not touch!
# Warning: table ip filter is managed by iptables-nft, do not touch!
}
> Lt. "list ruleset" sind keine native nf_tables-Regeln generiert. Auch von docker wird (noch) iptables (bzw. dessen Syntax) benutzt.
Und das heißt jetzt für den Port 8000?
Man kann ihn nicht schließen oder man kann nicht finden, wo er geöffnet wird?
Beste Grüße MB
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14402
|
mb-ware.de schrieb: Und das heißt jetzt für den Port 8000? Man kann ihn nicht schließen oder man kann nicht finden, wo er geöffnet wird?
Lt. der Doku für docker sollte das mit der DOCKER-USER chain schon möglich sein:
iptables -I DOCKER-USER 1 -i eth0 -p tcp --dport 8000 -j DROP
Quelle: https://docs.docker.com/engine/network/packet-filtering-firewalls/
Ich weiß nicht welche Rolle netcup bei der Benutzung von iptables (oder nf_tables) auf deinem Server, hat. EDIT: Wenn Du ufw noch aktiv hast,
systemctl status ufw
dann teste mal mit deaktivierter ufw. Evtl. hat ufw auch einen Einfluss auf die DOCKER chains.
|
|
mb-ware.de
(Themenstarter)
Anmeldungsdatum:
8. September 2024
Beiträge: 38
|
Wenn Du ufw noch aktiv hast,
systemctl status ufw
dann teste mal mit deaktivierter ufw. Evtl. hat ufw auch einen Einfluss auf die DOCKER chains.
Ich war der Meinung ufw ist bereits deaktiviert - oder? Hier die Ausgabe: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 | root@v220240911850328xxxx:~# systemctl status ufw
● ufw.service - Uncomplicated firewall
Loaded: loaded (/usr/lib/systemd/system/ufw.service; enabled; preset: enab>
Active: active (exited) since Fri 2024-09-13 10:28:11 CEST; 1h 8min ago
Docs: man:ufw(8)
Process: 492 ExecStart=/usr/lib/ufw/ufw-init start quiet (code=exited, stat>
Main PID: 492 (code=exited, status=0/SUCCESS)
CPU: 8ms
Sep 13 10:28:11 v220240911850328xxxx systemd[1]: Starting ufw.service - Uncompl>
Sep 13 10:28:11 v220240911850328xxxx systemd[1]: Finished ufw.service - Uncompl>
root@v220240911850328xxxx:~# ufw status
Status: inactive
root@v220240911850328xxxx:~#
|
netcup stellt nur den Server - sie haben 0,0 Einfluß auf die Installation!!!! Wie kann ich den "ufw-Service" denn deaktivieren? Danke!
|
|
mb-ware.de
(Themenstarter)
Anmeldungsdatum:
8. September 2024
Beiträge: 38
|
Wenn Du ufw noch aktiv hast,
systemctl status ufw
dann teste mal mit deaktivierter ufw. Evtl. hat ufw auch einen Einfluss auf die DOCKER chains.
So - jetzt habe ich nochmal getestet - davor auch den ufw-Service mit "systemctl disable ufw.service" deaktiviert! Hier die Ausgabe - aber Port 8000 ist nachwievor zugänglich ... 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 | root@v220240911850328xxxx:~# systemctl status ufw
○ ufw.service - Uncomplicated firewall
Loaded: loaded (/usr/lib/systemd/system/ufw.service; disabled; preset: ena>
Active: inactive (dead)
Docs: man:ufw(8)
root@v220240911850328xxxx:~# iptables -I DOCKER-USER 1 -i eth0 -p tcp --dport 8000 -j DROP
root@v220240911850328xxxx:~# iptables -nvx -L DOCKER-USER
Chain DOCKER-USER (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP 6 -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8000
13068 3372613 RETURN 0 -- * * 0.0.0.0/0 0.0.0.0/0
root@v220240911850328xxxx:~# iptables -I DOCKER 1 -p tcp --dport 8000 -j REJECT
root@v220240911850328xxxx:~# iptables -I DOCKER-USER 1 -p tcp --dport 8000 -j REJECT
root@v220240911850328xxxx:~#
|
|
|
encbladexp
Ehemaliger
Anmeldungsdatum:
16. Februar 2007
Beiträge: 17531
|
Ich will ehrlich sein: Ich habe nicht die vorherigen 4 Seite gelesen. Aber: Kann es sein das du einen Dienst per Docker auf 8080 laufen hast, und diesen nun für z.B. das Internet verstecken willst, z.b. weil man eh nur per Loadbalancer (nginx?) dran soll? Falls ja hast du 2 Optionen:
DOCKER-USER Chain, welche man dir schon geraten hat. Den Service nicht auf 0.0.0.0 zu exposen, sondern nur auf 127.0.0.1, spart dir auch das Spiel mit iptables.
Wie Docker seine regeln anlegt ist klar definiert, da gibt es nicht viel Überraschungen, meist exposen die Leute aber einfach zu viel. Hilfreich wäre der output von:
docker container ls --all Und eventuell kannst du mir beantworten von wo aus der Dienst erreichbar sein soll. Aktuell scheint es mir wollt ihr Port 8080 einfach von außen zumachen, was man sich wie erwähnt meist sparen kann.
|
|
lubux
Anmeldungsdatum:
21. November 2012
Beiträge: 14402
|
mb-ware.de schrieb: Hier die Ausgabe - aber Port 8000 ist nachwievor zugänglich ...
Schau mal nach, ob es auch die DOCKER-INPUT chain gibt:
iptables -nvx -L DOCKER-INPUT
Wenn ja, dann mal versuchen (als root):
iptables -I DOCKER-INPUT 1 -j DROP
und den Zugang aus dem Internet testen. Wenn es funktioniert, kann man die Regel noch optimieren/anpassen.
|
|
mb-ware.de
(Themenstarter)
Anmeldungsdatum:
8. September 2024
Beiträge: 38
|
lubux schrieb: mb-ware.de schrieb: Hier die Ausgabe - aber Port 8000 ist nachwievor zugänglich ...
Schau mal nach, ob es auch die DOCKER-INPUT chain gibt:
iptables -nvx -L DOCKER-INPUT
Wenn ja, dann mal versuchen (als root):
iptables -I DOCKER-INPUT 1 -j DROP
und den Zugang aus dem Internet testen. Wenn es funktioniert, kann man die Regel noch optimieren/anpassen.
Nach einem reboot und Deinem Befehl oben sieht es so aus:
| Last login: Sat Sep 14 11:26:38 2024 from 178.202.yy.yyy
root@v220240911850328xxxx:~# iptables -nvx -L DOCKER-INPUT
iptables: No chain/target/match by that name.
root@v220240911850328xxxx:~#
|
|