user31085
Anmeldungsdatum: 30. Juni 2017
Beiträge: 17
|
Hallo, mein DSL Anschluss besitzt eine reine IPv6 Adresse, so dass ich mir einen VPS Server gemietet habe und dort 6tunnel betreibe. So komme ich weiterhin von außen mit einer IPv4 Adresse auf mein IPv6 Netz. U.a. habe ich per 6tunnel eine RDP Verbindung eingerichtet (Standard-Port ist geändert und 2FA ist eingerichtet). Das Problem ist, dass öfters per brute force probiert wird auf meinen Rechner zu kommen. Mein Virenscanner blockiert nach einigen Versuchen die IPv6 des VPS Servers, so dass ich auch nicht mehr drauf komme. Derzeit sperre ich manuell (per itables) die IP Adressen, welche mich "angreifen". Am liebsten wäre es mir, ich sperre alle öffentlichen IP Adressen - außer die deutschen IPs. Eine Liste deutscher IP Adressen habe ich, allerdings funktioniert folgender Befehl nicht: iptables -A INPUT -m iprange -–src-range 98.124.172.0-98.124.172.255 -j ACCEPT (Meldung: unknown option "iprange"). Alternativ habe ich an Fail2ban gedacht. So wie ich das verstehe, benötigt Fail2ban allerdings ein logfile - 6tunnel erstellt aber kein logfile. Hat jemand eine Idee, wie ich das umsetzten könnte? Danke.
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7719
|
Wenn das nur für dich ist - alles mit Wireguard machen. Auch den sshd am Server nur hinter Wireguard laufen lassen. Angreifen kann dann nur wer einen gültigen Key hat (oder über ein anderes Gerät geht das bereits eingeklinkt ist). Ansonsten ist da Ruhe. Nachteil: Wireguard ist ein komplettes Netzwerk, nicht nur eine Weiterleitung für einen bestimmten Port. Wenn nur bestimmte Ports o.ä. durchgehen sollen, wie man das von der alten Tunnellösung eventuell gewohnt war, muss man das separat konfigurieren wie in jedem anderen Netzwerk auch.
|
user31085
(Themenstarter)
Anmeldungsdatum: 30. Juni 2017
Beiträge: 17
|
Danke für deine Antwort. Einige Zugänge sind nicht nur für mich. Z.B. tausche ich u.a. beruflich Daten aus. Ich nutze als nicht nur RDP. U.a. wird ein Home Assistant genutzt. Gibt's da noch eine Lösungen?
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 18019
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
So komme ich weiterhin von außen mit einer IPv4 Adresse auf mein IPv6 Netz.
Musst du denn aus Netzen draufkommen, die noch kein IPv6 haben?
Falls ja, geht da Teredo-Tunneling? Falls nein: Spricht was gegen ein VPN, was IPv6 bietet? Das würde die Sache massiv vereinfachen.
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17511
|
user31085 schrieb: Einige Zugänge sind nicht nur für mich. Z.B. tausche ich u.a. beruflich Daten aus. Ich nutze als nicht nur RDP. U.a. wird ein Home Assistant genutzt.
Beruflich: Im Auftrag von deinem Arbeitgeber und der weiß darüber Bescheid 😉
|
user31085
(Themenstarter)
Anmeldungsdatum: 30. Juni 2017
Beiträge: 17
|
Andere Frage: während der Befehl iptables -A INPUT -m iprange --src-range 92.10.0.0-92.15.255.255 -j ACCEPT angenommen wird, wird folgender Befehl mit: unknown option "iprange" abgewiesen iptables -A INPUT -m iprange -–src-range 101.33.10.0-101.33.11.255 -j ACCEPT Warum?
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 18019
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
iptables -A INPUT -m iprange -–src-range 101.33.10.0-101.33.11.255 -j ACCEPT
Schau genau. Halbgeviertstrich
Viertelgeviertstrich
|
user31085
(Themenstarter)
Anmeldungsdatum: 30. Juni 2017
Beiträge: 17
|
Stimmt. Hier im Forum wirds richtig angezeigt. Im Notepad++ sieht es aus, wie zwei Minusse. Danke!
|
trollsportverein
Anmeldungsdatum: 21. Oktober 2010
Beiträge: 4107
|
Portknocking wäre auch noch eine Möglichkeit. Unter dem Artikel gibts auch einen Link auf eine Ubuntu Help Webseite zum Thema.
|
user31085
(Themenstarter)
Anmeldungsdatum: 30. Juni 2017
Beiträge: 17
|
In der rules.v4 habe ich folgendes stehen: :INPUT DROP
-A INPUT -m iprange --src-range 100.100.100.100-111.111.111.111 -j ACCEPT
-A INPUT -p tcp -m ctp --dort 3368 -j ACCPET Die IPs und der Port entsprechen nicht der Realität in meiner rules.v4 Ich nehme jetzt an, dass alle incomming Daten verworfen werden (:INPUT DROP), außer diese kommen aus dem IP-Netz 100.100.100.100-111.111.111.111 und enthalten die Anfrage für den Port 3368. Jedoch funktionieren IPs auch außerhalb der Range. Was mach ich da falsch? Habe ich einen gedanklichen Fehler?
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 14148
|
user31085 schrieb: Jedoch funktionieren IPs auch außerhalb der Range. Was mach ich da falsch? Habe ich einen gedanklichen Fehler?
Poste mal die Ausgabe von:
sudo iptables -nvx -L
|
user31085
(Themenstarter)
Anmeldungsdatum: 30. Juni 2017
Beiträge: 17
|
Wie man erkennt, ein Oracle VPS Server: Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1330 152313 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 source IP range 100.100.100.100-111.111.111.111
5 231 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3368
38047 28127765 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
6639 269178 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0
1125 118947 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
1 32 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:123
1995 119508 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
226828 24660612 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT 42982 packets, 30730133 bytes)
pkts bytes target prot opt in out source destination
4684 382983 InstanceServices all -- * * 0.0.0.0/0 169.254.0.0/16
Chain InstanceServices (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- * * 0.0.0.0/0 169.254.0.2 owner UID match 0 tcp dpt:3260 /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure docum>
0 0 ACCEPT tcp -- * * 0.0.0.0/0 169.254.2.0/24 owner UID match 0 tcp dpt:3260 /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure docum>
0 0 ACCEPT tcp -- * * 0.0.0.0/0 169.254.4.0/24 owner UID match 0 tcp dpt:3260 /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure docum>
0 0 ACCEPT tcp -- * * 0.0.0.0/0 169.254.5.0/24 owner UID match 0 tcp dpt:3260 /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure docum>
0 0 ACCEPT tcp -- * * 0.0.0.0/0 169.254.0.2 tcp dpt:80 /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for securit>
1196 128619 ACCEPT udp -- * * 0.0.0.0/0 169.254.169.254 udp dpt:53 /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for securit>
0 0 ACCEPT tcp -- * * 0.0.0.0/0 169.254.169.254 tcp dpt:53 /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for securit>
0 0 ACCEPT tcp -- * * 0.0.0.0/0 169.254.0.3 owner UID match 0 tcp dpt:80 /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documen>
0 0 ACCEPT tcp -- * * 0.0.0.0/0 169.254.0.4 tcp dpt:80 /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for securit>
3473 253224 ACCEPT tcp -- * * 0.0.0.0/0 169.254.169.254 tcp dpt:80 /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for securit>
0 0 ACCEPT udp -- * * 0.0.0.0/0 169.254.169.254 udp dpt:67 /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for securit>
0 0 ACCEPT udp -- * * 0.0.0.0/0 169.254.169.254 udp dpt:69 /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for securit>
15 1140 ACCEPT udp -- * * 0.0.0.0/0 169.254.169.254 udp dpt:123 /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for securi>
0 0 REJECT tcp -- * * 0.0.0.0/0 169.254.0.0/16 tcp /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impac>
0 0 REJECT udp -- * * 0.0.0.0/0 169.254.0.0/16 udp /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impac>
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 14148
|
user31085 schrieb: Jedoch funktionieren IPs auch außerhalb der Range. Was mach ich da falsch? Habe ich einen gedanklichen Fehler?
Ja, ... Du hast in der INPUT chain Freigaben/Regeln (mit dem target ACCEPT) für ankommende Verbindungen (mit dem state NEW), auch für Verbindungen zu destination-IP-Adressen von außerhalb der Range 100.100.100.100-111.111.111.111. BTW: Warum hast Du noch 2 Regeln mit dem target DROP und Reject, wenn die default policy der INPUT chain, schon auf DROP konfiguriert ist?
|
user31085
(Themenstarter)
Anmeldungsdatum: 30. Juni 2017
Beiträge: 17
|
D.h. ich müsste statt iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT den Befehl:
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT nehmen? Ich weiß, dass ich quasi doppelt die Anweisung drin hab "alles andere verwerfen". Ich hatte den Befehl "iptables -A INPUT -p ALL -j DROP" einmal mal ausprobiert. Werde ich nun wieder löschen.
|
lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 14148
|
user31085 schrieb: D.h. ich müsste statt iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT den Befehl:
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT nehmen?
Nein. Du müsstest diese Regel ganz weg lassen, wenn sich die dest.-IP-Adresse mit dem lauschenden TCP-Port 22, schon in der IP-Range 100.100.100.100-111.111.111.111 befindet.
|