staging.inyokaproject.org

user31085 schrieb:

[…] VPS Server gemietet habe und dort 6tunnel betreibe. So komme ich weiterhin von außen mit einer IPv4 Adresse auf mein IPv6 Netz.

Mit anders Worten: Du betreibst den VPS-Server als Router.

Für diese Aufgabe ist seitens Netfilter in der Filtertabelle die Kette INPUT überhaupt nicht zuständig, d.h. alles was Du hier an Filterregeln definierst oder auch weglässt, ist in Bezug auf die Aufgabenstellung völlig irrelevant.

Für Deine Aufgabenstellung relevant wären die Ketten PREROUTING und FORWARD, aber Du kannst Dir auch hier Experimente ersparen. Weil:

1. Du kannst nicht verhindern, wenn in irgendeiner finsteren Ecke dieser Welt ein Schurke beschließt, Deinen Server anzugreifen, und

2. Du kannst auch mit keiner noch so raffinierten Regel für Netfilter auf Deinem Rechner verhindern, dass ein Schadpaket, welches Deinen Rechner bereits erreicht hat, Deinen Rechner nicht erreicht.

Wenn Netfilter helfen soll, Schadpakete vom Eintreffen auf Deinem Rechner abzuhalten, muss dies bereits auf einem Deinem Rechner vorgeschalteten Gerät geschehen. Einer Firewall.

Was Du tun kannst, ist:

• Den Kernel nicht daran hindern, Pakete, die für ihn erkennbar nicht für ihn bestimmt sind, umgehend zu verwerfen. Dies erreichst Du am besten, wenn Du den Schrott nicht selbst prüfst.

• Die übrig bleibenden Pakete gehören zu Diensten, die auf dem Rechner laufen und können deshalb nicht gefiltert werden. Lediglich der Dienst kann prüfen, ob sie autorisiert sind oder nicht. Also muss die Autorisierung des Dienstes so technisch hochwertig wie möglich sein.

Sichere also die Dienste ab, statt Dich mit Netfilter zu beschäftigen.

user31085 schrieb:

Hat jemand eine Idee, wie ich das umsetzten könnte?

BTW: Wenn Du für einzelne Dienste (z. B. sshd) eine service-unit benutzt, kannst Du die native (oder die generierte) service-unit des Dienstes, mit einer (oder mehreren) drop-in-Dateien ergänzen/verbessern und in deinem Fall, für die [Service]-Section, die Optionen:

IPAddressDeny=any
IPAddressAllow=<Liste_1>
IPAddressAllow=<Liste_2>
IPAddressAllow=<Subnetz>

("IPAddressAllow=<Liste>" auch mehrere Zeilen) benutzen.

Siehe z. B. auch: https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#IPAddressAllow=ADDRESS%5B/PREFIXLENGTH%5D%E2%80%A6

Danke für Eure Hilfe!

@kB Der VPS Server an sich, ist mir "eigentlich" egal. Ich möchte nur nicht, dass die RDP brute force Anfragen mein Endgerät/Server erreichen.

Daher habe ich gedacht, ich lasse nur deutsche IPs zu. Das sind ca. 14000 iptables Einträge und ich habe die Vermutung, dass iptables das nicht verarbeitet bekommt. Wenn ich zwei, drei IP Ranges freigebe, dann gehts - bei den 14000 Einträgen, gehts nicht mehr.

user31085 schrieb:

Daher habe ich gedacht, ich lasse nur deutsche IPs zu. Das sind ca. 14000 iptables Einträge und ich habe die Vermutung, dass iptables das nicht verarbeitet bekommt. Wenn ich zwei, drei IP Ranges freigebe, dann gehts - bei den 14000 Einträgen, gehts nicht mehr.

BTW: Es gibt xt_geoip mit den xtables-addons. Siehe z. B.:

apt show xtables-addons-common

user31085 schrieb:

[…] Der VPS Server an sich, ist mir "eigentlich" egal. Ich möchte nur nicht, dass die RDP brute force Anfragen mein Endgerät/Server erreichen.

Wenn Du den VPS-Server als vorgeschalteten Firewall für Dein Endgerät ansiehst, dann ist Dein Ansatz …

Daher habe ich gedacht, ich lasse nur deutsche IPs zu.

… grundsätzlich valide.

Das sind ca. 14000 iptables Einträge und ich habe die Vermutung, dass iptables das nicht verarbeitet bekommt. Wenn ich zwei, drei IP Ranges freigebe, dann gehts - bei den 14000 Einträgen, gehts nicht mehr.

Allerdings ist die technische Umsetzung über 14000 einzelne Regeln falsch. Für solche Fälle gibt es ipset, womit man alles in eine einzige Regel zusammenfassen kann und diese Regel muss in der Tabelle mangle in die Kette PREROUTING. Allerdings erzeugt natürlich auch eine solche Realisierung erhebliche Rechenlast und bietet damit einem Brute-Force-Angreifer bessere Chancen zur Erzeugung der von ihm angestrebten Fehlfunktion nach Überlastung. Professionelle Firewalls setzen daher noch früher an und programmieren den Netzwerk-Stack mit speziellen BPF.

hab jetzt mal mit xt_geoip gearbeitet. läuft auch soweit.

in der rules.v4 habe ich nun folgendes eingetragen:

-A INPUT -m geoip ! --src-cc DE -j DROP

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
     593    53952 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
      82     2984 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
       1       95 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
    1683   183826 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-host-prohibited
       0        0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            -m geoip ! --source-country DE

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 2260 packets, 369164 bytes)
    pkts      bytes target     prot opt in     out     source               destination
       9      661 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>
       1       95 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>
       8      566 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>
       0        0 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>

Funktioniert leider trotzdem nicht. Ich verzweifel bald....

Warum nicht einfach ein Rate Limit einrichten?

Sorry, aber nach mehreren Tag hin und her, fällt mir nur ein was das Ganze für ein Müll ist. iptables läuft nicht richtig (mit 14000 Datensätze), xt_geoip, usw. Es nervt nur. 😠

Wie würde der Rate Limit Befehl aussehen?

Eine Frage ist noch aufgekommen:

iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

Was bewirkt der zusätzliche Befehl: -m state --state NEW

Wenn ich den RDP Port freigeben will, sollte ich diesen zusätzlichen Befehl nehmen?

user31085 schrieb:

iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

Was bewirkt der zusätzliche Befehl: -m state --state NEW

Dass eingehende Verbindungen mit dem syn-Flag (... für "syn, syn+ack, ack") erlaubt/möglich sind. BTW: Wenn Du RELATED,ESTABLISHED-Verbindungen (bei einer default policy mit DROP), schon _an der richtigen Stelle in der INPUT chain, erlaubt hast, warum brauchst dann noch diese Regel:

iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

? Oder hast Du die Funktionsweise von iptables, noch nicht richtig verstanden?

user31085 schrieb:

Wenn ich den RDP Port freigeben will, sollte ich diesen zusätzlichen Befehl nehmen?

Welchen Befehl meinst Du? Auf welchem Port lauscht der RDP-Dienst?

? Oder hast Du die Funktionsweise von iptables, noch nicht richtig verstanden?

Das sind die Oracle Standard-Einträge, welche ich nicht geändert habe, sondern nur um meine ergänze. Ich würde schon behaupten wollten, dass ich weiß was iptables macht und wie es funktioniert. Die Einzelnen Befehle sind mir nur nicht geläuftig.

Hier der Standardeintrag der rules.v4 von Oracle.

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1583:721303]
:InstanceServices - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -m udp --sport 123 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A OUTPUT -d 169.254.0.0/16 -j InstanceServices
-A InstanceServices -d 169.254.0.2/32 -p tcp -m owner --uid-owner 0 -m tcp --dport 3260 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for securi>
-A InstanceServices -d 169.254.2.0/24 -p tcp -m owner --uid-owner 0 -m tcp --dport 3260 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for securi>
-A InstanceServices -d 169.254.4.0/24 -p tcp -m owner --uid-owner 0 -m tcp --dport 3260 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for securi>
-A InstanceServices -d 169.254.5.0/24 -p tcp -m owner --uid-owner 0 -m tcp --dport 3260 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for securi>
-A InstanceServices -d 169.254.0.2/32 -p tcp -m tcp --dport 80 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or>
-A InstanceServices -d 169.254.169.254/32 -p udp -m udp --dport 53 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifyin>
-A InstanceServices -d 169.254.169.254/32 -p tcp -m tcp --dport 53 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifyin>
-A InstanceServices -d 169.254.0.3/32 -p tcp -m owner --uid-owner 0 -m tcp --dport 80 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security>
-A InstanceServices -d 169.254.0.4/32 -p tcp -m tcp --dport 80 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or>
-A InstanceServices -d 169.254.169.254/32 -p tcp -m tcp --dport 80 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifyin>
-A InstanceServices -d 169.254.169.254/32 -p udp -m udp --dport 67 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifyin>
-A InstanceServices -d 169.254.169.254/32 -p udp -m udp --dport 69 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifyin>
-A InstanceServices -d 169.254.169.254/32 -p udp -m udp --dport 123 -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifyi>
-A InstanceServices -d 169.254.0.0/16 -p tcp -m tcp -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing t>
-A InstanceServices -d 169.254.0.0/16 -p udp -m udp -m comment --comment "See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing t>

Welchen Befehl meinst Du? Auf welchem Port lauscht der RDP-Dienst?

Nach dem ganzen hin und her, werde ich iptables wohl manuell pflegen müssen. Wenn ich nun Angriffe erkenne, wollte ich per Befehl

iptables -A INPUT -s 155.23.0.0/16 -j DROP

die IP Adresse (bzw. ein Subnetz) verwerfen. Um meinen RDP Port (3368) richtig frei zu geben, wollte ich wissen, wie dieser Befehl auszusehen hat. Weiß halt nicht ob

iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

oder

iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

user31085 schrieb:

Nach dem ganzen hin und her, werde ich iptables wohl manuell pflegen müssen.

Wenn Du netfilter-persistent benutzt, musst Du nach jeder "nützlicher/geeigneter/brauchbarer" manueller Änderung der iptables-Regeln:

sudo iptables-save > /etc/iptables/rules.v4

und:

sudo systemctl daemon-reload
sudo systemctl restart netfilter-persistent

, ausführen.

user31085 schrieb:

Weiß halt nicht ob

iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

oder

iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

Mit:

sudo iptables -I INPUT 1 -p tcp -m tcp --dport 22 -j ACCEPT

bist Du "auf der sicheren Seite".

Effizienter als 14000 Regeln wäre es übrigens ip sets zu verwenden, dann hat man nur noch eine Regel. Das ist auch die Technik welche z.B. Sophos in seinen Firewalls verwendet.

Hallelujah! Mit ipset hat es funktioniert. Ich lasse jetzt nur die deutschen IPs durch! Danke!