[Problem] Hilfe mit TR-064 Remote Access für Fritz!Box 7490 über WAN Zugriff

[kfr86]

Moin,

vielleicht hat jemand schon mal den Fernzugriff über TR-064 nach der Beschreibung von AVM geschafft (Fernzugriff Remote Access Beschreibung PDF).

Ziel ist es darüber WOL zu machen um einen Server aus dem Schlaf zu wecken ohne sich auf der Fritzbox WebGUI anzumelden.

was ich bis jetzt habe sieht wie folgt aus (für PowerShell)

# Skript für Fritzbox WOL via MAC und Remote Access.

# Benutzer nach Fritzbox-Passwort fragen. –asSecureString versteckt die Eingabe, aber macht die folgenden beiden Befehle nötig,
# um das verschlüsselte Passwort wieder in Klartext zu verwandeln.
$passwort = Read-Host -Prompt "Bitte Fritzbox-Passwort eingeben" –asSecureString
$passwort = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($passwort)
$passwort = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($passwort)


# Erstmal einen WebClient erzeugen, der später mit der Box spricht
$w=New-Object System.Net.WebClient

# Das Encoding sollte immer UTF8 sein.
$w.Encoding=[System.Text.Encoding]::UTF8

# Der WebClient enthält die Antowrt-Header aus der vorigen Abfrage. Daher diese neu setzen:
$w.Headers.Set("Content-Type", 'text/xml; charset="utf-8"')

# Der Funktionsaufruf kommt in den Header SOAPACTION Name der Funktion laut  http://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/hostsSCPD.pdf
$w.Headers.Set("SOAPACTION", 'urn:dslforum-org:service:Hosts:1#X_AVM-DE_WakeOnLANByMACAddress')

# Der SOAP-Aufruf wird in XML verpackt, und zwar...
# ... beginnt er mit einem immer gleichen Header.

$query='<?xml version="1.0"?>
        <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
        s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
        <s:Body> ' +
        # Dann kommt nochmal der Aufruf, diesmal steht der Funktionsname vorne
        # Der mitgegebene Parameter steht innerhalb des Funktions-Tags
        # Hier wird mit NewMACAddress die MAC Adresse des Servers eingetragen
        '<u:X_AVM-DE_WakeOnLANByMACAddress xmlns:u="urn:dslforum-org:service:Hosts:1">
                <NewMACAddress>00:00:00:00:00:00</NewMACAddress>
                </u:X_AVM-DE_WakeOnLANByMACAddress>' +
        # Und das Ende ist auch immer gleich
        '</s:Body>
        </s:Envelope>'

# Der WebClient braucht nur die Zugangsdaten, dann wickelt er das Login ganz allein ab.
# dslf-config ist der im TR-64-Standard definierte Name.
$w.Credentials=New-Object System.Net.NetworkCredential("Benutzername",$passwort)

# Das SSL-Zertifikat der Box ist nicht so signiert, dass es der sehr genauen Prüfung im WebClient standhält.
# Daher würde keine Verbindung zu Stande kommen, wenn man nicht die  
# SSL-Zertifikatprüfung für diesen Prozess ausschaltet.
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}

$r = [xml]$w.UploadString("https://dyndns:"443"/tr064/upnp/control/hosts",$query)

Leider rauscht das bei mir in einen TimeOut. Ausgabe ist dann:

Ausnahme beim Aufrufen von "UploadString" mit 2 Argument(en): "Timeout für Vorgang überschritten"

Hat jemand schon mal ein Remote Access mit TR-064 hinbekommen ganz egal ob für WOL oder irgend welche GetInfo Sachen? Ich bin für jeden Tipp dankbar

Gruß KFR86

 

[PeterPawn]

$r = [xml]$w.UploadString("https://dyndns:"443"/tr-064/upnp/control/hosts",$query)

Ohne mir den Rest angesehen zu haben ... woher kommt hier der Bindestrich? Der steht so nicht in der AVM-Beschreibung und auch in der "tr064cgi" gibt es den Bindestrich nicht:

# strings tr064cgi | grep tr.*64
tr064cgi.c
/tr064

 

[kfr86]

Ja stimmt war mein Fehler beim anonymisieren der URL Strings, Danke ich hab es angepasst, daran liegt der Fehler (Timeout) also nicht.

 

[PeterPawn]

1. Es darf gerne auch etwas ausführlicher sein, wenn Du den Fehler beschreibst bzw. erklärst, was Du sonst noch alles getan hast, um den Fehler einzugrenzen.

2. Was ist denn ansonsten noch dem "Anonymisieren" zum Opfer gefallen? Das wäre erst einmal gar nicht erforderlich, wenn Du einfach beim lokalen Test auf die Verwendung der DynDNS-Adresse verzichten würdest. Solltest Du von Beginn an nur "remote access" haben, wäre auch das eine Erwähnung wert gewesen, ansonsten kann man natürlich dieselbe URL auch von intern benutzen, sofern man den DynDNS-Namen durch "fritz.box" oder im Extremfall die IP-Adresse ersetzt.

3. Der Zugriff auf den Port 443 setzt zumindest mal voraus, daß man den Fernzugriff entsprechend eingerichtet hat. Da die automatische Einstellung für den externen HTTPS-Port häufig erst einmal ein zufällig gewählter Wert ist (die Angabe von FRITZ!Box-Modell und OS-Version habe ich auch nicht gefunden), braucht das also (wenn es sich nicht auch dabei um das Ergebnis der "Anonymisierung" handelt) noch zusätzliche Änderungen im GUI - solltest Du diese bereits vorgenommen haben, wäre auch das eine Erwähnung wert gewesen.

4. Bei mir liefert dieses Skript

Param([Parameter(Mandatory = $True, Position = 0, HelpMessage = 'the username to login to TR-064')][string]$Username,
      [Parameter(Mandatory = $True, Position = 1, HelpMessage = 'the password to login to TR-064')][string]$Password,
      [Parameter(Mandatory = $False, Position = 3, HelpMessage = 'the IP address of the FRITZ!Box, defaults to 192.168.178.1')][string]$Address = "192.168.178.1")

function GetSecurityPort()
{
    Param([Parameter(Mandatory = $False, Position = 0, HelpMessage = 'the IP address of the FRITZ!Box, defaults to 192.168.178.1')][string]$Address = "192.168.178.1")

    $WebClient = New-Object System.Net.WebClient
    $WebClient.Encoding = [System.Text.Encoding]::UTF8
    $WebClient.Headers.Set("Content-Type", 'text/xml; charset="utf-8"')
    $WebClient.Headers.Set("SOAPACTION", 'urn:dslforum-org:service:DeviceInfo:1#GetSecurityPort')
    $port_query='<?xml version="1.0"?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:GetSecurityPort xmlns:u="urn:dslforum-org:service:DeviceInfo:1"></u:GetSecurityPort></s:Body></s:Envelope>'
    $response = [xml]$WebClient.UploadString("http://" + $Address + ":49000/upnp/control/deviceinfo",$port_query)
    $sslport = $response.Envelope.Body.GetSecurityPortResponse.NewSecurityPort
    return $sslport       
}

$WebClient = New-Object System.Net.WebClient
$SSLPort = GetSecurityPort $Address
$GUISSLPort = 443
$getinfo_query='<?xml version="1.0"?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><s:Body><u:GetInfo xmlns:u="urn:dslforum-org:service:ManagementServer:1"></u:GetInfo></s:Body></s:Envelope>'

$WebClient.Encoding = [System.Text.Encoding]::UTF8
$WebClient.Headers.Set("Content-Type", 'text/xml; charset="utf-8"')
$WebClient.Credentials = New-Object System.Net.NetworkCredential($Username, $Password)
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
$WebClient.Headers.Set("Content-Type", 'text/xml; charset="utf-8"')
$WebClient.Headers.Set("SOAPACTION", 'urn:dslforum-org:service:ManagementServer:1#GetInfo')
$response = [xml]$WebClient.UploadString("https://" + $Address + ":" + $SSLPort + "/upnp/control/mgmsrv", $getinfo_query)

$WebClient.Encoding = [System.Text.Encoding]::UTF8
$WebClient.Headers.Set("Content-Type", 'text/xml; charset="utf-8"')
$WebClient.Credentials = New-Object System.Net.NetworkCredential($Username, $Password)
[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
$WebClient.Headers.Set("Content-Type", 'text/xml; charset="utf-8"')
$WebClient.Headers.Set("SOAPACTION", 'urn:dslforum-org:service:ManagementServer:1#GetInfo')
$response = [xml]$WebClient.UploadString("https://" + $Address + ":" + $GUISSLPort + "/tr064/upnp/control/mgmsrv", $getinfo_query)

für beide Requests eine Antwort - der erste erfolgt halt aus dem LAN über TR-064 und den nur dort erreichbaren SSL-Port (i.d.R. 49443) und beim zweiten kommt dann der CGI-Wrapper zum Einsatz, der aus der URL mit "/tr064" dann den passenden internen Request generiert.

 

[kfr86]

Danke für die Antwort gern ein paar mehr Infos:
- FritzBox 7490 06.69-41670 BETA
- FritzBox ist für externen Zugriff eingerichtet
- Port für Zugriff aus Internet 443
- der Benutzer hat das recht auf Zugriff über Internet

Was funktioniert bis jetzt:
- über X_AVM-DE_WakeOnLANByMACAddress WOL aus dem Netzwerk
- das gleiche funktioniert auch über VPN
die Änderung gegenüber oben sieht wie folgt aus:

$r = [xml]$w.UploadString("https://192.168.178.1:49443/upnp/control/hosts",$query)

Da funktioniert alles.

Für den WAN/Internet Zugriff müsste doch laut PDF der Port auf den Verwaltungsport fürs Internet geändert werden (bei mir 443) und für den Service Pfad von upnp/control/hosts nach /tr064/upnp/control/hosts geändert werden.

Fehlermeldung bei Port 443 über WAN nach ca. 1min.:

Ausnahme beim Aufrufen von "UploadString" mit 2 Argument(en): "Timeout für Vorga
ng überschritten"
Bei C:\Users\XXXXX\Downloads\1506-132\WAN.ps1:48 Zeichen:26
+ $r = [xml]$w.UploadString <<<< ("https://dyndns.XXXXXXX.de:443/tr064/upnp/control/h
osts",$query)
+ CategoryInfo : NotSpecified: ) [], MethodInvocationException
+ FullyQualifiedErrorId : DotNetMethodException

Was ich noch vergessen habe es ist egal ob über dyndns-dienst, MyFritz oder öffentliche IP Adresse genutzt wird. Und die Verbindung zur Box kann hergestellt werden denn wenn ich /tr064 in der URL weg lasse

$r = [xml]$w.UploadString("https://dyndns.k1f.de:443/upnp/control/hosts",$query) 

statt:

 $r = [xml]$w.UploadString("https://dyndns.k1f.de:443/tr064/upnp/control/hosts",$query)

kommt die Fehlermeldung:

"Der Remoteserver hat einen Fehler zurückgegeben: (404) Nicht gefunden."

 

[PeterPawn]

Da hat dann AVM wohl einen Fehler in die 113.06.69-41670 eingebaut ... da erhalte ich auch nur einen Timeout beim Aufruf. Das Skript in #4 hatte ich gegen 141.06.62 getestet.

Was jetzt die Ursache dieses Verhaltens bei der Labor-Version ist und seit wann die ggf. so reagiert, weiß ich auch nicht ... installiere Dir doch einfach eine 06.60 in der anderen Partition und probiere es mit dieser. Ich weiß nicht, was AVM da gerade ändern will ... aber ganz zumachen werden sie den externen Zugriff auf TR-064 vermutlich nicht (ich schwanke immer, ob ich das nun gut finden würde oder nicht), denn der wird (oder wurde zumindest bisher) auch für einige FRITZ!Apps benötigt.

Allerdings wäre es auch denkbar, daß nach der Einführung der neuen Schnittstelle (https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_appsetup.pdf) für die Authentifizierung von "Apps" die bisherige Exposition der TR-064-Funktionen über das CGI-Interface sterben soll (reine Spekulation meinerseits) ... solange das noch "Labor" ist, wird es da vermutlich wenig Gehaltvolles von AVM dazu geben (jedenfalls fände ich das recht überraschend, auch "X_AVM_DE_AppSetup" wurde erst nach der Veröffentlichung der Release-Version dokumentiert).

 

[kfr86]

Na das nenne ich mal eine schnelle Antwort. Danke für die Infos!
Bzgl. Installation auf die andere Partition, gibt's da irgendwo Infos wie ich das mache? Bis jetzt habe ich einfach nur die Firmware von AVM geflasht hab also nicht so viel Ahnung was da noch alles möglich ist.

 

[PeterPawn]

Beim Fernsehkoch würde man jetzt sagen: Ich habe da schon mal etwas vorbereitet ...

http://www.ip-phone-forum.de/showthread.php?t=273304 - das wäre eine Möglichkeit (wo man dann auch das Umschalten zwischen den Systemen per GUI einbauen lassen kann).

Ansonsten kann man auch einfach die aktive Partition umschalten und die Version 06.60 über das Laden in den Speicher installieren lassen (auch da gäbe es fertige Skript-Dateien - auch wenn das nicht als "all-in-one"-Lösung bereitsteht) - dabei wird dann die aktive Partition beschrieben.

Dritter Weg ist das Anpassen eines Images (die /sbin/flash_update wäre zu modifizieren), damit die Installation in die inaktive Partition erfolgt (lohnt nur dann, wenn man das neue Image mehr als einmal installieren will oder wird).

Bestimmt gibt es noch einige weitere Möglichkeiten - es hängt auch immer von den eigenen "skills" (und dem vorhandenen "Gerätepark") ab, was am schnellsten geht.

- - - Aktualisiert - - -

Ich hatte ohnehin gerade mal kurz die 113.06.60 in einer 7490 aktiv ... es ist wirklich so, daß der Zugriff in dieser Version wie erwartet und dokumentiert funktioniert.

Nachdem das eigentlich eine "offizielle Schnittstelle" von AVM ist (selbst wenn sie intern vielleicht auf "AppSetup" umstellen wollen), ist das wohl ein Fehler bei dieser Version - nachdem ich halbwegs sicher weiß, daß es eine Änderung beim Aufruf von CGIs gab (da sollte ein mir bekanntes Problem beseitigt sein), könnte das auch die Folge dieser Änderung sein (wieder Spekulation, aber irgendetwas muß ja die Ursache sein). Dann sollte es allerdings in der Vorgängerversion (müßte 41556 sein) noch funktionieren.

 

[kfr86]

Danke für die Links ich beschäftige mich damit die Woche mal.

Was ich definitiv sagen kann, dass es mit der Version 41137 nicht funktioniert hat! Die war nämlich bevor ich Updates gemacht habe darauf. Ich dachte mit der 41670 ist das Problem vielleicht wieder behoben.

 

[KunterBunter]

Den letzten Absatz hättest du eigentlich als den ersten des Threads nehmen müssen.

 

[kfr86]

Naja im Rückblick vielleicht schon. Ich dachte ich bin zu dumm für die richtige Anfrage über WAN und irgend jemand hat das schon mal erfolgreich geschafft. Bin da nicht von ausgegangen, dass AVM da irgendwas verändert/deaktiviert hat. Das hat sich ja erst jetzt heraus kristallisiert.

Dennoch vielen vielen Dank für die super Unterstützung hier...

 

[fipsy]

Zitat AVM: TR-064
TR-064 ist ein vom DSL-Forum entwickeltes Protokoll, um DSL-Internetzugangsgeräte aus dem lokalen Netz zu
konfigurieren. Es basiert auf dem UPnP-Standard (Universal Plug and Play), der allgemein zur herstellerübergreifenden
Ansteuerung von Geräten in IP-basierten Netzwerken dient. Die bei UPnP und somit auch bei TR-064
zum Einsatz kommenden Multicast-Adressen stammen aus einem Adressbereich, der nicht geroutet wird. Ein
Zugriff auf die FRITZ!Box mit TR-064 ist daher nur aus dem eigenen lokalen Netzwerk möglich. (https://avm.de/fileadmin/user_uploa...chnical_Note_-_Konfiguration_ueber_TR-064.pdf)

Würde mich also sehr wundern, wenn man aus dem WAN auf TR-064 zugreifen könnte.

 

[PeterPawn]

Dann solltest Du Dich einfach weiter wundern oder versuchen, Dich Deinerseits schlau zu machen ... es ist zwar mit der Suchfunktion vom IPPF tatsächlich schwer, die Themen zu "TR-064" zu finden (da stört vermutlich der Bindestrich), aber über Google ist das keine Hürde und dann findet man auch die entsprechenden IPPF-Threads.

Wer sich mit dem Thema TR-064 bei AVM beschäftigen will, sollte eigentlich auch die Seite http://avm.de/service/schnittstellen/ kennen (darüber stolpert man ja i.d.R. als erstes und auch das von Dir verlinkte Papier ist dort ja aufgeführt) und wenn man dort dann das Dokument mit der Nummer 33 in der Liste ansieht, dann wird aus Wundern vielleicht Staunen und mit fortschreitendem Verständnis dann auch Wissen.

 

[fipsy]

Eine etwas weniger überhebliche Antwort hätte es auch getan.

Wenn du schon meinen anderen Beitrag gelesen hast, hättest du eigentlich sehen müssen, dass mir die genannte Seite durchaus bekannt ist. Sonst wäre es mir wohl kaum möglich gewesen, Telefonbucheinträge über TR-064 zu bearbeiten. Das Dokument 33 habe ich nie angesehen, weil ich bis so weit unten gar nicht gelesen habe, da die relevanten Dokumente weiter oben sind. Das Dokument ist ja auch neueren Datums.

Es widerspricht vom Inhalt aber auch dem auf der Seite zuerst verlinkten Dokument "AVM Technical Note - Konfiguration über TR-064.pdf". Dort steht, dass ein Zugriff auf TR-064 nur aus dem LAN möglich ist (was aus Sicherheitsgründen auch höchst empfehlenswert wäre) und in Dokument 33 wird beschrieben, wie man von außerhalb des LAN auf TR-064 zugreift. Das ist völlig widersinnig und zudem auch ein dickes Einfallstor / potenzielles Sicherheitsloch.

 

[PeterPawn]

Als wie überheblich Du diese Antwort empfindest, tangiert mich aber nicht wirklich ... lies einfach, was da wirklich steht und wenn Du Dich über Überheblichkeit aufregen möchtest, dann kannst Du ja noch einmal die Formulierungen "Würde mich also sehr wundern ..." oder gerne auch "Das Dokument 33 habe ich nie angesehen, weil ich bis so weit unten gar nicht gelesen habe, da die relevanten Dokumente weiter oben sind. Das Dokument ist ja auch neueren Datums." hinterfragen.

Bei letzterem fehlt ja nur noch ein "hatte ich nicht nötig" in einem eingeschobenen Nebensatz (wobei das ja offenbar der Fall gewesen wäre (das "Nötigsein") und für die hier zu klärende Frage des Fernzugriffs auf TR-064 war das fragliche Dokument ja dann offenbar doch auch relevant) und wenn Du Dir die Revisionshistorie in der Datei einmal genauer angesehen hättest, solltest Du eigentlich auch auf die Idee mit dem "ist neueren Datums" (was ja wohl in diesem Kontext in die Richtung "gibt es noch gar nicht so lange" gehen sollte) nicht wirklich gekommen sein.

Ich weiß nicht, wie Du das ansonsten handhabst ... aber wenn/bevor ich jemand anderem so vehement widerspreche, lese ich zumindest erst einmal, was in diesem Thread geschrieben steht und der Link auf dieses für Dich so irrelevante Dokument steht bereits im ersten Satz im ersten Beitrag dieses Threads. Da bin ich auf die Erklärung, was Dich zu dem Beitrag #12 veranlaßt hat, echt gespannt. Wenn ich das aber (nachweislich!) nicht gründlich lese und deshalb Unsinn schreibe, müßte ich auch mit entsprechender (verbaler) Prügel leben können - ich hätte es mir ja selbst zuzuschreiben.

Auch hättest Du Deiner Verwunderung ob des hier vollkommen fehlenden Themas "TR-064" in dem anderen Thread ja dadurch entgegenwirken können, daß Du Deinerseits tatsächlich - ehrliche - Anstrengungen unternimmst, die Threads zum Thema zu finden. Selbst ohne die Beschränkung der Ergebnisse auf diese Site findet sich bei einer normalen Google-Suche innerhalb der ersten zwei Seiten (also innerhalb der ersten 20 Ergebnisse, falls jemand mehr oder weniger als 10 Treffer pro Seite anzeigen läßt) auch dieses Forum ... da wirkt dann auch Deine Einleitung im anderen Thread nicht mehr so überzeugend. Gerade jemandem, der auch programmieren kann, würde ich eben etwas mehr "Medienkompetenz" auch in der Richtung unterstellen, daß ein Schlagwort "TR-064" nach dem "Normalisieren" recht ungeeignet dafür ist, entsprechende Beiträge zu finden und wenn man da mit "TR064" (also ohne das enthaltene Sonderzeichen) ans Werk geht, findet sogar die foreninterne Suche entsprechende Treffer.

Das Eröffnen eines neuen Threads für Dein Programm ist Dir absolut unbenommen ... es in ein "Hab' nichts anderes gefunden" zu packen (gespielt oder nicht), ist sicherlich gar nicht notwendig. Auch hättest Du sicherlich wesentlich freundlichere Reaktionen von mir erhalten, wenn Du Deinerseits um Hilfe gebeten hättest (ob die dann möglich gewesen wäre, steht wieder auf einem anderen Blatt) und nicht so aufgetreten wärst, wie in diesem Thread ... und noch einmal: Hättest Du Dir nur diesen einen Thread gründlich angesehen, bevor Du #12 geschrieben hast, wäre sicherlich der ganze Beitrag nicht entstanden.

Das "Nichtlesen" (oder meinetwegen auch das "Nichtgründlichlesen") reiht sich aber nahtlos an das "Nichtgründlichsuchen" aus dem anderen Thread an (insofern ist das hier für mich auch kein isolierter Ausrutscher mit dem ersten Satz von #1, wie er jedem mal passieren kann) und wer sich dadurch hervortut, hat in meinen Augen auch entsprechende Reaktionen verdient - zumal das m.E. nicht unhöflich war, was ich dort schrieb.

Es war mehr der (vielleicht zu sehr verbrämte) Hinweis, daß man eben zuerst lesen und recherchieren sollte, bevor man "wilde Thesen" äußert oder versucht, den Opponenten zu widerlegen - so zumindest meine Erfahrung. Ansonsten kann es eben schnell "peinlich" werden, wenn man auf die Schwächen der eigenen Argumentation hingewiesen wird und da liest man dann auch mal Überheblichkeit an einer Stelle, die eigentlich eher sarkastisch gemeint war.

Wenn Dich Sarkasmus bereits dermaßen verletzt, kannst Du dem ja auch problemlos aus dem Weg gehen, indem Du einfach nur noch Thesen aufstellst, die Du dann erfolgreich beweist. Das hast Du zwar in #12 auch versucht (das Zitat von AVM ist schon mehr, als die meisten schreiben würden), aber in der Gesamtansicht auch nur für diesen Thread (die Schnittstellenseite nicht bis zum Ende gelesen und hier auch nicht ab #1) ist das dann eben doch in die Hose gegangen.

EDIT: Oben vergessen: Diese "normale" Suche bei Google verwendete dann die Stichworte "TR-064 fritzbox" - nur falls es jemand kontrollieren möchte.

- - - Aktualisiert - - -

Den von Dir entdeckten Widerspruch zu dem anderen Dokument von AVM kann ich auch nur in begrenztem Umfang nachvollziehen. Der Zugriff über TR-064 (so, wie es in der Spezifikaktion des Breitband-Forums definiert ist) funktioniert tatsächlich nur aus dem LAN heraus ... der Port 49000 ist aus dem WAN nicht erreichbar.

Der von AVM hier eingesetzte Wrapper, der aus einem HTTPS-Request mittels eines CGI-Programms (tr064cgi) praktisch einen TR-064-Request im internen LAN macht (wobei das wohl intern weitergereicht wird, es ist jedenfalls keine Netzwerkaktivität weiter zu sehen), ist sicherlich etwas gewöhnungsbedürftig ... solange der aber ordnungsgemäß über eine TLS-gesicherte Verbindung und mit der unbedingten Notwendigkeit der Verwendung eines gültigen Benutzerkontos arbeitet (was er zumindest machen soll nach dem Willen von AVM), ist das nichts anderes und nichts Gefährlicheres als jeder andere CGI-Aufruf.

Sofern man als Hersteller irgendwelche Apps verwenden/anbieten will, die von extern auf die Box zugreifen, hat man ja nur noch die Wahl zwischen irgendeinem zusätzlichen API (meinetwegen als Web-/Microservice o.ä.) oder irgendeiner anderen standardisierten Schnittstelle.

Ich war früher auch gegen diese "Veröffentlichung" von TR-064, habe aber inzwischen weite Teile des API auf Authentifizierungsprobleme abgeklopft und finde es seitdem gar nicht mehr so widersinnig, wenn man für die interne und externe Konfiguration (dazu gehören auch Telefonbücher und Anruflisten, die Du ja offenbar bereits ausliest) dieselben Schnittstellen verwendet, solange man die Authentifizierung ausreichend prüft.

Das ist u.U. sogar besser und sicherer, als wenn man zwei getrennte Implementierungen verwaltet, von denen jede ihre eigenen Fehler haben kann. Hier braucht es nur den (hoffentlich sehr gründlich getesteten) Wrapper, der solche HTTPS-Requests "demaskiert" und an der richtigen Stelle in den "TR-064-Server" kippt. Wenn dieser Wrapper dann parallel noch sicherstellt, daß wirklich sicherheitskritische Funktionen nicht über das CGI-Programm aufgerufen werden können, dann sehe ich da keine größere Gefahr in dieser Art und Weise des Zugriffs, als sie bei einem getrennten API auch bestünde.

Max. noch die hier nicht mögliche getrennte Abschaltung von TR-064 "nach außen", wäre ein Kritikpunkt meinerseits - aber auch der wird dadurch zumindest entschärft, daß es ein Admin-Konto für derartige Zugriffe braucht (ich hoffe mal, daß es auch eines mit "aus dem Internet"-Berechtigung sein muß, das wäre glatt noch einmal einen zweiten Blick wert) und ein Angreifer mit dessen Kenntnis dann auch das GUI "mißbrauchen" könnte; da bringt das TR-064 jetzt keine wirklich neue Angriffsfläche (wenn es wie spezifiziert arbeitet, weil es natürlich auch Lücken gab). Welche Berechtigungen für welche Funktionen erforderlich sind, steht - nebenbei bemerkt - auch in irgendeinem der anderen Dokumente von AVM zum Thema TR-064 - das mit dem "Admin-Konto" gilt nur für die Funktionen, die auch an den FRITZ!Box-Einstellungen etwas ändern (sollen).