Unbekannter Verbindungsversuch von lokaler IP

aNewUser · Dec 5th 2017

Ich habe im Syslog meines Servers einen gescheiterten Verbindungsversuch von einer 192.168.*.* IP bemerkt. Wurde da irgendwie die IP gefälscht? Ist es sinnvoll IP-Adressen aus 192.168.*.* gleich in der Firewall auszusperren?

mainziman · Dec 5th 2017

Kann es ein Transportnetz sein, welches hier im Spiel ist?

aNewUser · Dec 6th 2017

Eine (wahrscheinlich) dumme Frage: was ist ein Transportnetz? Ich habe docker installiert, wenn das etwas aussagen könnte.

Die genaue IP war 192.168.11.27.

Mein Heimnetzwerk hat 192.168.2.*.

Also glaube ich nicht, dass etwaige SSH Port Forwarding etwas damit zutun haben könnten.

perryflynn · Dec 6th 2017

Ich logge mich auf meinen Servern auch mit einer 192.168.*.* IP ein, da meine Server via VPN mit meinem lokalen Netz verbunden sind.

Zwischen meinem lokalen Netz und den Servern steht ein VPN Tunnel wo die Knoten IP Adressen im 192.168.169.* Netz haben. Dieses Netz ist in meinem Fall das Transportnetz welches einfach nur zwischen Daheim und den Servern routet.

Lukay · Dec 6th 2017

Du sagst, dass du Docker installiert hast. Wie ist das Netz deiner Container konfiguriert?

Sitzen die möglicherweise in einem internen Netz, vergleichbar mit deinem LAN zuhause?

Ps: Mit "ifconfig" kannst du dir alle Interfaces deines Servers anzeigen lassen. Würden die Container da ein internes Netz haben, würdest du es dort sehen.

aNewUser · Dec 6th 2017

Docker nutzt 172.17.0.*

Code

docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 0.0.0.0
        inet6 fe80::42:78ff:???:???  prefixlen 64  scopeid 0x20<link>
        ether 02:42:78:??:??:??  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5  bytes 438 (438.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Syslog:

Code

Dec  6 09:08:01 ***** kernel: [34649.511397] iptables[DOS]: IN=ens3 OUT= MAC=2a:db:c1:69:cd:0a:2c:6b:f5:a0:77:c0:08:00 SRC=192.168.11.27 DST=37.120.***.*** LEN=48 TOS=0x00 PREC=0x00 TTL=114 ID=64002 PROTO=TCP SPT=60549 DPT=22 WINDOW=65535 RES=0x00 SYN URGP=0

DPT 22 ist schon verdächtig...

___ · Dec 6th 2017

Schade, dass der KVM-Wirt solche Pakete durchreicht. Ich DROPpe die Pakete einfach.

Code

# iptables -nvL --line -t raw
Chain PREROUTING (policy ACCEPT 2126 packets, 1605K bytes)

num   pkts bytes target     prot opt in     out     source               destination         
1       23  1744 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
2     461K  105M            all  --  *      *       0.0.0.0/0            0.0.0.0/0            
3        0     0 DROP       all  --  *      *       127.0.0.0/8          0.0.0.0/0           
4        3   128 DROP       all  --  *      *       0.0.0.0/8            0.0.0.0/0           
5      149  7540 DROP       all  --  *      *       10.0.0.0/8           0.0.0.0/0           
6       19   920 DROP       all  --  *      *       172.16.0.0/12        0.0.0.0/0           
7      207 10008 DROP       all  --  *      *       192.168.0.0/16       0.0.0.0/0           
8        0     0 DROP       all  --  *      *       224.0.0.0/3          0.0.0.0/0

Display More

Lukay · Dec 6th 2017

Ich finde es interessant, dass die überhaupt ankommen.. eigentlich dürften die doch von keinem Router im Internet weiter gegeben werden, oder sehe ich das falsch?

mainziman · Dec 6th 2017

auch wenn Port 22 verdächtig wirkt, der Eintrag im syslog verrät Dir etwas ...

MAC=2a:db:c1:69:cd:0a:2c:6b:f5:a0:77:c0:08:00

2a:db:c1:69:cd:0a <-- MAC Destination, Dein Server

2c:6b:f5:a0:77:c0 <-- MAC Source, ein fetter Router

08:00 <-- TCP

gib mal arp -n ein und sieh Dir das Ergebnis an ...

mei meinen 2 hast folgendes ...

Code

# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
185.194.140.170          ether   36:fa:94:7c:5f:b9   C                     eth0
185.194.140.2            ether   10:0e:7e:26:f1:c0   C                     eth0
185.194.140.1            ether   00:00:5e:00:01:01   C                     eth0
185.194.140.3            ether   2c:6b:f5:a0:77:c0   C                     eth0
185.194.143.82           ether   d6:7e:cc:b1:99:f4   C                     eth0

bzw.

Code

# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
46.38.250.1              ether   00:00:5e:00:01:0d   C                     eth0
46.38.250.3              ether   2c:6b:f5:a0:77:c0   C                     eth0
46.38.250.2              ether   10:0e:7e:26:f1:c0   C                     eth0

die IPs mit .3 haben die selbe MAC wie bei Dir die Quell-MAC, das scheint ein fetter Router zu sein ...

ich wette bei Dir liefert arp -n f. diese MAC-Adresse auch eine IP mit .3

aNewUser · Dec 6th 2017

Stimmt. Genau das gleiche kommt bei mir auch. Also kommen die Pakete von einem internen Gerät?

Warum aber dann der Verbindungsversuch von intern auf SSH? Wenn netcup Zugriff haben wollte gäbe es sicher andere Möglichkeiten .

Da versucht ein Server im internen Netz in meinen zu kommen?

Sind die Server im Rechenzentrum untereinander irgendwie im 192.168 Netz? (Ab hier lassen mich meine Kentnisse über Netzwerke im Stich...)

Ich hatte vor kurzem auch mal eine IP von einem anderen Kunden im Syslog wegen eines Verbindungsversuches auf Port 22.

Was bedeutet das?

Tags