Bei FritzOS 6 war das noch nicht.
Ich wage mal die Behauptung, daß das eine falsche Beobachtung ist. Daß es beim FRITZ!OS einen anderen Anmeldedialog gibt, in Abhängigkeit vom "vermuteten" Standort des Benutzers ("from_internet" oder nicht), ist schon sehr viel länger implementiert ... der "externe" Anmeldedialog bietet z.B. auch bei aktivierter Anmeldung mit Benutzernamen und Kennwort keine Select-Box für die Benutzernamen an (wie der Dialog aus dem LAN), sondern ein normales Input-Feld.
Auch die Tatsache, daß eine externe Anmeldung
nur mit Benutzernamen und Kennwort möglich ist (unabhängig vom eingestellten Modus aus dem LAN), ist schon länger implementiert und bekannt - nur ändert es sich ab und an mal, was AVM als "extern" ansieht. Das bemerkten früher besonders die Benutzer, die über VPN auf das GUI zugreifen wollten - wenn sie denn aus einem "fremden" Netz kamen. Manchmal ist es allerdings auch keine Änderung bei AVM, sondern eine Änderung im eigenen Netz, die entsprechende Auswirkungen auf die Tests von AVM hat, ob das nun lokal oder "remote" ist. Früher wurde das daran festgemacht, über welches Netzwerk-Interface in der FRITZ!Box das Ziel zu erreichen ist ... war es "dev lan" (i.d.R. eine Bridge, die alle lokalen Interfaces enthält), ist es halt lokal, ansonsten remote. Damit kann schon eine eingerichtete statische Route den Unterschied machen, wie die FRITZ!Box den Zugriff bewertet.
Wie sieht es mit dem Zugang vom WLAN und aus dem Adressbereich des Gäste-WLAN aus?
WLAN ist mit LAN in einer Bridge, da gilt das also 1:1 genauso mit dem unauthentifizierten Zugriff und nur der WPA(2)-PSK schützt vor "öffentlicher Verfügbarkeit" der Dateien, solange der Media-Server in den "Werkseinstellungen" läuft.
Das Gastnetz habe ich noch nicht (erneut) angesehen ... alleine auf der Basis der "Bindungen" der Daemons kann man es noch nicht ausschließen, daß diese auch aus dem Gastnetz erreichbar sein
könnten:
Code:
root@FB7490:~ $ netstat -anp | grep -v "^unix" | grep upnp
tcp 0 0 :::49443 :::* LISTEN 2798/upnpd
tcp 0 0 :::49000 :::* LISTEN 2798/upnpd
tcp 0 0 :::49200 :::* LISTEN 2798/upnpd
udp 0 0 192.168.LAN.1:1900 0.0.0.0:* 2798/upnpd
udp 0 0 0.0.0.0:1900 0.0.0.0:* 2798/upnpd
udp 0 0 fe80::a96:d7ff:fexx:xxxx:1900 :::* 2798/upnpd
udp 0 0 fd00::a96:d7ff:fexx:xxxx:1900 :::* 2798/upnpd
udp 0 0 2a02:81xx:xxxx:xxxx:a96:d7ff:fexx:xxxx:1900 :::* 2798/upnpd
udp 0 0 :::1900 :::* 2798/upnpd
udp 0 0 :::52694 :::* 2798/upnpd
root@FB7490:~ $
Die einzigen "listener", die explizit NICHT aus dem Gastnetz zu erreichen sind (und wo das nicht erst später durch entsprechende Tests unterschieden werden muß), sind der in der vierten Zeile und die für die IPv6-Adressen (da hat das "guest"-Interface andere als die hier "maskierten") ... die sind also ausschließlich an die LAN-Adressen der FRITZ!Box gebunden und nur von dort zu erreichen.
Nun ist der "upnpd" bei AVM aber genauso eine "Wundertüte" mit allen möglichen Aufgaben (Advertising, TR-064, Netzwerk-Discovery für andere UPnP-Devices) in einem einzigen Binary, wie es der "multid" ist ... und da der eben "closed source" ist, muß man das tatsächlich auch ausdrücklich alles testen und zwar für jeden Dienst, der über diese Ports bereitgestellt wird. Für den Media-Server ist dabei der TCP-Port 49200 ausschlaggebend, über den erfolgt der Zugriff auf den HTTP-Server, der die Dateien übertragen soll. Da ich bei mir im "Normalmodus" kein Gastnetz aktiviert habe, fällt das leider "nicht so nebenbei" ab.
Aber gerade im Angesicht der sich auch immer wieder ändernden IPv6-Funktionen ist das sicherlich noch einen erneuten Test wert .. über die "ungebundenen Listener" können natürlich auch lokale Zugriffe mit IPv6-Adressen erfolgen und da reicht dann eine "vergessene" Abfrage für IPv6 ggf. schon aus, damit der mit IPv4-Adressen noch sauber blockierte Zugriff am Ende vielleicht doch klappt.
Allerdings hat AVM eigene Erweiterungen in den internen Strukturen des Kernels für den Inhalt von Netzwerk-Paketen vorgenommen und in einem dieser zusätzlichen Felder wird auch das Interface vermerkt, über das ein Paket eingegangen ist (damit muß man das nicht anhand von Adressen "schlußfolgern"). Das ist einer der Gründe, warum die parallele Verwendung von "iptables" so große Probleme bereitet, obwohl von AVM-Seite auf den LAN-Interfaces da ansonsten gar nichts anderes aktiv ist - die eigentliche AVM-"Firewall" sitzt im "dsld" (bzw. dem entsprechenden Kernel-Module "kdsldmod.ko") und es kamen höchstens noch ein paar Tests hinzu bei den AVM-Daemons, was die Abschottung zwischen LAN und Gastnetz anbelangt.