Portfreigabe und DynDNS: Zugriff vom internen lokalen Netz auf DnyDNS-URL

[frank_m24]

Hallo,

Mich würde einfach interessieren warum die spoofing-Gefahr steigt.

Die meisten Virenscanner und Firewalls setzen die eigene öffentliche IP in die Whitelist, da es sonst zu Schwierigkeiten auf dem localhost mit einigen Anwendungen kommen kann. Ankommende Pakete mit der eigenen IP werden also nicht überprüft bzw. gefiltert. Das machen sich böse Buben gerne Mal zunutze. Stichwort ist IP-Spoofing, nicht DNS-Spoofing. Wenn du darunter bei Wikipedia suchst, findest du folgendes:

IP-Spoofing bezeichnet in Computernetzen das Versenden von IP-Paketen mit gefälschter Absender-IP-Adresse.
...
Paketfilter sind eine mögliche Gegenmaßnahme gegen IP-Spoofing. Das Gateway zu einem Netzwerk sollte eine eingehende Filterung vornehmen: Von außen kommende Pakete, die Quelladressen von innenliegenden Rechnern haben, werden verworfen. Dies verhindert, dass ein externer Angreifer die Adresse einer internen Maschine fälschen kann.

Sehr gescheite Aussage.

Und der Provider unterbindet die Sache 2.1km weiter entfernt nicht.

Auch mit der 7390 geht es bei den Providern, die das Routing nicht unterbinden. Damit die Pakete aus deinem Netz deine Box nicht erreichen, müssen definitiv zwei Randbedingungen gleichzeitig erfüllt sein:
- Der Provider muss es blocken
- Deine Box muss es blocken
Ist nur eines von beiden nicht erfüllt, kommen die Pakete an. Das ist beliebig oft hier im Forum nachzulesen, besonders in den frühen Firmwarethreads zur 7390, denn um die Zeit wurde das eingeführt.

 

[fordprefect64]

Hallo,

ich habe derzeit das gleiche Problem mit der FB 7390 (84.04.91). In diesem Zusammenhang sind mir einige Spezifikationen zu diesem Thema aufgefallen die vielleicht für den einen oder anderen auch interessant sind.
Das Thema wird bei den Router-Herstellern als "NAT Hairpinning" bezeichnet.
RFC 5382 Kapitel 7.2 TCP
RFC 4787 Kapitel 6 UDP

Pakete aus dem Intranet, welche für die "Internet Adresse des Routers" bestimmt sind, sollten von diesem aufgelöst und wieder zurück ins Intranet zum entsprechenden Ziel gesendet werden.

Wie z.B. AVM das umgesetzt hat, kann man am Beispiel FB 7270 (geht) und FB 7390 (geht nicht) gut erkennen. Unterschiedliche Geräte haben eine unterschiedliche Firmware etc. Vielleicht wird diese Funktion des NAT-Hairpinnings irgendwann doch noch sauber umgesetzt. Es gibt Hersteller anderer Preis und Leistungsklasse (Cisco), die diese Dinge eben können.

Zum Thema Spoofing kann ich nicht viel sagen, aber wenn die Pakete aus dem "Intranet" den Router überhaupt nicht Richtung Provider verlassen, kann ich keine unmittelbare Gefahr erkennen...

 

[frank_m24]

Zum Thema Spoofing kann ich nicht viel sagen, aber wenn die Pakete aus dem "Intranet" den Router überhaupt nicht Richtung Provider verlassen, kann ich keine unmittelbare Gefahr erkennen...

Darum geht es ja nicht. Wenn Pakete von außen mit gefälschter Absenderadresse (= deiner eigenen öffentlichen Adresse) die Firewall erreichen, dann lässt sie die Pakete vielleicht ungeprüft durch. Bei vielen Firewalls, gerade auch bei den Softwarefirewalls unter Windows, landet die eigene öffentliche IP automatisch auf der Whitelist. Schickt dir ein böser Bube Pakete mit der Absenderadresse, ist er an den meisten Sicherheitseinrichtungen deines Rechners schon vorbei. Im Falle von Trojanern und Würmern kann es aus durchaus aus dem eigenen LAN ein Sicherheitsrisiko darstellen.

 

[netzlaboranten]

Stichwort ist IP-Spoofing, nicht DNS-Spoofing.

Da klappt das auch mit der Forensuche ein wenig besser. Anscheinend ist das bei der 7390 mit Firmware 84.04.89 eingeführt worden. Laut diesem Thread bin ich nicht allein mit meinem Problem und der AVM-Support arbeite an einer Lösung mit einer anderen Sicherheitstechnik. Welche das auch immer sei. Mit der aktuellen Laborfirmware könne man angeblich wieder mit seinen (Dyn)DNS-Namen zugreifen. Ich finde leider im Changelog keinen Anhaltspunkt dafür, dass das Verhalten adressiert worden ist. Man kann eigentlich nur hoffen, dass es eine einigermaßen sichere Implementierung gibt, die NAT Hairpinning (ist das, was wir wollen?) erlaubt. Die Sicherheitsbedenken scheinen ja berechtigt zu sein, aber der Komfortverlust ist schon erheblich.

- Der Provider muss es blocken
- Deine Box muss es blocken

Ich kann auf jeden Fall feststellen, dass Arcor-DSL anscheinend bei uns nicht blockt, wohingegen Unitymedia schon.

Das ist beliebig oft hier im Forum nachzulesen, besonders in den frühen Firmwarethreads zur 7390, denn um die Zeit wurde das eingeführt.

Tut mir leid, dass ich das nochmal hochgekocht habe, aber die Forensuche hat mich auch bis jetzt nicht zu den Firmwarethreads gebeamt.

Dafür hab' ich ja jetzt befriedigende Antworten
thx
guy

 

[rollo]

Allen hier aufgeführten Theorien zum Trotz:
Ich habe es eben mal mit der 7390, 84.04.89 probiert. Ich komme aus dem internen Netz über die DynDNS-Adresse mit ssh auf einen linuxserver, der ebenfalls im internen Netz läuft. Ebenso klappt ein Zugriff auf das Webinterface der Telefonanlage. Allerdings verwende ich nach aussen andere Ports.

jo

 

[netzlaboranten]

Allen hier aufgeführten Theorien zum Trotz:
Ich habe es eben mal mit der 7390, 84.04.89 probiert. Ich komme aus dem internen Netz über die DynDNS-Adresse mit ssh auf einen linuxserver, der ebenfalls im internen Netz läuft. Ebenso klappt ein Zugriff auf das Webinterface der Telefonanlage. Allerdings verwende ich nach aussen andere Ports.

- Der Provider muss es blocken
- Deine Box muss es blocken

Ich kann auf jeden Fall feststellen, dass Arcor-DSL anscheinend bei uns nicht blockt, wohingegen Unitymedia schon.

Bevor wir auf Unitymedia umgestiegen sind, also mit Arcor-DSL, ging es bei uns auch, weswegen ich mich ja so gewundert habe. Ich gehe davon aus, das frank_m24 recht hat und eben beide Voraussetzungen erfüllt sein müssen, damit es geblockt wird: Provider und Box müssen blocken; wenn einer nicht blockt nicht haben wir den Komfort und dafür fehlende Sicherheit. Es sieht so aus, als würde es bei dir gehen, weil es der Provider zuläßt...

 

[wichard]

Um abzuklären, wie z.B. rollos Box das handhabt, könnte man ja mal einen Mitschnitt des Datenstroms auf DSL-Ebene machen (http://fritz.box/html/capture.html) und verfolgen, ob die Pakete die Box überhaupt verlassen.


Gruß,
Wichard

 

[rollo]

Warum sollten die Pakete die Box verlassen? Ziel ist doch das WAN-IF der Box.
Das geht vom LAN zum LAN-IF der Box und wir dort zum WAN-IF geroutet. Von dort geht es zurück ins LAN. Das ist eine klassiche Hairpin Verbindung. Es funktioniert nur nicht mit Ports, die die Box selber verwendet, möglicherweise auch nicht, wenn WAN-Port und LAN-Port identisch sind, was bei mir nicht der Fall ist.

jo

 

[RalfFriedl]

Ich sehe es auch so, dass es keine Grund gibt, warum die Pakete überhaupt ins Internet sollen.

Grundsätzlich funktioniert die Weiterleitung nicht, wenn bei der Weiterleitung die ursprüngliche Quell-Adresse erhalten bleibt, Was sinnvoll ist, wenn der Zielrechner die richtige Adresse sehen soll. Eine Weiterleitung von einem Internen Rechner kann funktionieren, wenn die Box immer ihre eigne Adresse als Absender-Adresse einsetzt und die Weiterleitung von intern grundsätzlich unterstützt, statt diese zum Beispiel nur mit eingehenden Paketen im dsl-Modul zu machen. Der Nachteil bei dieser Methode ist, dass der Zielrechner immer nur die Adresse der Box sieht und nicht die des externen Kommunikationspartners.

 

[frank_m24]

Doch, es gibt einen Grund, warum die Pakete im Normalfall übers Internet müssen, denn sonst stimmt die Source IP-Adresse im Antwortpaket für den Client nicht: http://wiki.mikrotik.com/wiki/Hairpin_NAT (Siehe Fall 2 der drei erläuterten Fälle). Die Client würde die Antworten verwerfen, weil sie von der falschen Quell-Adresse stammen.

Wir können ausschließen, dass die Box die in Fall 3 beschriebene spezielle Hairpin-Umsetzung der Adressen macht. Auf einem Server kommen Anfragen von der externen IP der Box an, nicht von der internen, und werden auch dahin zurückgeschickt. Ich hab mir das gerade im Wireshark angesehen für eine SSH Verbindung. Szenario:
Client PC mit Putty (192.168.177.1)
Fritzbox mit SSH Server (192.168.177.1 und öffentlicher IP 93.204.???.???)
=> Client baut SSH Verbindung zum Server im eigenen LAN auf, aber über die öffentliche IP mit Portweiterleitung.

Folgender Verbindungsaufbau kommt dabei heraus: (Bitte nicht über die Portnummern wundern, der SSH Server läuft aus Sicherheitsgründen nicht auf einem Well Known Port für SSH oder SSL.)

Man sieht deutlich, dass sowohl Client als auch Server ihre Pakete jeweils an die öffentliche IP richten. Da der Paketmitschnitt auf der PVC1 angefertigt wurde, haben die Pakete auch definitiv die DSL Schnittstelle der Box passiert.

 

[RalfFriedl]

Kannst Du mal eine größere Datei übertragen und die Übertragungsgeschwindigkeit messen?

 

[rollo]

Bei mir kommt die oben beschriebene Anfrage aus dem LAN auf dem SSH-Server mit der externen IP an:

jo@xxxx2:~> who
jo       pts/0        Jun 16 14:44 (p4fe8xxxx.dip.t-dialin.net)

Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0    132 192.168.178.133:22      79.232.yyy.xx:50884     VERBUNDEN

Letzlich wird aber die Box nicht wirklich verlassen. Das ist so, als wenn ich durch die Wohnung zur Haustür gehe, sie kurz öffne und dann wieder reinkomme, allerdings so behandelt werde, als käme ich tatsächlich von draussen.

Die Verbindung dazu auf dem LAN-Client

 TCP    192.168.178.104:50884  79.232.yyy.xx:yyy23    HERGESTELLT

 

[RalfFriedl]

Ich gehe auch davon aus, dass die Pakete die Box nicht verlassen. Anderenfalls müssten die ausgehenden Pakete die eigene Adresse als Quelle und Ziel haben, und normalerweise werden solche Pakete erst gar nicht nach draußen gesendet.

 

[frank_m24]

Aber warum funktioniert es dann an einigen Anschlüssen nicht?

 

[rollo]

gleiche Ports extern und intern, oder Ports die Box selbst benutzt wie im Eingangspost.?

jo

 

[Outlaw]

Ich habe mich heute dazu durchgerungen, meine Leihbox mit der aktuellen Labor zu bestücken und der Aufruf von intern auf die DynDNS funzt wieder 1A.