ImAnonym
Anmeldungsdatum: 24. Mai 2021
Beiträge: 19
|
Hey,
Ich habe vorhin auf zwei verschiedenen Root-Servern (1x VPS und 1x Dedicated) UFW eingerichtet.
Alles hat funktioniert, nur musste ich feststellen, dass obwohl alles außer bestimmte Dienste blockiert werden sollte alles erreichbar ist.
Kann mir jemand helfen und verraten was ich falsch mache? Liegt es irgendwie an "Iptables" woran ich allerdings nichts gemacht habe?
Komisch ist, dass es bei beiden Servern nicht funktioniert und es zwei verschiedene Provider sind. Folgendes habe ich ausgeführt:
| sudo ufw default deny incoming
|
Hier der Status:
1
2
3
4
5
6
7
8
9
10
11
12 | Status: active
To Action From
-- ------ ----
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
443/tcp ALLOW Anywhere
OpenSSH ALLOW Anywhere
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
443/tcp (v6) ALLOW Anywhere (v6)
OpenSSH (v6) ALLOW Anywhere (v6)
|
Das gibt ip a aus:
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 | 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:50:56:44:4a:9d brd ff:ff:ff:ff:ff:ff
inet xxx.xxx.xxx.xx/32 scope global eth0
valid_lft forever preferred_lft forever
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
link/ether 02:42:a8:a6:7a:a8 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
5: veth2e1dd91@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether 6e:65:e9:02:09:65 brd ff:ff:ff:ff:ff:ff link-netnsid 0
15: veth556b288@if14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether 36:19:0e:66:0c:b0 brd ff:ff:ff:ff:ff:ff link-netnsid 5
29: veth63e7843@if28: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether 6e:2b:23:06:2c:b4 brd ff:ff:ff:ff:ff:ff link-netnsid 6
31: veth77eb4ae@if30: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether d2:0a:0a:d0:1e:f9 brd ff:ff:ff:ff:ff:ff link-netnsid 2
33: vethf4aa6ca@if32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether 92:ab:d9:74:f9:c3 brd ff:ff:ff:ff:ff:ff link-netnsid 7
35: vethc903d29@if34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether ae:45:97:e8:48:2a brd ff:ff:ff:ff:ff:ff link-netnsid 1
37: vethd2b7764@if36: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default
link/ether d2:30:f7:a8:00:92 brd ff:ff:ff:ff:ff:ff link-netnsid 3```
|
Ich habe die Ports auch schon manuell blockiert und die Firewall auch neu gestartet, neu installiert und neu geladen. Vielen Dank für eure Hilfe! Moderiert von noisefloor: Verschoben von "Sicherheit" nach "Fortgeschrittene Netzwerkkonfiguration".
|
Doc_Symbiosis
Anmeldungsdatum: 11. Oktober 2006
Beiträge: 4391
Wohnort: Göttingen
|
Hm, also dieses hättest Du gar nicht machen müssen, da es eh default ist:
sudo ufw default deny incoming Aber das dürfte ja trotzdem nichts schaden. Auf welchen Dienst kann denn z.B. noch zugegriffen werden, obwohl der eigentlich geblockt werden sollte? Hast Du noch irgendwas an besonderem Routing oder Bridges oder so eingerichtet? EDIT: Verwendest Du vielleicht das -p flag bei docker?
https://askubuntu.com/questions/652556/uncomplicated-firewall-ufw-is-not-blocking-anything-when-using-docker Man findet auch jeden Fall noch mehrere Probleme, wenn man nach ufw in Verbindung mit docker sucht. Das Problem scheint darin zu bestehen, dass Docker mit bestimmten Optionen auch direkt iptables manipuliert. Dazu findest Du aber Workarounds in obigem Link.
|
ImAnonym
(Themenstarter)
Anmeldungsdatum: 24. Mai 2021
Beiträge: 19
|
Danke für die schnelle Antwort.
Tatsächlich war das Problem mit Docker.
Das konnte ich nun lösen.
Die andere Applikation, die ohne eine Einstellung einen Port durch bringt ohne eine Regeln geschrieben zu haben ist OpemVPN Port 1194.
Ist das auch normal, ändern die auch etwas an den Iptables?
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8625
Wohnort: Münster
|
ImAnonym schrieb: auf […] Root-Servern […] UFW eingerichtet
UFW hat auf Servern absolut nichts zu suchen. Wenn Du auf einem Server eine Firewall einrichten möchtest (was generell eine gute Idee ist), beschäftige Dich mit Netfilter und den dafür vorgesehenen Dienstprogrammen iptables und nftables und vermeide indirektes (und damit unsicheres!) Arbeiten über UFW und Co.
[…] alles erreichbar ist
Durch nichts, was Du auf dem Zielrechner selbst einrichtest, kannst du verhindern, dass irgendwer im Internet IP-Pakete an dieses Ziel schickt. Ein an das Internet angeschlossener Rechner ist erreichbar. (Klinkt logisch, ist es auch und sogar trivial.) Das kann daher schon aus rein logischen Gründen nur durch ein zwischen Internet und Zielrechner geschaltetes separates Element eingeschränkt werden.
|
ImAnonym
(Themenstarter)
Anmeldungsdatum: 24. Mai 2021
Beiträge: 19
|
„ Durch nichts, was Du auf dem Zielrechner selbst einrichtest, kannst du verhindern, dass irgendwer im Internet IP-Pakete an dieses Ziel schickt.“ Klar kann ich mit UFW verhindern, dass gewisse Ports nicht aus dem „lokalen“ 127.0.0.1er Netz erreichbar sind. Was ja auch Sinn macht. Oder anders rum nur von einer gewissen IP wie der eigenen externen.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
ImAnonym schrieb: Die andere Applikation, die ohne eine Einstellung einen Port durch bringt ohne eine Regeln geschrieben zu haben ist OpemVPN Port 1194.
Ist das auch normal, ...
Wie ist die Ausgabe von:
sudo iptables -nvx -L INPUT
?
|
ImAnonym
(Themenstarter)
Anmeldungsdatum: 24. Mai 2021
Beiträge: 19
|
lubux schrieb: ImAnonym schrieb: Die andere Applikation, die ohne eine Einstellung einen Port durch bringt ohne eine Regeln geschrieben zu haben ist OpemVPN Port 1194.
Ist das auch normal, ...
Wie ist die Ausgabe von:
sudo iptables -nvx -L INPUT
?
Folgendes wird ausgegeben:
| Chain INPUT (policy DROP 11787 packets, 498416 bytes)
pkts bytes target prot opt in out source destination
135280 25487828 ufw-before-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
135280 25487828 ufw-before-input all -- * * 0.0.0.0/0 0.0.0.0/0
17410 779309 ufw-after-input all -- * * 0.0.0.0/0 0.0.0.0/0
17215 769397 ufw-after-logging-input all -- * * 0.0.0.0/0 0.0.0.0/0
17215 769397 ufw-reject-input all -- * * 0.0.0.0/0 0.0.0.0/0
17215 769397 ufw-track-input all -- * * 0.0.0.0/0 0.0.0.0/0
|
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
ImAnonym schrieb: Folgendes wird ausgegeben:
Chain INPUT (policy DROP 11787 packets, 498416 bytes)
...
17215 769397 ufw-reject-input all -- * * 0.0.0.0/0 0.0.0.0/0
Die default policy der INPUT chain ist auf DROP und Du hast keine Regel die den Port 1194 erlaubt. Evtl. ist es ein OpenVPN-Client, der ein Loch in die FW bohrt. Wie sind die Ausgaben von:
sudo iptables -nvx -L OUTPUT
sudo iptables -nvx -L POSTROUTING -t nat
ps aux | grep -i vpn
sudo netstat -tulpena | grep -i 1194
?
|
ImAnonym
(Themenstarter)
Anmeldungsdatum: 24. Mai 2021
Beiträge: 19
|
sudo iptables -nvx -L OUTPUT:
| Chain OUTPUT (policy ACCEPT 283 packets, 14784 bytes)
pkts bytes target prot opt in out source destination
121381 27185641 ufw-before-logging-output all -- * * 0.0.0.0/0 0.0.0.0/0
121381 27185641 ufw-before-output all -- * * 0.0.0.0/0 0.0.0.0/0
1498 122498 ufw-after-output all -- * * 0.0.0.0/0 0.0.0.0/0
1498 122498 ufw-after-logging-output all -- * * 0.0.0.0/0 0.0.0.0/0
1498 122498 ufw-reject-output all -- * * 0.0.0.0/0 0.0.0.0/0
1498 122498 ufw-track-output all -- * * 0.0.0.0/0 0.0.0.0/0
|
sudo iptables -nvx -L POSTROUTING -t nat:
| Chain POSTROUTING (policy ACCEPT 95 packets, 6024 bytes)
pkts bytes target prot opt in out source destination
800261 47360806 MASQUERADE all -- * !docker0 172.17.0.0/16 0.0.0.0/0
|
ps aux | grep -i vpn:
| root 2675148 0.0 0.0 8900 672 pts/0 R+ 12:07 0:00 grep --color=auto -i vpn
|
sudo netstat -tulpena | grep -i 1194:
| sudo: netstat: command not found
|
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
ImAnonym schrieb: ps aux | grep -i vpn:
| root 2675148 0.0 0.0 8900 672 pts/0 R+ 12:07 0:00 grep --color=auto -i vpn
|
Nichts zu erkennen. Wie hast Du festgestellt, dass Traffic über den Port 1194 geht? Evtl. mit:
sudo tcpdump -c 50 -vvveni any port 1194
testen.
|
ImAnonym
(Themenstarter)
Anmeldungsdatum: 24. Mai 2021
Beiträge: 19
|
Ich habe ganz einfach eine OpenVPN Sitzung zu diesem Server gestartet. Dies läuft über den Port 1194 und die Verbindung hat funktioniert.
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5348
|
ImAnonym schrieb: Ich habe ganz einfach eine OpenVPN Sitzung zu diesem Server gestartet. Dies läuft über den Port 1194 und die Verbindung hat funktioniert.
Hast du seitdem am Server openVPN gestoppt? Zurzeit laeuft der ja nicht.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
ImAnonym schrieb: Dies läuft über den Port 1194 und die Verbindung hat funktioniert.
Wie bzw. wo hast Du gesehen, dass es der Port 1194 ist? Von wo und mit welchem OS hast Du die VPN-Verbindung hergestellt? Installiere z. B. lsof, denn damit kannst Du einen lauschenden udp/tcp-Port anzeigen lassen:
sudo lsof -nPi
|
ImAnonym
(Themenstarter)
Anmeldungsdatum: 24. Mai 2021
Beiträge: 19
|
lubux schrieb: ImAnonym schrieb: Dies läuft über den Port 1194 und die Verbindung hat funktioniert.
Wie bzw. wo hast Du gesehen, dass es der Port 1194 ist? Von wo und mit welchem OS hast Du die VPN-Verbindung hergestellt? Installiere z. B. lsof, denn damit kannst Du einen lauschenden udp/tcp-Port anzeigen lassen:
sudo lsof -nPi
Ich habe selber konfiguriert dass es über den Port 1194 läuft. Steht such zusätzlich in der Config und auf dem Client.
Der Client war in diesem Fall ein Windows Recher, es funktioniert aber auch von meinem IOS Gerät.
|