Sanitycheck und Passwort fuer Bricks beim Zugriff "von aussen"

Hallo Tinkerforge, hallo borg,

wie bereits in dem Beitrag angesprochen waere ein Sanitycheck prima, da man mit einem "falschem" Paket den Brick zum Absturz bringen kann.

Aber genauso wichtig waere in diesem Zusammenhang eine Passwortoption, insbesondere im Hinblick auf den Ethernet/Wlan Brick. Warum?

Ich moeche an einigen Standorten diese "autonomen" Bricks anklemmen und im dortigen Router nur ein Portforwarding einbauen. So kann man remote Temperaturwerte auslesen, Messages aufs Display schicken oder LEDs anmachen.

Aus "Angst" vor Portscannern, die wilde Pakete losschicken und somit die Bricks zum Absturz bringen koennen, koennte der Sanitycheck gleich auch ein hinterlegtes Passwort pruefen. Von mir aus 4-stellig und nur Zahlen oder 16-stellig und Alphanumerisch.

Eine Idee dazu:

Default Passwort koennte "0000" sein. Wenn das Defaultpasswort gesetzt ist, werden beim Sanitycheck auch Anfragen ohne Passwort akzeptiert. Damit bleibt die neue Brickfirmware kompatibel zu bisherigen Programmen.

Wenn das Brickpasswort ungleich "0000" ist werden Pakete nach dem bisherigen Muster verworfen und nur Pakete mit dem neuen Aufbau akzeptiert und bei passendem Passwort weiterverarbeitet.

Der Paketaufbau koennte so sein: ID:FUNKTION:LAENGE:PAYLOAD:PASSWORT

Das sollte problemlos kompatibel zu machen sein. Eleganter find ich die Reihenfolge PASSWORT:PAYLOAD. Da muss aber euer Parser mehr machen.

Das Aendern des Passwortes koennte man so gestalten, dass es nur in der ersten Minute nach Power on oder ueber einen anderen IP Port moeglich ist.

Der Loetkolben

Das finde ich ehrlich gesagt eine recht wichtige Option, eine entsprechende Umsetzung würde ich befürworten. Ich habe selber den Plan, bald ein paar TF-Sachen zu bauen, die per W-Lan angeschlossen sind und als "Sateliten" arbeiten, und das in einer Umgebung, wo ich schon öfters die Erfahrung gemacht habe mir "Wardrivern" etc. Wenn jeder Portscan direkt zum Absturz führt, ist das ärgerlich. Das PW muss ja nicht extrem sicher sein, sollte aber ein "Stören im Vorbeigehen" unterbinden.

Wenn jeder Portscan direkt zum Absturz führt

Das habe ich so nicht gesagt. 

Wenn jemand einen Portscan ausfuehrt und dann (wilde) Pakete schickt, dann kann es sein, dass die Bricks abstuerzen. Einen reinen Portscan wird der Stack wohl ueberleben.

Ein Sanitycheck wuerde ja schon reichen um den Absturz zu verhindern, aber ein zusaetzliches Passwort schuetzt auch vor "Missbrauch" Dritter die wissen, dass dort ein Brick haengt.

Der Loetkolben

Ah ok, danke für die Aufklärung. Hatte das falsch verstanden.

Trotzdem bleibe ich dabei, dass ich das gut fände. Aufgrund aller von uns (dir) genannten Gründe.

Eine robustere Firmware ist definitiv geplant und wir sind auch schon Stück für Stück dabei den kram robuster zu machen. Um zu verhindern das Pakete die ausversehen an den brickd Port geschickt werden etwas zum abstürzen bringen, brauchen wir kein zusätzliches Passwort.

Wenn es dir nicht um "safety" sondern um "security" geht, hilft kein Passwort was als Plaintext an das Paket angehängt wird. So ein Passwort würde Sicherheit vortäuschen aber keine bringen.

Die WLAN Extension wird WPA2 können, das bringt Sicherheit. Wenn du über das Internet etwas steuern möchtest und den Port nach außen frei gibst, gibt es Möglichkeiten wie VPNs oder SSH Tunnel.

Um das nochmal klar zu machen: Wenn wir an unsere Produkte schreiben das sie "mit Passwort kommen" und Zugriffe von dritten verhindern etc. müssen sie auch echten Angriffen statthalten können.

Um das wirklich sicherzustellen müsste man schon eines der bekannten Verschlüsselungsverfahren verwenden (AES, Blowfish etc). Da fehlt uns dann aber wiederum die Expertise um das richtig zu tun (guckt euch einfach an wie oft auch jetzt noch Fehler in openSSL gefunden werden).

Also: Wenn es nicht um "safety" sondern um "security" geht, bitte sowas wie WPA, SSH oder VPN verwenden! Möglichkeiten eine TCP/IP Verbindung sicher zu machen existieren wie Sand am Meer.

Die WLAN Extension wird WPA2 können, das bringt Sicherheit. Wenn du über das Internet etwas steuern möchtest und den Port nach außen frei gibst, gibt es Möglichkeiten wie VPNs oder SSH Tunnel.

Hallo borg,

wird die WLAN-Extension auch WPA2-Enterprise unterstützen?

Gruß

Hallo borg,

danke fuer die Mail. Deinen Ausfuehrungen stimme ich zu, aber wir reden ein wenig aneinander vorbei.

Eine robustere Firmware ist definitiv geplant und wir sind auch schon Stück für Stück dabei den kram robuster zu machen. Um zu verhindern das Pakete die ausversehen an den brickd Port geschickt werden etwas zum abstürzen bringen, brauchen wir kein zusätzliches Passwort.

Das sehe ich auch so.

Bezueglich WLAN ist WPA/WPA2 Pflicht, aber auch hier koennte ein "Passwort" gegen Spielkinder im eigenen Netz helfen, bzw. die Huerden hoeher setzen. Ohne Passwort koennten Kinder mit dem brickv Problemlos den Stapel steuern, mit Passwort muessten sie zumindest per WLAN sniffing das Netz ueberwachen und dann noch die richtigen Schluesse aus dem IP Dump ziehen.

Ich spreche aber hier ueber den _kostenguenstigen_ Zugriff uebers Internet. Wenn die Bricks OpenVPN sprechen koennten waere ich begeistert, aber ich glaube das ist wohl nicht Aufgabe der Bricks. Fuer den Zugriff auf ein paar LEDs oder ein Temperaturbricklet extra einen VPN Server/Router hinzustellen sprengt aber die Kosten und den Administrationsaufwand.

Das zusaetzliche "Passwort" wuerde natuerlich im Klartext uebers Internet uebertragen, aber warum auch nicht? Mir geht es darum "Experten" und Spielkinder abzuhalten die wissen dass dort ein Stapel erreichbar ist und nun versuchen daran per brickv rumzuspielen. Um das Klartextpasswort abzufagen muessten sie irgendwo Zugriff zwischen Provider und Hausanschluss haben. Das ist aber wohl extrem unwahrscheinlich. Wer die 100% Sicherheit haben muss, kann ja gerne einen VPN Router installieren.

Versuchen wir es mal so und nennen es nicht "Passwort":

Nennen wir es "Logical Address Key". Jedem Stapel kann man einen frei waehlbaren "Logical Address Key" geben. Wenn der "Logical Address Key" im TCP Paket mit dem im Brick gespeicherten Key zueinanderpasst werden die Pakete durchgelassen.

Der Loetkoben

Ich kann den Wunsch nachvollziehen, bin aber absolut kein Fan von "schlechter security", was das wäre.

Ich werde das morgen mal mit den anderen TFlern hier diskutieren, die können mich dann überstimmen .

@Einstein: Das RN-171 Modul (welches unser Momentan aktueller Prototyp nutzt) kann leider kein Enterprise WPA-PSK

Hallo borg,

ich freue mich, dass du meinen Wunsch verstehst.

Echte Security ist das nicht, aber macht den Gebrauch etwas "stabiler". Noch ein schoener Name: "Brick Match Code"

Danke.

Der Loetkolben

@Loetkolben: Hast du schon einen Stapel Router rumzuliegen bzw. dort wo der Einsatz geplant ist installiert? Für den Fall, dass du diese noch erwerben müsstest gäbe es grundsätzlich zwei Optionen die ohne TF-UNterstützung laufen:

- Der Router kann selbst VPN (etwa Fritzboxen)

- Es gibt erweiterbare Firmwares (etwa OpenWRT) für den Router, dann kannst du entweder auch dort VPN oder aber einen Wrapper für die Brick(let)s installieren (der beispielsweise eine Prise Security hinzugibt)

Ich denke das Problem ist, dass die Bricks ursprünglich nicht dafür gedacht waren nackig irgendwo aufgestellt zu werden. Ich gebe dir aber recht, dass das oft die einfachste/günstigste Lösung ist, wenn man mehrere Sateliten hat.

Hallo AuronX,

danke fuer die Info. Deine Argumente kann ich zum Teil verstehen, aber auf der anderen Seite moechte ich nicht jedes "fremde" Lan per VPN mit meinem Lan verbinden nur weil ich einen Stack ansprechen will.

Fuer einen Standort mit VPN waere dies eine Aufgabe: Wie bekomme ich ein OpenVPN auf eine "Fritz!box Fon Wlan"?

Ansonsten habe ich noch einen "Thomson irgendwas Router" im Angebot. Mit Glueck koennen die ein Portforwarding.

Sicher waren die Bricks anfaenglich dafuer nicht gedacht, aber man denkt ja weiter.

Der Loetkolben

Sicher waren die Bricks anfaenglich dafuer nicht gedacht, aber man denkt ja weiter.

Habe meine Aussage auch absichtlich mit "ursprünglich" angereichert

Wegen Fritzbox: Ich habe die 7390 und ehemals die 7270 im Einsatz, beide haben VPN onboard, ich glaube über IPSec, aber da lehne ich mich schon aus dem Fenster ^^ Zumindest irgendeinem externen Standard entsprechend, also nix von AVM selbst geschustertes. Kann aber durchaus sein, dass die kleineren Boxen das nicht können. Welche Fon WLAN hast du?

Sollte ja auch nur eine Idee für den Fall eines "Nein" von TF sein ^^

Welche Fon WLAN hast du?

Eine "Fritz!Box Fon Wlan" eben.

Da gab es noch keine Nummern. Steht nicht bei mir, sondern an einem anderen Standort. Diese Boxen haben noch nie was von VPN gehoert und man muss viel fummeln um da ein VPN anzuflicken.

Wie gesagt: Portforwarding koennen die Fritzboxen schon ewig.

Der Loetkolben

 

@Einstein: Das RN-171 Modul (welches unser Momentan aktueller Prototyp nutzt) kann leider kein Enterprise WPA-PSK

Mhh das is natürlich schlecht...würde mir nur eine zweite SSID übrigbleiben nur für die Bricks.

IMHO würde auch eine in der Netzwerktechnik gebräuchliche Absicherungsmethode (nur gegen unbemerkte Manipulation!) genügen:

Der MAC-Code (hat nichts mit Hardware MAC zu tun, sondern ist ein "Message Authentication Code", der schlicht aus einem HASH der Nachricht abgeleitet wird.

Dazu müssen beide Parteien (Sender und Empfänger) einen z.B. 32 Bit Schlüssel kennen, der z.B. im TF hinterlegt wird und im Programm benutzt wird.

Das Programm (der Dämon in diesem Fall) berechnet für jedes gesendete Paket die Prüfsumme und hängt diese als MAC an die Payload an.

Der Parser beim Empfänger macht das auch und vergleicht mit dem empfangenen MAC. 

Passt er, wird gearbeitet, passt er nicht, geht das Paket ohne viel "Federlesens" in die ewigen Jagdgründe...

Ist ein symmetrisches Verfahren mit beherrschbaren Aufwänden und verlangt halt nach Einbringen des Schlüssels (für das XOR mit dem Basis-Hash (einer aus AES/MD5/SHA/...)) auf beiden Seiten.

Aber auch nicht zwingend, denn viele Nullen sind schon fast ein wenig eine Eins ;-)

Wenn der Defaultschlüssel binär 0 (z.B. 32 Bit) beträgt, ergibt ein XOR damit einfach den mit dem vereinbarten Verfahren ermittelten HASH. Und der ist ziemlich eindeutig.

Und er reicht als MAC in der Regel schon dicke aus, um gegen Übertragungsprobleme und "Möchtegern Hacker" zu schützen... 

Dafür gibt es eine zuverlässige Ausscheidung von "Ramsch" und transportiert keine Passwörter im Klartext in der Gegend umeinander.

Bei erhöhtem Aufkommen von Paranoia kann auch "a grain of Salt" hinzugefügt werden.

Ich denke, dass die Authentifikation der "guten" Pakete in jedem Fall (jedenfalls bei allen mir derzeit einfallenden Anwendungen der TF-Module) ausreichend sein sollte.

Damit wäre auch das Port-Forwarding ausreichend und mithin so alles, was sich halbwegs aktuell heute als Router bezeichnet, nutzbar.

Einer späteren Ausweitung auf bestimmte Teile der Informationen oder gar  der gesamten Nachricht als Verschlüsselungslösung sollte damit auch (außer Speicher und/oder Prozessor) nichts im Wege stehen.

Dietmar

Hallo Dietmar,

danke fuer die Info, aber ich moechte das nochmals fuer mich zusammenfassen:

Deiner Meinung nach soll an jedes Paket (in beide Richtungen) ein Checksumme angehaengt werden, die aus dem Paketinhalt und einem geheimen Key gebildet wird.

Der Key steckt auf der einen Seite im Ethernetbrick/Wlanbrick/brickd und auf der einen Seite im PC Programm. Damit kann ein empfangenes Paket geprueft und bei gueltiger Pruefsumme weiterverarbeitet werden. Der Inhalt selbst wird weiterhim im Klartext uebertragen.

Wenn dem so ist, dann erfuellt das zu 120% meine Wuensche und kann ggf. auch noch Tinkerforge ueberzeugen. 

Danke.

Der Loetkolben

Es würde reichen, wenn diese MAC-Bildung im brickd ("PC") und im WLAN/ETH-Modul stattfinden würde.

Somit wäre der gesamte Vorgang völlig transparent für Anwendung und Master.

Initial könnte XOR 0 verwendet werden - so lange, bis ein anderer Key hinterlegt (brickd.conf), bzw. via USB auf den Master eingebracht wird.

Ist eine gängige Methode und läuft/lief millionenfach selbst mit schwachbrüstigen MPUs/HSM.  Woher ich das so sicher weiß:  (NDAs)

Dietmar

Es würde reichen, wenn diese MAC-Bildung im brickd ("PC") und im WLAN/ETH-Modul stattfinden würde.

Ich habe nicht verstanden warum es aussreicht es nur dort stattfinden zu lassen.

Meinst du das berechnen und verschicken oder das entrechnen und verarbeiten?

Der Loetkolben.

Es reicht, wenn das immer nur die Kommunikationsprozesse machen.

Für die Applikation oder das Bricklet ist das völlige Nebensache.

Wenn das jeweils in den "Kommunikationsstack" (also an der "Außenkante" der Kommunikationsbeziehung) eingebaut wird, habe ich -als willkommenen Nebeneffekt- keinerlei Aufwände in der Applikation.

Ich kann mich dann einfach darauf verlassen, dass Pakete, die ankommen, schon richtig gekennzeichnet waren.

Und die nicht richtig gekennzeichneten: Don't care. Hacker oder fehlerhafte Übertragung...

Hallo macdiverone,

das verstehe ich, aber es muss doch auf beiden Seiten des Uebertragungsweges passieren nicht auf beiden Ebenen einer Seite oder?

Also: Zum einem auf dem PC, der die Paket verschickt und zum anderen Auf dem brickd/Ethernet/Wlanbrick wenn er Pakete verschickt. Dass das nicht in den Applikationen gemacht werden muss ist mir schon klar.

Wenn ich selbst IP Pakete erzeuge muss ich natuerlich selbst die Aufgabe des Stacks uebernhemen. 

Der Loetkolben

Klar,

einmal im brickd und einmal im WLAN-Empfangs-Board...

Hallo macdiverone,

kann es sein, dass du den Tinkerforgesoftwareweg nicht so genau kennst?

Das WLAN-Board ersetzt den sonst benoetigten zusaetzlichen brickd. Ein Wlan-Board wird nie mit einem brickd kommunizieren.

Ich unterstelle mal die meinst mit brickd die Bindings?!

[Application-->Binding] --->TCP/IP---> [brickd-->Masterbrick]

[Application-->Binding] --->TCP/IP---> [ETHERNETextension-->Masterbrick]

[Application-->Binding] --->TCP/IP--->WLAN---> [WLANextension-->Masterbrick]

Der Loetkolben

Genau so wie es Loetkolben beschreibt ist es korrekt ^^

Das heißt für die Anwendung ist es noch immer halbwegs transparent. Allerdings muss sie der IPConnection den Key mitteilen, an der Stelle muss die Anwendung also bescheid wissen.

Bingo! Ich habe den durch die Bindings erzeugten TCP/IP-Übergang (für die noch nicht erhältlichen Module) UND den existierenden brickd gemeint!

Und fleißig ausschließlich brickd (vermutlich, weil der entsprechend agiert und den Übergang vom brick via TCP/IP an ein System mit angeschlossenen USB-TF-Modulen realisiert) geschrieben...

Alle Übergänge müssen an der jeweiligen Mediengrenze zu TCP/IP dieses Verfahren (und einen ggfs. von 0 abweichenden Schlüssel + "the grain of Salt") kennen und beherrschen.

Aber eben nur dort.

Und: In der Regel dürfte schon der "Default key: 0" ausreichend sein, um Unfug zu erkennen.

Damit wäre dann normalerweise weder in der Anwendung, noch sonstwo etwas zu ändern oder einzutragen...

Dietmar