Das ist ein Mapping, was alle FRITZ!Boxen mit dem neuen Mechanismus der Portfreigabe (eben dem "Port Control Protocol") verwenden ... immer! Steht praktisch in jeder (als Router arbeitenden) FRITZ!Box als Mapping und kann dort in den Support-Daten angesehen werden (woanders taucht es nicht auf):
Code:
MAP TCP [192.168.178.1]:9 [123.1.2.3]:9, lifetime 120 secs, renew in 53 secs
uniqid 0
group "IGDPROBE" desc "IGDPROBE4"
nonce 15ab0cdcbc42012821406f9b active
[COLOR="#008000"]<= [255.255.255.255]/128 port 9[/COLOR]
filter version: wanted 1 sent 1 installed 1
wanted_lifetime 184549375 lifetime 120
age 1229426 lasttime 7 endtime 53 nsent 0
last actions: req 7 reply 7 (secs ago)
Die Frage ist halt, ob diese zusätzliche Angabe ggü. anderen Mappings "[255.255.255.255]/128 port 9", die ja offensichtlich ein Filter sein soll (bei PCP arbeitet alles prophylaktisch mit Adressen in IPv6-Breite) für die Quell- oder die Zieladresse gelten soll. Ich denke mal für die Zieladresse und da es auf dem Port 9 in der Box gar keinen wartenden Prozess gibt (sagt mein "netstat"), muß das schon ziemlich früh im IP-Stack, aber eben noch nach der Firewall/dem Forwarding (sonst bräuchte es den Eintrag nicht), ausgewertet/umgeleitet werden. Da bei PCP auch der vorgelagerte Server seinerseits einen PCP-Client per Broadcast über Änderungen informieren kann (nur die Festlegung auf den "discard"-Port habe ich noch nirgendwo gefunden - der ist nämlich auch beim WoL nur "mißbraucht" worden, weil da eben keine Antwort geplant ist auf diesem Port), werden da wohl solche Pakete von einem PCP-Server auf der WAN-Seite der FRITZ!Box "durchgelassen" und dann irgendwie ausgewertet.
Da vermutlich die vorgelagerte 7390 seit dem Update mit PCP-Unterstützung nun ihrerseits bereits das Mapping für Port 9 verwendet, kriegte die dahinterliegende 7490 eben einen anderen externen Port zugewiesen, als sie beim PCP-Server der 7390 den Port 9 für sich reklamieren wollte. So ein PCP-Request kann zwar einen "Wunschport" enthalten, aber der muß ja nicht zwangsläufig zur Verfügung stehen.
Warum das jetzt nicht mehr eingerichtet wird, würde mich viel mehr interessieren ... entweder die 7490 "will" den gar nicht mehr (weil sie die 7390 nicht als zuständigen Server sieht) oder die 7390 zeigt jetzt diese Mappings nicht länger an, um die Kunden nicht zu verwirren (sollte man aber in den Support-Daten der 7390 sehen können, ob das immer noch/schon wieder existiert).
Solange da der Filter für "Broadcast-Adresse und TCP-Port 9" wirkt und das wohl direkt im Kernel oder im kdsld abgefangen wird, dürfte vom "Verschweigen" dieser Mappings (zumindest wenn um die "Sicherheit"-Seite im GUI geht) eher keine Gefahr ausgehen und das eine eher "läßliche Sünde" sein.
Ich staune zwar über mich selbst (und wenn der Filter nicht da wäre, sähe ich das auch anders), aber ein durchzulassendes Paket muß dann ja aus der Broadcast-Domain unmittelbar vor der WAN-Seite stammen und kann nicht irgendwo von weither aus dem Internet kommen. Damit müßte also der Angreifer die Chance haben, irgendwelchen sinnlosen Payload in ein Broadcast-Paket für TCP-Port 9 unmittelbar vor dem DSLAM zu kippen ... das ist dann sogar mir zu theoretisch, wenn es um "malformed payload" für einen so tief im IP-Stack vergrabenen Zweck geht - wie gesagt, eigentlich soll jedes System dort eingehende Pakete ungesehen verwerfen (discard).
Dieses versteckte Mapping ist es eben auch, warum seit ein paar Monaten das Mappen von TCP-Port 9 von extern auf irgendeinen LAN-Client nicht mehr funktioniert, damit man den auf diesem Weg (mit irgendwelchen Apps) wecken kann. Da muß jetzt halt ein anderer externer Port verwendet werden und eine passende Anwendung, die so einen abweichenden Port auch kennt. Das FRITZ!Box-eigene Mapping hat Priorität und eine Möglichkeit "Broadcasts ins Kröpfchen, die anderen ins Töpfchen (im LAN)" gibt es m.E. nicht. Das Port 9-Mapping steht auch in keiner Konfigurationsdatei - da kann man also auch nichts ändern oder ergänzen.
