Hallo zusammen, ich habe zwei PCs, einer ist sicher und einer potentiell unsicher. Der sichere PC soll Daten an den unsicheren senden. Umgekehrt soll das nicht möglich sein, damit der unsichere PC den sicheren nicht korrumpieren kann. Die Trennung soll unbedingt physikalisch stattfinden. Folgende Ideen habe ich bis jetzt: Nullmodem über RS232 (ohne Rückkanal, d.h. Rx gekappt) Vorteil: - Kontinuierliche Verbindung - Günstig - Ausgereift Nachteil: - Langsam USB-Stick mit Hardware-Schreibschutz (Schreibschutz auf unsicherem PC aktiviert) Vorteil: - Schnell - Günstig Nachteil: - Keine kontinuierliche Verbindung - Unsicher bei versehentlich vergessenem Schreibschutz Fallen Euch noch weitere Alternativen ein? Gibt es Ethernet-Protokolle, die ohne (physikalischen) Rückkanal funktionieren? Das Ganze ist übrigens privat. Grüße Steffen
Steffen Hausinger schrieb: > > Nullmodem über RS232 (ohne Rückkanal, d.h. Rx gekappt) > Vorteil: > - Kontinuierliche Verbindung > - Günstig > - Ausgereift > > Nachteil: > - Langsam meine erste Idee wäre auch einfach eine TX Leitung vom RS232 zu benutzen und RX weglassen -> Dauerhafte Verbindung wie du schon erwähnt hast Was du nicht erwähnt hast, was dort rüber gehen soll. Wenn du von langsam sprichst, dann solltest du auch mal eine Größenordnung angeben oder wozu das ganze geeignet sein soll
Was du dabei auch noch bedenken solltest: Du hast dann keinerlei Kontrolle, ob die Daten auch fehlerfrei beim Empfänger angekommen sind. Du müßtest dann also ein Protokoll mit FEC einsetzen, damit der Empfänger wenigstens eine Möglichkeit der Korrektur bei Übertragungsfehlern hat.
> USB-Stick mit Hardware-Schreibschutz gibt es denn so etwas? > Das Ganze ist übrigens privat. damit ist die Anforderung vermutlich Blödsinn. Mach es über Netzwerk, dort über eine Firewall (kann auch eine klein Box sein) nur UDP in einer Richtung zulassen und gut ist. Bei Unidirektionale hast du aber immer noch das Problem, das du nicht weißt ob die Daten wirklich richtig angekommen sein.
Hallo, zu RS232 hätte ich da eine Idee: Da das kappen des Rückkanals eigentlich immer zu Problemen führt, die Übertragung kann nicht auf Korrektheit geprüft werden, keine Flusssteuerung, ... sollte schon eine Kommunikation in beide Richtungen möglich sein, der Rückkanal darf aber nur für die obengenannten Zwecke benutzt werden. Das könnte ein in die RS232 Leitung eingeschleifter Mikrocontroller mit 2 UARTS tun. Daten in der richtigen Richtung werden ungeprüft durchgereicht, und auf dem Rückkanal werden nur wohldefinierte Zeichen/Sequenzen weitergereicht, das kann man ja z.B. auf XON/XOFF, Datenpaket war OK, Datenpaket war fehlerhaft bitte wiederholen, u.ä. reduzieren. Mit freundlichem Gruß - Martin
Tim R. schrieb: > Was du nicht erwähnt hast, was dort rüber gehen soll. Wenn du von > langsam sprichst, dann solltest du auch mal eine Größenordnung angeben > oder wozu das ganze geeignet sein soll Die Verbindung soll Daten transportieren, keine Echtzeit notwendig. Die Größe variiert, schätzungsweise <500MB. Ist halt eine Zeitfrage (500 MB dauern einen halben Tag bei 115200 kbaud, wenn ich mich nicht verrechnet habe). npn schrieb: > Du müßtest dann also ein Protokoll mit FEC einsetzen, damit der > Empfänger wenigstens eine Möglichkeit der Korrektur bei > Übertragungsfehlern hat. Das stimmt leider, liegt aber in der Natur der Sache (kein Rückkanal). Ein "ACK" wäre naturlich toll. Kennst Du da ein Protokoll? Ansonsten muss ich halt mit Prüfsummen arbeiten. Peter II schrieb: > Das Ganze ist übrigens privat. > > damit ist die Anforderung vermutlich Blödsinn. Möglicherweise, aber was ist schon sinnvoll?
Martin Schlüter schrieb: > Das könnte ein in die > RS232 Leitung eingeschleifter Mikrocontroller mit 2 UARTS tun. Daten in > der richtigen Richtung werden ungeprüft durchgereicht, und auf dem > Rückkanal werden nur wohldefinierte Zeichen/Sequenzen weitergereicht, > das kann man ja z.B. auf XON/XOFF, Datenpaket war OK, Datenpaket war > fehlerhaft bitte wiederholen, u.ä. reduzieren. Weitere Idee, um das noch weiter zu vereinfachen: Es wäre doch auch möglich, nur den Rückkanal über den µC zu geben, wenn der Hin-Kanal sowieso alles durchreicht, oder?
Martin SchlüterEmpfängerinBeitrag #3776653: > Hallo, > > zu RS232 hätte ich da eine Idee: Da das kappen des Rückkanals eigentlich > immer zu Problemen führt, die Übertragung kann nicht auf Korrektheit > geprüft werden, keine Flusssteuerung, ... sollte schon eine > Kommunikation in beide Richtungen möglich sein, der Rückkanal darf aber > nur für die obengenannten Zwecke benutzt werden. Das könnte ein in die > RS232 Leitung eingeschleifter Mikrocontroller mit 2 UARTS tun. Daten in > der richtigen Richtung werden ungeprüft durchgereicht, und auf dem > Rückkanal werden nur wohldefinierte Zeichen/Sequenzen weitergereicht, > das kann man ja z.B. auf XON/XOFF, Datenpaket war OK, Datenpaket war > fehlerhaft bitte wiederholen, u.ä. reduzieren. > > Mit freundlichem Gruß - Martin Gute Idee! Der Empfänger könnte die Daten einfach spiegeln. Der uC würde dann auf das Echo prüfen von dem, was er zuvor gesendet hat!
Bevor hier weiter spekuliert wird bräuchte man eigentlich mal Infos vom TS um was für Daten es sich handelt. Dann kann man über ein geeignetes Übertragungsmedium nachdenken.
Steffen Hausinger schrieb: > Das stimmt leider, liegt aber in der Natur der Sache (kein Rückkanal). > Ein "ACK" wäre naturlich toll. Kennst Du da ein Protokoll? Ansonsten > muss ich halt mit Prüfsummen arbeiten. Eine Prüfsume nützt dir nichts, denn sie sagt dir nur, dass ein (oder auch mehrere) Fehler aufgetreten ist (oder sind). Für eine FEC mußt du die Daten redundant senden, damit auch eine Korrektur möglich ist. Der Empfänger muß also in der Lage sein, aus dem empfangenen Datenstrom herauszufinden, welche Daten falsch sind und diese durch richtige Daten zu ersetzen. Was es da für Möglichkeiten / Protokolle gibt, findest du hier: http://en.wikipedia.org/wiki/Forward_error_correction Hier stehen auch noch ein paar Infos: http://de.wikipedia.org/wiki/Vorw%C3%A4rtsfehlerkorrektur
Martin Schlüter schrieb: > die Übertragung kann nicht auf Korrektheit > geprüft werden Naja, kann notfalls auch vom Benutzer uebernommen werden: z.B. Datei uebertragen, Checksumme auf beiden Seiten ausrechnen (Viele Dateiformate haben ohnehin schon eine Checksumme, z.B. zip Format). Checksumme ueberpruefen. Wenn falsch Datei nochmal uebertragen. Wenn zu viele (immer) Fehler stimmt irgendwas mit der Seriellen Schnittstelle nicht. Martin Schlüter schrieb: > Flusssteuerung > XON/XOFF Man kann ja Flusssteuerung auch ueber HW-Signale machen (RTS/CTS). Dann kann man die Tx Leitung in die eine Richtung komplett kappen und hat nur eine RTS Leitung ueber die man keine Daten senden kann. ZigZeg
npn schrieb: > Weitere Idee, um das noch weiter zu vereinfachen: > Es wäre doch auch möglich, nur den Rückkanal über den µC zu geben, wenn > der Hin-Kanal sowieso alles durchreicht, oder? Ja, das könnte man natürlich machen, dann reicht sogar ein Controller mit einem UART, ich würde es aber nicht machen, irgendwann kommt man vielleicht auf die Idee, daß es sinnvoll ist, den Kontext der gesendeten Daten zu kennen, um die Rückantwort zu beurteilen, und kommt da nicht ran. Mann könnte ja auch vorsehen, das der Hinweg nicht über den Mikrocontroller läuft, aber trotzdem vom Controller 'belauscht' werden kann, also die Daten nur an Rx geführt sind. 500 Mb über RS232 sind aber schon heftig! Da sollte man sich tatsächlich über eine Ethernet / Firewall Lösung Gedanken machen, oder über ein NAS auf das beide Rechner Zugriff haben. Dateien an sich machen ja einen Rechner nicht kaputt, gefährlich wird es erst, wenn nicht vertrauenswürdige Dateien zur Ausführung gebracht werden, man muß also unterbinden, das Schadcode auf dem unsicheren Rechner in der Lage ist auf dem sicheren Rechner Programme zur Ausfürung zu bringen. Das sollte eigentlich per Firewall machbar sein. (Ausrangierte Internet-Router lassen sich da eventuell verwenden) Mit freundlichem Gruß - Martin
Eigentlich sollte sowas auch mit Ethernet gehen. 10 oder 100 Mbit mit einem doofen Hub dazwischen. Das Empfangsaderpaar von der unsicheren Seite wird am Hub nicht angeschlossen. Die Übertragen erfolgt dann mit UDP Broadcast Paketen. Es muss natürlich genug Redundanz vorhanden sein um Fehler zu korrigieren. Wie tragisch sind bei deiner Übertragung fehlende Pakete? z.B. bei einer Audio Live Übertragung würde ein kurzer Aussetzer ja kaum auffallen.
Mach es nicht so kompliziert. TX geht beim unsicheren PC auf ein max232 und wird dann einfach zurückgeschickt. Sichere PC hat ein HW remote loopackmit repeater (wichtig) und unsicherer nur ein rx. Sollte HW flusssteuerung notwendig sein, dann muss ein UC mit buffer inzwischen geschälten werden. Stromversorgung für max232 muss vom PC genommen werden. Default pull up nicht vergessen.
Türöffner schrieb: > Eigentlich sollte sowas auch mit Ethernet gehen. 10 oder 100 Mbit Klar und der PC geht dann in den half duplex mode, dieser braucht nur ein Adernpaar und du merkst es nicht mal. > Wie tragisch sind bei deiner Übertragung fehlende Pakete? > > z.B. bei einer Audio Live Übertragung würde ein kurzer Aussetzer ja kaum > auffallen.
Ichhabe mir gerade überlegt (um mal bei der RS232 zu bleiben), daß es doch noch viel einfacher wäre, wenn es auf der Senderseite ein Programm gibt, das nur (blockweise zum Beispiel) Daten senden kann und lediglich Steuerdaten empfangen kann (ACK / NAK). Und auf der Empfängerseite kann das Programm nur Daten empfangen und sie dann ledglich bestätigen oder neu anfordern. Die Programme wären relativ leicht zu programmieren, man muß kein FEC-Protokoll implementieren, sondern nur eine CRC auswerten und bei Fehler den Datenblock nochmal anfordern. Alles andere läßt man weg. Da könnte doch ein potentieller Schädling, der sich auf dem Empfänger-Rechner befindet, nichts auf dem Sende-Rechner anrichten. Oder sehe ich das falsch? Klar müßten dann zwei kleine Progrämmchen für die beiden PCs geschrieben werden, aber das sollte doch kein Problem sein... Habe ich was übersehen oder nicht beachtet?
Steffen Hausinger schrieb: > USB-Stick mit Hardware-Schreibschutz Das ist in der Regel zwar ein mechanischer Schalter, der aber auch nur in Software ausgewertet wird. Ich habe eine Zeitlang Daten vom Krypto-Notebook zum normalen PC (und andersherum) per CD-R transportiert. CD-brenner war in beiden vorhanden. Und daß man von demn 700MB teilweise nur ein paar Kilobyte nutzt, jo mei...
chris schrieb: > Mach es nicht so kompliziert. Macht er doch schon, da kommt es auf die paar Details auch nicht mehr an...
Steffen Hausinger schrieb: > Gute Idee! Der Empfänger könnte die Daten einfach spiegeln. Der uC würde > dann auf das Echo prüfen von dem, was er zuvor gesendet hat! Womit die Übertragungsrate glatt halbiert wäre... Wenn RS232, dann mit Rückkanal und einem Protokoll, wie z.B. Kermit - das ist seit 100 Jahren ausgereift, nutzt den Kanal sehr gut und kostet nix. Zum Schutz müßte es ausreichen, wenn die Schnittstelle von Kermit exklusiv belegt wird - was üblich ist. Das Ganze hat keinen direkten Anschluss ans Dateisystem und ans LAN, damit ist es nur mit maßgeschneiderten Angriffen verwundbar. Es lebe die Artenvielfalt ;-)
Einfach eine SD-Karte nehmen. Im Quell-Rechner beschreiben, im Ziel-Rechner auslesen. Bevor sie wieder in den Quell-Rechner kommt, in der Kamera formatieren. Wenn du der nicht traust, baust du dir mit einem Arduino mit SD-Shield einen SD-Formatierer - der wird sicher von nichts befallen. Schnell, guenstig und ausreichend paranoid.
Sowas daemliches. Man kann sich ja auch darauf beschraenken, nur Daten und keine Programme zu uebertragen
Ich würd's seriell über einen USB/RS232-Konverter machen: Die Hardware ist schnell gestrickt, die Treiber gibt's auch und sicher ist es, weil nur ein darauf spezialisiertes Programm überhaupt etwas mit der Verbindung anfangen kann. Der FTD232r kann 3MBaud/s, damit sind 2MBit/s drin, schnell genug, umm 500MByte in erträglicher Zeit zu übertragen. Mit Protokoll, damit Übertragungsfehler erkannt werden - anders macht das keinen Sinn.
Quack+ schrieb: > Einfach eine SD-Karte nehmen. Hat auch einen Mikroprozessor und ist damit für wahre Paranoiker ungeeignet. :-)
Siebzehn Zu Fuenfzehn schrieb: > Sowas daemliches. Man kann sich ja auch darauf beschraenken, nur > Daten > und keine Programme zu uebertragen Du weißt ja nicht, was er überhaupt damit machen will. Wenn es beispielsweise eine Art Datensicherung sein soll, dann können natürlich auch Programme dabei sein. Ein Backup wäre wenig sinnvoll, wenn die Programme nicht mitgesichert werden.
radiostar schrieb: > Mit Protokoll, damit Übertragungsfehler erkannt werden - anders macht > das keinen Sinn. dann kann er auch gleich Netzwerk machen und braucht sich nicht zu kaufen um dann doch nur 3mbit/s zu übertragen. Dann muss er die Einbahnstraße nur in Form von Software umsetzen.
radiostar schrieb: > 3MBaud/s 1 Baud = 1 Symbol/s ist eine Geschwindigkeit 1 Baud/s = 1 Symbol/s² ist eine Beschleunigung
Ich wollte zum Spaß schreiben: Nimm ein Gbit LWL und zieh einen Stecker. Jetzt gibts das wirklich: http://www.giac.org/paper/gsec/2848/unidirectional-networking/104817
Danke für Eure zahlreichen Antworten!! Vorweg: Ich habe bewusst wenig über den zu übertragenden Dateninhalt geschrieben, weil es mir um eine Lösung auf dem ISO OSI Layer 1 aka. Physical Layer geht. Zur Dimensionierung habe ich geschrieben, dass die max. Dateigröße 500 MB ist. Die Übertragungsrate ist natürlich wichtig, aber erstmal ging es darum, überhaupt eine Lösung zu finden. Ich habe inzwischen entdeckt, dass es für mein Vorhaben bereits einen Namen gibt: Daten-Diode. Infos dazu gibt es im bereits von hp-freund verlinkten Paper, auf Wikipedia (http://en.wikipedia.org/wiki/Unidirectional_network) sowie ein fertiges Projekt hier http://ephemer1c.wordpress.com/2013/05/16/data-diode/
Steffen Hausinger schrieb: > aber erstmal ging es darum, überhaupt eine Lösung zu finden. Du musst dir darüber klar sein, dass eine Lösung wie etwa ein Lichtleiter ohne Rückkanal in ein Dilemma führt: es gibt keine Verifizierung der übertragenen Daten, die Übertragung ist also nicht sicher gegen Fehler aller Art. Führst du eine Prüfung und Rückmeldung ein, ist die Diodenwirkung aufgehoben. Georg
Georg schrieb: > die Übertragung ist also nicht > sicher gegen Fehler aller Art. Dann codiert man die Daten halt geeignet. Ist ja nicht so, daß "Rückmeldung" zwingend wäre, um Übertragungsfehlern entgegenwirken zu können.
Gustav schrieb: > Ist ja nicht so, daß "Rückmeldung" zwingend wäre, um Übertragungsfehlern > entgegenwirken zu können. Ganz so einfach ist es nicht. Das sendende System würde es nicht mal merken, wenn die Verbindung überhaupt nicht mehr besteht. Also müsste der Admin immer wieder mal nachsehen (am anderen Ende), ob überhaupt noch was ankommt, und ob es korrekt ist. Georg
Man könnte auch in festen Zeitabständen eine Datei senden die ein Verzeichnis der gesendeten Dateien und deren Prüfsummen enthält die seit der letzen Datei dieser Art eingegangen sein sollten.
Sollte heissen loopback mit. Ein HW loopback mittels max232 welcher vom PC seine vcc bezieht. So wird das Signal empfangen und zurück gesendet. Der sichere PC kann so erkennen dass die Daten richtig angekommen sind oder nicht und weiters ob der remote PC an oder aus ist. Auch werden normalerweise die x Pakete vor dem Ausschalten nachträglich invalidiert.
Nö, alles was man dann weis ist das der Empfangende PC den MAX mit Strom versorgt. Der kann auch grade mit einer BIOS Fehlermeldung da stehen, oder bei Win mit einem Bluescreen
Der unsichere PC könnte mit RTS und DTR vier Zustände signalisieren 00-01-10-11. Dies könnte in Kombination mit einer CRC (besser noch Reed-Solomon-Codes) zur Fehlererkennung und Transferwiederholung genutzt werden.
Das Problem mit dem Rückkanal ist dass ein Programm damit auf dem sicheren Rechner so SW nachladen kann. In so einem falle wie schon geschrieben UC mit grossen buffer dazwischen ist nötig, ansonsten ist es viel zu einfach dies zu umgehen. Dann kann auch HW flow zwischen UC und unsicheren PC verwendet werden. Dieser UC sollte dann die Möglichkeit haben den ma232 auszuschalten.
chris schrieb: > In so einem falle wie schon > geschrieben UC mit grossen buffer dazwischen ist nötig Im Endeffekt beschreibst du hier eine externe Firewall, die nur bestimmte Telegramme durchlässt. Sowas lässt sich auch bei Ethernet mit einer externen Firewall realisieren. Wobei man da mit genug Paranoia auf das Herstellungsland der Firewall achten muß damit man weis welcher Geheimdienst da eine Backdoor hat.
hp-freund schrieb: > Man könnte auch in festen Zeitabständen eine Datei senden die ein > Verzeichnis der gesendeten Dateien und deren Prüfsummen enthält die seit > der letzen Datei dieser Art eingegangen sein sollten. Wenn die Verbindung unterbrochen ist, kommt die ja auch nicht an. Man müsste also beim Empfänger noch ein Time Out installieren und die Datei automatisch auswerten, sonst ist dem Admin nicht damit geholfen. Georg
00 - Ready Zustand 01 - Daten Angekommen Checksumme OK (Daten konnten durch redundanz gerettet werden) zusätzlich wenn das signal nach Transfer und einer gewissen Latenz nich kommt kein empfänger da 10 - Daten haben Checksummen Fehler Wiederholungsanfrage 11 - was weiß ich...
Entweder ist man so paranoid (ist hier nicht abwertend gemeint) dass man wirklich eine rein unidirektionale Verbindung will, dann macht es auch keinen Sinn durch die Hintertür wieder einen Rückkanal einzuführen, oder man lässt einen Rückkanal zu, dann muss man auch kein Gebastel mit RS232 und Mikrocontroller machen, sondern kann wie schon vorgeschlagen eine Firewall dazwischenschalten die z.B. in Rückrichtung nur ACK-Pakete zulässt. Was man mit den hier vorgeschlagenen Prüfsummen, Wiederholanforderungen usw. tut ist ja letztendlich nichts anderes, als etablierte Verfahren wie TCP/IP auf umständliche Weise selbst nachzuimplementieren. Und ob das letztendlich der Sicherheit zuträglich ist, darf man bezweifeln.
:
Bearbeitet durch Admin
Ich habe eine unidirektional Verbindung vorgeschlagen welche nur als Kontrolle einen ruckkanal Hat und dies in HW. Weiters wird bei solchen Sachen Heute eine charge pump verwendet, CNC like. Ansonsten greift das remote admin interface vom BIOS. Ich kenne solche Sachen für logging Server mit wdt auf dem TX. Da wird aber auch davon ausgegangen dass rs232 passt oder tx auf rs422 Pegel für längere Leitung verwendet.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.