[Problem] Fritzbox LAN-to-LAN-VPN: Fern-Administration der anderen FB geht, aber nicht des daran angeschlossenen IP-Telephones

[PeterPawn]

Und schon wieder falsch ... "peinlich" finde ich gar nicht Deine Weigerung, diese "Meinung" irgendwie zu begründen; das erscheint mir nur unverständlich und nimmt dem Opponenten die Möglichkeit, dagegen zu argumentieren und zu zeigen, wo genau die Löcher in der Argumentation liegen.

Wer solche Behauptungen mit dem notwendigen Sachverstand aufstellt, wird das i.d.R. auch begründen können - daher legitimiert Deine Weigerung in meinen Augen auch die Annahme, daß Dir das dazu notwendige Wissen tatsächlich fehlt und es nur "nachgeplappert" war und damit dann auch nur Meinung aus dritter Hand.

Es steht Dir selbstverständlich frei, die Leser (und das steht hier ja noch eine Weile im IPPF) vom Gegenteil zu überzeugen ... oder eben einzugestehen, daß das eher ein "Schnellschuß" war und mit einer differenzierten und fachlich begründbaren Ansicht zu tatsächlichen Vor- und Nachteilen einer VPN-Verbindung wenig bis nichts zu tun hatte.

Nicht umsonst beginnt mein Beitrag #15 mit einer Frage (oder auch ein paar mehr) an Dich - auf keine einzige davon bist Du irgendwie eingegangen (oder ich bin nur zu dumm, das zu erkennen).

==================================================================

Denn was ich tatsächlich peinlich finde, ist eine "eigene Meinung", die nur in der Wiedergabe von irgendwelchen Parolen besteht, die man selbst anderenorts aufgeschnappt hat (und wo man diese Orte nicht mal benennen will) - und mit jeder weiteren Weigerung, die zum Ausdruck gebrachte (und in meinen Augen unter den passenden Umständen sogar vollkommen falsche) "höhere Sicherheit" einer VPN-Verbindung zu einer FRITZ!Box im Vergleich zum WAN-Zugriff auf das GUI zu begründen, verstärkt sich halt dieser Eindruck (vielleicht ja auch nur bei mir).

Somit halte ich mal ausdrücklich fest, daß sich das Folgende gar nicht explizit an Dich richtet, sondern all diejenigen, die u.U. ebenfalls der Ansicht sind, eine VPN-Verbindung wäre ein Allheilmittel und/oder immer "sicherer" als andere (ebenfalls verschlüsselte) Zugriffe oder etwas in dieser Richtung irgendwo lesen bzw. gelesen haben, dazu verleiten soll, sich eigene Gedanken zu den Vor- und Nachteilen zu machen (am besten sogar selbst dazu zu recherchieren) und nicht alles zu glauben, was man irgendwo liest.

Dazu gehört selbstverständlich auch das IPPF und mein Beitrag hier - wobei ich mich schon (nach Kräften) mühe, nicht nur irgendwelche Behauptungen aufzustellen, sondern diese auch zu begründen und mit anderen Quellen (wo das möglich ist) und passenden Erklärungen zu untermauern.

Ob Du das dann "schlicht ablehnst", ist mir letztlich auch herzlich egal ... schon Goethe wußte (in Gestalt des Wagner im Faust I), daß "allein der Vortrag des Redners Glück" macht und somit ergreife ich (mal wieder) die Gelegenheit, das etwas genauer zu beleuchten und so einfache Parolen wie oben zu hinterfragen.

==================================================================

Denn ich kann ja einfach mal einen Punkt "in den Ring" werfen, wo man sehr deutlich sehen kann, daß eine "herrschende Meinung" (wenn es sie so, wie in #18 kolportiert, überhaupt gibt/gäbe) ohne entsprechende Betrachtung der Rahmenbedingungen eben auch irren würde (daher stellt sich halt die Frage, wer hier diese "herrschende Meinung" definiert haben soll).

Wobei man mit "herrschender Meinung" generell vorsichtig sein sollte - "Schwarmintelligenz" verlagert die Verantwortung für das Geschriebene/Gesagte auch immer von einem selbst weg und eher auf den Nebenmann - und es soll angeblich auch Zeiten gegeben haben, wo die herrschende Meinung der Ansicht war, daß die Erde eine Scheibe wäre ... eine heutzutage nur noch von deutlichen Minderheiten vertretene Lehrmeinung.

Aber zurück zu meinem versprochenen Beispiel, wo eine VPN-Verbindung (zu einer FRITZ!Box) sogar das genaue Gegenteil von "sicherer" wäre ... was ist denn daran besser, daß eine "malicious app" (https://arstechnica.com/information...-with-1-7-million-downloads-many-by-children/ oder auch https://www.wired.com/story/apple-app-store-malware-click-fraud/ als Nachweis dafür, daß es solche Apps auch in die jeweiligen Stores schaffen und das nicht nur "theoretisch" ist) bei einer aktivierten VPN-Verbindung nicht nur die Daten auf dem betroffenen Mobilgerät komplett kompromittieren kann, sondern auch gleich noch Zugriff auf das über VPN verbundene LAN erhält?

In meinen Augen ist das eindeutig "schlechter" und nicht im Ansatz irgendwie "besser" - aber wie hier auch schon richtig angemerkt wurde, muß das halt jeder selbst entscheiden ... nur muß er für eine fundierte Entscheidung eben wissen, worauf er sich einläßt und was ihm ggf. "droht".

Denn wenigstens wird ja von AVM für eine solche VPN-Verbindung dann der "NetBIOS-Filter", der Angriffe über eine VPN-Verbindung von einem Mobilgerät auf die Windows-Clients im LAN über NetBIOS/TCP bzw. SMB ausfiltern könnte, automatisch aktiviert ("dont_filter_netbios = no;") ... ach nein, halt - das war ja gar nicht so. Der Filter wird in Wirklichkeit für diese Art von VPN-Verbindung (conntype_user) sogar explizit abgeschaltet - zumindest (immer noch) beim Einrichten einer VPN-Verbindung in der aktuellen Labor-Version für die 7490 (113.07.19-79325).

Damit steht nicht nur der Media-Server der FRITZ!Box weit offen (https://www.ip-phone-forum.de/threads/dein-freund-der-avm-mediaserver-und-wie-er-dir-in-den-rücken-fallen-könnte.288570/) und erlaubt (in der Standardeinstellung) das Auslesen jedes an der FRITZ!Box angeschlossenen USB-Volumes (ohne jede Authentifizierung und auch über diese VPN-Verbindung) - nein, man kann auch in aller Ruhe die anderen Clients im LAN auf potentielle Lücken abklopfen, ohne daß das irgendwo in der FRITZ!Box selbst eine Spur hinterlassen wird - mal abgesehen von der Nachricht über das Herstellen der VPN-Verbindung (bei wirklich ausführlicher Protokollierung), was ja aber zum "erwarteten Verhalten" gehört (sofern man diese VPN-Verbindung "gewohnheitsmäßig" nutzt) und daher - anders als das Einrichten neuer Portfreigaben oder neuer Verbindungen - auch "im Rauschen" untergeht bzw. gar nicht als Angriff erkannt werden kann.

An einiges (u.a. an den Inhalt des Media-Servers) kommt man zwar auch mit kompromittierten Credentials für den Zugriff auf das GUI heran (wenn der Account die passenden Rechte hat), aber alles das, was man dann unternehmen müßte, um sich den Weg weiter ins LAN zu bahnen, hinterläßt (mittlerweile) in der AVM-Firmware entsprechende Spuren, wenn es nicht sogar über die 2FA abgesichert ist (von Portfreigaben bis zum Anlegen neuer VPN-Verbindungen).

==================================================================

Und auch AVM benutzt bei den eigenen Apps eben nicht in jedem Falle eine VPN-Verbindung (und mich würde tatsächlich interessieren, wo bei AVM etwas davon zu finden wäre, daß eine VPN-Verbindung IMMER sicherer als ein Zugriff aufs GUI sein soll, der von der WAN-Seite auch nur mit TLS-Support zu erlangen ist) - die MyFRITZ!-App vom Hersteller funktioniert auch ohne jede VPN-Verbindung ganz hervorragend bei den Funktionen, die auch über TR-064 erreichbar sind und das ist z.B. eine der von mir weiter vorne erwähnten Apps, die sich automatisch den (auch externen) Zugriff auf das GUI per TR-064 freischalten (mit Genehmigung des Benutzers beim Einrichten im Heimnetz) und bei deren Benutzung man eben den externen HTTPS-Zugang nicht wieder selbst abschalten sollte/darf. Nur bei den Zugriffen, die tatsächlich eine VPN-Verbindung erfordern würden (in erster Linie "Heimnetz", wie der Name ja schon nahelegt), streicht sie ohne VPN-Verbindung dann die Segel.

Auf den Aspekt, daß eine "normale" VPN-Verbindung (conntype_user) i.d.R. auch ohne PFS arbeitet bei der FRITZ!Box und somit zuvor aufgezeichneter Traffic eben auch wieder entschlüsselt werden kann, wenn man später an den PSK für die VPN-Verbindung gelangt (z.B. wenn sich Strafverfolger nach richterlichem Beschluß Zugriff auf die FRITZ!Box verschaffen und den PSK für die VPN-Verbindung auslesen - ggf. auch "auslesen lassen"), habe ich weiter vorne schon hingewiesen. Beim GUI-Zugriff unterstützt das FRITZ!OS (spätestens die aktuelle Labor-Version, aber iirc auch schon frühere) dann auch TLS 1.3, wo sich die Frage nach PFS nicht mehr stellt, weil es dort "mandatory" ist und auch es bei der Spezifikation - trotz gegenteiliger Bemühungen einiger Interessengruppen - nicht aufgeweicht wurde. Und das Extrahieren so eines PSK ist ja auch nicht nur auf der Box möglich ... ein kompromittiertes mobiles Gerät wird den im Normalfall auch persistent gespeichert haben.

Auch muß es nicht immer die Strafverfolgung sein oder irgendein Geheimdienst ... auch die berufliche Konkurrenz freut sich sicherlich, wenn sie direkten Zugriff auf das heimatliche LAN eines leitenden Mitarbeiters einer Firma erlangt, weil der Filius (oder auch die Filia, ich will niemanden diskriminieren) sich auf dem Smartphone mit dem neuesten "hot shit" (ja, das ist auch schon wieder älter) auch gleich noch eine Wanze eingefangen hat (auch WLAN- und/oder Bluetooth-Lücken sind ja nichts wirklich Unbekanntes) und diese - dank VPN-Verbindung - auch aus der Ferne im LAN wildern kann.

Selbst wenn man auf dem Mobilgerät die eigenen Zugangsdaten zum administrativen Account in der FRITZ!Box gespeichert hat und damit bei einer Kompromittierung des Mobilgerätes bereits beträchtlicher Schaden angerichtet wird, ist in diesem Falle das LAN mit all seinen sonstigen Geräten (von Windows-PCs über STBs, von IoT-Devices bis zu Smart-TVs) immer noch relativ sicher und somit hält sich der Schaden in Grenzen.

Ist auf dem Mobilgerät eine VPN-Verbindung konfiguriert, für die auch noch die notwendigen Zugangsdaten gespeichert sind (und das ist nun mal der Normalfall, wie sich wohl jeder Benutzer einer VPN-Verbindung auf einem solchen Gerät eingestehen wird) und die somit von einer App aktiviert werden kann, ist der Schaden viel größer - eben weil auch die "Angriffsfläche" (die sich ja nicht nur an den Diensten bemißt, die auf einem Gerät laufen (wie es oben auch mal anklang), sondern auch an der Anzahl der Geräte und deren jeweiligem "Wartungszustand" der Soft-/Firmware) dann entsprechend größer wird und damit die Wahrscheinlichkeit eines erfolgreichen Angriffs auf weitere Geräte als nur dieses eine kompromittierte, mobile Gerät mit der "malicious app".

Außerdem ist der Zugang zum GUI (oder auch zum TR-064-Interface, das von der WAN-Seite über ein CGI erreichbar ist) mit einem Schutz gegen "brute force attacks" ausgestattet, der einen Angreifer durch erzwungene Pausen erheblich beim "schnellen Probieren" behindert. Das gibt es (bisher) beim VPN bei AVM auch nicht ... Connection-Requests beim VPN, mit denen die Box nichts anfangen kann (weil sie den PSK nicht findet anhand der "remote id" oder er nicht zum Entschlüsseln verwendet werden kann), werden einfach ignoriert. Von einem ähnlichen Schutz gegen Brute-Force-Angriffe, wie beim GUI, habe ich hier noch nichts bemerkt - sollte es ihn mittlerweile doch geben, hätte ich schlecht getestet.

Mal abgesehen davon, daß solch ein Schutz naturgemäß auch einem Angreifer immer wieder eine DoS-Möglichkeit eröffnet - aber einen Tod muß man sterben und wenn man unter "Sicherheit" wenigstens die Information, daß man angegriffen wird und ob das erfolgreich war, versteht, dann nimmt man lieber einen eigenen, fehlschlagenden Zugriffsversuch in Kauf, als einen erfolgreichen durch einen Angreifer.

==================================================================

Ein TLS-Zugriff auf das GUI ist also nicht per se "unsicherer" als einer über eine VPN-Verbindung und er ist in vielen Fällen (wenn er ausreichend ist) sogar vorzuziehen - es reicht schon aus, daß so mancher Provider bei der Fernkonfiguration von FRITZ!Boxen (bei einer Fehlermeldung durch den Kunden) einfach mal für sich selbst einen Account anlegt und den HTTPS-Zugang "freischaltet" (alles per TR-069) ... dabei wird dann gerne auch mal der bereits genutzte externe Port geändert (der wird ja "ausgewürfelt" bei der Einrichtung und es wird nicht der Port 443 verwendet, um DoS-Angriffe auf die Box zu erschweren) und die Kunden stehen danach mit ihren bereits eingerichteten Apps wieder auf dem Schlauch (und lasten das meist eher der App an), wenn der zuvor benutzte Port dann nicht wiederhergestellt wird.

So beobachtet beim Schweizer Anbieter "iWay AG", der das mehrmals für zwei FRITZ!Box 5490 (die auch tatsächlich Leihgeräte vom Provider sind, was aber nicht heißt, daß der Kunde die Apps nicht benutzen darf oder ständig neu einrichten muß) und auch für eine kundeneigene 7490 (an einem DSL-Anschluß, wo die letzte Meile über die Swisscom läuft) vorexerziert hat - auch wenn das jeweils netterweise im Event-Log von den Boxen protokolliert wurde.

 

[hl3]

Da auch das entfernte Netz aus Sicht der FRITZ!Box "Internet" ist, liegt hier auch das Problem. Entweder die Telefone sollen nur lokal zugreifen dürfen (auch ein Zugriff per PC auf ein Telefon braucht natürlich für die Antworten das "Recht", diese auch zu senden) ... dann paßt doch das gezeigte Verhalten exakt. Oder es soll ein entfernter Zugriff möglich sein (hier ist der PC ja auch nicht als Client im lokalen Netz, wie er es bei einer eigenen Verbindung per VPN-Client wäre), dann muß man den eben auch zulassen.

Nein, das Problem dürfte *nicht* hier liegen, sondern da, wo ich es schon in Nachricht #4 verdächtigte: In den Snom-Telephonen habe ich nun im Feld IP-Gateway die Default-Einstellung <blank> ersetzt durch die private Adresse der direkt angeschlossenen FB. Die FB-Filter für die Snom-Telephone blieben auf "Gesperrt" (denn gesperrt wird damit nur ihr Zugang zum *Internet*), und der Fern-Zugriff auf das Web Interface des Telephones über den PC gelingt nun trotzdem, da sich beide im selben VPN (wenn auch in unterschiedlichen, weit entfernten LANs) befinden.

Das VPN ist eben *kein* "Internet" (auch nicht "das entfernte Netz aus Sicht der FRITZ!Box"), sondern, wie der Name sagt, ein *privates* Netzwerk, das durch den Zusammenschluß von 2 oder mehr LANs zu einem größeren entsteht, die über einen "Tunnel" durch das (öffentliche) Internet miteinander verbunden werden. Solange die Daten sich im VPN (einschließlich des Tunnels zwischen den LANs) bewegen, sind sie vor Zugriffen aus dem Internet geschützt: darauf beruht ja der anhaltende Erfolg dieser bewährten Technik seit über 20 Jahren. Ich kann nur jedem raten, diese Vorteile zu nutzen und sich, wo es möglich ist, nicht mit https zufrieden zu geben. Der VPN-Tunnel ist wesentlich sicherer und umfassender, insbesondere wenn sich beide Endpunkte in eigener Hand (und nicht bei einem fragwürdigen VPN Provider) befinden. Daß auch ein VPN keinen *totalen* Schutz (z. B. gegen menschliches Versagen oder spezielle Malware) bietet, sollte selbstverständlich sein und wurde von mir nie behauptet.

Das erste Buch, das ich mir vor ca. 15 Jahren über VPN gekauft habe, beschreibt die Situation immer noch recht gut, und was ich daraus gelernt habe, "plappere" ich nicht "nach", sondern ich setze es in die Praxis um. Mehr möchte ich zu deinem jüngsten rhetorischen Produkt nicht sagen, zumal das aktuelle Problem ja nun gelöst ist. Mir tun nur die Leser leid, die durch den ganzen Wust hindurch müssen, bevor sie endlich auf etwas konkret Brauchbares zu dem von mir geposteten Thema stoßen. Denn dieses Thema war ein anderes als das von dir nun ausufernd herangezogene.

 

[KunterBunter]

Solange die Daten sich im VPN (einschließlich des Tunnels zwischen den LANs) bewegen, sind sie vor Zugriffen aus dem Internet geschützt: darauf beruht ja der anhaltende Erfolg dieser bewährten Technik seit über 20 Jahren. Ich kann nur jedem raten, diese Vorteile zu nutzen und sich, wo es möglich ist, nicht mit https zufrieden zu geben.

Das klingt fast wie aus deinem Buch abgeschrieben. Welches Buch ist das denn?
Nur leider kann ich deinem Rat nicht folgen, beim Online-Banking muss ich mich weiterhin mit dem weniger sicheren HTTPS zufrieden geben. Oder kannst du mir eine Bank nennen, bei der ich mich per VPN verbinden kann? Das würde ich dann glatt einmal versuchen.

 

[PeterPawn]

Die Ansicht, ob ein Zugriff aus einem per VPN verbundenen LAN-Segment nun "Internet" ist oder nicht, ändert sich bei AVM auch schon mal - auch mit der Implementierung in der Firmware. Man kann mir hier also zum "Vorwurf" machen, daß ich bei den Versionsnummern nicht genau genug hingesehen habe, weil das seit FRITZ!OS 7 tatsächlich nicht länger so ist - ja, das war eine Änderung, die AVM sogar in der "info_de.txt" festgehalten hat:

- **Änderung:** In der Kindersicherung für Internetnutzung gesperrte Geräte über VPN erreichbar

Diese explizit erwähnte Änderung zeigt aber auch, daß es vorher anders war und das kann man hier in mehreren Threads nachlesen - bei der Frage, ob "lokal" oder nicht, ging es meist um die Login-Seite und ob dort die vorhandenen Konten aufgezählt werden oder nicht.

Das ändert leider nichts an der "Schande", daß mein Tipp hinsichtlich des falschen Profils angesichts der Version tatsächlich falsch war und Du es ja schon in #4 soo viel besser wußtest. Aber ich würde hier mal - quasi als Entschuldigung - anführen, daß Dir das ja offensichtlich auch erst eine Minute vor meinem Klick auf "Post reply" eingefallen ist:

und da hatte ich den Beitrag tatsächlich schon geschrieben und auch die regelmäßige JS-Abfrage nach weiteren Beiträgen im Thread hat den zu diesem Zeitpunkt noch nicht signalisiert. Mir das jetzt dann "um die Ohren zu hauen", ist durchaus legitim ... aber die Frage, warum man (eigene Netzwerk-Kenntnisse mal unterstellt) das mit dem fehlenden Gateway erst nach 4 1/2 Stunden und nachdem man sich mit einer (unsinnigen) Änderung aus der entfernten Box selbst ausgesperrt hat, bemerkt, stellt man sich eben auch unwillkürlich.

========================================================

Was das dann aber wieder mit HTTPS vs. VPN zu tun hat, erschließt sich mir nicht ... und ich habe eben auch niemals VPNs per se in Grund und Boden verdammt. Bei mir wirst Du lesen können, daß sie Vor- und Nachteile haben und daß man diese kennen und gegeneinander abwägen muß/sollte. Nicht zuletzt wollte ich Dir dazu Gelegenheit geben ... außer Allgemeinplätzen (zumindest nach meiner Ansicht) und dem Berufen auf die "herrschende Meinung (und AVM)" kam da aber nicht wirklich etwas.

Aber da macht eben dann eine Erklärung dieser Vor- und Nachteile (nicht jeder kann in dem von Dir gelesenen Buch nachschauen, erst recht nicht, wenn Du uns die Quelle nicht verraten willst) auch für andere Leser wieder Sinn - aber nicht eine weitgehend unreflektierte Aussage, daß ein VPN immer sicherer wäre. Daß das eben genau nicht so sein muß, habe ich versucht zu erklären - zumal hier auch wieder zwei unterschiedliche VPN-Szenarien munter durcheinander geworfen werden von Deiner Seite.

Bei einer LAN-LAN-Kopplung zwischen zwei FRITZ!Boxen kommt tatsächlich auch PFS zum Einsatz (wenn man die Konfiguration über das GUI erstellt) - damit ist die Aufzeichnung und spätere Entschlüsselung dann auch nicht möglich. Aber auch davon war hier ja gar nicht die Rede:

Auch um von unterwegs mit der FritzApp Fon über WLAN zu telephonieren, wird dieser "Zugang aus dem Internet" zur heimischen FB nicht benötigt, da es sicherer über VPN geht.

- denn auch das entfernte LAN bei einer VPN-Verbindung ist ja wohl kaum "unterwegs"; zumindest nicht das, was man gemeinhin unter "unterwegs" zu verstehen pflegt und diese Bemerkung hatte ja wohl kaum noch etwas mit Deiner LAN-LAN-Kopplung aus #1 zu tun, bei der es ja um irgendwelche IP-Telefone von Snom geht und nicht um die FRITZ!App Fon.

Daß ein VPN auch in der Lage ist, anderen Verkehr als HTTP zu verschlüsseln (bei HTTPS über VPN ist das dann aber wieder sinnlose Ressourcenverschwendung in vielen Fällen), versteht sich von selbst und das habe ich auch nie bestritten. Nur was spielt das für eine Rolle, wenn es am Ende nur darum geht, über diese VPN-Verbindung HTTP-Traffic zu übertragen? Hast Du tatsächlich eine Ahnung von den jeweils verwendeten Crypto-Algorithmen und deren Einfluß auf die Frage, was da am Ende "sicherer" wäre? Es gibt gar keinen (plausiblen) Grund zu der Annahme, daß der HTTP(S)-Zugriff auf den Port 49000 (oder 49443 bei HTTPS) durch eine FRITZ!App "von unterwegs" irgendwie sicherer wäre in Abhängigkeit davon, ob er über ein VPN erfolgt oder über das "tr064cgi" (unter der URL /tr064, siehe https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/AVM_TR-064_remote.pdf).

Wie ich schon weiter vorne angeführt habe, ist das sogar bei Nutzung von TLS 1.3 über HTTPS viel eher als "sicherer" anzusehen - zumindest dann, wenn die VPN-Verbindung kein PFS nutzt (und hier geht es dann auch wieder nur um den Aspekt der "Transportsicherheit"). Für die Sicherheit des gesamten LANs ist es eben nicht wirklich besser - NIEMAND hat tatsächlich die beiden Endpunkte einer VPN-Verbindung (weder bei LAN-LAN noch bei LAN-User - aka Smartphone/Tablet/Laptop) so unter Kontrolle, daß er die Anwesenheit eines "Angreifers" (in Form einer Software, die nicht ganz das macht, was sie zu tun behauptet) 100% ausschließen kann (heute und für alle Ewigkeit) und da wird dann auch mal die VPN-Verbindung, die eben nicht nur den HTTP(S)-Transport unterstützt, zum "Sicherheitsrisiko".

Im Übrigen paßt nach meiner Ansicht die Feststellung, daß eine VPN-Verbindung auch genau deshalb einem HTTPS-Zugriff immer vorzuziehen sei:

Ich kann nur jedem raten, diese Vorteile zu nutzen und sich, wo es möglich ist, nicht mit https zufrieden zu geben. Der VPN-Tunnel ist wesentlich sicherer und umfassender, insbesondere wenn sich beide Endpunkte in eigener Hand [...] befinden.

ja nun so gar nicht zu der Ansicht:

Denn jeder überflüssige Zugang ist eine zusätzliche Angriffs- und damit Schwachstelle.

... am Ende ist auch eine VPN-Verbindung, die beliebigen Traffic transportiert, den man für das Bereitstellen eines bestimmten Dienstes gar nicht benötigt (und das AVM-VPN filtert - ohne manuelle Änderungen - auch keinen Traffic nach Portnummern oder Protokollen aus), nichts anderes als ein solcher "überflüssiger Zugang" und wenn ein Zugriff auf ein (vernünftig per TLS gesichertes) Interface auch ohne VPN-Verbindung möglich ist (das gilt natürlich nicht nur für HTTP, sondern auch für SIP und RTP, usw.), braucht es diese Verbindung auch aus den angesprochenen Erwägungen zur "kleinstmöglichen Angriffsfläche" nicht. Wenn eine "malicious app" nicht den Telnet-Zugang der IP-Kamera im LAN erreichen kann (weil es keine VPN-Verbindung gibt und der Port nicht anderweitig freigegeben ist), kann sie diesen auch nicht benutzen oder "angreifen" und sich so in der Kamera einnisten (um mal ein Beispiel zu nennen, was so tatsächlich passierte: https://www.golem.de/news/mirai-iot...kunden-mit-malware-infiziert-1611-124602.html).

Noch mal ganz deutlich zur Klarstellung ... ich bin nicht der Ansicht, daß VPNs per se irgendetwas vom Teufel wären und man sie - da wo sie sinnvoll oder unumgänglich sind - nicht einsetzen sollte. Aber sie sind eben auch kein "Allheilmittel" bzw. sie sind eher eine Medizin, die auch ihre Nebenwirkungen hat.

Und wer gänzlich unreflektiert (oder eben auch auf Nachfrage ohne weitere Begründung) die Ansicht äußert, daß ein VPN immer sicherer wäre und event. Probleme dabei nur durch "menschliches Versagen oder spezielle Malware" entstünden, der verkennt eben die Wirklichkeit ... denn es gibt solches menschliches Versagen (dem Vernehmen nach) immer mal wieder und auch solche "spezielle Malware" (die z.B. über eine RPC-Lücke als Ransomware den Inhalt der HDDs von Windows-PCs verschlüsselt oder Banking-Daten versucht abzugreifen: https://www.bsi-fuer-buerger.de/BSIFB/DE/Service/Aktuell/Informationen/Artikel/emotet.html) wurde m.W. schon in freier Wildbahn gesichtet.

Außerdem würde diese Prämisse, daß Sicherheitsprobleme eigentlich immer nur durch menschliches Versagen oder "spezielle" Malware (manchmal auch nur in Gestalt fehlerhafter "Goodware") hervorgerufen werden, auch für TLS-verschlüsselte Zugriffe gelten (bzw. die dabei eingesetzten Komponenten, in erster Linie den TLS-Stack).

 

[hl3]

Das klingt fast wie aus deinem Buch abgeschrieben. Welches Buch ist das denn?

Woher weiß du das, da du das Buch ja gar nicht kennst? Es ist weder abgeschrieben noch zitiert. Aber vielleicht darf man sich ja noch ein eigenes Urteil bilden, ohne sich dafür mit genauer Quellenangabe und/oder akademischem Leistungsnachweis dafür zu rechtfertigen, ja? Das Buch ist: Markus a Campo / Norbert Pohlmann: Virtual Private Networks, 2. Aufl. 2003, 398 Seiten, mitp.

Nur leider kann ich deinem Rat nicht folgen, beim Online-Banking muss ich mich weiterhin mit dem weniger sicheren HTTPS zufrieden geben. Oder kannst du mir eine Bank nennen, bei der ich mich per VPN verbinden kann? Das würde ich dann glatt einmal versuchen.

Das wäre ein *neues* Thema, das du selbst anlegen solltest. Aber daß Deutschland (inclusive seiner Banken) ein digitales Entwicklungsland ist, dürfte inzwischen allgemein bekannt sein. Mehr sage ich dazu an dieser Stelle nicht.

-- Zusammenführung Doppelpost by stoney

... aber die Frage, warum man (eigene Netzwerk-Kenntnisse mal unterstellt) das mit dem fehlenden Gateway erst nach 4 1/2 Stunden und nachdem man sich mit einer (unsinnigen) Änderung aus der entfernten Box selbst ausgesperrt hat, bemerkt, stellt man sich eben auch unwillkürlich.

Ich bin eben nicht perfekt und habe es nie behauptet. Sonst hätte ich mein Problem wohl auch nicht hier vorgestellt, oder? Wie man darin etwas Fragwürdiges finden kann, erschließt sich mir nicht. Das gegenwärtige Thema, wie es von mir formuliert wurde, halte ich mit der ebenfalls von mir bekannt gegebenen Lösung für erledigt. Wer Lust hat, mag weiter reden. Viel Spaß dabei; mir fehlt die Zeit dafür.

 

[PeterPawn]

Wie man darin etwas Fragwürdiges finden kann, erschließt sich mir nicht.

Fragwürdig war weder Dein Problem, noch die Lösung ... merkwürdig wurde das erst durch das "ich habe es doch schon in #4 selbst gewußt und Du lagst daneben" in #22, wobei #4 eben nur eine Minute vor meinem Beitrag von Dir "nachgereicht" wurde:

sondern da, wo ich es schon in Nachricht #4 verdächtigte:

- das kann man leicht mißverstehen nach der bisherigen "Auseinandersetzung". Zumindest habe ich es dahingehend mißverstanden, wenn das nur eine vollkommen neutrale Beschreibung der nunmehr von Dir selbst gefundenen und bestätigten Lösung gewesen sein soll - angesichts der "Zugaben", die Du dann (in #22 im 2. Absatz) noch einmal zur Frage "HTTPS vs. VPN" gegeben hast, ist vielleicht auch diese Interpretation verständlich?

Und "schräg" wurde das hier für mich erst wirklich, als Du Dich - nach meinen "Nachfragen" zu Deinem Kommentar meiner Aussage hinsichtlich der FRITZ!Apps (wo es ja offensichtlich genau nicht um die Fon-App gehen konnte, weil die mit dem "Fernzugang" gar nichts anzufangen weiß) in #15 (1. Absatz) - anfingst zu winden ... aber meine "Interpretation" dessen, was da Deinerseits schon anklang, war ja offensichtlich doch nicht soo falsch, wenn man sich die danach noch folgenden Bemerkungen ansieht und daß man nach Deiner Ansicht unbedingt VPN benutzen sollte, wo immer es geht (oder habe ich das falsch interpretiert) - ohne Berücksichtigung der konkreten Umstände.

Daß das auch AVM offensichtlich nicht genauso sieht (entgegen Deiner Behauptung irgendwo weiter vorne) und bei der MyFRITZ!-App sogar explizit die TR-064-Funktionen auf der WAN-Seite selbst freischaltet (obwohl(!) diese App gleichzeitig auch eine VPN-Verbindung einrichten kann - und da gibt es bei AVM m.W. auch keine Info bzw. kein "Statement", was nun "besser" oder "sicherer" wäre), ist nun mal eine Tatsache, die man nicht so ohne weiteres "wegdiskutieren" kann. Und genau an die Benutzer dieser Apps (bzw. eigentlich ja an diejenigen, die diese Apps eben nicht nutzen) richtete sich auch mein Kommentar, daß man diesen Zugang - den man für die Dauer von Konfigurationsänderungen aktiviert hat, wenn man sich "nicht sicher" ist über die Auswirkungen der eigenen Handlungen bzw. wenn eine Aktion absehbar zum Verlust anderer Verbindungen/Zugänge führen wird - dann auch wieder deaktivieren könnte/sollte.

Letztlich stellt sich ja nun aber heraus, daß Du das eben nicht nur "versehentlich" schlecht formuliert oder mich mißverstanden hast (Du wolltest mir ja sogar "grammatikalische Penibilität" unterstellen) ... die von mir schon in #15 bezweifelte "Kernaussage" Deines Kommentars in #14, daß ein VPN-Zugang einem HTTPS-Zugang vorzuziehen wäre (ohne irgendeine plausible Begründung dafür anzugeben), bekräftigst Du ja nun extra noch einmal - leider immer noch ohne die notwendigen Differenzierungen, was ein VPN am Ende bringt und wo man es sinnvoll einsetzen kann/sollte.

Das klingt mir dann doch eher danach, als wenn da jemand irgendwelchen Empfehlungen, man sollte doch besser von unterwegs aus fremden WLANs nur per VPN arbeiten (die durchaus ihre Berechtigung haben - im richtigen Kontext), folgt und das dann eben für das (auch bereits angesprochene) Allheilmittel hält bzw. den Aspekt der "Sicherheit" (ohne das - selbst auf Nachfrage hin - näher zu spezifizieren) nur auf den Schutz gegen "eavesdropping" beziehen möchte (wo das durchaus seine Berechtigung hat, auch wenn DoT und HTTPS da schon gute Arbeit leisten - sofern man nicht aus IP-Adressen wieder auf die genutzten Dienste schließen kann). Sicherheit hat aber noch viel mehr zu berücksichtigende Gesichtspunkte ... und genau deshalb macht eine Aussage "das ist sicherer" ohne die Angabe, worauf sich dieser "Vergleich" beziehen soll, so gar keinen Sinn.

Denn als Schutz gegen dieses "eavesdropping" (also das Mitlesen von Traffic durch Unbefugte) hilft eine VPN-Verbindung auf dem mobilen Gerät tatsächlich ... solange es um das WLAN geht, aus dem man gerade "funkt". Wie oben schon richtig festgehalten wurde, kann aber bei der Nutzung eines kommerziellen VPN-Services spätestens dessen Anbieter auch wieder "sehen" (jedenfalls ebenso gut, wie der WLAN-Betreiber bei DoT oder DoH und HTTPS), wohin man gerade "telefoniert" ... und auch wenn E.T.s VPN-Verbindung am heimatlichen Anschluß mit der FRITZ!Box endet (man also "nach Hause telefoniert"), hat der Anbieter für diesen Anschluß wieder dieselben Möglichkeiten. Nur traut man dem eigenen Provider i.d.R. am meisten, dann ggf. auch einem VPN-Anbieter (der sich sein Geschäft ruiniert, wenn er zuviele Protokolle führt) und dem WLAN-Anbieter sicherlich immer am wenigsten.

Trotzdem erfährt auch letzterer bei passender Konfiguration des eigenen Geräts "nichts Neues" (oder nur wenig) bei der Benutzung des externen GUI (einer FRITZ!Box) mit einer App - jedenfalls im Vergleich zu einer VPN-Verbindung zu derselben Box und das bei deutlich verringertem Risiko für das heimatliche LAN, wenn man eben keine VPN-Verbindung (dafür) nutzt.

Denn was braucht die App für den Zugriff? Zunächst mal den DNS-Namen der FRITZ!Box - bei vielen sicherlich die myfritz.net-Adresse. Dessen Ermittlung (EDIT: hier ist logischerweise die Ermittlung der Adresse zum Namen gemeint) kann der jeweilige Provider "mitlesen" ... je nachdem, wo da Verschlüsselung eingesetzt wird ("normales" DNS vs. DoT/DoH), verlagert sich der Ort, an dem das "aufgedeckt" werden muß, halt immer weiter zu irgendeinem Anbieter (auch der DoT-/DoH-Server muß am Ende schon erfahren, was der Client eigentlich wissen will).

Anschließend wird die App die Box über den (bei der Einrichtung zufällig gewählten) Port für den HTTPS-Zugriff kontaktieren ... spätestens da weiß dann der "lokale" Betreiber eines WLAN auch, wo sich die FRITZ!Box des Besitzers des mobilen Gerätes befindet - damit könnte er jetzt seinerseits das GUI "quälen", aber eben nur in begrenztem Maße, denn es gibt den bereits erwähnten Schutz gegen Brute-Force-Angriffe.

Was passiert denn nun, wenn man stattdessen eine VPN-Verbindung für diese App benutzen möchte? Nun ... um diese Verbindung (zur heimischen FRITZ!Box) aufzubauen, muß man erst mal wissen, wo man sie in den Weiten des Internets finden kann. Dazu braucht es die DNS-Abfrage ... genau wie zuvor beim direkten Zugriff mit der App. Die Portnummer (bei HTTPS noch zufällig im FRITZ!OS, s.o.) ist hier "fest" (zumindest ist die Auswahl mit UDP 500 bzw. UDP 4500 klein) und spätestens beim Versuch, die VPN-Verbindung aufzubauen, sieht jetzt der lokale WLAN-Betreiber auch wieder (wenn die DNS-Abfrage ihm tatsächlich entgangen sein sollte, was bei DoH innerhalb eines Browsers auch wieder wahrscheinlicher ist, als daß ein ganzes OS (wo das VPN i.d.R. ein Teil von wäre und deshalb auch dessen Dienste nutzt) komplett über DoT arbeitet), wo sich die FRITZ!Box (derzeit) finden läßt.

Allerdings werden viele automatische "Scanner" diesen Traffic gar nicht wahrnehmen ... die konzentrieren sich in den allermeisten Fällen nämlich auf die "well-known ports" und da gehört das GUI einer FRITZ!Box (im Gegensatz zu deren VPN-Endpoint) nicht zwangsläufig dazu, wenn es der Benutzer nicht genauso haben will. Wenn also jemand nur IP-Adressen sammelt (ohne die dazugehörigen Ports) und die Geräte dort auf "bekannte Dienste" scannt, wird er bei einer FRITZ!Box i.d.R. beim GUI eher auf taube Ohren stoßen, solange er nicht alle Ports durchprobiert oder den richtigen kennt.

Da eine App auf das GUI des FRITZ!OS auf der WAN-Seite auch nur verschlüsselt zugreifen KANN (ohne TLS gibt's den Zugriff gar nicht), gibt es hier - hinsichtlich der "akuten" Transportsicherheit - gar keinen relevanten Unterschied zwischen HTTPS und VPN bei der Benutzung einer der FRITZ!Apps, die ihrerseits auf das (externe) GUI des FRITZ!OS zugreifen.

Und genau auf diesen Punkt (FRITZ!Apps, die auf GUI-Ports starren) bezog sich meine Aussage, die später dahingehend kommentiert wurde (und die "Zusammenfassung" aller FRITZ!Apps als FRITZ!App Fon wollte ja auch @hl3 so verstanden wissen in #20 - und so habe ich das auch schon in #14 verstanden), daß man das ohnehin über eine VPN-Verbindung "sicherer" machen sollte.

Daß es für die FRITZ!App Fon dieser Aussage gar nicht bedarf (weil die mit dem HTTPS-Zugang ohnehin nichts macht), dürfte inzwischen auch deutlich herausgearbeitet worden sein - das macht also auch die "Interpretation" meinerseits, daß sich dieser Kommentar gar nicht wirklich auf die FRITZ!App Fon speziell beziehen sollte, sondern "alle FRITZ!Apps" damit gemeint waren, sicherlich nachvollziehbar ... und warum diese Aussage für "alle FRITZ!Apps" eben nicht stimmt (zumindest nicht so pauschal, wie sie in #14 daherkam), habe ich nun auch zur Genüge begründet.

Wer also der Ansicht ist, er benutze ja eine VPN-Verbindung und damit wäre das Thema "Sicherheit" gegessen bzw. das wäre per se sicherer, als wenn er den HTTPS-Zugang zum GUI des FRITZ!OS freischaltet (damit die Apps ihn nutzen können, aber auch damit man darüber z.B. Konfigurationsänderungen vornehmen oder auch mal die Box neu starten kann), der unterliegt - wenn er das so pauschal behaupten will - einem Irrtum. Es gibt durchaus gewichtige "Löcher" in der Sicherheit, die mit einer (unnötigen) VPN-Verbindung erst aufgerissen werden und weit mehr Geräte "gefährden" (bzw. am Ende unbemerkt bleiben können), als nur ein paar kompromittierte Credentials für einen GUI-Zugriff (wobei die beim XAUTH für eine LAN-User-Connection ohnehin ebenfalls kompromittiert wären, wenn jemand Zugriff auf gespeicherte Daten für die VPN-Verbindung erhält). Auch gegen Brute-Force-Attacken (durch "Probieren" von Credentials) ist der HTTPS-Zugang der Box deutlich besser geschützt, als der VPN-Endpoint.

Ob sich das mit dem nächsten Release nun ändert (AVM hat das VPN ja ziemlich umgekrempelt), wird sich zeigen - entsprechende Meldungen im Event-Log sind mir bisher noch nicht aufgefallen. Und hier meine ich nicht das tatsächliche Log einer Box, die jemand angegriffen hat, sondern die von AVM dafür vorgesehenen Meldungen - siehe Anhang, die sind für die 113.07.19.-79325. Weder mit "VPN" noch mit "fehlgeschlagen" habe ich einen passenden Meldungstext für eine Attacke (DoS oder BF) auf den VPN-Endpoint gefunden. Ob das am Ende durch die "Verhaltenserkennung" von AVM als Angriff gewertet und (sofern der Besitzer dem zugestimmt hat) an den Hersteller "gemeldet" wird, lohnt sich auch erst wieder beim Release zu testen.