IGD-Protokoll

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Das Internet Gateway Device (IGD) Control Protokoll ist ein standardisiertes Geräte-Steuerungsprotokoll, das auf Universal Plug and Play (UPnP) basiert und von einigen NAT-Routern unterstützt wird. Es ist ein übliches Verfahren, Port-Weiterleitungen automatisch zu konfigurieren.

Diagramm zur Darstellung des Austausches von Nachrichten zwischen den Steuerungs- und den Peripheriegeräten über UPnP.

Anwendungen, die Peer-to-Peer-Netze, Multiplayer-Spiele und Fernwartungsprogramme, zum Beispiel Remote-Desktop, oder Medienfreigaben über ein lokales Netzwerk verwenden, benötigen ein Verfahren, um über Heim- oder Geschäfts-Gateways zu kommunizieren. Ohne IGD-Protokoll muss das Gateway-Gerät manuell konfiguriert werden, um die Durchleitung des Datenverkehrs einer Anwendung aus dem Internet zu erlauben, was sehr fehleranfällig und zeitaufwändig ist. Mit Universal Plug and Play (UPnP) wurde eine Lösung speziell für NAT entwickelt, die heute unter vielen Betriebssystemen verfügbar gemacht werden kann.[1]

IGD kann dem Benutzer die folgenden Aufgaben erleichtern:

  • Ermittlung der öffentlichen (externen) IP-Adresse
  • Auflistung der vorhandenen Port-Weiterleitungen
  • Hinzufügen und Entfernen von Port-Weiterleitungen
  • Ablaufzeiten für Weiterleitungen zuordnen

UPnP IGDv2, veröffentlicht 2010, fügte IPv6-Unterstützung hinzu und ändert das Verhalten beim setzen einer unendlichen Lease-Time mit einem Wert von 0. Die Spezifikationen sind abwärtskompatibel, aber es gibt Kompatibilitätsprobleme, z. B. mit dem Microsoft-Client.

Kompatibilitätsprobleme

[Bearbeiten | Quelltext bearbeiten]

Aufgrund der unterschiedlichen Interpretationen der sehr umfangreichen eigentlich abwärtskompatiblen IGDv1- und IGDv2-Spezifikationen gibt es zahlreiche Kompatibilitätsprobleme. Eines davon ist der UPnP IGD-Client, in aktuellen Microsoft Windows- und Xbox-Systemen mit zertifizierten IGDv2-Routern. Das Kompatibilitätsproblem besteht noch immer seit der Einführung des IGDv1-Clients in Windows XP im Jahr 2001, und einem IGDv2-Router ohne einem Workaround das Router-Portweiterleitungen unmöglich macht.[2]

Wenn UPnP nur zur Steuerung von Router-Portweiterleitungen und Pinholes verwendet wird, gibt es alternative, neuere viel einfachere und leichtgewichtige Protokolle wie das PCP und das NAT-PMP, die beide von der IETF als RFCs standardisiert wurden. Bei diesen Alternativen sind bisher keine Kompatibilitätsprobleme zwischen verschiedenen Clients und Servern bekannt, aber die Verbreitung ist noch gering. Bei Routern für Endverbraucher ist derzeit nur von AVM und den Open-Source-Router-Softwareprojekten OpenWrt, OPNsense und pfSense bekannt, dass sie PCP als Alternative zu UPnP unterstützen. Die AVM Fritz!Box UPnP IGDv2 und PCP Implementierung ist seit ihrer Einführung sehr fehlerhaft. In vielen Fällen funktioniert sie nicht.[3][4][5][6][7] Die Open-Source-Router-Softwareprojekte verwenden den MiniUPnPd[8] Server, der alle drei Protokolle unterstützt.

Sicherheitsrisiken

[Bearbeiten | Quelltext bearbeiten]

Mit Hilfe von Skriptsprachen auf einer Webseite können aber auch neue Risiken und Gefahren durch das IGD-Protokoll herbeigeführt werden, falls die Veränderung der Konfiguration auf dem Gateway-Gerät zuvor erlaubt worden ist. Dadurch wäre es möglich, einen Computer oder auch ein ganzes Netzwerk unter die Kontrolle fremder Anwender zu bringen, was oft in krimineller Absicht erfolgt.[9] Viele DSL-Router, wie zum Beispiel die in Deutschland weit verbreiteten Fritz!Boxen, unterstützen dieses Verfahren, die Veränderung der Konfiguration muss jedoch meist vom Benutzer extra über die Weboberfläche freigegeben werden, sofern der Zugang zu dem Gerät mittels eines Passwortes vorher gesichert wurde.

Über SSDP kann der Host nach im Netzwerk vorhandenen Geräten suchen lassen, die dann mit Hilfe eines Netzwerkprotokolls wie SOAP gesteuert werden können. Die Suchte nach verfügbaren IGDv1/IGDv2-Geräten erfolgt mit nur einem M-SEARCH nach IGDv1. Eine Suchanfrage wird über HTTP und Port 1900 an die Multicast-Adresse 239.255.255.250 verschickt:

M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 2
ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1
  • Internet Gateway Device (IGD) V 1.0. (JavaScript) UPnP Forum, 12. November 2001, archiviert vom Original (nicht mehr online verfügbar) am 20. März 2012; (englisch).
  • Internet Gateway Device (IGD) V 2.0. (JavaScript) UPnP Forum, 9. Dezember 2010, archiviert vom Original (nicht mehr online verfügbar) am 20. März 2012; (englisch).
  • UPnP Forum Internet Gateway Device presentation. (ppt; 455 kB) UPnP Forum, archiviert vom Original (nicht mehr online verfügbar) am 7. Februar 2016; (englisch).
  • Beschreibung der UPnP-Features in Windows XP (Universelles Plug & Play). Microsoft, 1. Dezember 2007;.
  • Port Mapping Protocols Overview and Comparison 2024 — About UPnP IGD & PCP/NAT-PMP

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. Reiko Kaps: Netzwerk-Magie. heise online, 30. Januar 2009, abgerufen am 11. Juni 2013.
  2. MiniUPnPd's workaround: Detect FDSSDP as a microsoft client. In: github.com, 23. Juni 2023.
  3. 12 Fehler in der AVM UPnP IGD- und PCP-Implementation (aller FritzBoxen). In: pastbin.net, 2024.
  4. UPnP not working with my FRITX!Box. In: forum.syncthing.net, April 2022.
  5. UPNP_GetValidIGD returns Temporary IPv6 Address, causing UPNP_AddPinHole to fail with 606 #600. In: github.com, 21. Mai 2022.
  6. upnpc shows wrong duration for port forward longer than 120 seconds #222. In: github.com.
  7. Setting up portforward doesn't work. In: tuxfamily.org.
  8. MiniUPnP ist ein freier, leichtgewichtiger Open-Source-Client/Server und eine C-Bibliothek mit Unterstützung für UPnP IGD und zusätzlich PCP/PMP als Server. In: tuxfamily.org.
  9. Daniel Bachfeld: Ungewollte Fernkonfiguration für Heim-Router. heise online, 15. Januar 2008, abgerufen am 21. Juli 2012.