staging.inyokaproject.org

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.

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.

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?

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.

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 😉

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?

iptables -A INPUT -m iprange -–src-range 101.33.10.0-101.33.11.255 -j ACCEPT

Schau genau.

Halbgeviertstrich Viertelgeviertstrich

Stimmt. Hier im Forum wirds richtig angezeigt. Im Notepad++ sieht es aus, wie zwei Minusse.

Danke!

Portknocking wäre auch noch eine Möglichkeit. Unter dem Artikel gibts auch einen Link auf eine Ubuntu Help Webseite zum Thema.

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?

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

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>

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?

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.

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.