Beantwortet: Merkwürdige RFC1918 Adressen schlagen bei mir über den Züricher vpn auf

theoth

Active Member
Code:
ShW:net2fw:DROP:IN=ZUR10 OUT= MAC= SRC=192.168.2.20 DST=10.3.11.247 LEN=101 TOS=0x00 PREC=0x00 TTL=52 ID=32389 PROTO=UDP SPT=33330 DPT=11247 LEN=81 
ShW:net2fw:DROP:IN=ZUR10 OUT= MAC= SRC=192.168.2.14 DST=10.3.11.247 LEN=101 TOS=0x00 PREC=0x00 TTL=112 ID=4813 PROTO=UDP SPT=51219 DPT=11247 LEN=81 
ShW:net2fw:DROP:IN=ZUR10 OUT= MAC= SRC=192.168.2.25 DST=10.3.11.247 LEN=101 TOS=0x00 PREC=0x00 TTL=48 ID=16559 PROTO=UDP SPT=49174 DPT=11247 LEN=81

Ein 192.168.2.0 Netzwerk gibt es bei mir nicht - muß also von extern kommen. Das sieht wie automatisches portforwarding aus. Hat da jemand vergessen zu natten?
 
Solution
Nö das sind Pakete die ganz 'normal' durchs Internet gehen
und in diesem Fall am Server zufällig an einem Port angekommen sind wo du ein Forwarding hast.

Davon das der Absender eine LAN IP ist darf man sich nicht beeindrucken lassen.
Nicht nur das man einfach so die Source IP fälschen kann, was ja z.b. für diese amplification DDOS Attacken benutzt wird, nein,
es ist sogar egal ob das ein LAN IP ist, das filtert anscheinend niemand.

Ich habe mal probeweise auf meinem Testserver geloggt wie oft sowas passiert
'iptables -I INPUT -i eth0 -s 192.168.0.0/16 -j LOG --log-prefix "TADAA: " --log-level 4'

Innerhalb von 30 Minuten warten 2x :
2016-02-05T14:40:51 IN=eth0 OUT= SRC=192.168.0.3 DST=<mein testserver> LEN=40 TOS=0x00 PREC=0x00...
Nö das sind Pakete die ganz 'normal' durchs Internet gehen
und in diesem Fall am Server zufällig an einem Port angekommen sind wo du ein Forwarding hast.

Davon das der Absender eine LAN IP ist darf man sich nicht beeindrucken lassen.
Nicht nur das man einfach so die Source IP fälschen kann, was ja z.b. für diese amplification DDOS Attacken benutzt wird, nein,
es ist sogar egal ob das ein LAN IP ist, das filtert anscheinend niemand.

Ich habe mal probeweise auf meinem Testserver geloggt wie oft sowas passiert
'iptables -I INPUT -i eth0 -s 192.168.0.0/16 -j LOG --log-prefix "TADAA: " --log-level 4'

Innerhalb von 30 Minuten warten 2x :
2016-02-05T14:40:51 IN=eth0 OUT= SRC=192.168.0.3 DST=<mein testserver> LEN=40 TOS=0x00 PREC=0x00 TTL=111 ID=3542 DF PROTO=TCP SPT=27357 DPT=62105 WINDOW=256 RES=0x00 ACK FIN URGP=0
2016-02-05T14:45:38 IN=eth0 OUT= SRC=192.168.0.2 DST=<mein testserver> LEN=131 TOS=0x00 PREC=0x00 TTL=115 ID=9025 PROTO=UDP SPT=47682 DPT=39910 LEN=111

Ich kann die Pakete aber mal Serverseitig blockieren, die machen ja eh keinen sinn.

Grüße
Lars
 
Solution
Normal sind die nicht - jeder richtig konfigurierte router, der öffentlich IPs routet wird die verwerfen. Die müßten also von lokal stammen - ich droppe die ja auch - aber sehe sowas in einem Interface nach "außen" eigentlich nie.
Blockieren ist wahrscheinlich nicht verkehrt...
 
"jeder richtig konfigurierte router, der öffentlich IPs routet wird die verwerfen"

Sollte man denken.. ist aber gar nicht so. Die Router die das Internet zusammenhalten filtern gar nix.

" Die müßten also von lokal stammen"
Da ich ja auf einem anderen Server in einem anderen RZ auch diese Pakete sehe,
und die von der MAC des Gateways im RZ an eth0 ankommen, kommen die eindeutig aus dem Internet.

Grüße
Lars
 
Darf ich mich hier mal kurz einklinken ? Ich hab nämlich auch eine Frage zu der LAN IP.
Beir mir läuft gerade der VPN Manager mit Kaskade : Amsterdam -> Erfurt ... als IP wird im Tray Icon 217.114.118.25 angezeigt.
Jetzt hab ich noch den SSH Manager aktiv mit den Einstellungen : Socks Proxy, Moscow1, lokaler Port 8050.
Im Browser hab ich als Socks5 Proxy angegeben : localhost:8050

gehe ich jetzt z.B. auch whoer.net wird dort als IP folgende angezeigt : 192.162.100.240

Ist es überhaupt richtig konfiguriert oder geht der Webtraffic jetzt nur noch durch den Socks? Wenn ich es richtig verstanden hab ist doch diese Konstellation eigentlich keine Kaskade á la "VPN -> SSH -> Socks5" sondern
eher ein Tunnel im Tunnel oder ? So hat es jedenfalls mal irgendwer erklärt.
 
Back
Top