Mit wem Verbindet sich der RevPi im Hintergrund? Datensicherheit?

[RevPiModIO]

Was ist "tunnel-start.sh", wohin verbindet er sich und WARUM?

Hat das was mit "https://www.revolutionpi.de/" zu tun?
Und warum muss man da bei der Kennwortvergabe dies lesen:
"numbers and letters only!"

SICHERHEIT???

Meiner persönlichen Meinung nach (kann jeder anders sehen) passt CLOUD einfach nicht zum RevPi! Kann sein, dass meine ABNEIDUNG der CLOUD daher kommt, dass ich in der Industrie arbeite und nicht in einer Bastelbude... Aber wenn ich Unilever, Thyssen oder Daimler einen RevPi vorstelle und der sich mit "tunnel-start.sh" in die Weiten der Welt verbinden will damit ALLE die Daten sehen können... ... EEHHHHH... NEIN?!?!?!

Für so einen Home-RevPi oder was ihr da vor habt, ist der IoT-Kram ja echt cool - Aber den INDUSTRIE-RevPi, baut BITTE für die Industrie und aktiviert da nicht von Haus aus irgendwelche Lösungen die sich ins Internet verbinden.

Was der RevPi für mich ist und was er richtig gut können soll? Anlagen mit mehreren Kilowatt Leistung steuern! Er soll Rückmeldungen erhalten und diese auswerten. Er soll Frequenzumrichter mit Analogwerten versorgen. Er soll analoge Werte empfangen können und noch mit anderen Bussystemen klar kommen. Er soll seine Werte/Daten für andere Systeme zur Verfügung stellen - für Visualisierungen, Auswertungen, opc-server usw usw... Von mir aus auch für Dienste, die die Daten dann in die Cloud jagen - aber das ist nicht SEINE Aufgabe...

Baut das Ding für die Industrie. Baut es SICHER. Lasst es nicht zu, das aus dem Internet auf das Teil direkt zugegriffen werden kann - Stichwort Sicherheitskameras

Das musste ich mir mal vom Herzen schreiben, als ich "CLOUD" las. Und ich würde mich freuen, wenn ihr uns aufklärt

Gruß, Sven

PS: Der RevPi ist das geilste was in der letzten Zeit entwickelt wurde!

[volker]

Hi Sven,
der Service, den Du ansprichst, kann seine Verbindung nur aufbauen wenn er a) aktiviert ist (was per Default bei ausgelieferten geräten der Fall ist) und b) wenn Du Dein spezielles Gerät unter Deinem Login auf dem KUNBUS Connection Server dafür freigeschaltet hast und c) wenn das Gerät einen Zugang zum Internet hat. Nur wenn diese 3 Bedingungen erfüllt sind, dann wird die Verbindung vom Pi zum Connection Server ausfgebaut und aktuell auch ausschließlich für das https Protokoll. Unser connection Server prüft bei der Anmeldung des Gerätes über den Cryptochip, ob es sich wirklich um das auf dem Server freigeschaltete Gerät handelt. Bei der registrierung auf dem Server muss der User sowohl die interne, als die externe Seriennummer angeben, wodurch der physikalische Besitz des Gerätes durch die Person, die den Login am Server besitzt, abgeprüft wird.
Wenn diese Tunnelverbindung aufgebuat wurde, dann kann der inhaber des Logins sich mit einem Browser am Connection Server anmelden und bekommt eine Liste seiner aktuell verbundenen Geräte. Er sucht sich eines aus und wird dann über https mit dem Webserver des Gerätes verbunden. Aktuell gibt es keine Möglichkeit mit vertretbarem Aufwand diese Verbindung irgendwie abzuhorchen. letztlich kommt sie allgemein anerkannten und als sicher eingestuften Verfahren des Online-Zahlungsverkehrs gleich.
Ich denke, dass Du mit deiner Einschätzung zur Cloud einen extremen Standpunkt einnimmst, den wir hier bei Revolution Pi anders wahrnehmen. Die nachfrage nach industrieller Cloudanwendung ist enorm und die Anfragen an uns sind vielfältig. Big Data und IoT sind ein Milliardenmarkt, dem wir uns nicht entziehen können und wollen. Daher zielt unser Projekt von Anfang an auch darauf ab, unseren Kunden die Werkzeuge in die Hand zu geben, Geschäftsmodelle in der Cloud zu entwickeln.
Wichtig ist uns dabei, dass unsere Verfahren so ausgewähkt wurden, dass sie dem aktuellen Sicherheitsstandards entsprechen und darüber hinausgehen. Die oben beschriebene Methode des Firewall-hole punchings spiegelt dies wieder und ungelich viel sicherer als sehr viele andere Produkte es realiseren.
Wichtig ist uns auch, dass Du als Kunde absolut selber entscheiden kannst, ob Du deine Geräte für diese neue Welt öffnen willst oder lieber nicht. Im Tutorial beschreiben wir auch, wie die veschiedenen Dienste (u.a. auch der Tunnel-Dienst) abgeschaltet werden können. Eine Trennung vom internet müsstest Du aber auch ohne die Abschaltung eh vornehmen, wenn Dir wichtig ist, dass von außen niemand jemals Zugriff haben kann. Eine Firewall ist nämlich auch nur so sicher, wie ihre Konfiguration korrekt ist. Auch die Anmeldung und die Beschaffung eines Logins auf unserem Connection Server ist nicht erforderlich für einen Betrieb, wie Du ihn beschreibst. Somit hast Du es selber in der Hand, ob Du eine klassische Steuerunngslösung aus Deinem RvePi machst, oder aber einen IoT Knoten.
Sicher werden wir diese dinge noch besser kommunizieren müssen und unsere Tutorials haben das bisher nur im Ansatz besprochen.

[Mathias]

wenn es dich stört, dann deaktiviere den Dienst einfach mit

Code: Select all

sudo update-rc.d tunnel-start.sh remove

[RevPiModIO]

Hi ihr Beiden!

Danke für die ausgiebige Antwort, trotz wenig Zeit wegen der Messe nächster Woche!

Ich finde die Möglichkeit die ihr da geschaffen habt, bzw. momentan entwickelt nicht wirklich schlecht. Und ich sehe es genau wie ihr, dass IoT wichtig ist und auch Cloud-Dienste ein gutes Geschäft sind/sein können.

Mein Standpunkt ist nur so "extrem", weil ihr uns da ein gutes Werkzeug liefert, welches einer Kettensäge für die eigene Firewall gleicht - und Kettensägen kaufe ich lieber im AUSGESCHALTETEN Zustand! Ihr ermöglicht es, dass man sich vom Internet auf den RevPi verbinden kann, der im EIGENEN Netzwerk steht - auf dem Linux läuft - und hebelt damit viele Sicherheitssysteme, die viel Geld und Zeit kosten aus. Bei nur einer Sicherheitslücke, die bei der Kennwortvergabe beginnt, ist der Angreifer drin.

Das Thema ist sehr sensibel, vor allem bei großen Unternehmen! Wenn wir denen da so einen RevPi einbauen und raus kommt, dass der sich mit dem Internet verbindet und man von außen darauf zugreifen kann haben wir vermutlich Klagen am Hals, weil wir die Datenschutzrichtlinien nicht eingehalten haben. Und warum haben wir die nicht eingehalten?

Weil der Dienst im AUSLIEFERUNGSZUSTAND ohne "Warnungen" auf Begleitpapieren AKTIV ist! Und das ist, was mich wirklich "ankotzt".

Die Idee dahinter finde ich genial und ich sehe auch das Potenzial, was dahinter steckt - da sind wir einer Meinung - Aber der Benutzer sollte diese Werkzeuge BEWUSST einschalten MÜSSEN, wenn er sie verwenden will!

Dann würde Mathias schreiben "wenn du es brauchst, dann AKTIVIERE den Dienst einfach mit..."

Ihr wollt in die Industrie, also raus aus eurem Labor

Gruß, Sven

PS: Mein Online-Zahlungsverkehr ist sicherer allein wegen dem Kennwort (Sonderzeichen)

[Ingo]

Hi,

da muss ich Sven Recht geben, liefert die Geräte lieber so aus das Dienste die sicht ins Internet verbinden Standart mässig ausgeschaltet sind aus. Es gibt genung beispiele von Herstellern wo es schon zu Angriffen von aussen gekommen ist wo genau diese Sachen offen waren. bestes Beispiel Loxone mit Ihrem Miniserver. Da konnten Leute die Ahnung davon haben ohne weiteres auf die Geräte zugreifen.

Warum muss ich die Daten vom Gerät überhaupt hinterlegen? nur um zu wissen das ich der eigentümer bin.
Was ist wenn ich das gerät mal verkaufe und der neue Kunde meldet sich dann dort an, wird ihm dann mittgeteilt das er nicht der rechtmässige Eigentümer ist, oder wie geht das?

Es ist echt eine Brisante Frage. Ihr habt doch die Daten eh schon sobald man eine Bestellung aufgibt wo auch die Serien nummer hinterlegt ist.
So schreibt ihr in eurem Blog was von Sicherheit. kann ja sein, aber wer will kommt auch drauf und da gibt es genug Spinner die nichts anderes zu tun haben als den lieben langen tag so etwas zu versuchen.
Also. Auslieferungszustrand aus und gut ist.
Ich geh ja auch nicht in einen Laden und kaufe einen Schraubenschlüssel und wenn ich auf die seite vom Hersteller gehe das sich der Schlüssel mit den verbinden muss um zu sehen das er mir gehört, oder?

in diesem Sinne
Viel Spass auf der Messe

[volker]

Hallo Sven,
lass mich bitte noch mal zwei Punkte richtig stellen, die so, wie Du sie schreibst, einfach nicht korrekt sind:
1) Niemand kann sich von außen mit dem Gerät verbinden in dem Zustand, in welchem es ausgeliefert wird. Zwar ist ein Dienst aktiviert, der in gewissen Intervallen versucht Kontakt mit einem Server aufzunehmen, aber das alleine ist noch lange kein offenes Tor für einen Zugang von außen! Wenn Du so argumentierst, dann müsstest Du konsequenterweise auch die Zugriffsversuche vom revPi auf den zeitserver zur Aktualisierung der Systemzeit unterbinden und per Default deaktivieren. Dies ist definitv nicht im Sinne der Mehrheit unserer Firmenkunden. Die Usability muss sich hier nach der Mehrheit der Kunden richten, nicht nach erhöhtem Sicherheitsbedürfnisse einzelner Kunden, die sich dann aber individuell entsprechende Einstellungen ohne großem Aufwand herstellen können. Wie schon gesagt, die Kommunikation an der Stelle müssen wir sicher verbessern, aber die Defaults entsprechen aktuell den Wünschen aus der Industrie (wir haben wirklich die "Großen" in unserem Kundenkreis).

2) Ein zentrales Passwort, welches Du benötigst, um auf das System zu kommen (SSH, Command Line, etc.) ist das Linux Passwort, welches selbstverständlich auch Sonderzeichen erlaubt. Das Passwort für den Zugang zum Webserver über https ermöglicht aktuell ausschließlich den Zugriff auf PiCtory und erfordert den lokalen Netzzugang zum Gerät. Wir werden über diesen eingebauten Webserver demnächst auch umfangreiche Konfigurationen des Systems erlauben. Spätestens dann aber wird die Passwortvergabe auch Sonderzeichen und wesentlich längere Passwörter erlauben. Ob der user dies dann nutzt, ist ihm überlassen. Generell ist aber aus wissenschaftlichen Untersuchungen bekannt, dass die Vergabe von kryptischen langen Passwörtern mit Sonderzeichen statistisch gesehen eher Sicherheitsprobleme bringt, weil user dann dazu neigen, diese passwörter in geschriebener Form in Nähe des physikalischen Zugangs aufzubewahren. Leider ist das Argument "selber Schuld" dann nicht relevant, denn es kommt uns bei dem Thema Sicherheit darauf an, unter dem Strich für die Gesamtheit aller User eine Lösung zu finden, die statistisch ein maximum an Sicherheit bringt. Dies bedeutet als Konsequenz, dass wir Sonderzeichen und lange PW erlauben, aber nicht erzwingen werden.

3) Unsere KUNBUS Cloud verwendet einen komplett anderen Zugangsmechanismus, bei ebenfall der Verbindungsaufbau nur vom Gerät ins Internet, aber nicht anders herum erfolgen muss. Die Zertifkate müssen dabei physikalisch vom user selber auf das Gerät kopiert werden. Der Zugang zum Cloud Account ist dabei selbstverständlich über Passwörter geregelt, die dem aktuellen Stand der Sicherheit entsprechen.

Ich hoffe, Du siehst, dass wir hier nicht "Labor" und Experimente auf den Markt bringen. Wir hatten einen der anerkanntesten Sicherheitsberater für IT bei uns an Bord, als wir die Lösungen designed haben und alles ist gründlich durchdacht und für alle Entscheidungen gab es wichtige und gute Argumente. Sicher kann es sein, dass wir da an der ein oder anderen Stelle noch Bedarf an Korrekturen haben (u.a. zählt das aktuelle PW beim Webserver auf dem Gerät dazu). Wir sind auch froh um jeden Kommentar inder Community, der auf solchen Korrekturbedarf eingeht. Das Du persönlich Entscheidungen anders treffen würdest respektiere ich und die Möglichkeiten dazu wollen wir ja auch allen Kunden geben. Aber Du solltest auf der anderen Seite auch sehen, dass Deine Auffassungen dazu durchaus nicht der aktuelle mehrheitliche Stand der Sicherheitsdiskussionen in der Industrie sind, sondern dass es dort wohlüberlegte andere Auffassungen zu bestimmten Detailfragen gibt.

[volker]

Hallo Ingo,

ich weiß nicht, von welcher Abfrage durch uns Du sprichst, aber ich vermute, dass es um die Lizenzvergabe von logi.cad geht. Hier ist der nachweis, welches gerät Du besitzt deshalb wichtig, weil die logi.cad Lizenz nur für dieses eine Gerät funktionieren soll. Wenn Du das gerät verkaufts, funktioniert es natürlich immer noch mit derselbe Lizenz.

solltest du aber von dem Account auf dem Connection Server sprechen, so ist die Eingabe des Geräteschlüssels wichtig, um festzustellen, dass die person, die gerade das Gerät dem eigenen Accoutn zuordnen will, auch im Besitz des Gerätes ist, denn nur, wer im besitz ist, kann den Geräteschlüssel auslesen. Wenn Du ein Gerät wieterverkaufst, kann der neue Besitzer dieses Gerät seinem Account zuordnen, dann hast Du keinen Zugriff mehr mit Deinem Account. Der letzte Besitzer ist daher immer in der Lage, den Zugang vom Vorbesitzer zu löschen und einen eigenen zu aktivieren.

Loxon hatte eben genau all diese Überlegungen nicht angestellt. Der eigentliche Fehler von Loxon war aber, alle geräte mit ein und demselben Zugangspasswort auszuliefern und es dem user zu überlassen, dieses abzuändern. Genau diesen Fehler gibt es bei uns nicht. Daher ist der Vergleich nicht schlüssig.

Und ein gaz kalres NEIN: wer will, kommt eben nicht auf unser System! Dies wird nach Abschluss aller neuen SW-Änderungen dann z.B. von einer Firma geprüft, deren Spezialität es sit, mit Top-Hackern solcher Systeme zu knacken um uns dann im einem Security Report Empfehlungen für das Schließen von eventuell bestehenden Sicherheitslücken zu geben.

[RevPiModIO]

Ehhh... Ich will kein Spielverderber sein, ABER kann es sein, dass dieser tunnel-start.sh trotz:

Code: Select all

sudo update-rc.d tunnel-start.sh remove

sich weiterhin alle 10 Minuten durch den root-crontab versucht zu verbinden???

Code: Select all

*/10 * * * * /etc/init.d/tunnel-start.sh check

Screenshot_20170315_102508.png (8.34 KiB) Viewed 12717 times

Weil im init-script mit Aufruf "check" das Script dennoch gestartet wird, wenn der Prozess nicht läuft?

ALSO muss man, wenn man den Kram WIRKLICH deaktivieren will folgende Schritte machen:

Code: Select all

sudo update-rc.d tunnel-start.sh remove

sudo crontab -e

Im Editor dann ein # vor die Zeile:

Code: Select all

*/10 * * * * /etc/init.d/tunnel-start.sh check

packen:

Code: Select all

#*/10 * * * * /etc/init.d/tunnel-start.sh check

Und erst dann ist es wirklich deaktiviert, ja?

Gruß, Sven

[Mathias]

Hallo Sven,
du hast vollkommen recht. Ich habe neulich nicht daran gedacht, dass es ja auch noch den Cron-Job gibt. Entschuldige bitte vielmals.
In der nächsten Release werden wir solche Dienste nicht mehr standardmäßig starten, sondern eine Konfigurationsseite implementieren über die man sie aktvieren kann.
Gruß
Mathias