Hallo,
ich versuche derzeit einen Reverse Proxy einzurichten. Die Installation des Apache und von Letsencrypt hat funktioniert. Auch erreiche ich die Startwebseite. Ich möchte jedoch alle anrufen zu http://localhost:8083/fhem oder einer anderen IP weiterleiten. Jedoch funktioniert das nicht.
So sieht die .conf aus
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName ****.org
ServerAdmin ****.de
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/****.org.error.log
CustomLog ${APACHE_LOG_DIR}/****.org.access.log combined
SSLCertificateFile /etc/letsencrypt/live/****.org/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/****.org/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
<Location /fhem>
ProxyPass http://localhost:8083/fhem
ProxyPassReverse http://localhost:8083/fhem
</Location>
<Directory />
RedirectPermanent / /fhem
</Directory>
<Proxy *>
AuthType Basic
AuthName "Password for FHEM Required"
AuthUserFile /etc/fhem-htpasswd
Require valid-user
Order deny,allow
Allow from all
</Proxy>
</VirtualHost>
</IfModule>
Auch das mit /permanent funktioniert nicht. Die Anfragen werden nicht an /fhem weitergeleitet sondern bleiben beim root Verzeichnis.
Gruß
TWART016
Hat niemand eine Idee?
Als ich es noch mit dem Apache laufen hatte, war es wie folgt eingerichtet:
ProxyRequests Off
ProxyVia On
RewriteEngine on
SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1
ProxyPass /fhem http://localhost:8083/fhem
ProxyPassReverse /fhem http://localhost:8083/fhem
Dein ProxyPass sieht nicht sauber aus, da das Dir fehlt
Unter /fhem stehen die Einträge bei mit Proxypass. Trage ich den Parameter /fhem in die Zeile mit ein, startet der Apache nicht mehr.
Wie sieht denn keine komplette conf Datei aus?
Seltsam ist, die Standardseite wird aufgerufen. Nur jede Änderung an meiner eigenen Datei bleibt ohne Wirkung.
die Standardseite wird aufgerufen
Wie meinst Du?
Es öffnet sich die "Apache2 Ubuntu Default Page" und nicht wie konfiguriert automatisch mit Parameter /fhem
/fhem läuft in einen Timeout.
Fehler: Netzwerk-Zeitüberschreitung
Auch die Authentication Abfrage erscheint nicht.
Hast Du mal auf der Maschine selber versucht fhem zu erreichen?
also z.B.
wget http://localhost:8083/fhem
w3mhttp://localhost:8083/fhem
curl http://localhost:8083/fhem
beliebiger anderen Shell-Browser eben so möglich (lynx etc)
Über wget und die Remote Adresse wird mir zumindest der HTML Code von FHEM angezeigt.
Wenn de Zugriff über /fhem in ein TimeOut läuft, aber die gleiche Maschine es lokal erreichen kann, stehe ich auf dem Schlauch ... nur wie geschrieben, habe (aus anderen Gründen) den Proxy ausgelagert und verwende einen nginx
Meine alte Config hatte ich zu "/etc/apache2/conf-enabled/fhem.conf" ausgelagert und dort:
#<Location /fhem>
# AuthType Basic
# AuthName "Beschraenkter Zugriff! Intranet!"
# AuthBasicProvider file
# AuthUserFile /var/www/passwd/htpasswd
# Require user xxxx
#
# Order allow,deny
# Allow from all
# Satisfy any
# Require all granted
#</Location>
ProxyPass /fhem http://127.0.0.1:8083/fhem
ProxyPassReverse /fhem http://127.0.0.1:8083/fhem
# vim: ts=4 filetype=apache
Ist im Apache überhaupt das proxy_module enabled und für die Authentication das auth_basic_module?
Zu prüfen mit apachectl -M
Loaded Modules:
......
auth_basic_module (shared)
......
authn_core_module (shared)
authn_file_module (shared)
authz_core_module (shared)
authz_host_module (shared)
authz_user_module (shared)
.....
proxy_module (shared)
proxy_connect_module (shared)
proxy_html_module (shared)
proxy_http_module (shared)
....
ssl_module (shared)
....
In der mods-enabled/proxy.conf (sym. Link auf ../mods-available/proxy.conf) stehen bei mir beide Anteile drinnen
<IfModule mod_proxy.c>
ProxyPass "/fhem" "http://localhost:8083/fhem"
ProxyPassReverse "/fhem" "http://localhost:8083/fhem"
.....
<Location /fhem>
AuthType Basic
AuthName "Der ServerName order sonst irgendein Hinweis"
AuthBasicProvider file
AuthUserFile "passwd_file"
Require valid-user
</Location>
.....
</IfModule>
Beim AuthUserFile ohne absoluten Pfad muss das "passwd_file" dann direkt unter /etc/apache2/ liegen
Darin enthalten die User mit verschlüsseltem PW.
Und weil man es nicht oft genug schreiben kann, in der ssl.conf dann mind. diese Einstellungen vornehmen
SSLCipherSuite HIGH:!RC4:!aNULL:!eNULL
# Zur Verhinderungg einer Downgrade Attacke.
# Der Server entscheidet welche CipherSuite genutzt werden soll
SSLHonorCipherOrder on
# Nur TLSv1.2 ist erlaubt
SSLProtocol -ALL +TLSv1.2
Zitat von: Patrik.S am 17 Januar 2018, 21:52:57
Ist im Apache überhaupt das proxy_module enabled und für die Authentication das auth_basic_module?
Zu prüfen mit apachectl -M
Das ist aktiviert
Loaded Modules:
core_module (static)
so_module (static)
watchdog_module (static)
http_module (static)
log_config_module (static)
logio_module (static)
version_module (static)
unixd_module (static)
access_compat_module (shared)
alias_module (shared)
auth_basic_module (shared)
authn_core_module (shared)
authn_file_module (shared)
authz_core_module (shared)
authz_host_module (shared)
authz_user_module (shared)
autoindex_module (shared)
deflate_module (shared)
dir_module (shared)
env_module (shared)
filter_module (shared)
mime_module (shared)
mpm_event_module (shared)
negotiation_module (shared)
proxy_module (shared)
proxy_html_module (shared)
proxy_http_module (shared)
rewrite_module (shared)
setenvif_module (shared)
socache_shmcb_module (shared)
ssl_module (shared)
status_module (shared)
In mods-enabled habe ich bisher noch nichts bearbeitet? Wird das dort zwingend benötigt?
Ich habe was eigenes in sites-available angelegt.
Zitat von: Patrik.S am 17 Januar 2018, 21:52:57
Und weil man es nicht oft genug schreiben kann, in der ssl.conf dann mind. diese Einstellungen vornehmen
Ich habe SSLProtocol all -SSLv3 durch SSLProtocol -ALL +TLSv1.2 ersetzt, trotzdem gleiches Verhalten
Man kann auch alle Einstellungen in einer Datei vornehmen, der Apache verstreut aber die Konfigurationen über viele Dateien, die zu einzelnen Modulen gehöhren.
Im Verzeichnisn ./mods-enabled sieht man nur einen symbolischen Link auf Dateien nach ../mods-available/
Also editiert man eingentlich die Dateien in mods-available, diese werden aber nur gelesen und genutzt, wenn das Modul eingeschaltet ist, eben "mods-enabled".
ZitatÜber wget und die Remote Adresse wird mir zumindest der HTML Code von FHEM angezeigt.
Wie ist das eigentlich zu verstehen?
Ein
wget http://localhost:8083/fhem Lokal
auf dem Server ist etwas anderes als ein wget Zugriff auf ein Remotesystem wget http://192.1......:8083/fhem
Ist in FHEM zufälligerweise selbst auch eine Passwortabfrage konfiguriert?
Lauscht FHEM nur auf localhost und ist somit nur auf dem Server erreichbar?
"define WEB FHEMWEB 8083
global" vs. "define WEB FHEMWEB 8083"
"attr WEB HTTPS 1" NICHT gesetzt?
"attr WEB basicAuth ......." NICHT gesetzt?
Wenn das alles nichts hilft, mal das Loglevel hochschrauben und reingucken.
OT:
Das SSL Protokoll Thema ist so zu verstehen:
SSLProtocol all -SSLv3 === Es sind
ALLE Protokole
erlaubt, die beim kompilieren vorhanden und eingeschaltet sind, aus dieser Liste wird dann nur das
SSLv3 entfernt ==> Am Ende ist hier TLSv1.0 TLSv1.1 und TLSv1.2 erlaubt (Wenn OpenSSL nicht anders kompiliert wurde)
SSLProtocol -ALL +TLSv1.2 === Es ist
NICHTS erlaubt (Minus "-"), nur
TLSv1.2 wird
als einziges explizit erlaubt (Plus "+") ==> Am Ende ist nur TLSv1.2 erlaubt
Zitat von: Patrik.S am 18 Januar 2018, 20:38:46
Wie ist das eigentlich zu verstehen?
Über wget wird bei mir eine Datei erstellt mit Namen fhem. In der Datei steht der HTML Code.
Zitat von: Patrik.S am 18 Januar 2018, 20:38:46
Ein wget http://localhost:8083/fhem Lokal auf dem Server ist etwas anderes als ein wget Zugriff auf ein Remotesystem wget http://192.1......:8083/fhem
Beides geht bei mir. Ich habe FHEM auf dem gleichen Server und einem anderen laufen.
Zitat von: Patrik.S am 18 Januar 2018, 20:38:46
Ist in FHEM zufälligerweise selbst auch eine Passwortabfrage konfiguriert?
Lauscht FHEM nur auf localhost und ist somit nur auf dem Server erreichbar?
"define WEB FHEMWEB 8083 global" vs. "define WEB FHEMWEB 8083"
"attr WEB HTTPS 1" NICHT gesetzt?
"attr WEB basicAuth ......." NICHT gesetzt?
Ist alles nicht gesetzt. Auch WEB ist 8083 global
Zitat von: Patrik.S am 18 Januar 2018, 20:38:46
Wenn das alles nichts hilft, mal das Loglevel hochschrauben und reingucken.
Meinst du verbose WEB auf 5?
Mit Loglevel hochschrauben meinte ich den Apache Server: "LogLevel debug"
Das wget bei die die Daten bekommt und diese in eine Datei schreibt hatte ich schon verstanden, es geht hier um deine Aussage
Zitatwget und die Remote Adresse
Denn ein wget http://localhost:8083/fhem ist etwas völlig anderes als ein wget http://remote_IP_Adresse:8083/fhem
ZitatWEB ist 8083 global
Ja kann man machen, aber warum dann einen Apache davorschalten, wenn man es im lokalen Netz auch direkt erreichen kann?
Lass mal das Script von dieser Seite laufen, es sammelt alle Konfigurationen zusammen
https://benincampus.blogspot.de/2015/10/show-complete-apache-config-file.html
Je nach System kann die Erste Zeile auch ruhig mit Python 3 laufen, damit funktioniert es auch.
Nur eine der drei Zeilen aussuchen:
#!/usr/bin/python
#!/usr/bin/python3.5
#!/usr/bin/python2.7Das Ergebnis zeigt dann die gesamte Konfiguration aus allen Include Dateien.
Dein Setup ist nirgendwo beschrieben.
1. wo läuft der Apache?
2. wo läuft FHEM?
3. Betriebssystem wo der Apache läuft?
4. ist da drauf die Firewall eingeschaltet?
iptables --listBevor Du die dann hier aber postet, unbedingt die Sensitiven Daten UNKENNTLICH machen!!!! (Passwort des SSL Private Key, etc ....)
Zitat von: Patrik.S am 19 Januar 2018, 16:01:41
Mit Loglevel hochschrauben meinte ich den Apache Server: "LogLevel debug"
Mit debug sieht es das Apache Error Log so aus.
[Sat Jan 20 21:27:20.831453 2018] [ssl:info] [pid 1133:tid 140502718732160] AH01914: Configuring server fqdn:443 for SSL protocol
[Sat Jan 20 21:27:20.831698 2018] [ssl:debug] [pid 1133:tid 140502718732160] ssl_engine_init.c(392): AH01893: Configuring TLS extension handling
[Sat Jan 20 21:27:20.837181 2018] [ssl:debug] [pid 1133:tid 140502718732160] ssl_util_ssl.c(443): AH02412: [fqdn:443] Cert matches for name 'fqdn' [subject: CN=fqdn / issuer: CN=Let's Encrypt Au$
[Sat Jan 20 21:27:20.837194 2018] [ssl:info] [pid 1133:tid 140502718732160] AH02568: Certificate and private key fqdn:443:0 configured from /etc/letsencrypt/live/fqdn/fullchain.pem and /etc/letsencrypt/live/t$
[Sat Jan 20 21:27:20.861725 2018] [ssl:info] [pid 1134:tid 140502718732160] AH01914: Configuring server fqdn:443 for SSL protocol
[Sat Jan 20 21:27:20.865182 2018] [ssl:debug] [pid 1134:tid 140502718732160] ssl_engine_init.c(392): AH01893: Configuring TLS extension handling
[Sat Jan 20 21:27:20.868106 2018] [ssl:debug] [pid 1134:tid 140502718732160] ssl_util_ssl.c(443): AH02412: [fqdn:443] Cert matches for name 'fqdn' [subject: CN=fqdn / issuer: CN=Let's Encrypt Au$
[Sat Jan 20 21:27:20.868119 2018] [ssl:info] [pid 1134:tid 140502718732160] AH02568: Certificate and private key fqdn:443:0 configured from /etc/letsencrypt/live/fqdn/fullchain.pem and /etc/letsencrypt/live/t$
[Sat Jan 20 21:27:20.871901 2018] [proxy:debug] [pid 1137:tid 140502718732160] proxy_util.c(1790): AH00925: initializing worker http://localhost:8083/fhem shared
[Sat Jan 20 21:27:20.871907 2018] [proxy:debug] [pid 1137:tid 140502718732160] proxy_util.c(1832): AH00927: initializing worker http://localhost:8083/fhem local
[Sat Jan 20 21:27:20.871913 2018] [proxy:debug] [pid 1137:tid 140502718732160] proxy_util.c(1867): AH00930: initialized pool in child 1137 for (localhost) min=0 max=25 smax=25
[Sat Jan 20 21:27:20.874280 2018] [proxy:debug] [pid 1138:tid 140502718732160] proxy_util.c(1790): AH00925: initializing worker http://localhost:8083/fhem shared
[Sat Jan 20 21:27:20.874287 2018] [proxy:debug] [pid 1138:tid 140502718732160] proxy_util.c(1832): AH00927: initializing worker http://localhost:8083/fhem local
[Sat Jan 20 21:27:20.874296 2018] [proxy:debug] [pid 1138:tid 140502718732160] proxy_util.c(1867): AH00930: initialized pool in child 1138 for (localhost) min=0 max=25 smax=25
[Sat Jan 20 21:31:50.051579 2018] [ssl:info] [pid 1364:tid 140675369101184] AH01914: Configuring server fqdn:443 for SSL protocol
[Sat Jan 20 21:31:50.051785 2018] [ssl:debug] [pid 1364:tid 140675369101184] ssl_engine_init.c(392): AH01893: Configuring TLS extension handling
[Sat Jan 20 21:31:50.052030 2018] [ssl:debug] [pid 1364:tid 140675369101184] ssl_util_ssl.c(443): AH02412: [fqdn:443] Cert matches for name 'fqdn' [subject: CN=fqdn / issuer: CN=Let's Encrypt Au$
[Sat Jan 20 21:31:50.052038 2018] [ssl:info] [pid 1364:tid 140675369101184] AH02568: Certificate and private key fqdn:443:0 configured from /etc/letsencrypt/live/fqdn/fullchain.pem and /etc/letsencrypt/live/t$
[Sat Jan 20 21:31:50.062372 2018] [ssl:info] [pid 1365:tid 140675369101184] AH01914: Configuring server fqdn:443 for SSL protocol
[Sat Jan 20 21:31:50.062573 2018] [ssl:debug] [pid 1365:tid 140675369101184] ssl_engine_init.c(392): AH01893: Configuring TLS extension handling
[Sat Jan 20 21:31:50.062761 2018] [ssl:debug] [pid 1365:tid 140675369101184] ssl_util_ssl.c(443): AH02412: [fqdn:443] Cert matches for name 'fqdn' [subject: CN=fqdn / issuer: CN=Let's Encrypt Au$
[Sat Jan 20 21:31:50.062766 2018] [ssl:info] [pid 1365:tid 140675369101184] AH02568: Certificate and private key fqdn:443:0 configured from /etc/letsencrypt/live/fqdn/fullchain.pem and /etc/letsencrypt/live/t$
[Sat Jan 20 21:31:50.064111 2018] [proxy:debug] [pid 1369:tid 140675369101184] proxy_util.c(1790): AH00925: initializing worker http://localhost:8083/fhem shared
[Sat Jan 20 21:31:50.064118 2018] [proxy:debug] [pid 1369:tid 140675369101184] proxy_util.c(1832): AH00927: initializing worker http://localhost:8083/fhem local
[Sat Jan 20 21:31:50.064129 2018] [proxy:debug] [pid 1369:tid 140675369101184] proxy_util.c(1867): AH00930: initialized pool in child 1369 for (localhost) min=0 max=25 smax=25
[Sat Jan 20 21:31:50.064457 2018] [proxy:debug] [pid 1368:tid 140675369101184] proxy_util.c(1790): AH00925: initializing worker http://localhost:8083/fhem shared
[Sat Jan 20 21:31:50.064463 2018] [proxy:debug] [pid 1368:tid 140675369101184] proxy_util.c(1832): AH00927: initializing worker http://localhost:8083/fhem local
[Sat Jan 20 21:31:50.064474 2018] [proxy:debug] [pid 1368:tid 140675369101184] proxy_util.c(1867): AH00930: initialized pool in child 1368 for (localhost) min=0 max=25 smax=25
Zitat von: Patrik.S am 19 Januar 2018, 16:01:41
Lass mal das Script von dieser Seite laufen, es sammelt alle Konfigurationen zusammen
https://benincampus.blogspot.de/2015/10/show-complete-apache-config-file.html
Ich hoffe, ich habe alle Daten anonymisiert
https://pastebin.com/LnTn5Ki6 (https://pastebin.com/LnTn5Ki6)
Zitat von: Patrik.S am 19 Januar 2018, 16:01:41
Dein Setup ist nirgendwo beschrieben.
1. wo läuft der Apache?
2. wo läuft FHEM?
3. Betriebssystem wo der Apache läuft?
4. ist da drauf die Firewall eingeschaltet? iptables --list
Ziel ist es, einen Reverse Proxy zu haben, um von extern u.a. auf FHEM zugreifen zu können. Ob der Reverse Proxy auf dem FHEM System laufen wird weiß ich derzeit noch nicht.
Derzeit habe ich einen FHEM auf einem System und den Reverse Proxy auf einem andere System. Alle Server sind Ubuntu.
Der Reverse Proxy hat zu Testzwecken ebenfalls eine FHEM Installation, um Kommunikationsprobleme nur mit anderen Servern auszuschließen.
Die Firewall ist überall aus.
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Fangen wir mal anders an (auch umd as Problem "einzukreisen):
Der Apache selber ist z.B. mit einer statischen Seite extern erreichbar?
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.
Blöde Frage: Nach jeder Änderung apache2 neu gestartet?
Du sprichst von "/permanent" ??? Das sagt mir nichts ... ??
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.
Zitat von: Patrik.S 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
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
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.
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 (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.
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.
Zitat von: Patrik.S 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.
Ich habe die Auth mittlerweile auch in die Location verlagert, da ich das nicht für alle URL's haben möchte.
Zitat von: Patrik.S am 01 Februar 2018, 17:37:42
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.
Zitat von: Patrik.S am 01 Februar 2018, 17:37:42
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?
Zitat von: Patrik.S am 01 Februar 2018, 17:37:42
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>
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]
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.
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.
Zitat von: Patrik.S am 02 Februar 2018, 21:23:15
* 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?
Zitat von: Patrik.S am 02 Februar 2018, 21:23:15
* 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.
Zitat von: Patrik.S am 02 Februar 2018, 21:23:15
*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.
Zitat von: Patrik.S am 02 Februar 2018, 21:23:15
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 ??
Zitat von: Patrik.S am 02 Februar 2018, 21:23:15
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.
Zitat von: Wernieman 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.
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, ...
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.
Zitat von: Patrik.S 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.
Das verstehe ich nicht ganz. Einfach das Directory raus nehmen?
<Directory />
RedirectPermanent / /fhem
</Directory>Zitat von: Patrik.S am 04 Februar 2018, 22:02:00
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×tamp=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×tamp=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×tamp=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×tamp=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)
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.
Mit dem Netzwerkmonitor wird die IP mit folgenden Pfaden aufgerufen:
http://ip/index.php/...
http://ip/core/...
http://ip/apps/...
Wenn ich https://FQDN/nextcloud aufrufe wird auf http geswitched. Entferne ich die Portweiterleitung wird die GUI von NC natürlich nicht mehr geöffnet. Die URL wird jedoch korrekt aufgelöst.
http://FQDN/index.php/login
Somit sieht es für mich aus, dass der Reverse Proxy die Anfrage gar nicht weiterleitet.
Im errorlog vom Apache dazu steht nichts, nur im Access Log.
öffentlicheIP - - [05/Mar/2018:16:06:08 +0100] "GET /nextcloud HTTP/1.1" 302 4160 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0"
"https://FQDN/nextcloud" --> "GET /nextcloud HTTP/1.1" 302--> der Apache zeigt's ja schon.
Nextcloud gibt als Antwort ein Redirect zurück, dass der Browser es unter http://FQDN/index.php/login versuchen soll
Die Nextcloud Installation musst Du jetzt anpassen.
Kurz Google angeworfen mit dem Suchbegriff "apache reverse proxy nextcloud /index.php/login"
Gleich die zwei ersten Treffer beschäftigen sich ja damit.
https://help.nextcloud.com/t/nextcloud-with-apache-reverse-proxy/19742/2
https://docs.nextcloud.com/server/11/admin_manual/configuration_server/config_sample_php_parameters.html
Bevor ich anfange. Meine nextCloud Installation ist derzeit intern noch nicht über https erreichbar. Ist das eine Voraussetzung? Wenn ja, muss ich mich erst darum kümmern.