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

[ao]

Ideal wäre es, wenn ALLE WebServer (Ports 80,81,82) über nur EINEN externen Port 443 sich "tunneln" ließen.

Ich weiß, dass es technisch ohne Weiteres nicht geht mehrere Ports auf einen zu binden, aber vielleicht gibt es eine andere Möglichkeit, die "sekundären" WebIFs (z.B. 80,82) als Unterverzeichnis von dem primären (z.B. 81) einzubinden, dass man z.B. AVM WebIF unter

http://fritz.box:81/AVM/

erreichen könnte. Danach könnte man Port 81 über 443 routen.

Der Hintergrund ist, dass man in solchen Fällen sehr oft hinter einer Proxy sitzt und nur auf bestimmte Ports zugreifen kann...

Erstmal sorry für das fast full-quote aus diesem Thread, aber das ist einfacher, als es noch einmal zu beschreiben und scheint mir ein Thema für sich zu sein (dahei ein eigener Thread).

Ist Hermanns Vorschlag evtl. mittels Freetz umsetzbar?

 

[hermann72pb]

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

 

[McNetic]

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.

 

[ao]

Ah, squid ist gut. Aber das gibt ja (noch) gar nicht für Freetz. Wäre es möglich, das für Freetz / die FB zum Laufen zu bringen?
Hier gab's mal einen Thread dazu... Oder geht das evtl. mit tinyproxy oder privoxy?

 

[McNetic]

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.

 

[hermann72pb]

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

 

[McNetic]

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.

 

[hermann72pb]

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

 

[McNetic]

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 .

 

[RalfFriedl]

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

config FEATURE_HTTPD_PROXY
	bool "Enable support for reverse proxy"
	default n
	depends on HTTPD
	help
	  This option allows you to define URLs that will be forwarded
	  to another HTTP server. To setup add the following line to the
	  configuration file
	        P:/url/:http://hostname[:port]/new/path/
	  Then a request to /url/myfile will be forwarded to
	  http://hostname[:port]/new/path/myfile.

 

[hermann72pb]

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

MfG

 

[RalfFriedl]

make busybox-menuconfig

 

[hermann72pb]

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

 

[McNetic]

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.

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?

Ja, so müsste es funktionieren.

 

[ao]

Wow, dass es so klappen könnte, ist wirklich toll. Danke, Ralf, für die Idee.
Aber wie Hermann auch schon gefragt hat, komme ich mit der Kurzhilfe nicht zurecht. Wofür ist das P: ?
Und wofür ist "make busybox-menuconfig" nötig? Braucht man das, um die Änderungsmöglichkeiten überhaupt beim "make menuconfig" angeboten zu bekommen? Ich kannte "make busybox-menuconfig" bisher noch gar nicht.

 

[hermann72pb]

@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

 

[McNetic]

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.

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...

 

[RalfFriedl]

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]

Ah, verstehe, vielen Dank. Bzgl. der div. Sicherheitsrisiken habe ich das noch nicht alles durchblickt, aber es ist auf jeden Fall interessant überprüft zu werden - wenn ich dafür mal Zeit habe.

etwas OT:
Da ich eh dabei bin (und das auch noch fertig machen will), die diversen make Parameter (so nenne ich sie mal) im Wiki zu verewigen bzw. an einer Stelle zusammenzufassen, wollte ich hier noch fragen, welche Pakete denn ihre eigenen "menuconfigs" haben. Dazu habe ich nämlich keine Infos gefunden (ggf. nicht richtig danach gesucht, da ich mir dessen nicht bewusst war).

 

[Silent-Tears]

welche Pakete denn ihre eigenen "menuconfigs" haben.

busybox und der kernel denke ich.