Hallo Leute, um mein BHKW per WLAN zu steuern hab ich einen ESP-01S als Webserver programmiert, welcher Befehle über den UART rausgibt und den Antwort-String auf der Webseite darstellt. Das geht erstaunlich gut. Um das BHKW übers Internet anschalten zu können, hätte ich dann doch gerne einen Passwortschutz. Das könnte zwar man über einen "magischen Parameter" in der URL bewerkstelligen. Etwas eleganteres wäre aber schon wünschenswert. (Textfeld fürs Passwort z.B.). Wäre für eine Gehilfe sehr dankbar. Bernd
:
Bearbeitet durch User
Ich würde das nicht direkt über das Internet erreichbar haben wollen. Richte doch besser den VPN Zugang ein. Ist mit Sicherheit sicherer und du kannst dir das Passwort für den ESP sparen.
N. M. schrieb: > Ist mit Sicherheit sicherer Zunächst mal ist mit Sicherheit aufwendiger. Davor steht die Frage welche Sicherheit überhaupt nötig ist.
N. M. schrieb: > Ich würde das nicht direkt über das Internet erreichbar haben wollen. > Richte doch besser den VPN Zugang ein. Das sehe ich auch so. Eine einfache HTTP Authentifizerung nach https://tools.ietf.org/html/rfc7617 geht so: Der Server (ESP) erwartet in jedem Request einen HTTP Header in der Form
1 | Authorization: Basic d2lraTpwZWRpYQ== |
Wenn dieser fehlt oder wenn das Passwort ungültig ist, antwortet er mit einem HTTP Error 401. Dieser Code löst beim Browser aus, ein Dialogfenster zur Eingabe von Name und Passwort zu öffnen. Name und Passwort werden mit einem Doppelpunkt verbunden (z.B. "stefan:geheim") und dann base64 codiert. Dann lädt der Broweser die Seite erneut, dieses mal aber mit dem oben genannten Header. Das Verfahren ist unsicher, weil das Passwort leicht mitgelesen werden kann. Außerdem kann ein Angreifer einfach alle möglichen Passwörter durch probieren, sofern du dagegen nichts unternimmst. Die Digest Authentifizierung ist sicherer. Sie ist in https://www.rfc-editor.org/rfc/rfc7616 beschrieben. Sie ist aber immer noch weit unter der Sicherheit eines VPN Zugangs. Bedenke, dass man mit einer Heizung auch böse Dinge anstellen kann. Zum Beispiel die Haustiere töten.
Bernd K. schrieb: > um mein BHKW per WLAN zu steuern hab ich einen ESP-01S als Webserver > programmiert, welcher Befehle über den UART rausgibt und den > Antwort-String auf der Webseite darstellt. Das geht erstaunlich gut. > Um das BHKW übers Internet anschalten zu können, hätte ich dann doch > gerne einen Passwortschutz. Das könnte zwar man über einen "magischen > Parameter" in der URL bewerkstelligen. Etwas eleganteres wäre aber schon > wünschenswert. (Textfeld fürs Passwort z.B.). Wäre für eine Gehilfe sehr > dankbar. Mit einer Gehhilfe kann ich Dir leider nicht helfen, aber grundsätzlich bietet HTTP ja bereits Authentifizierungsverfahren, wie die Damen und Herren Teilnehmer ja bereits geschrieben haben. Allerdings möchte ich noch eine andere Möglichkeit ins Spiel bringen, um die Sicherheit Deiner Anwendung zu verbessern, nämlich HTTPS. Ich weiß nicht, welche Möglichkeiten Deine ESP32-Plattform dazu bietet, zur Not könntest Du aber auch einen beliebigen Webserver als Reverse Proxy vor Deine Anwendung schalten und die Verschlüsselung darauf terminieren. Ein schematisches Diagramm findest Du im Anhang. Das erfordert natürlich ein entsprechendes Gerät, auf dem dann ein Webserver läuft, der das kann. Vielleicht kann Deine Plattform das ja schon, oder hast Du ohnehin einen Rechner, etwa einen Raspberry Pi, der ständig läuft, oder planst eventuell etwas in dieser Richtung. Die Lösung mit dem Reverse Proxy hätte zudem noch einen anderen, und wie ich finde, sehr eleganten Vorteil: Du könntest auch die Authentifizierung über die TLS-Verschlüsselung realisieren. Dazu müßtest Du eine eigene CA (Certification Authority) aufsetzen und könntest für alle, die auf Deine Steuerung zugreifen sollen, individuelle Client-Zertifikate ausstellen, welche von dieser CA signiert werden. Der Reverse Proxy muß dann nur noch überprüfen, ob ein Client ein Zertifikat vorweisen kann, das von Deiner CA signiert worden ist. Im Zweifelsfall ist es obendrein einfach, Zertifikate wieder zu entziehen, wenn zum Beispiel einem Deiner Nutzer ein Endgerät abhanden gekommen ist oder Du jemandem Dein Vertrauen entziehen mußt. Auf diese Weise hättest Du zwar einen Aufwand, um die CA aufzusetzen und die Clientzertifikate auszustellen und zu verteilen, damit würdest Du ein sehr hohes Sicherheitsniveau erreichen. Das höchste Sicherheitsniveau würdest Du hingegen mit einer Zwei-Faktor-Authentifizierung erreichen, indem Du die von mir beschriebene Technik der TLS-Clientzertifikate mit einer paßwortbasierten Version kombinierst -- auch das könnte auf Deinem Reverse Prox stattfinden, ohne daß Du Deine Steuerung anfassen mußt.
Steve van de Grens schrieb: > Bedenke, dass man mit einer Heizung auch böse Dinge anstellen kann. Zum > Beispiel die Haustiere töten. In 99,99999999999% der Fälle wird das aber praktisch niemand tun. Wen interessiert schon irgendeine Haussteuerung!
Jan V. schrieb: > In 99,99999999999% der Fälle wird das aber praktisch niemand tun. Wen > interessiert schon irgendeine Haussteuerung! Das glaubst nur Du! Ich habe einen Server im Internet laufen mit Infos und zum Austausch für meine ziemlich grosse Familie. Da wollen jeden Tag mehrere Hundert Menschen/Bots/etc mit IP-Nummern aus der ganzen Welt rein, obwohl es da nichts gibt, was jemanden von ausserhalb meiner Familie interessieren könnte. fail2ban verzeichnet inzwischen mehrere Tausend gesperrte IP-Nummern.
Volker schrieb: > Jan V. schrieb: >> In 99,99999999999% der Fälle wird das aber praktisch niemand tun. Wen >> interessiert schon irgendeine Haussteuerung! > > Das glaubst nur Du! > > Ich habe einen Server im Internet laufen Das ist aber vermutlich keine Haussteuerung. Trotzdem ist es zweifellos sinnvoll, auch eine Haussteuerung bestmöglich zu schützen, zumal wenn mit falschen Einstellungen Schäden angerichtet werden können.
Vielen Dank für die Aufklärung diverser Möglichkeiten (rfc7616, rfc7617 ,Proxy,VPN), die ich weiter verfolgen werde. Fürs Erste nutze ich ein an die URL angehängtes langes Passwort, welches als Bookmark im Browser vom Handy und Privatlaptop gespeichert ist, um die Admin-Funktionen an diese IP zu binden. Dieses kenne nur ich. Die Gefahren beschränken sich somit auf Raub meiner Geräte und Netzwerk-Schnüffler. Ein Durchprobieren des Passwortes würde ewig dauern, da der Webserver 1s Reaktionszeit hat. Habe ich etwas übersehen? VG, Bernd
> an die URL angehängtes langes Passwort Ohne HTTPS (wovon ich bei einem ESP8266 ausgehe) wird das im Klartext übertragen und kann von jedem mitgelesen werden - ist dann nichts anderes als eine "geheime" URL. HTTP-DIGEST[1] ist einfacher etablierter Standard und bietet zumindest rudimentäre Sicherheit (u.a. ein verschlüsselt übertragenes Passwort). [1] https://en.wikipedia.org/wiki/Digest_access_authentication
foobar schrieb: > Ohne HTTPS (wovon ich bei einem ESP8266 ausgehe) wird das im Klartext > übertragen und kann von jedem mitgelesen werden - ist dann nichts > anderes als eine "geheime" URL. HTTP-DIGEST[1] ist einfacher > etablierter Standard und bietet zumindest rudimentäre Sicherheit (u.a. > ein verschlüsselt übertragenes Passwort). Richtig. Deswegen stellt sich natürlich die Frage, ob der Webserver auf dem ESP8266 HTTP Digest Authentication oder vielleicht sogar TLS beherrscht.
Karl Käfer schrieb: > Richtig. Deswegen stellt sich natürlich die Frage, ob der Webserver auf > dem ESP8266 HTTP Digest Authentication oder vielleicht sogar TLS > beherrscht. Wenn man es selbst programmiert, sicherlich. Ausser einem ssl-modul (https://docs.python.org/3/library/ssl.html) sind mir keine Bibliotheken dafür bekannt. TAN-Listen wären auch eine Möglichkeit, wenn die Komfort-Einbuße das rechtfertigt. Gegen man-in-the-middle hilft ja wohl auch HTTP-Digest nicht sicher, sagt Wiki. Ich will mich ja nur gegen Trolle schützen. Eine Webseite, wo ein "Motor-Ein"-Button steht, muss man einfach draufdrücken und schauen was passiert. :-)
Bernd K. schrieb: > Karl Käfer schrieb: >> Richtig. Deswegen stellt sich natürlich die Frage, ob der Webserver auf >> dem ESP8266 HTTP Digest Authentication oder vielleicht sogar TLS >> beherrscht. > > Wenn man es selbst programmiert, sicherlich. Davon würde ich nach meinen Erfahrungen mit OpenSSL und WolfSSL eher abraten, das macht echt keinen großen Spaß und es ist auch nicht ganz einfach, das korrekt und sicher hinzubekommen. > Ausser einem ssl-modul > (https://docs.python.org/3/library/ssl.html) sind mir keine Bibliotheken > dafür bekannt. Hm, okay... hier [1] scheint es etwas für NodeMCU zu geben, das ja auf einem der ESPs aufbaut. Andere Artikel sagen allerdings, daß HTTPS auf einem ESP8266 "very demanding" sei, man die Taktfrequenz bis auf 166 MHz hochdrehen und auch dann noch mit unerwarteten Resets rechnen müsse. Also eher nicht das, was man für eine Haussteuerung möchte... Vielleicht wäre ein ESP32 da geeigneter. [1] https://www.onetransistor.eu/2019/04/https-server-on-esp8266-nodemcu.html > TAN-Listen wären auch eine Möglichkeit, wenn die Komfort-Einbuße das > rechtfertigt. Klar, Onetime-Passwords wären auch eine Möglichkeit. Aber ob es dann nicht einfacher ist, irgendeinen kleines RasPi, ein NAS oder etwas Ähnliches als Reverse Proxy zu konfigurieren? Wenn man so etwas schon hat, sicherlich.
Ich habe einfach alle WLAN-IoT-Geräte in ein eigenes WLAN mit sicheren Password und in ein eigenes Subnetz mit restriktiver Firewall gelegt. Das erscheint mir für meinen Zweck hinreichend sicher. Ich sehe absolut keinen Vorteil darin, die Webseite der IoT-Devices direkt zu nutzen. Die brauch ich eigentlich nur zur Ersteinrichtung. Das Gerät selbst kommuniziert ausschließlich per MQTT. Die eigentliche Steuerung erfolgt über ein NodeRed-Dashboard, ioBroker etc. (Geschmackssache) Von Aussen (aus dem Internet) erreichbar ist nur NodeRed, und auch das nur via VPN.
:
Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.