Reverse Proxy

[martin.neu]

Wenn ich den Reverse Proxy in der smartVISU ausschalte funktionieren die Dienste. Kann es sein dass hier nginx ausgehend was blockt?

[smai]

Wird evtl. der ausgehende Verkehr auch durch eine Firewall blockiert? Das Gerät, auf welchem die smartVISU läuft, muss je nach Dienst per http oder https die Wetter- bzw. Kalenderdaten abrufen können.

[martin.neu]

Guten Abend!

muss mal vorab hier ein Lob aussprechen - super freundlich und super kompetent hier!

Hab mit lesen (fast) alles hin bekommen und nach ein paar Startschwierigkeiten die SmartVISU (2.9) hinter einem Reverse Proxy zum laufen gebracht - dh. Zugriff incl. schalten von außen funktioniert.
Einziges Problem: alle Anfragen vom Google Kalender (iCal) und Wetter (sowohl Wunderground als auch yr.no) liefern einen "read request failed".

Aufbau: smarthome.NG mit onkelandy image (1.4.2) ; reverse proxy mit nginx auf Raspberry (https://github.com/smarthomeNG/smart...ReverseProxy);
Evt eine Eigenheit bei mir: ddns auf das Modem (huigate von drei) und portweiterleitung (443) auf fritzbox und nochmals (443) zum Reverse Proxy (Ist so, weil die Geräte räumlich getrennt stehen und ich jeweils das wlan nutzen will)

Muss ich evt. noch weitere Ports weiterleiten oder an der nginx config was ändern?
Danke vorab für eure Hilfe!

[TCr82]

Naja, solange die Webseite HTTPS geschützt ist, muss man sich den Aufwand nicht an tun, schaden tut er aber auch nicht

[psilo]

TCr82 clientzertifikate sind mir lieber als basic auth. geht nur leider nicht bei jeden dienst... aber für die sv funzt es gut

[TCr82]

Also ich finde das spielt keine Rolle. Auch wenn das Getrennt ist - wenn etwas verwundbar wäre kommt der Böse Hacker trotzdem rein

Die goldenen Regeln sind eigentlich:

- Wenn möglich keinen Standardport verwenden. Ganz besonders kein Port 80 oder 8080 oder so. Https auf Port 443 ist auch nicht unbedingt zu empfehlen. Aber https wird zumindest jetzt *noch* nicht von vielen Scanner-Skripten abgesucht...

- Auf einem Webserver wenn es geht einen Passwortschutz über Basic Auth oder sowas verwenden, dann kann kein Hacker ein Skript angreifen, ausser er kennt das Passwort - natürlich sollte das dann auch ausreichend sicher sein - heisst nicht nur ein sicheres Passwort sondern auch einen sicheren Benutzernamen (also kein admin oder Vorname/Nachname oder etwas aus dem fqdn)

- wenn Skripte verwendet werden die ohne Basic-Auth zugreifbar sind, dann diese nicht in Standardverzeichnissen oder der Root hinterlegen (aka phpmyadmin/webmail oder sonstwas). Dann kann man auch mal ruhigen Gewissens ein Update verschlafen (aber nicht aus lassen). Und auch kein Index oder so auf der Root platzieren, sonnst wären natürlich die ganzen Bemühungen umsonnst.

- das Linux-Betriebsystem auf dem der Webserver läuft sollte aktuell und unter Support stehen und Aktualisierungen automatisch installieren (unter Debian/Ubuntu das Paket unattended-upgrades installieren und konfigurieren). Wer unbedingt MS als OS verwenden will, sollte kein Apache oder so einsetzten, da das nicht automatisch aktualisiert wird! Stattdessen sollte er halt IIS verwenden, wobei da auch PHP nicht aktualisiert wird... also am besten kein MS OS verwenden

- wenn möglich die Rechte des Webservers eingrenzen (AppArmor/SELinux)

Wenn man das Beachtet ist man eigentlich auf der sicheren Seite. Wer noch sicherer sein will der sollte Portknocking einsetzten oder gleich VPN - wobei das wieder dazu führt das die Akzeptanz schwindet und es eine unnötige bürde ist. Wie schon gesagt, solange man sich an die oberen Regeln hält kann ich Garantieren dass man sehr sicher fährt.

[psilo]

muss ich mal testen. bei mir sind untersch. kisten. auch aus gründen der sicherheit. mit physikalischer trennung ist mir wohler

[TCr82]

warum nicht den reverse proxy auch intern benutzen? Hab ich auch gemacht.
Die Anmeldung kann man ja für interne Zugriffe deaktivieren.
Und alles andere sollte auch kein Problem sein.. Muss sagen dass der Webserver auf dem die Visu läuft auch der Webserver ist der den Reverse Proxy bereitstellt. Deswegen bleibt es auch einfach was fehlersuche angeht.

[psilo]

TCr82 ja. wie gesagt, er geht dann immer auf port 80 oder 443, aber auf der lokalen ip (nicht via reverse proxy) ist es halt port 2424

[TCr82]

psilo - hast du es mal versucht den Server und Port in der SH Konfig der SV raus zu lassen? Wie smai schon schrieb, sollte das all deine Probleme lösen.

[smai]

weniger fehleranfällig

Das bezweifle ich. Du hast schon öfters bei einem Pull vergessen, eine deiner angepassten Dateien zu aktualisieren.

[psilo]

smai wäre vielleicht eine Idee ja. die eine Zeile im Treiber lokal bei mir zu "maintainen" ist jetzt aber auch nicht viel mehr Aufwand und weniger fehleranfällig, in Bezug darauf dass am Ende doch was offen im Netz steht. Du hast aber Recht.. LAN von WAN unterscheidbar machen könnte eklig werden.

[smai]

Die Logik ist relativ einfach:
Wenn kein Port für SHNG konfiguriert ist, wird derselbe benutzt, welcher in der URL der smartVISU verwendet wurde.
Es findet also keine Unterscheidung nach Quelle oder Ziel statt. Ich wüsste auch nicht, wie WAN oder LAN zu erkennen wäre, wenn müsste man da individuell IP-Ranges konfigurieren können.

Eine Möglichkeit wäre, dass du die smartVISU aus dem LAN per http aufrufst und aus dem WAN per https. Das läuft zwar trotzdem beides über den Reverse Proxy, die nicht unterstützten Security Sachen müsstest du dann aber nur für Port 443 aktivieren. Den Zugriff auf Port 80 sperrst du vom WAN (ist er hoffentlich eh, weil Authentication über eine unverschlüsselte Verbindung keinen Sinn macht).

[psilo]

doofe frage zur umsetzung: der port wäre in beiden fällen (lokal, remote) aber identisch oder? ich frage, weil ich bei mir den io_smarthome so patchen musste, dass er bei lanzugriff auf die 2424 und bei dyndns zugriff auf die 443 geht..

ah ich sehe gerade, der 8b97fe2446e1fdfd319213aca365ea76779069cb könnte das behoben haben.
wobei nein, eigentlich müsste das else als if vorangestellt werden... so dass der konfigurierte port nur greift, wenn das ganze per ws oder wss eingeht..

jetziger patch bei mir:

            if (!io.port) {
                // use port of current page if not defined and needed
                if (location.port != '') {
                    io.port = location.port;
                } else {                    
                    if (location.protocol == 'http:') io.port = '80';
                    if (location.protocol == 'https:') io.port = '443';
                    if (io.address == '192.168.178.100') io.port = '2424'
                }
            }

Evtl machts Sinn, für die Websockets einen LAN und einen WAN Port spezifizierbar zu machen? Ich brauch das so, da das Apple-Zeug in meinem Haushalt die ReverseProxy Security Sachen ja für Websockets nicht kann und daher nur im LAN bzw im VPN genutzt werden kann.

[smai]

Danke Thomas, ich habe den Pull Request eben gemerget.