• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Private Netzwerkadressen im Internet zurueckverfolgbar?

framp

Moderator
Teammitglied
Ich habe da mal 2 Fragen :lol:

1) Es gibt da die 3 reservierten privaten Adressbereiche 10.0.0.0-10.255.255.255, 172.16.0.0-172.31.255.255 und 192.168.0.0-192.168.255.255 die im Internet nichts zu suchen haben.
In der letzten Zeit versucht immer wieder jemand mit 172.16.2.225 vom Internet bei mir ins Netz zu kommen (iptables messages im log). Ich wuerde gerne wissen woher der kommt.
Leider bringt weder nslookup noch mtr was :cry: . Weiss jemand einen Weg das rauszubekommen bzw ist das ueberhaupt moeglich?

2) Ist es moeglich, dass jemand seine IP Adresse faked in eine private Netzadresse (ist technisch moeglich) und dann wieder die Antwort erhaelt uebers Internet (ist moeglich? Nach meinem Verstaendnis nicht da die Quell IP Adresse, die vom Empfaenger benutzt wird als Zielandress nicht aufgeloest werden kann) . D.h. eigentlich macht IP spoofing nur fuer DOS Angriffe Sinn wo auf keine Antwort gewartet wird und derjenige, der versucht bei mir mit einer privaten Adresse reinzukommen wird nie Erfolg haben (Abgesehn, dass sowieso kein Erfolg durch FW moeglich ist). Ist meine Annahme richtig? :?:
 

Martin Breidenbach

Ultimate Guru
Bei dem 172er Bereich weiß ich nie auswendig wo der genau liegt... ich geh jetzt mal davon aus daß das stimmt.

Theoretisch sollten IP-Adressen aus diesen Bereichen nicht übers Internet geroutet werden. Dazu müssen die Router aber auch so konfiguriert werden daß sie Pakete mit solchen Absendern auch wegschmeißen.

Wenn jetzt jemand mit gefälschten Absenderadressen Pakete sendet und die vom Provider oder dazwischen liegenden Routern NICHT gefiltert werden dann wird man die kaum zurückverfolgen können.
 
OP
framp

framp

Moderator
Teammitglied
Martin Breidenbach schrieb:
Bei dem 172er Bereich weiß ich nie auswendig wo der genau liegt... ich geh jetzt mal davon aus daß das stimmt.
Quelle: Linux Network Operations Guide, OReilley 8)

Aber ich kannte bislang auch nur den 10er und 192er Bereich. Man lernt eben nie aus :D. Das eine ist class A, das naechste class C - und da muss doch was fehlen ...

Aber das ist nur eine Antwort auf 1). Wie sieht's mit 2) aus?
 
Moin framp,

da normalerweise jeder DNS und jeder 'dadraussenrouter' Adressen aus dem privaten Bereich nicht weiterleitet, muß der Traffic aus dem Netz deines Providers kommen. Also hat sich einer entweder an deine Leitung gehängt (ich weiß ja nicht wie Du angebunden bist), oder er betreibt eine Form von Masquerading die mir jetzt nicht so ganz einleuchtet, ich mein im Sinne von: Wieso filtert der Provider nicht darauf?
Ich denke, Du solltest deinen Provider darauf mal ansprechen/schreiben.
 

oc2pus

Ultimate Guru
aus meiner FW FAQ ...

I see these strange log entries occasionally; what are they?

Nov 25 18:58:52 linux kernel:
Shorewall:net2all:DROP:IN=eth1 OUT=
MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00 SRC=206.124.146.179
DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP
TYPE=3 CODE=3 [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00
TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]

192.0.2.3 is external on my firewall... 172.16.0.0/24 is my internal LAN

Answer: While most people associate the Internet Control Message Protocol (ICMP) with “ping”, ICMP is a key piece of the internet. ICMP is used to report problems back to the sender of a packet; this is what is happening here. Unfortunately, where NAT is involved (including SNAT, DNAT and Masquerade), there are a lot of broken implementations. That is what you are seeing with these messages.

Here is my interpretation of what is happening -- to confirm this analysis, one would have to have packet sniffers placed a both ends of the connection.

Host 172.16.1.10 behind NAT gateway 206.124.146.179 sent a UDP DNS query to 192.0.2.3 and your DNS server tried to send a response (the response information is in the brackets -- note source port 53 which marks this as a DNS reply). When the response was returned to to 206.124.146.179, it rewrote the destination IP TO 172.16.1.10 and forwarded the packet to 172.16.1.10 who no longer had a connection on UDP port 2857. This causes a port unreachable (type 3, code 3) to be generated back to 192.0.2.3. As this packet is sent back through 206.124.146.179, that box correctly changes the source address in the packet to 206.124.146.179 but doesn't reset the DST IP in the original DNS response similarly. When the ICMP reaches your firewall (192.0.2.3), your firewall has no record of having sent a DNS reply to 172.16.1.10 so this ICMP doesn't appear to be related to anything that was sent. The final result is that the packet gets logged and dropped in the all2all chain. I have also seen cases where the source IP in the ICMP itself isn't set back to the external IP of the remote NAT gateway; that causes your firewall to log and drop the packet out of the rfc1918 chain because the source IP is reserved by RFC 1918.
 
OP
framp

framp

Moderator
Teammitglied
@geier0815
D.h. es werden alle privaten Adressen nicht geroutet sofern die Router so eingestellt sind? D.h. dann aber dass mein Provider (t-com) das nicht tut. Muss er das tun? Aber ich weiss immer noch nicht ob es technisch moeglich ist mit den privaten Adressen durchs Internet (sofern alles durchgeroutet wird) von A nach B kommt :cry:

@oc2pus
Das ist leider kein Ping. Es sind SYN requests auf ports >1024. Ich werde mal snort drauf ansetzen. Mal sehen ob da ein Muster zu erkennen ist.
 
framp schrieb:
@geier0815
D.h. es werden alle privaten Adressen nicht geroutet sofern die Router so eingestellt sind? D.h. dann aber dass mein Provider (t-com) das nicht tut. Muss er das tun? Aber ich weiss immer noch nicht ob es technisch moeglich ist mit den privaten Adressen durchs Internet (sofern alles durchgeroutet wird) von A nach B kommt :cry:
[...]
Alle Router die ausserhalb des Providernetzes liegen, verwerfen Adressen aus dem privaten Adressbereich, deshalb betreibst Du ja NAT (NetworkAdressTranslation) mittels Masquerading. Wenn Du dich da ein bißchen schlauer machen willst, kann ich dir das Buch "TCP/IP Netzwerk-Administration" aus dem O'Reilly-Verlag empfehlen.
 

Martin Breidenbach

Ultimate Guru
Das Problem ist ja auch: wie soll ein Router denn den Rückweg zu einer privaten Adresse finden ? Die kann man ja nicht eindeutig zuordnen.

Angenommen die würden nicht gefiltert.
Angenommen da wäre kein NAT am Werk.

Dann wären ja Tausende allein mit der 192.168.0.1 im Netz.

Das kann nicht funktionieren.
 
G

Guest

Gast
Meine Realadresse ist auch ne 172 löl xD

red:~ # ifconfig eth1
eth1 Link encap:Ethernet HWaddr 00:50:BF:D7:C9:08
inet addr:172.21.0.26 Bcast:172.21.15.255 Mask:255.255.0.0
inet6 addr: fe80::250:bfff:fed7:c908/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:13607 errors:0 dropped:0 overruns:0 frame:0
TX packets:13150 errors:0 dropped:0 overruns:0 carrier:0
collisions:141 txqueuelen:1000
RX bytes:11204919 (10.6 Mb) TX bytes:1574957 (1.5 Mb)
Interrupt:10 Base address:0x1f00

Bekomme eine Maskierte Ip (Die ihr seht) und diese Ip Adresse Oo Ist von meinen shice ISP so festgesetzt daher kann keiner auf meinen apache usw extern zugreifen ^-^

Ich hoffe mal, dass es das richtige ist was ihr wissen wolltet :D
 
Oben