Autor Thema: Reverse Proxy leitet Anfragen nicht weiter  (Gelesen 3987 mal)

Online Wernieman

  • Hero Member
  • *****
  • Beiträge: 4601
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #15 am: 21 Januar 2018, 16:24:12 »
Fangen wir mal anders an (auch umd as Problem "einzukreisen):
Der Apache selber ist z.B. mit einer statischen Seite extern erreichbar?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline TWART016

  • Sr. Member
  • ****
  • Beiträge: 783
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #16 am: 21 Januar 2018, 18:17:45 »
Ja, von extern komme ich per IP und DNS Namen auf den Apache, allerdings nur auf die "Startseite". Die Weiterleitung zu /fhem und das /permanent funktioniert nicht. Scheint, als ob meine eigene conf keine Auswirkung hat.
Intel NUC, Raspberry Pi,CUL 433+868, JeeLink, Uniroll, LD382/LD686 + WifiLight, Eventghost, Tablet UI, Homekit/Homebridge/Siri, Alexa, Squeezebox, Onkyo, MAX, Harmony, KODI, Winconnect, Geofancy, Nmap, Sysmon, Telegram

Online Wernieman

  • Hero Member
  • *****
  • Beiträge: 4601
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #17 am: 22 Januar 2018, 08:45:47 »
Blöde Frage: Nach jeder Änderung apache2 neu gestartet?

Du sprichst von "/permanent" ??? Das sagt mir nichts ... ??
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline Patrik.S

  • Jr. Member
  • **
  • Beiträge: 81
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #18 am: 23 Januar 2018, 22:30:43 »
Ich hoffe Du hast einfach nur zu viel anonymisiert, denn zwei <VirtualHost *:443> Einträge mit demselben "ServerName fqdn" wird wohl nicht funktionieren.
/etc/apache2/sites-enabled/000-default-le-ssl.conf
/etc/apache2/sites-enabled/fqdn.conf

Da Du ProxyPass und ProxyPassReverse innerhalb der Location Directive einsetzt, ist das Format so ok, es muss und darf kein zusätzliches "/fhem" rein, ansonsten kommt es beim Apache2 starten zum Fehler "ProxyPass|ProxyPassMatch can not have a path when defined in a location."

Dein RedirectPermanent 301 von "/" auf /fhem funktioniert bei mir Problemlos.





Offline TWART016

  • Sr. Member
  • ****
  • Beiträge: 783
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #19 am: 30 Januar 2018, 13:39:17 »
Ich hoffe Du hast einfach nur zu viel anonymisiert, denn zwei <VirtualHost *:443> Einträge mit demselben "ServerName fqdn" wird wohl nicht funktionieren.
/etc/apache2/sites-enabled/000-default-le-ssl.conf
/etc/apache2/sites-enabled/fqdn.conf
Stimmt, sobald man eine entfernt, funktioniert die Weiterleitung.

Wie macht man das am besten? Die 000-default-le-ssl.conf bearbeiten/löschen oder die fqdn.conf nicht anlegen?

Wie muss das Format für weitere Weiterleitungen aussehen?
/fhem
/nextcloud
/LMS
Intel NUC, Raspberry Pi,CUL 433+868, JeeLink, Uniroll, LD382/LD686 + WifiLight, Eventghost, Tablet UI, Homekit/Homebridge/Siri, Alexa, Squeezebox, Onkyo, MAX, Harmony, KODI, Winconnect, Geofancy, Nmap, Sysmon, Telegram

Offline Patrik.S

  • Jr. Member
  • **
  • Beiträge: 81
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #20 am: 30 Januar 2018, 20:19:04 »
Das bedeutet also, Dein initiales Problem ist gelöst.  :)

Wo Du die VirtualHost Konfiguration unterbringst, ist eigentlich "fast" egal.
Haupsache es ist nach einem Schema F, bei dem Du nicht ständig darüber nachdenken musst, in welcher Datei Du die Einstellungen vorgenommen hast.
Jedenfalls darf es in deinem Fall nur einmal gemacht werden.

Ich habe die SSL Einstellungen in die sites-enabled/default-ssl.conf gepackt und die Reserve Proxy Einstellungen in die Proxy Modul Konfiguration mods-enabled/proxy.conf

Weitere Ziele in Deinem Backend werden einfach mit weiteren <Location ...> Direktiven mit den entsprechenden IP_Adresssen Und Ports gesetzt
<Location /fhem>
      ProxyPass "http://IP_Adressse:8083/fhem"
      ProxyPassReverse "http://IP_Adressse:8083/fhem"
                AuthType Basic
                AuthName .........
                AuthBasicProvider file
                AuthUserFile "......."
                Require valid-user
 </Location>

 <Location /nextcloud>
        ProxyPass "http://IP_Adressse:Port/nextcloud"
        ProxyPassReverse "http://IP_Adressse:Port/nextcloud"
                AuthType Basic
                AuthName .........
                AuthBasicProvider file
                AuthUserFile "......."
                Require valid-user
 </Location>

 <Location /LMS>
        ProxyPass "http://IP_Adressse:Port/LMS"
        ProxyPassReverse "http://IP_Adressse:Port/LMS"
                AuthType Basic
                AuthName .........
                AuthBasicProvider file
                AuthUserFile "......."
                Require valid-user
 </Location>

Add-On: Wenn Du z.B. möchstest, das nur der User abcdef die Resourcen /nextcloud oder /LMS aufrufen darf, kannst Du anstatt "Require valid-user" dann auch "Require user abcdef" in der entsprechenden Location eintragen.

Offline TWART016

  • Sr. Member
  • ****
  • Beiträge: 783
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #21 am: 31 Januar 2018, 21:23:12 »
Das hat nun soweit funktioniert.

Beim Logitech Media Server und Openmediavault bekomme ich die Seite nicht angezeigt. Dazu habe ich das gefunden:
https://www.lxccu.com/doku.php?id=manuals:apache-reverse-proxy-manual&do=export_pdf
Wie kann ich das meine Konfig einfügen? Bei sieht der Aufbau ein wenig anders aus, als in dem Artikel.

Bei Nextcloud leite ich auf http://IP weiter. Anschließend wird mir im Browser jedoch auch nur http angezeigt, und nicht wie bei fhem https mit dem Zertifikat. Was stimmt da noch nicht?

Wenn ich den User & Passwort in der URL mitgeben, kann das z.B. mit Wireshark ausgelesen werden?

Besteht die Möglichkeit nur /fhem mit einem Zertifikat zu sichern, dass nur ein Client (PC, iPhone) mit einem installierten Zertifikat die Seite öffnen kann. Dann ggf. auch ohne Authentifizierung mit User+Passwort.
Intel NUC, Raspberry Pi,CUL 433+868, JeeLink, Uniroll, LD382/LD686 + WifiLight, Eventghost, Tablet UI, Homekit/Homebridge/Siri, Alexa, Squeezebox, Onkyo, MAX, Harmony, KODI, Winconnect, Geofancy, Nmap, Sysmon, Telegram

Offline Patrik.S

  • Jr. Member
  • **
  • Beiträge: 81
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #22 am: 01 Februar 2018, 17:37:42 »
Ja bei der Apache Konfiguration gibt es viele Wege nach Rom.
Man kann die ganzen Auth** Einstellungen zentral einstellen wie bei Dir, dann gelten sie für alle Ziele, oder wie bei mit pro Location einzeln.

Deine Nextcloud Weiterleitung sollte bei Verwendung von <Location /...> im Browser gar nicht zu einem Rückfall auf http führen.
Deine Listener auf Port 80 würde ich ausschalten. In deinem Router nur ein Portforwarding auf den SSL Port zum Apache einrichten

Wenn Du nur HTTP hast, wird alles im Klartext übertragen, auch dein user & password, darum ist https js so wichtig.

Sicher kannst Du nur für die Fhem Location ein Client Zertifikat benutzen, welches dem Apache präsentiert werden muss, damit man rein darf.
Dann sieht die Konfiguration aber anders aus und etwas komplizierter.
Im Client Gerät musst du dann das Zertifikat und priv. Schlüssel importieren und zum Server schicken. Der Apache muss das öffentliche Client Zertifikat dann in seinem Truststore im SSLCACertificateFile haben.
Damit es problemlos funktioniert empfehle ich hier auch ein Zertifikat aus der Letsencrypt CA zu  nutzen. Dann sind Client und Server aus der selben, macht es dann etwas einfacher.

Du kannst ja deine aktuelle Gesamt-Konfiguration nochmal abziehen und hochladen.

Offline TWART016

  • Sr. Member
  • ****
  • Beiträge: 783
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #23 am: 01 Februar 2018, 23:54:12 »
Ja bei der Apache Konfiguration gibt es viele Wege nach Rom.
Man kann die ganzen Auth** Einstellungen zentral einstellen wie bei Dir, dann gelten sie für alle Ziele, oder wie bei mit pro Location einzeln.
Ich habe die Auth mittlerweile auch in die Location verlagert, da ich das nicht für alle URL's haben möchte.


Deine Nextcloud Weiterleitung sollte bei Verwendung von <Location /...> im Browser gar nicht zu einem Rückfall auf http führen.
Deine Listener auf Port 80 würde ich ausschalten. In deinem Router nur ein Portforwarding auf den SSL Port zum Apache einrichten
So sollte es sein ja. Ich hatte bisher noch eine Umleitung im Router auf Port 80 auf den Server. Dann wird zu http umgeleitet. Sobald ich die Regel deaktiviere, kann ich von dem Server nichts mehr aufrufen.
Den Listener auf 80 habe ich auch aus sites-anable entfernt.
Die Config steht unten.


Wenn Du nur HTTP hast, wird alles im Klartext übertragen, auch dein user & password, darum ist https js so wichtig.
Also kann man bei htttps den User+Passwort nicht herausfinden?


Sicher kannst Du nur für die Fhem Location ein Client Zertifikat benutzen, welches dem Apache präsentiert werden muss, damit man rein darf.
Dann sieht die Konfiguration aber anders aus und etwas komplizierter.
Im Client Gerät musst du dann das Zertifikat und priv. Schlüssel importieren und zum Server schicken. Der Apache muss das öffentliche Client Zertifikat dann in seinem Truststore im SSLCACertificateFile haben.
Damit es problemlos funktioniert empfehle ich hier auch ein Zertifikat aus der Letsencrypt CA zu  nutzen. Dann sind Client und Server aus der selben, macht es dann etwas einfacher.
Problem derzeit ist, ich kann von extern nicht auf FHEM zugreifen. Ich würde gerne auf dem iPhone nur eine App (Link) öffnen, und damit FHEM öffnen. Nur kann ich seit der neuesten iOS Version keinen Link mehr mit User+Passwort zum Home-Bildschirm hinzufügen. Oder gibt es da einen Trick?

Hier anbei meine derzeitige Config:
<IfModule mod_ssl.c>
<VirtualHost *:443>
    ServerName fqdn
ServerAdmin e-mail
    DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/fqdn.error.log
    CustomLog ${APACHE_LOG_DIR}/fqdn.access.log combined
SSLCertificateFile /etc/letsencrypt/live/fqdn/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/fqdn/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
ProxyRequests Off
    ProxyVia Off
    ProxyPreserveHost On
<Location /fhem>
        ProxyPass http://192.168.178.11:8083/fhem
        ProxyPassReverse http://192.168.178.11:8083/fhem
        AuthType Basic
        AuthName "Password for FHEM Required"
        AuthUserFile /etc/fhem-htpasswd
        Require valid-user
        Order deny,allow
        Allow from all
    </Location>

<Location /nextcloud>
        ProxyPass http://192.168.178.12/
        ProxyPassReverse http://192.168.178.12/
    </Location>

<Location /lms>
        ProxyPass http://192.168.178.14:9000/
        ProxyPassReverse http://192.168.178.14:9000/
    </Location>

<Location /openmediavault>
        ProxyPass http://192.168.178.20
        ProxyPassReverse http://192.168.178.20
    </Location>

<Directory />
        RedirectPermanent / /fhem
    </Directory>

</VirtualHost>
</IfModule>
Intel NUC, Raspberry Pi,CUL 433+868, JeeLink, Uniroll, LD382/LD686 + WifiLight, Eventghost, Tablet UI, Homekit/Homebridge/Siri, Alexa, Squeezebox, Onkyo, MAX, Harmony, KODI, Winconnect, Geofancy, Nmap, Sysmon, Telegram

Offline Patrik.S

  • Jr. Member
  • **
  • Beiträge: 81
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #24 am: 02 Februar 2018, 21:23:15 »
Bei einer SSL gesichterten Verbindung kann man davon ausgehen, dass die Daten verschlüsselt sind und nicht ohne weitere entschlüsselt werden können.
Die Sicherheit steht und fällt aber mit den in den letzten Jahren gefundenen Problemen. CRIME, BEAST, ROBOT attack, RC4 Nutzung, SSLv3, TLSv1.0 & TLSv1.1, ....
Ist der RSA Schlüssel des Server Zertifikats nur 128 oder 256 Bit? Sind im Apache noch Cipher Suiten mit SHA-1 erlaubt, .....
Macht man seine TLSv1.2 Verbindung sicher, sollte es keine Probleme geben.

Deine Daten kann ich am Ende dann doch noch entschlüsslen, wenn ich Dich an meinem PC über meinem "vorkonfektioniert" Browser in dein System einloggen lasse und dabei gar nicht zuschaue welche Logindaten Du eingegeben hast. Ein Browser schließen bringt dann auch nichts mehr.

Also von daher... 100% Sicherheit gibt es nie, man kann es aber dem Gelegenheits Ganoven schwer machen!


Der Sicherheit wegen:

* sollte ein Router nur ein Portforwarding haben und zwar nur zum Apache auf den SSL Port.
DEr Apache geht dann über die verschiedenen Locations zu den anderen Systemen im Heimnetzwerk und verbirgt somit vieles
Man kann in der FritzBox auch noch relativ einfach ein VPN Zugang einrichten, ist aber eine andere Baustelle.

* Warum nur SSL abgesichert?
Solltest Du mal (im Urlaub) in einem öffentlichen WLAN unterwegs sein, könnte jemand mitschneiden was du in deinem Heimnetz machst.
Login Daten in Fhem oder im Media Center oder in deiner lokalen Cloud wären sonst ungeschützt

* Auch wenn es eine Komfortfunktion ist, solltest Du auf das RedirectPermanent verzichten. Dank IoT / www.shodan.io und anderer Portscanner würde deine Ip Adresse dem Angreifer sehr einfach zeigen, das es hinter der URI /fhem etwas gibt.
Wenn die Root "/" ins leere läuft, ist es für die Sicherheit von außen gesehen besser.

*Abschalten der Basic Authentication bei den anderen URIs ist keien gute Idee.
Sobald der Angreifer die URIs probiert, weil es Strings sind die "jeder" nutzt, würde er ohne weiter Abfrage zum Backend geroutet und sieht dann hoppla ein Media Server, eine Cloud, .....

Alles nur Paranoia?
Zu Zeiten wo das Analog/ISDN Modem den PC direkt mit dem Internet verbunden hatte, gab es keinen Tag an dem der Rechner keinen Portscan bemerkt hatte.
Jetzt wo es noch einen Router davor gibt, merkt man die "Angriffe" gar nicht mehr.
Erst das Portforwarding macht dein Netz wieder angeifbarer.

Mein Browser kann ein Username & Passwort im Passwortmanager abspeichern, das wird Apple ja wohl auch können im Safari?!? Ansonsten anderes Smartphone OS kaufen ;-)

Falls deine anderen Locations nicht funktionieren, ich hatte mal ein Problem mit einem Backend System, da musste die URL mit einem abschließenden Slash aufgerufen werden
Für den Apache ist eine "http://ipAdr:Port:/nextcloud" nicht das gleiche wie "http://ipAdr:Port:/nextcloud/"
Kann man mit diesen Einstellungen ändern, das es automatisch korrigiert wird
RewriteEngine on
RewriteRule ^/nextcloud$ /nextcloud/ [R]

« Letzte Änderung: 02 Februar 2018, 21:40:44 von Patrik.S »

Online Wernieman

  • Hero Member
  • *****
  • Beiträge: 4601
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #25 am: 03 Februar 2018, 11:29:01 »
Nur mal so zum "anfixen":
Habe vor 1 Woche bei hetzner für die Firma einen neuen Server aufgesetzt, incl. "Basishärten" durch fail2ban etc. Eine Prüfung am Ende hat ergeben, das innerhalb von 10 Minuten schon 20 Layenangriffe auf dem SSH-Port durchgeführt wurden.

IM DSL-Bereich ist es Ähnlich, was mir hier meine lokale Überwachung zeigt.

Abgekürzt:
Layen, bzw. Scriptangriffe dürften Täglich jeden von uns treffen und genau dagegen muß man sich schützen.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline TWART016

  • Sr. Member
  • ****
  • Beiträge: 783
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #26 am: 04 Februar 2018, 15:17:08 »
Dass es keine 100% Sicherheit gibt, sollte denke ich allen bewusst sein. Ich logge mich auch nur von meinen eigenen Geräten ein, daher der Gedanke mit den Client Zertifikaten.

* sollte ein Router nur ein Portforwarding haben und zwar nur zum Apache auf den SSL Port.
DEr Apache geht dann über die verschiedenen Locations zu den anderen Systemen im Heimnetzwerk und verbirgt somit vieles
Man kann in der FritzBox auch noch relativ einfach ein VPN Zugang einrichten, ist aber eine andere Baustelle.
Das ist auch mein Ziel. Blöderweise habe ich nur eine Speedport, die kein VPN unterstützt. VPN On Demand wäre sicherlich die ideale Lösung. Oder gibt es eine VPN Lösung nur über Web(browser) und ohne Client?

* Auch wenn es eine Komfortfunktion ist, solltest Du auf das RedirectPermanent verzichten. Dank IoT / www.shodan.io und anderer Portscanner würde deine Ip Adresse dem Angreifer sehr einfach zeigen, das es hinter der URI /fhem etwas gibt.
Wenn die Root "/" ins leere läuft, ist es für die Sicherheit von außen gesehen besser.
Damit hätte ich zunächst erstmal kein Problem, alles mit / zu versehen und RedirectPermanent zu deaktivieren.

*Abschalten der Basic Authentication bei den anderen URIs ist keien gute Idee.
Sobald der Angreifer die URIs probiert, weil es Strings sind die "jeder" nutzt, würde er ohne weiter Abfrage zum Backend geroutet und sieht dann hoppla ein Media Server, eine Cloud, .....
In dem Fall geht es erstmal nur um Nextcloud. Ein paar meiner Freunde nutzen das zum Teil auch. Dort finde ich 2 Authentifizierungen sehr ungeschickt. Nextcloud ist nach wie vor mit Benutzer + Passwort geschützt.

Mein Browser kann ein Username & Passwort im Passwortmanager abspeichern, das wird Apple ja wohl auch können im Safari?!? Ansonsten anderes Smartphone OS kaufen ;-)
Beim iPhone gibt es zwar eine Schlüsselverwaltung, aber beim Aufruf der Seite wird das bei mir nicht automatisch erkannt und eingeloggt. Ich muss das Schlüsselsymbol auswählen und den Eintrag auswählen + auf den Button einloggen klicken.
Erkennt Wireshark den User und Passwort in https://user:pw@fqdn.de ??

Falls deine anderen Locations nicht funktionieren, ich hatte mal ein Problem mit einem Backend System, da musste die URL mit einem abschließenden Slash aufgerufen werden
Für den Apache ist eine "http://ipAdr:Port:/nextcloud" nicht das gleiche wie "http://ipAdr:Port:/nextcloud/"
Kann man mit diesen Einstellungen ändern, das es automatisch korrigiert wird
RewriteEngine on
RewriteRule ^/nextcloud$ /nextcloud/ [R]
Wie in meinem Code oben zu sehen ist, habe ich bereits am Ende ein / eingetragen. Meine Nextcloud Instanz ist derzeit nur über http erreichbar. https läuft in einem Timeout. Kann es daran liegen?
Kann es an der config.php von nextcloud liegen?
https://help.nextcloud.com/t/nextcloud-with-apache-reverse-proxy/19742/3
https://docs.nextcloud.com/server/9/admin_manual/configuration_server/reverse_proxy_configuration.html

Beim Logitech Media Server und Openmedia Vault kann die Seite nicht richtig geladen werden? Woran könnte das liegen?
Openmedia: lädt nur den Hintergrund, Login Fenster nicht sichbar
LMS: Hinweis:
Logitech Media Server wird geladen... Seite wird aber nicht geladen.

Nur mal so zum "anfixen":
Habe vor 1 Woche bei hetzner für die Firma einen neuen Server aufgesetzt, incl. "Basishärten" durch fail2ban etc. Eine Prüfung am Ende hat ergeben, das innerhalb von 10 Minuten schon 20 Layenangriffe auf dem SSH-Port durchgeführt wurden.

IM DSL-Bereich ist es Ähnlich, was mir hier meine lokale Überwachung zeigt.

Abgekürzt:
Layen, bzw. Scriptangriffe dürften Täglich jeden von uns treffen und genau dagegen muß man sich schützen.
Ich denke die Frage nach dem absichern stellt sich nicht. Erstmal muss aber das grundlegende funktioneren (weiterleiten auf eine gewünschte Seite). Anschließend kümmert man sich um Sachen wie fail2ban, ...
Intel NUC, Raspberry Pi,CUL 433+868, JeeLink, Uniroll, LD382/LD686 + WifiLight, Eventghost, Tablet UI, Homekit/Homebridge/Siri, Alexa, Squeezebox, Onkyo, MAX, Harmony, KODI, Winconnect, Geofancy, Nmap, Sysmon, Telegram

Offline Patrik.S

  • Jr. Member
  • **
  • Beiträge: 81
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #27 am: 04 Februar 2018, 22:02:00 »
Beim RedirectPermanent meinte ich die URL ohne jeglichen Pfad nur https://ip:port oder https://ip:port/ und nicht jede Location mit einem abschließenden Slash zu versehen.

Wireshark kann die verschlüsselten Daten nicht einfach so entschlüsseln, der gesamte HTTP Traffic, auch der Header sind verschlüsselt. Dann könnte es ja sonst jeder.
Einfach mal selber probieren, der "TLS" Anteil ist nur Zeichensalat.

Der TLS Endpunkt spricht idealerweise die Hintergrundsysteme immer nur mit HTTP an. Warum deine Nextcloud nicht funktioniert, weiß ich nicht.
Sollte im Apache Error Log stehen oder einen Wireshark Mitschnitt machen.

Bei den beiden anderen Systemen könnte es sein, das zusätzlich zu dem Pfad noch andere geladen werden und diese nun durch diese Konfiguration nicht mehr gefunden werden können.

Auch hier würde Dir Wiresharek oder noch viel einfacher im Firefox die Entwicklerkonsole (Taste F12) sehr helfen zur Problemanalyse!
Einfach mal die Seite direkt aufrufen und nicht über den Apache und gucken ob zusätzlich zum dem Pfad noch was geladen wird.

Bsp: http://ip/lms aufrufen
das gibt dann Daten zurück von folgenden Locations:
http://ip/lms
http://ip/pics/
http://ip/cgi/
http://ip/fancydirectory/
http://ip/...../

Die aktuelle Apache Proxy Konfiguration weiß nämlich nicht, wohin z.B. die Anfrage auf http://ip/cgi/ reroutet werden soll.

Offline TWART016

  • Sr. Member
  • ****
  • Beiträge: 783
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #28 am: 05 Februar 2018, 00:08:38 »
Beim RedirectPermanent meinte ich die URL ohne jeglichen Pfad nur https://ip:port oder https://ip:port/ und nicht jede Location mit einem abschließenden Slash zu versehen.
Das verstehe ich nicht ganz. Einfach das Directory raus nehmen?
<Directory />
        RedirectPermanent / /fhem
    </Directory>


Der TLS Endpunkt spricht idealerweise die Hintergrundsysteme immer nur mit HTTP an. Warum deine Nextcloud nicht funktioniert, weiß ich nicht.
Sollte im Apache Error Log stehen oder einen Wireshark Mitschnitt machen.

Bei den beiden anderen Systemen könnte es sein, das zusätzlich zu dem Pfad noch andere geladen werden und diese nun durch diese Konfiguration nicht mehr gefunden werden können.

Auch hier würde Dir Wiresharek oder noch viel einfacher im Firefox die Entwicklerkonsole (Taste F12) sehr helfen zur Problemanalyse!
Einfach mal die Seite direkt aufrufen und nicht über den Apache und gucken ob zusätzlich zum dem Pfad noch was geladen wird.

Bsp: http://ip/lms aufrufen
das gibt dann Daten zurück von folgenden Locations:
http://ip/lms
http://ip/pics/
http://ip/cgi/
http://ip/fancydirectory/
http://ip/...../

Die aktuelle Apache Proxy Konfiguration weiß nämlich nicht, wohin z.B. die Anfrage auf http://ip/cgi/ reroutet werden soll.
Laut Entwicklertools werden bei Nextcloud mehrere URL's aufgerufen. Wie kann ich eine Wildcard setzen?
Im Apache Log erkenne ich auch nichts.
[Sun Feb 04 23:51:33.935118 2018] [ssl:info] [pid 6666:tid 140529064941312] [client ip:51207] AH01964: Connection to child 15 established (server fqdn:443)
[Sun Feb 04 23:51:33.935605 2018] [ssl:debug] [pid 6666:tid 140529064941312] ssl_engine_kernel.c(2096): [client ip:51207] AH02043: SSL virtual host for servername fqdn found
[Sun Feb 04 23:51:33.935622 2018] [core:debug] [pid 6666:tid 140529064941312] protocol.c(2208): [client ip:51207] select protocol from , choices=h2,http/1.1 for server fqdn
[Sun Feb 04 23:51:33.935631 2018] [ssl:debug] [pid 6666:tid 140529064941312] ssl_engine_kernel.c(2096): [client ip:51207] AH02043: SSL virtual host for servername fqdn found
[Sun Feb 04 23:51:33.937735 2018] [ssl:info] [pid 6667:tid 140528997799680] [client ip:51208] AH01964: Connection to child 87 established (server fqdn:443)
[Sun Feb 04 23:51:33.938032 2018] [ssl:debug] [pid 6667:tid 140528997799680] ssl_engine_kernel.c(2096): [client ip:51208] AH02043: SSL virtual host for servername fqdn found
[Sun Feb 04 23:51:33.938041 2018] [core:debug] [pid 6667:tid 140528997799680] protocol.c(2208): [client ip:51208] select protocol from , choices=h2,http/1.1 for server fqdn
[Sun Feb 04 23:51:33.938047 2018] [ssl:debug] [pid 6667:tid 140528997799680] ssl_engine_kernel.c(2096): [client ip:51208] AH02043: SSL virtual host for servername fqdn found
[Sun Feb 04 23:51:33.944447 2018] [ssl:debug] [pid 6666:tid 140529064941312] ssl_engine_kernel.c(2023): [client ip:51207] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
[Sun Feb 04 23:51:33.947754 2018] [ssl:debug] [pid 6667:tid 140528997799680] ssl_engine_kernel.c(2023): [client ip:51208] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
[Sun Feb 04 23:51:33.947890 2018] [ssl:debug] [pid 6666:tid 140529064941312] ssl_engine_kernel.c(354): [client ip:51207] AH02034: Initial (No.1) HTTPS request received for child 15 (server fqdn:443)
[Sun Feb 04 23:51:33.947984 2018] [authz_core:debug] [pid 6666:tid 140529064941312] mod_authz_core.c(835): [client ip:51207] AH01628: authorization result: granted (no directives)
[Sun Feb 04 23:51:33.948044 2018] [proxy:debug] [pid 6666:tid 140529064941312] mod_proxy.c(1160): [client ip:51207] AH01143: Running scheme http handler (attempt 0)
[Sun Feb 04 23:51:33.948055 2018] [proxy:debug] [pid 6666:tid 140529064941312] proxy_util.c(2160): AH00942: HTTP: has acquired connection for (192.168.178.12)
[Sun Feb 04 23:51:33.948060 2018] [proxy:debug] [pid 6666:tid 140529064941312] proxy_util.c(2213): [client ip:51207] AH00944: connecting http://192.168.178.12/ to 192.168.178.12:80
[Sun Feb 04 23:51:33.948065 2018] [proxy:debug] [pid 6666:tid 140529064941312] proxy_util.c(2422): [client ip:51207] AH00947: connected / to 192.168.178.12:80
[Sun Feb 04 23:51:33.948089 2018] [proxy:debug] [pid 6666:tid 140529064941312] proxy_util.c(2664): AH00951: HTTP: backend socket is disconnected.
[Sun Feb 04 23:51:33.948288 2018] [proxy:debug] [pid 6666:tid 140529064941312] proxy_util.c(2799): AH02824: HTTP: connection established with 192.168.178.12:80 (192.168.178.12)
[Sun Feb 04 23:51:33.948303 2018] [proxy:debug] [pid 6666:tid 140529064941312] proxy_util.c(2965): AH00962: HTTP: connection complete to 192.168.178.12:80 (192.168.178.12)
[Sun Feb 04 23:51:33.984076 2018] [proxy:debug] [pid 6666:tid 140529064941312] proxy_util.c(2175): AH00943: http: has released connection for (192.168.178.12)
[Sun Feb 04 23:51:35.654145 2018] [ssl:debug] [pid 6666:tid 140529031370496] ssl_engine_kernel.c(354): [client ip:51207] AH02034: Subsequent (No.2) HTTPS request received for child 19 (server fqdn:443)
[Sun Feb 04 23:51:35.654197 2018] [authz_core:debug] [pid 6666:tid 140529031370496] mod_authz_core.c(835): [client ip:51207] AH01628: authorization result: granted (no directives)
[Sun Feb 04 23:51:35.654223 2018] [proxy:debug] [pid 6666:tid 140529031370496] mod_proxy.c(1160): [client ip:51207] AH01143: Running scheme http handler (attempt 0)
[Sun Feb 04 23:51:35.654230 2018] [proxy:debug] [pid 6666:tid 140529031370496] proxy_util.c(2160): AH00942: HTTP: has acquired connection for (192.168.178.12)
[Sun Feb 04 23:51:35.654235 2018] [proxy:debug] [pid 6666:tid 140529031370496] proxy_util.c(2213): [client ip:51207] AH00944: connecting http://192.168.178.12/ to 192.168.178.12:80
[Sun Feb 04 23:51:35.654239 2018] [proxy:debug] [pid 6666:tid 140529031370496] proxy_util.c(2422): [client ip:51207] AH00947: connected / to 192.168.178.12:80
[Sun Feb 04 23:51:35.685910 2018] [proxy:debug] [pid 6666:tid 140529031370496] proxy_util.c(2175): AH00943: http: has released connection for (192.168.178.12)
[Sun Feb 04 23:51:40.662352 2018] [ssl:debug] [pid 6666:tid 140528981014272] ssl_engine_io.c(1017): [remote ip:51207] AH02001: Connection closed to child 19 with standard shutdown (server fqdn:443)
[Sun Feb 04 23:51:44.268346 2018] [proxy_http:error] [pid 6666:tid 140529056548608] (70007)The timeout specified has expired: [client 213.61.168.82:45753] AH01110: error reading response, referer: https://fqdn/fhem
[Sun Feb 04 23:51:44.268410 2018] [proxy:debug] [pid 6666:tid 140529056548608] proxy_util.c(2175): AH00943: HTTP: has released connection for (192.168.178.11)
[Sun Feb 04 23:51:44.268557 2018] [ssl:debug] [pid 6666:tid 140529056548608] ssl_engine_io.c(1017): [client 213.61.168.82:45753] AH02001: Connection closed to child 16 with standard shutdown (server fqdn:443)
[Sun Feb 04 23:51:44.268680 2018] [proxy_http:error] [pid 6666:tid 140529090119424] (70007)The timeout specified has expired: [client 213.61.168.82:9830] AH01110: error reading response, referer: https://fqdn/fhem
[Sun Feb 04 23:51:44.268713 2018] [proxy:debug] [pid 6666:tid 140529090119424] proxy_util.c(2175): AH00943: HTTP: has released connection for (192.168.178.11)
[Sun Feb 04 23:51:44.268872 2018] [ssl:debug] [pid 6666:tid 140529090119424] ssl_engine_io.c(1017): [client 213.61.168.82:9830] AH02001: Connection closed to child 12 with standard shutdown (server fqdn:443)
[Sun Feb 04 23:51:45.407714 2018] [ssl:info] [pid 6667:tid 140529182439168] [client 213.61.168.82:7587] AH01964: Connection to child 65 established (server fqdn:443)
[Sun Feb 04 23:51:45.407953 2018] [socache_shmcb:debug] [pid 6667:tid 140529182439168] mod_socache_shmcb.c(528): AH00835: socache_shmcb_retrieve (0x01 -> subcache 1)
[Sun Feb 04 23:51:45.407964 2018] [socache_shmcb:debug] [pid 6667:tid 140529182439168] mod_socache_shmcb.c(913): AH00851: shmcb_subcache_retrieve found no match
[Sun Feb 04 23:51:45.407966 2018] [socache_shmcb:debug] [pid 6667:tid 140529182439168] mod_socache_shmcb.c(538): AH00836: leaving socache_shmcb_retrieve successfully
[Sun Feb 04 23:51:45.407980 2018] [ssl:debug] [pid 6667:tid 140529182439168] ssl_engine_kernel.c(2096): [client 213.61.168.82:7587] AH02043: SSL virtual host for servername fqdn found
[Sun Feb 04 23:51:45.407983 2018] [core:debug] [pid 6667:tid 140529182439168] protocol.c(2208): [client 213.61.168.82:7587] select protocol from , choices=h2,http/1.1 for server fqdn
[Sun Feb 04 23:51:45.407988 2018] [ssl:debug] [pid 6667:tid 140529182439168] ssl_engine_kernel.c(2096): [client 213.61.168.82:7587] AH02043: SSL virtual host for servername fqdn found
[Sun Feb 04 23:51:45.409243 2018] [ssl:info] [pid 6667:tid 140529265710848] [client 213.61.168.82:40207] AH01964: Connection to child 64 established (server fqdn:443)
[Sun Feb 04 23:51:45.409492 2018] [socache_shmcb:debug] [pid 6667:tid 140529265710848] mod_socache_shmcb.c(528): AH00835: socache_shmcb_retrieve (0x01 -> subcache 1)
[Sun Feb 04 23:51:45.409504 2018] [socache_shmcb:debug] [pid 6667:tid 140529265710848] mod_socache_shmcb.c(913): AH00851: shmcb_subcache_retrieve found no match
[Sun Feb 04 23:51:45.409506 2018] [socache_shmcb:debug] [pid 6667:tid 140529265710848] mod_socache_shmcb.c(538): AH00836: leaving socache_shmcb_retrieve successfully
[Sun Feb 04 23:51:45.409517 2018] [ssl:debug] [pid 6667:tid 140529265710848] ssl_engine_kernel.c(2096): [client 213.61.168.82:40207] AH02043: SSL virtual host for servername fqdn found
[Sun Feb 04 23:51:45.409521 2018] [core:debug] [pid 6667:tid 140529265710848] protocol.c(2208): [client 213.61.168.82:40207] select protocol from , choices=h2,http/1.1 for server fqdn
[Sun Feb 04 23:51:45.409525 2018] [ssl:debug] [pid 6667:tid 140529265710848] ssl_engine_kernel.c(2096): [client 213.61.168.82:40207] AH02043: SSL virtual host for servername fqdn found
[Sun Feb 04 23:51:45.425687 2018] [ssl:debug] [pid 6667:tid 140529182439168] ssl_engine_kernel.c(2023): [client 213.61.168.82:7587] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
[Sun Feb 04 23:51:45.431744 2018] [ssl:debug] [pid 6667:tid 140529265710848] ssl_engine_kernel.c(2023): [client 213.61.168.82:40207] AH02041: Protocol: TLSv1.2, Cipher: ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
[Sun Feb 04 23:51:45.431828 2018] [ssl:debug] [pid 6667:tid 140529265710848] ssl_engine_kernel.c(354): [client 213.61.168.82:40207] AH02034: Initial (No.1) HTTPS request received for child 64 (server fqdn:443), referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.431892 2018] [authz_core:debug] [pid 6667:tid 140529265710848] mod_authz_core.c(809): [client 213.61.168.82:40207] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.431898 2018] [authz_core:debug] [pid 6667:tid 140529265710848] mod_authz_core.c(809): [client 213.61.168.82:40207] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.431965 2018] [authz_core:debug] [pid 6667:tid 140529265710848] mod_authz_core.c(809): [client 213.61.168.82:40207] AH01626: authorization result of Require valid-user : granted, referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.431971 2018] [authz_core:debug] [pid 6667:tid 140529265710848] mod_authz_core.c(809): [client 213.61.168.82:40207] AH01626: authorization result of <RequireAny>: granted, referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.432020 2018] [proxy:debug] [pid 6667:tid 140529265710848] mod_proxy.c(1160): [client 213.61.168.82:40207] AH01143: Running scheme http handler (attempt 0), referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.432031 2018] [proxy:debug] [pid 6667:tid 140529265710848] proxy_util.c(2160): AH00942: HTTP: has acquired connection for (192.168.178.11)
[Sun Feb 04 23:51:45.432037 2018] [proxy:debug] [pid 6667:tid 140529265710848] proxy_util.c(2213): [client 213.61.168.82:40207] AH00944: connecting http://192.168.178.11:8083/fhem?XHR=1&inform=type=status;filter=;since=1517784402.5300002;fmt=JSON&fw_id=57626&timestamp=1517784705306 to 192.168.178.11:8083, referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.432042 2018] [proxy:debug] [pid 6667:tid 140529265710848] proxy_util.c(2422): [client 213.61.168.82:40207] AH00947: connected /fhem?XHR=1&inform=type=status;filter=;since=1517784402.5300002;fmt=JSON&fw_id=57626&timestamp=1517784705306 to 192.168.178.11:8083, referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.432151 2018] [ssl:debug] [pid 6667:tid 140529182439168] ssl_engine_kernel.c(354): [client 213.61.168.82:7587] AH02034: Initial (No.1) HTTPS request received for child 65 (server fqdn:443), referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.432176 2018] [authz_core:debug] [pid 6667:tid 140529182439168] mod_authz_core.c(809): [client 213.61.168.82:7587] AH01626: authorization result of Require valid-user : denied (no authenticated user yet), referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.432242 2018] [authz_core:debug] [pid 6667:tid 140529182439168] mod_authz_core.c(809): [client 213.61.168.82:7587] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet), referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.432282 2018] [authz_core:debug] [pid 6667:tid 140529182439168] mod_authz_core.c(809): [client 213.61.168.82:7587] AH01626: authorization result of Require valid-user : granted, referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.432290 2018] [authz_core:debug] [pid 6667:tid 140529182439168] mod_authz_core.c(809): [client 213.61.168.82:7587] AH01626: authorization result of <RequireAny>: granted, referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.432311 2018] [proxy:debug] [pid 6667:tid 140529182439168] mod_proxy.c(1160): [client 213.61.168.82:7587] AH01143: Running scheme http handler (attempt 0), referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.432333 2018] [proxy:debug] [pid 6667:tid 140529182439168] proxy_util.c(2160): AH00942: HTTP: has acquired connection for (192.168.178.11)
[Sun Feb 04 23:51:45.432340 2018] [proxy:debug] [pid 6667:tid 140529182439168] proxy_util.c(2213): [client 213.61.168.82:7587] AH00944: connecting http://192.168.178.11:8083/fhem?XHR=1&inform=type=status;filter=;since=1517784402.434;fmt=JSON&fw_id=57603&timestamp=1517784705303 to 192.168.178.11:8083, referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.432348 2018] [proxy:debug] [pid 6667:tid 140529182439168] proxy_util.c(2422): [client 213.61.168.82:7587] AH00947: connected /fhem?XHR=1&inform=type=status;filter=;since=1517784402.434;fmt=JSON&fw_id=57603&timestamp=1517784705303 to 192.168.178.11:8083, referer: https://fqdn/fhem
[Sun Feb 04 23:51:45.432418 2018] [proxy:debug] [pid 6667:tid 140529265710848] proxy_util.c(2799): AH02824: HTTP: connection established with 192.168.178.11:8083 (192.168.178.11)
[Sun Feb 04 23:51:45.432447 2018] [proxy:debug] [pid 6667:tid 140529265710848] proxy_util.c(2965): AH00962: HTTP: connection complete to 192.168.178.11:8083 (192.168.178.11)
[Sun Feb 04 23:51:45.432624 2018] [proxy:debug] [pid 6667:tid 140529182439168] proxy_util.c(2799): AH02824: HTTP: connection established with 192.168.178.11:8083 (192.168.178.11)
[Sun Feb 04 23:51:45.432645 2018] [proxy:debug] [pid 6667:tid 140529182439168] proxy_util.c(2965): AH00962: HTTP: connection complete to 192.168.178.11:8083 (192.168.178.11)

Intel NUC, Raspberry Pi,CUL 433+868, JeeLink, Uniroll, LD382/LD686 + WifiLight, Eventghost, Tablet UI, Homekit/Homebridge/Siri, Alexa, Squeezebox, Onkyo, MAX, Harmony, KODI, Winconnect, Geofancy, Nmap, Sysmon, Telegram

Offline Patrik.S

  • Jr. Member
  • **
  • Beiträge: 81
Antw:Reverse Proxy leitet Anfragen nicht weiter
« Antwort #29 am: 26 Februar 2018, 20:59:17 »
Die drei Zeilen komplett rausnehmen:
<Directory />
        RedirectPermanent / /fhem
</Directory>

Dann ist durch einen bloßen Aufruf von außen mit https:/IP-Adresse nicht gleich ersichtlich, was sich hinter der IP Adresse verbirgt

Die User & Passwort Abfrage mit dem Text aus AuthName "Password for FHEM Required" zeigt dem Angreifer/Nutzer, das sich da was mit FHEM hinter verbirgt.
Kurze Suche nach FHEM im I-Net. Ahh eine Hausautomation, gleich mal digital ins Haus einbrechen.
Klar, wer aktiv nach FHEM Installationen sucht, macht einfach selber ein /fhem hinten dran, aber so ist es zumindest ganz minimal schwererm weil nicht sofort ersichtlich.

Den AuthName würde ich persönlich sowieso komplett im Text entfremden, damit man keine Rückschlüsse ziehen kann. Du weißt ja, das Du dich bei FHEM Einloggen willst/musst. Das müssen andere nicht wissen
AuthName "Das ist mein abgesicherter Serverbereich" ist da schon besser.
Für eventuelle Unterscheidungen und Zwangs Neueinloggen in andere "Sicherheitsbereiche" des Webservers, muss/kann man auch pro Location andere AuthName Strings vergeben.
Ein Login im /fhem Bereich loggt den User nicht automatisch im /nextcloud Bereich ein, dazu muss der Benutzer sein Daten neu eingeben.

Alles was bei /nextcloud noch zusätzlich hinten an der URL steht /nextcloud/.... wird vom Apache automatisch durchgereicht.
Schwieriger wird es bei parallel liegenden Pfaden
http://ip/nextcloud/
http://ip/cgi/
http://ip/fancydirectory/
http://ip/...../

Ich kann nur dringend empfehlen die Seiten im Heimnetz mal direkt ohne Apache aufzurufen und dabei im Browser mit <F12> in der Entwicklerkonsole den Netzwerkverkehr anzusehen, welche URLS alles geladen werden.
Diese Arbeit kann Dir keiner abnehmen.

Ich bin soweit raus aus der Sache, da ich hier nicht speziell weiterhelfen kann. Habe kein Nextcloud & Co.

 

decade-submarginal