|
Anmeldungsdatum: Beiträge: 3400 |
Hallo Users, wann setzt man welches Verfahren ein? sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 80 -j ACCEPT sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 443 -j ACCEPT sudo netfilter-persistent save oder sudo ufw allow 80/tcp sudo ufw allow 443/tcp Greetz undine |
|
Supporter, Wikiteam
Anmeldungsdatum: Beiträge: 9702 Wohnort: Münster |
Diese Regeln machen keinen Sinn, weil sie nichts filtern und nur explizit erlaubten, was sowieso schon möglich ist, weil ein Web-Server läuft.
Das mach aus den gleichen Gründen wie oben ebenfalls keinen Sinn. |
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 3400 |
Hallo, ohne diese Eingabe bekomme ich keinen Zugriff auf meinen Ubuntu 20.04 VPS Webserver. Wie ist das zu erklären, liegt das evtl. an dem VCN, Virtual Cloud Network? https://miro.medium.com/max/637/1*_VAnbOV9v-2mRfQiZasqzw.png |
|
Anmeldungsdatum: Beiträge: 14345 |
|
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 3400 |
ssh Zugang auf den VPS mit Ubuntu 20.04 Eingabe von sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 80 -j ACCEPT sudo iptables -I INPUT 6 -m state --state NEW -p tcp --dport 443 -j ACCEPT sudo netfilter-persistent save dann –> sudo iptables -nvx -L INPUT
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
565 5134209 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
24 1916 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:123
1 60 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:443
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibitedWas kann man daraus ersehen? |
|
Anmeldungsdatum: Beiträge: 14345 |
Die default policy ist auf ACCEPT und die letzte Regel in der INPUT chain, hat das target REJECT für "Alles" was rein will. Man sieht, dass z. Zt. der Zähler (counter) für die NEW-Regel bei den Ports 80 und 443, auf null ist. Bei der REJECT-Regel ist der Zähler z. Zt. auch auf null. Mach mal aus dem W/LAN einen Portscan (oder einen Zugriff) auf die Port 80, 443 und schau dann nach, wie der Zähler der NEW-Regeln ist. |
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 3400 |
Wie soll ich das machen, es ist ein VPS Server? Warum da das wlan nutzen? Ist das System so unsicher? Zur Zeit ist der VPS nicht gestartet, ich nutze ihn nur für Übungszwecke. Wie führe ich konkret den Portscan aus? |
|
Anmeldungsdatum: Beiträge: 14345 |
Nein, das System ist nicht unsicher, wenn die lauschenden Dienste, auch noch richtig konfiguriert sind.
Portscan aus dem Internet, z. B. so: nc -zv <IP-Adresse-Server> 80 443 oder sudo nmap -sS <IP-Adresse-Server> -p80,443 oder sudo nping -c 3 --tcp --flags syn --delay 500ms -g 12345 -p 80,443 <IP-Adresse-Server> |
|
Supporter, Wikiteam
Anmeldungsdatum: Beiträge: 9702 Wohnort: Münster |
Das, was ich Dir schon sagte: Du hast exakt 0 IP-Pakete verworfen, d.h. dieses „Filter“ wirkt genauso gut wie gar kein Filter. Lasse es weg und Du wirst sicherer, weil Du die mögliche Angriffsfläche verringerst: Ohne zustandsbehaftetes Filter ist auch kein DoS-Angriff gegen dieses möglich. |
|
Anmeldungsdatum: Beiträge: 14345 |
BTW: Ja, aber nur deshalb weil noch kein "unberechtigter" Zugriff statt gefunden hat. Wenn der TE, aus dem Internet einen Portscan auf z. B. den Port 23 macht, wird die letzte Regel mit dem REJECT-target wirksam werden und der Zähler der Regel, wird den versuchten Zugriff auch anzeigen. |
|
Supporter, Wikiteam
Anmeldungsdatum: Beiträge: 9702 Wohnort: Münster |
… und das wird der einzige Nutzeffekt des gesamten Filters sein! Denn:
Unzustellbare IP-Pakete zu zählen, kann man einfacher haben, sofern man sich überhaupt dafür interessiert. Derartige Filter, wie das hier beispielhaft vorgestellte, sind immer Unfug, weil sie den Rechner einfacher angreifbar machen und damit dessen Sicherheitsniveau verschlechtern! |
|
Anmeldungsdatum: Beiträge: 14345 |
Kann schon sein, ... aber das ist der Standard bei den Internet-Providern. Z. B. ein nativer IPv4-Internetanschluss in DE, mit einer _providereigenen_ FritzBox (als border device), gescannt aus dem Internet: 91.##.##.## > 192.168.178.22: ICMP host 91.##.##.## unreachable - admin prohibited filter, length 36 RCVD (0.2129s) ICMP [91.##.##.## > 192.168.178.22 Communication administratively prohibited by filtering (type=3/code=13) |
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 3400 |
Hallo, danke euch. Die gewünschten Ergebnisse: nc -zv <IP-Adresse-Server> 80 443 nc -zv 166.162.175.3 80 443 Connection to 166.162.175.3 80 port [tcp/http] succeeded! nc: connect to 166.162.175.3 port 443 (tcp) failed: Connection refused ------ sudo apt install nmap sudo nmap -sS <IP-Adresse-Server> -p80,443 sudo nmap -sS 166.162.175.3 80 -p80,443 Starting Nmap 7.80 ( https://nmap.org ) at 2022-03-09 07:30 CET Nmap scan report for 166.162.175.3 Host is up (0.045s latency). PORT STATE SERVICE 80/tcp open http 443/tcp closed https Nmap done: 2 IP addresses (1 host up) scanned in 1.82 seconds ------- sudo nping -c 3 --tcp --flags syn --delay 500ms -g 12345 -p 80,443 <IP-Adresse-Server> sudo nping -c 3 --tcp --flags syn --delay 500ms -g 12345 -p 80,443 166.162.175.3 Starting Nping 0.7.80 ( https://nmap.org/nping ) at 2022-03-09 07:34 CET SENT (0.0702s) TCP 192.168.178.26:12345 > 166.162.175.3:80 S ttl=64 id=53285 iplen=40 seq=1499168005 win=1480 RCVD (0.1137s) TCP 166.162.175.3:80 > 192.168.178.26:12345 SA ttl=56 id=0 iplen=44 seq=793013816 win=62720 <mss 1452> SENT (0.5704s) TCP 192.168.178.26:12345 > 166.162.175.3:443 S ttl=64 id=53285 iplen=40 seq=1499168005 win=1480 RCVD (0.6143s) TCP 166.162.175.3:443 > 192.168.178.26:12345 RA ttl=56 id=0 iplen=40 seq=0 win=0 SENT (1.0710s) TCP 192.168.178.26:12345 > 166.162.175.3:80 S ttl=64 id=53285 iplen=40 seq=1499168005 win=1480 RCVD (1.1139s) TCP 166.162.175.3:80 > 192.168.178.26:12345 SA ttl=56 id=0 iplen=44 seq=808636490 win=62720 <mss 1452> SENT (1.5725s) TCP 192.168.178.26:12345 > 166.162.175.3:443 S ttl=64 id=53285 iplen=40 seq=1499168005 win=1480 RCVD (1.6151s) TCP 166.162.175.3:443 > 192.168.178.26:12345 RA ttl=56 id=0 iplen=40 seq=0 win=0 SENT (2.0727s) TCP 192.168.178.26:12345 > 166.162.175.3:80 S ttl=64 id=53285 iplen=40 seq=1499168005 win=1480 RCVD (2.1151s) TCP 166.162.175.3:80 > 192.168.178.26:12345 SA ttl=56 id=0 iplen=44 seq=824288477 win=62720 <mss 1452> SENT (2.5737s) TCP 192.168.178.26:12345 > 166.162.175.3:443 S ttl=64 id=53285 iplen=40 seq=1499168005 win=1480 RCVD (2.6194s) TCP 166.162.175.3:443 > 192.168.178.26:12345 RA ttl=56 id=0 iplen=40 seq=0 win=0 Max rtt: 45.658ms | Min rtt: 42.337ms | Avg rtt: 43.452ms Raw packets sent: 6 (240B) | Rcvd: 6 (252B) | Lost: 0 (0.00%) ------- IP-Adressen nachträglich geändert! Die Anwendung ist über http://... und https://... mit einem Internetbrowser nutzbar. Wie kann ich den VPS Server nun besser, sicherer konfigurieren? Wo liegt der "Unfug" konkret? Greetz undine |
|
Anmeldungsdatum: Beiträge: 14345 |
SENT (2.5737s) TCP 192.168.178.26:12345 > 166.162.175.3:443 S ttl=64 id=53285 iplen=40 seq=1499168005 win=1480 RCVD (2.6194s) TCP 166.162.175.3:443 > 192.168.178.26:12345 RA ttl=56 id=0 iplen=40 seq=0 win=0 Der TCP-Port 443 (https) ist aber nicht erreichbar. Das liegt aber nicht an iptables. Schau mal nach, ob der Server, auf dem Port 443 lauscht: sudo netstat -tlpena | grep -iE '80|443' EDIT: Zum Vergleich, hier ein tcp-ping (mit dem syn-flag) an UU und den TCP-Port 443: SENT (0.0414s) TCP 192.168.178.22:23456 > 213.95.41.4:443 S ttl=64 id=43297 iplen=40 seq=2601873059 win=1480 RCVD (0.2275s) TCP 213.95.41.4:443 > 192.168.178.22:23456 SA ttl=55 id=0 iplen=44 seq=3826472663 win=29200 <mss 1460> |
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 3400 |
Richtig, per https://....................... ist der Server nicht zu erreichen. Die angefrage Information: Test auf dem VPS Server ssh Verbingung zum VPS Server https://wiki.ubuntuusers.de/netstat/ sudo apt install net-tools net-tools sudo netstat -tlpena | grep -iE '80|443' Antwort: ------ sudo netstat -tlpena | grep -iE '80|443' tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 101 21821 801/systemd-resolve tcp 0 0 10.0.0.146:60744 166.162.175.3:443 ESTABLISHED 584788 48308 1224/gomon tcp 0 0 10.0.0.146:55044 xxxxx.152:80 TIME_WAIT 0 0 - tcp6 0 0 :::80 :::* LISTEN 0 ------ Bei xxx standen Zahlen. Was ist falsch konfiguriert, wie löse ich das Problem? |
