ich sehe da jetzt kein Fehlverhalten [...] der FB.
Wenn es tatsächlich nicht auf den Inhalt des Paketes ankommt (die Antwort darauf steht ja noch aus) und der Rechner trotz nicht gesetzter Checkmark bei "automatisch starten" von der FRITZ!Box mit einem "magic packet" geweckt wird, ist das für mich schon ein Fehlverhalten. Wenn die Checkbox nicht genau dieses Verhalten steuern soll, wofür ist sie dann da?
Das ganze klappt ja nur, wenn das magic paket an den richtigen Rechner weitergeleitet wird und auch bereits die Mac-adresse des zu startenden Rechners enthält. Jede andere Kombination wird scheitern.
Das wäre zu überprüfen.
Wenn es tatsächlich ein "magic packet" braucht, um dort etwas zu bewirken, dann ist das immer noch eine Möglichkeit eines undokumentierten Zugriffs von extern auf eine FRITZ!Box.
Auch muß ja dann irgendwie aus diesem ankommenden Paket ein WoL-Paket (also i.d.R. 6x 0xFF gefolgt von 16 Wiederholungen der MAC-Adresse des zu weckenden Rechners) generiert werden. Ein "magic packet" wird als Broadcast oder als Unicast an die MAC-Adresse des zu weckenden Rechners gesendet.
Es muß also irgendwo in der FRITZ!Box mindestens eine Behandlung existieren, die - eben genau nach einer "deep packet inspection" - aus einem Paket an eine Zieladresse mit Port 9 (falls die Wahl des "discard"-Ports tatsächlich von Bedeutung wäre) ein entsprechendes Paket erzeugt.
Broadcasting für jedes externe Paket mit Zielport 9 wäre natürlich der Clou ... da reibt sich jeder Hacker die Hände. Also ist das hoffentlich - wenn es wirklich so implementiert ist - wenigstens etwas besser umgesetzt.
Wenn da aber nicht noch intensive Plausibilitätsprüfungen stattfinden (z.B. auf Existenz der MAC-Adresse im LAN), sondern eben nur ein passendes Paket ins LAN geleitet wird (egal ob generiert oder geroutet), dann hat ein Angreifer eine wunderbare Möglichkeit ein LAN mit Paketen zu fluten, was ja genau durch eine Firewall vermieden werden soll. Das wäre dann - in meinen Augen jedenfalls - eine Sicherheitslücke.
Wenn es aber am Ende nur das Ergebnis der existierenden Portweiterleitung (und der korrekten Auswertung der Checkbox "automatisch starten") ist, dann ist der Paketinhalt vollkommen Bummi und es handelt sich auch um eine (spärlich) dokumentierte und abschaltbare Funktion.
Dann weckt aber eben nicht das ankommende Paket, sondern ein getrennt von der FRITZ!Box generiertes WoL-Paket, den Computer. Das ist durch einfachen Packetdump ja problemlos zu verifizieren. Selbst ein Negativtest (WOL-Paket mit falscher MAC-Adresse vom Handy) wäre bei leseratte10 möglich.
Die Beschreibung, daß es funktioniert hat, zweifele ich nicht im Geringsten an ... das war es ja auch, was ich dem TE mit dem Verweis auf die WoL-Möglichkeiten im GUI ans Herz legen wollte in #6.
Ich bezweifele nur die dafür gelieferte Begründung und wenn leseratte10 berichtet, daß die Auswahl in der Checkbox bei "automatisch starten" am Ende egal ist, dann ist das - zumindest wenn meine Begründung, wie das abläuft, richtig ist - ein (schwerer) Fehler in der Firmware.
Ein Packetdump, der kein gesondertes WoL-Paket zeigt, ist ein weiteres Indiz für den behaupteten Zusammenhang von "wake over internet" und Port 9 - ein (EDIT: funktionierender) Test mit einer Weiterleitung an Port 10 anstelle von Port 9 ein Indiz für meine Annahme.
Mich interessiert dieses Thema nur so weit am Rande, daß ich mich nicht zu eigenen Tests aufraffen kann oder will. Es geht mir nur darum, ob die Begründung und der Mechanismus, mit dem das Wecken bei leseratte10 funktionierte, stimmen. Wenn das so wäre, halte ich es für ein Risiko und das würde ich dann gerne beseitigt sehen. Wenn leseratte10 das nicht testet, landet es bei mir auf der ToDo-Liste und wird sicherlich irgendwann in den nächsten zwei Wochen mal von mir ausgiebig getestet.
Wo stimmen die vorstehenden Überlegungen nicht? Ich kann mich ja auch irren ... aber dann bitte ich um entsprechende Begründungen/Tests. Aus einem funktionierenden Ablauf auf einen bestimmten Wirkmechanismus (also eine Kombination aus Eingangsvoraussetzungen und Ergebnissen) zu schließen ist nur dann zulässig, wenn man auch die Tests macht, bei denen die Eingangsbedingungen von den postulierten abweichen und dann genau nicht die erwarteten Ergebnisse erzielt werden. Ansonsten besteht eben der angenommene Zusammenhang einfach nicht und die Ergebnisse sind von den Voraussetzungen unabhängig.
Wenn AVM tatsächlich in den Netzwerkstack eine Sonderbehandlung für Port 9 (das wäre dann ja IP und UDP oder TCP als darüber liegende Schicht) eingebaut haben sollte, stellte sich mir wieder die Frage, warum das an anderen Stellen (Port-Knocking für den Hersteller) nicht auch der Fall sein sollte. Das geht aber selbst mir zu sehr in Richtung Verschwörungstheorien ...
