Closed Schnurbi closed 1 year ago
Du nutzt hier die Main Version. Die müsste man so langsam vom Dev branch updaten. In der Beta Version (0.5.109) dürfte dies nicht sein... bin aber ehrlich gesagt mit der Main nicht sicher ob es ein Bug oder eine Fehlbedienung ist?
@lumapu: Was denkst du dazu, könnte man Main nicht Updaten? Beim großen Update in Zukunft macht man ja ein größeren sprung.
Gruß Daniel
@Schnurbi
Es sei übrigens noch angemerkt das portforwarding absolut nicht mehr zeitgemäß ist und ein sehr großes Sicherheitsrisiko ist. Lieber mit VPN arbeiten. Nur als Hinweis.
Ja das ist ein guter Hinweis. Wurde hier aber bewusst so gemacht um erstmal die reine Funktionalität und Erreichbarkeit zu testen, da die FritzBox über ein LTE-Modem mit dem Internet verbunden wurde und sich so am besten die Erreichbarkeit testen ließ und sonst nichts kritisches dran hängt.
Ich würde dann jetzt einfach mal das Update auf die Version 0.5.109 machen und schauen, ob ich weiterhin einfach mit einem 2. Gerät auf die DTU zugreifen kann, wenn schon eine aktive Sitzung existiert.
So, habe jetzt das Update auf Version 0.5.109 gemacht und erneut getestet. Aufruf der DTU mit Handy 1 (Verbindung über WLAN und dann über einen festen DSL Anschluss) und Anmeldung mit dem Kennwort.
Dann Aufruf der DTU mit Handy 2 (Verbindung über Mobilfunk) und ohne Anmeldemaske oder Eingabe des Kennwortes besteht sofort Zugriff auf alle Funktionen und Einstellungen.
Wenn ich mich jetzt mit Handy 1 wieder abmelde und mit Handy 2 die DTU erneut aufrufe, erscheint sofort die Anmeldemaske.
VPN über Fritzbox und gut ist. So hast Du auch gesicherten Zugriff auf alles im Home Netz
VPN über Fritzbox und gut ist. So hast Du auch gesicherten Zugriff auf alles im Home Netz
Das beseitigt den Fehler dennoch nicht und kann kein ernst gemeinter Lösungsvorschlag sein. 😉
VPN über Fritzbox und gut ist. So hast Du auch gesicherten Zugriff auf alles im Home Netz
Das beseitigt den Fehler dennoch nicht und kann kein ernst gemeinter Lösungsvorschlag sein. 😉
Stimmt, das Problem bleibt. Aber ohne Portforwarding kommt man aus dem Internet gar nicht erst durch die Fritzbox zum Endgerät. Und mit VPN bist Du im Home Netz und kommst gesichert an die Endgeräte
Leider aber jeder andere User im gleichen Netzwerk auch. Zumindest solange der Bug besteht. D.h. Logout vergessen und jeder kann die DTU oder den Inverter abschiessen.
VPN über Fritzbox und gut ist. So hast Du auch gesicherten Zugriff auf alles im Home Netz
Das beseitigt den Fehler dennoch nicht und kann kein ernst gemeinter Lösungsvorschlag sein. 😉
Stimmt, das Problem bleibt. Aber ohne Portforwarding kommt man aus dem Internet gar nicht erst durch die Fritzbox zum Endgerät. Und mit VPN bist Du im Home Netz und kommst gesichert an die Endgeräte
Danke für das Rumreiten auf etwas, was ich durchaus selber weiß. Darum geht es hier aber nicht. Punkt. Wäre schön wenn wir diese sinnbefreite Diskussion damit beenden könnten und zum eigentlichen Problem zurück kommen könnten, das durchaus relevant ist. Danke. 😉
Leider aber jeder andere User im gleichen Netzwerk auch. Zumindest solange der Bug besteht. D.h. Logout vergessen und jeder kann die DTU oder den Inverter abschiessen.
Danke, du hast verstanden,dass es nicht um das drum herum geht. 👌😉
habe das Problem verstanden. Man müsste sich einfah die Client IP merken, wenn das Passwort eingegeben wurde. Wenn jemand anderes darauf zugreifen will stimmt die IP nicht und die Anmeldemaske erscheint. Gibt er das richtige Passwort ein, so wird die gespeicherte IP überschrieben. Einschränkung: nur eine Session geht gleichzeitig - dürfte aber hier nicht wirklich einschränkend wirken
@lumapu Ich würde egal wie nur 1 Session mit Anmeldung zulassen. Views gerne so viel das System packt, aber immer nur wirklich 1 angemeldete Session, dann passiert auch nichts ungewöhnliches. Wüsste auch gerade keinen plausiblen Grund auf einem Device 2x angemeldet zu sein.
@lumapu Ich würde egal wie nur 1 Session mit Anmeldung zulassen. Views gerne so viel das System packt, aber immer nur wirklich 1 angemeldete Session, dann passiert auch nichts ungewöhnliches. Wüsste auch gerade keinen plausiblen Grund auf einem Device 2x angemeldet zu sein.
Sehe ich auch so. Den passwortgeschützten Zugang braucht man ja nur um die Einstellungen anzupassen. Da ist eine Session vollkommen ausreichend. 👌
VPN über Fritzbox und gut ist. So hast Du auch gesicherten Zugriff auf alles im Home Netz
Das beseitigt den Fehler dennoch nicht und kann kein ernst gemeinter Lösungsvorschlag sein. 😉
Naja - wir habens hier mit nem Controllerboard zu tun, das ein paar html-Schnipsel zur Konfiguration per http(!) anbietet. Das über Portforwarding ins Internet zu stellen geschieht doch eher auf eigene Gefahr.. oder war das ernst gemeint? Die nächste Anfrage erwartet dann eine Firewall mit Schutz gegen DDOS Angriffe? ;-)
VPN über Fritzbox und gut ist. So hast Du auch gesicherten Zugriff auf alles im Home Netz
Das beseitigt den Fehler dennoch nicht und kann kein ernst gemeinter Lösungsvorschlag sein. 😉
Naja - wir habens hier mit nem Controllerboard zu tun, das ein paar html-Schnipsel zur Konfiguration per http(!) anbietet. Das über Portforwarding ins Internet zu stellen geschieht doch eher auf eigene Gefahr.. oder war das ernst gemeint? Die nächste Anfrage erwartet dann eine Firewall mit Schutz gegen DDOS Angriffe? ;-)
Leider ist der Beitrag null hilfreich. Wie ebereits erläutert ging es dabei nur um eine Testumgebung in der Bewusst auf VPN verzichtet wurde um überhaupt erstmal die Funktionalität mit so wenigen potetntiellen Fehlerquellen wie möglich festzustellen. Dass sich jetzt einige hier daran aufzugeilen scheinen darauf rum zu reiten ist mir schleierhaft. Ich habe das auch nur dazu geschrieben um die Rahmenbedingungen beim erstmaligen Feststellen des Problems so genau wie möglich zu beschreiben. Da die Problematik aber eben auch unabhängig von Portweiterleitungen besteht, sind diese Beiträge leider wertlos. Diese Besserwisserei löst keine Probleme und ist absolut sinnfrei, wenn dem Melder (in diesem Fall mir) absolut klar ist, dass das keine Dauerlösung ist und das es auch nicht sicher ist. Es geht hier aber nunmal nicht um die Testumgebung oder die Gründe warum ich diese so aufgebaut habe und des Weiteren habe ich nie erwartet bei einem Bastelboard eine Firewall und DDOS Schutz zu erhalten. Ich muss mich ernsthaft Fragen, wozu dieser Kommentar dienen sollte.
Ich muss @GallusMax zustimmen, das Projekt hier ist eine ganz einfache Bastelei für zu Hause, sowas stellt man nicht offen ins Netz. Und selbst mit einem Passwort wird dir nicht geholfen sein, denn es wird in Ahoy selbst garantiert irgendwelche Lücken geben, die ein Angreifer ausnutzen könnte. Des Weiteren ist das Passwort nur für das Webinterface. Das braucht du aber nicht um den Inverter "abzuschießen", dafür reicht ein Zugriff auf die API. Hier reicht nur eine kleine Zeile über die Kommandozeile um den Inverter auf 0 zu setzen, egal ob ein Passwort vergeben ist oder nicht.
Ich muss @GallusMax zustimmen, das Projekt hier ist eine ganz einfache Bastelei für zu Hause, sowas stellt man nicht offen ins Netz. Und selbst mit einem Passwort wird dir nicht geholfen sein, denn es wird in Ahoy selbst garantiert irgendwelche Lücken geben, die ein Angreifer ausnutzen könnte. Des Weiteren ist das Passwort nur für das Webinterface. Das braucht du aber nicht um den Inverter "abzuschießen", dafür reicht ein Zugriff auf die API. Hier reicht nur eine kleine Zeile über die Kommandozeile um den Inverter auf 0 zu setzen, egal ob ein Passwort vergeben ist oder nicht.
🤦♂️🤦♂️ Langsam hab ich das Gefühl ich unterhalte mich hier mit einer Wand, oder dass einige in der Schule nie "Lesen und Verstehen" gelernt haben.
Was möchtest du denn von uns? Ja Passwort ist toll, macht ja aber Ahoy nicht wirklich sicherer.
Außerdem muss ich noch eines loswerden: Wir alles haben Spaß an der Entwicklung des Projektes. Die Community hält das Ganze zusammen, solange alle miteinander auskommen. Du bist seit diesem Monat Mitglied und schreibst hier solche Kommetare. Wir können uns in einem normalen Ton unterhalten, das hier ist nicht Facebook.
Ich klinke mich hier jetzt aus, dein letzter Kommentar ist mir zu pampig.
Was möchtest du denn von uns? Ja Passwort ist toll, macht ja aber Ahoy nicht wirklich sicherer.
Außerdem muss ich noch eines loswerden: Wir alles haben Spaß an der Entwicklung des Projektes. Die Community hält das Ganze zusammen, solange alle miteinander auskommen. Du bist seit diesem Monat Mitglied und schreibst hier solche Kommetare. Wir können uns in einem normalen Ton unterhalten, das hier ist nicht Facebook.
Ich klinke mich hier jetzt aus, dein letzter Kommentar ist mir zu pampig.
Sorry dafür, aber anders scheint es ja nicht anzukommen, dass wir diese sinnbefreite Diskussion um Portweiterleitung oder VPN endlich beenden sollten, da das System nur zum Zeitpunkt der Fehlerfeststellung in diesem Zustand war, ganz bewusst um etwas zu Testen, was aber (wie unterdessen ja bekannt ist) nichts mit dem Fehler zu tun hat. Das System befindet sich quch schon seit Abschluss dieser Tests nicht mehr in dem Zustand dass es per Portweiterleitung erreichbar ist und bei dem besagten Test war auch kein Wechselrichter angeschlossen, eben weil das mit den potentiellen Sicherheitsrisiken mir absolut bewusst ist. Für den ersten Hinweis dazu habe ich mich bedankt, weil ein Hiweis durchaus angebracht ist, wenn man das die Hintergründe nicht kennt. Nachdem ich deise aber nun schonmehrfach ausführlich dargelegt habe, kann ich wohl erwarten, dass weitere Teilnehmer der Diskussion dies auch lesen und verstehen dass eine weitere Diskussion über Portweiterleitung oder VPN hier einfach am Thema vorbei gehen. Dass ich dann irgendwann viellecht auch etwas schnippisch schreiben muss, damit das auch der letzte versteht tutmir Leid, aber es ist offensichtlich manchmal das einizige Mittel damit der eine oder andere aufwacht.
Konstruktive Beiträge zum eigentlichen Problem sind immer gerne willkommen.
Um auf deine Frage zu antworten was ich möchte:
Ich möchte eine sacheliche Diskussion über das Problem und ggf. eine Lösung. Eine Posswortfunktion macht Ahoy sicherlich nicht zu Fort Knox, aber sie hat einen gewissen Zweck.
DanielR92, lumapu und rmayergfx haben verstanden worum es geht, die haben das Problem erkannt, haben sich mit dem eigentlichen Thema befasst und nicht daran vorbei geredet. Kurz, knapp und sachlich. So wünsche ich mir das. So macht das ganze auch Spaß. Deswegen ganz klarer Dank an die 3.
Ich muss @GallusMax zustimmen, das Projekt hier ist eine ganz einfache Bastelei für zu Hause, sowas stellt man nicht offen ins Netz. Und selbst mit einem Passwort wird dir nicht geholfen sein, denn es wird in Ahoy selbst garantiert irgendwelche Lücken geben, die ein Angreifer ausnutzen könnte. Des Weiteren ist das Passwort nur für das Webinterface. Das braucht du aber nicht um den Inverter "abzuschießen", dafür reicht ein Zugriff auf die API. Hier reicht nur eine kleine Zeile über die Kommandozeile um den Inverter auf 0 zu setzen, egal ob ein Passwort vergeben ist oder nicht.
Dann sollten wir diese Lücke auch noch per Passwort abfangen. Zumindest was solch kritischen Sendebefehle anbelangt. Mir egal wer oder ob jemand die Werte auslesen kann, aber Werte verändern oder "abschiessen" ist ein NoGo.
Ja, es ist ein Projekt für zu Hause, aber wie viele IOT sollte man auch hier eine gewisse Sorgfalt walten lassen, damit nicht ein Dritter sich ins heimische Netz einschleicht. Viele Netzwerke werden ja gerade über Schwachstellen solcher IOT gehackt ohne das es der User bemerkt und nicht jeder hat den Skill oder auch das Equipment sich ein VLAN oder ein anderes sicheres Netzwerk aufzubauen, damit die ganzen Smarten Gerätschaften sich da tummeln wo sie nichts anrichten können. Damit man etwas auf der sicheren Seite ist, bietet es sich schon mal an das man in der FRITZ!Box (sofern man eine besitzt) schon mal den ganzen Geräten den Internetzugang per Kindersicherung sperrt.
Ich finde das Thema Security sollte man auch bei einem solchen Bastelprojekt nicht vernachlässigen. Natürlich gibt es bessere Lösungen wie VPN um sich in das heimische Netz einzuwählen, das steht aber doch auf einem ganz anderen Blatt. Es gibt eine Sicherheitslücke (mehrere!) Man hat diese erkannt und teilt sie dem Entwickler mit. Er entscheidet nun ob er sie fixt oder nicht. Andere User nun anzugehen wie sie das Problem lösen sollten hilft keinem der beiden Seiten, denn das löst die grundsätzliche Problematik nicht.
Sorry, aber ich finde das rumreiten auf "das LAN ist doch sicher" obwohl hier eine Sicherheitslücke aufgezeigt wird sehr gruselig! Entweder man baut eine Login-Maske um auch wirklich sicherzustellen, dass sich da jemand einloggt, damit diese Person Zugriff hat oder man lässt es gleich. In diesem Fall täuscht es eine Sicherheit vor, die überhaupt nicht gegeben ist! Wenn man diesen Weg unbedingt wählt, dann sollte der Nutzer deutlich bei der Einrichtung des Benutzers darauf hingewiesen werden!
Moin, möglich, dass die Leistung des ESP 8266 nicht ausreicht, und für Cookies, Sessiontokens oder eine andere Authentifizierungsprüfung nicht genug 'Dampf' hat.
Ich sehe es als Gateway, welches im privaten Umfeld genutzt wird.
'Mein' Netzwerk ist in verschiedene VLANs aufgeteilt. Besucher oder die Jungs haben je ihr eigenes Netzwerk, welche nicht auf die Heimautomation kommen. Von extern geht es nur über VPN rein.
Diese Trennung hat nicht jeder. Und was Suchmaschinen für offene Systeme finden, ist erschreckend.
Wenn jemand Angst hat, dass da böse Leute was umkonfigurieren, und die Leistung des ESPx nicht ausreicht, könnte man über eine Option nachdenken, dass da per Webinterface / API überhaupt nichts mehr verstellt werden darf. > Nur gucken, nix anfassen.
Alternativ einen Rechner zur Authentifizierung zwischenschalten, welcher per MQTT mit der DTU spricht. Das Dashboard kann man per anderem Rechner wieder nachbauen.
Ansonsten finde ich das Projekt prima. - Die Open-DTU, auf einem ESP32, schafft nur eine kurze, einmalige Verbindung zu meinem Wechselrichter, selbst auf maximaler Sendeleistung, die Ahoy-DTU, auf einem ESP8266, läuft auf kleiner Sendeleistung mit dem selben Sendemodul stabil durch und passt in ein kleineres Gehäuse.
Platform
ESP8266
Model name
No response
nRF24L01+ Module
nRF24L01+ plus
Antenna
circuit board
Power Stabilization
nothing
Connection diagram
Connection diagram I used:
Note: [*] GND Pin 1 has a square mark on the nRF24L01+ module
Connection picture
Version
0.5.66
Github Hash
f8fe044
Build & Flash Method
ESP Tools (flash)
Desktop
Windows
Setup
Device Host Name
WiFi
Inverter
Inverter 0
noch keiner eingerichtet
General
NTP Server
MQTT
nicht eingerictet
System Config
Pinout (Wemos)
Radio (NRF24L01+)
Serial Console
Debug Serial Log output
No response
Error description
1) Go to http://ahoy-dtu/setup 2) configure above settings 3) Reboot 4) I did this: Ich habe die Ahoy DTU aufgesetzt, ins WLAN eingebunden, habe ein Kennwort für den Zugriff auf alle Funktionen vergeben und habe sie über eine Portweiterleitung in der Fritzbox und einen DynDNS Dienst aus dem Internet erreichbar gemacht. Dann habe ich mit über das Internet von meinem Handy aus an der DTU angemeldet (direkt über Mobilfunk). 5) I expected that: Ich habe erwartet, dass jetzt nur ich von meinem Gerät Zugriff auf die DTU habe. 6) and something completely differen happened: Stattdessen konnte ich ein weiteres Gerät nehmen, das über einen vollkommen anderen Internetzugang verfügt (WLAN über einen festen Internetanschluss) und von dem aus ich zuvor noch nie auf die DTU zugegriffen habe. Dem Gerät war also weder das Passwort vorher bekannt, noch der DynDNS-Link. Trotzdem war ich sofort auf der DTU-Oberfläche und hatte Zugriff auf alle Einstellungen, ohne jemals das Passwort eingegeben zu haben.