ich baue mir gerade meine Netzwerkzugänge auf (mobiles Internet, VPN & co). Dabei ist mir aufgefallen, dass im Auslieferungszustand erstmal Tür und Tor bei vanpi offen steht, er sollte daher nur offline oder hinter einer Firewall im Router betrieben werden!
Das UI ist völlig ohne Authentifizierung abrufbar
Das Nodered Backend ist ebenfalls ohne Authentifizierung abruf- und änderbar
Fernzugriff auf den Raspberry mit Adminrechten ist per ssh ist mit dem Standardlogin (“pi” / “Raspberry”) über Port 22 möglich.
Mögliche Szenarien, in denen das passiert:
a) Ihr nutzt den Wlan Hotspot eures Android Smartphone für vanpi
b) Ihr nutzt einen USB-Surfstick am Raspberry pi
c) Ihr verbindet euch mit einem öffentlichen Wlan
d) Ihr lasst jemanden in euren Hotspot, weil “seine Daten leer sind”
Auch eine VPN Verbindung nutzt an der Stelle nichts, wenn ihr nicht alle anderen Ports explizit mit einer Firewall abschaltet. Eine Firewall auf dem Vanpi zu installieren ist jedoch relativ mühselig und ihr kommt auch lokal nur noch über VPN auf euer UI, weil Ihr den Port 1880 sperren müsstet.
Es kommt eigentlich daher nur ein Router mit aktiver Firewall als Internetzugang für den Vanpi in Frage.
Das ist richtig, der Raspberry ist ein Server und sollte entsprechend abgesichert werden sobald er im Netzwerk hängt.
Dazu gehören mindestens die Standarddaten für SSH und Wlan Passwort. Bei einem öffentlichen Server gehört noch einiges mehr dazu, aber das ist hier ja nicht der Fall.
Zugriffe von außen sollte die Firewall des Routers abfangen, sobald jemand Zugriff auf dein Netzwerk hat stehen aber natürlich alle Türen in Richtung Vanpi offen - solange nichts abgesichert worden ist.
Man könnte das Frontend über Nginx mit einer Authentifizierung absichern, das Backend ebenfalls mit einem Passwort versehen und das Routing anpassen. Allerdings hätte das auch Auswirkungen auf die APIs.
Im Endeffekt ist aber die Frage, welcher Aufwand wann sinnvoll ist. Wenn ich jemandem bei mir zuhause mein Wlan Passwort gebe, dann könnte diese Person bei mir das Licht ein- und ausschalten, logisch. Deswegen versehe ich den Zugang zu meinen Lichtschaltern aber nicht mit einem Passwort etc. ich sehe aber zu, dass der Kreis der Personen mit Zugriff auf mein Netzwerk überschaubar bleibt und dass das Netzwerk entsprechend gesichert ist.
Im Großen und Ganzen gebe ich dir natürlich Recht, es ist wichtig, dass man sich bewusst ist was passiert (bzw. passieren kann), wenn man Geräte über das Internet erreichbar macht.
Also wäre es am sichersten den VanPi als Hotspot im Van zu betreiben und beim ersten Start dann das WLAN Passwort zu ändern ?
Idealerweise dann noch das Passwort vom RPI und das vom SSH ändern.
Wenn ich den PI im Netzwerk habe dann ist es so das wenn ich im Router den Port 1880 und 22 sperre ist der Nutzer der von der Ferne zugreifen will auch raus.
Dann stellt sich die Frage was wäre dann eine sichere alternative für den VanPi als Fernzugriff ? Wollte gerne eine Verbindung zum Van haben um die Heizung, Lüftung und Lampen zu steuern.
Moin,
leider ist das ganze nicht so einfach: im VanPi sind so einige Dinge hart verdrahtet und eher auf Funktionalität als auf Sicherheit ausgelegt.
U.a. der MQTT Broker, SSHd, WLAN AP, Node Red, Nginx, HomeKit, AVAi, dhcpd … - alle stehen offen.
Für ein Betrieb am Internet sind auch einfache Dinge wie SSL, Firewall und Authentifizierung zu beachten, die sehr schnell auch sehr komplex werden und damit so einige überfordern können.
Meines Erachtens kannst du da nur einen Router davor stellen, der Firewall, CapativePortal und WLAN AP mit DHCP abdeckt. Ich habe mich dazu mit einem Teltonika RUTX50 entschieden, da er auch gleich GPS, DualSIM und 5G abdeckt.
Für die eigentliche Steuerung des Vans baue ich gerade ein Home Assistant Addon “HA_VanPi”, welches dann den Dimmy und Relayboard (mit i2C, Serial, USB und 1-wire) abdeckt. VanPi bekommt dadurch KEINEN direkten Netzwerkzugriff mehr
Das komplette Thema der Authentifizierung, Autorisierung und Patchmanagement überlasse ich damit den Home Assistant Entwicklerteam und kümmere mich selbst nur um die Abbildung der VanPi Hardware-Funktionen. Home Assistant selbst wurde gerade einem Security-Audit unterzogen. (Security audits of Home Assistant - Home Assistant)
Sowas beim VanPi durchführen zu lassen würde ich bei dem aktuellen Entwicklungsstand nicht anraten.
Meine Motivation für den Post war “zum denken anregen”, in Zeiten, in denen ein Android Telefon in einem Klick zum Router ohne Firewall wird.
Ich würde nicht die beiden Ports blocken, sondern grundsätzlich alles und dann die freigeben, die ich brauche. Ich weiß nicht welche Ports sonst noch bedenklich sein könnten. Ich bin auch kein Sicherheitsexperte und habe da respekt vor.
Fernzugriff könntest du über vpn realisieren, wenn alles andere gesperrt ist, erscheint mir das als recht sicher.
Alternativ könnte ein Ansatz sein, den port 1880 freizugeben und alles, was darüber zu erreichen ist, über Authentifizierungen abzusichern. Da fehlt mir aber noch der Überblick und man muss wie okidoki sagt einiges beachten und am Ball bleiben.
Für mich ist die Praktikabelste Lösung Router mit Firewall und VPN.
Ich habe mir bereits einen Vpn Server mit dyndns (alles mit ipv6 wegen dslite) im Heimnetz eingerichtet, vanpi und Handy verbinden sich als clients da drauf. Der vpn server würde so von der configuration auch auf dem vanpi laufen, für mich hat es jedoch ein paar Vorteile, wenn der auf einem Raspberry im Heimnetz läuft.
Z.b. die Variante unter 3. (Smartphone Hotspot). Hatte das selbst mit einem Android Handy ausprobiert, der Rasperry pi bekommt eine öffentliche ip (ipv6). Mit Ip und Port lässt sich das Ui und das Backend vollkommen ohne Schutz über das Internet aufrufen. Der ssh Login funktioniert ebenfalls weltweit. Eine Firewall auf dem Pi macht in der Konfiguration keinen Sinn und unter Android wäre es nur mit root rechten möglich.
Variante 2 (usb surfstick) dürfte ebenfalls problematisch sein. Hier könnte jedoch wenigstens eine Firewall auf dem Pi installiert werden, aber da sind wir auch schon bei einem etwas fortgeschritteneren User.
Habs grade getestet und bin nicht über die öffentliche IPv6 draufgekommen, müsste das nicht auch schon der NAT des Providers blocken? Mit der internen IPv6 komm ich drauf, aber nicht mit der öffentlichen. Ansonsten kann man ja IPv6 auch einfach deaktivieren beim RPI, damit sollte man das ja auch umgehen können.
Oder direkt im Smartphone auf nur IPv4 umstellen, müsste theoretisch auch funktionieren.
Was verstehst du unter “interne IPv6”? Du hast mit IPv6 in der Regel keine privaten Adressen mehr, die Adresse, welche dir der Raspberry Pi mit ifconfig ausspuckt ist normalerweise öffentlich erreichbar, wenn es keine Firewall blockt.
Unter IPv4 sieht das ganze etwas anders aus, hier würde auch der NAPT des Providers eingehende Verbindungen verhindern, weil Kunden üblicherweise keine exklusive öffentliche IPv4 mehr besitzen. Ich sehe keinen Grund, warum Provider IPv6 Verbindungen blocken sollten und meine tun dies zum Glück auch nicht.
Abschalten von IPv6 kann natürlich Zugriff verhindern, ich halte eine Firewall für sinnvoller.
Ich hatte folgendes Testsetup:
Samsung S10 im Telekom Mobilfunk
Samsung S5 im Netzklub (O2) Mobilfunk, Wlan Hotspot aktiv
Raspberry Pi mit Wlan Hotspot des S5 verbunden
Jedes Interface hat ja zumindest eine fe80::… Adresse, das ist die link-local Adresse, die mein ich mit intern. Mein Setup sieht folgendermaßen aus:
RPI angeschlossen per LAN über eth0 (lokal, hinter Fritzbox)
Selber RPI angeschlossen per Wifi and den Hotspot meines Handys (Telekom Mobilfunk) über wlan0
PC im lokalen LAN (Fritzbox)
Ich hab nun 4 IPv6 Adressen beim RPI angezeigt, jeweils eine öffentliche und eine interne (die fe80::…)
Am PC versuche ich mich jetzt jeweils per SSH zum RPI mit jeder der 4 Adressen zu verbinden:
PC zu eth0 über öffentliche IPv6: Zugriff möglich
PC zu eth0 über interne IPv6: Zugriff möglich
PC zu wlan0 über öffentliche IPv6: kein Zugriff
PC zu wlan0 über interne IPv6: kein Zugriff
Andersrum jetzt auf dem Handy per SSH:
Handy zu eth0 über öffentliche IPv6: kein Zugriff
Handy zu eth0 über interne IPv6: kein Zugriff
Handy zu wlan0 über öffentliche IPv6: Zugriff möglich
Handy zu wlan0 über interne IPv6: Zugriff möglich
Also eth0 ist im selben Netzwerk mit dem PC, wlan0 ist ein anderes Netzwerk, in welchem auch das Handy ist.
Dass ich vom Handy aus keinen Zugriff auf die eth0 Adresse habe ist ja eigentlich logisch und auch gut so, weil die hängt ja hinter der Fritzbox. Aber ich komme wie gesagt auch nicht vom PC aus auf die wlan0 Adresse.
Natürlich kann das alles jetzt noch mit den Konfigurationen des ISP zusammenhängen, oder Caching, oder mein Testsetup, oder sonst was.
Wenn ich das richtig verstanden haben, werden die öffentlichen IPv6 Adressen in bestimmten Intervallen neu generiert. Generell hab ich mich aber noch nicht richtig damit auseinandergesetzt, als dass ich da konkrete Fakten auf den Tisch legen kann. Eine Firewall ist in jedem Fall immer sinnvoll.
Eine Funktion in VANPI einzubauen, mit der man IPv6 de- bzw. aktivieren kann sollte aber kein Problem darstellen, ist ja an sich nur eine Zeile die geschrieben werden müsste.
Die fe80 Adressen hatte ich tatsächlich noch gar nicht wahrgenommen, ich hatte mich auch erst vor kurzem in die Thematik eingearbeitet, da im Privatbereich mit dslite und mobilfunk ipv4 für viele Anwendungen keine Option mehr ist.
Dass du über die öffentliche Adresse keine Verbindung bekommst, könnte tatsächlich am anderen Provider liegen. Ich werde das ggf. die nächsten Tage aus Interesse mal ausprobieren. Möglicherweise gibt es auch Unterschiede zwischen Android und ios?
Sehr gut möglich, da hab ich aber wie gesagt zu wenig Erfahrung im Bereich IPv6.
Alternativ wäre (für IPv4) eventuell auch eine Option einen Tailscale Client zu installieren und mit einem Headscale Server zu kombinieren, dann hätte man einen selfhosted VPN Controller und P2P Zugriff auf die Clienten. Dabei wäre die IP-Adresse egal.
Ich hatte mir diesen Thread schon abgespeichert, aber bin zeitlich noch nicht dazu gekommen alles zu lesen. Nun ist mein VanPi offenbar gehackt worden, bevor ich mich mit dem Thema auseinandergesetzt habe: https://forum.pekaway.de/t/kein-zugriff-mehr-auf-das-system/1233/8
Ich schaue mir das alles einmal ganz genau an und hoffe, dass wir alle in Zukunft ein System konfigurieren können, das besser vor Angriffen geschützt ist.
Hilfreich wäre eine Anleitung was man tun sollte um das Ding hinter einem Router mit Firewall halbwegs sicher zu betreiben…und vielleicht so geschrieben das man es versteht wenn man von IT eher wenig Ahnung hat. Grade für die Leute ist es ja wichtig das abzusichern.
prinzipiell sind Router für den Endkunden mit verschieden Sicherheitsfunktionen eingestellt, die es fast unmöglich machen von außen in dein “Heimnetz” zu kommen.
Heiko hatte in seiner Fritzbox den “Exposed Host” aktiviert und damit sein Netzwerk komplett von außerhalb zugänglich gemacht. Wenn man dies tut, müssen unbedingt nachgestellte Sicherheitsmaßnahmen getroffen werden.
Ein “Exposed Host” ist eine Netzwerkkonfiguration, bei der der gesamte eingehende Verkehr an ein bestimmtes Gerät innerhalb eines privaten Netzwerks weitergeleitet wird. Dies macht das Gerät direkt aus dem Internet erreichbar. Es wird oft für Dienste wie Webserver oder Spielserver verwendet, birgt jedoch Sicherheitsrisiken, da alle Arten von Verkehr zugelassen werden. Portweiterleitung oder eine strengere Firewall-Konfiguration sind normalerweise sicherere Alternativen, um bestimmte Dienste aus dem Internet zu ermöglichen.
Die Fritzbox sollte eigentlich beim aktivieren auch Warnhinweise dazu ausgeben.
es ist richtig, dass die FRITZ!Box eine Exposed Host Einstellung hatte. Allerdings wurde damit der Verkehr “nur” zu dem Teltonika RUTX10 Router weitergeleitet. Dieser sollte eigentlich eine eigene Firewall haben, die den Verkehr absichert. Ob das so konfiguriert ist, versuche ich gerade nachzuvollziehen.
Aus Schaden wird man klug. Auch wenn der Schaden bei mir noch gar nicht abzusehen ist.
