NEWS
IoBroker (und vis) über ReverseProxy
-
@Marc_St
Ich hätte den selben Wunsch: Verwendung der in IO-Broker eingebauten Authentifizierung samt unterschiedliche Berechtigungen für unterschiedliche User - und das über einen Apache reverse proxy.Geht das? Hat das schon jemand geschafft? Ich stehe ziemlich an, und auch ohne Authentifizierung bin ich mit der aus diesem Thread hervorgegangenen Doku auf https://www.iobroker.net/docu/index-303.htm?page_id=5082&lang=de bin leider bisher nicht sehr weit gekommen...
-
@robotastic
Nach langer Zeit wollte ich heute mal wieder schauen, ob sich hier was getan hat und ich danke dir für deine Beispielkonfiguration.
Wundersamerweise funktioniert nun meine alte Konfiguration, ich nehme an, dass es irgendwelche Updates bei iobroker gab, die das verbessert hat.Mein Problem waren immer die Websocket-Verbindungen über die Pfade ".../socket.io/". Leider finde ich dazu in deiner Konfiguration nichts.
Anbei noch meine aktuelle Konfiguration:
server { listen 443 ssl; server_name myhost.de; server_tokens off; ssl_certificate ./fullchain.pem; ssl_certificate_key ./privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam ./ssl-dhparams.pem; location / { proxy_pass http://ioBroker:8082; proxy_set_header Host $http_host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; satisfy any; auth_basic "Access Restricted"; auth_basic_user_file .htpasswd; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_http_version 1.1; } #location /socket.io { #try_files $uri $uri/ @websocket; #} #location @websocket { # proxy_pass http://ioBroker:8082/socket.io/; # proxy_http_version 1.1; # proxy_set_header Upgrade $http_upgrade; # proxy_set_header Connection "upgrade"; #} location /socket.io/socket.io.js { #proxy_set_header Upgrade $http_upgrade; #proxy_set_header Connection "Upgrade"; #proxy_http_version 1.1; #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #proxy_set_header Host $host; proxy_pass http://ioBroker:8082/socket.io/socket.io.js; } location /socket.io { proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; proxy_http_version 1.1; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $host; proxy_pass http://ioBroker:8082/socket.io; } }
-
Hallo
Ich nehme mal den alten Thread aus der Versenkung.
Ich habe den apache2 reverse Proxy nach dieser Anleitung installiert:
https://www.iobroker.net/docu/index-303.htm?page_id=5082&lang=de
Das ist doch das, worüber hier diskutiert wird, oder?
Wenn ich mich auf domain.de/vis/... einlogge, springt der Dialog zu domain.de/login/index.html?href=%2Flogin, was natürlich nicht geht, da domain.de/vis/login richtig wäre ...
Kann mir da jemand behilflich sein oder gar eine aktuellere Anleitung empfehlen?Ach ja, ich benutze die Ports 81 und 444, da 80 und 443 von deCONZ besetzt sind.Edit:
Problem gelöst. Habe nun auch nginx installiert. -
Kann bitte noch einmal jemand eine aktuell nginx Konfiguration posten.
Meine Vis hinter dem ReverseProxy behauptet immer sie hätte keine Connection.
Ich bin schon etwas verzweifelt.
Milraun
-
Hier meine config (in /etc/nginx/sites-available ). Wobei mein ioBroker Server die interne IP 192.168.1.251 hat. Die musst Du auch anpassen.
An 2 Stellen muss Du Deine Dyn-DNS eintragen, wenn Du von extern zugreifen willst (wegen dem SSL Zertifikat).
Den Pfad zu den SSL Keys und htpasswd nicht vergessen anzupassen. Let's encrypt brauch ich Dir ja nicht zu erklären
Meine Config hat zusätzlich eine htaccess (zusätzliche Passwortabfrage) drin und lässt mich von auswärts nur in das vis Verzeichnis.
Ich habe die Ports 81 und 444 verwendet, weil 80 und 443 von deCONZ benutzt wird.map $http_upgrade $connection_upgrade { default upgrade; '' close; } auth_basic "Nur fuer mich"; auth_basic_user_file /etc/nginx/.htpasswd; # Pfad anpassen allow yy.yy.0.0/16; # IP Range yy.yy. zulassen allow xx.xx.xx.xx; # Einzelne zugelassene IP deny all; server { listen 81; server_name meine_dyndns.net; # hier deine DYN-DNS return 301 https://$host$request_uri; } # SSL configuration server { listen 444 ssl; server_name meine_dyndns.net; # hier deine DYN-DNS # return 301 https://$server_name$request_uri; ssl_certificate /etc/sslzertifikat/fullchain.pem; # Pfad anpassen ssl_certificate_key /etc/sslzertifikat/privkey.pem; # Pfad anpassen # Improve HTTPS performance with session resumption ssl_session_cache shared:SSL:10m; ssl_session_timeout 5m; # Enable server-side protection against BEAST attacks ssl_prefer_server_ciphers on; ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:!ADH:!AECDH:!MD5; # Disable SSLv3 ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Diffie-Hellman parameter for DHE ciphersuites ssl_dhparam /etc/sslzertifikat/dhparams.pem; # Pfad anpassen # Enable HSTS (https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security) add_header Strict-Transport-Security "max-age=63072000; includeSubdomains"; # rewrite_by_lua_file /etc/nginx/lua/htaccess.lbc; # Enable OCSP stapling (http://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox) ssl_stapling off; ssl_stapling_verify off; ssl_trusted_certificate /etc/sslzertifikat/fullchain.pem; # Pfad anpassen resolver 8.8.8.8 8.8.4.4 valid=300s; resolver_timeout 5s; location /vis { proxy_pass http://192.168.1.251:8082/vis; proxy_set_header Host $host; proxy_redirect http:// https://; proxy_http_version 1.1; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } location /login { proxy_pass http://192.168.1.251:8082/login; proxy_set_header Host $host; proxy_redirect http:// https://; proxy_http_version 1.1; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } location /lib { proxy_pass http://192.168.1.251:8082/lib; proxy_set_header Host $host; proxy_redirect http:// https://; proxy_http_version 1.1; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } location /socket.io { proxy_pass http://192.168.1.251:8082/socket.io; proxy_set_header Host $host; proxy_redirect http:// https://; proxy_http_version 1.1; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } }
Hier noch die Links, welche ich benutzt habe:
nginx reverse proxy anleitung:
https://bloggerbu.de/reverseproxy/
htaccess in nginx anleitung:
https://www.cyberciti.biz/faq/nginx-password-protect-directory-with-nginx-htpasswd-authentication/
IP range anleitung:
https://ubiq.co/tech-blog/how-to-whitelist-ip-in-nginx/
Ich hoffe, das hilft Dir etwas weiter
-
Auch über ein Reverse-Proxy ist der iobroker offen im Internet nicht sicher.
Wenn ihr unbedingt meint, dann den Rechner so absichern, das man von da nicht auch noch ins restliche Netz kommt (demilitarisierte Zone mit gut konfiguriertem Firewall zum restlichen Netz.
Idealerweise dort dann auch keine Standardports nutzen, die jeder schon kennt und weitere Angriffsvektoren bieten. -
@oliverio Mir geht es eher darum alle Dienste unter einem Port zu erreichen, um keine Probleme mit cross origin policies zu bekommen. Z.B. bei der Nutzung von Grafana-Charts in vis.
Oder gibt es da eine einfachere Lösung?
-
@milraun
Nein zu Hause für das lokale netz ist das vollkommen in Ordnung.
Ich hab da oben nur was von dyndns gelesenManche denken reverse proxy oder gar die ssl Verschlüsselung schützen das heimische Netz.
Reverse Proxy reduziert zwar den Angriffsvektor, macht halt nicht komplett sicher
Und wenn man sich dann mit der config nicht gut auskennt dann ist es halt doch nur eine scheinbare Sicherheit -
Muss ich in den admin-Einstellungen unter Reverse-proxy etwas eintragen?
-
@milraun
Ich hab da nichts drin.