Portfreigabe via UPnP (Fritzbox)

Tockra

Lt. Commander
Registriert
Dez. 2008
Beiträge
1.058
Guten Morgen,

ich habe mich kürzlich etwas mit UPnP beschäftigt und weiß nun was das ist. (zumindest grob).

Nun weiß ich schon seit längeren, dass man über UPnP temporär Ports im Router freischalten kann, womit man beispielsweise Peer 2 Peer Anwendungen programmieren kann.

Nun frage ich mich wie genau das via UPnP funktioniert?
Muss ich meine Anwendung als Control Point programmieren und der Router ist ein UPnP Device, welcher einen Portforwarding Service bereitstellt?

Also lasse ich meine Anwendung erstmal im Netzwerk nach einen Portforwarding Service suchen, und schicke diesem dann Instruktionen für die Portfreigabe (über SOAP) !?

Viele Grüße
T
 
Ich wäre sehr vorsichtig damit, UPnP im Router zu aktivieren. Sofern der Router nicht in irgendeiner Form über ACLs oder dergleichen verfügt, ist UPnP ein gewaltiges Sicherheitsrisiko. UPnP kann nämlich nicht zwischen guten und bösen Portweiterleitungen unterscheiden. Das heißt, ein PC, der via UPnP einen Port weiterleiten möchte, kann dies zB aufgrund eines Multiplayer-Games tun oder durch einen Trojaner. Der Router sieht nur "IP xyz will Port 1234 haben, zack, erledigt!"

Auch wenn du eine eigene Anwendung schreibst, die vollkommen unkritisch ist, ändert das nichts, weil wie gesagt auch Malware auf dem PC sein kann, die parallel dazu eben auch fleißig Ports beim Router anfragt.
 
ich habs aktiviert,das alte Skype am Ipad freut sich, auch Teredo vom XBOX gaming unter Windows 10
scheint sich ab und an einzutragen, je nachdem ob man IPV6 fährt oder nicht.
Man kann es auch wieder partiell deaktivieren oder speziellen Clients erlauben.
Ganz deaktivieren muss man es auch nicht, nur den Teil der Port Konfiguration.
ich sag immer locker bleiben und hab den Eindruck wenn es aktiv ist flutscht alles irgendwie besser.

Wenn Apple das mit Bonjour macht hat garantiert keiner was dagegen und bejubelt es auch noch.

Wenn Du eh schon Schadsoftware drauf hast hast Du ein anderes Problem
 
Klar "flutscht" es. UPnP ist ja auch dafür gedacht, dass man sich keinen Kopf mehr um Portweiterleitungen machen muss, weil Otto Normal davon schon überfordert ist. Es ist aber eine Tatsache, dass UPnP ein Sicherheitsrisiko ist. Man kann "locker bleiben" solange man sich keine Malware eingefangen hat, aber wenn doch, dann .. .. dumm gelaufen. Man kann auch "locker bleiben" und seinen Virenscanner deinstallieren solange man keinen Virus drauf hat, aber wenn doch...

ACLs können das Risiko eindämmen, aber mehr auch nicht. Solange zB ein PC eine Freigabe erhält, kann er dies eben für harmlose aber auch gefährliche Software (=Malware) tun.

Sicherheit basiert immer auf Eventualitäten. Wenn dein Haus nicht abbrennt, brauchst du keine Versicherung. Wenn keiner bei dir einbricht, brauchst du die Haustür nicht abschließen. Jeder muss für sich selbst entscheiden welche potentiellen Risiken er einkalkuliert, aber bei UPnP sind sich die meisten Leute dessen gar nicht so bewusst, bei der Haustür ist es hingegen jedem klar.
 
  • Gefällt mir
Reaktionen: h00bi und Madman1209
Tockra schrieb:
Nun frage ich mich wie genau das via UPnP funktioniert?
Muss ich meine Anwendung als Control Point programmieren und der Router ist ein UPnP Device, welcher einen Portforwarding Service bereitstellt?

  1. Eine Anwendung muß UPnP unterstützen und eine Anforderung an den Router senden
  2. Der Router muß UPnP aktiviert haben

Wie die anderen schon angemerkt haben, ist UPnP zwar bequem, aber wegen des Automatismus eben auch ein Sicherheitsrisiko. Nicht mehr du bestimmst damit, welche Anwendung was nach daußen funken darf, sondern die Anwendung.

In meinen Augen wiegt der Nachteil des Sicherheits- und Kontrollverlustes schwerer als der Vorteil der Bequemlichkeit. Eine Portfreigabe einzurichten, ist nun wahrlich keine Raketenwissenschaft und besonders mit einer FRITZ!Box gut dokumentiert und eingängig bedienbar.
 
Ich weiss ja nicht wie es mit der alten Sykpe Anwendung noch aussieht, die neue W10 App braucht das zumindest wohl nicht. Viele scheinen aber weiterhin auf die alte am PC zu schwören und ein Artikel im Web liess fast darauf schliessen dass man besser die UPNP Variante nimmt.
Mit Sicherheitsargumenten kann man alles totschlagen.
dafür bietet die Fritze ja entsprechende UPNP Management Möglichkeiten um das ansatzweise im Griff zu halten.
Viel passiert bei mir auf UPNP nicht, wie gesagt das Ipad2 und Skype, bzw. XBOX Gaming
NAT
IPV6 und Teredo sind ja auch problematische Themen, die aber ebenfalls von der Fritze adressiert werden können.
Bei beiden ist man je nach Konfiguration direkt erreichbar wenn man nicht aufpasst.
 
Natürlich kann man mit UPnP sicher online sein. Man muss dazu das vormalig sichere Netzwerk (LAN) in ein öffentliches umstellen, damit der Router als unsicheres Element von den Endgeräten betrachtet wird. Ein Router, der durch UPnP durchlöchert wird, ist nicht sicherer als ein reines Modem, ohne NAT und Firewill.
Wenn dann die ersten dicken Telefonrechnungen kommen, weil Hacker eigene VOIP-Nummer im Router eingerichtet haben, zahlt man dann Lehrgeld.
 
Wie gesagt, das ändert nicht wirklich etwas. Sobald der Router UPnP von deinem Rechner akzeptiert, wird er die Ports für deine Anwendung einrichten wie er es auch für einen Trojaner machen würde, der sich auf dem PC eingeschlichen hat. Der Router agiert bei UPnP ganz banal, Port-Anfrage rein, Portweiterleitung raus. Im Idealfall bietet der Router gewisse Sicherheitseinstellungen wie zB ACLs, um zumindest nur bestimmte Geräte für UPnP freizuschalten (zB nur Xbox1 + Xbox2).

Was genau hast du eigentlich vor? Evtl. lassen sich dynamische Ports ja gänzlich umgehen. Auch bei P2P Anwendungen kann man ja einen statischen Port definieren. Gerade dann, wenn deine Anwendung auch in anderen Netzwerken hinter anderen Routern funktionieren soll, kannst du dich nicht auf UPnP verlassen, weil der dortige Router eben nicht zwangsläufig auch UPnP unterstützt.
 
  • Gefällt mir
Reaktionen: Madman1209
Dann bist du hier aber gänzlich falsch. Du solltest dich stattdessen in einem Programmierforum umhören. Selbst wenn, du hast noch nicht mal erwähnt mit welcher Programmiersprache du arbeitest. Ansonsten empfehle ich dir nach den offensichtlichen Suchbegriffen "upnp port forwarding [ProgrammierspracheDeinerWahl]" zu googlen. Bei C# stößt man zB auf eine .Net DLL für diesen Zweck
 
Es geht mir ja auch nicht um die Umsetzung in einer speziellen Programmiersprache, sondern um den Ablauf.
Da UPnP ein Netzwerkprotokoll ist, dachte ich der Forenbereich hier könnte passen.

UPnP ist schließlich eine Middleware, die eigentlich relativ unabhängig von der verwendeten Programmiersprache ist.

Ich habe jetzt etwas mit einem UPnP discovery tool rumgespielt und bekomme das WAN-Device der Fritzbox angezeigt und sehe da auch die Actions und die Argumente, die ich den Actions übergebe, frage mich aber wo genau die korrekte Syntax einer Action definiert ist.
 
Dann schau dir mal diesen Link an. Da wird der Ablauf ganz gut erklärt. Vielleicht hilft dir das ja.

Ansonsten noch dies und das von hier.

Es ist sicherlich auch nicht verkehrt, nebenbei WireShark laufen zu lassen (oder tcpdump).
 
Zuletzt bearbeitet:
Okay, dann formuliere ich meine Frage einfach nochmal neu.

Wie implementiert man ein UPnP Control-Point. Unabhängig von den Service, den er verwenden soll.

Man implementiert einmal AutoIP, oder DHCP (das ist mir bewusst) um sich ins Netzwerk einzuwählen,
dann einmal eine Device Discovery per Simple Device Discovery Protocol um alle Devices bzw. Services die man benötigt im Netzwerk via UDP-TCP/IP-Broadcast zu finden.
Das ist mir auch bewusst.

Die Frage ist, was passiert dann!?
In einigen Quellen wird gesagt, man soll die Gerätedaten abfragen, welche auch die Servicedaten beinhalten.
Alles im XML Format. Dabei haben die Service-Infos das "Service Description Format" und die Device-Infos das "Device Description Format".

Andere Quellen fangen direkt mit Action-Aufrufe via SOAP zum Service an.

Welche Variante ist besser? Wie genau arbeitet man mit den Device- und Service-Descriptions um den Control-Point möglichst dynamisch und kontextabhängig zu programmieren?

Ich als Entwickler weiß ja sowieso, welche Actions ich verwenden möchte und deren Syntax sollte ich wohl kennen. Also sind das nicht die Informationen, die für mich relevant sind. Eventuell die Information, ob meine Gewünschte Action überhaupt vorhanden ist.

Aber ist das alles was ich mit den Descriptions anfangen kann?
 
Grundsätzlich startest du mit der UPnP Discovery ja bereits eine Suche nach einem expliziten Gerätetyp, zB "InternetGatewayDevice". Darauf melden sich dann eben auch nur Router bzw. eben Gateway-Devices und nicht zB ein UPnP-Medienserver. Lädst du nun die XML-Datei vom Gerät runter, findest du darin die Services, die das Gerät tatsächlich anbietet. Unterhalb dieser Services liegt dann eine controlURL, die du wiederum für den SOAP Aufruf nutzt.

Im Detail habe ich mich mit dem Protokoll selbst noch nicht beschäftigt, daher kann ich nicht beurteilen ob diese controlURL in irgendeiner Form standardisiert ist. Wenn ja, kann man durchaus auch implizit bereits den SOAP Aufruf starten, ohne erst die Service-Liste abzurufen. Natürlich besteht dann eine gewisse Gefahr, dass man einen Service nutzen will, der von eben diesem UPnP-GatewayDevice nicht unterstützt wird. Das heißt, dass du sobald du eine Action implizit auslöst, musst du immer im Hinterkopf behalten wie dein Programm reagieren soll, wenn der Service eben nicht unterstützt wird - error replies, timeouts, etc. Wenn du natürlich von vornherein erstmal die Services abfragst und erst dann den Request startest, wenn du den Service auch in der XML gefunden hast, sollten etwaige Fehlermeldungen sich im Rahmen halten bzw. sich dann explizit nur auf den Inhalt deines Request beziehen zB Port belegt oder was auch immer da als Reply kommen kann.

Wie gesagt, ich rate dir, mit WireShark bzw. tcpdump mal solch einen Request aufzuzeichnen, beispielsweise eben von einer Spielekonsole oder evtl. gibt's ja auch Tools, die explizit UPnP Requests generieren. So tief stecke ich da nicht drin. In meinem ersten Link ist der Vorgang aber recht ausführlich beschrieben, inkl. Beispielcode. Zwar ist der in Python, aber du hast ja erstmal sprachen-unabhängig gefragt und man sollte das Beispiel eigentlich auch mit überschaubarem Aufwand zB auf C# umsetzen können. Zum Mitschneiden brauchst du dann natürlich zB einen Mirror-Port am Switch oder ein TAP.
 
Zuletzt bearbeitet:
Raijin schrieb:
Tools, die explizit UPnP Requests generieren.
Es gibt in der Tat Tools, aber das eine Crasht immer (Windows App) und das andere gibt mir bei einem AddPortForward aufruf (oder wie die Action noch gleich heißt) immer nur einen ActionError zurück. Vermutlich weil ein paar Felder, die eigentlich leer sein sollten trotzdem Inhalte besitzen (weil die App nicht damit klar kommt Attribute leer zu lassen).
Ich habe leider kein Tool gefunden, dass mir die Device Description und/oder die Service Descriptions anfragen kann.
 
Die Frage ist nun: Willst du das alles zu Fuß machen oder eben vorhandene Bibliotheken verwenden möchtest. Es ist nämlich immer eine Sache ob man wirklich das Rad neu erfinden will, weil man in der Tiefe alles verstehen möchte, oder ob man sich fertiger Pakete bedient, die einem diese Ebene vom Hals halten. Letzteres ist in den meisten Fällen deutlich entspannter. Sofern man zumindest das Konzept der zugrundeliegenden Technologie verstanden hat, ist es keine Schande, sich bestehender Implementierungen zu bedienen.

Was UPnP-Tools angeht, könnest du dich mal bei Intel umschauen: Klick!

Ich habe eben mal in einem kurzen Test (zu Fuß) versucht, via UPnP meinen Test-Router zu finden, bei dem ich temporär UPnP aktiviert habe. Ich kann in WireShark auch sowohl den Notify-Event des Routers als auch die M-Search meines PCs sehen. Auch antwortet der Router mir, aber irgendwie habe ich im Quellcode beim Reply etwas verbockt, weil die Antwort nicht in meinem Tool ankommt obwohl man sie bei WireShark sehen kann. Gut. das passiert bei Quick'n'Dirty Code. Mit den verlinkten Intel-Tools (insbesonder Device Spy) kann man die Services sehen und darunter auch die entsprechenden Actions (zB AddPortMapping).
 
Zuletzt bearbeitet:
Zurück
Oben