Rückwirkungsfreiheit durch Rsync

[Torsten84]

Hallo zusammen,

ich habe eine Frage zur Verwendung von Rsync in einem Sicherheitsrelevanten System.

Ausgangslage:
Es sollen veränderte Dateien erkannt und auf einen Server mit der Linux-Version "Jessie 8.X" gemounten werden. Für diese Funktion soll Rsync verwendet werden. (Diese Entscheidung steht fest und kann nicht geändert werden).

Die Dateien auf dem Server liegen in einem Sicherheitsrelevanten-System. Ein unidirektionaler Zugriff ist daher unabdingbar, um eine Rückwirkungsfreiheit zu gewährleisten.

Ziel:
Durchführung einer Systemvalidierung zum Nachweis der Rückwirkungsfreiheit.

Frage:
Sind euch Situationen bekannt, die die Rückwirkungsfreiheit durch Rsync negativ beeinflussen können? Oder gibt es eine Aussage, die die Rückwirkungsfreiheit definitiv beweist?
Mir ist bewusst, dass ich diese Frage in einen weiten Raum werfe. Aber vielleicht bekomme ich so von euch Anreize aus allen Richtungen.

Ich danke euch für eure Hilfe

Viele Grüße
Torsten

[fork]

rsync ist relativ umfangreich in seine Funktionen. Es hat u. a. auch Funktionen, mit denen auf der Senderseite Dateien gelöscht werden, die z. B. auf der Zielseite nicht vorhanden sind. Zu empfehlen ist hier das durcharbeiten der rsync-manpage für Details und vor allem wie die Standardeinstellungen für rsync ist.

Ein Beweis wäre für mich z. B. mit der Methode: Vorherschnappschuss-Nachherschnappschuss-Vergleich möglich. Vorausgesetzt während der Vergleichszeit wird nichts geschrieben. Hier könnte man Dateisystemschnappschüsse(z. B. bei zfs oder btrfs) zu Hilfe nehmen um die Downtime gering zu halten. Kommt natürlich auch drauf an, wie genau man das nehmen will. Dabei könnte man bis zur Begutachtung des rsync-Quellcodes gehen.

Eine mögliche Hauptmethode(vorherschnappschuss,rsync,nachherschn appschuss) wäre es, eine sortierte Liste von Dateien zu haben mit Prüfsummen(MD5/SHA###/...) über alle Dateien zu generieren. Die Prüfsumme über diese Liste muss vorher und nachher identisch sein, womit dann bewiesen wäre das der Inhalt aller Dateien identisch ist als auch die Anzahl der existierenden Dateien.

[florian0285]

Hallo zusammen,

ich habe eine Frage zur Verwendung von Rsync in einem Sicherheitsrelevanten System.

Ausgangslage:
Es sollen veränderte Dateien erkannt und auf einen Server mit der Linux-Version "Jessie 8.X" gemounten werden.

Was genau verstehst du jetzt unter "gemountet"? Das heißt eigentlich der unsichere Server greift auf den sicheren Server zu und bindet irgendein Netzlaufwerk o. ä. (z. B. NFS, SAMBA) ins Dateisystem ein. Das wiederspricht der Forderung "unidirektionaler Zugriff".



Für diese Funktion soll Rsync verwendet werden. (Diese Entscheidung steht fest und kann nicht geändert werden).

rsync mit ssh oder nur rsync?



Die Dateien auf dem Server liegen in einem Sicherheitsrelevanten-System. Ein unidirektionaler Zugriff ist daher unabdingbar, um eine Rückwirkungsfreiheit zu gewährleisten.
Da ist die Frage was du unter "unidirektionaler Zugriff" verstehst. Das ganze läuft über TCP, daher kommen Antworten im Protokoll zurück und ist somit nicht mehr "unidirektional". Sprich wenn entsprechende Sicherheitslücken vorhanden sind bilden diese einen geeigneten Angriffsvektor über die Antwort-Pakete. Also kann man diese Rückwirkungsfreiheit eigentlich nur unabhängig von möglichen vorhandenen oder entstehenden Softwarefehlern betrachten.



Ziel:
Durchführung einer Systemvalidierung zum Nachweis der Rückwirkungsfreiheit.

Da stellt sich die Frage ob du dafür Testfälle vorgesehen hast? Mir fällt eigentlich speziell dafür nur Source-Code durchackern ein. Im Normalfall und richtig konfiguriert funktioniert der Zugriff in eine Richtung ohne, dass auf dem unsicheren Server ein Zugriff auf den sicheren möglich ist. Wie du das jetzt aber nachweisen willst ist mir nicht klar, außer du suchst dir die entsprechenden Stellen im Code raus und stellst die entsprechenden Funktionen auf dem Papier vereinfacht dar. Stempel drauf und ab in den Ordner. Wie gesagt mögliche Sicherheitslücken wirds da in Zukunft immer geben. Da kannst du den Source-Code einer professionellen Sicherheitsanalyse unterziehen lassen. Das wäre meine Empfehlung, bevor du den Nachweis mit "ein Forist hat gesagt: Check geht" begründest.



Frage:
Sind euch Situationen bekannt, die die Rückwirkungsfreiheit durch Rsync negativ beeinflussen können? Oder gibt es eine Aussage, die die Rückwirkungsfreiheit definitiv beweist?

Wie gesagt betrachtest du das fehlerfreie Vorgehen der Software wäre das so gesagt wasserdicht. Wasserdicht nachweisen kannst du meiner Meinung nach nur, wenn du die entsprechenden Stelle im Code nachvollziehst und absegnest und wenn du Sicherheitslücken mit ins Spiel bringst hast du noch mehr Arbeit damit :D



Abgesehen davon halte ich es für fragwürdig Daten von einem sicheren System auf ein unsicheres System ggf. noch in ein unsicheres Netz zu transferieren. Das Backupsystem sollte mindestens die gleiche Klassifizierung wie das zu sichernde System haben. Hier kommts dann auch wieder drauf an ob ggf. Daten transferiert werden, die einen Einbruch ins sichere System zulassen? Ganz klassisch abgespeicherte Zugangsdaten oder Keyfiles oder eben andere Angriffsszenarien...

[florian0285]

Ein Beweis wäre für mich z. B. mit der Methode: Vorherschnappschuss-Nachherschnappschuss-Vergleich möglich. Vorausgesetzt während der Vergleichszeit wird nichts geschrieben.
Eine mögliche Hauptmethode(vorherschnappschuss,rsync,nachherschn appschuss) wäre es, eine sortierte Liste von Dateien zu haben mit Prüfsummen(MD5/SHA###/...) über alle Dateien zu generieren. Die Prüfsumme über diese Liste muss vorher und nachher identisch sein, womit dann bewiesen wäre das der Inhalt aller Dateien identisch ist als auch die Anzahl der existierenden Dateien.

Da sehe ich ein Problem, dass man ggf. nur lesenden Zugriff ausübt um so z. B. Zugangsdaten auszulesen und dann nach dem rsync Vorgang "authorisiert" zugreift. Dann gibt es nach wie vor ein laufendes System, welches tmp Daten verändert und somit nie 100% des MD5-Checks übereinstimmen werden. Wenn ich dann dumm gesagt in /tmp Schadcode einschleuse fällt der nicht auf. Wenn ich auch einfach irgendwas z. B. netcat in den RAM lade und somit eine Verbindung aufbaue fällt das im Dateisystem ggf. auch nicht auf.

Wie gesagt technisch wäre das von der Funktion her ausgeschlossen, aber in der Theorie wäre es möglich und wäre somit ein Nachweis mit Lücken.

Die andere Frage wäre auch wie sicherheitsrelevant das System denn ist? Ist das ein Heim-Netz mit Urlaubsbildern, der Source-Code von iOS oder COSMIC TOP SECRET von der NATO? Je nachdem wäre dann der "Nachweis" mehr oder weniger entsprechend ausreichend und man kann dann auch vernünftiger empfehlen, weil man dann auch eine Budget-Vorstellung hat. Für deine Urlaubs-Bilder würde z. B. der Nachweis als Hinweis in den Man-Pages ausreichen.

[fork]

Auch wenn ich Florians Beitrag nicht richtig gelesen habe:

Das einfachste überhaupt ist ja per Remote-Mount, der als nur-lesend konfiguriert ist auf das Originalsystem zuzugreifen. In dem Fall kann ist es - von Softwarefehlern bzw. Angriffsmethoden abgesehen nicht möglich das Originalsystem zu verändern.

Nachtrag

Und wenn das tatsächlich nur so sein soll, dass vom Quellsystem(Originalsystem) gemountet wird, dann könnte man einen Benutzer nehmen, der die entsprechenden Verzeichnisse nur lesen darf. Damit ist eine
Veränderung auch ausgeschlossen.

[florian0285]

Auch wenn ich Florians Beitrag nicht richtig gelesen habe:


Ganz kurz gesagt gibt es Probleme beim Nachweis. Da ja ein laufendes System dahinter steckt werden zumindest von diesem Dateien verändert also muss ich Verzeichnisse ausschließen und kann dadurch nicht mehr ausschließen, dass am Dateisystem etwas verändert wurde. Egal ob es jemand im Regelfall technisch könnte oder nicht.

Technisch mag das alles funktionieren und auch mit rsync "unidirektional". Beim Nachweis muss ich aber darauf eingehen, dass dies wirklich nicht geschehen ist. Also ist der Nachweis entweder nicht möglich oder es ist Restrisiko, welcher dann auf dem Nachweis vermerkt werden sollte. Darauf hin wird wohl entschieden ob das so umgesetzt wird oder nicht?

[Torsten84]

Hallo zusammen,

vielen Dank für die ausführlichen Antworten. Ich werde mir dazu heute Abend Gedanken machen und morgen ein Feedback liefern.

Viele Grüße
Torsten

[sysop]

Als Denkanstoss noch rsync als Daemon (https://wiki.ubuntuusers.de/rsync/)

[Torsten84]

Hallo zusammen,

hier die Antworten auf eure Fragen.


Was genau verstehst du jetzt unter "gemountet"?
Es soll mit "ro-mount" ein Dateiverzeichnis (Nicht das Dateisystem) auf dem nicht sicheren Server abgebildet werden.


rsync mit ssh oder nur rsync?
Ohne ssh


Da ist die Frage was du unter "unidirektionaler Zugriff" verstehst
Unter unidirektional verstehe ich, dass durch Rsync nur ein "lesender" Zugriff stattfindet und keine Daten auf den sicheren Server geändert/gelöscht/hinzugefügt werden können.



Da stellt sich die Frage ob du dafür Testfälle vorgesehen hast?
Ja, für sämtliche Anforderungen sind Testfälle (soweit technisch möglich) vorgesehen. Nicht testbaren Anforderungen werden durch Analysen nachgewiesen. Der Aufwand für die Tests zum Thema Rückwirkungsfreiheit spielt keine Rolle, da bin ich unabhängig von anderen Instanzen.




Abgesehen davon halte ich es für fragwürdig Daten von einem sicheren System auf ein unsicheres System ggf. noch in ein unsicheres Netz zu transferieren. Das Backupsystem sollte mindestens die gleiche Klassifizierung wie das zu sichernde System haben. Hier kommts dann auch wieder drauf an ob ggf. Daten transferiert werden, die einen Einbruch ins sichere System zulassen? Ganz klassisch abgespeicherte Zugangsdaten oder Keyfiles oder eben andere Angriffsszenarien...

Es werden keine sensiblen/kritische Daten transferiert.


Die andere Frage wäre auch wie sicherheitsrelevant das System denn ist? Ist das ein Heim-Netz mit Urlaubsbildern, der Source-Code von iOS oder COSMIC TOP SECRET von der NATO?
Die Sicherheitsrelevanz würde ich es zwischen Source-Code von IOS und Nato einstufen.


Zu empfehlen ist hier das durcharbeiten der rsync-manpage für Details und vor allem wie die Standardeinstellungen für rsync ist.
Das werde ich tun.


Ein Beweis wäre für mich z.B. mit der Methode: Vorherschnappschuss-Nachherschnappschuss-Vergleich möglich.
Das ist eine gute Idee. Über die Prüfsummen kann ich zumindest nachweisen, dass die transferierten Dateien nicht durch Rsync verändert worden. Von dem laufenden System werden die Dateien, sobald sie generiert wurden, nicht mehr angefasst.


Dann gibt es nach wie vor ein laufendes System, welches tmp Daten verändert und somit nie 100% des MD5-Checks übereinstimmen werden.
Das sehe ich auch so. Mit der Methode: Vorherschnappschuss-Nachherschnappschuss-Vergleich kann ich nur sicher Nachweisen, dass die transferierten Dateien durch Rsync nicht verändert wurden. Da das laufende System permanent neue Dateien erzeugt, kann ich durch den Check nicht mit Sicherheit sagen, ob Rsync oder das laufende System die Dateien erzeugt hat.


Mir fällt eigentlich speziell dafür nur Source-Code durchackern ein
Das werde ich zur Nachweisführung aufnehmen. Vielleicht könnte ich das auch vereinfachen, in dem ich lediglich prüfe, ob die Funktionen von Rsync die einen Einfluss auf die Rückwirkungsfreiheit haben, nicht enthalten sind.





Ich danke euch vielmals für eure Antworten. Hat sich etwas an euren Aussagen aufgrund meiner beantworteten Fragen geändert?

Viele Grüße
Torsten

[fork]

Die temporäre Pause der Datenveränderung des Produktivsystems kann man durch anhalten der Dienste erreichen, die die Daten schreiben. Da der Validierungsprozess evtl. länger dauert, kann man unmittelbar nach dem abschalten der Dienste und vor dem validieren einen Dateisystem-Snapshot(geht nur mit zfs/btrfs bzw. etwas unkomfortabler mit LVM) erzeugen, den man dann validiert. Ein Dateisystemsnapshot ist ein Prozess, der keine bzw. minimale Zeit benötigt(Stichwort: Copy-On-Write). Anschliessend werden alle Veränderungen Nach dem Abschluss des Validierungsprozess kann dann der Snapshot wieder gelöscht werden, was dann bei hohem Veränderungsaufkommen etwas dauern könnte.

[Newbie314]

Die Sicherheitsrelevanz würde ich es zwischen Source-Code von IOS und Nato einstufen.

In dem Falle solltest du auch prüfen ob du alle relevanten Vorschriften und evtl. BSI Vorgaben kennst. Manchmal gibt es da Überraschungen, z.B. dass das BSI GpG nicht als sicheres Verschlüsselungsverfahren zugelassen hat obwohl Snowden es fleißig benutzt.

[florian0285]

Wenns nur die bestimmten Daten betrifft rudere ich mit "dem Problem" zurück und sage "läuft".

Wie du dann den abgleich machst is ja von fork schon gut beschrieben und nur noch von deinem Zeitfaktor abhängig.

Das einzige wo man überlegen könnte wäre der mount am unsicheren System. Hängt natürlich vom Netzaufbau und der Datendiode ab. Wenn möglich würde ich das drehen, dass "sicher" die Daten auf "unsicher" schiebt bzw mountet. Sonst muss am sicheren System ein Zugriff geöffnet werden, der evtl vermeidbar wäre.




Manchmal gibt es da Überraschungen, z.B. dass das BSI GpG nicht als sicheres Verschlüsselungsverfahren zugelassen hat obwohl Snowden es fleißig benutzt.
Woher kommt das?

Das BSI empfiehlt es sogar als Maßnahme im Grundschutz:
https://www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKataloge/Inhalt/_content/m/m05/m05063.html

Die eingesetzten Verschlüsselungsverfahren u. a. AES, RSA und DSA sind ebenfalls anerkannt. Lediglich die Zertifizierung für nationale VS fehlt.

[Newbie314]

Lediglich die Zertifizierung für nationale VS fehlt

Exakt der Grund warum ich es als Beispiel nahm.

[florian0285]

In Behörden hat in der Regel die Entscheidungsgewalt der zuständige Dienststellenleiter welche er auf seinen IT-Sicherheitsbeauftragten übertragen kann. Die "Vorgaben" des BSI sind dafür erstmal nur Empfehlungen. Wenn z. B. aus plausiblen Gründen (z. B. kostet zu viel und wir haben kein Geld) von der Empfehlung abgewichen wird ist das grundsätzlich zulässig. Man darf nur ein "Vorgabesystem" nicht abändern. Zum Beispiel die VPN Hardware der übergeordneten Dienststelle einfach gegen was anderes tauschen. Für sein eigenes System trifft man selbst die Entscheidung, nicht das BSI. Hier wird das Einzel-System neu aufgebaut und beinhaltet keine kritischen Daten. Sonst würde es schon mal am Netzübergang von rot in schwarz scheitern. Weil hier schwarz in rot greift.

GnuPG ist demnach kein "unsicheres Verfahren" wie du sagst, sondern hat für bestimmte Daten einfach keine Zertifizierung. Wenn eine Dienststelle für sein System eine Vorgabe strikt als Maßstab umsetzt ist das auch möglich und nur absicherungsdenken. Deshalb gibt es auch für jede/viele Behörde(n) wieder eine eigene Liste mit zugelassener Hard- und Software die der BSI-Liste fast baugleich sind, nur mit vereinzelten spezifischen Unterschieden.

Aber dass das BSI GnuPG für unsicher erklärt hat stimmt nicht [emoji317]