HS hinter Apache2 Reverse Proxy mit https

[rjumper]

Hallo,

obwohl ich schon eine ganze Weile Mitglied bin, war ich bisher hier im Forum nur lesend aktiv. Als Privatperson betreibe ich den HS mehr oder weniger als Hobby, viel lesen und testen ist angesagt und schließlich will man ja nicht durch dumme Kommentare auffallen.

Jetzt stehe ich allerdings vor einem für mich bisher nicht lösbaren Problem: Ich betreibe den HS zu Testzwecken noch im privaten LAN und möchte ihn jetzt neben zwei anderen Webservern im Internet möglichst sicher veröffentlichen. Grundgedanke hierzu ist, den öffentlichen Datenverkehr über https abzuwickeln. Dazu bestehen die folgenden Voraussetzungen: Internetaccount mit variabler IP inkl. Webspace und Domain, DynDNS-Domain, Fritzbox mit Portforwarding Ports 80 und 443 auf einen Linux-Server mit Apache2-Webserver und 2 Virtual Hosts. Nachfolgend habe ich den geplanten Verlauf skizziert und dabei die tatsächlichen Namen/Daten durch Platzhalter ersetzt und hervorgehoben.

Ein Aufruf von http://www.meinedomain.de wird redirected auf http://www.meinaccount.dyndns.de, erreicht somit den Apache2-Webserver und wird beantwortet. Auf einer zurückgegebenen Website gibt es einen Link für einen privaten Bereich, der über https://sec.meinaccount.dyndns.de/webcontent/ (das sec steht für secured im Gegensatz zu www) mit einem selbstsignierten SSL-Zertifikat und Benutzer-Authorisierung angesprochen wird. Über mehrere Reverse-Proxy-Befehle (ProxyPass... und ProxyPassReverse...) des Apache2 sind nun folgende Bereiche erreichbar:

1. https://sec.meinaccount.dyndns.de/webcontent/ -> nicht weiterleiten sondern selbst beantworten per https
2. https://sec.meinaccount.dyndns.de/server2/ -> Anfrage durch Proxy per http an internen Server2 und Antwort durchleiten ins Internet per https
3. https://sec.meinaccount.dyndns.de/ -> Anfrage durch Proxy per http an HS und Antwort transparent durchleiten ins Internet per https

Von aussen ist somit nur der Linux-Server erreichbar. Unter Punkt 1 wird der Webinhalt des Linux-Servers im Unterverzeichnis /webcontent abgebildet. Punkt 2 bildet den Webinhalt von Server2 transparent im Unterverzeichnis /server2 ab, der Nutzer merkt nichts von der im Hintergrund stattfindenen Umleitung auf Server2. Punkt 3 bildet den HS im Root-Verzeichnis der Website (/) ab. Somit wird der Aufruf https://sec.meinaccount.dyndns.de/hs vom Proxy in den in der Gira-Doku genannten Aufruf http://ip-Adresse/hs umgesetzt und die Antwort über https ins Internet zurückgegeben.

Die Punkte 1 und 2 funktionieren einwandfrei, bei 3 (HS-über-Proxy-Variante) habe ich allerdings mein Problem: Gemäß Doku wird der HS angesprochen durch .../hs, .../hshtm, .../hsthm?Anmeldedaten, .../shs, .../shshtm, .../hswap.wml, .../hslist, .../hslist?Liste+Anmeldedaten und .../shslist.

Mit der Firmware RC2.2 vom 10.07.07 führten die Aufrufe .../hslist und .../shslist zu einem Proxy-Error 502, der Aufruf .../hslist?Liste+Anmeldedaten sowie alle anderen Aufrufvarianten funktionieren einwandfrei, auch alle Icons (htmico?..., htmbg?... usw.) werden richtig nachgeladen und angezeigt. Seinerzeit habe ich intensiv gegoogelt und bin auf einen kommentierten Bug im Apache2-Proxy-Modul gestoßen, wo diese Fehlermeldung erwähnt wird und von seltenen Fällen des Auftretens gesprochen wird. Ich habe den Fall zunächst zu den Akten gelegt, da ich mit Übergabe der Parameter Liste+Anmeldedaten die Listen aufrufen konnte.

Kurz vor Weihnachten bin ich dann über den Design-Generator gestolpert, bei dem unter anderem eine aktualisierte Version der Firmware als Voraussetzung angegeben ist. Also habe ich die neue Firmware (RC vom 07.12.07) eingespielt mit dem Ergebnis, dass ich jetzt überhaupt nicht mehr von außen auf die HS-Listen zugreifen kann (auch der Aufruf .../hslist?Liste+Anmeldedaten funktioniert jetzt nicht mehr). Alle anderen Aufrufe funktionieren weiterhin einwandfrei (Bei beiden Firmwareversionen funktionieren alle Aufrufe vom internen LAN sowohl über die HS-IP-Adresse als auch über den HS-Namen tadellos).

Daraufhin habe ich die Feiertage genutzt und wieder nach Lösungen gesucht. Den Apache2-Webserver gibt es in einer aktualisierten Version - habe ich aufgespielt - keine Veränderung. Allerdings gibt die neue Version im Error-Log jetzt zusätzlich den Grund des Proxy-Fehlers aus: "(70014) End of file found: proxy: error reading status line from remote server HS-Name, referer: https://sec.meinaccount.dyndns.de/hslist", der mir jedoch nicht weiterhilft.
Unter den Apache-Bug-Reports habe ich dann gefunden, dass diese Fehlermeldung bedeutet "TCP FIN was sent from server" und auf serverseitige Netzwerkprobleme oder ein Problem mit dem Server (hier HS) selbst hinweist. Allerdings wird auch von einer "race condition" gesprochen, die den Fehler sporadisch auftreten lassen könnte: Unmittelbar nach Abfrage durch Apache schließt der Backend-Server die Keepalive-connection und der Apache startet seine Proxy-Anfrage auf einer eigentlich schon toten Verbindung, Browser würden sich hier anders verhalten und ihre Anfrage ohne Parameter wiederholen.

Da der Fehler reproduzierbar immer bei /hslist und /shslist auftritt, bei allen anderen Aufrufen jedoch nicht, vermute ich zurzeit die Ursache beim HS, insbesondere, da sich durch Änderung der Firmware auch eine Änderung im diesbezüglichen Verhalten gezeigt hat. Unschuldig ist der Apache2 allerdings auch nicht, da es ja über Browser von intern funktioniert.

Trotzdem würde ich gerne den Weg über einen Proxy mit Verschlüsselung (https) beibehalten. Die Variante, den Zugriff über verschiedene Ports zu realisieren, kommt nicht in Frage, da ich z.B. in der Firma hinter einer Firewall sitze, die Anfragen nur über die Ports 80 und 443 zulässt.

Hat vielleicht irgendjemand hierzu weitere Ideen oder Lösungsansätze oder sind evtl. schon irgendwo ähnliche Probleme aufgetreten?

So, hoffe, jetzt ist es nicht zu lang geworden und ich habe mein Problem trotzdem einigermaßen verständlich rübergebracht...

Danke für jede weitere Anregung

Rolf

[AScherff]

ja, ein wenig lang zum lesen....

Ich denke, da sind einige "Denkfehler"... hier nur mal zwei

1. Linux-Server heißt nicht gleichzeitig "Sicher". Im Gegenteil: wird der Server nicht regelmaßig und damit meine ich wirklich alle paar Tage (zumindest für Kernal-Patches) gewartet, ist er "Unsicher".
2. Die Tatsache, das du "über" Server1 den Server2 ansprichst macht es nicht sicherer, da Server2 dennoch im öffentlichen Netz erreichbar ist und damit zumindest potentiell wieder angreifbar ist.

Was ich verstanden habe, Du willst den HS über HTTPS erreichen. Warum HTTPS, damit Dritte die Daten nicht mitlesen?? Du mußt über einen Proxy gehen (Firma), ok. geht doch. Wo ist Dein Problem? Hast Du die Befürchtung, das der HS angegriffen wird? Setze eine vernünftige Firewall dazwischen (ich empfehle ASTARO.DE).

Oder ich habe alles falsch verstanden....

[rjumper]

Danke für die schnelle Rückmeldung und Okay, ich versuch mal die Kurzform unter Berücksichtigung der Anmerkungen:

Vorhandener Webauftritt läuft zukünftig auf Server1: mit nur einer IP-Adresse und einem Port (80 für http) kann ich mit der Fritzbox lediglich einen Server von aussen zugänglich machen. Das ist der besagte Linux-Server. Ob sicher oder nicht ist für mein Problem zunächst egal. Stimme allerdings der Anmerkung zu Linux im allgemeinen voll zu. Aber auf dem Server läuft auch noch eine Firewall und eine Benutzer-Authentifizierung, sodass Server2 schon deutlich schwerer erreichbar ist. Aber auch Server2 können wir für die weitere Betrachtung aussen vor lassen.

Um jetzt zusätzlich zu Server1 den HS von aussen zugänglich zu machen, benötige ich meiner Meinung nach einen Reverse-Proxy. Da Apache eh schon läuft, möchte ich dessen Modul mod_proxy nutzen. Daher habe ich die Umleitung des Document-Root-Verzeichnisses über ProxyPass und ProxyPassReverse auf den HS vorgenommen und den eigentlichen Webauftritt in das Unterverzeichnis /webcontent verschoben und von der Umleitung ausgeschlossen. HTTPS für den HS wäre ein Goodie, muss aber nicht unbedingt sein. Daher habe ich eben mal schnell umgestellt auf http über Proxy und kurz getestet, allerdings mit dem gleichen Fehler:

Jetzt wird ein Aufruf http://www.meinaccount.dyndns.de/hs oder /shs korrekt beantwortet, es erscheint die Loginmaske des HS. War in der https-Version genauso. Der gleiche Aufruf mit /hslist oder /shslist führt zu dem beschriebenen Proxy-Error statt zur erwarteten Login-Maske für Listen. Dies ist mein Problem, welches ich gerne beseitigen würde. Eine Lösung über einen anderen Port mit direktem Anschluß als 2. Server scheidet wie im 1. Posting schon geschrieben aus.

Vielleicht ist diese Schilderung ja doch etwas leichter verständlich.

[RaK]

@rjumper: Kann dir leider nicht helfen, hab aber eine Frage an dich.

Hab meinen Misterhouse genauso zugänglich gemacht. Ich hab es bisher nur nicht geschafft intern http zu nutzen und extern unter einer https Adresse erreichbar zu sein. Wie hast du das gemacht?

Ich komme über http://myname.dyndns.org auf meine Linux Kiste und hab dort ueber apache einen reverse Proxy von http://myname.dyndns.org/mh auf die interne IP http://192.168.x.x:8080 (der Port wird nur intern für das Web Interface von Misterhouse genutzt).

Funktioniert soweit prächtig. Ich haette gerne extern nur https. Hast du da einen Tipp für mich? Gerne auch per PM.

[Michel]

Da du ja sowieso schon sowohl über eine Fritzbox als auch einen Linux-Server verfügst:

Richte Open-VPN entweder auf

• der Fritzbox, oder
• dem Linux-Server

ein.
Damit blieben die Varianten 1+2 weiterhin verfügbar und du bekommst neben einem Zugang in dein LAN auch einen gesicherten HS-Zugang.

[rjumper]

@RaK

Da die Beantwortung deiner Frage nicht so richtig in das Thema passt, hab ich dir soeben eine PM geschickt.

[rjumper]

@Michel

vom Prinzip her finde ich die Idee gut, obwohl ich bisher keine Erfahrung mit VPN habe. Allerdings gehe ich davon aus, dass ein Zugriff dann nur von externen Rechnern mit irgendeinem installierten VPN-Client möglich ist. Dadurch wird der Zugang dann wieder eingeschränkt, beispielsweise könnte ich aus der Firma nicht zugreifen, da kein VPN-Client verfügbar und bei mir auch nicht die Rechte vorhanden sind, einen solchen zu installieren. Ähnliches stelle ich mir an öffentlichen Zugangspunkten vor.

Andererseits funktioniert der Zugriff über meinen Weg mit /hs und /shs ja problemlos über den Proxy, egal ob http oder https. Lediglich Listen (/hslist oder /shslist) können nicht aufgerufen werden. Alllerdings sehe ich in der Rückgabe des HTML-Codes der HS-Seiten technisch keinen Unterschied zwischen den vier Aufrufvarianten (klar, es gibt unterschiedliche Eingabefelder, aber vom Prinzip her funktioniert es doch gleich oder?). Warum bricht also der Proxy-Server bei Listen-Abruf sofort mit Fehler ab noch ehe die Eingabemaske erscheint und alles andere funktioniert einwandfrei?

Gruß

Rolf

[Tru]

Von Apache verstehe ich zur Zeit noch mehr als von KNX. Dieser Thread motivierte mich jetzt mich doch noch zu registrieren.

Meine Vermutung: Die HTTP-Response-Header auf /hslist und /shslist könnten nicht standard-konform sein. Während Browser in der Regel sehr tolerant sind, nehmen es andere Softwarekomponenten wie mod_proxy oder Squid Proxy Server wesentlich genauer und reagieren mit Fehlern, wenns nicht schön stimmt.

Mangels KNX und HS kann ich das selbst nicht nachprüfen. Ich würde die fraglichen Aufrufe auf den HS mittels Tools wie wget oder curl machen und insbesondere die Header-Zeilen genauer untersuchen.

Gruss, Othmar

[EIB-Freak]

Grundsätzlich: Die Listen sind auch für den Externen Abruf freigegeben per PIN oder Passwort ?

[rjumper]

@EIB-Freak

ich habe seinerzeit extra einen Listenbenutzer angelegt, da mit der alten RC-Version (aus Juli 07) zwar der Aufruf .../hslist oder .../shslist nicht klappte, ich aber per Aufruf .../hslist?lst=LLL&user=uuu&pw=ppp die gewünschte Liste abrufen konnte. Außerdem geht der Aufruf per Browser im internen Netz über die interne IP oder den hinterlegten Namen des HS und der Proxy sollte eigentlich über seine interne Netzwerkkarte den gleichen Aufruf machen.

@Tru

zunächst einmal herzlich willkommen hier im Forum.

Deiner Meinung schließe ich mich sofort an, genau die gleiche Vermutung habe ich auch, insbesondere, da es mit der älteren Firmware ja zumindest zum Teil funktioniert hat (siehe oben). Allerdings bin ich jetzt nicht sicher, wie ich weiterkomme (Header auswerten?). Die heruntergeladenen Dateien hatte ich mir ganz am Anfang schon mal angeschaut (nach Aufruf im Browser auf Quelltext umgeschaltet) und keine Auffälligkeiten bemerkt.

Habe aber sofort den folgenden Test unternommen:

1. wget http://IP_des_HS/hs liefert:
HTTP-Anforderung gesendet, warte auf Antwort...200 OK
Länge: nicht spezifiziert [text/html]

2. wget http://IP_des_HS/hslist liefert:
HTTP-Anforderung gesendet, warte auf Antwort...200 Keine Header, vermutlich ist es HTTP/0.9
Länge: nicht spezifiziert

3. wget http://IP_des_HS/shslist wie 2.

Super Tip mit dem wget

Habe ich jetzt das Problem gefunden? Sind es die fehlenden Header. Gehe ich dann Recht in der Annahme, dass nur die Fa. DACOM helfen kann (Firmwareanpassung?)

Grüsse aus dem Ruhrgebiet

rjumper

[Tru]

Ja, ich glaube schon, dass du das Problem gefunden hast. Aber um ganz sicher zu gehen würde ich gerne sehen (am besten über PM), was du bekommst wenn du folgenden Befehl verwendest:
curl -v -o /dev/null http://IP_des_HS/hslist
oder
wget -S http://IP_des_HS/hslist

Als erstes müsste eine saubere Response-Zeile in der Art von "HTTP/1.1 200 OK" erscheinen. Ich kenne jetzt den HTTP-RFC nicht genau auswendig, aber dann sollten auch noch einige obligatorische Header-Felder kommen, mindestens Content-Type und ich glaube auch Content-Length ist obligatorisch. Anschliessend an eine Leerzeile kommt dann der Body, also das Dokument. Wenn das nicht alles sauber erscheint, dann wird das mod_proxy nichts damit anfangen können.

Gruss, Othmar

[rjumper]

@Tru

Nochmal Danke für deine Hilfe (auch per PM).

@Alle

Ursache meines Problems ist gefunden, aber noch keine Lösung

kurze Zusammenfassung:

habe also den Befehl wget -S http://ip-hs/hslist ausprobiert mit folgender Bildschirmausgabe:

Verbindungsaufbau zu ... verbunden
HTTP Anforderung gesendet, warte auf Antwort...
Länge: nicht spezifiziert

[ <=> ] 487 --.-- K/s

Da ich nicht erkannt habe, was Tru mit diesen Angaben anfangen kann oder will (da steht ja fast nichts) habe ich nochmal alternativ den Befehl wget -S http://IP-HS/hs benutzt und ich denke mal, jetzt ist alles klar. Hier erscheint nämlich die folgende Ausgabe (ein richtiger Header):

Verbindungsaufbau zu ... verbunden
HTTP Anforderung gesendet, warte auf Antwort...
HTTP/1.0 200 OK
Connection: close
Cache-Control: no-cache, must-revalidate
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Content-Type: text/html; charset = ISO-8859-1
Länge: nicht spezifiziert [text/html]

[ <=> ] 702 --.--K/s

Die erste Antwort (/hslist) ist nach Tru's Aussage absolut nicht RFC-konform. Ein toleranter Browser kann das wohl verarbeiten, mod_proxy und vermutlich die meisten anderen Proxies aber nicht. Damit ich mit Apaches mod_proxy eine Chance habe, bleibt wohl nur, das DACOM hier nachbessert.

Also, falls einer von DACOM hier mitliest...

[makki]

Ich halte das mit dem reverse-proxy für einen durchaus brauchbaren Ansatz..

Zum eigentlichen Problem kann ich (mangels HS, immernoch) nicht viel mehr als das bereits geschriebene sagen, aber das scheint ja eh schon eingegrenzt.
So ein mod_proxy ist erheblich pingeliger als ein Browser, genau hier findet man aber ein sehr gutes Beispiel dafür warum man auf die Idee kommen kann, den HS per reverse-proxy abzuschotten..
So ganz grundlegend hatte ich ziemlich dieselbe Idee für einen sicheren externen Zugriff auf den HS (und andere interne Dienste/Server wie NAS, Webcam etc.)


Makki

[touareg]

... da hänge ich mich mal dran

Hallo,

auch ich versuche den HS hinter einem reverse proxy (ebenfalls Apache) zum Laufen zu bekommen und kann mich dem Wunsch von rjumper nur anschließen.

... und ich könnte mir vorstellen, DASS einer von Dacom mitliest

[babel]

Den HS hinter einen Reserve Proxy zu stellen steht auch noch auf meiner TODO Liste.

Und wenn jetzt einer fragt warum Reserve Proxy und nicht direkt. Es gibt nicht nur einen Dienst den ich gerne hinter https://<dyndns.org> erreichen würden. Dort horcht schon mein Wiki, ein OTRS, ein Horde und ein VDR. Und der HS wäre nur ein weiterer Dienst, daher braucht es den Reserve Proxy. Einfach einen anderen Port benutzen und darüber die Dienste zu verteilen ist auch keine prima Idee, da in vielen Firmen (zu Recht) SSL nur auf Port 443 erlaubt ist.