? Zwei Pis verbinden ?

Quote from RaspberryBaum

Danke für die guten Ratschläge. Ich habe mir die Möglichkeiten angesehen/ durchdacht

warum habe ich da Glaubensschwierigkeiten?

OK sagen wir anders, welche beiden meinst du denn?
Mein erster Vorschlag war rein Hardware, 2 PI Rx an Tx und Tx an Rx, GND nicht vergessen

Da ist doch nix mit Internet?

Quote from RaspberryBaum

und bin an folgendem Punkt hängengeblieben: Beide Ratschläge basieren auf einer Benutzung des Internets. Das ist an sich erstmal die beste Lösung, die mir zur Zeit zur Verfügung steht, ich wollte aber nochmal fragen: Gibt es auch eine Möglichkeit, das ganze mit einer "Hardware-Verbindung" zu machen?

??? s.o.

Auch können sich 2 PI über das Netzwerkkabel unterhalten von IP an IP, einer muss nur Server spielen einer Client, ich sehe da noch kein Internet, aber das müssen die Netzwerkprofis erklären wie man das einrichtet.

OK...
Als Antwort auf eure Kritik:

Dass ich ein zu unübersichtlich schreibe, stimmt ( meigrafd). Dass ich zu viele" A"s und "B"s benutze, stimmt ebenfalls; das merkt man daran, dass du -glaube ich- in deiner Antwort "a" und "b" genau andersherum als ich gebraucht hast. Was aber meine Schuld ist. Zur Distanz zwischen beiden Pis (wegen Kabel und so): die lägen -wie gesagt- direkt nebeneinander. Also zwischen 50- und 5cm. Was wiederum belegt, dass ich mich unklar ausdrücke.

Zu jar: Du sagtest, dein erster Vorschlag sei rein Hardware gewesen. Ich sehe allerdings keinen Vorschlag von einem "jar". Entweder, ich übersehe da gerade etwas sehr rabiat (was durchaus sein kann...), oder du hast mir da als "Andreas" geschrieben. Ich habe daraufhin aber direkt __deets__'s Vorschlag gelesen, der mit den Worten "statt aber so etwas SELBST zu frickeln" ausdrückte, sein Vorschlag sei so etwas wie eine don't-do-it-yourself-methode des Vorherigen, was mich dazu brachte, insbesondere die in seinem Vorschlag angesprochenen Dinge (SSH bzw SFTP oder RSYNC) zu googeln. Die Resultate (ein weiterer Beleg dafür, dass man bei jeder Recherche entweder die Ungesichertheit von Internetinformationen oder GidF kennen lernen muss...) sprachen leider allesamt von einer übers Internet laufenden Methode (wobei ich selbst natürlich nicht wissen konnte, was SSH etc. sind, denn dann hätte ich hier ja auch nicht gefragt...), und mir selbst kam leider nicht der Gedanke, dass das Internet, wenn es "Internet" sagt, meistens nur versucht, Alternativen, die es zu ihm gibt, zu verschleiern, und in Wirklichkeit "Netzwerk" meint.

Und nochmal zu Kabeln & Co (siehe miegrafd): Das geht (räumlich) schon, denn beide Pis liegen direkt nebeneinander.

Also was ich eigentlich vorhabe:

Ich dachte mir, es wäre praktisch, wenn ein Pi, den man für Internetzugriffe verwendet, so "eingerichtet" wäre, dass er keine sensiblen Daten (also am Besten gar keine Dateien, mit denen man irgendwie arbeitet und die potentiell "wertvoll" sind, wie z.B. längere Texte...) enthält, da diese von etwaigen Viren beschädigt oder von Angreifern geraubt werden könnten.
Wenn trotzdem jemand reingelangt und "randaliert", könnte dadurch relativ wenig kaputt gehen (wo wenig ist, ist wenig gefärdet...). Allerdings wäre es schade ums Betriebssystem und etwaige Browser, die man sich dazu geladen hat. Also dachte ich mir, es wäre günstig, wenn der Pi nach jeder Benutzung (egal was passiert, also solange sich keiner an der Hardware vergreift...) wieder exakt derselbe ist wie zuvor. Indem z.B. die SD, die das Betriebssystem enthält, schreibgeschützt ist und alles, auf das Zugriff benötigt wird, bei jedem Boot im Arbeitsspeicher landet. Dann könnten etwaige Eindringlinge sich nur an der Kopie vorhandener Verzeichnisse im Arbeitsspeicher vergreifen, und da die und alle vorgenommenen Änderungen, Neuspeicherungen etc. nach dem Runterfahren vom RAM gelöscht werden, wäre die SD sicher vor Schäden.

Auf meine Anfrage dazu unter "Betriebssystem im Arbeitsspeicher ausführen" hat miegrafd mir eine hervorragende Antwort, nämlich bei jedem Boot var/log/ in den RAM zu verlegen, geboten.

Auf jeden Fall ist das eine hervorragende Idee, wie ich finde. Internet und "wertvolles Datengut" fein voneinander getrennt zu halten. Machen bekanntlich viele so. Den Pi für die Speicherung und Bearbeitung sensibler Dateien würde ich allerdings natürlich völlig ohne "Internet-Zugriffs-USB" lassen, sodass ich nichtmal versehentlich damit ins Netz kann.

Problem: Wenn man dann irgendwelche Dateien (im Sinne von Text usw.) "mit ins Internet nehmen" muss, um sie z.B. hochzuladen oder zu publizieren, muss man diese entweder direkt auf dem fürs Internet bestimmten Pi anlegen, wo man sie aber langfristig nicht speichern kann, was bei längeren Texten insbesondere aufgrund ihrer "Herstellungszeit" und ihrer Ausspähbarkeit während dieser unpraktisch wäre, oder aber man zieht sie vom Pi, der für sensible Informationen bestimmt ist, auf eine SD und von der im schreibgeschützten Zustand über einen Adapter auf den "Internet-Pi".

Problem dabei: Es ist langfristig extrem zeitaufwendig, das Zeug, das man ins Internet haben will (auch, um es z.B. zu verschicken, wobei man es, wenn es sehr sensibel ist, ja auch bereits auf dem "Sicherheits-Pi" verschlüsseln könnte), jedes mal mit einem umständlichen "auf die SD- SD raus- SD schreibschützen- SD rein- von der SD"-Manöver vom Sicherheits-Pi auf den Internet-Pi zu ziehen. Deshalb will ich eine Verbindung zwischen beiden aufbauen, über die Daten vom sicheren Pi auf den potentiell unsicheren Pi mit Internet-Anschluss übertragen werden können. Und deshalb sollte die Verbindung ja auch eine "Einbahnstraße" sein: Damit der Pi, der ans Internet geht, keine Lese- oder Schreibzugriffe auf den anderen Pi vornehmen kann und der Pi, der NICHT ans Internet geht, keine Lesezugriffe auf Daten, auf die der Andere Schreibzugriff hat, durchführen kann.

Hallo RaspberryBaum,

vielen Dank für die weiteren Infos.

Unabhängig davon, dass mein Vorschlag mit den Socket-Server/Socket-Client-Verbindung ohne Begründung verworfen wurde, bleibe ich bei meinem Vorschlag. Genau damit lässt sich alles realisieren, was Du hier geschildert hast. Und darüber kannst Du auch eine - ebenfalls socket-gesteuerte und socket-angestoßene - Datenübertragung durchführen.

Die Art der Verbindung bleibt dabei ganz Dir überlassen.

Und wenn Du Angst hast, dass Dir jemand sensible Daten vom RPi "klaut" oder vernichtet:
1. Die gehören nicht auf den Raspberry Pi
2. Dann sichere den RPi entsprechend gegen Angreifer

Bei der von mir beschriebenen Socket-Sache ist nur ein Port offen. Der bleibt nur solange offen, bis einem Angreifer es nicht gelungen ist, sich zu authentifizieren. Ggf. kannst Du die Angreifer-IP sperren. Oder von vorneherein nur Anfragen über die IP Deines Super-Geheimnisvoll-RPi erlauben.

Beste Grüße

Andreas

Danke für die Antwort. Und nochmal sorry, dass ich deinen Vorschlag derart verworfen habe. Ich werde deinen Rat, denke ich, befolgen. Hab ihn vorher wohl ziemlich übersehen.

Also nochmal sorry für meine Ignoranz.
Automatisch zusammengefügt:[hr]
Und die "sensiblen Daten" würden natürlich nicht direkt auf der Speicher-SD vom Pi, sondern an einen daran angeschlossenen USB mit regelmäßigem Backup landen. Der übrigens gepanzert ist und aus ca. 8 Meter Höhe auf Beton fallen könnte, ohne sich dabei was zu tun.
Automatisch zusammengefügt:[hr]
Wobei nicht zu übersehen ist, dass ich letzteres sogar eigenständig getestet habe.

Quote from RaspberryBaum

Zu jar: Du sagtest, dein erster Vorschlag sei rein Hardware gewesen. Ich sehe allerdings keinen Vorschlag von einem "jar". Entweder, ich übersehe da gerade etwas sehr rabiat (was durchaus sein kann...), oder du hast mir da als "Andreas" geschrieben.

das war der Beitrag #5 wie du das übersehen konntest weisst nur du

Quote from jar

kreuze einfach die RxD von einem PI mit der TxD am anderen PI und umgekehrt, PI1 GND an PI2 GND nicht vergessen !
Nullmodemkabel wäre was zum lesen.

wenn wheezy auf beiden läuft hilft dir CuteCom, sonst im LX Terminal minicom
http://kampis-elektroecke.de/?page_id=1682

Quote from __deets__

Was fuer ein System... Aluhut anfertigen nicht vergessen

Die einfachste Loesung waere ja einfach deine Daten per USB-Stick rueber zu nehmen. Physikalische Barrieren ueberwindet auch der gewiefteste Hacker nicht. Und wenn der Stick eine physikalischen Schreibschutz hat, dann kann da auch nichts drauf, dass dann wieder das sichere System kompromittiert.

Mit rsync koenntest du auch ein Verzeichnis auf dem sicheren System (S) zyklisch per Push abgleichen mit den unsicheren System (U). Da die Login-Moeglichkeit nur in eine Richtung etabliert wird, kann ein Angreifer nicht so ohne weiteres auf S zugreifen, selbst wenn sie sich dem SSH-Daemon auf U bemaechtigt hat. Denn dann bedarf es noch eines Protokoll-Exploits der es erlaubt, von einer eingehenden SSH-Verbindung aus Kontrolle ueber den Client zu bekommen. Das kann schon nicht mehr jedes Skriptkiddie.

nun ja 2 PI,

einer 1. ist intern und schreibt nur Daten auf Rx raus
2. liest nur Daten und stellt sie dar und ist im Internet, so kann einer zwar PI2 hacken aber kommt nie rein, er kann nur die Daten lesen die PI 2 über Rx von PI 1 Tx bekommt.

Zu __deets__:
Eine physikalische Barriere ist eigentlich genau das, was ich damit erreichen wollte/ will. Um sozusagen 100% Hackersicherheit zu erhalten. Weil, wie du bereits so treffend feststelltest, selbst der beste Hacker keine physikalischen Barrieren überwinden kann. Das meine ich auch mit #19: dass ich eine Verbindung suche, die bereits durch die Hardware auf nur eine Richtung beschränkt ist. Ich habe mich da allerdings zugegebenermaßen echt schwammig ausgedrückt.

Das ist übrigens auch der Grund, weshalb ich ursprünglich an eine Funkverbindung dachte: Weil da der "Sicherheitspi" den Sender und der "Internetpi" den Empfänger haben könnte. Ist allerdings logischerweise (wie meigrafd bereits feststellte) denkbar ungeeignet, um komplexere Dateien zu übertragen.

Und zu jar:
Ich habe deinen Vorschlag, den du da in #5 gebracht hast, relativ schnell (zu schnell...) verworfen, weil du da von "kreuze [...] und umgekehrt" gesprochen hast, was mich auf eine zwangsläufig beidseitige Verbindung schließen ließ... Ich sollte mir da nächstens echt bischen mehr Zeit nehmen...

Ich werd mir deinen Vorschlag jetzt unbedingt nochmal genauer ansehen.... Wenn ich das richtig verstanden habe, meinst du, ich solle die Daten von diesen "Output-Stängeln" seitlich bei Pi 1 (deren terminus technikus mir bis dato unbekannt war) auf die "Input-Stängel" seitlich bei Pi 2 übertragen, oder? Sorry, aber über Begriffe stolper ich immer wieder. Wenn es das ist, was du meinst, und ich hänge nur "Output-Stängel" von Pi 1 an "Input-Stängel" von Pi 2, dann wäre das doch ebenfalls eine physikalische Beschränkung auf eine Richtung, also eine entsprechende Barriere, oder?

Servus,
was mir gerade so spontan dazu einfiel: warum nicht einen nfs-share des "sicheren" auf dem "unsicheren" Raspi mit Nur-Leseberechtigung einhängen?
Wär' sonst keine weitere Aktion, script, Programm oder sonst was nötig.

cu,
-ds-

Quote from RaspberryBaum

Und zu jar:
Ich werd mir deinen Vorschlag jetzt unbedingt nochmal genauer ansehen.... Wenn ich das richtig verstanden habe, meinst du, ich solle die Daten von diesen "Output-Stängeln" seitlich bei Pi 1 (deren terminus technikus mir bis dato unbekannt war) auf die "Input-Stängel" seitlich bei Pi 2 übertragen, oder? Sorry, aber über Begriffe stolper ich immer wieder. Wenn es das ist, was du meinst, und ich hänge nur "Output-Stängel" von Pi 1 an "Input-Stängel" von Pi 2, dann wäre das doch ebenfalls eine physikalische Beschränkung auf eine Richtung, also eine entsprechende Barriere, oder?

ja logisch, man sollte Vorschläge schon versuchen zu verstehen bevor man sie verwirft, sonst haben Antworten keinen Sinn.

Du hast es doch in der Hand welche Daten vom PI1 zum PI2 geschickt weren und per RS232 am PI2 der im Internet ist kann keiner den PI1 manipulieren wenn es

1. den Weg nicht gibt oder
2. wenn PI1 jede Anfrage an RS232 einfach ignoriert weil so konfiguriert
(von alleine tut der nix wenn der Port aus dem OS gehängt wird)

Bequemlichkeit.

Quote from RaspberryBaum

... es würde mir jede Menge Suchen und Durchwühlen verschiedener Möglichkeiten ersparen...

Das mit dem Durchwühlen - aka Ausprobieren verstehe ich noch. Das mit dem Suchen klingt mir nach Bequemlichkeit.

Warum suchst Du nicht und offerierst uns Deine Findings zum kommentieren? Solch ein Verhalten stimuliert zum kommentieren und helfen. Bequemlichkeit nicht

Moin deets,
naja ... das kann man jetzt so oder so sehen ... weil bekannt, ist es stärker im Focus und dadurch möglicherweise sogar ziemlich sicher.
Andererseits könnte man den Server natürlich auch auf dem "unsicheren" Pi laufen lassen, den share lokal auf r/o setzen und vom "sicheren" Pi her einhängen (, synchronisieren, aushängen).
Ginge natürlich auch, wie von Dir schon angedacht, zyklisch per rsync ...

Wäre imho halt einfacher und auch sicherer, als sich selbst ein eigenes Syncronisierungs-Programm per rs232 oder whatever zusammen zu frickeln, das dann u.U. fehlerhaft oder unsicher läuft - ok, per rs232 - wie von jar angedacht - ist eine Sicherheitslücke eher unwahrscheinlich. Aber der Aufwand ist sicher nicht zu unterschätzen ...

Kommt halt u.a. drauf an, was der TO bereit ist an Arbeit zu investieren.

cu,
-ds-

Hallo zusammen,

bevor ich aus diesem Thread aussteige, mein letzter Versuch die Sache mit den Sockets zu verdeutlichen, die ich persönlich für den sichersten Weg und in Anbetracht der Probleme, die viele User mit UART / RS232 etc. hier haben (was aber lösbar ist):

Der eine Pi fungiert als Socket-Server - der andere als Socket-Client.

IP & Port des Socket-Servers ist bekannt. Auf diesem Port lauscht er.

Der andere Pi (der mit dem Socket-Client) stellt eine Verbindung her.

Der Socket-Server hat mehrere Möglichkeiten der Authentifizierung:
1. IP-Adresse des Gegenstelle: Passt diese nicht wird die Socket-Verbindung geschlossen. Ggf. die IP-Adresse (dauerhaft) gesperrt.
2. Socket-Server sendet z.B. 10 Bytes
3. Socket-Client erzeugt mit einem Algorithmus eine Antwort und sendet diese zurück
4. Der Socket-Server vergleicht die Antwort mit der erwarteten. Passt diese nicht wird die Socket-Verbindung geschlossen. Ggf. die IP-Adresse (dauerhaft) gesperrt.

In Kombination dieser 4 Punkte reduziert sich die Zahl der erfolgreichen Angreifer pro Zeiteinheit drastisch...

Wie sicher ist das mit den 10 Bytes und der Wahrscheinlichkeit, in Unkenntnis des Algorithmus und nur durch Abhören des Datenstroms der beiden Socket-Teilnehmer die richtige Antwort zu einem Code zu erhaschen? Und hoffen, dass bei einer Wiederholung des Codes die gleiche Antwort immer noch valide ist?

10 Bytes entspricht 256^10 Möglichkeiten = 1208925819614630000000000 Möglichkeiten.

Angenommen, ein Angreifer würde den Datenstrom abfangen und wäre in der Lage, 1000 Authentifizierungen pro Sekunde mitzubekommen (was in dem betrachteten Fall nicht passiert, da nur eine Authentifizierung erfolgt - und keine zweite Chance erfolgt), dann würde es
1208925819614630000000000 / 1000 Sekunden = 1208925819614630000000 Sekunden
= 335812727670730000 Stunden
= 13992196986280400 Tage
= 38308547532595,3 Jahre dauern, bis alle Code statistische gesehen je einmal erzeugt wurden.

Unser Sonnensystem hat so rund 15 * 10⁹ Jahre hinter sich.

Machen wir es mal ein paar Stufen unsicherer. Der Socket-Server schickt nur 6 Zeichen. Dann erhalten wir
281474976710656 Möglichkeiten
281474976710,656 Sekunden
78187493,5307378 Stunden
3257812,23044741 Tage
8919,403779459 Jahre

Selbst wenn 8919 Rechenknechte nichts anderes machen würden, als eine Socket-Verbindung, die sie überdies noch nicht kennen, zu belauschen, würde ein Jahr vergehen, bis alle Codes durchgenudelt sind.

Und wie gesagt, ohne Kenntnis des Codes zur Erzeugung des Authentifizierungscodes nutzt das Belauschen gar nichts.

Viel paranoider und gleichzeitig sicherer geht's wohl nimmer. Außer man packt in die Codierung noch einen versteckten Zeitschlüssel. Dadurch besteht dann gar kein Zusammenhang mehr zwischen beiden Bytefolgen.

So ein Socket-Teil ist mit ansprechender GUI in rund 30 Minuten programmiert. Tricky wird's dann mit dem Algorithmus zur Authentifizierung. Da kann man sich so richtig austoben. Mit ein wenig Übung ist das aber auch in 30 Minuten wasserdicht.

Beste Grüße

Andreas

Ja servus Andreas,

mal wieder in Sachen "Security by obscurity" unterwegs ...

Ne, jetzt im Ernst ... das lässt sich sicher per Standard-Methoden wie RSA oder schlagmichtot mit public und private key lösen ...

Das, worauf deets u.a. anspielt, sind imho exploits, die "man" einfach nicht einkalkulieren kann ... also "bufferoverflows" und so ein Krams ... oder seinerzeit das berühmt berüchtigte sendmail Phänomen, mit dem man problemlos eine root-shell erhalten hat.
Und da weiss man halt nicht, wo die nächste "vulnerability" auftaucht.
So gesehen bleibt eben jar's Ansatz vom Sicherheitsaspekt her wohl der sicherste ... aber halt wohl auch der äufwändigste.

Alles frei nach dem Motto: "die sicherste Firewall ist ein gezogener Netzwerkstecker"

cheers,
-ds-

Quote from dreamshader

So gesehen bleibt eben jar's Ansatz vom Sicherheitsaspekt her wohl der sicherste ... aber halt wohl auch der äufwändigste.

ich tät mich halt leichter mit RS232 Datenverkehr als die Sockets und den IP Kram bombensicher zu machen.

Hallo Dreamshader, halo Jar,

Quote from jar

ich tät mich halt leichter mit RS232 Datenverkehr als die Sockets und den IP Kram bombensicher zu machen.

meiner Meinung nach sind die Socket-Sachen sehr sicher. Es existiert nur ein offener Port. Die Verbindung zu allem, was nicht richtig auf die Sicherheitsabfrage antworten kann, wird vom Socket-Server getrennt. Es gibt keinen weiteren offenen Standard-Port, über den Angreifer sonst Zugang erhalten können.

Ich setze sowas seit letztem Jahr in mehreren Projekten zuverlässig ein.

Wenn es einem Angreifer gelungen sein sollte, einen Schädling über eine unsichere Internetanbindung etc. eingepflanzt zu haben, dann ist es sicherlich kein Problem, auch die Kommunikation über RS 232 / UART zu verfolgen.

Andererseits muss jemand schon einen an der Klatsche haben, äußerst sensible Daten auf dem RPi zu lagern, dass es schon ratsam ist, solche Vorkehrungen treffen zu müssen.

Beste Grüße

Andreas

Quote from Andreas

Wenn es einem Angreifer gelungen sein sollte, einen Schädling über eine unsichere Internetanbindung etc. eingepflanzt zu haben, dann ist es sicherlich kein Problem, auch die Kommunikation über RS 232 / UART zu verfolgen.

nix da wenn der interne PI1 auf Tx nur die freigegebenen Daten sendet und keine Rx Verbindung hat kann der Internet PI2 der diese Daten am Rx empfängt wohl kaum dem internen PI1 irgendwas befehlen, es gibt keinen Weg rein!

Der umgekehrte Weg existiert einfach nicht!