Separater httpd für WoL-CGI notwendig?

Wir haben uns alle daran gewöhnt, daß die Web-Oberfläche für Etherwake (Wake-on-LAN) im DS-Mod auf Port 82 erreichbar ist. Ich persönlich frage mich seit langem, ob es nicht eine Integration ins normale DS-Mod-Menü auch getan hätte. Damit könnte man sich einen separaten Webserver-Prozeß (httpd) einsparen. Stattdessen hätte man eben eine URL wie http://fritz.box:81/wol.cgi zur Verfügung, welche über einen entsprechenden Menüpunkt im DS-Mod erreichbar wäre. Die Konfigurationsseite http://fritz.box:81/cgi-bin/pkgconf.cgi?pkg=wol würde sich vereinfachen (kein Port und kein separates Paßwort mehr zu pflegen), der Start/Stop-Menüpunkt unter "Dienste" würde auch entfallen, /mod/etc/httpd-wol.conf ebenfalls.

Ich schlage daher vor, daß wir das vereinfachen bzw. vereinheitlichen und WoL direkt in die DS-Mod-Oberfläche integrieren. Gerade Besitzern schwächer ausgestatteter Boxen würde das entgegen kommen.

Nun mag es Gründe geben, weshalb der eine oder andere Benutzer WoL lieber separat in einem eigenen httpd auf einem eigenen Port haben möchte. Falls dem so ist, wäre es interessant, mehr über solche Anwendungsfälle zu erfahren. Beschreibt Sie bitte ggf. hier in diesem Thread.

P.S.: Daß WoL als Nachladelösung für Benutzer ohne DS-Mod evtl. einen eigenen httpd verwendet, ist hier nicht das Thema.

Dann sollte man aber auch keinen unverschlüsselten Zugriff auf Port 82 zulassen (Paßwortübertragung!!!). Ich z.B. tunnele beide Ports (81 und 82) durch eine SSH-Verbindung, und dann ist es wieder egal. Andere Möglichkeit: matrixssl vorschalten, dann wird das Paßwort verschlüsselt übertragen. Somit ist das aus meiner Sicht kein besonders starkes Argument.

Genau deshalb verschlüssele ich auch: kein Bedarf, meine Rechner von anderen wecken zu lassen, während ich im Urlaub bin. Aber zurück zum Grundproblem, damit ich es auch verstehe. Geht es Euch um eine kurze, eindeutige URL, um den Mod schnell zu erreichen? Da wäre mir http://xy:81/wol.cgi genauso recht wie http://xy:82. Man könnte das CGI ja auch in einem separaten Fenster öffnen lassen (wie meine Rudi-Shell), damit der Rest der DS-Menüs nicht "stört". Oder geht es Euch darum, daß das Knacken des Paßworts für WoL gleichbedeutend wäre mit dem Knacken des DS-Mod-Paßworts? In dem Fall empfehle ich ein langes, kompliziertes PW und, wie schmatke das ja auch macht, SSL-Verschlüsselung. Die zusätzlichen Möglichkeiten wie Port-Knocking sichern das Ganze bei Bedarf noch besser ab, aber das wäre dann doch so langsam off-topic.

Ich schätze mal, es geht Euch um eine Art Schadensbegrenzung im Sinne von: Wenn ich schon unsicher arbeite, dann ist es weniger schlimm, wenn jemand meine Rechner einschaltet (kostet "nur" Energie) als wenn er auch direkten Zugriff auf sie samt Router bekommt. Richtig? Kann ich teilweise nachvollziehen, obwohl ich mich dann wieder frage, weshalb ich einen Rechner von außen einschalte, wenn nicht, um ihn anschließend fernzusteuern oder in sonstiger Form auf ihn zuzugreifen. Wenn also jemand mein WoL-Paßwort mitloggen kann, kann er auch alles andere, das unverschlüsselt über die Leitung geht, mitloggen und somit auf den Rechner im LAN zureifen. Der wiederum sieht meistens auch den Router...

Hmm, grübel... würde es allen Seiten gerecht werden, wenn man in make menuconfig zwischen zwei Varianten (separates und integriertes WoL-CGI) wählen könnte?

Tip für alle, die nicht Symptome (offene Ports != SSH), Paßwortübertragung im Klartext, Buffer Overflows, sondern Ursachen bekämpfen wollen: Tunnelt WoL, Administration, Fernwartung und alles andere durch SSH. Und wer dringend WoL braucht, aber keinen SSH-Zugang herstellen kann, dafür aber eine Box mit Telephoniefunktion hat, kann es machen wie ich und unbenutzte ISDN- oder VoIP-Nummern via Callmonitor zum Aufwecken der Rechner zu benutzen: kein Interface = kein Ausnutzen von Buffer Overflows.

Ich ziehe mal aus der bisherigen Mehrheitsmeinung das Fazit: WoL-CGI auf Einzelport ist das geringere Übel, wenn unverschlüsselt. Das ist wohl wahr, und da offenbar viele es so benutzen, werde ich mir das höchstens zum Spaß privat so einrichten, daß ich alles in einem habe. Ich nutze ja sowieso meistens die Variante mit dem Telephon und ob meine SSH-Verbindung nun drei oder vier Ports tunnelt, ist im Grunde auch egal.

Danke für die bisherigen Meinungen, Ihr habt mir sehr geholfen. Das IPPF ist einfach klasse!

Nicht ganz falsch, shadow. Du hattest ja mal z.B. die Rudi-Shell einfach auf dem websrv von AVM laufen lassen, eine Idee, auf die ich gar nicht gekommen war. Funktioniert tatsächlich problemlos, ich habe es dann auch probiert. Das Thema, ob man den httpd, so klein er auch ist, überhaupt braucht, wäre mal eine Extra-Diskussion wert.