Eindeutigkeit von IP-Adressen bei Unitymedia nicht gegeben

Bis vor wenigen Tagen konnte man bei Unitymedia anonym oder mit der Adresse eines anderen Internetteilnehmers im Internet surfen. Sofern man einen Linuxrechner mit dem von Unitymedia bereitgestellen Cisco-Router EPC3212 verbunden hatte (etwa als Firewall), ging das sehr leicht, und wird im Folgenden beschrieben. Linux-Grundkenntnisse werden vorausgesetzt. Da dies nicht mehr funktioniert, sehe ich kein Problem damit, hier eine Anleitung zu veröffentlichen. 🙂

Zuerst guckt man, welche IP und welches Subnetz man im Unitymedia-Netz derzeit nutzt:

srv ~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:08:54:57:43:11 brd ff:ff:ff:ff:ff:ff
inet 37.24.104.181/22 brd 255.255.255.255 scope global eth1

Als nächstes sucht man sich eine freie Adresse, dazu pingt man einfach 254 Hosts im aktuellen Subnetz an (ja, ich weiß, dass das nicht das ganze /22 ist, aber es reicht aus).

for ((i=1;i<255;i++)); do ping 37.24.104.$i -c 1 -w 1 &>/dev/null & done

In der MAC-Adresstabelle stehen nun für kurze Zeit bei erreichbaren Hosts MAC-Adressen, bei nicht-erreichbaren Hosts steht dort “incomplete”:

srv ~ # arp -an | grep 37.24.104. | grep ether
? (37.24.104.180) at 00:23:51:33:44:e1 [ether] on eth1
? (37.24.104.63) at 14:d3:4a:ff:c4:45 [ether] on eth1
[...]

srv ~ # arp -an | grep 37.24.104. | grep incomplete
? (37.24.104.210) at <incomplete> on eth1
? (37.24.104.232) at <incomplete> on eth1
[…]

Eine der unbenutzten IPs kann man sich nun ausleihen.

Achtung: falls man eine in Verwendung befindliche Adresse benutzte, könnte man ggfs. Verbindungsprobleme bei anderen verursachen. Außerdem surft man mit fremder IP!

Man legt zuerst ein sogenanntes macvlan Interface an, damit die neue IP mit einer neuen MAC-Adresse ‘verknüpft’ werden kann.
ip link add link eth1 address 00:11:22:33:44:55 macvlan0 type macvlan

Dann fügt man eine IP hinzu, die frei ist (siehe oben):
ip a add 37.24.104.210/22 dev macvlan0

und aktiviert anschließend das virtuelle Device.
ifconfig macvlan0 up

Nun richtet man in seiner bestehenden Firewall eine Regel ein, die alle Zugriffe eines Hosts hinter der Firewall auf eine neue öffentliche IP umschreibt, wenn man auf eine der IPs von http://checkip.dyndns.org zugreift. Dies ermöglicht es zu verifizieren, ob man tatsächlich mit der falschen IP 37.24.104.210 surft. Außerdem kann man eine der übrigen IPs von http://checkip.dyndns.org aufrufen um zu verifizieren, dass beide IP-Adressen gleichzeitig in Benutzung sind. Im Beispiel nutze ich hier bereits Shorewall und es wird in der passenden iptables-Chain eine Regel dafür angelegt (bei direkter Verwendung von iptables in POSTROUTING anlegen) :

srv ~ # iptables -t nat -I eth1_masq 1 -s 192.168.0.1/32 -d 216.146.38.70/32 -j SNAT --to-source 37.24.104.210

In der Praxis würde man hier die Regel so umschreiben, dass jeglicher Verkehr über die neue IP läuft, und komplett anonym – oder mit der IP von jemand anderem (!) – zu surfen.

srv ~ # iptables -t nat -I eth1_masq 1 -s 192.168.0.1/32 -j SNAT --to-source 37.24.104.210

Vom Rechner 192.168.0.1 hinter unserer Firewall führt man nun z.B. curl oder wget aus, um zu verifizieren, dass ein Aufruf der IP 216.146.38.70 tatsächlich über die neue Quell-IP geschieht:

srv2# curl 216.146.38.70
<html><head><title>Current IP Check</title></head><body>Current IP Address: 37.24.104.210</body></html>
srv2# curl 216.146.39.70
<html><head><title>Current IP Check</title></head><body>Current IP Address: 37.24.104.181</body></html>

Voila, anonymes Internet. Abmahnungen gehen nun möglicherweise an den unschuldigen Nachbarn.

Soweit ich weiß, ist es aber nun behoben! Nach wie vor sieht man aber einiges an ARP-Traffic und DHCP-Requests von anderen Teilnehmern, z.B:

12.576487 10.132.192.1 -> 255.255.255.255 DHCP 329 DHCP ACK      - Transaction ID 0x4010211f
12.627097 00:1d:45:6b:da:d1 -> ff:ff:ff:ff:ff:ff ARP 60 Who has 10.4.128.221?  Tell 10.4.128.1

Warum funktionierte das Ganze? Siehe hierzu: DOCSIS.

Meiner Ansicht nach war das Ganze aber zusätzlich auch eine Fehlkonfiguration bei Unitymedia. Jeder Kunde sollte nur eine MAC und IP nutzen können, und von Unitymedia sollte nur Traffic für IPs durchgeleitet werden, die auch in Benutzung sind und per DHCP an genau diesen Kunden zugewiesen wurden. Ich bin aber kein Experte für Kabelnetze. 🙂

1 thought on “Eindeutigkeit von IP-Adressen bei Unitymedia nicht gegeben

  1. Pingback: Abmahnung von Waldorf Frommer – Teil 3 | Branko Čanak

Leave a Reply

Your email address will not be published. Required fields are marked *