fischertechnik community forum

Im tx-pi-Thread kam das Thema "Schutz vor Netzwerkzugriffen" ja gerade wieder auf.

Es geht dabei um Zugriffe von außen auf den TXT. Ausgehend darf der TXT alles und da sehe ich auch keinen Bedarf irgendwas einzuschränken. Eingehend haben wir z.Zt mindestens ssh, www, das launcher-Kommandointerface, VNC und meine Websocket-Apps, allen voran Brickly.

Auf der einen Seite kann man natürlich wie es im Internet üblich ist jeden einzelnen Dienst absichern. Das scheitert m.E. bei uns schon an der Man-Power. Aber wir haben einen großen Vorteil gegenüber allen Servern dieser Welt: Wir haben immer auch physischen Zugriff auf den TXT und genau das unterscheidet uns von irgendwelchen fiesen Leuten im gleichen WLAN. Das hat Richard ja im Falle von SSH auch schon genutzt und der TXT fragt ja lokal nach einem OK, wenn man ohne gesetztem Password per SSH von außen auf den TXT zugreifen will.

M.E. ist der einzig realistische Weg, dieses Konzept zu vereinfachen und auf alle Netzwerkdienste auszuweiten. Das hieße z.B. direkt nach dem Einschalten zunächst jeglichen eingehenden Netzwerkzugriff zu verbieten. Die dazu nötigen Tools wie iptables sind m.E. bereits alle in der CFW eingeschaltet. Sobald ein Programm von außen auf den TX T zugreifen will erfolgt am TXT die Frage "Netzwerkzugriff erlauben?" Ja/Nein. Wenn man auf "Ja" klickt ist sämtlicher Netzwerkzugriff (nur von diesem Gerät?) erlaubt solange der TXT eingeschaltet ist. Nach einem Reboot geht das Spiel von vorne los.

Ich persönlich fände es schick, wenn man sein Heim-Netzwerk irgendwie identifizieren könnte und sagen könnte, dass man dort generell Netzzugriff erlaubt. Aber wie erkennt man sein Heimnetzwerk?

Problem dabei: Wenn eine App (speziell die Original-GUI) läuft kann man den Dialog nicht so ohne weiteres einblenden und z.B. den RoboPro-Zugriff kann man dann kaum erlauben.

M.E. sollten wir versuchen, dass ganze Konzept einfach und universell zu halten. Da mit neuen Tricks auf jeden neuen Dienst zu reagieren werden wir kaum hinbekommen und wir enden in so kaputten Situationen wie wir sie mir dem VPN hatten.

Ein wichtiges Thema!
Solange ich den TXT in meinem eigenen WLAN betreibe, kann ich ja nur aus diesem auf den TXT zugreifen, z.B. Brickly starten, oder?
Wenn ich ihn jetzt in ein anderes WLAN einhänge, kann jeder aus diesem WLAN auf ihn zugreifen. Das könnte ja z.B. in einer Schule nervig sein.
Kann man sich denn eine Situation vorstellen, wo der TXT im Internet hängt und von jedem Rechner der Welt aus zugängig ist? Dann könnte man Blödsinn mit ihm veranstalten, mit Kamera und Mikrofon arbeiten oder den armen Kerl zu einem Bot machen.
Mir persönlich wäre es vor allem wichtig, dass die CFW nicht die gespeicherten WLAN-Passwörter verrät.
Welche anderen Szenarien sind denkbar?

Gruß
Esther

Dein WLAN ist in der Regel ein "privates Netzwerk" mit einem sog. privaten (nicht ins Internet vermittelten) Adressbereich und ohne Tricks nicht aus dem Internet erreichbar. Dazu müsste Dein DSL-Router mitspielen und Zugriffe von außen auf Deinen TXT weiterleiten. Sowas kann man bei fast allen DSL-Routern einstellen. Das nennt sich "port forwarding" https://de.wikipedia.org/wiki/Portweiterleitung . Bei irgendwelchen billihgen Plasteroutern lässt sich sowas ggf auch von außen aus dem Internet machen. Zusätzlich kann es natürlich immer vorkommen, dass Leute sich aus der Nähe direkt in Dein WLAN schummeln. Tatsächlich ist diese Gefahr aber m.E. vergleichsweise gering. Darauf zielte ja auch meine Frage nach der Freischaltung für's Heimnetz.

Der echte Problemfall sind genau die von Dir erwähnten Schul- und Firmen-WLANs oder WLANs auf Messen und Conventions. Gerade auf Messen und Convetions wird sich immer einer finden, der mit einem halben Auge mitbekommen hat, dass Du da einen TXT betreibst und dann mal eben mit passenden Tools nach ungeschützten Zielen sucht. Der findet Deinen TXT recht schnell und kann dann prima rumstänkern. Für das Szenario würde dann einmal der "Netwerkzugriff erlauben?"-Dialog auftauchen, wenn da jemand zuzugreifen versucht. Und wenn Du weisst, dass Du selbst das gerade nicht bist, dann klickst Du auf "Nein" und hast erstmal Ruhe.

Ich finde die Idee super.

Ich habe das mal testweise umgesetzt, im nächsten Weekly-Build wird es drin sein.

Sobald von extern auf den TXT zugegriffen wird erscheint folgender Dialog:
Man kann dann auf eines der beiden Icons klicken. Ab dem Moment darf dann das anfragende Gerät ohne weitere Nachfragen zugreifen bzw. nicht mehr zugreifen. Sobald mal den TXT neu bootet beginnt das Spiel von vorne.

Das macht der TXT an der Mac-Adresse und der IP-Adresse des anfragenden Geräts fest. Wenn man also auf einer Messe ist, wo sich auch mal die IP-Adresse ändern kann, dann führt eben diese Änderung dazu, dass man nochmal gefragt wird. Und wenn jemand "meine" IP-Adresse zugewiesen bekommt kann er trotzdem nicht auf meinen TXT zugreifen.

Das ist ein erster Test. Probiert es mal aus. M.E. können wir mit sowas z.B. auch VNC erlauben. Ja, man kann MAC-Adresse verändern und wenn jemand weiss, welche Adresse ich für meinen TXT zugelassen habe, dann kommt er mit geringem Aufwand an dieser Sperre vorbei. Aber m.E. haben wir nicht die Man-Power, um das Ganze besser und sicherer zu machen und trotzdem die spaßigen Dinge wie VNC zu erlauben.

Man könnte später noch ermöglichen, diese Sache optional permanent zu machen. Also wenn man dann z.B. vor dem Klick auf den grünen Button einen Haken bei "für immer merken" setzt, dann merkt sich der TXT das über den Neustart hinaus oder so. Und es geht auch grafisch ganz fehlerfrei nur mit echtem CFW-Apps. Bei der Original-FT-GUI schaut z.B. die Uhr oben rechts durch. Aber das ist m.E. zu verkraften.

Schaut's Euch mal an, ob wir das lassen sollen oder ob Euch was besseres einfällt ...

Hallo,

ich finde deine Idee super, vor allem ist das auch einfach umgesetzt. Fürs erste reicht das auf jeden Fall, man muss ja nicht mit Kanonen auf Spatzen schießen. Den m.E. wichtigsten Zugang SSH kann man ja ausreichend mit Passwort/Key vor Fremdzugriff sichern.



olagino

Hallo MoG,

sieht super aus.

Ein kleiner Verbesserungsvorschlag: Wie wäre es statt dem generischen "Netzwerkverbindung zulassen" mit einem je nach Port passenden Text für die bereits bekannten Services? Also z.B. "SSH-Verbindung zulassen" für Port 22, "RoboPro-Verbindung zulassen" für Port 65000, ...

Zur Zeit lässt man sämtliche Netzwerverbindungen mit einem Ok zu. Ich habe kurz darüber nachgedacht, das pro Anwendung/Port zu machen. Aber das ist m.E. ein zu seltener Spezialfall. Wann/warum sollte ich nur eine bestimmte Anwendung zulassen wollen?

Hallo!

Tolle Sache!

Wann/warum sollte ich nur eine bestimmte Anwendung zulassen wollen?

Nun ja, machst Du das Scheunentor immer komplett auf?
Bei einer Firewall lässt man nur die Ports zu, die man auch nutzt.
Beispiel: Ich will nur SSH nutzen. Warum soll dann Port 80, ... offen sein?
Da reicht es doch wenn der Port 22 offen ist. Mehr ist ja nicht nötig.

Gruß
sven

Das Scheunentor ist doch gar nicht komplett auf. Es läßt nur die Verbindungen einer MAC mit dem TXT zu. Da sehe ich überhaupt kein Problem, es sei denn, daß das entsprechende Gerät verwurmt ist und per Portforwarding oder so auf den TXT zugreift. Ähem, und dann hat der geneigte User andere Probleme...

Gruß
Peter

Ich bin offen für Anregungen bzw. jeder kann seinen eigenen Ideen einfach einpflegen.

Aber wir sollten im Hinterkopf behalten, dass das (auch) für Kinder ist. Zuviele zu unverständliche Nachfragen sind da ggf. ein Problem.

Zu der Absicherung einzelner Ports: Brickly verwendet zwei Ports, würde also zweimal nachfragen. Boa verwendet sogar drei, würde also dreimal nachfragen. Nun könnte man automatische Abhängigkeiten irgendwo hinterlegen ("wer WWW öffnet darf auch die VNC- und Brickly/Boa-Sachen benutzen"). Sowas könnte man im Manifest hinterlegen.

Aber brauchen wir das wirklich? Gehen wir davon aus, dass ein Angriff von genau dem Gerät aus erfolgt, mit der Benutzer selbst gerade zugreifen will? Also mit dem gehackten PC, den Peter beschreibt?

Könnten wir die IPTABLE noch abspeichern?
Das hin-und-hergelaufe zum TXT ist doch etwas nervig.

Jetzt haben wir schonmal Sven, der mehr Rückfragen will und Raphael, der weniger will. Solange es keinen Kompromiss gibt wird es nicht weiter gehen.

Dann soll man das einfach konfigurieren.

Zuhause soll das bitte ganz weg und meinem Handy soll es egal wo immer vertrauen.

Ich persönlich würde dafür tendieren, dass man das System so lässt, wie es im Moment ist. m.E. ist das genügend Sicherheits-Schikane für einen möglichen Angreifer, feiner aufgedröselt (also Ports etc.) hat man das ja auch nicht an einem normalen Rechner, den man bei so Events ins Netz hängt, oder?

olagino hat geschrieben:Ich persönlich würde dafür tendieren, dass man das System so lässt, wie es im Moment ist. m.E. ist das genügend Sicherheits-Schikane für einen möglichen Angreifer, feiner aufgedröselt (also Ports etc.) hat man das ja auch nicht an einem normalen Rechner, den man bei so Events ins Netz hängt, oder?

Meine volle Zustimmung!

Ich möchte das System grundsätzlich so lassen wie es ist. Zusätzlich möchte ich noch zwei Punkte ergänzen:

• Trusted Devices: wenn man im Bestätigungsdialog lange auf den grünen Haken drückt, kann man das Gerät nach einer Abfrage als sicher abspeichern. Von nun an werden alle Verbindungen dieses Gerätes immer akzeptiert. Das würde ich auf MAC-Basis machen.
• Trusted Networks: in einer neuen App kann man dann die Geräte und Netzwerke verwalten. Auf Basis der MAC-Adresse des Gateways kann man ein Netzwerk als sicher einstufen. Von nun an werden alle Verbindungen in diesem Netzwerk automatisch akzeptiert.

Das Ganze zu implementieren sollte kein großes Problem darstellen. Bloß wo kann man sicher die Konfigurationsdatei ablegen?

Der normale Anwender hat so überhaupt keine Sicherheitseinbußen, wenn er nichts als "Trusted" hinzufügt. Für Conventions o.ä. wäre ein spezieller Modus denkbar, indem nur trusted devices möglich sind. So hat man keine unnötigen Rückfragen.

Raphael

P.S. Wie machen wir das jetzt mit dem VNC? Ein zugelassenes Gerät konnte so jetzt auch Anfragen anderer Geräte umgehen.

ski7777 hat geschrieben:Das Ganze zu implementieren sollte kein großes Problem darstellen.

Na dann mal los!

Ich denke es gibt eine Mehrheit für "erstmal so lassen wie's ist" und Raphael baut sich einfach seine persönliche Variante, die ihn weniger nervt.

ski7777 hat geschrieben:wenn man im Bestätigungsdialog lange auf den grünen Haken drückt ...

Sowas wie "lange auf den grünen Haken drücken" ist unüblich. Bei App- und Datei-Icons ist das vor allem auf Handies gängig aber bei Bestätigungsknöpfen nicht. Also würde a) keiner von sich aus drauf kommen, dass da noch eine Funktion verborgen ist und b) würde sich jeder der dann doch mal lange drauf klickt wundern, was denn nun passiert ist. Sowas wie "Entscheidung merken" oder "nicht mehr nachfragen" macht man üblicherweise mit einer Extra-Checkbox.

Natürlich kann man ganz neue GUI-Konzepte entwickeln, aber unser Nischenprodukt lebt m.E. davon, dass die Bedienung vor allem für Windows- und Handy-User halbwegs offensichtlich ist.