undine
Anmeldungsdatum: 25. Januar 2007
Beiträge: 3312
|
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 https://gridscale.io/community/tutorials/linux-firewall/
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
undine schrieb: […]
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
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.
oder sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
Das mach aus den gleichen Gründen wie oben ebenfalls keinen Sinn.
|
undine
(Themenstarter)
Anmeldungsdatum: 25. Januar 2007
Beiträge: 3312
|
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
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13927
|
undine schrieb: Hallo, ohne diese Eingabe bekomme ich keinen Zugriff auf meinen Ubuntu 20.04 VPS Webserver. Wie ist das zu erklären, ...
Evtl. liegt es auch an der default policy der INPUT chain. Poste mal die Ausgabe von:
sudo iptables -nvx -L INPUT
|
undine
(Themenstarter)
Anmeldungsdatum: 25. Januar 2007
Beiträge: 3312
|
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-prohibited Was kann man daraus ersehen?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13927
|
undine schrieb: 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-prohibited Was kann man daraus ersehen?
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.
|
undine
(Themenstarter)
Anmeldungsdatum: 25. Januar 2007
Beiträge: 3312
|
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?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13927
|
undine schrieb: Ist das System so unsicher?
Nein, das System ist nicht unsicher, wenn die lauschenden Dienste, auch noch richtig konfiguriert sind. undine schrieb: Zur Zeit ist der VPS nicht gestartet, ich nutze ihn nur für Übungszwecke. Wie führe ich konkret den Portscan aus?
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>
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
undine schrieb: […] 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-prohibited Was kann man daraus ersehen?
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.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13927
|
kB schrieb: Das, was ich Dir schon sagte: Du hast exakt 0 IP-Pakete verworfen, ...
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.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8616
Wohnort: Münster
|
lubux schrieb: […] der Zähler der Regel, wird den versuchten Zugriff auch anzeigen
… und das wird der einzige Nutzeffekt des gesamten Filters sein! Denn:
Ohne das Filter würde das IP-Paket verworfen werden, weil es im Rechner unzustellbar ist (kein lauschender Socket). Mit Filter wird es gezählt und auch verworfen.
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!
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13927
|
kB schrieb: Derartige Filter, wie das hier beispielhaft vorgestellte, sind immer Unfug, weil sie den Rechner einfacher angreifbar machen und damit dessen Sicherheitsniveau verschlechtern!
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)
|
undine
(Themenstarter)
Anmeldungsdatum: 25. Januar 2007
Beiträge: 3312
|
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
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13927
|
undine schrieb: 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 Die Anwendung ist über http://... und https://... mit einem Internetbrowser nutzbar.
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>
|
undine
(Themenstarter)
Anmeldungsdatum: 25. Januar 2007
Beiträge: 3312
|
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?
|