alle Ports 80, 81, 82 (AVM, Freetz, WOL) über einen externen Port 443 tunneln

Ich hatte es ausprobiert, ao. So einfach geht es nicht. Schuld daran ist die Verlinkung auf cgi-s, die so verrückt verschachtelt ist, dass ich da kaum durchblicken kann. Insbesondere bei AVM Web-IF.

Ich hatte versucht die kompletten Verzeichnisse so zu verlinken, wie oben angesprochen, es reicht aber leider nicht, weil die dazugehörigen cgi-s sinngemäss 1-2 Etagen höher liegen (../../) und somit nicht angesprochen werden können, wenn man bloß die html-Verzeichnisse so verlinkt. Außerdem bin ich mir da auch mit Benutzerrechten nicht so ganz sicher.

Was eher gehen würde:

1. Alles unter den selben Verzeichnisen des Hauptwebservers packen (z.B. AVM-Webif). cgi-s zu cgi-s, htmls zu htmls usw. Man muss dabei natürlich aufpassen, dass die gleichen Namen nicht vorkommen. index.html von freetz und wol muss man dann in freetz.html und wol.html umbenennen, Unterverzeichnisse /freetz und /wol anlegen und dort ein symlink freetz/index.html -> ../freetz.html und wol/index.html -> ../wol.html anlegen. Dann dürfte es gehen.

oder

2. In Prinzip das gleiche wie 1., nur die Dateien nicht rüberschieben, sondern für jede einen Symlink anlegen. Sehr aufwendig und eigentlich nicht gerade wartungsfreundlich, aber, wenn man es will.

AVM-WebIF lässt sich mit dem httpd laufen. Ich benutze es für einen alternativen https-Zugang mit matrixtunnel. AVM-httpd läuft bei mir dann zusätzlich zum AVM-eigenem Webserver, nur auf einem anderen Port, sagen wir z.B. 5000. Matrixtunnel leitet dann die https-verschlüsselte Anfragen von einem anderen Port, z.B. 4000 auf 5000. In ar7.cfg kannst du dann wiederum eine beliebige Weiterleitung, z.B. 443 -> 4000 machen, und hast dann AVM-WebIF über matrixtunnel auf Port 443 von draußen. httpd kannst du so starten, dass er dich nach einem vollwertigen Usernamen und Pass fragt, wie es sich gehört. AVM-WebIF-Pass hätte man dann abschalten können, wäre es nicht diese dämliche Sperre der Wahlhilfe.

MfG

Die einfachste Möglichkeit wäre, einen Proxy (in der Konfiguration sog. reverse proxy) auf der Box laufen zu lassen, der abhängig von der aufgerufenen URL auf unterschiedliche Webserver weiterleitet. Sowas kann natürlich squid, sowas gibts als Apache-Modul, und evtl. können auch diverse kleinere Proxy-Server sowas. Das müsste man mal genauer nachsehen.

Ich habe mal ein Squid-Paket für die Box in den aktuellen Trunk eingebaut. Das scheint auch so weit zu laufen, allerdings ist das Binary noch sehr groß (ca. 1.8 MB), während das Binary bei Debian nur die Hälfte der Größe hat. Möglicherweise lässt sich über das configure-Script noch verschiedenes einstellen bzw. Optionen deaktivieren, womit man sowohl die Binary-Größe als auch u.U. den Speicherverbrauch im Betrieb reduzieren könnte. Es gibt da auf jeden Fall sehr viele Optionen. So oder so dürfte das nur was für Boxen mit großem Speicher sein.

Ob die alternativen Proxy-Lösung ähnliches können, weiss ich nicht. Das wäre sicher mal einen Versuch bzw. ein wenig Nachlesen wert.

aber wo ist dann denn der Vorteil gegenüber Apache? Mit Apache könnte man definitiv die Unterscheidung nach dem Namen machen, wie du es mit proxy vorgeschlagen hast. Es wäre direkterer Weg. Ich weiß allerdings nicht wie gut Apache auf der Box läuft und was gegenüber dem Standard-Apache von z.B. debian da gekürzt wurde.

MfG

Ich weiss nicht, welche Lösung für das angesprochene Problem in speicherverbrauchstechnischer Hinsicht das die Bessere ist. Ein einfacher, kleiner Proxy wäre wahrscheinlich die Beste. Nichtsdestotrotz mag vielleicht mancher auch so den Squid für irgendwas nutzen, und darum habe ich einfach das Paket erstellt.

ok, aber warum willst du es mit squid machen? Hast du das schon irgendwo anders gemacht/gesehen (nicht mit freetz)? Weißt du wie man dann squid einrichten muss, damit es geht? Ich hatte sowas ähnliches (mehrere DNS-Namen, diverse Ports) auf meinem debian-Server bei Strato gemacht, allerdings mit Apache. Von daher weiß ich, dass es mit apache grundsätzlich gehen sollte. Ob apache dafür irgendwelche Module braucht, die wahrscheinlich bei debian sowieso per see drin sind, weiß ich nicht. Aber, dass man sowas ähnliches auch mit squid machen kann, davon wusste ich bisher nicht.

MfG

Wie weiter oben beschrieben: Squid kann als reverse Proxy dienen, und wenn das nicht URL-abhängig geht, würde ich mich doch sehr wundern (weil das Feature dann nur wenig Wert hätte, und es wird vielfach produktiv eingesetzt).
Ich selbst weiss nicht, wie das geht (kann man sich aber sicher in 15 Minuten anlesen), und ich selbst will das auch überhaupt nicht machen. Ich hab einfach nur ein Paket zur Verfügung gestellt. Der Anwender kann jetzt damit machen, was er möchte .

Habt Ihr es schon mal mit dem httpd der Busybox versucht?

o nee, auf die Idee muss mal erstmal kommen. Kannst du auch bitte sagen, wie man die Option auf "y" setzen kann?

MfG

make busybox-menuconfig

angenommen, es würde funktionieren. Ich muss mich da noch in die Optionen von httpd einlesen, denn aus dieser Kurzhilfe bin ich nicht so ganz schlau, was dort dieses große P soll. Meine Frage ist nun die Verständnisfrage: darf man dort als hostname fritz.box eintragen? Schaut dann httpd nach seinem lokalen fritz.box, wenn man aus der Ferne darauf kommt? Funktioniert da überhaupt die Namensauflösung?

MfG

Der von mir beschrieben Angriff hat mit der Browsersicherheit nichts zu tun; es ist vielmehr so, daß jede beliebige Seite, die man aufruft, beliebiges von beliebigen anderen Seiten referieren darf (z.B. Bilder). Dabei kann einfach eine URL sein, die z.B. auf http://fritz.box:81/cgi-bin/rudi_shell.cgi?..... verweist. Der Browser wird dann einfach versuchen, diese URL aufzurufen; und wenn Du Dich während der Browsersession einmal am Freetz-WebIF angemeldet hattest, dann wird diese URL erfolgreich gefunden und ggfs. Befehle über Rudi-Shell ausgeführt oder Konfigurationeinstellungen geändert oder oder. Und Du merkst es noch nicht einmal.

hermann72pb schrieb:

Frage ist nun die Verständnisfrage: darf man dort als hostname fritz.box eintragen? Schaut dann httpd nach seinem lokalen fritz.box, wenn man aus der Ferne darauf kommt? Funktioniert da überhaupt die Namensauflösung?

Zum Vergrößern anklicken....

Ja, so müsste es funktionieren.

@McNetic: Danke für die Aufklärung. Ich teste mal das aus, wenn ich mal Zeit habe und verschicke mir z.B. Passwörter per e-mail... Bin gespannt, ob es klappt. Aaaber..
1. Das bedeutet, dass theoretisch jeder momentan davon betrofen ist. Es reicht einfach irgendeine unglückliche Seite aufzurufen...
2. Das geht nur, wenn du zuhause bist. Wenn du von draußen deine Seite aufrufst mit https:/meineexterneadresse.dyndns.org:81 , dann muss der Angreifer diese Adresse auch exakt wissen. Unmöglich ist es nicht, das wird aber für den Angreifer schon schwierig.


@ao: Ich habe Ralf schon verstanden und versuche es auszutesten. P: meine ich, hatte ich in der config-datei gesehen. Man muss es aber genau in man zu httpd nachlesen, welche Reihenfolge usw. Denn auch die Passphrase muss da irgendwie rein in die Optionen. ich schaue es mir an. Und "make busybox-menuconfig" ist nichts Ausergewöhnliches. Einige pakete haben eben ihre eigene menuconfigs.

MfG

hermann72pb schrieb:

1. Das bedeutet, dass theoretisch jeder momentan davon betrofen ist. Es reicht einfach irgendeine unglückliche Seite aufzurufen...
2. Das geht nur, wenn du zuhause bist. Wenn du von draußen deine Seite aufrufst mit https:/meineexterneadresse.dyndns.org:81 , dann muss der Angreifer diese Adresse auch exakt wissen. Unmöglich ist es nicht, das wird aber für den Angreifer schon schwierig.

Zum Vergrößern anklicken....

1. Ja. Ist natürlich grundsätzlich ein Problem von Weboberflächen; darum macht man Session Timeouts. Bei der HTTP Basic Authentication gibts aber leider keinen bzw. der müsste im Browser implementiert sein, was bei den Standardbrowser zumindest in der Standardkonfiguration nicht der Fall ist.
2. Ebenfalls ja, wobei natürlich das von Zuhause-Konfigurieren auch bei weitem der häufigste Fall ist.

Weil es nicht ganz ungefährlich ist, wird das Freetz Webinterface irgendwann in Zukunft auch auf session-basiert umgestellt werden...

Verwendet habe ich das bisher auch noch nicht.

Mit "make busybox-menuconfig" kann man die Option aktivieren, normalerweise ist das nicht der Fall. Falls es sich als nützlich erweist, kann man das aber auch in die Haupt-Config von Freetz einbauen, da gibt es ja inzwischen schon einige Busybox Optionen.

Das große P ist die Anweisung in der Config-Datei des httpd. Der httpd der Busybox verwendet in der Config keine Schlüsselwörter, sondern nur Buchstaben. Und das P steht dann wohl für Proxy.

ao schrieb:

welche Pakete denn ihre eigenen "menuconfigs" haben.

Zum Vergrößern anklicken....

busybox und der kernel denke ich.