Fernwartung im anderen Netz eines Raspberry Pi 3 mit Debian 9
Re: Fernwartung im anderen Netz eines Raspberry Pi 3 mit Debian 9
Da wir im Handy eine Karte haben auf der nur ein gewisses Datenvolumen verfügbar ist und das Datenvolumen sich im Moment noch im kb Bereich sich bewegt kann ich das ja mal probieren.
Wo finde ich zu OpenVPN (SSH) ein Tutorial oder eine Anleitung nach der ich vorgehen kann? Im Netz gibt es ja viel was nicht zu gebrauchen ist....
Wo finde ich zu OpenVPN (SSH) ein Tutorial oder eine Anleitung nach der ich vorgehen kann? Im Netz gibt es ja viel was nicht zu gebrauchen ist....
pro2311
Re: Fernwartung im anderen Netz eines Raspberry Pi 3 mit Debian 9
Ich würde einen PreShared-Key nehmen. Netztechnisch musst du innerhalb des VPN nicht viel konfigurieren, da ja Client und Server sich anschließend nur unterhalten wollen.
Schau hier: https://wiki.debian.org/OpenVPN
Den UDP-Port für OpenVPN musst du natürlich am DSL-Router weiterleiten.
Ob das am Ende eine gute Idee ist den VPN-Tunnel 7/24 offen zu halten weiß ich nicht.
Durch den Tunnel kannst du dann z. B. SSH nutzen. Musst natürlich auf den Pi dafür einen SSH-Server installieren falls nicht vorhanden.
Schau hier: https://wiki.debian.org/OpenVPN
Den UDP-Port für OpenVPN musst du natürlich am DSL-Router weiterleiten.
Ob das am Ende eine gute Idee ist den VPN-Tunnel 7/24 offen zu halten weiß ich nicht.
Durch den Tunnel kannst du dann z. B. SSH nutzen. Musst natürlich auf den Pi dafür einen SSH-Server installieren falls nicht vorhanden.
Re: Fernwartung im anderen Netz eines Raspberry Pi 3 mit Debian 9
Sowohl ein bestehender OpenVPN-Tunnel als auch eine SSH-verbindung tauschen in regelmässigen Abständen Nachrichten untereinander aus, um sicherzustellen, daß die Verbindung noch besteht. Das sind halt ein paar Netzwerkpakete pro Stunde, Dazu kommen die Datenmengen, die beim Verbindungsaufbau selbst entstehen und das Volumen beim eigentlich Administrieren. Vermutlich wird das unter 50MByte pro Monat bleiben, aber nagel mich bitte nicht darauf fest.pro2311 hat geschrieben:28.05.2019 16:37:59Da wir im Handy eine Karte haben auf der nur ein gewisses Datenvolumen verfügbar ist und das Datenvolumen sich im Moment noch im kb Bereich sich bewegt kann ich das ja mal probieren.
https://openvpn.net/community-resources/how-to/Wo finde ich zu OpenVPN (SSH) ein Tutorial oder eine Anleitung nach der ich vorgehen kann?
Re: Fernwartung im anderen Netz eines Raspberry Pi 3 mit Debian 9
Wenn das bedeutet, dass fremde Personen Zugang zu diesem Pi haben, würde ich Dir davon abraten, die einfache Static-Key-Variante mit OpenVPN zu verwenden, sondern deutlich sicherer nur eine Password-Gesicherte TLS-Authentifizierung zu erlauben. Zusätzlich würde ich sowohl das Password als auch die Keyfiles bei Nichtgebrauch in einem LUKS-Container sichern, der nur bei Bedarf vor dem Verbindungsaufbau dazugemountet wird und sofort wieder getrennt wird. Fakt ist, wenn fremde Zugang zu dem PI haben und sich des Static-Keys bemächtigen, hast Du ab dem Moment keinerlei Kontrolle mehr darüber, wer sich auf Deinen Rechner bzw. Netzwerk zuhause (oder im Büro, etc.) aufschaltet. Ich betrachte das als hochgradig fahrlässig.pro2311 hat geschrieben:28.05.2019 15:58:20Hinzu kommt noch ein vermutlicher Vandalismus gegen die Anwendung die es mir nicht erlaubt zu sagen was passiert als nächstes...
Ich erinnere lieber noch mal... eine LTE-Verbindung mit begrenztem Guthaben würde ich nur bedarfsorientiert öffnen.... entweder tuts der Pi automatisch zu vorgegebenen Zeiten oder er bekommt eine kurze Aufforderung via Message. Und sofort nach Beendigung der Arbeiten wird sowohl die Verbindung als auch der Container wieder geschlossen. Damit hast Du wenigstens eine kleine Chance, dass die Zugangsdaten in Dein System geschützt sind.
Re: Fernwartung im anderen Netz eines Raspberry Pi 3 mit Debian 9
AckTomL hat geschrieben:28.05.2019 18:34:10Wenn das bedeutet, dass fremde Personen Zugang zu diesem Pi haben, würde ich Dir davon abraten, die einfache Static-Key-Variante mit OpenVPN zu verwenden,
Paßwortabsicherung bei einem Client, der sich automatisch verbinden soll, ist einigermassen sinnlos, denn das Paßwort muß irgendwo im Klartext abgelegt werden (spätestens im aufrufenden Skript).sondern deutlich sicherer nur eine Password-Gesicherte TLS-Authentifizierung zu erlauben.
Und den LUKS-Container mountet man dann per Shellskript, in dem das Paßwort lesbar ist, vor dem Verbindungsaufbau mit OpenVPN. Welchen Sicherheitsvorteil soll das bringen?Zusätzlich würde ich sowohl das Password als auch die Keyfiles bei Nichtgebrauch in einem LUKS-Container sichern, der nur bei Bedarf vor dem Verbindungsaufbau dazugemountet wird und sofort wieder getrennt wird.
Wer den static Key aus der SD-Karte des Raspis auslesen kann, kann auch die Skripte, die den LUKS-Container mounten und OpenVPN mit Paßwort aufrufen, auslesen und die Paßwörter extrahieren. Mit anderen Worten, komplizierter (security by obscurity) aber ohne Sicherheitsgewinn.Fakt ist, wenn fremde Zugang zu dem PI haben und sich des Static-Keys bemächtigen, hast Du ab dem Moment keinerlei Kontrolle mehr darüber, wer sich auf Deinen Rechner bzw. Netzwerk zuhause (oder im Büro, etc.) aufschaltet. Ich betrachte das als hochgradig fahrlässig.
Ich gebe dir ja recht, das static Keys eine gewisse Problematik mitbringen. Vor allem muß man bei einer Komprometierung einen neuen Key generieren. Solange das nicht wie im heimischen WLAN mit preshared Key läuft, bei dem zig Geräte mit neuem Key versehen werden müssen, sondern nur ein Client und ein Server involviert sind, ist das auch nicht unsicherer als merklich komplizierter zu erzeugende SSL-Zertifikate, die man einzeln zurückziehen kann.
Ein echter Sicherheitsgewinn wäre es, wenn man den OpenVPN-Server (zuhause oder om Büro) in eine DMZ sperrt, damit eine kompromitierte Netzverbindung nicht direkt ins heimische Netz eindringen kann.
Re: Fernwartung im anderen Netz eines Raspberry Pi 3 mit Debian 9
MSfree hat geschrieben:28.05.2019 20:23:40...ist einigermassen sinnlos, denn das Paßwort muß irgendwo im Klartext abgelegt werden (spätestens im aufrufenden Skript).
Äääh, wer auf so eine Lösung kommt, muss eigentlich nicht weiter über Sicherheit nachdenken.... das wäre ja imho mehr als nur fahrlässig. Definitiv würde ich auf einem so exponierten System kein Password für den Container irgendwo in Reinschrift hinterlegen.Und den LUKS-Container mountet man dann per Shellskript, in dem das Paßwort lesbar ist, vor dem Verbindungsaufbau mit OpenVPN. Welchen Sicherheitsvorteil soll das bringen?
Ohne das jetzt groß durchdacht zu haben, hatte ich von Anfang an eine Lösung im Kopf, die vermutlich schon passen würde. Ich würde das Container-Password in ein kleines und unauffälliges Mini-Binary (C, CPP) packen, was das notwendige tut, um den Container zu öffnen, zu verbinden und sofort wieder schließen. Und das man das Pwd dann da nicht in Klartext reinschreibt ist ja wohl auch klar. Ich würde irgend 'ne dämliche 300-Zeichen-Textzeile durch base64 (o.ä.) verhuddeln lassen und dann diesen String im Binary als Klartext hinterlegen. Um dann in der Fibonacci-Reihenfolge ein 10- oder 12-Zeichen-Password daraus für den Container rauszulesen. Irgendwie sowas.... ich will ja nicht die NSA austricksen, aber für Spanner und Gelegenheitshacker reicht sowas allemal. Und wennn ich Probleme hätte, z.B. wegen spawn, exec, system (oder so, das einzige, was ich mir vorstellen könnte) würde ich hier um Hilfe fragen.... schließlich sind das ja nur ein paar Codezeilen. Mir ist völlig klar, dass das Schwachstellen hat.... aber es ja hier nicht darum, echte Profis abzuhalten, sondern Spanner und Fummler.
Und wie gesagt, in meiner ersten Antwort hatte ich ja schon drauf hingewiesen, dass das eine technische Herausforderung ist, wenn man die Sicherheit nicht außen vor lassen will. Und wenn man unbeaufsichtige Zugänge in sein Netz bereitstellen will, sollte man da schon über entsprechende Sachkenntnis verfügen. Also einfach nur ein paar Bash-Scripte mit Klartext-Passwörtern und Keyfiles geht ja wohl gar nicht.... dann kann man sichs auch ganz sparen, über Sicherheit nachzudenken.
Ja, das ist ne richtig gute Idee. Vielleicht reichts ja schon, dass in eine VM zu sperren und via Paketfilter die Zugänge ins LAN zu sperren. Ich hab sowas schon gemacht: eine VM als regulärer Lan-Client = Internet ja, LAN nein.Ein echter Sicherheitsgewinn wäre es, wenn man den OpenVPN-Server (zuhause oder om Büro) in eine DMZ sperrt, damit eine kompromitierte Netzverbindung nicht direkt ins heimische Netz eindringen kann.
Re: Fernwartung im anderen Netz eines Raspberry Pi 3 mit Debian 9
Die Sicherheit ist so eine Sache und damit kommen wir wieder zurück zu meiner Remote-SSH-Idee.
Für Remote-SSH könnte man nur themporär zuhause den SSH-Server starten und zudem reicht dem Benutzer die Shell /bin/false.
https://kram.nz/2018/01/remote-ssh-tunnel/
(das sudo-Zeug bitte überlesen)
Für Remote-SSH könnte man nur themporär zuhause den SSH-Server starten und zudem reicht dem Benutzer die Shell /bin/false.
https://kram.nz/2018/01/remote-ssh-tunnel/
(das sudo-Zeug bitte überlesen)
Re: Fernwartung im anderen Netz eines Raspberry Pi 3 mit Debian 9
Das könnte man mit dem OpenVPN-Server ebenfalls.uname hat geschrieben:29.05.2019 09:02:43Für Remote-SSH könnte man nur themporär zuhause den SSH-Server starten
OpenVPN öffnet gar keine Shell.und zudem reicht dem Benutzer die Shell /bin/false.
Ich will aber die Idee mit SSH nicht schlechtreden, die ist genauso machbar und sinvoll einsetzbar wie OpenVPN. Da soll sich der OP selbst entscheiden.
Re: Fernwartung im anderen Netz eines Raspberry Pi 3 mit Debian 9
Funktioniert dyn-dns mit LTE? Wenn ja, wäre das doch die einfachste Lösung: Man hängt einen LTE-Stick an den Pi, der damit direkt ins Internet geht. Damit umgeht man das ganze Gewurschte mit dem Handy als AP. Auf dem Pi läuft ein SSH-Server, der auf einem unüblichen Port lauscht und nur User-Logins zulässt. Dazu läuft ein dyn-dns-Client auf dem Pi, der den Pi über einen kostenlosen dyn-dns-Account erreichbar macht. Das könnte man dann natürlich auch noch per Cron auf bestimmte Zeitfenster beschränken.
Re: Fernwartung im anderen Netz eines Raspberry Pi 3 mit Debian 9
Das lässt sich meiner Meinung nach aber relativ einfach lösen. Ich würde dem Pi einfach nen billigen 3G-Surfstick gönnen, dort die Simcard einsetzen und schon kann man ihn On-The-Fly und nur bei Bedarf entweder via SMS oder telegram-Msg genau dann auffordern eine Verbindung aufzubauen, wenn man es braucht. Das bedeutet, allein die Bereitschaft in der Wartestellung ist somit kostenneutral für das Mobil-Guthaben.MSfree hat geschrieben:28.05.2019 16:17:53Die Frage ist nur, ob man mit LTE so eine Dauerverbindung hinbekommt oder ob einen die Mobilfunkanbieter nicht immer wieder rauswerfen. Und dann könnte das durchaus auch ein gewisses Datenvolumen verursachen, was entsprechende kosten bedeutet.
Das funkioniert meiner Meinung nach nicht.... und falls seitens des Mobilfunkbetreibers auch noch NAT dazwischen ist, sowieso nicht.
Zuletzt geändert von TomL am 29.05.2019 09:49:55, insgesamt 1-mal geändert.
Re: Fernwartung im anderen Netz eines Raspberry Pi 3 mit Debian 9
Mobilfunkverbindungen, egal ob GSM, UMTS, LTE oder G5, stecken fast immer hinter einem NAT-Gateway. Man kommt von aussen also nicht bis zum gewünschten Gerät durch.